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 of 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 User Story User Story User Story Analysis Design Implementation Test User Story User Story User Story Time 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 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 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
Recommend
More recommend
