Software Engineering 10IS51
MODULE – 3
SOFTWARE DESIGN
Software Design
Architectural Design
• Establishing the overall Structure of a software system.
Objectives
• To introduce software engineering and to explain its
importance
• To set out the answers to key questions about software
engineering
• To introduce ethical and professional issues and to explain why
they are of concern to software engineers
Software architecture
• The design process for identifying the sub-systems making up a
system and the framework for sub-system control and
communication is the architectural design
• The output of this design process is a description of the
software architecture
Architectural design
• An early stage of the system design process
• Represents the link between specification and design processes
• Often carried out in parallel with some specification activities
• It involves identifying major system components and their
communications
Advantages of explicit architecture
• Stakeholder communication: Architecture may be used as a
focus of discussion by system stakeholders
• System analysis: Means that analysis of whether the system can
meet its non functional requirements is possible or not.
• Large-scale reuse: The architecture may be reusable across a
range of systems
Architectural Design Decisions
Architectural design process
System structuring: The system is decomposed into several principal sub-
systems and communications between these sub-systems are identified.
Control modeling: A model of the control relationships between the different
parts of the system is established.
Modular decomposition: The identified sub-systems are decomposed into
modules
Department of CSE, SJBIT Page 28
Software Engineering 10IS51
Sub-systems and modules
• A sub-system is a system in its own right whose operation is independent
of the services provided by other sub-systems.
• A module is a system component that provides services to other
components but would not normally be considered as a separate system
Architectural models
• Different architectural models may be produced during the design
process
• Each model presents different perspectives on them architecture
• Static structural model that shows the major system components
• Dynamic process model that shows the process structure of the system
• Interface model that defines sub-system interfaces
• Relationships model such as a data-flow model
Architectural styles
The architectural model of a system may conform to a generic architectural
model or style.
An awareness of these styles can simplify the problem of defining system
architectures
• However, most large systems are heterogeneous and do not follow a single
architectural style
Architecture attributes
• Performance: Localize operations to minimize sub-system
communication
• Security: Use a layered architecture with critical assets in inner layers
• Safety: Isolate safety-critical components
• Availability: Include redundant components in the architecture
• Maintainability: Use fine-grain, self-contained components
System structuring
• Concerned with decomposing the system into interacting sub-systems
• The architectural design is normally expressed as a block diagram
presenting an overview of the system structure
• More specific models showing how sub-systems share data, are
distributed and interface with each other may also be developed
Packing robot control system
I
Vision
system
Object Arm Gripper
identification controller controller
system
Packaging
selection
system
Packing Conveyor
system controller
Department of CSE, SJBIT Page 29
Software Engineering 10IS51
System Organization
The repository model
• Sub-systems must exchange data. This may be done in two
ways:
• Shared data is held in a central database or repository and may
be accessed by all sub- systems.
• Each sub-system maintains its own database and passes data
explicitly to other sub- systems
• When large amounts of data are to be shared, the repository
model of sharing is most commonly used.
CASE toolset architecture
I
Design Code
editor generator
Design Project Program
translator repository editor
Design Report
analyser generator
Repository model characteristics
Advantages
• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data is produced
• Centralized management e.g. backup, security, etc.
• Sharing model is published as the repository schema
Disadvantages
• Sub-systems must agree on a repository data model. Inevitably
a compromise
• Data evolution is difficult and expensive
• No scope for specific management policies
• Difficult to distribute efficiently
Client-server architecture
• Distributed system model which shows how data and
processing is distributed across a range of components
Department of CSE, SJBIT Page 30
Software Engineering 10IS51
• Set of stand-alone servers which provide specific services such
as printing, data management, etc.
• Set of clients which call on these services
• Network which allows clients to access servers
Film and picture library
Client 1
I Client 2 Client 3 Client 4
Wide-bandwidth network
Catalogue Video Picture Hypertext
server server server server
Film clip Digitized Hypertext
Catalogue
files photographs web
Client-server characteristics
Advantages
• Distribution of data is straightforward
• Makes effective use of networked systems. May require
cheaper hardware
• Easy to add new servers or upgrade existing servers
Disadvantages
• No shared data model so sub-systems use different data
organization. Data interchange may be inefficient
• Redundant management in each server
• No central register of names and services - it may be hard to
find out what servers and services are available
Abstract machine model
• Used to model the interfacing of sub-systems
• Organizes the system into a set of layers (or abstract machines)
each of which provide a set of services
• Supports the incremental development of sub-Systems in
different layers. When a layer interface changes, only the adjacent
layer is affected
• However, often difficult to structure systems in this way
Department of CSE, SJBIT Page 31
Software Engineering 10IS51
Version management system
Version management
I
Object management
Database system
Operating
system
Control Styles
Control models: Are concerned with the control flow between sub-systems.
Distinct from the system decomposition model
• Centralized control: One sub-system has overall responsibility
for control and starts and stops other sub-systems
• Event-based control: Each sub-system can respond to
externally generated events from other sub-systems or the system’s
environment
Centralized control
• A control sub-system takes responsibility for managing the
execution of other sub-systems
• Call-return model: Top-down subroutine model where control
starts at the top of a subroutine hierarchy and moves downwards.
Applicable to sequential systems
• Manager model: Applicable to concurrent systems. One system
component controls the stopping, starting and coordination of other
system processes. Can be implemented in sequential systems as a
case statement
Call-return model
I Main
program
Routine 1 Routine 2 Routine 3
Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2
Department of CSE, SJBIT Page 32
Software Engineering 10IS51
Real-time system control
I
Sensor Actuator
processes processes
System
controller
Computation User Fault
processes interface handler
Event-driven systems:
Driven by externally generated events where the timing of the
event is outwit the control of the sub-systems which process the
event.
Two principal event-driven models
• Broadcast models. An event is broadcast to all sub-systems.
Any sub-system which can handle the event may do so.
• Interrupt-driven models. Used in real-time systems where
interrupts are detected by an interrupt handler and passed to some
other component for processing
Other event driven models include spreadsheets and production
systems
Broadcast model
• Effective in integrating sub-systems on different computers in a
network
• Sub-systems register an interest in specific events. When these
occur, control is transferred to the sub-system which can handle the
event
• Control policy is not embedded in the event and message
handler. Sub-systems decide on events of interest to them
• However, sub-systems don’t know if or when an event will be
handled
Selective broadcasting
I
Sub-system Sub-system Sub-system Sub-system
1 2 3 4
Event and message handler
Department of CSE, SJBIT Page 33
Software Engineering 10IS51
Interrupt-driven systems
• Used in real-time systems where fast response to an event is essential
• There are known interrupt types with a handler defined for each type
• Each type is associated with a memory location and a hardware switch
causes transfer to its handler
• Allows fast response but complex to program and difficult to validate
Interrupt-driven control
Interrupts
I
Interrupt
vector
Handler Handler Handler Handler
1 2 3 4
Process Process Process Process
1 2 3 4
Modular decomposition Styles
• Another structural level where sub-systems are decomposed
into modules
• Two modular decomposition models covered
• An object model where the system is decomposed into
interacting objects
• A data-flow model where the system is decomposed into
functional modules which transform inputs to outputs. Also known
as the pipeline model
• If possible, decisions about concurrency should be delayed
until modules are implemented
Object models
• Structure the system into a set of loosely coupled objects with
well-defined interfaces
• Object-oriented decomposition is concerned with identifying
object classes, their attributes and operations
• When implemented, objects are created from these classes and
some control model used to coordinate object operations
Department of CSE, SJBIT Page 34
Software Engineering 10IS51
Invoice processing system
Customer
I Receipt
customer# invoice#
name date
address Invoice amount
credit period customer#
invoice#
date
amount
customer
Payment issue ()
invoice# sendReminder ()
date acceptPayment ()
amount sendReceipt ()
customer#
Data-flow models
• Functional transformations process their inputs to produce
outputs
• May be referred to as a pipe and filter model (as in UNIX shell)
• Variants of this approach are very common. When
transformations are sequential, this is a batch sequential model
which is extensively used in data processing systems
• Not really suitable for interactive systems
Domain-specific architectures
• Architectural models which are specific to some application
domain
• Two types of domain-specific model
• Generic models which are abstractions from a number of real
systems and which encapsulate the principal characteristics of these
systems
• Reference models which are more abstract, idealized model.
Provide a means of information about that class of system and of
comparing different architectures
• Generic models are usually bottom-up models; Reference
models are top-down models
Object-oriented Design
• Designing systems using self- contained objects and object
classes
Characteristics of OOD
• Objects are abstractions of real-world or system entities and
manage themselves
• Objects are independent and encapsulate state and
representation information.
• System functionality is expressed in terms of object services
Department of CSE, SJBIT Page 35
Software Engineering 10IS51
• Shared data areas are eliminated. Objects communicate by
message passing
• Objects may be distributed and may execute sequentially or in
parallel.
Interacting objects
Advantages of OOD
• Easier maintenance. Objects may be understood as stand-alone entities
• Objects are appropriate reusable components.
• For some systems, there may be an obvious mapping from real world
entities to system objects
Object-oriented development
• Object-oriented analysis, design and programming are related but
distinct
• OOA is concerned with developing an object model of the application
domain
• OOD is concerned with developing an object-oriented system model to
implement requirements
• OOP is concerned with realizing an OOD using an OO programming
language such as Java or C++
Objects and object classes
• Objects are entities in a software system which represent instances of real-
world and system entities
• Object classes are templates for objects. They may be used to createobjects
• Object classes may inherit attributes and services from other object classes
Objects
• An Object is an entity which has a state and a defined set of operations
which operate on that state. The state is represented as a set of object
attributes. The operations associated with the object provide services to
other objects (clients) which request these services when some
computation is required.
• Objects are created according to some object class definition. An object
class definition serves as a template for objects. It includes declarations of
Department of CSE, SJBIT Page 36
Software Engineering 10IS51
all the attributes and services which should be associated with an object of
that class.
The Unified Modeling Language
• Several different notations for describing object-oriented
designs were proposed in the 1980s and 1990s
• The Unified Modeling Language is an integration of these
notations
• It describes notations for a number of different models that may
be produced during OO analysis and design
• It is now a de facto standard for OO modeling
Employee object class (UML)
Object communication
• Conceptually, objects communicate by message passing.
• Messages
• The name of the service requested by the calling object.
• Copies of the information required to execute the service and
the name of a holder for the result of the service.
• In practice, messages are often implemented by procedure calls
• Name = procedure name.
• Information = parameter list.
Message examples
// Call a method associated with a buffer
// object that returns the next value
// in the buffer
v = [Link] ();
// Call the method associated with a
// thermostat object that sets the
Department of CSE, SJBIT Page 37
Software Engineering 10IS51
// temperature to be maintained
[Link] (20);
Generalization and inheritance
• Objects are members of classes which define attribute types
and operations
• Classes may be arranged in a class hierarchy where one class (a
super-class) is a generalization of one or more other classes (sub-
classes)
• A sub-class inherits the attributes and operations from its super
class and may add new methods or attributes of its own
• Generalization in the UML is implemented as inheritance in
OO programming languages
A generalization hierarchy
I
Advantages of inheritance
• It is an abstraction mechanism which may be used to classify
entities
• It is a reuse mechanism at both the design and the programming
level
• The inheritance graph is a source of organizational knowledge
about domains and systems
Problems with inheritance
• Object classes are not self-contained. they cannot be
understood without reference to their super-classes
• Designers have a tendency to reuse the inheritance graph
created during analysis. Can lead to significant inefficiency
• The inheritance graphs of analysis, design and implementation
have different functions and should be separately maintained
Department of CSE, SJBIT Page 38
Software Engineering 10IS51
Inheritance and OOD
• There are differing views as to whether inheritance is
fundamental to OOD.
• View 1. Identifying the inheritance hierarchy or network is a
fundamental part of object-oriented design. Obviously this can only
be implemented using an OOPL.
• View 2. Inheritance is a useful implementation concept which
allows reuse of attribute and operation definitions. Identifying an
inheritance hierarchy at the design stage places unnecessary
restrictions on the implementation
• Inheritance introduces complexity and this is undesirable,
especially in critical systems
UML associations
• Objects and object classes participate in relationships with
other objects and object classes
• In the UML, a generalized relationship is indicated by an
association
• Associations may be annotated with information that describes
the association Associations are general but may indicate that an
attribute of an object is an associated object or that a method relies
on an associated object
An association model
Coords c1, c2 ;
Satellite sat1, sat2 ;
Navigator theNavigator ;
public Position givePosition ()
{
return currentPosition ;
}
Department of CSE, SJBIT Page 39
Software Engineering 10IS51
Concurrent objects
• The nature of objects as self-contained entities make them
suitable for concurrent implementation
• The message-passing model of object communication can be
implemented directly if objects are running on separate processors
in a distributed system
Servers and active objects
• Servers: The object is implemented as a parallel process
(server) with entry points corresponding to object operations. If no
calls are made to it, the object suspends itself and waits for further
requests for service
• Active objects: Objects are implemented as parallel processes
and the internal object state may be changed by the object itself and
not simply by external calls.
Object- Oriented design process
Active transponder object
• Active objects may have their attributes modified by operations
but may also update them autonomously using internal operations
• Transponder object broadcasts an aircraft’s position. The
position may be updated using a satellite positioning system. The
object periodically update the position by triangulation from
satellites.
An active transponder object
class Transponder extends Thread {
Position currentPositi on ;
public void run ()
{
while (true)
{
c1 = [Link] () ;
c2 = [Link] () ;
currentPosition = [Link] (c1, c2) ;
}
}
} //Transponder
Java threads
• Threads in Java are a simple construct for implementing
concurrent objects
• Threads must include a method called run() and this is started
up by the Java run-time system
Department of CSE, SJBIT Page 40
Software Engineering 10IS51
• Active objects typically include an infinite loop so that they are
always carrying out the computation
An object-oriented design process
• Define the context and modes of use of the system
• Design the system architecture
• Identify the principal system objects
• Develop design models
• Specify object interfaces
Layered architecture
System context and models of use
Develop an understanding of the relationships between the software
being designed and its external environment
• System context: A static model that describes other systems in
the environment. Use a subsystem model to show other systems.
Following slide shows the systems around the weather station
system.
• Model of system use: A dynamic model that describes how the
system interacts with its environment. Use use-cases to show
interactions
Department of CSE, SJBIT Page 41
Software Engineering 10IS51
Subsystems in the weather mapping system
Use-cases for the weather station
I
Use-case description
System Weather station
Use-case Report
Actors Weather data collection system,
Weather station
Data The weather station sends a
summary of the weather data that
has been collected from the
instruments in the collection
period to the weather data
collection system. The data sent
are the maximum minimum and
average ground and air
temperatures, the maximum,
minimum and average air
pressures, the maximum,
minimum and average wind
Department of CSE, SJBIT Page 42
Software Engineering 10IS51
speeds, the total rainfall and the
wind direction as sampled at 5
minute s intervals.
Stimulus The weather data collection
system establishes a modem link
with the weather station and
requests transmission of the data.
Response The summarized data is sent to
the weather data collection
system
Comments Weather stations are usually
asked to report once per hour but
this frequency may differ from
one station to the other and may
be modified in future
Architectural design
• Once interactions between the system and its environment have
been understood, you use this information for designing the system
architecture
• Layered architecture is appropriate for the weather station
• Interface layer for handling communications
• Data collection layer for managing instruments
• Instruments layer for collecting data
• There should be no more than 7 entities in an architectural
model
Weather station architecture
I
Object identification
• Identifying objects (or object classes) is the most difficult part
of object oriented design
• There is no 'magic formula' for object identification. It relies on
the skill, experience and domain knowledge of system designers
• Object identification is an iterative process. You are unlikely to
get it right first time
Department of CSE, SJBIT Page 43
Software Engineering 10IS51
Approaches to identification
• Use a grammatical approach based on a natural language
description of the system (used in Hood method)
• Base the identification on tangible things in the application
domain
• Use a behavioral approach and identify objects based on what
participates in what behavior
• Use a scenario-based analysis. The objects, attributes and
methods in each scenario are identified
Weather station object classes
• 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
I
Further objects and object refinement
• Use domain knowledge to identify more objects and operations
• Weather stations should have a unique identifier
• Weather stations are remotely situated so instrument failures
have to be reported automatically. Therefore attributes and
operations for self-checking are required
• Active or passive objects: In this case, objects are passive and
collect data on request rather than autonomously. This introduces
flexibility at the expense of controller processing time
Department of CSE, SJBIT Page 44
Software Engineering 10IS51
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
• Sub-system models that show logical groupings of objects into
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,
generalization models, etc.
Subsystem models
• Shows how the design is organized into logically related groups
of objects
• In the UML, these are shown using packages – an
encapsulation construct. This is a logical model. The actual
organization of objects in the system may be different.
IWeather station subsystems
Sequence models
• Sequence models show the sequence of object interactions that
take place
• Objects are arranged horizontally across the top
• Time is represented vertically so models are read top to bottom
• Interactions are represented by labeled arrows, Different styles
of arrow represent different types of interaction
Department of CSE, SJBIT Page 45
Software Engineering 10IS51
• A thin rectangle in an object lifeline represents the time when
the object is the controlling object in the system
Data collection sequence
Statecharts
• Show how objects respond to different service requests and the state
transitions triggered by these requests
• If object state is Shutdown then it responds to a Startup() message In
the waiting state the objec t is waiting for further messages
• If reportWeather () then system moves to summarizing state
• If calibrate () the system moves to a calibrating state
• A collecting state is entered when a clock signal is received
Department of CSE, SJBIT Page 46
Software Engineering 10IS51
Weather station state diagram
Object 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 interface
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;
public void startup (Instrument i) ;
public void shutdown () ;
public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;
public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
} //WeatherStation
Department of CSE, SJBIT Page 47
Software Engineering 10IS51
Design evolution
• Hiding information inside objects means that changes made to an object
do not affect other objects in an unpredictable way
• Assume pollution monitoring facilities are to be added to weather
stations. These sample the air and compute the amount of different
pollutants in the atmosphere
• Pollution readings are transmitted with weather data
Changes required
• Add an object class called ‘Air quality’ as part of
WeatherStation
• Add an operation reportAirQuality to WeatherStation. Modify
the control software to collect pollution readings
• Add objects representing pollution monitoring instruments
Pollution monitoring
• OOD is an approach to design so that design components have their own
private state and operations
• Objects should have constructor and inspection operations. They provide
services to other objects
Department of CSE, SJBIT Page 48
Software Engineering 10IS51
• Objects may be implemented sequentially or concurrently
• The Unified Modeling Language provides different notations for
defining different object models
• A range of different models may be produced during an object-oriented
design process. These include static and dynamic system models
• Object interfaces should be defined precisely using e.g. a programming
language like Java.
• Object-oriented design simplifies system evolution
Department of CSE, SJBIT Page 49