Transcript Document

Software Development Using
Executable UML (xUML)
Anoop Mathew
11-22-2002
1
Agenda
Introduction to xUML
 Software Design using xUML
 xUML tools
 Conclusion

2
What is Executable UML?

An executable version of UML.
 Automated methodology utilizing a highly
specialized subset of the UML notation.
UML
xUML
=
-
semantically
weak
elements
+
Precisely
defined action
semantics
3
Executable UML continued…
Accelerates development of realtime, embedded software systems.
 Well defined, disciplined approach to
software development
 Based on the object-oriented
approach to software development.

4
Executable UML continued…





xUML specification designed to separate
design from implementation.
Using xUML, application software design
is mostly shielded from target
platform/language and software
architecture considerations.
A much higher level of abstraction
compared to coding in a specific
programming language.
Creates extensible and reusable software.
Supports iterative software development. 5
The xUML methodology

Abstracts away specific programming
languages and software organization
decisions.
 xUML specification comprises of a set of
models that describe the problem under
study.
 Models can be verified/tested against
application requirements independently of
the design.
 This allows for early detection and
correction of errors.
6
The xUML methodology
Three basic types of models:
1. UML class diagrams – abstract common
real world objects into classes. Classes
have attributes and associations between
classes are modeled as relationships
2. UML state chart – each active object has
a lifecycle which is abstracted as state
machines.
3. Action Language – specifies the behavior
of the object as it goes through each
state of its lifecycle
7
How do these models become
executable?

For UML to be executable, rules have to be
defined for the dynamic specification.
 An xUML model compiler turns the models
into implementation.
 Target hardware and software
environment factors in type of
implementation compiler produces.
 Off the shelf compilers or custom made
compilers.
8
Software Development Using xUML
9
The system model
Executable UML model is built for
each subject matter, or domain in the
system.
 To create domains, requirements, in
the form of use cases, are sorted into
various subject matters in the
system.

10
What is a Domain?

A domain is an independent, real, or
hypothetical world composed of
conceptual entities.
 Domains are autonomous.
 Conceptual entities in one domain require
the existence of all others in the same
domain.
 Conceptual entities in one domain do not
require the existence of entities in other
domains.
11
Domain (continued)

Conceptual entities with the same name
can exist in different domains as long as
they mean different things.
 The domain where business logic
(application) requirements are captured is
called the application domain.
 All other supporting domains are called
service domains.
 Service domains provide services to
application domain.
12
Domain (continued)
The xUML model for each domain
comprises a set of class, state and
action models.
 Discovering domains and domain
refinement is an iterative process.
 Domain dependencies captured
graphically in a domain chart.

13
Domain Chart Example
Online Bookstore
Web GUI
<<realized>>
Package
Shipping
Inventory
<<realized>>
Ordering
<<realized>>
HTML
Model Compiler
<<realized>>
Java
Domain Chart
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
14
Classes and Attributes
Abstract requirements and use cases
into a model that formalizes
knowledge about the domain.
 xUML, being object oriented uses
classes, attributes and other
constructs to organize abstractions.

15
Classes
A class is an abstraction from a set
of conceptual entities in a domain.
 They all share the same
characteristics.
 They all behave according to the
same rules and policies.

16
Identifying classes
Tangible Things
 Roles played by people or
organizations
 Incidents
 Specifications

17
Attributes



1.
2.
3.
Attribute is an abstraction of a single
characteristic of entities abstracted into classes.
Attributes have a data type associated with it.
Types of Attributes
Descriptive – describes intrinsic
characteristics of a thing.
Naming – name used to refer to a thing.
Referential – provides information about links.
18
Datatypes in xUML
Core datatypes – boolean, string,
integer, real, date, timestamp.
 Domain specific datatypes - defines
a set of possible values an attribute
can take. Built with core data types.

19
Example Class
Customer
{6, Customer}
email: InternetEmailAddress
name: PersonalName
Name
Attributes
purchaseMade: Count = 0
Operations
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
20
Relationships and Associations
Associations between classes are
modeled as relationships.
 Relationships between classes are
labeled as roles or verb phrases.

Customer
R1
has items placed
in it by
Shopping Cart
adds items to
21
Types of relationships
Binary Relationships (1..1, 1..*, 0..1,
0..*)
 Generalization
 Associative Relationships

22
Example of relationship types
Product
Generalization
R1
Reflexive
Recording
Product
BookProduct
0..1
1..*
wrote
f ollows
0..1
R2
Authorship
1..*
R3
precedees
was written by
Author
Associative
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
23
Class Actions

Class diagrams capture entities.
 Class diagrams do not specify what these
entities do.
 An action is an individual operation that
performs a single task on an element in a
model.
 Class actions specify the behavior of the
class when the class is instantiated.
24
Class Actions (continued)

xUML relies on the Precise Action
Semantics for UML adopted in 2001 by the
Object Management Group (OMG).
 These action semantics provide the
specification but does not define a syntax
for these actions.
 There is no standard syntax for actions.
 Various action languages exist.
25
Action Languages
OAL - Object Action Language
 SMALL – Shlaer-Mellor Action
Language
 TALL – That Action Language

26
Example of OAL syntax
create object instance d of dog;
d.name = “sparky”;
Create object instance h of doghouse;
h.name = “sparkys house”;
relate d to h across R1;
unrelate d from h across R1;
delete object instance d;
delete object instance h;
select any d from instances of dog where …..
select many dogset from instances of d;
27
Lifecycles
Each active object (instance of a
class) in the domain has a lifecycle.
 Lifecycle describes the actions the
object performs.
 Lifecycles in xUML are modeled as
state machines.
 UML state charts used to graphically
represent state machines.

28
State Machines


1.
2.
3.
4.
Lifecycle formally expressed as a state
machine.
State machine is comprised of
States – each stage of the object
lifecycle.
Events – trigger.
Transitions – specifies the new state
given current state and event received.
Procedures – specifies the actions that
an object performs when it arrives in a
29
state. Specified using an action
StateChart Example
Creation State
------------------------entry/
//no actions here
EV1: AddItem(Item)
EV1: AddItem(Item)
Adding Items to Shopping
Cart
---------------------------------entry/
//add new item to shopping
cart
EV3: DeleteCart
EV2: Sav eCart
Saving Shopping Cart
----------------------------------entry/
//save of shopping cart for
later
Discarding Shopping Cart
------------------------------------entry/
//discard entire shopping
cart
30
Inter Object Communication





Objects communicate as a result of state
machine instances sending signals.
Signal is a message that may carry data
used by the actions in a procedure of a
recipients state machine.
Signaling is asynchronous
There is no return parameters.
Signals can be generated to self.
31
Signaling Example
1. Performing an action
entry/
self.action = rcvd_evt.action;
select any reqhelper from instances of requesthelper;
generate actionreceived(action: self.action) to reqhelper;
generate backToIdle to self;
32
Synchronizing Objects
There is no built in synchronization.
 Synchronization must be specified
explicitly.
 xUML uses signals to synchronize
state machine instances.

33
Rules for synchronization

Signals
Signals are never lost.
Signals are not reusable.
Signals are received in the order sent.
New signals are accepted by receiver only when
it has finished execution of current procedures
in a state.
Multiple signals could be outstanding at any
given time.
Signals generated to self always processed
before any others.
34
Rules for synchronization

Procedures
Only one state procedure being executed
at any given time.
Procedures in different objects can
execute at the same time.
New signals processed only after current
procedures are completed.
A procedure must leave data consistent.
35
Inter-Domain Communication





Each domain model include external entities (EE).
EE’s serve as anonymous proxies for the other
domains.
Link to another domain achieved by generating
signals or synchronously invoking operations on
EE’s.
When the signals are asynchronous, it is called a
bridge operation.
Bridge operation is an operation defined on an
external entity and implemented in another
domain.
36
Turning Models Into
Implementation

xUML models are compiled into
implementation.
 Compiler choice should be based on
application performance requirements and
the target environment
 A model compiler comprises a set of
mechanisms and a set of rules to bring the
xUML models together(archetypes).
37
Implementation (continued)





Mechanisms are library-like components
that require no specialization.
Model Compiler must provide an
implementation mechanism for each
element of xUML.
Model compiler must include mechanisms
to create, store and retrieve data.
Model compiler must include mechanisms
to execute procedures and actions.
Model compiler must include mechanisms
to generate signals and receive events. 38
Implementation (continued)

Rules for combining the xUML models
together are called archetypes.
 An archetype is a fragment of data access
and text manipulation logic that turns
xUML models into text, a format that the
compiler understands.
 Two types of archetypes – structural and
action semantics.
39
Implementation (continued)

Archetypes access a xUML repository
whose structure is defined using a metamodel.
 A metamodel is a model of a language
expressed using a modeling language.
 The metamodel of an xUML model is an
xUML model.
 The metamodel is a model that describes
application models, so that the archetype
language can traverse the xUML models.
40
Archetype and Java Class
.for each object in O_OBJ
Public class ProductSelection extends StateMachine {
public class ${obj.name} extends StateMachine
private StateMachineState currentState;
private StateMachineState currentState;
private Currency unitPriceOfSelection;
.select many attributes related by object->O_ATTR[R105]
.for each attribute in attributes
protected void addSelection () throws ooaException;
private ${attribute.implType}${attribute.name};
protected void changeQuantity() throws ooaExeption;
.end for
.select many signals related by object->SM_SM[R301]->SM_EVT[R303]
}
.for each signal in signals
protected void ${signal,name} throws ooaException;
.end for
}
.emit to file ${obj.name}.java
.end for
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
41
Sample Compilers
Transaction safe system with
rollback from Kabira Techologies.
 BridgePoint Model Compilers from
Project Technologies.

42
Executable UML tools
43
BridgePoint Development Suite






By Project Technologies
Full support of the XTUML Process.
Early execution, debug, and test of XTUML
application models.
Translation of XTUML application models
into target-optimized 100% complete code.
Customizable translators.
Powerful performance-tuning and system
resource-optimization.
courtesy www.projtech.com
44
BridgePoint Development Suite
Image courtesy www.projtech.com
45
BridgePoint Development Suite
BridgePoint Model Builder – allows
you to build all the artifacts needed
in the xUML process.
 Syntax checking for OAL.
 Strong model configuration
management and version control.
 Central repository model.

46
Image courtesy www.projtech.com
47
BridgePoint Development Suite
BridgePoint Model Verifier – executes
xUML models to quickly debug and verify
application behavior.
 Models can be verified as soon as they are
created. They do not need to be compiled.
 Verifier is interpretive.
 Early detection and correction of errors.

48
Image courtesy www.projtech.com
49
BridgePoint Development Suite
BridgePoint Model Generator – translates
the models into executable code using
design pattern and rules specified through
a model compiler.
 Sample Model Compilers
MC-2020 – generates C++ code, runs on
multiple RTOS and host OS environments.
MC-3020 – generates C code.

50
Image courtesy www.projtech.com
51
Conclusion
Executable UML has been used
successfully by many projects.
 There has to be an agreement on a
standard Executable UML.
 This would lead to standardized
compilers

52
More Info/Questions

Project Website
http://www.geocities.com/snpdg804/

More Info
Mellor Steven J, Balcer Marc J, Executable UML,
A foundation for model driven architecture,
Addison Wesley 2002
www.executableumlbook.com
www.projtech.com
www.kc.com/MDA/xuml.html

Questions??
53