UML Unified Modeling Language UML Wolfgang Pelz 2000

UML Unified Modeling Language UML © Wolfgang Pelz 2000 -04 1

Chapter One Introduction UML © Wolfgang Pelz 2000 -04 2

District Module Order Initiated Application Server Semi-Auto Fill Order Requested Central-Office Module Order Approved Database Server Delivery Status Sign-Shop Module Order Filled Figure 4 Data Flow of Sign Orders UML © Wolfgang Pelz 2000 -04 3

Engineering and Blueprints • standard notation • communication tool UML © Wolfgang Pelz 2000 -04 4

History • • • CASE Tools: Automation of Software Development People-to-People-to-Computer Rational Software (An IBM Company) Rational Rose / MS Visio: Converting UML-Diagrams-to-Programs • OMG: Object Management Group UML © Wolfgang Pelz 2000 -04 5

History • • UML Booch: Booch Method Rumbaugh: OMT (object modeling tech. ) Jacobson: OOSE (OO software engrg. ) Three amigos: UML © Wolfgang Pelz 2000 -04 6

History • UML: an open standard controlled by OMG • UML 1. 0 (1997) • UML 2. 0 (2004) UML © Wolfgang Pelz 2000 -04 7

Meta-Model • a diagram that defines the notation to be used in the modeling language UML © Wolfgang Pelz 2000 -04 8

UML supported diagrams • class • object • use case • interaction » component • package • deployment – – communication sequence collaboration timing • activity • state/statechart UML © Wolfgang Pelz 2000 -04 9

Brief Overview • class - set of classes, interfaces, collaboration, relationships • object - set of objects and their relationships • use case - description of functionality provided by system along with actors and their connection to the use case UML © Wolfgang Pelz 2000 -04 10

Overview (cont. ) • interaction - set of objects and their relationships including messages • state/statechart - a state machine showing states, transitions, events, and activities • activity - statechart sequential flow of activities • component - physical structure of code in terms of code components UML © Wolfgang Pelz 2000 -04 11

Overview (cont. ) • deployment - physical architecture of hardware and software in the system • package - shows packages of classes and dependencies among them – grouping mechanism – form of class diagram – also called subsystem UML © Wolfgang Pelz 2000 -04 12

Organization of Diagrams domain expert • use case • activity • interaction UML system designer • class • component • deployment • state • package © Wolfgang Pelz 2000 -04 13

Another Organization static • class • component • package • deployment UML dynamic • use case • interaction • state • activity © Wolfgang Pelz 2000 -04 14

Another Organization UML © Wolfgang Pelz 2000 -04 15

Model Terminology • user model view - problem and solution from the perspective of the users • structural model view - static or structural aspects of a problem and solution • behavioral model view - dynamic or behavioral aspects; interactions or collaborations among problem and solution elements UML © Wolfgang Pelz 2000 -04 16

Model Terminology • implementation model view - structural and behavioral aspects of the solution’s realization • environment model view - structural and behavioral aspects of the domain in which a solution must be realized UML © Wolfgang Pelz 2000 -04 17

Language versus Method • A (software engineering) method is composed of a language and a process. • UML is a language, not a method, since it has no notion of process • process can be: UML © Wolfgang Pelz 2000 -04 18

UML © Wolfgang Pelz 2000 -04 19

Terminology • inception - a few days’ work to decide if a few months of elaboration is worth it • elaboration - risk assessment, about 1/5 of project time; includes planning based on use cases; generates a commitment schedule • construction - composed of iterations that include refactoring, frameworks & patterns • transition - beta testing, optimizing, training UML © Wolfgang Pelz 2000 -04 20

Refactoring the process of changing the internal structure of a program or system to make it easier to understand or change while maintaining its functionality UML © Wolfgang Pelz 2000 -04 21

Frameworks & Patterns • frameworks are reusable designs of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate • patterns are common designs that have repeating themes UML © Wolfgang Pelz 2000 -04 22

Chapter Three Class Diagram UML © Wolfgang Pelz 2000 -04 23

Class Diagram • static view of a system in terms of classes and relationships among the classes – associations – subtypes • typically done in parallel with interaction diagrams • a more graphical alternative to CRC cards UML © Wolfgang Pelz 2000 -04 24

Important Questions (Finding classes) • Is there information to be stored/analyzed? • Do external systems exist? • Are there patterns, class libraries, components, etc? • Must the system handle devices? • Are there organizational parts (business model)? • Do actors have roles to play in the system? UML © Wolfgang Pelz 2000 -04 25

Common Uses • Objective: provide a view of services the system should provide to its end user • model the vocabulary of a system • model simple collaborations • model a logical database schema UML © Wolfgang Pelz 2000 -04 26

Terminology • association: a description of a related set of links between objects of two classes • subtype: “is a” or “is a kind of” • generalization: relationship between a more general and a more specific element - see subtype UML © Wolfgang Pelz 2000 -04 27

Terminology (cont. ) • dependency: relationship where a change in the independent element affects the dependent element • refinement: relationship between two descriptions of the same thing, but at different levels of abstraction UML © Wolfgang Pelz 2000 -04 28

Terminology (cont. ) • Aggregation: association specifying a whole-part relationship between the aggregate (whole) and a component (part). An aggregation may not have any components and a component may not belong to any aggregation. • composition: special form of aggregation (a component must belong to a composition and only to one composition) – strong ownership – coincident lifetime of parts and whole UML © Wolfgang Pelz 2000 -04 29

Notation UML © Wolfgang Pelz 2000 -04 30

More Notation UML © Wolfgang Pelz 2000 -04 31

Aggregation/Composition UML © Wolfgang Pelz 2000 -04 32

Example UML © Wolfgang Pelz 2000 -04 33

Levels of Abstraction • conceptual model: class name – associations are conceptual relationships • specification model: above + behavior – associations and responsibilities • implementation model: above + state – probably too low-level for design stage UML © Wolfgang Pelz 2000 -04 34

Another Example UML © Wolfgang Pelz 2000 -04 35

Associations • Describe relations between classes • associations have roles (given at the end of the association) which have multiplicities • associations have navigability – A sends a message to B – A creates an instance of B – A needs to maintain a connection with B • navigability is identified from collaboration diagrams UML © Wolfgang Pelz 2000 -04 36

Associations (cont. ) • navigability in one direction is termed unidirectional association and has an arrow • two-way navigability is bi-directional association and has no arrow • an association with no arrow could also mean that the direction is unknown • bidirectional requires inverse relationship f ( f -1(y)) = y UML f -1( f (x)) = x © Wolfgang Pelz 2000 -04 37

Operation Signatures visibility name (parameters) : return type optional + public # protected - private • Example: + get. Data (pos : Position) : Data UML © Wolfgang Pelz 2000 -04 38

Operations & Methods • Operation – something invoked on an object which in turn is implemented by a method • Method (in coding not design method) – body of the procedure • polymorphism forces a distinction between the two (all siblings have the same operation but different methods) UML © Wolfgang Pelz 2000 -04 39

Steps to create a Class Diagram • Identify classes using the interaction diagram and place them in the class diagram • get attributes from the conceptual model and the method names from the interaction diagram • add type information and associations based on attribute visibility • add navigability arrows and dependencies UML © Wolfgang Pelz 2000 -04 40

Another Example UML © Wolfgang Pelz 2000 -04 41

Cautions • start small • perspective should match activity – analysis: conceptual model – software: specification model • don’t go to details too early UML © Wolfgang Pelz 2000 -04 42

Dependency Relationship • One element (of any kind, including classes, use cases, etc. ) has knowledge of another element • if one element changes, the other might have to change as well • differs from plain attribute visibility which uses regular association line and a navigability arrow UML © Wolfgang Pelz 2000 -04 43

Example revisited UML © Wolfgang Pelz 2000 -04 44

Example with Dependency UML © Wolfgang Pelz 2000 -04 45

Interface • Interface is a class of abstract/pure virtual functions. • All functions in the interface are public. • Interface cannot be used to instantiate objects. • There is no data members in an interface class. • UML: use <<interface>> to prefix the class name. UML © Wolfgang Pelz 2000 -04 46

Abstract Class • An abstract class has one or more abstract/pure virtual functions. • An abstract class cannot be used to instantiate objects. • An abstract class can contain data members. • UML: use Abstract to prefix the class name. UML © Wolfgang Pelz 2000 -04 47

Examples Figures in UML Distilled. UML © Wolfgang Pelz 2000 -04 48

Chapter 6 Object Diagrams UML © Wolfgang Pelz 2000 -04 49

Object Diagrams • • A snapshot of the objects in a system at a point in time. Also called instance diagrams. Useful of showing object connections (not interactions) Can be thought of as collaboration/communication diagram without messages. • Naming convention (did not change as sequence diagram did): UML © Wolfgang Pelz 2000 -04 50

UML © Wolfgang Pelz 2000 -04 51

Object Diagrams (try this example) class Pet { // define a class protected: string name; // protected members can be accessed by child classes public: Pet() {name = ""; } // default constructor Pet(string nm){name = nm; } // constructor string get. Name() {return name; } // to be inherited by child classes //virtual method, to be overridden virtual string speak() const { return “’I can't speak. ’”; } }; . . . int main() { vector<Pet *> pets; pets. push_back(new Dog("Midnight")); pets. push_back(new Cat("Ginger")); pets. push_back(new Pet("Dummy")); } UML © Wolfgang Pelz 2000 -04 52

Chapter 9 Use Case Diagram UML © Wolfgang Pelz 2000 -04 53

Use Case Diagram • For capturing the functional requirements of a system. • Typical interaction between user and system – captures some user-visible function – achieves a discrete goal for the user note the distinction between the user goal and system interaction in which system interaction is the low-level work that ultimately achieves the user goal UML © Wolfgang Pelz 2000 -04 54

Notation UML © Wolfgang Pelz 2000 -04 55

An Example (UML 1. 3) UML © Wolfgang Pelz 2000 -04 56

Another Example (UML 1. 1) UML © Wolfgang Pelz 2000 -04 57

Common Uses • to model the context of a system – system, actors, and their interactions with it • to model the requirements of a system – what system should do – independent of how it is done – point of view outside of system UML © Wolfgang Pelz 2000 -04 58

Caution • it is easy to get too low-level A use case is a relatively large end-to-end process description that typically includes many steps or transactions; it is not normally an individual step or activity in a process. – Larman [1998] Applying UML and Patterns UML © Wolfgang Pelz 2000 -04 59

Steps • capture normal case first • for every step, ask: “What can go wrong” “How might this work differently” • each variation is plotted as an extension • common behavior can be encapsulated in another use case to be used by other cases UML © Wolfgang Pelz 2000 -04 60

Steps (cont. ) • after creating the diagram, write a generic scenario (called a use case description) which is a series of sentences describing each step in the interaction • Each step in a use case is an element of the interaction between an actor and the system. • use case description can be used to generate specific scenarios and interaction diagrams UML © Wolfgang Pelz 2000 -04 61

Scenario • a thread through a use case • a sequence of steps describing an interaction between a user and a system. • A use case is a set of scenarios tied together by a common user goal. UML © Wolfgang Pelz 2000 -04 62

Exercise • Produce a use case diagram for an ATM UML © Wolfgang Pelz 2000 -04 63