Executable and Translatable UML

7/28/2019 Executable and Translatable UML

1/137


2/137


3/137


4/137


5/137

xtUML


6/137

xtUML


7/137

xtUML


8/137

xtUML


9/137


10/137

DomainsA domain is an autonomous, real, hypothetical, or

abstract world inhabited by a set of conceptualentities that behave according to characteristicrules and policies (Mellor and Balcer, 2002)

Domains are used to organize the subject matterof each concern

Each domain deals with a single concern and formsa cohesive whole, semantically autonomous ofother domains


11/137

DomainsWhen building software systems we typically deal with

various subject matters:

The application itself

Hardware and user interfaces

Data management

Security Networks

Commercial Off The Shelf Software (COTS)

Implementation technologies

Each of these software development concern can beconsidered separately


12/137

Domain CategoriesModeled using Executable UML, DFD, etc.

Application Domains Interface Domains

Service Domains

Software Architectural Domains

Realized already implemented or well understood,

no need to model Implementation technology domains

External systems and legacy code


13/137

Domain Chart


14/137

Domain Chart


15/137

Application DomainsDeal with applications (book store, microwave oven,

railway signaling, etc.)

Assume that other domains will

Handle generic services such as networking, securityand logging etc.

Provide mechanisms to create and delete objects,generate events and implement state machines, etc.(in accordance with a particular architecture thatsatisfies various nonfunctional requirements)


16/137

Interface Domain

All applications interface to the outside world

user, hardware, software

Usually independent of the underlying

mp ementat on tec no ogy


17/137

Service DomainsDeal with common aspects that cut across an application or set of applications

Reusable

General concerns such as

Security policy

Networking

UI Look & Feel

Reusable domain specific concerns such as

Inventory management

Target tracking

Engine management Calendar services

Work flow

Configuration management and version control


18/137

Software Architectural DomainsProvide mechanisms needed to execute applications

generated from models e.g. For Executable UML

Initialization

Object creation and deletion

Object attribute manipulation

Link creation and deletion State machines (events, transitions and actions)

Constraint enforcement

Ensure uniformity of implementation

Deal with nonfunctional requirements


19/137

Realized DomainsDomains that already exist and are well understood

They don't need to be modeled

Implementation technologies such as

Java (and its APIs)

MySQL

External systems such as

A bank

A Search Engine

Legacy Code


20/137

Executable and Translatable UML

Class Diagram


21/137

Object and ClassThe world contains real and hypothetical things

Like things can be abstracted as classes

The set of all university courses can be

a stracte as a ourse c ass The set of all students can be abstracted as aStudent class

There are relationships between classes

Students are enrolled in courses


22/137

Finding ClassTangible Things

Lecture Theatre

Examination Paper

Roles

Student

Chair of examiners

Incidents

Assignment submission

Graduation

Interactions

Enrolment (relating a student and course)

Specifications

Assessment scheme


23/137

Naming ClassThe Class Diagram as a dictionary

Use names in common usage

Names used by people working in the subject domain

Avoid invented names

Be precise

StoreRoom rather than Room

Avoid generic words

User, task, order etc.


24/137

AttributesAll classes possess attributes (characteristics)

Each attribute of a class represents a singlecharacteristic which every instance of that class mustpossess

Each instance of a class may possess a different value forthe same attribute

Each attribute must possess an appropriate range ofvalues (a type)


25/137

Types of Attribute

Descriptive attributes

Naming attributes

Referential attributes


26/137

Descriptive Attributes

Provide facts about a class instance

They describe instances

Examples Student Image

Student Name


27/137

Naming Attributes

Provide an arbitrary label for instances

StudentID

CourseID


28/137

Referential Attributes

Associate a particular instance of one class to a

particular instance of another

Student.CourseID


29/137

Data TypesThe set of values an attribute can take on

constitutes its Data Type

wo n s Core Data Types

Domain Specific Data Types


30/137

Core Data TypesFundamental Data types from which domain

specific types can be defined Boolean

String

Integer Real

Date

Timestamp

ID


31/137

Domain Specific Data TypesNumeric Types

type TutorialSize is integer range 1..20

String Types

type StudentName is symbolic length 20

Enumerated Types

type UserLanguage is (English, Japanese, Arabic, Greek)


32/137

Domain Specific Data TypesComposite Types

Attributes of composite types are always treated as asingle unit.

The components of a composite type are not accessible

type Address isrecord

Street : String

Number : integer

PostCode : integer range 0000..9999end record


33/137

Using TypesAll attributes have a type

Attributes are defined in terms of

Attribute Name

Optional default initial valueExample

Language : UserLanguage = English

Use Domain Specific Types whenever possible


34/137

A Class


35/137

AssociationsAn association is an abstraction of a realworld

relationship between realworld entities.

Classes are abstractions of realworld entities

realworld entities Associations are abstraction of the relationships

between realworld entities

They formalize how realworld entities relate to eachother


36/137

AssociationsAssociations are represented as a line

connecting the associated classes on the classdiagram


37/137

Association NamesEach association has a name

Arbitrary, unique

Used as a reference e.g. In State Machine

ct ons

eg. R1, R34


38/137

Association MeaningsThe meaning of each association is expressed

by associating a string with each end of theassociation


39/137

MultiplicityAn association between two objects can be

characterized in terms of the number of class

instances that participate in the association

Unconditional

1..1 only one instance1..* one or more instances

Conditional

0..1zero or one instance

0..*zero or more instances


40/137

Multiplicity


41/137

Association ClassesSimple associations can be 'formalized' with verb phrases and

multiplicity.

In some cases associations are more complex having their ownattributes and behavior.

We deal with such situations by using association classes classes thatformalize associations.

Association Classes can have attributes, behavior and otherassociations just like any other class

Instances of association classes are the links between participatingobjects


42/137

Association Classes


43/137

Association ClassesAssociation Classes are created when an

association between participating instancesis created

They are deleted when the participating

instances are unrelated.


44/137

Generalizations Common attributes and behavior are defined

in a superclass (superset) Specialized attributes and behavior is defined


45/137

Generalizations


46/137

Generalizations


47/137

Generalizations


48/137

Generalizations


49/137

Reflexive AssociationsReflexive Associations are associations

between instances of the same class

se to mo e o ects t at systemat ca y

associate with each other

a sequence of objects

a network of objects

a hierarchy of objects


50/137

Reflexive Associations


51/137

Sequences


52/137

Networks


53/137

Hierarchies


54/137

Reflexive Association Classes


55/137


Statechart Diagram


56/137

Simple Statechart


57/137

More Complex Statechart


58/137

Very Complex Statechart


59/137

Statechart ComponentsStates

Light - on, off, broken

Car Cruise Control - maintaining speed, accelerating, braking

Events

abstractions of real-world incidents or conditions

events cause transitions from one state to another

Light - power applied, power removedCar Cruise Control - speed dropped, speed increased

Transitions

paths from one state to another

associated with events

taken when a corresponding event is received

Actions

executed when state changes


60/137

Two ApproachesState models can be organized in two ways,

including:

The Moore model

act ons are assoc ate w t states

actions are executed on entry to a state

The Mealy model

actions are associated with transitions

actions are executed during transition


61/137

Moore Model


62/137

Mealy Model


63/137

ComparisonThe Mealy model:

4 states

Duplicated actions (e.g. actions on each transition to theWaitingForSet state)

The Moore model:

5 states

No duplicated actions

It sometimes makes sense to combine the two models Actions during transitions, and

Action on entry to states


64/137

Charts and TablesState Models can be represented in various ways,

including:

State Charts (as on previous slides)

State Transition Tables

Each representation has its place

State Charts provide a good overview of a statemodel

State Transition Tables can be used to analyze thecompleteness of a State Model


65/137

Charts and Tables


66/137

Statechart

Statechart


67/137

Statechart

State Transition Table


68/137




69/137


Empty Cell


70/137

Empty Cell

Empty cells in the State Transition Table need to be analyzed

This analysis can sometimes identify

Missing states

Missing transitions

More questions for stakeholders

If nothing is missing, then we need to state if the subject event

is Ignored

Cant Happen

Finding New Transitions


71/137


Empty cells on the State Transition Table mayindicate transitions that have been overlooked

Need to develop consensus among expertsregarding the correctness of empty cells

For example Pressing the oven button when cooking is

complete is shown as an empty cell

But, it may make sense to start cooking when thebutton is pressed in this state



72/137




73/137


Finding New States and Events


74/137




75/137




76/137




77/137


Ignored Events


78/137

g

Some empty cells in the STT represent events thatare simply ignored

Pressing the button when the door is open MUSThave no effect

Add Event Ignored to the STT

Objects stay in their current state when an event is

ignored The event is consumed by the state machine

Ignored Events


79/137

g

Events that Cannot Happened


80/137

pp

Some events simply cannot happen according to therules, policies and physical laws of the subject domain

A doorClosed event cannot happen when the oven is inthe Cooking state - the door is already closed

already opened

Add Cannot Happen to the STT

Describe why such events cannot happen

Events that Cannot Happened


81/137

pp


82/137


Action

Actions


83/137

Actions are used to describe what happens when a state is entered (Moore model) or a transition is taken

(Mealy model)

Actions can be used to create and delete entities/classes

navigate relationships between entities/classes

read/write entity/class attributes

send events (to self and other state machines)

perform calculations

Actions can be described in various ways

Structured Natural Language (e.g. English)

maintain a glossary of terms

ensure consistent references to data, events, states etc.

if its a specification, eliminate all implementation concerns Formal Languages

eXecutable and Translatable UML (XT UML) Action Language

tool specific languages

programming languages (only if state machine is developed during implementation)

Actions


84/137

An action performs a single task on an elementof a model

Object Actions

Link Actions Link Object Actions

Signaling

Calculations

Object Actions


85/137

Object actions operate on objects

Create and Delete objects Select objects

Reclassify objects

The object operated on is specified at runtime

Create and Delete Objects


86/137



87/137



88/137

Create and Delete


89/137

Reclassification


90/137

Selecting Object


91/137

Iteration Thru Sets of Object


92/137

Selecting One Object


93/137

Attribute Actions


94/137

Attribute Actions operate on attributes

Read attributes Write attributes

Link Actions


95/137

Object Actions operate on class instances called

objects

n ct ons operate on assoc at on nstances

called links

- Create and Delete Objects

- Traversals

Link Actions


96/137

Create and Delete Links


97/137

Create and Delete Links


98/137

Link Traversals


99/137

Link Traversals


100/137

Link Traversals


101/137

Link Object Actions


102/137

Object Actions operate on class instances calledobjects

Link Actions operate on association instances

Link Object Actions operate on association classinstances called link objects

- Create and Delete Link Objects- Traversals

Link Object Actions


103/137

Create and Delete Link Object


104/137

Link Object Traversals


105/137

Signaling


106/137

Objects communicate by sending signals

Objects send signals to other objects

More generally, an event is anything that can be detectedby a state model

signal events (events caused by a signal)

time events a condition in the external environment

Signaling


107/137

Actions can be used to send signals

Signaling is asynchronous

sender continues processing after a signal is sent the receiver will recognize the signal at some later time as an event

depending on the state of the receiver object, the event may cause a state transition or it

may e gnore

Events detected by a State Model can include data in the form of Parameters

The set of parameters associated with an event can be viewed as an object created by the

sender

Parameters can be used by procedure actions in the receiving objects state model

All events that cause a transition to a given state, must carry exactly the same event parameters

The procedure executed as a result of the transition will always have the same parameters

available, regardless of which event caused the transition

In some ways this is similar to anonymous calls to functions/methods in Java, C++ etc

Signaling


108/137

Signaling


109/137

Signaling


110/137

Signaling


111/137

Signaling


112/137

Signaling


113/137

Signaling


114/137

Signal to Self


115/137

Signal to Self


116/137

Signal to External Entities


117/137

Asynchronous v.s. Synchronous

Methods are not used in xtUML


118/137

Methods are not used in xtUML

All communication is asynchronous i.e. using

signals

xt mo e s are pure y async ronous

Easily translated into either synchronous orasynchronous implementations (e.g. distributed,multi-threaded architectures)

Synchronous models are difficult to translate intoasynchronous implementations

Synchronous Passive Objects


119/137

Asynchronous Active Objects


120/137



121/137



122/137



123/137



124/137

Synchronous Active Objects


125/137


126/137


Visualization

Complete Model


127/137

Visualization

We need better ways to visualize large models


128/137

We need better ways to visualize large models

xtUML relies on two high level views of large

mo e s

Collaboration Diagrams - summary of all signalflowing among objects and external actors

Sequence Diagrams - details of behavior in a

specific scenario

Collaboration Diagrams

Informal/preliminary collaboration diagrams can be produced as a startingpoint for the development of formal State Models


129/137

point for the development of formal State Models

A bit like a Context Diagram - an overall view of what is going on

As State Machines take shape, these first cut collaboration diagrams mayneed to be revised.

When State Models are complete, Collaboration Diagrams can be

automatically derived Everything needed to build a Collaboration Diagrams is specified within

the state models

In practice, collaboration diagrams my shock!

Horrendously complicated communications Often indicates a need to revise Class Models and State Models

Collaboration Diagrams


130/137

Sequence Diagrams

An Execution Trace is a sequence of procedures and signals that occurs inresponse to an event


131/137

p

Depends on the current state of the system

Involves a subset of domain objects and actors

Sequence Diagrams provide a graphical representation of execution traces

Sequence Diagrams should not be used to show every possible Execution

Trace Be sensible

e.g. use them to represent important test cases

Sequence diagrams can be sometimes generated by model

execution/debugging environments

Sequence Diagrams


132/137

Sequence Diagrams


133/137


134/137


Verification

Static Verification

Check that models are constructed properly. Forexample:


135/137

example:

classes have attributes attributes are typed

states ave proce ures

OCL and Action language is compilable

Static Checks can be completed by:

tools such as BridgePoint inspections e.g. peer review

Dynamic Verification

Execute models to check that they behave properly.


136/137

Test Cases are developed and run using techniques similar to those used to testsoftware

The verification of xtUML models starts very early in the software life-cycle

testers work throughout the entire software development life-cycle

Text cases are executed to verify model dynamics and are defined in terms of:

An initial system state State Model states

Instantiated objects

Object attribute values

An initiating event and parameter values Possibly, a range of values

An expected outcome Events, state, attribute values

Verification


137/137

Documents

Executable and Translatable UML