SOFTWARE ENGINEERING
LECTURE 5
• Today:
- An overview to OO Analysis and OO Design
- Introduction of Assignment 2.
OHTO -99
THE PROGRAMMING PARADIGM
• The requirements specification should be as
programming paradigm (such as OO, logic
programming, etc.) independent as possible.
• However, that’s where it stops. The system
analysis methods and tools are oriented towards a
programming paradigms (intentionally or not).
• Usually the programming paradigm has been fixed
before the analysis starts. Reasons for this
include:
- expertise in some paradigm,
- client’s demands,
- HW/SW platform
OHTO -99
SYSTEM ANALYSIS METHODS
• Analysis and Design are described in Pressman’s
book both for the Object Oriented approach and
the so called ”traditional approach” (separate
descriptions for data and processing, procedural
implementation language).
• Choose a system analysis method, which:
- communicates with the client,
- you have tools for (no tools, no motivation),
- supports your programming paradigm (no
additional complicated transformations are
required),
- you are familiar with (or willing to learn)
OHTO -99
EXAMPLE METHODS
•
•
•
•
•
•
•
•
Data Flow Diagrams
SA/SA (Structured Analysis/Structured Design)
Flowcharts
Object oriented methods
NIAM
ER-diagrams
Other conceptual modelling methods
Formal methods based on logic
OHTO -99
TOOLS
• Graphical is generally easier to use
• Nowadays the selection of tools has improved
• The tools should support also software design,
implementation and modification - prefer an
integrated or a compatible set of tools.
OHTO -99
OO ANALYSIS AND DESIGN
• There are several competing OO methods and OO
design languages.
• These are also introduced in Pressman’s book.
• These methods share common ideas. We try to
present these general ideas in today’s lecture.
OHTO -99
SYSTEM ANALYSIS
• In the analysis phase, we take the requirements
and produce a model of the system.
• The analysis model of the system describes the
architecture of the system on a very rough level.
• The analysis model does not describe the
implementation, but rather the overall structure
and functionalities of the system.
OHTO -99
OO SYSTEM ANALYSIS
• Object oriented system analysis produces an
object oriented model of the system.
• The model produced in OO system analysis needs
not to be directly implementable.
• The understandability and correctness of the
model are key points in it.
OHTO -99
OO SYSTEM ANALYSIS MODEL
• The main products in the OO system analysis
model are:
- A class diagram
- Descriptions of the classes
- Scenarios created for the use cases
• Classes may be divided into categories.
• Re-usable classes may be identified.
OHTO -99
FINDING CANDIDATE CLASSES
• The candidate classes in the analysis model
understandably come from the requirement
specification.
• The text in the specification can be analysed to
find potential classes.
• Generally, a noun in the requirement description
corresponds to a potential class.
• Adjectives may represent attributes of these
candidate classes.
• Verbs may represent methods of these candidate
classes.
OHTO -99
PERFORM OBJECT ANALYSIS
• Identify subclasses and superclasses
– Common attributes and naming may give hints for this.
•
•
•
•
Identify whole-part structures (aggregations)
Analyse the domain to identify re-usable classes.
Divide classes into subsystems.
Explain the role and motivation for the class.
OHTO -99
BUILD SCENARIOS
• Build a scenario for each use case.
• The objects in the scenarios should be the objects
identified of the analysis model obtained this far.
OHTO -99
METHODS & STATE DIAGRAMS
• The scenarios can now be used to identify
methods for the objects in the analysis model.
• The methods should have some understandable
description.
• The exceptions in the use cases (if not included in
the scenarios) can be used to identify further
methods.
• Identifying the methods may give rise to new
attributes.
• Based on the identified methods and the
attributes, it is possible to construct state
diagrams for the objects.
OHTO -99
FURTHER OBJECT ANALYSIS
• After all these steps, analyse the analysis object
model further.
• The result should now describe the structure of the
system to be built.
OHTO -99
OBJECT ORIENTED DESIGN
• Object oriented design should transform the
analysis model into a model which can be
implemented.
• Object oriented design contains the following:
- System design
- Human interface design
- Object design
- Data management design
- Process management design – control, priority,…
OHTO -99
SYSTEM DESIGN
•
•
•
•
•
•
•
Divide the analysis model into subsystems
Identify hardware components
Identify processes – attach to hardware
Allocate subsystems to processes
Identify user interface components
Choose basic strategy for data management
Make sure that the overall system structure works
and design a control mechanism for it.
OHTO -99
HUMAN INTERFACE DESIGN
• Specify human interface functionalities
• Perform graphical design
OHTO -99
OBJECT DESIGN
• Transform the object model into something that
can be implemented.
• Generally, classes will be divided.
• Implementable classes – efficiency considerations.
• Describe method parameters and functionality.
• Check attributes (generally, more will be added).
• Create versions of the scenarios which use the
classes obtained in this object design.
• Iterate, until it seems to work.
OHTO -99
DATA MANAGEMENT DESIGN
• Identify persistent data.
• Identify system parameter data.
• Make a storage plan for these:
- database type
- database schema/storage plan
- efficiency considerations
OHTO -99