ISM 6124 – Advanced Information Systems Analysis and Design Abstracted From: Object Modeling with OMG UML Tutorial Series Introduction to UML ISM 6124 – Advanced Information Systems Analysis and Design Fall Semester 2001 © 1999-2000 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, Hewlett-Packard, InLine Software, IntelliCorp, Kabira Technologies, Klasse Objecten, ObjectTime Ltd., Rational Software, Unisys

Tutorial Goals What you will learn: What you will not learn: what the UML is and what is it not UML’s basic constructs, rules and diagram techniques how the UML can model large, complex systems how the UML can specify systems in an implementation-independent manner What you will not learn: Object Modeling 101 object methods or processes Metamodeling 101

Why do we model? Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem solutions Decrease development costs Manage the risk of mistakes

Quick Tour The UML is a graphical language for specifying visualizing constructing documenting the artifacts of software systems Added to the list of OMG adopted technologies in November 1997 as UML 1.1 Most recent minor revision is UML 1.3, adopted in November 1999

UML Goals Define an easy-to-learn but semantically rich visual modeling language Unify the Booch, OMT, and Objectory modeling languages Include ideas from other modeling languages Incorporate industry best practices Address contemporary software development issues scale, distribution, concurrency, executability, etc. Provide flexibility for applying different processes Enable model interchange and define repository interfaces

OMG UML Evolution

OMG UML Contributors Aonix Colorado State University Computer Associates Concept Five Data Access EDS Enea Data Hewlett-Packard IBM I-Logix InLine Software Intellicorp Kabira Technologies Klasse Objecten Lockheed Martin Microsoft ObjecTime Oracle Ptech OAO Technology Solutions Rational Software Reich SAP Softeam Sterling Software Sun Taskon Telelogic Unisys …

OMG UML 1.3 Specification UML Summary UML Semantics UML Notation Guide UML Standard Profiles Software Development Processes Business Modeling UML CORBAfacility Interface Definition UML XML Metadata Interchange DTD Object Constraint Language

Tutorial Focus: the Language language = syntax + semantics syntax = rules by which language elements (e.g., words) are assembled into expressions (e.g., phrases, clauses) semantics = rules by which syntactic expressions are assigned meanings UML Notation Guide – defines UML’s graphic syntax UML Semantics – defines UML’s semantics

Building Blocks The basic building blocks of UML are: model elements (classes, interfaces, components, use cases, etc.) relationships (associations, generalization, dependencies, etc.) diagrams (class diagrams, use case diagrams, interaction diagrams, etc.) Simple building blocks are used to create large, complex structures cf. elements, bonds and molecules in chemistry cf. components, connectors and circuit boards in hardware

Well-Formedness Rules Well-formed: indicates that a model or model fragment adheres to all semantic and syntactic rules that apply to it. UML specifies rules for: naming scoping visibility integrity execution (limited) However, during iterative, incremental development it is expected that models will be incomplete and inconsistent.

What is structural modeling? Structural model: a view of an system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations.

Structural Modeling: Core Elements

Structural Modeling: Core Elements (cont’d) ¹ An extension mechanism useful for specifying structural elements.

Structural Modeling: Core Relationships

Structural Modeling: Core Relationships (cont’d)

Structural Diagram Tour Show the static structure of the model the entities that exist (e.g., classes, interfaces, components, nodes) internal structure relationship to other entities Do not show temporal information Kinds static structural diagrams class diagram object diagram implementation diagrams component diagram deployment diagram

Static Structural Diagrams Shows a graph of classifier elements connected by static relationships. kinds class diagram: classifier view object diagram: instance view

Classes Fig. 3-17, UML Notation Guide

Classes: method body Fig. 3-21, UML Notation Guide

Associations Fig. 3-31, UML Notation Guide

Composition Fig. 3-36, UML Notation Guide

Generalization Fig. 3-39, UML Notation Guide

Constraints and Comments Fig. 3-15, UML Notation Guide

Implementation Diagrams Show aspects of model implementation, including source code structure and run-time implementation structure Kinds component diagram deployment diagram

Component Diagram Shows the organizations and dependencies among software components Components include source code components binary code components executable components

Components Fig. 3-84, UML Notation Guide

Component Diagram Fig. 3-81, UML Notation Guide

Deployment Diagram Shows the configuration of run-time processing elements and the software components, processes and objects that live on them Deployment diagrams may be used to show which components may run on which nodes

Deployment Diagram Fig. 3-82, UML Notation Guide

When to model structure Adopt an opportunistic top-down+bottom-up approach to modeling structure Specify the top-level structure using “architecturally significant” classifiers and model management constructs (packages, models, subsystems; see Tutorial 3) Specify lower-level structure as you discover detail re classifiers and relationships If you understand your domain well you can frequently start with structural modeling; otherwise If you start with use case modeling (as with a use-case driven method) make sure that your structural model is consistent with your use cases If you start with role modeling (as with a collaboration-driven method) make sure that your structural model is consistent with your collaborations

Structural Modeling Tips Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain. Focus on using basic constructs well; add advanced constructs and/or notation only as required. Defer implementation concerns until late in the modeling process. Structural diagrams should emphasize a particular aspect of the structural model contain classifiers at the same level of abstraction Large numbers of classifiers should be organized into packages

What is use case modeling? 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’).

Use Case Modeling: Core Elements

Use Case Modeling: Core Relationships <<extend>>

Use Case Modeling: Core Relationships (cont’d) <<include>>

Use Case Diagram Fig. 3-44, UML Notation Guide

Use Case Relationships Fig. 3-45, UML Notation Guide

Use Case Description: Change Flight Actors: traveler, client account db, airline reservation system Preconditions: Traveler has logged on to the system and selected ‘change flight itinerary’ option Basic course System retrieves traveler’s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then … System displays transaction summary. Alternative courses If no flights are available then …

When to model use cases Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven method start with use cases and derive your structural and behavioral models from it. If you are not using a use-case driven method make sure that your use cases are consistent with your structural and behavioral models.

Use Case Modeling Tips Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams (see Lecture 2) Factor out common usages that are required by multiple use cases If the usage is required use <<include>> If the base use case is complete and the usage may be optional, consider use <<extend>> A use case diagram should contain only use cases at the same level of abstraction include only actors who are required Large numbers of use cases should be organized into packages (see Lecture 3)

Ideas to Take Away UML is effective for modeling large, complex software systems It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects It can specify systems in an implementation-independent manner 10-20% of the constructs are used 80-90% of the time Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior Use case modeling specifies the functional requirements of system in an object-oriented manner

Behavioral Modeling Part 1: Interactions and Collaborations Part 2: Statecharts Part 3: Activity Diagrams

What are interactions? Interaction: a collection of communications between instances, including all ways to affect instances, like operation invocation, as well as creation and destruction of instances The communications are partially ordered (in time)

Interactions: Core Elements Construct Description Syntax Instance (object, data value, component instance etc.) An entity with a unique identity and to which a set of operations can be applied (signals be sent) and which has a state that stores the effects of the operations (the signals). name attr values Action A specification of an executable statement. A few different kinds of actions are predefined, e.g. CreateAction, CallAction, DestroyAction, and UninterpretedAction. textual

Interaction: Core Elements (cont’d) Construct Description Syntax Stimulus A communication between two instances. Operation A declaration of a service that can be requested from an instance to effect behavior. textual Signal A specification of an asynchronous stimulus communicated between instances. «Signal» Name parameters

Interaction: Core Relationships Construct Description Syntax Link A connection between instances. Attribute Link A named slot in an instance, which holds the value of an attribute. textual

Example: Instance triangle : Polygon triangle : Polygon triangle underlined name triangle : Polygon triangle center : Point = (2,2) vertices : Point* = ((0,0), (4, 0), (2,4)) borderColor : Color = black fillColor : Color = white attribute links : Polygon

Example: Instances and Links : Family husband wife Joe : Person Jill : Person

Operation and Method Triangle foreach v in vertices do v.x := v.x + dist.x; v.y := v.y + dist.y + move (in dist : Point) + scale (in factor : Real) foreach v in vertices do v.x := factor * v.x; v.y := factor * v.y

Interaction Diagram Tour Show interactions between instances in the model graph of instances (possibly including links) and stimuli existing instances creation and deletion of instances Kinds sequence diagram (temporal focus) collaboration diagram (structural focus)

Sequence Diagram object symbol lifeline stimulus activation delete name : Class other object symbol lifeline stimulus name (…) activation : Class create new (…) delete return

Different Kinds of Arrows Procedure call or other kind of nested flow of control Flat flow of control Explicit asynchronous flow of control Return

Example: Different Arrows teller : Order : Article Nested Flow getValue price getName caller exchange callee Flat Flow lift receiver dial tone dial digit ringing tone ringing signal appl err handl alarm Asynchronous Flow unknown

Collaboration Diagram object symbol link symbol standard stereotype : Controller : Window wire :Wire {new} : Line left : Bead right : Bead redisplay () stimulus 1: displayPositions (window) wire «local» line contents {new} window «self» window «parameter» standard constraint 1.1.3.1 add (self) 1.1 *[i := 1..n]: drawSegment (i) 1.1.2: create (r0, r1) 1.1.3: display (window) 1.1.1a: r0 := position () 1.1.1b: r1 := position ()

When to Model Interactions To specify how the instances are to interact with each other. To identify the interfaces of the classifiers. To distribute the requirements.

Interaction Modeling Tips Set the context for the interaction. Include only those features of the instances that are relevant. Express the flow from left to right and from top to bottom. Put active instances to the left/top and passive ones to the right/bottom. Use sequence diagrams to show the explicit ordering between the stimuli when modeling real-time Use collaboration diagrams when structure is important to concentrate on the effects on the instances

Wrap Up: Interactions & Collaborations Instances, Links and Stimuli are used for expressing the dynamics in a model. Collaboration is a tool for identification of classifiers specification of the usage of instances expressing a mapping between different levels of abstraction Different kinds of diagrams focus on time or on structure

State Machine (Automaton) Diagram Graphical rendering of automata behavior Lamp On off on off Lamp Off

Outputs and Actions As the automaton changes state it can generate outputs: on off Lamp On Lamp Off on/print(”on”) Mealy automaton on off Lamp On print(”on”) Lamp Off Moore automaton

Extended State Machines off on Lamp On Lamp Off on/ctr := ctr + 1 Addition of variables (“extended state”) ctr : Integer

A Bit of Theory An extended (Mealy) state machine is defined by: a set of input signals (input alphabet) a set of output signals (output alphabet) a set of states a set of transitions triggering signal action a set of extended state variables an initial state designation a set of final states (if terminating automaton)

Basic UML Statechart Diagram “top” state State Initial pseudostate top Trigger Ready Transition stop /ctr := 0 Done Final state Action stop

What Kind of Behavior? In general, state machines are suitable for describing event-driven, discrete behavior inappropriate for modeling continuous behavior time threshold

Event-Driven Behavior Event = a type of observable occurrence interactions: synchronous object operation invocation (call event) asynchronous signal reception (signal event) occurrence of time instants (time event) interval expiry calendar/clock time change in value of some entity (change event) Event Instance = an instance of an event (type) occurs at a particular time instant and has no duration

Wrap Up: Statecharts UML uses an object-oriented variant of Harel’s statecharts adjusted to software modeling needs Used to model event-driven (reactive) behavior well-suited to the server model inherent in the object paradigm Primary use for modeling the behavior of active event-driven objects systems modeled as networks of collaborating state machines run-to-completion paradigm significantly simplifies concurrency management

Wrap Up: Statecharts (cont’d) Includes a number of sophisticated features that realize common state-machine usage patterns: entry/exit actions state activities dynamic and static conditional branching Also, provides hierarchical modeling for dealing with very complex systems hierarchical states hierarchical transitions orthogonality

Activity Diagram Applications Intended for applications that need control flow or object/data flow models … ... rather than event-driven models like state machines. For example: business process modeling and workflow. The difference in the three models is how step in a process is initiated, especially with respect to how the step gets its inputs.

Control Flow Each step is taken when the previous one finishes … …regardless of whether inputs are available, accurate, or complete (“pull”). Emphasis is on order in which steps are taken. Weather Info Start Decision is taken with whatever information you have at the time. Does not wait for complete input or even any input to be provided. Analyze Weather Info Not UML Notation! Chart Course Cancel Trip

Object/Data Flow Each step is taken when all the required input objects/data are available … … and only when all the inputs are available (“push”). Emphasis is on objects flowing between steps. Design Product Acquire Capital Procure Materials Build Subassembly 1 Build Subassembly 2 Final Assembly Not UML Notation

Action (State) Action An action is used for anything that does not directly start another activity graph, like invoking an operation on an object, or running a user-specified action. However, an action can invoke an operation that has another activity graph as a method (possible polymorphism).

Subactivity (State) Subactivity A subactivity (state) starts another activity graph without using an operation. Used for functional decomposition, non-polymorphic applications, like many workflow systems. The invoked activity graph can be used by many subactivity states.

Example POEmployee.sortMail Deliver Mail Deliver Mail POEmployee Check Out Truck Put Mail In Boxes Deliver Mail No standard notation yet for the name of an action, to indicate what kind of object and operation are being invoked. No standard notation for connecting an action state to the object it invokes an operation on. Likewise for the decomposition of a subactivity state into another state machine. The action state is polymorphic, the subactivity state is not.

Object Flow (State) Class [State] A special sort of step (state) that represents the availability of a particular kind of object, perhaps in a particular state. No action or subactivity is invoked and control passes immediately to the next step (state). Places constraints on input and output parameters of steps before and after it.

Object Flow (State) Order [Taken] Take Order Fill Order Take Order must have an output parameter giving an order, or one of its subtypes. Fill Order must have an input parameter taking an order, or one of its supertypes. Dashed lines used with object flow have the same semantics as any other state transition. More about semantics of dashed line in pitfalls section. A step parameter refers to the parameters of the operations invoked by action states. Take Order and Fill Order can be subactivity states, whereupon the parameters are in the first/last action state in the subactivity graph, recursively.

Coordinating Steps Inherited from state machines Initial state Final state Fork and join

Coordinating Steps Decision point and merge ( ) are inherited from state machines. For modeling conventional flow chart decisions. Calculate Cost Charge Account Get Authorization [cost < $50] [cost >= $50] Use merge instead of dummy state before join.

Convenience Features Partitions are a grouping mechanism. Swimlanes are the notation for partitions. They do not provide domain-specific semantics. Register Bug Evaluate Impact Fix Revise Plan Release Test [ priority = 1] Management Support Engineering

Case Study Communications of the ACM Kobryn, “UML 2001” Adapted from partition Submission Team Task Force Revision Task Force Issue RFP Evaluate initial submissions Submit specification draft Collaborate with competitive submitters Develop technology action state RFP [issued] [optional] control flow Finalize Specification [initial proposal] input value Begin object flow initial state join of control conditional fork fork of control [final Case Study Communications of the ACM Kobryn, “UML 2001” Adapted from October 1999

Case Study Communications of the ACM Kobryn, “UML 2001” Adapted from Evaluate initial submissions Evaluate final Vote to recommend Enhance specification Implement Revise Finalize Specification [final proposal] [adopted] Recommend revision [revised] [NO] [YES] [else] [Enhanced] decision final state guard Collaborate with competitive submitters Case Study Communications of the ACM Kobryn, “UML 2001” Adapted from October 1999

When to Use Activity Diagrams Use activity diagrams when the behavior you are modeling ... does not depend much on external events. mostly has steps that run to completion, rather than being interrupted by events. requires object/data flow between steps. is being constructed at a stage when you are more concerned with which activities happen, rather than which objects are responsible for them (except partitions possibly).

Activity Diagram Modeling Tips Control flow and object flow are not separate. Both are modeled with state transitions. Dashed object flow lines are also control flow. You can mix state machine and control/object flow constructs on the same diagram (though you probably do not want to).

Wrap Up: Activity Diagrams Use Activity Diagrams for applications that are primarily control and data-driven, like business modeling … … rather than event-driven applications like embedded systems. Activity diagrams are a kind of state machine until UML 2.0 … … so control and object/data flow do not have separate semantics. UML 1.3 has new features for business modeling that increase power and convenience. Check it out and give feedback!