Object Oriented Analysis and Design Using UML

1. Object Oriented Analysis and Design Using UML

2. Course description: • OBJECTIVE: The understand the Unified Modeling Language and orient towards Object Oriented methodology using UML for modeling software systems. • TARGET AUDIENCE: In particular, it is intended for software professionals who have sound knowledge of object concepts and some experience towards analysis and design. • PREREQUISITES: Good understanding of object concepts. Sound knowledge of any object oriented language. Knowledge of software engineering process.

3. Course description: • TABLE OF CONTENTS: Module1 Introduction Module2 Use case diagram Module3 Flow of events Module 4 Realization of the class diagram Sequence diagram and Collaboration Diagram Module5 Class diagram and refinement attributes Module6 State transition and activity diagram Module7 Implementation diagram Component diagram and Deployment diagram Module8 Understanding project culture Appendix-A

4. Module-1

5. Importance of modeling • What is a model? • A model is a simplification of reality • Why do we model? • help visualizing • permit specification • provides a template • document decisions

6. 4 Principles of Modeling • Choose your models well • Every model may be expressed at various levels of precision • The best models are connected to reality • No single model is sufficient

7. What is Software Engineering? • DEFINITION:The application of systematic, disciplined and qualifiable approach to the development, operation and maintenance of a software system is software engineering. • Software development life cycle has following stages: REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TESTING

8. Effort Distribution for each stage: Analysis & design 40 % Development 20 % Testing 40 % Analysis - What is to be done ? Design - How it is to be done ? Two Popular methodology approaches are: • Structured Analysis & Design • Object Oriented Analysis & Design-OO model

9. Major benefits of OOAD: • The object oriented approach is a way of thinking about a problem using real world concepts instead using adhoc function concepts. • We intent to learn OOAD approach for the following reason: • Promotes better understanding of user requirements • Leads cleaner design • Design flexibility' • Decomposition of the system is consistent • Facilitates data abstraction & information hiding • Software reuse • Easy maintenance • Implementation flexibility

10. Elements of OO Methodology: Following are three elements for every OO methodology: • Notation • Process / Method • Tool

11. What is Notation? • Notation: It is collection of graphical symbols for expressing model of the system. The Unified Modeling Language [UML] provides a very robust set of notation which grows from analysis to design. This brings end of the method wars as far as notation is concerned with adoption of the language [UML] By unifying the notations used by these object oriented methods, the unified modeling language provides the basis for a de facto standard in the domain of object oriented analysis and design founded on a wide base of user experience

12. What is UML? • It is a Unified Modeling Language, which is mainly a collection of graphical notation that methods use to express the designs. • The UML is language for visualizing, specifying, constructing and documenting the artifacts of software system. • UML is visual modeling language for modeling systems and is non proprietary • UML is not a radical departure from Booch, OMT, OOSE notations but rather legitimate successor to all three. • It is an evolutionary step, which is more expressive and more uniform than individual notations. • Whitehead says “ By relieving the brain of unnecessary work, a good notation, sets it free to concentrate on more advance and creative problems “ UML is not a method or process but is the means to express the same.

13. Where can you use the UML? • System of several different kinds, absolutely anywhere everywhere. • Primarily for software intensive systems like: Systems software Business processes

14. The Evolution of the UML: OMG vote’97 Submission to OMG, sept’97 Public Feedback UML1.1 Submission of OMG group UML1.0 Beta version OOPSLA’96 UML0.9 Unified Method 0.8 Booch OMT OOSE Other method

15. Advantages of UML: • Captures business processes • Enhance communication and ensures the right communication • Capability to capture the logical software architecture independent of the implementation language • Manages the complexity • Enables reuse of design

16. UML refers to: • UML things: Class, component, node, relationship, package etc.. • UML diagrams: Use case diagram, interaction diagram, class diagram, State diagram,deployment diagram

17. What is Process? What isProcess? • It is an extensive set of guidelines that address the technical and organizational aspects of software development focusing on requirements, analysis and design. • Process basically encapsulates the activities leading to the orderly construction of system model. • OO model supports the iterative and incremental model for the process.

18. More about Process? • Guidance as to the order of team’s activities • It specifies what artifacts should be developed • It directs the task of individual developers and team as a whole • It offers criteria for monitoring and measuring project activities • The selection of particular process will vary greatly depending upon things like problem domain, implementation technology and skills of team • Booch,OMT,OOSE and many other methods have well defined process and UML supports almost all methods • There has been some convergence on development process practices but there is no consensus for standardization. • Framework for the every stage of software development life cycle.

19. Best Practices followed by Rational Unified Process • Develop software iteratively • Manage requirements • Use component based architectures • Visually model software • Verify S/W quality • Control changes to software.

20. What is a tool? • It is automated support for every stage of software development life cycle. • Since we are concentrating on requirement, analysis and design phase, following are the names of few tools which are greatly in use: 1. Rational Rose 2. Cayenne 3. Platinum 4. Select

21. Why Tool? • Helps designer for creating designs much more quickly. • Supports validations like: Consistency checking Completeness checking Constrain checking. • Time required for certain operation could be predicted . • Code generation • Reverse engineering. • Round trip engineering • Conversion from SSAD to OOAD • Quick documentation…etc

22. Triangle for Success: • All three components play equally important role towards the success of the project. Notation Tool Method

23. Objective of the first module: • Get introduced with Unified Modeling Language and know the basic components of software development life cycle.

24. Module-2

25. OO model: DYNAMIC MODEL STATIC MODEL LOGICAL MODEL PHYSICAL MODEL The models of Object Oriented Development

26. Models and Views: • 4+1 view of OO model. • Process view • Deployment view • Logical view • Dynamic view + • Use case view • As shown in the model , for each dimension we define a number of diagrams that denote a view of the system’s model. • The use case view is central since its contents drive the developments of other views.

27. UML diagrams: 1. Use case diagram 2. Class Diagram 3. Behavioral diagrams - State chart diagrams - Object diagram - Activity diagrams - Interaction diagrams - Sequence diagrams - Collaboration diagrams 4. Implementation diagrams - Component diagram - Deployment diagram

28. Semantics of Diagrams: • Use case diagrams represent the functions of a system from the user’s point of view. • Sequence diagrams are a temporal representation of objects and their interactions. • Collaboration diagrams are a spatial representation of objects, links, and interactions. • Object diagrams represent objects and their relationships, and correspond to simplified collaboration diagrams that do not represent message broadcasts. • Class diagrams represent the static structure in terms of classes and relationships.

29. Semantics of Diagrams: Contd... • State chart diagrams represent the behavior of a class in terms of states • Activity diagrams are to represent the parallel behavior of an operation as a set of actions. • Component diagrams represent the logical components of an application. • Deployment diagrams represent the deployment of components on particular pieces of hardware.

30. What is USE CASE diagram? • A use case diagram establish the capability of the system as a whole. • Components of use case diagram: Actor Use case System boundary Relationship Actor relationship • Semantic of the components is followed.

31. Manager Cashier Customer ACTOR: What is an actor? • An actor is some one or something that must interact with the system under development • UML notation for actor is stickman, shown below.

32. ACTOR: More about an actor: • It is role a user plays with respect to system. • Actors are not part of the system they represent anyone or anything that must interact with the system. • Actors carry out use cases and a single actor may perform more than one use cases. • Actors are determined by observing the direct uses of the system,

33. ACTOR: Contd… • Those are responsible for its use and maintain as well as other systems that interact with the developed system. • An actor may - input information to the system. - receive information from the system. - input to and out from the system.

34. ACTOR: How do we find the actor? • Ask following questions to find the actors: • Who uses the system? • Who installs the system? • Who Starts up the system? • What other systems use this system? • Who gets the information from the system? • Who provides information to the system? • Actor is always external to the system. They are never part of the system to be developed.

35. ACTOR: 4-Categories of an actor: • Principle : Who uses the main system functions. • Secondary : Who takes care of administration & maintenance. • External h/w : The h/w devices which are part of application domain and must be used. • Other system: The other system with which the system must interact.

36. ACTOR: Note: • If newly identified actor is using a system in a same way like an existing actor, then new actor can be dropped. • If two actors use system in the same way they are same actors.

37. USE CASE: What is USE case? • A use case is a pattern of behavior, the system exhibits • Each use case is a sequence of related transactions performed by an actor and the system in dialogue. • USE CASE is dialogue between an actor and the system. • Examples: Withdrawal of cash from ATM Open new account

38. USE CASE: More about USE CASE: • It is a snapshot of one aspect of system. • They model a dialog between actor and system. • A use case typically represents a major piece of functionality that is complete from beginning to end. • Most of the use cases are generated in initial phase, but you find some more as you proceed. • A use case may be small or large. It captures a broad view of a primary functionality of the system in a manner that can be easily grasped by non technical user.

39. USE CASE: Contd… • A use case must deliver something of value to an actor. • The use cases may be decomposed into other use cases. • Use cases also present a good vehicle for project planning.

40. USE CASE: How do we find the use cases? • What functions will the actor want from the system? • Does the system store information? What actors will create, read, update. Or delete that information? • Does the system need to notify an actor about changes in its internal state?

41. USE CASE: • Generic format for documenting the use case: - Pre condition: If any • Use case : Name of the case. • Actors : List of actors(external agents), indicating who initiates the use case. • Purpose : Intention of the use case. • Overview : Description. • Type : primary / secondary. • Post condition: If any • Typical Course of Events: ACTOR ACTION : Numbered actions of the actor. SYSTEM RESPONSE : Numbered description of system responses.

42. USE CASE: USE CASE documentation example: • The following use case describes the process of opening a new account in the bank. Use case :Open new account Actors :Customer, Cashier, Manager Purpose :Like to have new saving account. Description :A customer arrives in the bank to open the new account. Customer requests for the new account form, fill the same and submits, along with the minimal deposit. At the end of complete successful process customer receives the passbook. Type :Primary use case.

43. Grouping USE CASES: • Those use case functionality which are directly dependent on the system environment are placed in interface objects • Those functionality dealing with storage and handling of information are placed in entity objects • Functionality's specific to one or few use cases and not naturally placed in any of the other objects are placed in control objects By performing this division we obtain a structure which helps us to understand the system from logical view

44. OOAD --- USE CASE driven Analysis Design & Implementation Test Use cases make up the glue Implement use cases Verify that use cases are satisfied Capture,clarify & validate use cases

45. SYSTEM BOUNDARY: What is System Boundary? • It is shown as a rectangle. • It helps to identify what is external verses internal, and what the responsibilities of the system are. • The external environment is represented only by actors.

46. RELATIONSHIP: What is Relationship? • Relationship between use case and actor. Communicates • Relationship between two use cases Extends Uses • Notation used to show the relationships: << >>

47. RELATIONSHIP: • Relationship between use case and actor is often referred as “communicates” . • Relationship between two use cases is refereed as either uses or extends. USES: • - Multiple use cases share a piece of same functionality. • - This functionality is placed in a separate use case rather than documenting in every use case that needs it.

48. RELATIONSHIP: Contd... • A uses relationship shows behavior that is common to one or more use cases. EXTENDS: • It is used to show optional behavior, which is required only under certain condition.

49. USE CASE diagram: Use case diagram for the shown functionality. Balance status report extends Withdraw cash Clerk Customer uses Validation ATM Manager

50. Objective of the second module • To understand and capture the detailed specification of a system to be developed, from user perspective.