Practical UML

Slide 1: Practical UML Rama Raman & Mohammed Memon May 20, 2002

Slide 2: Information Discussions are encouraged Project development experience necessary Object Oriented Analysis and Design preferred May 20, 2002 Rama Raman & Mohammed Memon 2

Slide 3: Objectives Why Model ? Architectural views UML Overview UML Diagrams CASE tool support for UML May 20, 2002 Rama Raman & Mohammed Memon 3

Slide 4: The Software Crisis “We estimate only 26% of software projects will succeed” Source: Standish Group – Chaos Report 1998. May 20, 2002 Rama Raman & Mohammed Memon 4

Slide 5: Models Models are the language of designer, in many disciplines Models are representations of the system to-be- built or as-built Models are vehicle for communications with various stakeholders Visual models, blueprints Scale Models allow reasoning about some characteristic of the real system May 20, 2002 Rama Raman & Mohammed Memon 5

Slide 6: Many stakeholders, many views Architecture is many things to many different interested parties end-user  customer  project manager  system engineer  developer  architect  maintainer  other developers  Multidimensional reality Multiple stakeholders multiple views, multiple blueprints May 20, 2002 Rama Raman & Mohammed Memon 6

Slide 7: Representing System Architecture Logical View Implementation View End-user Programmers Functionality Software management Use Case View Process View Deployment View System integrators System engineering Performance System topology Scalability Delivery, installation Throughput Communication Physical Conceptual Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 7

Slide 8: The Unified Modeling Language The UML is a language for visualizing  specifying  constructing  documenting  the artifacts of a software-intensive system Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 8

Slide 9: The Value of the UML Is an open standard Supports the entire software development lifecycle Supports diverse applications areas Is based on experience and needs of the user community Supported by many tools Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 9

Slide 10: Overview of the UML Modeling elements Relationships Extensibility Mechanisms Diagrams Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 10

Slide 11: Modeling Elements Structural elements class, interface, collaboration, use case,  active class, component, node Behavioral elements interaction, state machine  Grouping elements package, subsystem  Other elements note  Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 11

Slide 12: Relationships Dependency Association Generalization Realization Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 12

Slide 13: Extensibility Mechanisms Stereotype Tagged value Constraint Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 13

Slide 14: Models A model is a complete description of a system from a particular perspective Some Perspectives : The Use Case Model  The Logical Model  The Dynamic Model  The Physical Model  Source: Rational Software May 20, 2002 Rama Raman & Mohammed Memon 14

Slide 15: Diagrams Use Case Diagram Statechart Diagram Sequence Diagram Collaboration Class Diagram Component Diagram Diagram Activity Diagram Deployment Diagram May 20, 2002 Rama Raman & Mohammed Memon

Slide 16: The Use Case Model A view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’). A scenario for a medical clinic.  "A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. " Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 16

Slide 17: Use Case Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 17

Slide 18: Use Case Diagram Captures system functionality as seen by users Built in early stages of development Purpose Specify the context of a system  Capture the requirements of a system  Validate a system’s architecture  Drive implementation and generate test cases  Developed by analysts and domain experts May 20, 2002 Rama Raman & Mohammed Memon 18

Slide 19: The Logical Model The logical model is a static view of the objects and classes, that make up the design/analysis space, and the relationships between them. The domain model is a looser, high level view of business objects and entities A class diagram is a more rigorous and design focused model. An object diagram shows instances of classes A package diagram is used to organize complex class diagrams by grouping classes into packages May 20, 2002 Rama Raman & Mohammed Memon 19

Slide 20: Class Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 20

Slide 21: Object Diagram The Class diagram above can be shown better like this Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 21

Slide 22: Composition and Aggregation Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 22

Slide 23: Visibility and Scope Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 23

Slide 24: Dependencies and Constraints Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 24

Slide 25: Interfaces and Stereotypes Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 25

Slide 26: Package Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 26

Slide 27: Class Diagram Captures the vocabulary of a system Built and refined throughout development Purpose Name and model concepts in the system  Specify collaborations  Specify logical database schemas  Developed by analysts, designers, and implementers May 20, 2002 Rama Raman & Mohammed Memon 27

Slide 28: The Dynamic Model Interaction diagrams are dynamic. They describe how objects collaborate. A sequence diagram details how operations are carried out -- what messages are sent and when. Collaboration diagrams convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. May 20, 2002 Rama Raman & Mohammed Memon 28

Slide 29: Sequence Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 29

Slide 30: Sequence Diagram Captures dynamic behavior (time-oriented) Built during analysis and design Purpose Model flow of control  Illustrate typical scenarios  Developed by analysts, designers and implementers May 20, 2002 Rama Raman & Mohammed Memon 30

Slide 31: Collaboration Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 31

Slide 32: Collaboration Diagram Captures dynamic behavior (message-oriented) Built during analysis and design Purpose Model flow of control  Illustrate coordination of object structure and control  Developed by analysts, designers and implementers May 20, 2002 Rama Raman & Mohammed Memon 32

Slide 33: The Dynamic Model A state diagram shows the possible states of the object and the transitions that cause a change in state. An activity diagram is essentially a fancy flowchart. Activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another. May 20, 2002 Rama Raman & Mohammed Memon 33

Slide 34: State Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 34

Slide 35: State Diagram Captures dynamic behavior (event-oriented) Built during analysis and design Purpose Model object lifecycle  Model reactive objects (user interfaces, devices, etc.)  Developed by analysts, designers and implementers May 20, 2002 Rama Raman & Mohammed Memon 35

Slide 36: Activity Diagram Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 36

Slide 37: Activity Diagram Captures dynamic behavior (activity-oriented) Built during analysis and design Purpose Model business workflows  Model operations  Developed by analysts, designers and implementers May 20, 2002 Rama Raman & Mohammed Memon 37

Slide 38: The Physical Model The component diagram shows the relationship between software components, their dependencies, communication, location and other conditions. A deployment diagram illustrates the physical deployment of the system into a production (or test) environment. It shows where components will be located, on what servers, machines or hardware. It may illustrate network links, LAN bandwidth & etc. May 20, 2002 Rama Raman & Mohammed Memon 38

Slide 39: The Physical Model This diagram shows the relationships among software and hardware components involved in real estate transactions. Source: www.TogetherSoft.com May 20, 2002 Rama Raman & Mohammed Memon 39

Slide 40: Component Diagram Captures the physical structure of the implementation Built as part of architectural specification Purpose Organize source code  Construct an executable release  Specify a physical database  Developed by architects and programmers May 20, 2002 Rama Raman & Mohammed Memon 40

Slide 41: Deployment Diagram Captures the topology of a system’s hardware Built as part of architectural specification Purpose Specify the distribution of components  Identify performance bottlenecks  Developed by architects, networking engineers, and system engineers May 20, 2002 Rama Raman & Mohammed Memon 41

Slide 42: Architecture and the UML Design View Implementation View Classes, interfaces, Components collaborations Use cases Use Case View Process View Deployment View Nodes Activity, Active classes Organization Dynamics Package, subsystem Interaction, State machine May 20, 2002 Rama Raman & Mohammed Memon 42

Slide 43: Some CASE Support for UML Vendor Main UML Tool Main UML Tool Vendor Aonix StP/UML Ptech Framework Rational Rose/RoseRT Embarcadero (AST) GDPRO Riverton How CA(Platinum) Paradigm Plus MacA&D/WinA&D RogueWave Excel Software RW-UML Studio PrincetonSoftech i-Logix Rhapsody Select Enterprise (Select) Silverrun Silverrun JD MicroGold With Class Sybase PowerDesigner Microsoft Visio Telelogic(SterlingSoftware) Together Tau TogetherSoft Control Center Objecteering U of CAIrvine (Freeware) Objecteering ArgoUML Popkin Object Architect Visual System Visual Analyst May 20, 2002 Rama Raman & Mohammed Memon

Slide 44: Summary - UML UML is a state-of-the-art modeling language suitable for object-oriented system and software development UML was developed collaboratively by many methodologists, but primarily by Jim Rumbaugh, Grady Booch, and Ivar Jacobson, now of Rational UML is a language, not a method, but good OO methods have been adapted to the language UML takes the best of the OMT, Booch, and OOSE notations UML has been standardized by OMG and almost universally accepted by the OO development industry May 20, 2002 Rama Raman & Mohammed Memon

Slide 45: Discussions QUESTIONS ??? May 20, 2002 Rama Raman & Mohammed Memon 45

Slide 46: More information on the web… Rational Software -- UML Resource Center, UML Quick Reference, UML Whitepapers, Recommended Books, UML Cafe TogetherSoft – UML Tutorial, UML Resources The Object Management Group -- UML resource Page, UML Tutorial The UML Center -- UML Information, UML Events, Articles and Publications, Industry Links, UML Tools The UML Zone -- UML FAQ, UML Q&A May 20, 2002 Rama Raman & Mohammed Memon 46

Slide 47: More Information in print… Martin Fowler, Kendall Scott: UML Distilled second edition. Publisher: Addison-Wesley. Doug Rosenberg with Kendall Scott: Use Case Driven Object Modeling with UML. Publisher: Addison-Wesley. Grady Booch, et al: The Unified Modeling Language User Guide. Publisher: Addison-Wesley. James Rumbaugh, et al: The Unified Modeling Language Reference Manual. Publisher: Addison-Wesley. Ivar Jacobson, et al: Unified Software Development Process. Publisher: Addison-Wesley. May 20, 2002 Rama Raman & Mohammed Memon 47

Slide 48: Conclusion Parting thoughts: UML is only as good as the designer Without a software development methodology, UML is not effective. Rational Unified Process is a very effective methodology that incorporates the industry best practices. eXtreme Programming, affectionately known as XP, is a lightweight methodology that is also effective for OO projects. May 20, 2002 Rama Raman & Mohammed Memon 48