02291: system integration · law of demeter law of demeter i ”only talk to your immediate...
TRANSCRIPT
02291: System IntegrationWeek 9
Hubert [email protected]
DTU ComputeTechnical University of Denmark
Spring 2018
Contents
Principles of Good Design
Software Development Process
Project Introduction
DRY principle
DRY principleDon’t repeat yourself”Every piece of knowledge must have a single, unambiguous,authoritative representation within a system.”The Pragmatic Programmer, Andrew Hunt and David Thomas
I codeI documentationI build stystem
Example: Code Duplication
Example: Code Duplication
Companynamec-address-streetc-address-cityprintAddress
Addressstreetc i typrintAddress
Companyname
Personnamecpr-number
works at
home address
address
Personnamecpr-numberhome-address-streethome-address-cityprintAddress
works at
DRY principle
I Techniques to avoid duplicationI Use appropriate abstractionsI DelegationI InheritanceI Classes with instance variablesI Methods with parameters
I Refactor to remove duplicationI Generate artefacts from a common source. Eg. Javadoc
KISS principle
KISS principleKeep it short and simple (sometimes also: Keep it simple,stupid)
I simplest solution firstI Strive for simplicity
I Takes time!!I refactor for simplicity
Antoine de Saint Exupery”It seems that perfection is reached not when there is nothingleft to add, but when there is nothing left to take away”.
YAGNI principle
YAGNI principleYou ain’t gonna needed it
I Focus on the task at handI E.g. using the observer pattern because it might be needed
→ Two different kinds of flexibilityI make your design changeable
I tests, easy to refactorI design for change
I Use good OO principlesI High cohesion, low couplingI Decentralized control
→ Both are needed, but focus on the first before introducingnot needed constructs for the second
Low Coupling
High coupling
A B
D E
C
F
Low coupling
A
B
D
E
C
F
Low Coupling
High coupling
A B
D E
C
F
Low coupling
A
B
D
E
C
F
High Cohesion
Low CohesionPerson
namecpr-numbercompanyNamework-address-streetwork-address-cityhome-address-streethome-address-city
High Cohesion
Addressstreetcity
Companyname
Personnamecpr-number
works at
home address
address
High Cohesion
Low CohesionPerson
namecpr-numbercompanyNamework-address-streetwork-address-cityhome-address-streethome-address-city
High Cohesion
Addressstreetcity
Companyname
Personnamecpr-number
works at
home address
address
Law of Demeter
Law of DemeterI ”Only talk to your immediate friends”I Only method calls to the following objects are allowed
I the object itselfI its componentsI objects created by that objectI parameters of methods
I Law of Demeter = low coupling→ delegate functionality→ decentralised control
Computing the price of an order
Order
calculate pricecalculate base pricecalculate discounts
Productnameprice
Customernamediscount info
OrderLinequantity
*
1
1
Computing the price of an order
Order
calculate pricecalculate base pricecalculate discounts
Productnamepriceget price for quantity
Customernamediscount infocalculate discount
OrderLinequantitycalculate price
*
1
1
Layered Architecture
Eric Evans, Domain Driven Design, Addison-Wesley, 2004
Example Vending Machine
Two different presentation layers
I Swing GUI
I Command line interfaceCurrent Money: DKK 5
0) Exit1) Input 1 DKK2) Input 2 DKK3) Input 5 DKK4) Select banana5) Select apple6) Cancel
Select a number (0-6): 5Rest: DKK 2Current Money: DKK 0Dispensing: Apple
Architecture
«abstract»Observable
VendingMachineUI VendingMachineTextUI
«enumeration»Fruit
APPLEBANANA
VendingMachine
dispensedItem : FruitcurrentMoney : inttotalMoney : intrestMoney : int
input(money : int)select(f : fruit)cancel()...
Observable
Presentation LayerPresentation Layer
Application Layer
«delegate»
Observer
«delegate»
«delegate»
Observer
Contents
Principles of Good Design
Software Development Process
Project Introduction
Success rate for software projects 2000—2008
Sheet1
Page 1
2000 2002 2004 2006 2008
succeeded 28% 34% 29% 35% 32%
failed 23% 15% 18% 19% 24%
challenged 49% 51% 53% 46% 44%
2000 2002 2004 2006 2008
0%
20%
40%
60%
80%
100%
120%
challenged
failed
succeeded
CHAOS Summary 2009 Report
I Succeeded: 32%I Failed: 20%I Challenged: 48% (over
time, over budget, lots ofdefects, low customersatisfaction. . . )
Failed or challengedI AmandaI RejsekortetI Obamacare WebsiteI German road toll systemI Denver airport baggage
systemI . . .
Scaling software development
Small hutI one personI no special knowledge
SkyscraperI not possible with one
personI special knowledge: static,
electricity, water, waste,elevator, . . .
Types of software (Lehmann)
I s-type: mathematical function, sorting: completespecfication
I p-type: real world problems, e.g., chess: modelling the realworld
I e-type: embeded into socio-technical systems.Requirements change as the environment changes.System changes the environment: e.g., operating system
I Continuing ChangeI Increasing ComplexityI Conservation of Organisational Stability (invariant work
rate)I Continuing GrowthI Declining Quality
Activities in Software Development
I Understand and document what the customer wants:Requirements Engineering
I How to build the software: DesignI Build the software: ImplementationI Validate: Testing, Verification, Evaluation→ Waterfall
Waterfall process
I 1970: Winston W. Royce how not to develop softwareI 1985: Waterfall was required by the United States
Department of Defence
Example: Empire State Steel Construction
From The EmpireState Building by JohnTauranac
From Building the Empire State by Willis,1998
I Kept the budgetI Was finished before
deadlineI Built in 21 month (from
conception to finishedbuilding) (1931)
→ Basic design in4 weeks
I Fast-track construction
→ Begin theconstructionbefore the designis complete
→ create a flow
Delays in waterfall processes
D I TA
Time
Features
Release date
Implementation by layers and not functionality
Costs of changing requirements: Waterfall
I Changed / new requirements change the design andimplementation
I Cost of change not predictable→ Avoid changing/new requirements if possible
→ Good for s-type projects, not applicable to p-type ande-type projects
Iterative Processes: E.g. Rational Unified Process(1996)
Agile Software Development Methods (1999)I Extreme Programming (XP) (1999), Scrum (1995–2001),
Lean Software Development (2003), . . .I Kanban (2010): not a method; tool to improve processes
Functionality
TimeAD IT
AD ITR
AD ITR
AD IT
R
AD IT
R
AD IT
R
F 1
F 2
F 3a
F 8
F 4
F 5
F 6
RAD IT
1. Iteration
Database / Infrastructure Layer
Presentation Layer
Application Layer
Domain Layer
UserStory
UserStory
UserStory
I Highest priority user storyfirst
I If delayed: importantfeatures are implemented
Problem in Software Engineering (Recap)
I Liggesmeyer 1998
Changing Requirements: Agile Methods
Scott Ambler 2003–2014 http://www.agilemodeling.com/artifacts/userStory.htm
I Cost of changeI New / changed requirements not done yet: zero costsI Changed requirements already done: the cost of a
requirement that can not be implemented
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 https://trello.com/b/4wddd1zf/kanban-workflow
Process for the exam project
1. Create workflows2. Create use case diagrams3. Select 6 use cases4. Determine basic (intended) architecture5. Pair modelling: 2 people work together→ https:
//trello.com/b/CqzwTiRT/02291-example-lean
I Meet often to coordinate the designI Update your plan, use cases, detailed use cases,
acceptance tests, etc. as needed→ Important for grading: models have to be consistent with
each other6. Check the acceptance tests and use case realization for all
use case scenarios
Important!
Report structure 6= project structureI Report structure: waterfall (by technique)I Project structure: agile (by user case scenario)
Contents
Principles of Good Design
Software Development Process
Project IntroductionDescription of the toll systemTaskOrganization
Exam Project: Model of a Toll System
I ReportI 45 min group presentation
A detailed project description can be found on CampusNet
Toll Lane
Toll Lane
Cash Register
Credit Card Reader
Printer
Single Ticket Reader
Toll Lane ComputerTouchscreen
Bank
))) (((
Antenna
1)
1)1)
1)
3) 2)
1) Only normal check-in lane2) Only normal check-out lane3) Only express lane (check-in and check-out)
Barrier
1,2,3)
1)
Toll Station
Toll Lane
Toll Station
Toll Lane
Toll Lane
Toll Lane
::
Station Server Station Client
Enterprise
Toll Station
Enterprise
Toll Station
Toll Station
Toll Station
::
Enterprise ServerEnterprise Client
Webserver
Functionality
I Check-inI Express Lane with toll tagI Normal Lane using a single ticket with cash / credit card
I Check-outI Express Lane with toll tagI Normal Lane using a ticket
I Buy Toll TagI Show ReportsI Change RateI Notify CustomersI Adminstration
Tasks
I TasksI Analyse the requirementsI Acceptance testsI Design the system: Components, Interfaces, PSM’s,
Classes, LSM’s, OCL constraintsI Use case realizations as sequence diagrams
I General remarksI Abstract from any physical implementation, e.g. embedded
system, communication protocol, . . .I Abstract away from any concrete user interface
representation: Application layer functionalityI Focus on the 6 use cases you have chosen
Evaluation Criteria
Evaluation CriteriaHow well are the learning objectives in the course descriptionaccomplished by each participant.
I Danish law: Be able to evaluate everybody individuallyI Two aspects:
a) to give a fair evaluation to each of youb) to be able to detect possible differences
→ For each section, diagram etc. name who did it (at mosttwo names)
I Make sure that everybody did something of everythingI In the project presentation: Everybody should have
I read the project reportI be able to explain each part of the model
Evaluation Criteria (cont.)
I Correct use of UML diagrams and OCL constraintsI Understandability of the designI Correct use case realizations that are consistent with the
LSM’s, PSM’s, classes, interfaces, etc.I Correct implementation of componentsI Correct object life cycle state machineI Appropriate abstraction level of the design
Organization
I Start: TodayI End: Wednesday 2.5I Upload the report as PDF and with the correct name on
Campus Net using the assignment moduleI Project presentations
I Mon 28.5—Tue 29.5I 45 min: around 10 min slides presentation; rest is Q&A
I Teaching assistants and I are available for questions /clarifications
I More detailed specification of the problem is on CampusNetI Lectures continueI No specific exercises, but exercise session 8:15—10:00 will
be kept for questions
Project: Rules on Cheating
Rules for Quoting (from Study Handbook Sect. 3.9)”. . . The rules regarding citations and references to sources inwritten assignments are that citations must be indicated byquotation marks at the start and end of the citation and thesource of the citation must be referred to either in parenthesesor in a note to the text. When not citing directly but basing thediscussion on a specific source, the source must be referredto either in parenthesis or a note to the text. . . . ”
→ Usual rules for referencing sources: sources must benamed
Course
I 2 more lecturesI Week 10: Model-driven architecture (MDA) and Agile
modellingI Week 11: Verification of models: Model checkingI Week 12: No lectureI Week 13: No lecture