02291: System Integration Week 10

Hubert Baumeister [email protected]

DTU Compute Technical University of Denmark

Spring 2018 Last Week

I Principles of good design: layered architecture

I Software Development Processes

I Introduction to Examination Project Contents

Software Development Process

Agile Modeling

Model Driven Architecture

More UML Diagrams Resource Triangle

Plan Driven Agile Features User User User Story Story Story

Presentation Layer

Application Layer A D I T Domain Layer

Database / Infrastructure Layer

Release date Time eXtreme Programming (XP)

I Kent Beck 1999

I 12 Practices

Kent Beck, Extreme Programming 1st ed. Scrum file:///Users/huba/Desktop/Scrum_process.svg

24 h

30 days

Working increment Product Backlog Sprint Backlog Sprint of the software

Wikipedia

I Robert Martin (Uncle Bob) about ”The Land that Scrum Forgot” http://www.youtube.com/watch?v=hG4LH6P8Syk → History about agile methods, the agile manifesto, and Scrum and its relationshop to XP 1 of 1 /18.3.13 24:16 Lean Software Development

I Lean Production:

I Value for the customer I Reduce the amount of waste in the production process I Generate flow I Waste: resources used which do not produce value for the customer

I time needed to fix bugs I time to change the system because it does not fit the customers requirements I time waiting for approval I ... Generating flow using Pull and Kanban

WIP = Work in Progress Limit ATD I Done Work Item Queue WIP 3Queue WIP 3Queue WIP 3 Queue WIP 3 6 1 4 2 3 5

7

8 10 9

Blah Composite

Leaf 4Assembly 2 3 Flow through Pull with Kanban

I Process controlling: local rules

I Load balancing: Kanban cards and Work in Progress (WIP) limits

I Integration in other processes

Figure from David Anderson www.agilemanagement.net Online Kanban Tool: Trello

I www.trello.com: Electronic Kanban board useful for your project

I Kanban board the exam project example https: //trello.com/b/CqzwTiRT/02291-example-lean

I Another Example https: //trello.com/b/4wddd1zf/kanban-workflow Contents

Software Development Process

Agile Modeling

Model Driven Architecture

More UML Diagrams Agile Modelling

I Traditional modelling: Requirements model, design model → waterfall I What is the role of modelling in agile software development?

I XP and documents I XP and modelling → Agile modelling Agile Modelling

I Agile Modelling: values, principles, and practices I References

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

I Communication

I Simplicity

I Feedback

I Courage

I Humility

http://www.agilemodeling.com/values.htm Agile Modelling Principles

I Core Principles

I Software is your primary goal I Enabling the next effort is your secondary goal I Travel light I Incremental change I Model with a purpose I Multiple models ... Practices

I Core Practices

I Supplementary Practices

I Real Good Ideas Core Practices

I Active Stakeholder Participation

I Collective Ownership

I Model in Small Increments

I Create Several Models in Parallel

I Iterate to Another Artifact

I Display Models Publicly

I Model With Others

I Prove it With Code

I Use the Simplest Tools

I ... List of practices: http://www.agilemodeling.com/practices.htm Disciplined Agile Development (DAD) I Hybrid Agile development method evolved from I Agile Modelling I Agile Unified Process I Based on

SAFe: Scaled Agile Framework, Outside In Dev.: Focus on stakeholder requirements, Evo: Evolutionary Development

http://disciplinedagileconsortium.org Iterative Processes: E.g. Rational Unified Process (1996) A*High*Level*Lifecycle*

DAD

Focus on complete lifecycle

http://disciplinedagileconsortium.org

© Disciplined Agile Consortium 4 DAD

DAD + Lean

New Initial features Architectural Vision

Identify, prioritize, Retrospective and select Replenishment projects modeling session Business Value Initial Vision Learnings Operate and Funding Initial Initial Release and Require modeling, Fixed Delivery Date Daily work solution into support -ments planning, and production solution in organization Work items are pulled when Strategy production Business Roadmap, Expedite capacity is available Technology Roadmap to address them Feedback Coordination Demo Meeting Envision the Intangible future Options Enhancement Requests New and Defect Reports features

Inception Construction Transition

Continuous stream of development Stakeholder vision Sufficient functionality Proven architecture Production ready Delighted stakeholders F 10. T DAD L . http://disciplinedagileconsortium.org strategies should enhance the ability of DAD teams intelligence” approach supported via automated to deliver business value to their stakeholders in dashboards. a cost eff ec ve and mely manner. Unfortunately many exis ng IT governance strategies are based on a Being enterprise aware has several important implica ons command-and-control, bureaucra c approach which for the delivery lifecycle. First, to help teams understand o en proves ineff ec ve in prac ce. Chapter 20 of the the enterprise context that they operate in we should DAD book provides a comprehensive discussion of explicitly depict major collabora on fl ows with other agile governance [3]. parts of the organiza on. Figure 9 shows how to do so by • Open and honest monitoring. Although agile evolving the governed agile delivery lifecycle of Figure 4. Note that these fl ows are not necessarily ar fact based, approaches are based on trust, smart governance they may represent other forms of communica on such strategies are based on a “trust but verify and then as face-to-face discussion. guide” mindset. An important aspect of appropriate governance is the monitoring of project teams The second implica on is that one lifecycle does not fi t through various means. One strategy is for anyone all. We have worked with several organiza ons, some interested in the current status of a DAD project as small as thirty IT staff , that had teams that followed team to a end their daily coordina on mee ng very diff erent lifecycles. For teams that are new to agile and listen in, a strategy promoted by the Scrum the lifecycle of Figure 9 is a great place to start. But, community. Although it’s a great strategy that we because of the agile philosophy of ac vely striving to highly recommend, it unfortunately doesn’t scale very learn and improve your approach teams start to evolve well because the senior managers responsible for away from the Scrum-based lifecycle. It is common for governance are o en busy people with many eff orts them to realize that prac ces such as itera on planning, to govern, not just your team. Hence the need for itera on modeling, retrospec ves, and demos do not more sophis cated strategies such as a “development need to be on the same cadence, that instead they

12 Contents

Software Development Process

Agile Modeling

Model Driven Architecture

More UML Diagrams Traditional Development to MDA Traditional Development to MDA Traditional Development to MDA MDA

I Model Driven Architecture (MDA) → Derive code from models through transformations I Literature

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

Platform Independent Model (PIM): Example I: Attributes

Platform Specific Model (PSM) for Java:

Transformation PIM → PSM

I Introduce getter and setter methods for each attribute Example II: Associations

PIM: Example II: Associations

PSM for Java

Transformation PIM → PSM

I Introduce an attribute for a navigable association PIM for Rosa’s Breakfast Service MDA for Rosa’s Breakfast Service

I Three PSM’s

I Relational database model I Enterprise Java Beans implementation I Web interface PSM Relational database model PSM EJB PSM Web Interface Communication Bridge EJB relational DB Principles of MDA: Models Principles of MDA: Models Principles of MDA: Models Principles of MDA: Transformations Principles of MDA: Transformations Principles of MDA: Transformations

I Another example: Java Emitter Templates Transformations

I Standard transformations

I Customised transformations 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 MDA and Metamodels I MDA and Metamodels II

Short notation for the previous diagram MDA and Metamodels III

I UML: Meta Object Facility (MOF)

I EMF: Eclipse Modelling Framework

I 02162 Software Engineering II The MDA/MDA promise The MDA/MDA promise MDA

I Benefits

I Higher productivity I Portability I Interoperability I Maintenance and Documentation I Issues

I Modelling is abstraction

I Transformations need to add things I Multiple models

I Behavioural models Contents

Software Development Process

Agile Modeling

Model Driven Architecture

More UML Diagrams Object Diagrams Package Diagrams Deployment Diagram Object Diagram Example

Class Diagram Object Diagram Object Diagram Purpose

I Snapshot of a running system

I objects: Instance of a class I links: instance of an association

I Communication diagram Update operation of Account

State before executing update(n) State after executing update(n)

{n + b >= 0} a: Account bal = b + n

a: Account bal = b h1: History bal = b

prev h: History h: History bal = m bal = m Notation

I Variant 1: an object with name and class

I Variant 2: an anonymous object of a class

I Variant 3: a named object of unknown class Notation

I Value Specifications

I Slots

I Links to other objects Package Diagram

I Groups model elements: classes, objects, use cases, packages, . . . I Structures the model, not the system

I c.f. component diagram I Define a name space

I P::C means class C in package P → Java packages Package notation

I Notations for packages Examples

I Dependencies between packages Deployment Diagram

Martin Fowler, UML Distilled Next Week

I Validation of models: Model checking

I Summary of the course