CHAPTER 4

DESIGN REQUIREMENT AND

IMPLEMENTATION APPROACH

1
 CHAPTER 4.1
UNDERSTAND OBJECT ORIENTED DESIGN USING THE UML

2
 DESIGN AND
IMPLEMENTATION
• Software design and implementation is the stage in the
software engineering process at which an executable
software system is developed.
• Software design and implementation activities are
invariably inter-leaved.
– Software design is a creative activity in which you identify
software components and theirrelationships, based on a
customer’s requirements.
– Implementation is the process of realizing thedesign as a
program.

3
 BUILD OR BUY
• In a wide range of domains, it is now possible to buy
off-the-shelf systems (COTS) that can be adapted and
tailored to theusers’ requirements.
– For example, if you want to implement a medical records
system, you can buy a package that is already used in
hospitals. It can be cheaper and faster to use this approach
rather than developing a system in a conventional
programming language.
• When you develop an application in this way,the design
process becomes concerned with how to use the
configuration features of that system to deliver the
systemrequirements.

4
 AN OBJECT-ORIENTED DESIGN
PROCESS
• Structured object-oriented designprocesses involve
developing a number of different system models.
• They require a lot of effort for development and maintenance
of these models and, for small systems, this may not be cost-
effective.
• However, for large systems developed by different groups
design models are an important communication
mechanism.

5
 PROCESS STAGES
• There are a variety of different object-oriented design
processes that depend on the organization using the
process.
• Common activities in these processesinclude:
– Define the context and modes of use of the system;
– Design the systemarchitecture;
– Identify the principal system objects;
– Develop design models;
– Specify object interfaces.
• Process illustrated here using a design for a
wilderness weather station.

6
 SYSTEM CONTEXT AND
INTERACTIONS
• Understanding the relationships between thesoftware that is
being designed and its external environment is essential for
deciding how to provide the required system functionality
and how to structure the system to communicate with its
environment.
• Understanding of the context also lets you establish the
boundaries of the system. Setting the system boundaries
helps you decide what features are implemented in the
system being designed andwhat features are in other
associatedsystems.

7
 CONTEXT AND
INTERACTION MODELS
• A system context model is a structural model that
demonstrates the other systems in the
environment of the system beingdeveloped.
• An interaction model is a dynamic model that
shows how the system interacts with its
environment as it is used.

8
SYSTEM CONTEXT FOR THE WEATHER STATION

9
WEATHER STATION USECASES

10
USE CASE DESCRIPTION—REPORT WEATHER
System Weather station
Use case Report weather
Actors Weather information system, Weather station
Description The weather station sends a summary of the weather data that has been
collected from the instruments in the collection period to the weather
information system. The data sent are the maximum, minimum, andaverage
ground and air temperatures; the maximum, minimum, and average air
pressures; the maximum, minimum, and average wind speeds; the total
rainfall; and the wind direction as sampled at five-minute intervals.
Stimulus The weather information system establishes a satellite communication link
with the weather station and requests transmission of the data.
Response The summarized data is sent to the weather informationsystem.
Comments Weather stations are usually asked to report once per hour but thisfrequency
may differ from one station to another and may be modified in the future.

11
 ARCHITECTURAL DESIGN
• Once interactions between the system and its environment have been
understood, you use this information for designing thesystem
architecture.
• You identify the major components that makeup the
system and their interactions, and then may
organize the components using an architectural
pattern such as a layered or client-server model.
• The weather station is composed of independent
subsystems that communicate by broadcasting
messages on a common infrastructure.
HIGH-LEVEL ARCHITECTURE OF THE
WEATHER STATION
ARCHITECTURE OF DATA
COLLECTIONSYSTEM

14
 OBJECT CLASS IDENTIFICATION
• Identifying object classes is too often a difficult
part ofobject oriented design.
• There is no 'magic formula' for object identification. It
relies on theskill, experience and domain knowledge
of systemdesigners.
• Object identification is an iterative process. You are
unlikely to get it right first time.
 APPROACHES TO IDENTIFICATION
• Use a grammatical approach based on a natural language
description of the system (used in HoodOOD method).
• Base the identification on tangible things in the application
domain.
• Use a behavioural approach and identify objects based on what
participates in whatbehaviour.
• Use a scenario-based analysis. The objects, attributes and methods
in each scenario are identified.
WEATHER STATION DESCRIPTION
A weather station is a package of software controlled instruments
which collects data, performs some data processing and transmits
this data for further processing. The instruments include air and
ground thermometers, an anemometer, a wind vane, abarometer
and a rain gauge. Data is collected periodically.

When a command is issued to transmit the weather data, the

weather station processes and summarises the collected data.
The summarised data is transmitted to the mappingcomputer
when a request is received.
WEATHER STATION OBJECT CLASSES
• Object class identification in theweather station system may be
based on the tangible hardware and data in the
system:
– Ground thermometer, Anemometer, Barometer
• Application domain objects that are ‘hardware’ objects related to the
instruments in the system.
– Weather station
• The basic interface of the weather station to its environment. It therefore reflects
the interactions identified in the use-case model.
– Weather data
• Encapsulates the summarized data from the instruments.
WEATHER STATION OBJECT CLASSES
 DESIGN MODELS

• Design models show the objects and object

classes and relationships between these entities.
• Static models describe the static structure of the
system in terms of object classes and relationships.
• Dynamic models describe the dynamic
interactions between objects.
 EXAMPLES OF DESIGN MODELS
• Subsystem models that show logical groupings of objectsinto
coherent subsystems.
• Sequence models that show the sequence of object
interactions.
• State machine models that show how individual objects change
their state in response to events.
• Other models include use-case models, aggregation models,
generalisation models, etc.
 SUBSYSTEM MODELS
• Shows how the design is organised into
logically related groups of objects.
• In the UML, these are shown using packages- an
encapsulation construct. This is a logical model.
The actual organisation of objects in the system
may be different.
 SEQUENCE MODELS
• Sequence models show the sequenceof object
interactions that takeplace
– Objects are arranged horizontally across the top;
– Time is represented vertically so models are read top to
bottom;
– Interactions are represented by labelled arrows, Different
styles of arrow represent different types of interaction;
– A thin rectangle in an object lifeline represents the time
when the object is the controlling object in the system.
SEQUENCE DIAGRAM DESCRIBING DATA
 STATE DIAGRAMS
• State diagrams are used to show how objects respond to different
service requests and thestate transitions triggered by these requests.
• State diagrams are useful high-level modelsof a system or an object’s
run-time behavior.
• You don’t usually need a state diagram for all of the objects in the
system. Many of the objects in a system are relatively simple anda state
model adds unnecessary detail to the design.
WEATHER STATION STATE DIAGRAM
 INTERFACE SPECIFICATION

• Object interfaces have to be specified so that the objects and

other components can be designed in parallel.
• Designers should avoid designing the interface representation but
should hide this in the object itself.
• Objects may have several interfaces which are viewpoints on the
methods provided.
• The UML uses class diagrams for interface specification but Java
may also be used.
WEATHER STATION INTERFACES
 SUMMARY
• Software design and implementation are inter-leaved activities. The level of
detail in the design depends on the type of system and whether you are using
a plan-driven or agile approach.
• The process of object-oriented design includes activities to design the
system architecture, identify objects in the system, describe the design
using different object models and document the componentinterfaces.
• A range of different models may be produced during an object-oriented
design process. These include static models (class models, generalization
models, association models) and dynamic models (sequence models, state
machine models).
• Component interfaces must be defined precisely so that otherobjects can use
them. A UML interface stereotype may be used to define interfaces.
THE END

30