UML Analysis and Design

Table of contents⌘

Requirements Management	3
Unified Modeling Language	9
MDA	20
Activity Diagram	24
Component Diagram	40
Deployment Diagram	46
Use Case Basics	53
Communication Diagram	68
Class Diagram	72
Composite Structure Diagram	103
Interaction	107
Sequence Diagram	108
Interaction Overview Diagram	116
Timing Diagram	118
State Machine Diagram	121
Introduction to Design Patterns	146

Requirements Management⌘

Requirement⌘

• A requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.
• A Requirements specification is the direct result of a requirements analysis.
• A Software requirements specification (SRS) is a complete description of the behavior of a system to be developed and may include a set of use cases and non-functional requirements.

Recommended Practice⌘

IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998)

Characteristics of a good SRS⌘

1. Correct - every requirement is one that the software shall meet;
2. Unambiguous - every requirement has only one interpretation;
3. Complete:
   • contains all significant requirements, specifies all responses to valid and invalid input values
   • includes references to all figures, tables, and diagrams in the SRS and definition of all terms;
4. Consistent - internal consistency, if an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct
5. Ranked for importance and/or stability - each requirement in it has an identifier to indicate either the importance or stability of that particular requirement;
6. Verifiable - every requirement is verifiable;
7. Modifiable - its structure and style are such that any changes to the requirements can be made easily, completely, and consistently;
8. Traceable - the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation.

FURPS⌘

FURPS is an acronym representing a model for classifying requirements.

Usability - UX, Human Factors, Aesthetics, Consistency, Documentation

Reliability - Availability, Robustness/Durability, Recoverability, Stability, Accuracy

Performance - Speed, Efficiency, Resource Consumption

Requirements Management
with Enterprise Architect⌘

Unified Modeling Language⌘

History of UML ⌘

UML was developed by Grady Booch, Ivar Jacobson and James Rumbaugh (The Three Amigos)

UML versions⌘

• 0.8 Booch & Rumbaugh 1995
• 0.9 The Three Amigos 1996
• 1.1 OMG 1997
• 1.2-1.5 OMG refinements 1998-2003
• 2.0 OMG major review and redesign 2003-2005
• 2.1.1, 2.1.2 OMG 2007
• 2.2 OMG 2009
• 2.3 OMG 2010
• 2.4.1 OMG 2011
• 2.5 OMG 2015 current version

UML specification: http://omg.org/spec/UML/Current

Overview ⌘

• OMG Standard
• The Unified Modeling Language (UML)
• Data modeling, business modeling (work flows), object modeling, and component modeling
• UML aims to be a standard modeling language which can model concurrent and distributed systems
• UML is a de-facto industry standard
• UML models may be automatically transformed to other representations (e.g. Java, PHP)
• UML is extensible, through profiles, stereotypes and tagged values
• A lot of other languages are based on UML (SysML, SoaML)
• Usually default language for a lot of architecture frameworks (MoDAF, DoDAF, NAF)

UML 2.5 Specification⌘

• This specification has been extensively re-written from its previous version to make it easier to read by removing redundancy and increasing clarity.
• The UML Infrastructure no longer forms part of the UML specification.
• Package Merge is not used within the specification.
• The compliance levels L0, L1, L2, and L3 have been eliminated, because they were not found to be useful in practice. A tool either complies with the whole of UML or it does not.

Parts of UML 2.5 Specification⌘

• Abstract Syntax contains one or more diagrams that define that capability in terms of the UML metamodel
• Semantics specifies the semantics (meaning) of all of the concepts.
• Notation specifies the notation corresponding to all of the concepts defined in the sub clause. Only concepts that can appear in diagrams will have a notation specified.

UML Features⌘

• Does not define method (see Unified Process)
• UML defines both:
  • UML model (contains documentation and all relations)
  • UML diagrams (partial graphic representation of a system's model)
• UML can model both views of the system:
  • Static (structural)
  • Dynamic (behavioral)
• Contains 14 different diagrams

UML Diagrams ⌘

Structure diagrams⌘

Structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.

• Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
• Component diagram: describes how a software system is split up into components and shows the dependencies among these components.
• Composite structure diagram: describes the internal structure of a classifier and the collaborations that this structure makes possible.
• Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
• Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.
• Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings.
• Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype.

Behavior diagrams⌘

Behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.

• Activity diagram: describes the business and operational step-by-step workflows of components in a system.
• Use Case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
• State machine diagram: describes the states and state transitions of the system.

Interaction diagrams⌘

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

• Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
• Communication diagram: shows the interactions between objects or parts in terms of sequenced messages.
• Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.
• Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

MDA ⌘

• Model Driven Architecture (MDA) is a software design approach
• specification is expressed as computer model
• created by OMG in 2001
• http://www.omg.org/mda/

MDA Process ⌘

MDA Process ⌘

• Define system functionality using a platform-independent model (PIM)
  • domain-specific language DSL
  • e.g. UML, BPMN, SoaML, etc...
• Translate PIM to one or more executable platform-specific model(s) (PSMs)
  • uses different DSLs (e.g. MVEL)
  • or programming languages (e.g Java, C#, etc...)
• Transformation is done by automated tool

Related Standards ⌘

• The Meta Object Facility (MOF)
  • http://www.omg.org/mof/
• The Unified Modeling Language (UML)
  • http://www.omg.org/spec/UML/Current/
• The Common Warehouse Metamodel (CWM)
  • http://www.omg.org/spec/CWM/

Activity Diagram⌘

• Describes the workflow behavior of a system, focuses on flows.
• A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work.

Activity, Action⌘

Activity

• describes a sequence of actions based on control models and object flow models
• contains edges and activity nodes (e.g. actions)
• represented by a rectangle with rounded corners

Action

• is a fundamental unit of executable functionality contained within an Activity
• represents a single step within an activity

Activity ⌘

Activity contains nodes:

• Action
• Object
• Control Node

and edges:

• Control Flow
• Object Flow

Control Flow⌘

• A control flow is an edge that starts an activity node after the previous one is finished

Object Flow⌘

OR

• An object flow is an activity edge that can have objects or data passing along it

Objects⌘

• Incoming or outgoing objects are parameters
• Placed (as rectangles) on the border

• Or as small rectangle, called a pin (input or output)

Token⌘

• The semantics of an activity is based on a token flow
• Control tokens and object tokens flow between nodes over edges

Activity Example⌘

Initial Node⌘

• It has outgoing edges but no incoming edges
• An activity may have more than one initial node
  • Each generates a concurrent flow
• An initial node can have more than one outgoing edge
  • Semantics: a control token at each outgoing edge
• Activity diagrams do not have to have initial nodes
• Notation: a filled circle

Final Node⌘

• An activity may have more than one activity final node
• The first one reached stops all flows in the activity
  • Regardless of the number of tokens in activity
• At least one incoming edge and no outgoing edges
• If several incoming edges only one must carry a token
• Activity diagrams do not have to have final nodes
• Notation: a filled circle with an outer ring

Decision⌘

• is a control node that chooses between outgoing flows
• One incoming edge and several outgoing edges
• When a token is supplied guards on outgoing edges are evaluated
  • Token goes to first true outgoing
• Notation: a rhombus

Merge⌘

• A merge node is a control node that brings together multiple alternate flows
  • It is not used to synchronize concurrent flows
• Several incoming edges, one outgoing edge
• Nothing calculated, nothing expected
• Notation: an empty rhombus

Fork, Join⌘

• Fork – one incoming edge and multiple outgoing edges
• Join – multiple incoming edges and one outgoing edge

Implicit splitting⌘

Once action A terminates

• a control token is available at both outgoing edges
• actions B and C start concurrently

Implicit synchronization⌘

Action F doesn't start until tokens are available at both incoming edges - actions D and E have to terminate

Implicit split/synchronization - object flow⌘

AND semantics for object flows

• Once action A terminates it provides two object nodes
• Action F doesn't start until object tokens are available at both incoming edges - actions D and E have to terminate

Component Diagram⌘

• Describes how a software system is split up into components and shows the dependencies among these components.

Component⌘

• A Component represents a modular part of a system that encapsulates its contents.
• A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers.
• A Component specifies a formal contract of the services that it provides to its clients and those that it requires from other Components
• A Component is a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality.

Interfaces⌘

Port⌘

• Ports represent interaction points through which an Classifier communicates with its environment.
• A Port may specify the services an Classifier provides (offers) to its environment as well as the services that an Classifier expects (requires) of its environment.

Connector⌘

• Connector specifies a link that enables communication between two (or more) instances.
• Two types of connectors:
  • delegation (connect externally provided interfaces to the parts that realize or require them, represents the forwarding of events)
  • assembly (connector between two or more parts that defines that one part provides the services that other part use)

Manifestation⌘

• An Artifact may embody, or manifest, a number of model elements.
• Manifestation represents implementation of one or more model elements by an artifact.

Deployment Diagram⌘

• Describes the hardware used in system implementations, execution environments and artifacts deployed on the hardware.

Node⌘

• A Node is computational resource upon which Artifacts may be deployed.
• Nodes may have complex internal structure (can only consist of other nodes)
• Two types of nodes:
  • Device (physical machine components) - e.g. application server, client workstation, mobile device
  • Execution Environment (software systems) - e.g. OS, workflow engine, database system, J2EE container

Artifact⌘

• An artifact represents some item of information that is used or produced by a software development process or by operation of a system.
• An artifact represents concrete elements in the physical world.
• Examples of artifacts: model files, source files, scripts, executable files, database tables, word-processing documents, and mail messages.

Communication Path⌘

• A communication path is an association between two nodes, through which they are able to exchange signals and messages.
• It usually represents physical connection between devices or some protocol between execution environments.

Deployment⌘

• A deployment is a dependency relationship which describes allocation (deployment) of an artifact to a deployment target.

Deployment Specification⌘

• A deployment specification specifies a set of properties that determine execution parameters of a component artifact that is deployed on a node.

Connection between Node, Component and Artifact⌘

Use Case Basics⌘

• Use cases are used to model the requirements of a system (what a system is supposed to do)
• The key concepts associated with use cases are actors, use cases, and the subject.

Use Case Diagram⌘

• describes the relationships among a set of use cases and the actors participating in these use cases
• it does NOT describe behavior or flows (WHO and WHAT, not HOW)

Actor⌘

• a role played by an external entity - a user or any other system that interacts with the subject
• may represent roles played by human users, external hardware, or other subjects
• Notation: "stick man" icon (with the name above or below) or rectangle

Relationships Between Actors⌘

• Generalization
• Specialization

UseCase⌘

• the specification of a set of actions performed by a system and produce a result
• a complete set of actions that perform a function for a particular actor
• Notation: an ellipse (with the name inside or below) or rectangle with stereotype

Subject⌘

• a system (subject) is a box containing use cases
• defines boundaries and responsibilities
• actors are always external to a system

Relationships Between Actors and Use Cases⌘

• an association expresses a communication path between the actor and the use case
• directed association from the active to the passive element (who initiated the communication)
• association with multiplicity like 0..*, 2..*, *, etc
  • at the actor end - more than one actor instance is involved in initiating the use case
  • at the use case end - an actor can be involved in multiple use cases of that type

Relationships Between Use Cases⌘

Three types of relationship:

• «include»
• «extend»
• generalization

Include⌘

• defines that a use case contains the behavior defined in another use case
• behavior of the included use case is inserted into the behavior of the including use case
• included use case is not optional, and is always required

Include - common part⌘

• include relationship is intended to be used when there are common parts of the behavior of two or more use cases
• this common part is then extracted to a separate use case, to be included by all the base use cases having this part in common

Include Example⌘

• basic flow of events is incomplete without the inclusion

Extend⌘

• a relationship from an extending use case to an extended use case
• specifies how and when the behavior defined in the extending use case can be inserted into the extended use case
• the extension takes place at extension point
• basic flow of events should still be complete

Extension Point⌘

Generalization⌘

• the specific use case inherits the features of the more general use case

Abstract Use Case⌘

• does not provide a complete declaration and can typically not be instantiated
• is intended to be used by other use cases, e.g., as a target of generalization relationship
• the name of an abstract Use Case is shown in italics

Communication Diagram⌘

• Describes interactions between objects.
• The sequencing of Messages is given through a sequence numbering scheme.
• Communication Diagrams correspond to simple Sequence Diagrams.
• Lifeline represents an individual participant in the interaction.

Message⌘

• A message is shown as a line from the sender to the receiver.
• The send and receive events may both be on the same lifeline.
• The form of the line or arrowhead reflects properties of the message:
  • Synchronous message (send message and suspend execution while waiting for response)
  • Asynchronous message (send message and proceed immediately without waiting)
  • Reply message (reply to synchronous message)

Entity-Control-Boundary Pattern⌘

• Entity: objects representing system data
• Control: objects that manages the flow of interaction of the scenario (the logic of a system)
• Boundary: objects that interface with system actors

Entity-Control-Boundary Links⌘

	Actor	Boundary	Control	Entity
Actor		OK
Boundary	OK		OK
Control		OK	OK	OK
Entity			OK	OK

Class Diagram⌘

Describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.

Classifier⌘

• an abstract base class
• describes a set of instances that have features in common

Feature⌘

• declares a behavioral or structural characteristic of instances of classifiers
• structural feature describes a structure of an instance of a classifier (e.g. property)
• behavioral feature specifies an aspect of the behavior of classifier's instances (e.g. operation)

Property⌘

• Properties are Structural Features that represent:
  • the attributes of Classifiers (when a property is owned by a Classifier other than an Association)
  • the member Ends of Associations
  • the parts of Structured Classifiers.

Operation⌘

• a behavioral feature of a classifier, which specifies name, type, parameters, and constraints
• can have preconditions and postconditions
• can have a type (the type of the return parameter)
• example:

+ createWindow (location: Coordinates): Window

Class⌘

• describes a set of objects that share the same specifications of features (attributes and operations)
• is a special classifier
• an object is an instance of a class

Generalization⌘

• relationship between a more general classifier and a more specific classifier
• each instance of the specific classifier is also an indirect instance of the general classifier
• the specific classifier inherits the features of the more general classifier

Generalization Example⌘

Association⌘

• specifies a relationship between instances
• describes a set of tuples whose values refer to typed instances
• declares that there can be links between instances of the associated types

Multiplicity⌘

• specifies how many objects of the opposite class an object can be associated with
• is a range of the minimum and maximum values
• syntax: number or min..max

Multiplicity	Notation
zero	0 or 0..0
exactly one	1
zero or one	0..1
zero or more	0..* or *
one or more	1..*

Multiplicity example⌘

Multiplicity - order and uniqueness⌘

• Multiplicity defines a specification of order and uniqueness of the collection elements.
• This option can specify whether the values should be unique and/or ordered.
  • ordered: the collection of values is sequentially ordered (default: not ordered)
  • unique: each value in the collection of values must be unique (default: is unique)

Property = End or Attribute⌘

Navigability⌘

• specifies whether one object can be accessed directly from another

Aggregation⌘

• shows how something (whole) is composed of parts
• parts can exist separately - can be shared
• precise semantics of aggregation varies by application area and modeler :)

Composition⌘

• a strict form of aggregation
• the whole is the owner of its parts
• parts can not be shared
• the existence of its parts depends on the whole

Aggregation / Composition Example⌘

N-ary association⌘

• if an association has more than two end points (here: ternary association)
• Notation: a rhombus is used as a connection point

Association Class ⌘

• Association Class ia a model element that has both Association and Class properties.
• It not only connects a set of Classifiers but also defines a set of Features that belong to the Association itself.

Dependency ⌘

• a relationship that signifies that a model element(s) requires other model element(s) for their specification or implementation
• the complete semantics of the depending elements is dependent on the definition of the supplier element(s)
• the modification of the supplier may impact the client model elements
• the semantics of the client is not complete without the supplier
• the type of dependency can be specified by using a keyword or stereotype

Interface⌘

• is a kind of classifier that represents a declaration of a set of coherent public features and obligations
• an interface specifies a contract; any instance of a classifier that realizes the interface must satisfy that contract
• it is just declaration - so it is not instantiable

Provided Interface⌘

• an interface realized by a classifier is its provided interface
• represent the obligations that instances of that classifier have to satisfy

Required Interface⌘

• specify services that a classifier needs in order to perform its function

Interface Example⌘

Named Element⌘

• represents an element that may have a name and a visibility

Visibility Kind	Notation
public	+
private	-
protected	#
package	~

Package⌘

• used to group elements, and provides a namespace for the grouped elements
• qualified name:

package name::element name

Package Import, Access⌘

A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace.

Two types:

• «import» for a public package import
  • transitive: if A imports B and B imports C then A indirectly imports C
• «access» for a private package import
  • intransitive

Package Import Example⌘

• elements in Types are imported to ShoppingCart, and then further imported to WebShop
• elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced from WebShop

Instance ⌘

• is a concrete instance in the modeled system
• instance = object

Comment⌘

• a textual annotation that can be attached to an element
• may contain information that is useful to a modeler
• can be attached to more than one element

Constraint⌘

• condition or restriction related to an element
• it must always be true
• can be in a formal (OCL) or in a human language
• syntax:

{ [name :] boolean expression }

Composite Structure Diagram⌘

• Describes the internal structure of a classifier and the collaborations that this structure makes possible.
• Structured Classifiers may contain an internal structure of connected elements each of which plays a role.
• Encapsulated Classifier extends Structured Classifier with the ability to own Ports, a mechanism for isolating an Encapsulated Classifier from its environment.

Role and Part⌘

• Role represents a participant within the internal structure of a Structured Classifier.
• Part is special kind of Role (owned using composition).
• A part may be shown by graphical nesting of a box symbol with a solid outline representing the part.
• A role that is not a composition may be shown by graphical nesting of a box symbol with a dashed outline.

Connector⌘

• A Connector specifies links between two or more instances playing roles within a structured classifier.

Port⌘

• A Port represents interaction point through which an Encapsulated Classifier communicates with its environment.

Interaction⌘

• An interaction is a unit of behavior that focuses on the visible exchange of information between participants (limited in time).
• 4 interaction diagrams in UML 2.0:
  • Sequence diagrams - sequence in which messages are exchanged
  • Communication diagrams - relationship between the participants
  • Timing diagrams - state changes of the participants relative to the time
  • Interaction overview diagrams - order of interactions in an activity-like notation

Sequence Diagram⌘

• Participants are represented by a rectangle and a dashed line (lifeline)
• Messages are represented by arrows between lifelines
• Time runs from top to bottom
• The entire diagram represents one interaction

Connectable Element⌘

Connectable Element

• a set of instances
• can be considered as objects of the specified type
• lifelines (participants) represent connectable elements

Execution Specification (Execution Occurrence)⌘

• Specification of the execution of a unit of behavior within the lifeline.
• Sending and receiving messages determine start and end of execution specification.

Message⌘

Message Types⌘

• Synchronous message (filled arrowhead):
  • caller waits until called behavior terminates
  • reply message is represented by dashed line with either an open or filled arrow head
• Asynchronous message (open arrowhead):
  • caller doesn't wait but continues after call, no reply
• Found message (open arrowhead originating from a filled circle):
  • receiver known, sender not known
• Lost message (open arrowhead pointing to a filled circle)
  • sender known, receiver not known
• Create message (dashed line with open arrowhead pointing to header of lifeline):
  • new lifeline is created at this point in the diagram
• Delete message (open arrowhead):
  • object destruction, stop (destruction of an object is represented by a cross on the lifeline)

Event Occurrences⌘

• send event is denoted by an exclamation mark (!p)
• receive event is denoted by question mark (?p)
• A valid sequence for the interaction: < !p, ?p, !q, ?q >
• It's not the only valid sequence!

Event Occurrences valid trace⌘

Event Occurrences Rule⌘

• Send event before receive event
• The order of events along one lifeline is relevant.
• The position of one event relative to an event on another lifeline is insignificant.

Interaction Overview Diagram⌘

• Interaction Overview Diagram is a variant of Activity Diagram.
• Interaction Overview Diagrams focus on the overview of the flow of control where the nodes are Interactions or InteractionUses.

Interaction Overview Diagram⌘

Timing Diagram⌘

Timing diagrams show change in state of a structural element over time.

General Value Lifeline⌘

• Shows the value of the connectable element as a function of time.
• Value is explicitly denoted as text.
• Crossing reflects the event where the value changed.

More Lifelines⌘

State Machine Diagram⌘

• State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state transitions.
• State machine diagrams can also be used to express the valid interaction sequences (protocols) for parts of a system.
• Two kinds of state machines:
  • behavior state machine,
  • protocol state machine.

Behavior State Machine⌘

Vertex⌘

• Vertex is named element which is an abstraction of a node (State or Pseudostate) in a state machine graph.
• It can be the source or destination of any number of transitions.

State⌘

• State models a situation during which some invariant condition holds.
• In most cases this condition is not explicitly defined.
• Kinds of States:
  • Simple State (has no internal vertices or transitions)
  • Composite State (contains at least one region)
  • Submachine State (refers to an entire State Machine)

Transition⌘

• Directed relationship between a source vertex and a target vertex.
• Syntax: [<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
  • trigger specifies events that may cause state transition,
  • guard is a boolean expression,
  • optional behavior-expression is an expression specifying the effect (is executed when the transition fires)

Transition Kind⌘

The semantics of a Transition depend on its relationship to its source Vertex:

• external - transition exits its source vertex (executes exit action of source state)
• local - transition does not exit its containing State (exit action of the containing state will not be executed)
  • Target vertex may be different from its source Vertex.
  • Local transition can only exist within a composite State.
• internal is a special case of a local transition with the same source and target states,
  • the state is never exited (and not re-entered)
  • no exit or entry actions are executed

Internal Behaviors⌘

• entry - a Behavior which is performed upon entry to the State (entry Behavior).
• do - an ongoing Behavior (doActivity Behavior) that is performed as long as the modeled element is in the State or until the computation specified by the expression is completed.
• exit - a Behavior that is performed upon exit from the State (exit Behavior).

Completion Transitions, completion events⌘

• Completion transition has an implicit trigger (may have a guard).
• Completion event enables this trigger if all actions associated with the source state have completed execution:
  • In simple states: a completion event is generated when the associated entry and doActivity actions have completed executing.
  • In composite or submachine states: a completion event is generated when:
    • all internal activities have completed execution, and
    • if the state is a composite state, all its orthogonal regions have reached a final state, or
    • if the State is a submachine State, the submachine State Machine execution has reached a final state.

Pseudo State⌘

• Pseudostate is an abstract vertex that describes different types of transient vertices in the state machine graph.
• Pseudostates are transitive - a compound transition execution simply passes through them, arriving on an incoming Transition and leaving on an outgoing Transition without pause.

Initial ⌘

• Initial Pseudostate represents a starting point for a Region.
• It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard.
• There can be at most one initial Vertex in a Region.

Choice⌘

• Choice is used to realize a dynamic conditional branch.
• It allows splitting of compound transitions into multiple alternative paths.
• The decision on which path to take may depend on the results of Behavior executions performed in the same compound transition prior to reaching the choice point.
• If more than one guard evaluates to true, one of the corresponding Transitions is selected.
• If none of the guards evaluates to true, then the model is considered ill formed

Junction ⌘

• Junction can be used to merge multiple incoming Transitions into a single outgoing Transition or,
• it can be used to split an incoming Transition into multiple outgoing Transition segments with different guard Constraints.
• Such guard Constraints are evaluated before any compound transition containing this Pseudostate is executed, which is why this is referred to as a static conditional branch.

Fork⌘

• Splits an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State.
• The Transitions outgoing from a Fork cannot have a guard or a trigger.

Join⌘

• Common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions.
• Transitions terminating on a Join cannot have a guard or a trigger.

Terminate ⌘

• Execution of the State Machine is terminated immediately.
• The State Machine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are automatically aborted.

Entry Point ⌘

• Represents an entry point for a State Machine or a composite State that provides encapsulation of the insides of the State or StateMachine.
• In each Region of the StateMachine or composite State owning the Entry Point, there is at most a single Transition from the entry point to a Vertex within that Region.

If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. If multiple Regions are involved, the entry point acts as a fork Pseudostate.

Exit Point ⌘

• Represents an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or State Machine.
• Transitions terminating on an exit point within any Region of the composite State or a State Machine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior).

If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Psuedostate.

Shallow History⌘

• Represents the most recent active substate of its containing Region, but not the substates of that substate.
• Transition terminating on this Pseudostate implies restoring the Region to that substate.
• A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State.
• Shallow History can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State.

Deep History⌘

• Represents the most recent active state configuration of its owning Region.
• Transition terminating on this Pseudostate implies restoring the Region to that same state configuration.
• The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State.
• Deep History Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State.

Final State⌘

• Final State is a special kind of State (not Pseudo State) signifying that the enclosing Region has completed.
• Transition to a Final State represents the completion of the behaviors of the Region containing the Final State.

Event Processing for State Machines⌘

The run-to-completion paradigm (in general)

• State Machine will perform its initialization during which it executes an initial transition, after which it enters a wait point.
• A wait point is represented by a stable state configuration. It remains thus until an Event stored in its event pool is dispatched.
• This Event is evaluated and a single State Machine step is executed.
• A step involves executing a transition and terminating on a stable state configuration (i.e., the next wait point).
• This cycle then repeats until the State Machine completes its Behavior.
• Event occurrences are detected, dispatched, and processed by the State Machine execution, one at a time.

Transition Execution Algorithm⌘

Protocol State Machine⌘

• Is always defined in the context of a classifier.
• Specify allowed invocation sequences (lifecycle of a classifier).
• Describes which operations of the classifier can be called in which state and under which condition.

Protocol State⌘

• A protocol State represents an exposed stable situation of its context Classifier.
• The States of a ProtocolStateMachine cannot have defined entry, exit, or doActivity actions.

Protocol Transition⌘

• A Protocol Transition specifies a legal Transition for an operation of the context Classifier.
• Syntax: [precondition] event / [postcondition]

Introduction to Design Patterns⌘

• A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise - it provides solution to common software design problems.
• The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science.

GoF - Gang of Four ⌘

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design patterns : elements of reusable object-oriented software

GoF Design Patterns ⌘

• Creational Patterns - how to create objects
  • Abstract Factory
  • Builder
  • Factory Matehod
  • Prototype
  • Singleton
• Structural Patterns - how to create structures of objects
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

GoF Design Patterns ⌘

• Behavioural Patterns - how to describe communication between objects
  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

GoF Patterns Examples⌘

• http://www.blackwasp.co.uk/GofPatterns.aspx
• http://www.blackwasp.co.uk/Observer.aspx
• http://www.gofpatterns.com/design-patterns/module2/why-use-design-patterns-quiz.php