Introduction to the Unified Modeling Language “The act of drawing a diagram does not constitute analysis or design. … Still, having a well-defined and expressive notation is important to the process of software development.” – Grady Booch ©SoftMoore ConsultingSlide 1

Why Model? Less expensive to build and modify Can be built more quickly Can be “tested” before building Promotes better communication among developers and with customers Allows visualization of proposed solutions and alternatives ©SoftMoore ConsultingSlide 2 “All models are wrong. Some models are useful.” – George Box

The Unified Modeling Language The UML is a language for –specifying –constructing –visualizing –documenting the artifacts of a software-intensive system. ©SoftMoore ConsultingSlide 3

UML Origins The UML Represents an evolution and unification of OOAD methods Integrates many of the best features from earlier methods, including –Booch method (Grady Booch) –Object Modeling Technique (Rumbaugh et al.) –Object-Oriented Software Engineering (Jacobson et al.) ©SoftMoore ConsultingSlide 4

The Three Amigos ©SoftMoore ConsultingSlide 5 Grady Booch Ivar Jacobson James Rumbaugh

Model Elements Class A description of a set of objects that share the same attributes, operations, relationships, and semantics. Active Class A class whose objects own a process or thread and can initiate control activity. (concurrent behavior) Interface A collection of operations that specify a service of a class or component. ©SoftMoore ConsultingSlide 6

Model Elements (continued) Use Case A description of a set of sequences of actions, including variants, that a system performs that yields an observable result of value to a particular actor. Collaboration A society of roles and other elements that work together to provide some cooperative behavior. Component A modular part of the system design that hides its implementation behind a set of external interfaces. Components with same interfaces can be substituted. ©SoftMoore ConsultingSlide 7

Model Elements (continued) Package A general purpose mechanism for organizing model elements into groups. Node A physical element that exists at run time and represents a computational resource, generally having at least some memory and often processing capability. State A situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event. ©SoftMoore ConsultingSlide 8

Model Elements (continued) Message A specification of a communication between objects that conveys information with the expectation that activity will ensue. Artifact A physical part of a system at the level of the implementation platform. Note A graphic symbol for rendering constraints or comments attached to an element or a collection of elements. ©SoftMoore ConsultingSlide 9 message «artifact»

Relationships Dependency A semantic relationship between two elements in which a change to one element (the independent element) may affect the semantics of the other element (the dependent element). Association A static, structural relationship between classifiers (classes, interfaces, components, etc.) ©SoftMoore ConsultingSlide 10

Relationships (continued) Generalization A specialization/generalization relationship, in which objects of the specialized element (the subclass or child) are substitutable for objects of the generalize element (the superclass or parent). Realization A semantic relationship between classifiers in which one classifier (e.g., an interface) specifies a contract that another classifier (e.g., a class or component) guarantees to carry out. ©SoftMoore ConsultingSlide 11

Diagrams (bold = most used in this course) Class Diagram (classes, interfaces, relationships) Object Diagram (objects, relationships) Use Case Diagram (actors, use cases, relationships) Interaction Diagram (objects, relationships, messages) –Sequence Diagram –Communication Diagram Statechart Diagram (states, transitions, events) Activity Diagram (activities, flow of control) Component Diagram (components and relationships) Deployment Diagram (nodes and connections) ©SoftMoore ConsultingSlide 12

Example: Class Diagram ©SoftMoore ConsultingSlide 13 Subject attach(Observer) detach(Observer) notify() ConcreteSubject subjectState getState() Observer update() ConcreteObserver observerState update() for each i in observers i.update() * observers

Example: Sequence Diagram ©SoftMoore ConsultingSlide 14 : Passenger : Call Button: Scheduler r : Request : Lamp push() turnOn() «create» schedule(r) : Elevator service(r)

Example: Statechart Diagram ©SoftMoore ConsultingSlide 15 OffOn CoastingCruising on button off button brake set speed resume coast button depressed coast button released brake

Notes A note is a graphical symbol for rendering comments attached to an element or a collection of elements. A note is rendered as a rectangle with a “dog-eared” corner, together with a textual and/or graphical comment. Use notes to specify things like requirements, observations, reviews, and explanations. ©SoftMoore ConsultingSlide 16 See for an explanation of this pattern.

Attaching Notes to Modeling Elements A note may be used to comment the diagram as a whole, or it may be attached to one or more modeling elements using undirected dependencies. ©SoftMoore ConsultingSlide 17 «requirement» must be stable «utility» Collections EMPTY_SET EMPTY_LIST min() max() sort()...