19-design-rup-agile - umass amherst€¦ · 19-design-rup-agile readings ... what is polymorphism?...
TRANSCRIPT
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
19-Design-RUP-AgileReadings
OOAD Using the UMLCopyright 1994-1998 Rational Software, all rights reserved
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
So Where Were We?
Architect
ArchitecturalAnalysis
ArchitecturalDesign
DescribeConcurrency
DescribeDistribution
Review theArchitecture
DatabaseDesign
Use-CaseAnalysis
SubsystemDesign
ClassDesign
Use-CaseDesign
Review theDesign
Designer
DatabaseDesigner
DesignReviewer
ArchitectureReviewer
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Design Iterations•Architectural Design•decide what the infrastructure is (the pieces/parts of thearchitecture, if you will, and how they interact).
•Use Case Design•determine the responsibilities of the system are allocatedto the pieces/parts.
•Subsystem and Class design•detail the specifics of the pieces/parts.adjust the classes to the particular products in use, theprogramming languages, distribution, adaptation tophysical constraints (e.g. limited memory), performance,use of component environments such as COM orCORBA, and other implementation technologies
There is frequent iteration between Class Design,Subsystem Design, and Use Case Design.
ArchitecturalDesign
DescribeConcurrency
DescribeDistribution
SubsystemDesign
ClassDesign
Use-CaseDesign
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Class Design StepsCreate Initial Design ClassesDefine OperationsDefine StatesDefine AttributesDefine Associations Define Generalizations
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 3
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
•attribute (field) visibility: B is an attribute of A•remains an association
•parameter visibility: B is a parameter of a method A•becomes a dependency
•local visibility: B is a (non-parameter) local object in amethod of A
•becomes a dependency•global visibility: B is in some way globally visible
•becomes a dependency
Define Dependencies
+ notifyOfferingSelection(offering : CourseOffering)
Global visibility
Field visibility -> association
Local visibility -> dependency
MainStudentForm
+ registerForCourses()
(from Student Interface)
<<boundary>>
ICourseCatalog(from CourseCatalog)
<<Interface>>
RemoteRegistrationController
+ getOfferings(curriculum)
+ saveSchedule(theSchedule : Schedule)
(from Registration)
Naming
+ lookup()
(from java.rmi)
RegistrationController
getOfferings(curriculum)notifyOfferingSelection(offering : CourseOffering)new(context : SecureUser)saveSchedule(sched : Schedule)cancelSchedule(sched : Schedule)
<<control>>
1
1
Schedule<<entity>>
MaintainScheduleForm
displayOfferings()selectCurriculum() : CurriculumselectOffering() : CourseOfferingsave()cancel()update(changedItem : ISubject)displaySchedule()
<<boundary>>
1 1
0..1
1
0..1
0..1
Parameter visibility -> dependency
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Example: Composition
notifyOfferingSelection(offering : CourseOffering)
RegistrationController
getOfferings(curriculum)
new(context : SecureUser)saveSchedule(sched : Schedule)cancelSchedule(sched : Schedule)
<<control>>MaintainScheduleForm
displayOfferings()selectCurriculum() : CurriculumselectOffering() : CourseOfferingsave()cancel()update(changedItem : ISubject)displaySchedule()
<<boundary>>
1 1
association relationship has been refined into a composition relationship.MSF represents a sessionRC never exists outside of session
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 4
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Trucktonnage
GroundVehicleweightlicenseNumber
Car
owner
register( )
getTax( )
Person
0..*
Trailer
1ancestor
decendent
generalization
size
Generalization (Inheritance)One class inherits from another
not just finding common attribute, operations and relationshipsmore about the responsibilities and essence of the classes. avoid “skyscrapers”; the hierarchies should look like small,
independent “forests
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
What is Polymorphism?The ability to hide manydifferent implementationsbehind a single interface
Use generalization tosupport polymorphism
Tube
Pyramid
Cube
Shape
DrawMoveScaleRotate
<<interface>>
Animal
talk ()
Lion Tiger
talk () talk ()
Without Polymorphism With Polymorphism
if animal = “Lion” thendo the Lion talk
else if animal = “Tiger” thendo the Tiger talk
end
do the Animal talk
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 5
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Define Generalizations
MaintainScheduleForm(from Student Interface)
<<boundary>>ReportCardForm
(from Student Interface)
<<boundary>>
MainStudentForm(from Student Interface)
<<boundary>>
1
0..1
1
0..1
MaintainStudentForm(from Registrar Interface)
<<boundary>>MaintainProfessorForm
(from Registrar Interface)
<<boundary>>CloseRegistrationForm
(from Registrar Interface)
<<boundary>>
MainRegistrarForm(from Registrar Interface)
<<boundary>>
1
0..*
1
0..*
1
0..1 (from Professor Interface)SubmitGradesForm
<<boundary>>SelectCoursesForm
(from Professor Interface)
<<boundary>>
MainProfessorForm(from Professor Interface)
<<boundary>>
11
0..1 0..1
MainApplicationForm(from GUI Framework)
<<boundary>>LogonForm
(from GUI Framework)1 0..1
whycomposition?
whyaggregation?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
So Where Are We?
Architect
ArchitecturalAnalysis
ArchitecturalDesign
DescribeConcurrency
DescribeDistribution
Review theArchitecture
DatabaseDesign
Use-CaseAnalysis
SubsystemDesign
ClassDesign
Use-CaseDesign
Review theDesign
Designer
DatabaseDesigner
DesignReviewer
ArchitectureReviewer
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 6
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Strategy -- where are we?have defined subsystems, their interfaces, and their
dependencies as “containers” of complex behavior that, forsimplicity, we treat as a ‘black box’
made an initial cut at some design classes, which have beenallocated to subsystems
need to flesh-out the details of the internal interactionswhat classes exist in the subsystem to support?how do they collaborate to support, the responsibilitiesdocumented in the subsystem interfaces?In Subsystem Design, we look at the responsibilities of thesubsystems in detail, defining and refining the classes thatare needed to implement those responsibilities, refiningsubsystem dependencies, as needed. The internalinteractions are expressed as collaborations of classes andpossibly other components or subsystems
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
UML 2.0 changesUML 1.x
Subsystems were groupings of model elements representing abehavioral unit, offering interfaces and having operations.
Components were physical, replaceable parts of a system thatpackage implementation and provide the realization of a set ofinterfaces, and represented a physical piece of implementation of asystem (code, scripts, command files)
in UML 2Components are autonomous, encapsulated units within a system orsubsystem that provide one or more interfaces, and. implicitly, largerdesign units that represent things that will typically be implementedusing “replaceable" modules
Subsystems are specialized versions of a components classifier,inheriting all the same rules as the component notation element withthe only difference being the <<subsystem>> stereotype
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 7
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Interfaces & Subsystems (Components)What is an interface?
a model element which defines a set of behaviors (a set ofoperations) offered by a classifier model element (specifically,a class, subsystem or component)
What is a subsystem?Contains other model elements and has behaviorRealizes one or more interfaces
<<subsystem>>Finance System
FinancialTransaction
FinancialTransaction<<Interface>>
realizes
<<subsystem>>Finance System
Recall: packages provide no behavior; they are simply containers of things whichprovide behavior
UML 1.x
UML 2.0
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Distribute Subsystem Responsibilities
Identify or reuse existing classes and/or subsystemsAllocate subsystem responsibilities to classes and/orsubsystems
Incorporate the applicable mechanisms (e.g.,persistence, distribution, etc.)
Document collaborations with “interface realization”diagrams1 or more sequence diagrams per interface operation
Revisit Architectural DesignAdjust subsystem boundaries and/or dependencies, asneeded
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 8
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Client Support<<subsystem>>
Server Support<<subsystem>>
Moreflexible
Server
Client Support<<subsystem>>
Server Support<<subsystem>>
Server<<Interface>>Client
(from Client Support)
Describe Subsystem DependenciesSubsystem layering using direct dependency
Subsystem layering using interface dependency
Notrecommended
Abstract Interface
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Describe Subsystem Dependencies
ICourseCatalogRegistration CourseCatalog
<<subsystem>>
University Artifacts
RelationalDBMS
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
UML 2.0 dependencies
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Component Dependencies
©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition (1998)
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Component Diagram Detailed
©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition(1998)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
So Where Are We?
Architect
ArchitecturalAnalysis
ArchitecturalDesign
DescribeConcurrency
DescribeDistribution
Review theArchitecture
DatabaseDesign
Use-CaseAnalysis
SubsystemDesign
ClassDesign
Use-CaseDesign
Review theDesign
Designer
DatabaseDesigner
DesignReviewer
ArchitectureReviewer
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 11
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Strategy need to do some Use Case Design before Subsystem Design &
after Analysis and Architectural Designusually only have sketchy notions of responsibilities of classes andsubsystems
details need to get worked out in Use Case Design, before one isreally ready to design the classes and subsystems
where are we?made an initial attempt at defining the architecturedefined the major elements of our system
the subsystems, their interfaces, the design classes, the processes andthreads
relationships & how these elements map into the hardware on which thesystem will run.
now, concentrate on making sure that there is consistency from beginning to end of use case
implementation, i.e., that nothing has been missed (i.e., this is where wemake sure that what we have done in the previous design activities isconsistent with regards to the use case implementation).
Reminder: there is frequent iteration between Use Case Design,Subsystem Design and Class Design.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Use Case Design StepsDefine Interactions Between Design ObjectsRefine the Flow of Events DescriptionUnify Classes and Subsystem
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 12
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Review: Use Case Realization
Use Case Use Case Realization
<<realizes>>
Class Diagrams
Sequence Diagrams Collaboration Diagrams
Use Case RealizationDocumentation
Use Case Model Design Model
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Implementation (Construction)Source CodeBuild ScriptsUnit TestsTest Cases
System design
system designobject modeldesign goals subsystem
decomposition
Implementation
sourcecode Test
deliverablesystem
Object design
object designmodel
classdiagram
adapted from Bruegge/Dutoit O-O SW Engr
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 13
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Agile Methods - ReadingsGeneral
Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, and JuhariWarsta, "Agile software development methods: review and analysis,"www.inf.vtt.fi/pdf/publications/2002/P478.pdf
Barry Boehm, "Get Ready for Agile Methods, with Care," IEEEComputer, 2002. 35(1): p. 64-69 http://fc-md.umd.edu/projects/Agile/Boehm.pdf
XPExtreme Programming Explained, Kent Beck Addison Wesley 1999Refactoring: Improving the Design of Existing Code, Martin Fowler,Addison Wesley 1999
http://www.extremeprogramming.orghttp://www.xp2001.org
AOPAspect-Oriented Programming with AspectJ™ Erik Hilsdale, GregorKiczales (with Bill Griswold, Jim Hugunin, Wes Isberg, Mik Kersten),
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Agile Methods Agile methods
Adaptive Software Development (ASD), Agile Modeling, Crystal Methods,Dynamic System Development Methodology (DSDM), Extreme Programming(XP), Feature Driven Development, Lean Development, and Scrum
Plan-Driven Methods include: documented process procedures that involve tasks and milestone plans product development strategies that involve requirements, designs, and
architectural plans. Risk-driven spiral methods and frameworks
Rational UnifiedProcess (RUP), Model-Based Architecting and SoftwareEngineering (MBASE), and the CMMI
Boehm 2002
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 14
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Agile Methodsemphasize these values:
individuals and interactions over processes and toolsworking software over comprehensive documentationcustomer collaboration over contract negotiationresponding to change over following a plan
a method is agile when when software development isincremental (small releases with rapid cycles)cooperative (customers and developers work togetherand communicate closely)straightforward (easy to learn and modify)adaptive (changes can be made at last minute)
Highsmith and Cockburn 2001
Abrahamsson, et al 2002
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Risk ManagementTo determine risk exposure, RE, assess the probability of
loss, P(L), involved in a course of action, the correspondingsize of loss, S(L), and then computethe risk exposure as theexpected loss: RE = P(L) x S(L).
Loss can include profits, reputation, quality of life, or othervalue-related attributes.
risk exposure frominadequate plans as afunctionof the company’slevel of investment in itsprojects & process andproduct plans.
risk exposure frommarket share erosioncaused by delays inproduct introduction.
Boehm 2002
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 15
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Risk: Agile vs. Plan-Driven
agile home-ground company with asmall installed base and less need forhigh assurance.
plan-driven home-ground company thatproduces large, safety-critical systems.
Boehm 2002
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Extreme Programmingan example of an agile processshort-term emphasis
frequent releases, no pre-design, task lists, metaphorscustomer oriented
stories, use-cases, on-site customers, featurenegotiation
contributionspair-programming, test-first
applicabilitynew, high-risk, small-to-medium projects
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 16
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
XP Process (Abrahamsson, et al)
6 Phases: Exploration, Planning, Iteration, Productionizing,Maintenance, Death
XP Practices: Refactoring, Pair Programming, CollectiveCode Ownership, Continuous Integration, 40-Hour WorkWeek, On-Site Customer
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
CollectiveCode Ownership
Iteration
XP - another view (J. Donovan Wells)
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 17
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
XP PracticesRefactoringPair ProgrammingCollective Code Ownership
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
XP PracticesRefactoring
purpose is to improve the design of the code for greatercomprehension, preparation for added features, ease ofmaintenance, etc. without changing behaviorrefactorings include extracting methods, movingmethods in an inheritance hierarchy, etc.unit tests allows this to occur without danger
Why?cost of software change becomes higher when donelate in process.good design must anticipate future change. Makesdesign too complex.design should evolve.
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 18
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
RefactoringStrategy
disciplined technique for restructuring an existing body of code.alter structure, behavior unchanged.series of small behavior preserving transformations.each refactoring is small, less likely to go wrong.system kept working after each step.
Fowler’s catalog of common refactoringsmany refactorings can be automatedsome tools help the refactoring process..
YAGNI (“You Aren’t Going to Need It”)do extra work to get rid of architectural features that do notsupport the system’s current version.OK when future requirements are largely unpredictable, butwhere future requirements are predictable, throws away valuablearchitectural support & creates problems with customers whowant their priorities and evolution requirements accommodated
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
XP PracticesPair Programming
all production code is written by two programmerssitting at one machine; essentially, all code is reviewedas it is written.Helm – at keyboard and mouse doing implementationTactician – thinking about the implications and possibleproblems
Collective Code Ownershipno single person "owns" a moduleany developer is expect to be able to work on any partof the code base at any timeimprovement of existing code can happen at anytime byany pair
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 19
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
XP PracticesContinuous Integration
all changes are integrated into the code base at least dailythe tests have to run 100% both before and after integration.
40-Hour Work Weekprogrammers go home on time. in crunch mode, up to oneweek of overtime is allowed.multiple consecutive weeks of overtime are treated as a signthat something is very wrong with the process.
On-Site Customerdevelopment team has continuous access to a real livecustomer, that is, someone who will actually be using thesystem.for commercial software with lots of customers, a customerproxy (usually the product manager) is used instead
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Scrum empirical approach, appplying ideas of industrial process control
theory does not specify development techniques, but concentrates on
team members includes three phases: pre-game, development and post-game
30-day “Sprint”
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 20
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Crystal family of methodologies, select & tailor to fit
to project “color coded” to represent the “heaviness” of
the methodologyCrystal Clear - small projects (D6)Crystal Orange - medium-size projects (D40)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Is Open Source (OSS) Agile?OSS development differs from agile devlopment inphilosophical, economic and team structure aspects(Cockburn 2002)
however, there are some similarityearly and frequent releasesa lack of plan-based development features such asplans, system-level designs, schedules, definedprocesses
Phases (Sharma 2002): problem discovery; findingvolunteers; identifying solutions; code development andtesting; code change review; code commit; releasemanagement
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 21
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
The changing OSS environmentlarge companies (e.g., IBM) showing interest in OSSand beginning to serve as mediators (= managers?)
new service industries (e.g., Red Hat) providing supportrepositories (e.g., SourceForge) provide hosting,version control, bug tracking, project management,backups, archives
volunteer hirearchiesproject leaders, developers (senior/core, peripheral,occasional contributors), community input (users,posters)
market forcesdevelopers have to find interest and attract volunteers ina very harsh and competitive OSS environment
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Is RUP Agile?Contains extensive guidelines for process phases that may
be irrelevant in an agile approachThere are those that argue RUP can be made to be agile.As to the Agile principles, here are a few:
Active Stakeholder ParticipationRUP includes project stakeholders, such as users and customers,
but to be agile project stakeholders need to take on modelingroles
Collective OwnershipRUP supports collective ownership with its strong focus on
configuration management issues, although its changemanagement processes may potentially get in your way
Prove it With CodeAt the end of every iteration, except perhaps for the ones during
the Inception phase, RUP specifically states that you should havea working prototype.
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 22
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Agile vs. Plan-Based Methodsplan-based methods not used in practice?
too mechanistictoo hard to learnpotential adopters are skeptical
agile methodsbegan with agile manifestolack of empirical evidencenot applicable to large and/or critical projects?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Sawyer & Guinan 1998
Microsoft’s S&S ProcessS&S = “Synchronize and Stabilize”Strategy
Parallel development -- team structure parallels codestructureContinually testMetric data for milestone completionCommon developer languageDivide large projects into multiple milestone cyclesUse a vision statement and outline specification offeatures to guide projects
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 23
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Microsoft S&S Process
Vision StatementSpecification DocumentSchedule and Feature Team Formation
1 prog. mgr, 3–8 developers, and3–8 testers (who work in parallel 1:1with developers).
Planning
Development
Stabilization
Feature development in 3 or 4sequential subprojects
Subproject I First 1/3 of features(Most critical features and sharedcomponents)Subproject II Second 1/3 of featuresSubproject III Final 1/3 of features(Least critical)
Internal TestingExternal Testing (OEMs, ISVs, & endusers)Release preparation
Cusumano & Selby 1997
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
S+S Issuesbenefits
breaks down large products into manageable pieceslarge teams to work like small teams, proceeding in parallelbut synchronizing continuouslyfacilitates competition on customer input, product features,and short development timesallows a product team to be very responsive to events in themarketplace by “always” having a product ready to ship
problemsdoesn’t work for teams that are not co-locatedonly works for feature-driven developmentno built-in maintenance or support
planned as future versions of productmust have customer base to drive development decisions
Cusumano & Selby 1997
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 24
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Mary Shaw 2001
Process Model Comparison
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Agile and Other MethodsAgile
Adaptive Software Development (ASD), Agile Modeling,Crystal Methods, Dynamic System DevelopmentMethodology (DSDM), Feature Driven Development, LeanDevelopmentSee Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, andJuhari Warsta, "Agile software development methods: reviewand analysis," www.inf.vtt.fi/pdf/publications/2002/P478.pdf
Other “hot” technologyGenerative Programming, Meta Programming, ReflectiveProgramming, Compositional Filtering, AdaptiveProgramming, Subject Oriented Programming, IntentionalProgramming
Other ApproachesDesign by ContractAspect-Oriented Software Development
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 25
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Design by ContractOriginated by Bertram Meyer (Eiffel)
Incorporated in others methods (e.g., JML) and tools(e.g. Parasoft)
methodology for evolving code together with itsspecification.classes define their responsibility precisely.class invariants, method preconditions andpostconditions.compiler instruments code to monitor.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Preconditions and postconditionsClass to client: “If you promise to call r with pre satisfied, then I promise to
deliver a final state in which post is satisfied …” A method’s precondition
says what must be true to call it, I.e., what must hold upon entry to method binds the client.
A method’s normal postconditionmethod guarantees it will hold upon exitwhat is true when it returns normally (i.e., without throwing an exception).
A method’s exceptional postconditionwhat is true when a method throws an exception.
//@ signals (IllegalArgumentException e) x < 0; Class Invariants
Global properties of a class.Must be preserved by all exported routines.
Lecture 19 - RUP & Agile Processes November 16, 2002
© Rick Adrion 2005 (except as noted) 26
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
DBCThe role of a contract
may monitor at run time - debugging tool. eiffel - by the compiler. other languages - specific tools.
conceptual tool for correctness and robustness.design aid.aid to understandingdocumentation
advantagesclear responsibility for checking.run time violation shows a bug:
Precondition violation -- bug in client. Postcondition violation -- bug in supplier.
simplify code method need not check precondition. If precondition is not satisfied, do anything
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Contracts and inheritanceMethodological implications of contracts on inheritance:
Invariants and postconditions may only be strengthened;Preconditions may only be weakened.Eiffel enforces this principle..