1 © Wolfgang Pelz UML UML Unified Modeling Language
2 © Wolfgang Pelz UML Chapter One Introduction
3 © Wolfgang Pelz UML Figure 4 Data Flow of Sign Orders Central-Office Module Application Server Order Requested Semi-Auto Fill District Module Order Initiated Order Approved Database Server Sign-Shop Module Order Filled Delivery Status
4 © Wolfgang Pelz UML Engineering and Blueprints standard notation communication tool
5 © Wolfgang Pelz UML History CASE Tools: Automation of Software Development People-to-People People-to-Computer Rational Software (An IBM Company) Rational Rose / MS Visio: Converting UML-Diagrams-to-Programs OMG: Object Management Group
6 © Wolfgang Pelz UML History Booch: Booch Method Rumbaugh: OMT (object modeling tech.) Jacobson: OOSE (OO software engrg.) Three amigos: UML
7 © Wolfgang Pelz UML History UML: an open standard controlled by OMG UML 1.0 (1997) UML 2.0 (2004)
8 © Wolfgang Pelz UML Meta-Model a diagram that defines the notation to be used in the modeling language
9 © Wolfgang Pelz UML UML supported diagrams class object »component package deployment use case interaction –communication –sequence –collaboration –timing activity state/statechart
10 © Wolfgang Pelz UML 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
11 © Wolfgang Pelz UML 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
12 © Wolfgang Pelz UML 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
13 © Wolfgang Pelz UML Organization of Diagrams domain expert use case activity interaction system designer class component deployment state package
14 © Wolfgang Pelz UML Another Organization static class component package deployment dynamic use case interaction state activity
15 © Wolfgang Pelz UML Another Organization
16 © Wolfgang Pelz UML 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
17 © Wolfgang Pelz UML 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
18 © Wolfgang Pelz UML 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:
19 © Wolfgang Pelz UML
20 © Wolfgang Pelz UML 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
21 © Wolfgang Pelz UML 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
22 © Wolfgang Pelz UML 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
23 © Wolfgang Pelz UML Chapter Three Class Diagram
24 © Wolfgang Pelz UML 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
25 © Wolfgang Pelz UML 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?
26 © Wolfgang Pelz UML 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
27 © Wolfgang Pelz UML 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
28 © Wolfgang Pelz UML 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
29 © Wolfgang Pelz UML 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
30 © Wolfgang Pelz UML Notation
31 © Wolfgang Pelz UML More Notation
32 © Wolfgang Pelz UML Aggregation/Composition
33 © Wolfgang Pelz UML Example
34 © Wolfgang Pelz UML 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
35 © Wolfgang Pelz UML Another Example
36 © Wolfgang Pelz UML 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
37 © Wolfgang Pelz UML Associations (cont.) navigability in one direction is termed uni- directional 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 f -1 ( f (x)) = x
38 © Wolfgang Pelz UML Operation Signatures visibility name (parameters) : return type optional + public # protected - private Example: + getData (pos : Position) : Data
39 © Wolfgang Pelz UML 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)
40 © Wolfgang Pelz UML 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
41 © Wolfgang Pelz UML Another Example
42 © Wolfgang Pelz UML Cautions start small perspective should match activity –analysis: conceptual model –software: specification model don’t go to details too early
43 © Wolfgang Pelz UML 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
44 © Wolfgang Pelz UML Example revisited
45 © Wolfgang Pelz UML Example with Dependency
46 © Wolfgang Pelz UML 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 > to prefix the class name.
47 © Wolfgang Pelz UML 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.
48 © Wolfgang Pelz UML Examples Figures in UML Distilled.
49 © Wolfgang Pelz UML Chapter 6 Object Diagrams
50 © Wolfgang Pelz UML 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):
51 © Wolfgang Pelz UML
52 © Wolfgang Pelz UML 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 getName() {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 pets; pets.push_back(new Dog("Midnight")); pets.push_back(new Cat("Ginger")); pets.push_back(new Pet("Dummy")); }
53 © Wolfgang Pelz UML Chapter 9 Use Case Diagram
54 © Wolfgang Pelz UML 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
55 © Wolfgang Pelz UML Notation
56 © Wolfgang Pelz UML An Example (UML 1.3)
57 © Wolfgang Pelz UML Another Example (UML 1.1)
58 © Wolfgang Pelz UML 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
59 © Wolfgang Pelz UML 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
60 © Wolfgang Pelz UML 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
61 © Wolfgang Pelz UML 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
62 © Wolfgang Pelz UML 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.
63 © Wolfgang Pelz UML Exercise Produce a use case diagram for an ATM