Software Development Using Executable UML (xUML)

1. Software Development Using Executable UML (xUML) Anoop Mathew 11-22-2002

2. Agenda • Introduction to xUML • Software Design using xUML • xUML tools • Conclusion

3. What is Executable UML? • An executable version of UML. • Automated methodology utilizing a highly specialized subset of the UML notation. UML semantically weak elements Precisely defined action semantics xUML + - =

4. 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… • 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 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 methodology Three basic types of models: • UML class diagrams – abstract common real world objects into classes. Classes have attributes and associations between classes are modeled as relationships • UML state chart – each active object has a lifecycle which is abstracted as state machines. • Action Language – specifies the behavior of the object as it goes through each state of its lifecycle

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

9. Software Development Using xUML

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

11. 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) • 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) • 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 Example Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002

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

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

17. Identifying classes • Tangible Things • Roles played by people or organizations • Incidents • Specifications

18. Attributes • 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.

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

20. Example Class Name Customer {6, Customer} email: InternetEmailAddress name: PersonalName purchaseMade: Count = 0 Attributes Operations Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002

21. Relationships and Associations • Associations between classes are modeled as relationships. • Relationships between classes are labeled as roles or verb phrases. R1 Customer Shopping Cart adds items to has items placed in it by

22. Types of relationships • Binary Relationships (1..1, 1..*, 0..1, 0..*) • Generalization • Associative Relationships

23. Example of relationship types Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002

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

25. 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 Languages • OAL - Object Action Language • SMALL – Shlaer-Mellor Action Language • TALL – That Action Language

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

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

29. State Machines • 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 state. Specified using an action language.

30. StateChart Example

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

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

33. Synchronizing Objects • There is no built in synchronization. • Synchronization must be specified explicitly. • xUML uses signals to synchronize state machine instances.

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

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

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

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

38. 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) • 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) • 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 Class Public class ProductSelection extends StateMachine { private StateMachineState currentState; private Currency unitPriceOfSelection; protected void addSelection () throws ooaException; protected void changeQuantity() throws ooaExeption; } .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 Adapted from Executable UML, A foundation for model driven architecture, Addison Wesley 2002

42. Sample Compilers • Transaction safe system with rollback from Kabira Techologies. • BridgePoint Model Compilers from Project Technologies.

43. Executable UML tools

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

45. BridgePoint Development Suite Image courtesy www.projtech.com

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

47. Image courtesy www.projtech.com

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

49. Image courtesy www.projtech.com

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