Carol Britton & Jill Doake

Course Aim
To look at how a software system is developed using an object orientated approach

System Life Cycle – Why?
• Need an agreed framework for the development
– Identify milestones
– Structure activities
– Monitoring deliverables

System Life Cycle – Why?
• Advantages of agreed framework
– An overall picture of the development process
– A basis for development
– Consistency in approach
– Ensures quality
• Structure for planning, monitoring and controlling the development process

Stage of life cycle Issues addressed Deliverables
Requirements
Analysis
Design
What are the problems, needs and wishes of clients and users?
What are the objectives and scope of the proposed system?
What are the major risks involved?
What does the system look like from the clients’ and users’ perspective?
How can the system be constructed, so as to satisfy the requirements?
List of requirements that can be used as a starting point for development.
List of problem areas that fall within the scope of the proposed system.
Assessment of risk factors.
A set of models, each taking a different view of the system, which together give a complete picture. The models may be text, diagrams or early prototypes.
Models from the analysis stage, refined to illustrate the underlying architecture of the system. These models take account of technological considerations and constraints arising from the implementation environment.
A fully tested suite of programs.
Implementation How can the models produced be translated into code?
Installation What is needed to support clients and users and ensure that they can use the new system effectively?
User manual, technical documentation, user training.
Note - Stage names reflect activities carried out at each stage

Traditional Life Cycle Models
• Waterfall
• V-model
• Spiral
• Prototyping
• Iterative Development
• Incremental Development

• Functional Decomposition
– Functions and data separated
– Data accessible by several processes
Major problem - data not protected
• Poor modularity
• Data versus function

• Functional Decomposition
• Poor modularity
– Ideally modules should be self-contained
– Have well defined purpose
– Be independent
Major problem – interdependency between modules
• Data versus function

• Functional Decomposition
• Poor modularity
• Data versus function
– System functionality is more likely to change than the data
– Over time the functionality is more unstable than the data

The Object-Orientated Approach
Phases (stages) of Development
• Inception
• Elaboration
• Construction
• Transition
These indicate the state of the system at each phase NOT the activities involved at that point in development

The Object-Orientated Approach
Phases (stages) of Development
• Inception – the initial work required to set up and agree terms for the project.
Includes establishing the business case
– Feasibility
– Basic risk assessment
– Scope of the system to be delivered

The Object-Orientated Approach
Phases (stages) of Development
• Inception
• Elaboration – deals with putting the basic architecture of the system in place
– All main project risks are identified
• Construction
• Transition

The Object-Orientated Approach
Phases (stages) of Development
• Inception
• Elaboration
• Construction – involves bulk of work on building the system
– Ends with beta-release of system
• Transition

The Object-Orientated Approach
Phases (stages) of Development
• Inception
• Elaboration
• Construction
• Transition – process involved in transferring the system to the clients and users

Workflows
• The activities implied by the stages in a traditional structured modelling approach are referred to as Workflows in the objectorientated approach
• Workflows -
– Requirements
– Analysis
– Design
– Implementation
– Testing

PHASES
Workflows - activities
WORKFLOWS
Inception
Requirement s
Elaboration Analysis
Design
Construction
Transition Implementation

The Object-Orientated Approach
Iterative Process -
• Workflows may be carried out during any phase of development
• In each phase a range of workflows (activities) may be carried out several times before moving on to the next phase

The Object-Orientated Approach
Requirements
Analysis
Design
Implementatio n
Testing

The Object-Orientated Approach
I n c e p t i o n
E l a b o r a t i o n
C o n s t r u c t i o n
An iterative process.
The ellipses represent iterations of workflows
(requirements, analysis, design, implementation, testing)
T r a n s i t i o n

The Object-Orientated Approach
A seamless Development Process
• Phases less distinct than in a structured approach
• Difficult to say when one phase ends and another begins
• Driven by a single unifying idea – the object

The Object
• Basic building block
• Objects in the real world translate into objects in the software system
– Physical (customers, products)
– Conceptual (orders, reservations
– Organisation (companies, departments)
– Implementation (GUI Windows)

The Object-Orientated Approach
• The foundation of all development work is the object
• No new system models introduced at different stages
• Early models developed and refined through the development process
• An iterative design process

• To capture the whole of a system we need to view it from different aspects
• Each diagram provides some but not all of the information – abstraction
• Each model is an abstraction of the complete system
• System is broken down into small workable chunks decomposition

• A notation or language for development
• Not a development method
• Set of diagrammatic techniques
• Industry standard for modelling OO systems
• UML Creators – Ivar Jacobson, Grady Booch,
James Rumbaugh

Principal UML Models
Model
Use case
Class
Interaction (sequence and collaboration)
State
View of the system
How the system interacts with its users.
The data elements in the system and the relationships between them.
How a use case affects all the objects that are involved in it.
Activity
Component
Deployment
How the different objects of a single class behave through all the use cases in which the class in involved.
The sequence of activities that make up a process.
The different components of the system and the dependencies between them.
The software and hardware elements of the system and the physical relationships between them.

Summary
• Problems of a traditional life cycle
• Phases of the object-orientated approach, Inception,
Elaboration, Construction, Transition
• Object-orientated design is an iterative process
• Unified Modelling Language

• Bennett, S., McRobb, S. and Farmer, R. Object-Oriented Systems
Analysis and Design Using UML, 2nd Ed, London: McGraw-Hill, 2002.
• Brown, D. Object-Oriented Analysis: objects in plain English, New York:
John Wiley, 1997.
• Fowler, M. UML Distilled: a brief guide to the standard object modeling language, 2nd Ed, Reading Massachusetts: Addison-Wesley, 2000.
•
Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven
Approach , Wokingham, England: Addison-Wesley, 1992.
• Larman, C. Applying UML and patterns: an introduction to objectoriented analysis and design, New Jersey: Prentice Hall, 1998.
• Stevens, P., with Pooley, R. Using UML. Software Engineering with
Objects and Components Updated edition, Harlow: Addison-Wesley,
2000 .