1
Software Development Using Software Development Using Executable UML (xUML)Executable UML (xUML)
Anoop Mathew11-22-2002
2
AgendaAgenda
Introduction to xUMLSoftware Design using xUMLxUML toolsConclusion
3
What is Executable UML?What is Executable UML? An executable version of UML. Automated methodology utilizing a highly specialized subset of
the UML notation.
xUML Precisely defined action semantics
semantically weak elements
UML
= - +
4
Executable UML continued…Executable UML continued…
Accelerates development of real-time, embedded software systems.
Well defined, disciplined approach to software development
Based on the object-oriented approach to software development.
5
Executable UML continued…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.
6
The xUML methodologyThe 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.
7
The xUML methodologyThe xUML methodologyThree 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
8
How do these models become How do these models become executable?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.
9
Software Development Using xUML
10
The system modelThe 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.
11
What is a Domain?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.
12
Domain (continued)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.
13
Domain (continued)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.
14
Domain Chart ExampleDomain Chart ExampleOnline Bookstore
Inventory<<realized>>
PackageShipping
<<realized>>Ordering
Model Compiler
<<realized>>Java
Web GUI
<<realized>>HTML
Domain Chart
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
15
Classes and AttributesClasses 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.
16
ClassesClasses
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.
17
Identifying classesIdentifying classes
Tangible ThingsRoles played by people or
organizationsIncidentsSpecifications
18
AttributesAttributes Attribute is an abstraction of a single
characteristic of entities abstracted into classes. Attributes have a data type associated with it. Types of Attributes1. Descriptive – describes intrinsic
characteristics of a thing.2. Naming – name used to refer to a thing.3. Referential – provides information about
links.
19
Datatypes in xUMLDatatypes 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.
20
Example ClassExample Class
Customer {6, Customer}
email: InternetEmailAddress
name: PersonalName
purchaseMade: Count = 0
Name
Attributes
Operations
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
21
Relationships and AssociationsRelationships and Associations
Associations between classes are modeled as relationships.
Relationships between classes are labeled as roles or verb phrases.
R1Customer Shopping Cart
has items placed in it by
adds items to
22
Types of relationshipsTypes of relationships
Binary Relationships (1..1, 1..*, 0..1, 0..*)
GeneralizationAssociative Relationships
23
Example of relationship typesExample of relationship types
Product
BookProduct RecordingProduct
R1
Author
Authorship
1..*
1..*
R2
wrote
was written by
R3
0..1
f ollows0..1
precedees
Generalization
Associative
Reflexive
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
24
Class ActionsClass 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.
25
Class Actions (continued)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.
26
Action LanguagesAction Languages
OAL - Object Action LanguageSMALL – Shlaer-Mellor Action
LanguageTALL – That Action Language
27
Example of OAL syntaxExample 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;
28
LifecyclesLifecyclesEach 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.
29
State MachinesState Machines Lifecycle formally expressed as a state
machine. State machine is comprised of1. States – each stage of the object lifecycle.2. Events – trigger.3. Transitions – specifies the new state given
current state and event received.4. Procedures – specifies the actions that an
object performs when it arrives in a state. Specified using an action language.
30
StateChart ExampleStateChart ExampleCreation State
-------------------------entry/
//no actions here
Adding Items to ShoppingCart
----------------------------------entry/
//add new item to shoppingcart
Saving Shopping Cart-----------------------------------
entry///save of shopping cart for
later
EV1: AddItem(Item)
EV1: AddItem(Item)
EV2: Sav eCart
Discarding Shopping Cart-------------------------------------
entry///discard entire shopping
cart
EV3: DeleteCart
31
Inter Object CommunicationInter 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.
32
Signaling ExampleSignaling Example
entry/
self.action = rcvd_evt.action;
select any reqhelper from instances of requesthelper;
generate actionreceived(action: self.action) to reqhelper;
generate backToIdle to self;
1. Performing an action
33
Synchronizing ObjectsSynchronizing Objects
There is no built in synchronization.Synchronization must be specified
explicitly.xUML uses signals to synchronize
state machine instances.
34
Rules for synchronizationRules 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.
35
Rules for synchronizationRules 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.
36
Inter-Domain CommunicationInter-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.
37
Turning Models Into Turning Models Into ImplementationImplementation 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).
38
Implementation (continued)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.
39
Implementation (continued)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.
40
Implementation (continued)Implementation (continued) Archetypes access a xUML repository
whose structure is defined using a meta-model.
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.
41
Archetype and Java ClassArchetype and Java Class.for each object in O_OBJ
public class ${obj.name} extends StateMachine
private StateMachineState currentState;
.select many attributes related by object->O_ATTR[R105]
.for each attribute in attributes
private ${attribute.implType}${attribute.name};
.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
Public class ProductSelection extends StateMachine {
private StateMachineState currentState;
private Currency unitPriceOfSelection;
protected void addSelection () throws ooaException;
protected void changeQuantity() throws ooaExeption;
}
Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002
42
Sample CompilersSample Compilers
Transaction safe system with rollback from Kabira Techologies.
BridgePoint Model Compilers from Project Technologies.
43
Executable UML tools
44
BridgePoint Development SuiteBridgePoint Development Suite By Project Technologies Full support of the X
TUML Process. Early execution, debug, and test of X
TUML 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
45
BridgePoint Development SuiteBridgePoint Development Suite
Image courtesy www.projtech.com
46
BridgePoint Development SuiteBridgePoint 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.
47Image courtesy www.projtech.com
48
BridgePoint Development SuiteBridgePoint 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.
49Image courtesy www.projtech.com
50
BridgePoint Development SuiteBridgePoint 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.
51Image courtesy www.projtech.com
52
ConclusionConclusion
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
53
More Info/QuestionsMore 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??