02291: System Integration Hubert Baumeister

(1)

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2011

1 Recap

Recap Explorative Modelling

• Explorative Modelling

– Using a programming language as the modelling language

– Use a high level programming language; focus on the aspects one wants to model and disregard, e.g.

user interface, database, etc.

– If UML models are needed for documentation: Reverse engieer models from the code or use tools that, e.g., can work with code as well as with diagrams at the same time (e.g. eUML)

– Advantages

∗ Allows to experience with the models

∗ Allows to automatically test models

• Software Development Process

– Cyle time = Number of user stories / Production rate

– Goal: to reduce the cycle time by reducing the number of user stories, which leads to an improvement of the production rate

(2)

Recap Software Development

• Two basic strategies:

1) Iterate through each activity→mass production/water fall

→ Can make the activity very efficient, but does not help in making the overall prodcut better

Analysis Design Implementation

User Story User Story User Story User Story User Story User Story

Time

Test

2) Iterate through the whole process by user stories→lean production/single piece flow

→ improves the overall result and interaction of activities instead of one activity

user story user story user story user story user story user story user story user story user story user story user story user story user story user story user story user story

user story

Analysis Test Design

Implementation

Time

Possible process for the project

Note that you can develop the model and writing the report independentaly

→ How you develop the modelneed notfollow the structure of the report 1) Business Processes

2) Domain class diagram 3) Glossary

4) Define basic architecture (e.g. basic component diagram with ports and connections between ports but no detailed interfaces yet and no protocol state machine)

5) User stories (= use case scenarios)→project plan (in which week to do which user story)

(3)

Possible process for the project (cont.) 6) Repeat for each user story

6.1) Detail use story

6.1) Acceptance tests for the user story

6.1) Extend detailed class diagram so that the user story can be realized (e.g. CRC cards) and take the architecture into account

∗ Make sure that the detailed class diagram implements the interfaces from the component diagram (here the operations for the interfaces will be defined)

6.1) Extend the behaviour diagrams to cope with the new user story

6.1) Extend the PSM (based on the behaviour diagram) to cope with the new user story 6.1) Show that the user story is realizable by drawing the sequence diagram

7) Consolidate the diagrams for the report

→ Check that the sequence diagrams are still applicable; if not, update the sequence diagrams 7) Write the text for the report

2 Agile Modeling

Agile Modelling

Is an approach to improve traditional modelling techniques

• Waterfall

– Requirements – Design

– Implementation – Test

– Maintenance

• Each phase requires apredefinedset of documents (described in someprocess manual)

• The next phase can start only when the previous phase is terminated

• These documents need to beapproved;changesto these documentscan’t be easily doneanymore

• Very muchfocusedon the process and the documentsto deliver but not on the result

Agile Modelling

• Agile modelling originates in agile processes like eXtreme Programming (XP)

– However, e.g. XP makes no real statements on modelling issues; modelling is done but is kept rather informal

– Agile modelling focuses on the modelling part but in an agile way

• Agile Modelling is based on values, principles, and practices

– Values: Defines avalue system: What isimportantand what not

∗ Communication, Simplicity, Feedback, Courage, Humility (Modesty) – Principles:Provideguidelinesfor determining what to do.

(4)

– Practices:Describeconcrete actionswhat to do

∗ Create several models in parallel, create simple content, iterate to another artifact, . . .

• References

– http://www.agilemodeling.com(Scott Ambler) – ”Agile Modelling” Scott Ambler, Wiley 2002

Agile Modelling Values

The values are the central part of agile modelling. If you don’t agree to them, then you should not apply agile modelling

• Communication

• Simplicity

• Feedback

• Courage

• Humility

Agile Modelling Principles

The principles support the values

• Core Principles

– Software is your primary goal

– Enabling the next effort is your secondary goal

∗ One should be able to extend the system over time – Travel light

∗ Do the necessary things but not the unnecessary things

∗ Document your models / keep the documentation updated as needed (update when it hurts) – Assume simplicity or KISS (Keep It Short and Simple)

∗ Assume that the simplest solution is the best solution

∗ Things to avoid

→ Applying complex patterns too soon

→ Over-architecting your system to support potential future requirements

→ To develop complex infrastructure

→ Tip:Don’t ”What if” yourself to death:-)

• Core Principles (cont.) – Embrace change

∗ Accept the fact that change happens – Incremental change

∗ Change your system a small portion at a time instead of trying to get everything accomplished in one big release

– Model with a purpose

∗ If you cannot identify why and for whom you are creating a model, then why are you bothering to work on it at all?

– Multiple models

(5)

∗ Each model type has its strengths and weaknesses

∗ Iterate between the model types to get feedback

∗ Typical situation: Moving between User Cases, Sequence Diagrams / State Machines / Activity Diagrams, Class Diagrams, User Interface flow diagram, GUI mock ups

– Quality work – Rapid feedback

– Maximise stakeholder investment

• Supplementary Principles

– Content is more important than representation – Everyone can learn from everyone else – Know your models

– Local Adaptation

– Open and honest communication – Work with people’s instincts

Practices

A complete list of practices with description can be found at http://www.agilemodeling.com/

practices.htm. Here we only address a few:

• Core Practices

• Supplementary Practices

• Real Good Ideas

Core Practices

• Active Stakeholder Participation

• Apply the Right Artifact(s)

• Collective Ownership

• Create Several Models in Parallel

• Create Simple Content

• Depict Models Simply

• Display Models Publicly

• Iterate to Another Artifact

– E.g. Start with a use case / user story – Move to the class diagrams

– Move to the scenarios – Move to the state machines – Move to the components – . . .

(6)

Core Practices (cont.)

• Model in Small Increments

→ Iterate to another artifact

• Model With Others

• Prove it With Code

→ Explorative Modelling

• Single Source Information

• Use the Simplest Tools

Supplementary Practices

• Apply Modelling Standards

• Apply Patterns Gently

– Don’t force the use of patterns if not necessary (Simplicity!)

• Discard Temporary Models

• Formalise Contract Models

– e.g. API (interfaces but also behaviour→Design by Contract) – file layout specification

– XML DTD

– Physical Data model – . . .

• Update Only When It Hurts

3 Model Driven Architecture

3.1 Introduction

MDA

• Model Driven Architecture (MDA) – Defined by the OMG

– MDA is a trademark by the OMG

• Literature

– Anneke Kleppe, Jos Warmer, Wim Bast ”MDA Explained”, 2003, Addison Wesley Professional – MDA Website by OMG (http://www.omg.org/mda/)

(7)

Model Driven Architecture MDA Basic Idea

Derive the code / systemfrom a high level,platform independent modelbytransformations

• ”Programmingusing amodelling language”

• Code is obtained by”compiling”the abstract model

• Properties can be analysed on the model level;

– if transformations are correct, the resulting code also has the properties

• Choice of the modelling language

– In principle any, but MDA is based on UML for describing the models

Traditional Development to MDA

(8)

MDA PIM

ThePlatform Independent Modeldescribes the problem domain independent of the specific technology to imple- ment the system.

The PIM corresponds roughly to the Domain model.

(9)

PSM

The Platform Specific Modelis a model taking into account the target platform of the system, like the use of EJB’s, .Net, etc.

3.2 Example MDA

Example I: Attributes

• In a PIM, attributes would be modelled as UML attributes

Example I: Attributes

• In a Java specific PSM attributes are implemented using accessor functions

• Transformation

– ”For each attribute, make that attribute private and introduce setter and getter functions for that attribute with the same visibility as the original attributes”

Example II: Associations

• In a PIM, associations would be modelled using UML associations

(10)

Example II: Associations

• In an OO programming language, associations are implemented as private attributes with accessor methods

• Transformation

– ”For each association end that is navigable introduce an accessor function”

3.3 Principles of MDA

MDA Benefits

• Higher productivity

– ”Program” on higher abstraction level

∗ Don’t need to care about programming ”details”

∗ Closer to the problem domain – Complex transformations can be reused

• Portability

– The same PIM can be used to generate PSM’s for different platforms

(11)

• Interoperability

– PSM’s for different platforms generated from the same PIM can be easily related

• Maintenance and Documentation – PIM’s act as documentation

– Since the high level PIM is used to generate the code, it is kept up to date – Changes in the PSM’s can be reflected back into the PIM

Principles of MDA: Models

Models are written in alanguage(e.g. UML) and describe asystem

Modles are written using the UML

(12)

Each model has its own language (e.g. a Petri nets uses the Petri nets language and a ER Model uses entity- relationship diagrams)

Principles of MDA: Transformations

• The PIM is transformed to the PSM which is transformed to code

• The transformation is done bytransformation programs

• A transformation consists of thetransformation definition

• A transformation definition describes a mapping of a model in one language to a model in another language

• Thetransformation tooluses the transformation definition and does the actual transformation

→ Transformation definitions are easier to write than transformation programs

(13)

• Example of a transformation definition form UMLto C#.

• Another example: Java Emitter Templates and EMF (Extended Modelling Framework) for the Eclipse platform

3.4 Example: Rosa’s Breakfast Service

Example: Rosa’s Breakfast Service (From ”MDA Explained”)

• ”Rosa has founded a company that supplies a complete breakfast delivered to the homes of its customers.

– Customers can order from one of the breakfast menus on Rosa’s Web site,

∗ indicate the hour and place of delivery,

∗ give their credit card number, and the ordered breakfast will be delivered

• Rosa has composed a series of breakfasts, each of which comes with special decorations

– For instance, the Valentine breakfast is served on plates decorated with small hearts and cupids, with matching napkins.

– The items served are set by the choice of breakfast. [..]

– Orders can be filled for any number of people, where any in the party may order a different breakfast.”

PIM for Rosa’s Breakfast Service

(14)

MDA for Rosa’s Breakfast Service

• Three PSM’s

– Relational database model

– Enterprise Java Beans implementation – Web interface

PSM Relational database model

(15)

PSM EJB

PSM Web Interface

(16)

Communication Bridge EJB relational DB

3.5 Transformations

Transformations

• Standard transformation provided by a transformation tool (e.g. the IDE)

(17)

– E.g. UML PIM→UML for Java – UML→Code (Java, C#, . . . )

• Customised transformations – Defined by the user

– Usually defined as rules in a transformation language

∗ E.g. Query View Transformation (QVT)

∗ Graph Transformation Techniques

• Rules can be applied by hand or automatically

– To which model elements should the rules be applied?

– E.g. Which classes should be represented as EJB’s and which as ordinary classes

Example Transformation

Transformation classes to DB schema (Pseudo Code)

if the association A to B is adorned by an association class or the multiplicity at both ends is more-than-one

then create a table representing the association class or the association

and create foreign keys in both the table representing A and the table representing B referring this new table

else if the multiplicity at one end is zero-or-one

then create a foreign key in the table representing the class at that end, referencing the other end

else // the multiplicity of the association is one-to-one create a foreign key in one of the tables, referencing the other end

endif endif

3.6 MDA and Metamodels

MDA and Metamodels I

• E.g.: A UML model is written using the UML (first level)

• The UML language can be described by the UML meta model

• The UML meta model need is written in MOF (Meta-Object Facility) (second levelormeta level)

• In which language is the MOF written ?

(18)

MDA and Metamodels II

Short notation for the previous diagram

MDA and Metamodels III

(19)

• Models, transformations, as well asmodeling languages and transformation languagescan be expressed by the same meta language(or an extension thereof)

• E.g. Meta Object Facility (MOF) / Eclipse Modeling Framework (EMF)

→ Use of the same basic language and its tools (editors, transformation engines, exchange formats etc.) for models, transformations, and their languages

3.7 Summary

The MDA/MDA promise

(20)

The MDA/MDA promise

Problems I

• ”Programming using a modelling language”; code is obtained by ”compiling” the abstract model – Nice idea, but

∗ Models usually focus on certain aspects of a system by leaving out other aspects (structural vs.

behavioural models, GUI, Distribution, Components, . . . )

∗ the abstract model does not contain all aspects of the resulting system

∗ the missing aspects (like distribution / components) have to be ”invented” by the transformation – Design decisions made by the designer

→ Choice of the transformation

(21)

Problems II

• What happens with behavioural models?

– How is a state machine / activity diagram / interaction diagram transformed?

– How to deal with different abstraction levels of behaviour descriptions?

∗ E.g. business processes vs. Java methods

→ No out-of-the-box simple ”compilation” techniques applicable that apply to all cases

4 Summary

Summary

• Agile Modeling

– Applies values and principles from XP programming

→ creates a new set of practices for modelling

→ Adapt your modelling to what you want to achieve (e.g. if you want to create softwareonlyproduce the models that help you create the software and only in thedetail needed)

• Model Driven Architecture

– Platform Independent Model (PIM) – Platform Specific Model (PSM) – Transformations PIM→PSM→code

– Metamodelling (e.g. using EMF/MOF) allow to describe modelling languages and transformations in a general way

02291: System Integration Hubert Baumeister