Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
02291: System IntegrationWeek 10
Hubert [email protected]
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