A tool for presentation of Architecture UML Diagrams A tool for presentation of Architecture

UML origins 80’s and early 90’s – explosion of modeling methods and notations Not to mention competition among methods people The “three amigos” (Booch, Jacobson, Rumbaugh) were working on the UML by 1996 OMG issued UML 1.3 in March, 2000 OMG issued UML 2.0 in July 2005

UML is Language NOT method Good for communication Standardization is essential Mostly graphical Example: used everywhere in Fowler NOT method You can use any design method you like to create UML diagrams Standardization can be helpful, but is not so important

More precise, less precise … UML Natural language Usefulness in design Code Precision

UML diagram types (1.x) Static diagrams Dynamic diagrams Use case Class Dynamic diagrams Object State Activity Collaboration (Called Communication in UML 2.0) Sequence Implementation diagrams Component Deployment

UML 2.0 New Diagrams Composite Structure – runtime decomposition of a class Interaction Overview – mixed sequence and activity Timing – interaction between object with timing Composite Structure – Runtime decomposition of class

Ron’s Belief: (Applied to UML) Use what makes sense Don’t be subservient to the tool You don’t always need electronic forms and editors – use paper and a pencil!

Use Case Diagram Elements Order Merchandise Order Book <<include>> Enter Credit Card consumer Check Order Status Remember: the ovals are use cases, NOT use case steps Use case names should be: Action-verb + object-phrase

Use Case Diagram

O-O Diagrams Class – static relationships Object – dynamic snapshot Inheritance, composition, association,dependency Object – dynamic snapshot Object relationships at runtime, processes,threads

Classes Class name Attributes Interface Operations

Relationships dependency association generalization realization

Class Diagram

<<interface>> <<transfer object>> Stereotypes Text in << >> are stereotypes Stereotypes should be defined in the project’s glossary. Examples: <<interface>> Runnable + run( ) : void <<transfer object>> BankMessage + balance : Money + account : long

Behavioral Diagrams Sequence Collaboration State Chart Activity Interaction (for one use case) viewed by time Collaboration Interaction (for one use case) viewed by structure State Chart Internal state of an object (or class) across multiple use cases Activity Interaction of multiple objects across multiple use cases (includes concurrent activity)

Sequence diagram

System Sequence diagram (a way to draw use case steps) :Customer :Amazon.com :creditCardSvc Add book to cart Confirm cart contents Request checkout Request authentication Provide credentials Present options Credit card service is a supporting actor This is a case where return arrows are often helpful Don’t try to include the whole GUI spec! These diagrams may not work with business people, but IT people may find them helpful for clarification, design input Third edition of Larman may have different chapter numbers (I have 2nd edition) Provide credit card info, shipping options Validate card Confirm order See Larman, Chpt 9 (2nd edition)

Summing up UML is responsibility-oriented UML diagrams are a means to an end OOAD allows many benefits, but does not guarantee them

UML Usage Guide Use the diagrams to communicate Don’t become a slave to the diagrams What you leave out is as important as what you put into the diagram! Highlight important details; leave the rest out Rule of thumb: when in doubt, leave it out.

Review question Why are there so many types of diagrams?

Bonus material

Three levels of class diagrams Conceptual view Boxes are concepts, associations are associations :-) Concepts may or may not correspond to classes Specification view Boxes are interfaces Associations imply responsibilities Implementation view Boxes are classes Associations imply navigability Following Fowler, UML Distilled

Behavioral Things state message object Alice:Employee asynch message

Components and Nodes component node

System Packaging Component Diagrams Deployment Modules and Packaging of software Deployment Physical Layout Hardware