object oriented analysis & design unit-1

1. SOWMIYA…(Padmavani Arts & Science College for Women, Salem) OBJECT-ORIENTED ANALYSIS AND DESIGN (OOAD) In UML by

2. CHAPTER-1 ABOUT OOAD

3. Roles in software department Planning Upper Case Analysis Design INTEGRATEDCASE Implementation Lower Case Testing Maintanance

4. Object Orientation Describe the (OO) method of building software. Approach –treated as the most important element. Cannot flow freely around the system. Restrictions –that can be manipulate the data. BINDS THE DATA AND METHOD

5. Object form basis- properties Encapsulation Abstraction Implementation hiding Inheritance Dynamic binding Polymorphism Overriding Overloading

6. 1.Encapsulation m Wrapping upon data. Various meanings , depending upon the approach used for Analysis & Design. getEmpID() attributes empID empName dateofjoining seEmpID() setEmpName() operations getDOJ() getEmpName() setDOJ()

7. 2.Abstraction Object is consists of many subunits. Eg: Station management Power Management,etc 3.Implementation Hiding • Manner in which data is stored in an object is hidden from the outside world. • Eg: • dd/mm/yyyy or • mm/dd/yyyy.

8. 4.Inheritance • It is a property. • One class inherits the features of another class. Eg: Animal Mammal Dog Poodle

9. 5.DYNAMICBINDING • Technique in which the piece of code to be executed is determined only at runtime. • User clicks,the particular piece of code to be executed. Eg: during compiling this will be execute. 6.polymorphism • Ability to take more than one form. • Eg: • Calculate area() • Square=side * side () • Rectangle= length() & breadth()

10. 7.OVERRIDING & OVERLOADING • METHOD OVERRIDING • Same method, name and signature can be used in different subclasses of the class and defined differently in each subclass. • METHOD OVERLOADING • Same name of the method with different signatures is used many times in the same class.

11. What is OOAD? • OBJECT ANALYSIS • Understanding requirements. • Developer tries to identify the concepts in the domain. Eg: VLMS,Patron,DVD,Cassette(objects) • OBJECT DESIGN • Finding software objects. Eg: Conceptual object - DVD Attributes - capacity,title of the film,film certifications,etc.

12. OVERVIEWOFVARIOUSOOADMETHODOLOGIES • BOOCH METHODOLOGY • COAD & YOURDON METHODOLOGY • Fusion • Jacobson: Objectory and OOSE • LBMS SEOO • Rumbaugh OMT • Shlaer and mellor OO Analysis

13. GOALSOFUML • Visibility • Extensibility • Independence • OO tool markets • Integrate best practices

14. CHAPTER - 2 USE CASE MODELING

15. USE CASE • Describes how a user uses a system to accomplish a particular goal.  • Each other to visualize:  • whatis being described? (system) • whois using the system? (actors) • what do the actors want to achieve? (use cases) • Ensure correct system is developed by capturing the requirementsfrom the user's point of view.

16. ACTORS Actor Human Non-human <<actor>> ATM authorization service • Role that a user plays with respect to the system. Eg:

17. USE CASE RELATIONSHIPS • THE INCLUDE RELATIONSHIP • THE EXCLUDE RELATIONSHIP • THE USECASE GENERALIZATION

18. 1.THE INCLUDE RELATIONSHIP • Depict similar behaviour across several use-cases,without the description of that behaviour being replicated. customer <<include>> <<include>> Process Rental request Process Sale request Handle Credit Card Payment

19. 2.THE EXTEND RELATIONSHIP • Extending use case is dependent on the extended (base) use case. • Extending use case is usually optional. • Extended (base) use case must be meaningful on its own. Extension points Customer, an employee of IT Company SoftTech Payment Process Customer Sale Handle Voucher Redemption

20. 3.USE CASE GENERALIZATION Relationship between a BASE USECASE & a DERIVED USECASE. Specifies DERIVED USECASE  BASE USECASE. Draw Polygon Draw Triangle Draw Square Mathematician

21. WRITING USECASE FORMALLY Formal template fields as: Primary actor Stakeholders and interests Pre & Post condition Main success scenario Alternate flow Special requirements Technology and data variations list

22. How to choose the System Boundary Grouping the use cases in the rectangle boundary. System Boundary in Visual Paradigm provides use case containment behavior.

23. FINDING ACTORS ACTOR An actor instance is someone or something outside the system that interacts with the system. An actor is anything that exchanges data with the system. An actor can be a user, external hardware or another system. FINDING ACTORS Who- invlolved in keeping it in working condition? Who-will manage & secure the system? Will- system interact any other system/hardware? Will – take services or give services to any other system?

24. FINDING USECASES primary tasks the actor wants the system to perform? Will the actor create, store, change, remove, or read data in the system? Will the actor need to inform the system about sudden, external changes? Does the actor need to be informed about certain occurrences in the system? Will the actor perform a system start-up or shutdown?

25. USE FOR USECASES FOR VALIDATION & VERIFICATION Testing involves both Validation & Verification VALIDATION— built that actually meets the requirements of the customer. Repeat iterations & frequent reviews & discussions with the customer. VERIFICATION –- built according to the requirements specification & design. Analysis & Design test cases can be prepared. It detect the presence of bugs in the programs.

26. USECASE REALIZATION Realization –between an element that specifies behaviour & one that provides implemenation Represents the design perspective of a usecase. A particular usecase is realized within the design model, in terms of collaborating objects.

27. Any Questions ???

28. <<<<THANK YOU>>>>