12/01/2012

M.Sc ComputerScience

Resources
Textbooks: ApplyingUMLandPatterns;AnIntroductiontoObject OrientedAnalysisandDesignandIterativeDevelopment, CraigLarman,3rd edition,PrenticeHall2002 DesignPatterns.ElementsofReusableObjectOriented Software.E.Gamma,R.Helm,R.Johnson,J.Vlissides. LectureNotes: http://www.dcs.bbk.ac.uk/~oded

ObjectOrientedDesignandProgramming Session1

Oded Lachish
Room:(FTsession)Malet 40413:3017:00,(PTSession)Malet 40718:0021:00 VisitingHours:Tuesday17:00to19:00 Email: [email protected] WebPage:http://www.dcs.bbk.ac.uk/~oded/OODP12/OODP2012.html

OODesignandProgramming
Mainobjectives: Anintroductiontosoftwareengineering.

Congratulations NewJob
Youarenowresponsiblefordevelopinganewsoftware productfromscratch

Whatwillwesee: Objectorientedanalysisanddesign(OODP) methodologies. UMLforillustratinganalysisanddesignmodels. DesignPatterns Refactoring

Great,
whatnext? IknowC++,Java,UML?

Howdoyoudevelopsoftware?
Me? Iwritethecode, allofit compile ANDITWORKS

TestDrivenDevelopment(TDD)
Philosophy
Untestedcodeisnotcode Shortdevelopmentcycle Testingisunderstanding

EVERYSINGLETIME
(thatiswhyIteach)

You?

12/01/2012

TDDCycle
Write Test Pas s Run Test Write Production Code
Refactor

TDDbenefits
LessDebugging(debuggingistediousandexpensive) Smallsteps easiertobacktrack(lessdebugging)
Fai l Run All Tests Write Code Properly Fai l Run All Tests

Smallpiecesdrivedeveloperstowardsmodularity Bugscaughtearlier Testingisunderstanding

Fai l

New feature, write a test to make sure you understand Test should fail, since there is no implementation 7

Pas s

TDDvulnerabilities
Developerwritingtestsforhisowncode Checkingprivatevariablesmayrequirededicatedhacks thatmayremaininthecode. Morecode Longertimetowrite Overrelianceonunittesting

TDDimplementation
WishList Easytoupgradecode(refactor) Dedicatedtestingtools Friendlyversioncontrol

1 0

Examplesofsoftwareproducts
Realtime: Embeddedsystems: Dataprocessing: Informationsystems: Sensors: Systemsoftware: Communications: Offices: Scientific: Graphical: etc. airtrafficcontrol digitalcamera,GPS telephonebilling,pensions websites,digitallibraries weatherdata operatingsystems,compilers routers,mobiletelephones wordprocessing,videoconferences simulations,weatherforecasting filmmaking,design

SoIKnowTDD CanIStart

12/01/2012

Puttingsoftwareproductioninperspective
Biggestprogramthatyouhavewritten? Biggestprogramthatyouhaveworkedon? Biggestprojectteamthatyouhavebeenpartof? Longestprojectthatyouhaveworkedon? Mostpeoplewhohaveusedyourwork? Longestthatyourprojecthasbeeninproduction? ThecourseworkforOODPshouldbeabout0.01personyears. Abigprojectmaybe100to1,000+personyears. Softwareproductionrequiresteamwork. Largesoftwareprojectsarebuiltonolderones. Softwareisexpensive.

Whatmakesgoodsoftware?
Relevance Usability Robustness Faulttolerance Maintainability Efficiency Theemphasisonthesemetricsvariesacrossprojects.

So?
Thenumberofpossibletasksseemsunbounded Thescaleofsometasksisimmense Therecanbemanydifferentqualityconstraints

What is software engineering?

Asystematicapproachisrequired! SoftwareEngineering

Software engineering is not just coding

KnowinganOOlanguage,likeJavaorC++,isnecessary,butnot sufficientinordertocreateobjectsoftware. Inbetweenaniceideaandaworkingsoftware,thereismuch morethanprogramming.
Engineers, Managers, Clients, Users
Analysis Design Programming

WhatNext?
Isthereamagicbookthatwillensuresuccess?

Regretfullyprobablyno.
Alargevarietyofentitiessome withmassiveresourceshave

Investigation of the problem

Logical solution

Code

failedmiserably!
DesignPatterns Verification

12/01/2012

SoBUZZWORDS

Start from the beginning

InthebeginningtherewasCHAOS Softwareiswrittenonthefly SystemsGrow Bugs verificationtakesforever Maintenancevirtuallyimpossible

(very partial history)

EngineeringMethodologies

Agile

Plan beforebuilding Predictable,Efficient

The (classical) waterfall model

Feasibility study Requirements System design Program design Coding Testing Acceptance testing
Next phase only after previous is 100% percent done!

Why waterfall model?

Emphasisondocumentation knowledgenotlost, lessdependenceonteammembers Predictproblemsanddealwiththemasearlyaspossible Simplestructuredapproach

Operation & maintenance

(Likeinotherengineeringareassuchasconstruction)

The (classical) waterfall model

Feasibility study Requirements System design Program design Coding Testing Acceptance testing Operation & maintenance

So?

Acceptthat
Requirementsmaychange Systemdesignproblemsmayariseduringprogramdesign Programdesignproblemsmayarisewhencoding

What are the problems with the waterfall model?

Needadesignmethodologythatcandealwiththeseproblems.

12/01/2012

AgileSoftwareDevelopment
A group of software development methodologies

ManifestoforAgileSoftwareDevelopment
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Focus: THE BIG PICTURE

Individuals and interactions over processes and tool Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Everything is personal

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

PrinciplesbehindtheAgileManifesto
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

PrinciplesbehindtheAgileManifesto
Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

Thebigconceptualchanges
Software development methodologies that are

Iterative,Incremental,Interactive
Customer

1. Iterative 2. Incremental 3. Interactive

(Treat software development as a learning process)
Skeleton

Interaction

Complete Product

TIME

12/01/2012

Agile Software Development Processes

Whatdowewant?
AsoftwaredevelopmentFRAMEWORKthatdealswith Analysisanddesign Objectorientedtechnology Welldefined Cleardocumentationandsharingofinformationduring softwaredevelopment Reusability Verification Testing

Extreme Programming Test-driven development Continuous integration Scrum war room common project room Daily meetings

Bothverticalandhorizontalpartition
Customer

Interaction

Complete Product

UP UnifiedProcess

Skeleton

TIME

UnifiedProcess(UP)
TheUnifiedProcessisaprocessframeworkparticularlysuited forbuildingOOsystems. RationalUnifiedProcess(RUP)isadetailedrefinementofUP

WhyUP?

Iterativeandevolutionary(incremental)development contrastedwithasequentialorwaterfalllifecycle. Earlyprogrammingandtestingofapartialsystem,in repeatingcycles. Itassumesdevelopmentstartsbeforealltherequirements aredefinedindetail. Feedbackisusedtoclarifyandadaptthesystemtoevolving specifications

WhyusetheUnifiedProcesstodevelopsoftware?

12/01/2012

The UP iterative development

Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1 Iterations are fixed in length - Outcome is a tested, integrated and executable partial system.
Requirements Analysis & Design Implementation Testing & Delivery Time Requirements Analysis & Design Implementation Testing & Delivery

UP phases
Inception Feasibility phase and approximate vision Elaboration Core architecture implementation, high risk resolution Construction Implementation of remaining elements Transition Beta tests, deployment

Iteration N

Iteration N+1

UP phases
Increment
Difference between two consecutive iter.

UP artifacts and disciplines

The UP describes work activities, which result in work products called artifacts. Examples of artifacts: Code Web graphics Database schema Use cases (text documents explaining business scenarios) Diagrams, models and so on A discipline (or workflow) is a set of work activities. Examples: Requirements Business modeling Design

Release
After each iteration

Final Release!
Construction Iteration 5 Construction Iteration 6 Construction Iteration 7 Construction Iteration 8 Transition Iteration 1 Transition Iteration 2

Milestone
Elaboration Iteration 1 Elaboration Iteration 2 Elaboration Iteration 3 Construction Iteration 1 Construction Iteration 2 Construction Iteration 3 Construction Iteration 4

TIME

Inception

Inception
(Usually,lastsoneortwoweeks(e.g.oneiteration))

Inception

Definethevisionandbusinessscopeoftheproject Definehighlevelgoalsandconstraints Investigatecorerequirements Studyfeasibility Identifycritical(business,technical,schedule,)risks Obtainanorderofmagnitudeestimateofthecost Determinewhowilldoit(buyand/orbuild) Decideifitisworthwhiletoinvestindeeperexploration Planthefirstiterationofelaboration Estimatethenumberofiterationsneededforelaboration

12/01/2012

Artifacts thatmaybestartedduringinception:
Artifact
Vision and Business Case Use-Case Model Supplementary Specifications Glossary Risk List and Risk Management Plan Prototypes and Proof-of-Concepts Iteration Plan
Phase Plan & Software Development Plan Development Case

Description
High level goals and constraints Functional requirements Non functional requirement
Key domain terminology, and data dictionary

Requirements

Risks and their mitigations Validating technical ideas Description of first iteration Guess for elaboration duration. Tools etc. Description of the Customized UP

Importanceofrequirementsspecification
Factors on challenged software projects
Poor user input 13%

Requirements
Requirementsarecapabilitiesandconditionstowhichthe system andmorebroadly,theproject mustconform.Either deriveddirectlyfromuserneeds,orstatedinacontract, standard,spec,formallyimposeddocument. TheFURPS+model[Grady92]: Functional quality requirements

Incomplete requirements 12% Other 50% Changing requirements 12% Poor technical skills 7% Poor staffing 6%

37% of factors are related to requirements

Usability Reliability Performance Supportability

nonfunctional requirements

The UP embraces changes in requirements and suggests their skilful specification through use-case writing.

+:{implementation,interface, operations,packaging,legal}

+
Implementation
Required standards, implementation languages, resource limits.

Examples
The project will be localised (support multiple human languages) The persistence will be handled by a relational database. The database will be Oracle 9i. The system will run 24x7 All presentation logic will be written in Visual Basic.

Interface
Specifies external items with which the system must interact

Physical
Constraints the hardware used to house the system, shape, size or weight for example.

Legal
Licensing etc

12/01/2012

Vision,Supp.Spec.andGlossary

Vision, Supplementary Specification and Glossary

The Vision includes the big ideas regarding why the project was proposed, what the problems are, who the stakeholders are, what they need, and what the proposed solution looks like. The Supplementary Specification captures non-functional requirements, e.g. documentation, packaging, supportability, licensing etc. The Glossary is like a data dictionary; it defines terms used in other artifacts (use cases, SS, vision etc.). Suggestion: start the glossary early!

A(partial)Visionexample
Revision History: (version, date, description, author) Introduction: We envision a fault-tolerant point-of-sale appl. With the flexibility to support varying business rules and integration with multiple third-party supporting systems. Positioning: Business Opportunity: (what existing systems cant do) Problem Statement: (problems caused by lack of features) Product Position Statement: (who the system is for, outstanding features, how is it different from competition) Stakeholder Descriptions: Stakeholder (non-user) summary: Stakeholder goals: User summary (and their goals): User-level goals: Product Overview: Product perspective: Product benefits: Cost and Pricing: Licensing and Installation: Summary of System Features: Other Requirements and Constraints:

A(partial)SSexample
Revision History: (version, date, description, author) Introduction: This document is the repository of all requirements not captured in the use cases. Functionality: Logging and Error Handling: Log all errors to pers. storage Pluggable Business Rules: Customize functionality Security: All usage requires user authentication Usability: Reliability: Performance: Supportability: (Adaptability: and Configurability:) Implementation Constraints: Java technology solution Purchased Components: Tax calculator. Interfaces: (Hardware: and Software:) Domain (Business) Rules: (id, rule, changeability, source) Legal Issues: Information in Domains of Interest: (pricing, sales tax, item ids)

DescriptionofFunctionality
Problem

UseCases

TheClientsarenotengineers ThrowingUMLdiagramsatthem,isatbestconfusing Goodcommunicationswiththemiscritical!

HOW?

12/01/2012

Theusecasemodel[Jacobson92]
Theusecasemodel thesetofallusecases isanartifact withintherequirements disciplineoftheUnifiedProcess. Usecases arestoriesofusingasystemtomeetgoals.

Usecaseswhatforandwhy?
Whatfor? Todescribehowthesystemwillbehave

Why? Usecaseexample(inbriefformat):
Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the system to record each purchased item. The system presents a running total and lineitem details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt and leaves with items.

Simple,easytocommunicate Replacetheoldfeaturelist,withsomethingthat relatestothestructureoftheproblem

Agoodwayofunderstandinganddescribingrequirements(esp.functionalones).

Guidelinesforwritingusecases
Trytoanswerthequestion:Howcanusingthesystemprovide observablevaluetotheusersorfulfiltheirgoals? Dontthinkofsystemrequirementsintermsofachecklistof featuresorfunctions. Emphasizethefunctionalrequirements(otherrequirement typesaresometimesincluded,buthaveasecondaryrole). Text,notdiagrams. Blackbox usecasesarehighlyrecommended.Wedescribethe responsibilitiesofasystem,nottheinternalworkings.
ProcessSale: Thesystemrecordsthesale NOT:ThesystemgeneratesanSQLINSERTstmtforthesale

Usecaseformats
Brief: oneparagraphdescribingthemainsuccessscenario
Previously

Casual: multipleparagraphsthatcovervariousscenarios Fullydressed: ColemansUseCaseTemplate

Next

Alreadyhavebriefandcasualusecases
Anactor issomethingwithbehaviour,suchasaperson, computersystem,ororganization;e.g.acashier. Ascenario alsocalledusecaseinstance isaspecific sequenceofactionsandinteractionsbetweenactorsandthe systemunderdiscussion.Itisonepaththroughtheusecase. Ausecase isacollectionofrelatedsuccessandfailure scenariosthatdescribeactorsusingasystemtosupportagoal.
ProcessSale MainSuccessScenario: Acustomerarrivesatacheckoutwithitemsto purchase AlternateScenarios: Ifthesystemrejectscustomerscreditcard Ifthecustomerhaslesscashthantherequiredpayment

Actors?
Actor anythingwithabehaviour(includingthesystemunder discussionifitrequiresothersystems)

Primaryactor hasgoalsfulfilledbySuD. SupportingActor serviceprovider,information. Offstageactor anyonewithaninterestintheSuD thatisnot oneoftheabove,HMRC,...

10

12/01/2012

ColemansUseCasetemplate
Fields UseCase Description Actors Assumptions Steps Variations (optional) NonFunctional (optional) Issues Description Usecaseidentifierandreferencenumberandmodification history. Goaltobeachievedbyusecaseandsourcesfor requirement. Listofactors(primary,secondary)involvedinusecase. Conditionsthatmustbetrueforusecasetoterminate successfully. Interactionsbetweenactorsandsystemthatarenecessary toachievegoal. Anyvariationsinthestepsofausecase.

Steps
1. 2. 3.
Astepcompleteswhenallitsinteractionshavecompleted. Eachstepiscompletedbeforethenextisstarted.

<sequencenumber><interaction> Interactiona interactionb IFtestTHEN 3.1interactiona 3.2interaction ELSE3.3interactionb

4.
Listofnonfunctionalrequirementsthattheusecasemust meet. Listofissuesthatremaintoberesolved

REPEAT

4.1interactiona 4.2interactionb

UNTIL nomore

Steps

Variations

Concurrency 1.INPARALLELinteractiona||interactionb||interactionc 2.Interactiond 1.INPARALLEL1.1interactiona||1.2interactionb||1.3

interactionc

1. Buyercallsinwithpurchaserequest # 1.Buyermayphonein,or faxin,or useweborder

form. Nonfunctionalrequirements <keyword>:<requirement> Performance,Reliability,FaultTolerance,Frequency, Priority

2.Interactiond

Example1
UseCase Description Assumptions Actors 2.Repairing_Cellular_Network historycreated1/5/98DerekColeman,modified5/5/98. Operatorrectifiedareportbychangingparametersofacell. sources [OperatingManual1993],[Jones1998] Changestonetworkarealwayssuccessfulwhenappliedtoa network. Operator(primary) Cellularnetwork Fieldmaintenanceengineer(secondary) 1. Operatornotifiedofnetworkproblem 2. Operatorstartsrepairsession 3. REPEAT 1. Operatorrunsnetworkdiagnosisapplication 2. Operatoridentifiedcellstobechangedandtheirnew parametervalues. 3. INPARALLEL 1. Maintenanceengineertestsnetworkcells|| 2. MaintenanceEngineersendsfaultreports. UNTILnomorereportsofproblems. 4. Operatorclosesrepairsession

Example1(cont)
Variations #1SystemmaydetectfaultandnotifiyoperatororField maintenanceengineermayreportfaulttoOperator. NonFunctional PerformanceMean:timetorepairnetworkfaultmustbelessthan3 hours. Faulttolerance:Arepairsessionmustbeabletotoleratefialureof Operatorsconsole. Issues Whatarethemodesofcommunicationbetweenfieldmaintenance engineerandoperator?

Steps

11

12/01/2012

Uses Relationship

Uses example
Using a sub- use case in a step is expressed by a keyword such as PERFORM (or USING). For example, if Tune_Cell were a use case it could be used by the following interaction:

In UML, commonalties between use cases are expressed with the uses relationship. The relationship means that the sequence of behaviour described in a used (or sub) use case is included in the sequence of the using use case. Using a use case is thus analogous to the notion of calling a subroutine. Sub use cases are full use cases in their own right, and therefore can be expressed using the use case template.

3. Operator PERFORMS 2.1 Tune_Cell

In allocating reference numbers to use cases it maybe convenient to use a Dewey Decimal numbering scheme to convey the using hierarchy. Thus if use case W, with reference number n, uses three sub use cases X, Y and Z, then X may be numbered n.1, Y n.2 etc.

ExtendingaUseCase
UseCaseExtension Description/Change Steps Variations(optional) Nonfunctional(optional) Issues <extensionidentifier>extends<usecaseidentifier> Goaltobeachievedbyextension Changestousecasesteps

Example2
UseCase Descirption Actors Assumptions Steps 1.Process_Sale AuserarrivesataPOSsalespointandtriestopurchaseanitem. Cashier(Primary) Cashierisidentifiedandauthenticated 1. CustomerarrivesatPOScheckoutwithgoodstopurchase. 2. Cashierstartsanewsale. 3. REPEAT 1. Cashierentersitemidentifier. 2. Systemrecordssalelineitemandpresentsitem description,priceandrunningtotal. UNTILEMPTY_BASKET 4. Systempresentstotalwithtaxescalculated. 5. CashiertellsCustomerthetotal,andasksforpayment. 6. CustomerpaysandSystemhandlespayment. 7. SystemupdatesAccountingandInventorysystems. 8. Systempresentsreceipt. 9. Customerleaveswithreceiptandgoods(ifany).

UseCaseExtension Description/Change Steps Issues

<Repair_may_fail>extends <2.Repairing_Cellular_Networks> Dealswithassumptionthatnetworkchanges canneverfail. #3.3if changestonetworkfailthen thenetwork isrolledbacktoitspreviousstate Howarefailuresdetected?Arerollbacks automaticorisOperatorinterventionrequired?

Extensions?

Extensions
*a.Atanytime,Systemfails: Ensurealltransactionstatesarerecoverable. 1.Cashierrestartsthesystem,logsin,andrequestsrollback.

Canyouthinkofusefulextensions (alternativeflows)thatarenotcoveredby theusecase?

2.Systemrollback. 3a.Invalididentifier: 1.Systemsignalserrorandrejectsentry. 3b.Therearemultipleofsameitemcategoryandtrackinguniqueitemidentitynot important. 1.Cashierentersitemcategoryidentifierandthequantity. 36a.CustomertellsCashiertocancelsale: 1.CashiercancelssaleonSystem.

12

12/01/2012

Actorgoallists
Actor Goal
processsales handlereturns cashin cashout startup shutdown

Actor
System Administrator

Goal
addusers modifyusers deleteusers analyzesales

Whatdowedo withalltheusecases?

Cashier

Manager

SalesActivity System

Whathappenedininception?
Ashortrequirementsworkshop Mostactors,goalsandusecasesnamed Mostusecaseswritteninbriefformat;1020%ofcaseswritten infullydressedformat Mostinfluentialandriskyqualityrequirementsidentified FirstversionoftheVisionandSSdocuments Userinterfaceorientedprototypestoclarifythevisionof functionalrequirements Recommendationsonwhatcomponentstobuy/build/reuse Planforthefirstiterationofelaboration

Summary
TheUseCaseModelisanartifactoftheRequirements disciplinethatincludes: writingusecasesanddesigningusecasediagrams(during InceptionandElaboration) designingsystemsequencediagrams(inElaboration) Vision,SSandGlossaryareotherartifactsoftheRequirements discipline,whichstartinInceptionandarefurtherrefinedin Elaboration. 1020%ofrequirementsaredefinedindetailbytheendofthe Inceptionphase. Almostallrequirementsaredefinedindetailbytheendof Elaboration.

13