02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring - - PDF document

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2011

Contents

1 Recap 1 2 Agile Modeling 3 3 Model Driven Architecture 6 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Example MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Principles of MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Example: Rosa’s Breakfast Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5 Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.6 MDA and Metamodels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4 Summary 21

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

• f the production rate

1

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 Implementation Design

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 model need not follow 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) 2

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 a predefined set of documents (described in some process manual)
• The next phase can start only when the previous phase is terminated
• These documents need to be approved; changes to these documents can’t be easily done anymore
• Very much focused on the process and the documents to 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 a value system: What is important and what not ∗ Communication, Simplicity, Feedback, Courage, Humility (Modesty) – Principles: Provide guidelines for determining what to do. ∗ Travel light, Assume simplicity (KISS), Embrace change, Incremental change, . . . 3

– Practices: Describe concrete actions what 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 :-) Agile Modelling Principles

• 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

• ne 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 4

∗ 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 Agile Modelling Principles

• 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 – . . . 5

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/) 6

Model Driven Architecture MDA Basic Idea Derive the code / system from a high level, platform independent model by transformations

• ”Programming using a modelling 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 7

MDA PIM The Platform Independent Model describes the problem domain independent of the specific technology to imple- ment the system. The PIM corresponds roughly to the Domain model. 8

PSM The Platform Specific Model is 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

9

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 10

• 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 a language (e.g. UML) and describe a system Principles of MDA: Models Modles are written using the UML 11

Principles of MDA: Models 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 by transformation programs

Principles of MDA: Transformations

• A transformation consists of the transformation definition
• A transformation definition describes a mapping of a model in one language to a model in another language
• The transformation tool uses the transformation definition and does the actual transformation

→ Transformation definitions are easier to write than transformation programs 12

Principles of MDA: Transformations

• Example of a transformation definition form UMLto C#.
• Another example: Java Emitter Templates and EMF (Extended Modelling Framework) for the Eclipse plat-

form

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 13

MDA for Rosa’s Breakfast Service

• Three PSM’s

– Relational database model – Enterprise Java Beans implementation – Web interface PSM Relational database model 14

PSM EJB PSM Web Interface 15

Communication Bridge EJB relational DB

3.5 Transformations

Transformations

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

16

– 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

• r 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

• ther 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 level or meta level)
• In which language is the MOF written ?

17

MDA and Metamodels II Short notation for the previous diagram MDA and Metamodels III 18

• Models, transformations, as well as modeling languages and transformation languages can 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 19

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 20

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 software only produce the models that help you create the software and only in the detail 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 21