Introduction system Life cycle
System Life cycle
A Student Guide Object-Oriented
Development
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
Traditional High Level System Life Cycle
Stage of life cycle
Issues addressed
Deliverables
Requirements
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?
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.
Analysis
What does the system look like from the clients’ and
users’ perspective?
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.
Design
How can the system be constructed, so as to satisfy
the requirements?
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.
Implementation
How can the models produced be translated into
code?
A fully tested suite of programs.
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
Problems with Traditional Approach
• Functional Decomposition
– Functions and data separated
– Data accessible by several processes
Major problem - data not protected
• Poor modularity
• Data versus function
Problems with Traditional Approach
• Functional Decomposition
• Poor modularity
– Ideally modules should be self-contained
– Have well defined purpose
– Be independent
Major problem – interdependency between modules
• Data versus function
Problems with Traditional Approach
• 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
Workflows - activities
PHASES
WORKFLOWS
Inception
Requirement
s
Elaboration
Analysis
Construction
Design
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
A range of
workflows
(activities) take
place during the
development of a
system
Requirements
Analysis
Design
Implementatio
n
Testing
The Object-Orientated Approach
Inception
Elaboration
Construction
Transition
An iterative
process.
The ellipses
represent iterations
of workflows
(requirements,
analysis, design,
implementation,
testing)
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
Modelling
• 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
Unified Modelling Language - UML
•
•
•
•
•
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
View of the system
Use case
How the system interacts with its users.
Class
The data elements in the system and the relationships
between them.
Interaction (sequence and
collaboration)
How a use case affects all the objects that are involved in it.
State
How the different objects of a single class behave through
all the use cases in which the class in involved.
Activity
The sequence of activities that make up a process.
Component
The different components of the system and the
dependencies between them.
Deployment
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
Further reading
•
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.