Med4 Aalborg Object-Oriented Analysis, Design and Programming

1
Med4 AalborgObject-Oriented Analysis, Design and
Programming

• Development Process
• (Based on Stevens and Pooley (2006, Chapter 4)
  and Fowler (2004, Chapter 2))

David Meredith dave_at_create.aau.dk
2
How do we build good, large systems?

• Large project may take several people several
  months or years to complete
• Dont just tell them to deliver product when its
  finished
• Might tell them we want part A finished in 1
  month, part B finished after 2 months etc.
• Large projects should be broken down into short
  phases with unambiguous milestones
• How do you eat an elephant?
• One spoonful at a time!

3
The need for a plan

• Large project has to follow a plan
• So can evaluate what has been achieved
• Determine whether project is on schedule and
  within budget
• Need to systematically document project
• So that people can join and leave mid-way through
• So that system can be maintained when it is
  delivered
• Usually use a development process or methodology
  to manage a large software project

4
Development process and methodology or method

• Development process
• The type of plan and way of working adopted
  within a particular software project
• The rules that define how project carried out
• Describes documents, design models and artifacts
  that should be delivered and in what order
• Methodology, method
• techniques for developing design models
• usually specifies modelling language to be used
  (e.g., UML)
• specifies method for capturing user requirements

5
Model

• an abstract representation of a specification, a
  design or a system, from a particular point of
  view
• usually expressed using diagrams
• represents essentials of a particular aspect of a
  system or project without irrelevant details
• allows team members to focus on a particular
  aspect of project without getting side-tracked
• purpose of model is to communicate
• a model must have a precise and well-understood
  meaning

6
Modelling language

• Way of expressing the different models used in a
  project
• Defines collection of model elements which are
  the building blocks of the models we construct
• Modelling language is usually diagrammatic
• in which case, model elements will be graphical
  elements of diagrams (e.g., types of arrow, types
  of box, etc.)
• Modelling language has syntax and semantics
• Syntax
• rules governing how the model elements can be put
  together to make legal models
• Semantics
• rules governing how a legal diagram should be
  interpreted

7
What makes a good modelling language?

• Sufficiently expressive
• need to be able to use the language to express
  those aspects of the project and system that we
  need to discuss and describe
• Easy to use
• needs to aid development, not hinder it
• Unambiguous
• model must have a precise meaning so everyone
  interprets it in the same way
• Widely used
• so that people in the industry can understand a
  model even if they are new to a project

8
Waterfall process

• Software life-cycle broken down into 5 large
  phases
• Assumes that once a phase has ended, we never
  return to it
• This is nearly always impossible because we dont
  always make the right decisions
• e.g., if requirements change during testing, we
  have to revisit the analysis and design phases
• Waterfall process doesnt work because we always
  need to be able to revise earlier decisions

9
Iterative process

• Every decision involves taking a risk - the risk
  that the decision is the wrong one!
• Need to manage such risks in a software project
• The more you build on a decision, the harder it
  is to go back and change it, if it turns out to
  be wrong
• Need to find out as soon as possible whether or
  not a decision is right
• do this by having frequent evaluation steps
  during the development process
• One of the biggest causes of failure in software
  projects is requirements change or
  misunderstanding
• Users find it easier to criticise a working
  system than to imagine a perfect one
• better to present users with prototypes for
  evaluation during the development process

10
A simple spiral process
See Boehm, B. (1988). A spiral model of software
development and enhancement. IEEE Computer,
21(5) 6172.
Engineer design, implement, test
Evaluate
Analyse requirements for this iteration
Analyse risks and plan
11
Iterative process

• Decomposes software into subsets of functionality
• Does complete software life-cycle for each subset
  of functionality before going on to the next
• Production quality software produced on each
  iteration
• Beware of pseudo-iterative development process
• "We are doing one analysis iteration followed by
  two design iterations..."
• "This iteration's code is very buggy but we'll
  clean it up at the end."

12
Time-boxing

• An iteration is forced to be of a fixed duration
• If necessary, must sacrifice functionality, not
  quality or delivery
• Learning to sacrifice functionality is good
  practice for when have to decide at big release
  between sacrificing functionality or delaying
  release
• Helps developers to prioritise requirements and
  identify what is really necessary

13
Rework

• Iterative development implies reworking and
  deleting existing code
• Seen as bad in manufacturing
• But in software engineering, rework is not
  necessarily bad
• Often easier and less error-prone to rework code
  than patch badly-made existing code
• Be prepared to throw one away (Brooks, 1975)

14
Making rework more efficient

• Automated regression
• Detecting defects introduced by changes
• See www.junit.org
• Refactoring (Fowler, 1999)
• Change existing software by making a series of
  small behaviour-preserving transformations
• Transformations can be automated
• See www.refactoring.com
• Continuous integration
• www.martinfowler.com/articles/continuousIntegratio
  n.html
• automatic build (including test) each time a team
  member checks code into the code base

15
Hybrid development processes

• Neither waterfall nor iterative processes are
  ever pure
• Always some back-flow in the waterfall process
• e.g., need to revisit design half way through
  implementation
• Exploratory phase before first iteration in an
  iterative process
• To get high-level view of requirements
• Usually non-iterative phase at end of iterative
  development for user training, ironing out final
  bugs, etc.
• Hybrid development processes
• e.g., Rational Unified Process

16
What is a good development process?

• Uses iteration to manage risk
• Supports architecture-centric, component-based
  design
• Has high level of user involvement
• Should be use-case driven
• Should allow users to evaluate prototypes and
  partial solutions frequently

17
(Rational) Unified Process (RUP)

• Proposed by
• Jacobson, I., Booch, G. and Rumbaugh, J. (1999).
  The Unified Software Development Process.
  Addison-Wesley.
• Accepts the need for non-iterative preliminary
  phase for planning, risk-assessment and
  high-level requirements capture
• Accepts the need for non-iterative phase at the
  end of a project for deploying software, training
  users and ironing out final bugs
• RUP is not a process it is a process framework
• Provides vocabulary and loose structure for
  discussing processes
• First step in using RUP is to choose a
  development case which is a process to use
• This process may not be one of the traditional
  processes
• RUP is essentially iterative

18
(Rational) Unified Process (RUP)

• Phase 1 Inception
• Business case completed
• Feasibility studies completed
• Decision taken to go ahead with project
• Phase 2 Elaboration
• Basic architectural decisions made
• Outline plan for construction finalised
• Major risks identified and understood
• High-level user requirements captured
• Phase 3 Construction
• Consists of a sequence of iterations, each one
  probably consisting of
• Analysis ? Design ?Implementation ? Test ?
  Evaluation
• Phase 4 Transition
• System introduced to users
• Late-stage, non-iterative activities such as
  deployment, user training

19
Other processes

• Object-oriented design (OOD)
• Booch, G. (1991). Object-Oriented Design with
  Applications. Benjamin/Cummings
• Object modeling technique (OMT)
• Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F.
  and Lorensen, W. (1991). Object-Oriented Modeling
  and Design. Prentice-Hall.
• Object-oriented software engineering (OOSE) and
  Objectory
• Jacobson, I., Christenson, M., Jonsson, P. and
  Oevergaard, G. (1992). Object-Oriented Software
  Engineering A Use Case Driven Approach.
  Addison-Wesley.
• Catalysis
• D'Souza, D. and Wills, A. C. (1998). Catalysis
  Objects, Frameworks and Components in UML.
  Addison-Wesley.

20
Predictive planning

• Assumes project is in two stages
• make plans - difficult to predict cost and time
  of this
• execute plans - much more predictable
• Generally, project becomes more predictable as it
  progresses
• Requirements analysis is inherently unpredictable
• Requirements churn
• changes in requirements at a late stage in a
  project
• Two solutions
• Can freeze requirements early on, but could
  result in system that doesn't meet users' needs
• Can put more effort into requirements analysis
  early on...but will this help?
• Can give a fixed-price/fixed-scope contract
• But will probably fail or overrun

21
Adaptive planning

• Sees requirements churn as inevitable
• Accepts that it is impossible to predict how
  requirements will change as software is developed
• Developing the software changes the requirements
  as users become more aware of what is possible
• Cannot fix scope until confident that
  requirements won't change
• Can have fixed-price/variable-scope contract
• Requires users to regularly assess functionality
  of product so far
• Customer may cancel project if too slow
• Uses iterative process

22
Agile programming

• Defined by the Agile Programming Manifesto
• www.agilemanifesto.org
• Claims that we should value
• individuals and interactions over processes and
  tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan
• Examples Extreme programming (XP), Scrum,
  Feature-driven development (FDD), Crystal,
  Dynamic systems development method (DSDM)

23
Agile processes

• Use adaptive planning, not predictive planning
• Are people-oriented
• Most important factor is quality of people and
  working relationships
• Use short, time-boxed iterations with frequent
  customer and user evaluation
• Low ceremony, lightweight
• i.e., few written reports and control points
• Embrace requirements change
• Use automated testing
• Avoid building in features that are not
  definitely required

24
Choosing the right process

• Depends on
• Kind of system
• Technology being used
• Size and distribution of team
• Risks
• Consequences of failure
• Working style of team
• Culture of organisation
• Better to start simple and add complexity than
  start complex and simplify
• Iterative development supports frequent process
  change and evolution

25
Retrospectives

• End each iteration with an iteration
  retrospective
• Make list with three categories
• things to keep
• problems things to get rid of
• things to try
• End project with a project retrospective
  (www.retrospectives.com)
• Learn from your successes and your mistakes

26
Patterns

• See
• Gamma, E., Helm, R., Johnson, R. and Vlissides,
  J. (1995). Design Patterns Elements of Reusable
  Object-Oriented Software. Addison-Wesley.
• Complete example software designs for solving
  commonly encountered problems
• A pattern identifies the common features in a
  class of good designs and incorporates them into
  a re-usable pattern
• A pattern is a software design on which you may
  base a new system

27
Summary

• Waterfall process and software life-cycle
• cannot easily revise decisions
• Iterative ("spiral") process - sequence of mini
  waterfalls
• allows risk to be managed effectively
• involves frequent user evaluation of working
  software
• uses time-boxing to prioritise requirements and
  stay on schedule
• rework not necessarily bad in software
  development
• Rational Unified Process
• Inception ?Elaboration ? Construction ?
  Transition
• Predictive and adaptive planning
• Agile programming
• Retrospectives
• Patterns