19-design-rup-agile - umass amherst€¦ · 19-design-rup-agile readings ... what is polymorphism?...

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


So Where Were We?

Architect

ArchitecturalAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

Review theArchitecture

DatabaseDesign

Use-CaseAnalysis

SubsystemDesign

ClassDesign

Use-CaseDesign

Review theDesign

Designer

DatabaseDesigner

DesignReviewer

ArchitectureReviewer




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


SubsystemDesign

ClassDesign

Use-CaseDesign


Class Design StepsCreate Initial Design ClassesDefine OperationsDefine StatesDefine AttributesDefine Associations Define Generalizations




•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


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




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


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




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?


So Where Are We?

Architect


ArchitecturalDesign

DescribeConcurrency



DatabaseDesign

Use-CaseAnalysis

SubsystemDesign

ClassDesign

Use-CaseDesign

Review theDesign

Designer

DatabaseDesigner

DesignReviewer





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


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




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


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




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


Describe Subsystem Dependencies

ICourseCatalogRegistration CourseCatalog

<<subsystem>>

University Artifacts

RelationalDBMS




UML 2.0 dependencies


Component Dependencies

©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition (1998)




Component Diagram Detailed

©The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co; 1st edition(1998)


So Where Are We?

Architect


ArchitecturalDesign

DescribeConcurrency



DatabaseDesign

Use-CaseAnalysis

SubsystemDesign

ClassDesign

Use-CaseDesign

Review theDesign

Designer

DatabaseDesigner

DesignReviewer





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.


Use Case Design StepsDefine Interactions Between Design ObjectsRefine the Flow of Events DescriptionUnify Classes and Subsystem




Review: Use Case Realization

Use Case Use Case Realization

<<realizes>>

Class Diagrams

Sequence Diagrams Collaboration Diagrams

Use Case RealizationDocumentation

Use Case Model Design Model


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




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),


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




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


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




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


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




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


CollectiveCode Ownership

Iteration

XP - another view (J. Donovan Wells)




XP PracticesRefactoringPair ProgrammingCollective Code Ownership


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.




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


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




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


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”




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)


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




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


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.




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?


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




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


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




Mary Shaw 2001

Process Model Comparison


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




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.


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.




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


Contracts and inheritanceMethodological implications of contracts on inheritance:

Invariants and postconditions may only be strengthened;Preconditions may only be weakened.Eiffel enforces this principle..

19-design-rup-agile - umass amherst€¦ · 19-design-rup-agile readings ... what is polymorphism?...

Documents