Object Oriented Analysis & Design

1. Object Oriented Analysis & Design K Hari Babu Department of Computer Science & Information Systems

2. Traditional Software Development Model Algorithms + Data Structures = Programs Emphasis was more on functionality. In object oriented systems, emphasis is on objects which combine functionality and data together. Tell system: “Compute payroll of this employee.” Tell employee object: “Compute your payroll” Responsibilities are assigned to objects.

3. Software development Analysis, design, implementation, testing & refinement to transform users’ need into software solution that satisfies those needs Object-oriented approach more rigorous process to do things right more time spent on gathering requirements, developing requirements model & analysis model, then turn into design model need not see code until after 25% development time

4. Software process – transforming needs to software product

5. Object-oriented approach: A use-case driven approach Object-oriented software development life cycle consists of Object-oriented analysis Object-oriented design Object-oriented implementation Use-case model can be employed throughout most activities of software development designs traceable across requirements, analysis, design, implementation & testing can be produced all design decisions can be traced back directly to user requirements usage scenarios can be test scenarios

6. Object-Oriented Systems Development Approach

7. Object-Oriented software development Activities Object-oriented analysis - use case driven Object-oriented design Prototyping Component-based development Incremental testing Encourages viewing of system as a system of cooperative objects incremental development

8. Object-oriented analysis - use-case driven Use Case, is a name for a scenario to describe the user–computer system interaction. Determine system requirements, identify classes & their relationship to other classes in domain To understand system requirements need to identify the users or actors who are the actors ? How do they use system ?

9. Use case Typical interaction between user & system that captures users’ goal & needs use cased modeling expressing high level processes & interactions with customers in a scenario & analyzing it gives system uses, system responsibilities developing use case is iterative when use case model better understood & developed, start identifying classes & create their relationship

10. Identifying objects What are physical objects in system ? Individuals, organizations, machines, units of information, pictures, whatever makes up application/ make sense in context of real world objects help establish workable system Intangible objects ? Data entry screens, data structures Documentation modeling & documentation inseparatable good modeling implies good documentation

11. Object-oriented Design Goal : to design classes identified during analysis phase and the user interface Identify additional objects & classes that support implementation of requirements Eg. add objects for user interface to system (data entry windows, browse windows) Activities & focus of oo analysis & oo design are intertwined

12. Object-oriented Design First, build object model based on objects & relationship Then iterate & refine model Design & refine classes Design & refine attributes Design & refine methods Design & refine structures Design & refine associations

13. Guidelines in Object-oriented Design Reuse rather than build new classes Know existing classes Design large number of simple classes rather than small number of complex classes Design methods Critique what has been proposed Go back & refine classes

14. Model Model is an iterative process. It can represent static or dynamic situations. Model Dynamic Static Provides a system’s parameters at rest or at a specific point in time. (e.g.) class diagram Represents a system’s behaviors that, taken together, reflect its behavior over time. (e.g.) interaction & activity diagrams

15. Why modeling Blue print Clarity Familiarity Maintenance Simplification

16. Advantages of modeling Easy to express complex ideas Reduce complexity Enhance & reinforce learning and training Low cost Easy to change the model

17. What is Unified Modeling Language (UML)? The UML is a graphical / standard language for visualizing, specifying, constructing & documenting the artifacts of a software system.

18. History of UML 1980 – 1990  Many different methodologies Booch method by Grady Booch Object Modeling Technique (OMT) by Jim Rumbaugh Object Oriented Software Engineering (OOSE) by Ivar Jacobson Each method had its strengths & weaknesses. Booch was great in design OMT & OOSE were great in analysis

19. History of UML UML 1.0 (January 1997) UML 1.1 (November 1997) UML 1.3 (Minor revision 1999) UML 1.4 (Minor revision 2000) UML 2.0 (Major revision 2004)

20. UML Concepts UML can be used to support entire software life cycle. The interaction of application with the outside world (use case diagram) Visualize object interaction (sequence & collaboration diagrams) The structure of system (class diagram) View the system architecture by looking at the defined package. The components in your system (component diagram)

21. UML Diagrams Class diagram (Object Modeling) Use case diagram Activity diagram Sequence diagram Collaboration diagram State chart diagram Component diagram Deployment diagram

22. 1. Class diagram Shows tatis structure of the system Object modelling is the process by which the logical objects in the real world are mapped to objects in the program. Problem space  logical space

23. 2.Use case diagram It shows a set of use cases and actors and their relationships. Address the static view of a system. Actor user (or) someone / something outside the system that interacts with the system (it must be a noun) & it is represented by a stickman. ……contd

24. 2.Use case diagram Use case  a sequences of actions (it must be a verb) & it is represented by an oval. Relationship illustrates a connection among model elements. UnidirectionalBi-directional It is created to visualize the interaction of your system with the outside world.

25. 2.Use case diagram

26. 3.Activity Diagram It shows the flow of events with our system & what is going on inside a use case. We draw the activity diagram for each & every use case. It is showing flow of control from activity to activity.

27. 3.Activity Diagram Activity  it represents the performance of a task within the workflow. Activity is represented by a lozenge (horizontal top and bottom with convex sides) Start state shows the beginning of a workflow on an activity diagram. There is only one start state.

28. 3.Activity Diagram A start state is represented by a solid circle. An end state represents a final or terminal state on an activity diagram. A end state is represented by a bull’s eye.

29. 3.Activity Diagram A state transition shows what activity follows after another. It is represented by a solid line with an arrow.

30. 3.Activity Diagram A decision is a point in an activity diagram where guard conditions are used to indicate different possible transitions. It is represented by a diamond. Guard conditions control the transition of a set of alternate transitions that follows after the activity has been completed.

31. 3.Activity Diagram AND Synchronization bar Joint

32. 3.Activity Diagram A synchronization bar allows you to show concurrent threads in a work flow of a use case. It represented by a thick horizontal or vertical line.

33. 3.Activity Diagram – ProcessLoan Use case

34. 4.Sequence Diagram It shows step by step what must happen to accomplish a piece of functionality provided by the system. It has 2Ds. Vertical dimensions  represents time Horizontal dimensions  represents different objects. Vertical line is called the object’s life line.

35. 4.Sequence Diagram Life line  the existence object at a particular time. Objects are shown at the top. The object role is shown as a vertical dashed line, the life line.

36. 4.Sequence Diagram A message is the communication between 2 objects that triggers an event. It is represented by a labeled arrow. Each message is represented by an arrow between the life lines of 2 objects.

37. 4.Sequence Diagram A focus of control shows the period of time during which an object is performing an action, either directly or through a subordinate procedure. It represented by a tall, thin rectangle.

38. 4.Sequence Diagram

39. 5.Collaboration Diagram It displays objects and their links to one other.

40. 5.Collaboration Diagram It is made up of the following basic elements : Actors Objects Links Messages

41. 5.Collaboration Diagram Actors  user Objects  data + logic / the representation of some real world entity. 3. Links  a pathway for communication between objects.  represented by a solid line between 2 objects 4. Messages  the communication between objects that triggers an event.  represented by a labeled arrow above the link.

42. 5.Collaboration Diagram

43. 6. State Chart Diagram It shows the sequence of states. A state is represented as a rounded box, which may contain one or more compartments. Name compartment  holds the name of the state. Internal transition compartment  list of actions / activities Start & end states

44. 6. State Chart Diagram

45. 7.Component Diagram It shows relationship between the components in the system. A component may be a software component [for (e.g.) a.h file in C++ (or) a .java file in Java], a run time component [for (e.g.) a.DLL file]

46. 7.Component Diagram

47. 8. Deployment Diagram It shows the configuration of run time processing elements & the software components, processes & objects that live in them. It shows the nodes in the system & the connections between them.

48. 8. Deployment Diagram

49. Object Oriented Analysis Identifying Use Cases Object Analysis: Classification Identifying object relationships, Attributes and Methods.

50. Identifying the use cases: Goals The use-case approach to object-oriented analysis and the object-oriented analysis process. Identifying actors. Identifying use cases. Documentation.