1 software development using executable uml (xuml) anoop mathew 11-22-2002

1

Software Development Using Software Development Using Executable UML (xUML)Executable UML (xUML)

Anoop Mathew

11-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 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

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 Attributes

1. 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


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


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

LifecyclesLifecycles

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.

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 Example

Creation 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

SignalsSignals 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

ProceduresOnly 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


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


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;

}


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


Image courtesy www.projtech.com

46


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 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.

50


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.

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??

1 software development using executable uml (xuml) anoop mathew 11-22-2002

Documents

xuml slide

xuml software design

application domain

xuml specification

lifecycle slide

application software

executable version of

reusable software