02291: System IntegrationWeek 10

Hubert Baumeisterhuba@dtu.dk

DTU ComputeTechnical University of Denmark

Spring 2018

Last Week

I Principles of good design: layered architectureI Software Development ProcessesI Introduction to Examination Project

Contents

Software Development Process

Agile Modeling

Model Driven Architecture

More UML Diagrams

Resource Triangle

Plan Driven

D I TA

Time

Features

Release date

Agile

Database / Infrastructure Layer

Presentation Layer

Application Layer

Domain Layer

UserStory

UserStory

UserStory

eXtreme Programming (XP)I Kent Beck 1999I 12 Practices

Kent Beck, Extreme Programming 1st ed.

Scrum

Working incrementof the software

Sprint Backlog SprintProduct Backlog

30 days

24 h

file:///Users/huba/Desktop/Scrum_process.svg

1 of 1 /18.3.13 24:16

Wikipedia

I Robert Martin (Uncle Bob) about ”The Land that ScrumForgot”http://www.youtube.com/watch?v=hG4LH6P8Syk→ History about agile methods, the agile manifesto, and

Scrum and its relationshop to XP

Lean Software Development

I Lean Production:I Value for the customerI Reduce the amount of waste in the production processI Generate flow

I Waste: resources used which do not produce value for thecustomer

I time needed to fix bugsI time to change the system because it does not fit the

customers requirementsI time waiting for approvalI . . .

Generating flow using Pull and Kanban

WIP = Work in Progress Limit

1324

A T IWork Item DoneDQueue WIP Queue QueueQueue WIP WIP WIP

8

7

9

10

5

6

BlahComposite

Leaf Assembly4 2 3

3 3 3 3

Flow through Pull with Kanban

I Process controlling: local rulesI Load balancing: Kanban cards and Work in Progress

(WIP) limitsI Integration in other processes

Figure from David Anderson www.agilemanagement.net

Online Kanban Tool: Trello

I www.trello.com: Electronic Kanban board useful foryour 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 softwaredevelopment?

I XP and documentsI XP and modelling

→ Agile modelling

Agile Modelling

I Agile Modelling: values, principles, and practicesI References

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

Agile Modelling Values

I CommunicationI SimplicityI FeedbackI CourageI Humility

http://www.agilemodeling.com/values.htm

Agile Modelling Principles

I Core PrinciplesI Software is your primary goalI Enabling the next effort is your secondary goalI Travel lightI Incremental changeI Model with a purposeI Multiple models

. . .

Practices

I Core PracticesI Supplementary PracticesI Real Good Ideas

Core Practices

I Active Stakeholder ParticipationI Collective OwnershipI Model in Small IncrementsI Create Several Models in ParallelI Iterate to Another ArtifactI Display Models PubliclyI Model With OthersI Prove it With CodeI Use the Simplest ToolsI . . .

List of practices:http://www.agilemodeling.com/practices.htm

Disciplined Agile Development (DAD)I Hybrid Agile development method evolved from

I Agile ModellingI Agile Unified Process

I Based on

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

http://disciplinedagileconsortium.org

Iterative Processes: E.g. Rational Unified Process(1996)

DAD

Focus on complete lifecycle

A*High*Level*Lifecycle*

© Disciplined Agile Consortium 4

http://disciplinedagileconsortium.org

DAD

DAD + Lean

12

Options

Business Value

Expedite

Fixed Delivery Date

Intangible

Work items are pulled when

capacity is available to address them

Replenishment modeling session

Operate and

support solution in production

Enhancement Requests and Defect Reports

New features

Initial Require-ments

Initial Architectural Vision

Initial modeling,

planning, and organization

Daily work

Retrospective

Demo

Release solution into production

CoordinationMeeting

Construction Transition

Continuous stream of developmentStakeholder vision

Sufficient functionality

New features

Feedback

Learnings

Strategy

Inception

Production readyDelighted stakeholders

Proven architecture

Identify, prioritize, and select projects

Initial Visionand Funding

Envision the future

Business Roadmap, Technology Roadmap

strategies should enhance the ability of DAD teams

to deliver business value to their stakeholders in

a cost eff ec ve and mely manner. Unfortunately

many exis ng IT governance strategies are based on a

command-and-control, bureaucra c approach which

o en proves ineff ec ve in prac ce. Chapter 20 of the

DAD book provides a comprehensive discussion of

agile governance [3].

Open and honest monitoring.• Although agile

approaches are based on trust, smart governance

strategies are based on a “trust but verify and then

guide” mindset. An important aspect of appropriate

governance is the monitoring of project teams

through various means. One strategy is for anyone

interested in the current status of a DAD project

team to a end their daily coordina on mee ng

and listen in, a strategy promoted by the Scrum

community. Although it’s a great strategy that we

highly recommend, it unfortunately doesn’t scale very

well because the senior managers responsible for

governance are o en busy people with many eff orts

to govern, not just your team. Hence the need for

more sophis cated strategies such as a “development

F®¦çÙ� 10. T«� DAD L��Ä ½®¥��ù�½�.

intelligence” approach supported via automated

dashboards.

Being enterprise aware has several important implica ons

for the delivery lifecycle. First, to help teams understand

the enterprise context that they operate in we should

explicitly depict major collabora on fl ows with other

parts of the organiza on. Figure 9 shows how to do so by

evolving the governed agile delivery lifecycle of Figure 4.

Note that these fl ows are not necessarily ar fact based,

they may represent other forms of communica on such

as face-to-face discussion.

The second implica on is that one lifecycle does not fi t all. We have worked with several organiza ons, some

as small as thirty IT staff , that had teams that followed

very diff erent lifecycles. For teams that are new to agile

the lifecycle of Figure 9 is a great place to start. But,

because of the agile philosophy of ac vely striving to

learn and improve your approach teams start to evolve

away from the Scrum-based lifecycle. It is common for

them to realize that prac ces such as itera on planning,

itera on modeling, retrospec ves, and demos do not

need to be on the same cadence, that instead they

http://disciplinedagileconsortium.org

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 LiteratureI Anneke Kleppe, Jos Warmer, Wim Bast ”MDA Explained”,

2003, Addison Wesley ProfessionalI 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 → PSMI Introduce getter and setter methods for each attribute

Example II: Associations

PIM:

Example II: Associations

PSM for Java

Transformation PIM → PSMI Introduce an attribute for a navigable association

PIM for Rosa’s Breakfast Service

MDA for Rosa’s Breakfast Service

I Three PSM’sI Relational database modelI Enterprise Java Beans implementationI 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 transformationsI Customised transformations

Example Transformation

Transformation classes to DB schema (Pseudo Code)

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

then create a table representing the association class or theassociationand create foreign keys in both the table representing A andthe table representing B referring this new table

else if the multiplicity at one end is zero-or-onethen create a foreign key in the table representing the class

at that end, referencing the other endelse // the multiplicity of the association is one-to-one

create a foreign key in one of the tables, referencing theother end

endifendif

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 ModellingFramework

I 02162 SoftwareEngineering II

The MDA/MDA promise

The MDA/MDA promise

MDA

I BenefitsI Higher productivityI PortabilityI InteroperabilityI Maintenance and Documentation

I IssuesI Modelling is abstraction

I Transformations need to add thingsI Multiple models

I Behavioural models

Contents

Software Development Process

Agile Modeling

Model Driven Architecture

More UML DiagramsObject DiagramsPackage DiagramsDeployment Diagram

Object Diagram Example

Class Diagram Object Diagram

Object Diagram Purpose

I Snapshot of a running systemI objects: Instance of a classI links: instance of an association

I Communication diagram

Update operation of Account

State before executingupdate(n)

a: Account

bal = b

h: History

bal = m

{ n + b > = 0 }

State after executingupdate(n)

h1: History

bal = b

h: History

bal = m

a: Account

bal = b + n

prev

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 systemI c.f. component diagram

I Define a name spaceI 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 checkingI Summary of the course