Software Design

Learning Outcome
• Software Architecture
• Object Oriented Design
• Real-time system design
• CASE tools
Architectural Design
•Establishing the overall structure of a software system
•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

Software Architecture
•The design process for identifying the sub-systems making up a system and the framework for
sub-system control and communication is architectural design
•The output of this design process is a description of the software architecture
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
•Large-scale reuse
The architecture may be reusable across a range of systems
Architectural Design Process
•System structuring
The system is decomposed into several principal sub-systems and communications between
these sub-systems are identified
•Control modelling
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
Example
Example
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 the 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

• However, most large systems are heterogeneous and do not follow a single architectural style
Architecture Attributes
•Performance

Localise operations to minimise 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

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
Advantages Disadvantages
Efficient way to share large amounts Sub-systems must agree on a
of data repository data model. Inevitably a
compromise
Sub-systems need not be concerned
with how data is produced Data evolution is difficult and
expensive
Centralised management e.g. backup,
security, etc. No scope for specific management
policies
Sharing model is published as the
repository schema Difficult to distribute efficiently
Client-Server Architecture
•Distributed system model which shows how data and processing is distributed across a range of components

•Set of stand-alone servers which provide specific services such as printing, data management, etc.

•Set of clients which call on these services

Advantages Disadvantages
•Network which allows clients to access servers Distribution of data is No shared data model so sub-
straightforward systems use different data
organisation.
Makes effective use of
networked systems. Data interchange may be
inefficient
May require cheaper hardware
Redundant management in each
Easy to add new servers or server
upgrade existing servers
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
•Organises 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
Control Model
•Areconcerned with the control flow between sub-systems. Distinct from the system
decomposition model
•Centralised 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 Model
•A control sub-system takes responsibility for managing the execution of other sub-systems
Manager Model
Call-return Model (Real-time system control)
Applicable to concurrent systems. One system component controls the
Top-down subroutine model where control starts at the top of a stopping, starting and coordination of other system processes. Can be
subroutine hierarchy and moves downwards. Applicable to sequential implemented in sequential systems as a case statement
systems
Event-driven system
•Driven by externally generated events where the timing of the event is outwiththe 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-systemsregister 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
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
Modular Decomposition Models
•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 Model
•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
Data-flow Model
•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
Reference Architecture
•Reference models are derived from a study of the application domain rather than from existing systems
•May be used as a basis for system implementation or to compare different systems. It acts as a standard against which
systems can be evaluated
•OSI (Open System Interconnection) model is a layered model for communication systems

Goal: to allow conformant

system to communicate with
each other
Object Oriented Design
• Designing systems using self-contained objects and object classes
• based on abstractions of real-world or system entities
• objects manage a private state
Passive objects
• communication by message passing all state changes effected through operations
defined in the object interface
e.g. aStack.Push(item)
Advantages Active objects
can change their own state
obvious map to real-world
e.g. an object might have a (private) timer to
easier to debug due to reduced system coupling update its state every 100 ms(similar to
easier reuse JavaScript setTimeout)
easier maintenance (objects are stand-alone entities)
The Office Information Retrieval System
(OIRS)
Automatic file clerk which can file documents under some name in one or more indexes, retrieve
documents, display and maintain document indexes, archive documents and destroy documents.
The system is activated by a request from the user and always returns a message to the user
indicating the success or failure of the request.
Weather Mapping System
A weather mapping system is required to generate weather maps on a regular basis using data collected from remote, unattended weather
stations and other data sources such as weather observers, balloons and satellites. Weather stations transmit their data to the area computer
in response to a request from that machine.

The area computer system validates the collected data and integrates it with the data from different sources. The integrated data is archived
and, using data from this archive and a digitised map database a set of local weather maps is created. Maps may be printed for distribution
on a special-purpose map printer or may be displayed in a number of different formats.
Subsystem Derived from Layered View
Object Identification
•The most difficult part of object oriented design
•No 'magic formula' for object identification
•Relies on skill, experience, and domain knowledge
•Iterative--you are unlikely to get it right first time
•How is this like anything else you do well?
•Approaches

grammatical based on a description of the system: nouns are objects, adjectives are attributes, verbs are
operations
identify tangible things in the application domain
behavioral, identifying objects based on what participates in what behavior
scenario analysis
Weather Station Objects?
•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
•What are the objects inside this?
Hardware Control Objects Weather Data Objects
Weather Station Sub-system (Layered)
Object Interface Design
•Specify the detail of the object interfaces so that objects can be developed in parallel
•This means defining
attribute types
the signatures and semantics of object operations
•Use a programming language to achieve precision
•Avoid representation information
Design Evolution
•How would you add pollution monitoring facilities to the weather stations?

•(to sample the air and compute the amounts of different pollutants)

•(pollution readings are transmitted with weather data)

•Changes required:

add an object class called Air Quality as part of Weather Station.

add an operation report Air Quality to Weather Station. Modify the control software to collect pollution readings.

add objects representing pollution monitoring instruments.

Weather Station Sub-system (Layered)
Detailed Design
•Concerned with producing a short design specification (mini-spec) of each function. This should describe the processing,
inputs, and outputs.
•These descriptions should be managed in a data dictionary.
•From these descriptions, detailed design descriptions, expressed in a Process Design Language, PDL, can be produced.
Object Oriented Design
Components
Components
Components
Components
Components
Steps for Object Oriented Design
Activity Diagram
Interaction Diagram
State Chart Diagram
Example
Example
Example
Use case Diagram
Sequence Diagram - Login
Sequence Diagram - Issue Book
Sequence Diagram - Return Book
Sequence Diagram - Query Book
Sequence Diagram -Maintain Catalog
Sequence Diagram - Generate Reports
Sequence Diagram - Maintain Login
Sequence Diagram - Maintain Student
Details
Class Diagram
Real-time System
•Systems which monitor and control their environment
•Inevitably associated with hardware devices
Sensors: Collect data from the system environment
Actuators: Change (in some way) the system's environment
•Time is critical. Real-time systems MUST respond within specified times
•Real-timesystem design involves designing embedded software systems whose behaviour is subject to
timing constraints
Real-time System Types
•A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and
the time at which these results are produced

•A ‘soft’ real-time system is a system whose operation is degraded if results are not produced according to the specified timing
requirements

•A ‘hard’ real-time system is a system whose operation is incorrect if results are not produced according to the timing specification
Stimulus/Response
•Given a stimulus, the system must produce a response within a specified time
•Periodic stimuli. Stimuli which occur at predictable time intervals
For example, a temperature sensor may be polled 10 times per second
•Aperiodic stimuli. Stimuli which occur at unpredictable times
For example, a system power failure may trigger an interrupt which must be processed by the
system
System Design
•Design both the hardware and the software associated with system. Partition functions to either hardware or software
•Design decisions should be made on the basis on non-functional system requirements
•Hardware delivers better performance but potentially longer development and less scope for change
RTS Design process
•Design algorithms to process each class of stimulus and response. These must meet the given
timing requirements
•Design a scheduling system which will ensure that processes are started in time to meet their
deadlines
•Integrate using a real-time executive or operating system

Timing Constraint
•May require extensive simulation and experiment to ensure that
these are met by the system

•May mean that certain design strategies such as object-oriented

design cannot be used because of the additional overhead
involved

•May mean that low-level programming language features have

to be used for performance reasons
Real-Time Programming
• Hard-real time systems may have to programmed in assembly language to ensure that deadlines
are met
•Languages such as C allow efficient programs to be written but do not have constructs to
support concurrency or shared resource management
•Ada as a language designed to support real-time systems design so includes a general purpose
concurrency mechanism
 Executive components Non-stop System components
•Real-time clock •Configuration manager
Provides information for process scheduling. Responsible for the dynamic reconfiguration of the
•Interrupt handler system software and hardware. Hardware modules may
Manages aperiodic requests for service. be replaced and software upgraded without stopping the
systems
•Scheduler
Chooses the next process to be run. •Fault manager
•Resource manager Responsible for detecting software and hardware
Allocates memory and processor resources. faults and taking appropriate actions (e.g. switching to

•Despatcher
RTS Executive Components backup disks) to ensure that the system continues in
operation
Starts process execution.
Process Priority
•The processing of some types of stimuli must sometimes take priority
•Interrupt level priority. Highest priority which is allocated to processes requiring a very fast
response
•Clock level priority. Allocated to periodic processes
•Within these, further levels of priority may be assigned
Servicing
•Concerned with managing the set of concurrent processes
•Periodic processes are executed at pre-specified time intervals
•The executive uses the real-time clock to determine when to execute a process
•Process period -time between executions
•Process deadline -the time by which processing must be complete

Interrupt Servicing Periodic Process Servicing

•Control is transferred automatically to a pre- •In most real-time systems, there will be several
determined memory location classes of periodic process, each with different
periods (the time between executions), execution
•This location contains an instruction to jump to an times and deadlines (the time by which processing
interrupt service routine must be completed)

•Furtherinterrupts are disabled, the interrupt serviced •The real-time clock ticks periodically and each tick
and control returned to the interrupted process causes an interrupt which schedules the process
manager for periodic processes
•Interrupt service routines MUST be short, simple and
fast •The process manager selects a process which is
ready for execution
Process Switching
•The scheduler chooses the next process to be executed by the processor. This depends on a
scheduling strategy which may take the process priority into account
•The resource manager allocates memory and a processor for the process to be executed
•The despatcher takes the process from ready list, loads it onto a processor and starts execution
Scheduling Strategies
•Non pre-emptive scheduling
Once a process has been scheduled for execution, it runs to completion or until it is blocked for
some reason (e.g. waiting for I/O)
•Pre-emptive scheduling
The execution of an executing processes may be stopped if a higher priority process requires
service
•Scheduling algorithms
Round-robin
Rate monotonic
Shortest deadline first
User Interface Design
•Designing effective interfaces for software systems
•System users often judge a system by its interface rather than its functionality
•A poorly designed interface can cause a user to make catastrophic errors
•Poor user interface design is the reason why so many software systems are never used
 Graphical User Interface (GUI)
•Most users of business systems interact with these systems through graphical interfaces
although, in some cases, legacy text-based interfaces are still used

Advantages
•They are easy to learn and use.
Users without experience can learn to use the system quickly.
•The user may switch quickly from one task to another and can interact
with several different applications.
Information remains visible in its own window when attention is
switched.
•Fast, full-screen interaction is possible with immediate access to
anywhere on the screen
GUI Example
Direct Manipulation Menu Selection Form Fill-in

Command Languages Natural Languages

Reliability Metric
•Reliability metrics are units of measurement of system reliability
•Systemreliability is measured by counting the number of operational failures and, where appropriate, relating these to the
demands made on the system and the time that the system has been operational
•A long-term measurement programme is required to assess the reliability of critical systems
Failure Consequences
•When specifying reliability, it is not just the number of system failures that matter but the consequences
of these failures

•Failures that have serious consequences are clearly more damaging than those where repair and recovery
is straightforward
How to Make Reliability Specification?
1. For each sub-system, analyse the consequences of possible system failures.
2. From the system failure analysis, partition failures into appropriate classes.
3. For each failure class identified, set out the reliability using an appropriate metric. Different
metrics may be used for different reliability requirements
4. Identify functional reliability requirements to reduce the chances of critical failures
Bank ATM System
•Each machine in a network is used 300 times a day

•Bank has 1000 machines

•Lifetime of software release is 2 years

•Each machine handles about 200, 000 transactions

•About 300, 000 database transactions in total per day

Software Reuse
• Software engineering has been more focused on original development
• but it is now recognized that to achieve better software, more quickly and at lower cost, we need to adopt a
design process that is based on systematic reuse rather than ad-hoc reuse.
•Application System Reuse
- The whole application of an application system may be reused either
by incorporating it without change into other systems (COTS reuse) or
by developing application families

•Component Reuse
- Components of an application from sub-systems to single objects may
be reused

•Objectand Function Reuse

- Software components that implement a single well-defined function
may be reused
Requirements for Reuse
•It must be possible to find appropriate reusable components
•Thereuse of the component must be confident that the components will be reliable and will
behave as specified
•The components must be documented so that they can be understood and, where appropriate,
modified
Reuse Benefits
•Increased Dependability
- Software/components/function has been tried and tested in working systems, so should be more dependable than new
software

•Reduced Process Risk

- Less uncertainty in development costs especially if a large software components are reused

•EffectiveUse of Specialists
- Reuse components instead of people. The specialist can create reusable components

•Standards Compliance
- Standards such as UI standard (e.g. , drop-down menu) can be implemented as reusable components to improve
dependability as users are less likely to make mistake

•Accelerated Development
- Avoid original development, speed-up production and hence able to market product early
Problems with Reuse
•Increased Costs
- in understanding whether the application/component/function is suitable for reuse, in testing it
to ensure its dependability and in maintaining the reused item.
•Lack of CASE tool support
•Not-invented-here syndrome
- Some software engineers may think that writing original software is seen as more challenging
than reusing other people’s software
•Maintaining a component library can be expensive
•Finding and adapting reusable components
Safety Specification
•The safety requirements of a system should be separately
specified
•These requirements should be based on an analysis of the
possible hazards and risks
•Safetyrequirements usually apply to the system as a whole
rather than to individual sub-systems. In systems
engineering terms, the safety of a system is an emergent
property
 Safety Processes
•Hazard and risk analysis

Assess the hazards and the risks of damage associated with the system

Assess the risk associated to discover their Define how each hazard must be
Identify potential
with each hazard potential root causes taken into account when the
hazards system is designed
 Risk Assessment
•Assesses hazard severity, hazard probability and accident probability

•Outcome of risk assessment is a statement of acceptability

Intolerable. Must never arise or result in an accident

As low as reasonably practical (ALARP) Must minimise possibility of

hazard given cost and schedule constraints

Acceptable. Consequences of hazard are acceptable and no extra costs

should be incurred to reduce hazard probability
Risk Acceptability/Reduction
Acceptability Reduction

•The acceptability of a risk is determined by human, social and •System should be specified so that hazards do not arise or result in
political considerations an accident

•In
most societies, the boundaries between the regions are pushed •Hazard avoidance
upwards with time i.e. society is less willing to accept risk The system should be designed so that the hazard can never arise
during correct system operation
For example, the costs of cleaning up pollution may be less than
the costs of preventing it but this may not be socially acceptable •Hazard detection and removal
The system should be designed so that hazards are detected and
•Riskassessment is subjective neutralised before they result in an accident
Risks are identified as probable, unlikely, etc. This depends on
who is making the assessment •Damage limitation
The system is designed in such a way that the consequences of an
accident are minimised
Specifying Forbidden Behaviour
•The system shall not allow users to modify access permissions on any files that they have not
created (security)
•The system shall not allow reverse thrust mode to be selected when the aircraft is in flight
(safety)
•The system shall not allow the simultaneous activation of more than three alarm signals (safety)
Security Specification
•Has some similarities to safety specification
Not possible to specify security requirements quantitatively
The requirements are often ‘shall not’ rather than ‘shall’ requirements
•Differences

No well-defined notion of a security life cycle for security management

Generic threats rather than system specific hazards
Mature security technology (encryption, etc.). However, there are problems in transferring this
into general use
Fault-tree Analysis
•Method of hazard analysis which starts with an identified fault and works backward to the causes of the fault.
•Can be used at all stages of hazard analysis from preliminary analysis through to detailed software checking
•Top-down hazard analysis method. May be combined with bottom-up methods which start with system failures and lead
to hazards
Example
•Identify hazard

•Identify potential causes of the hazard. Usually there will be a number of alternative causes. Link these on the fault-tree with ‘or’ or ‘and’
symbols

•Continue process until root causes are identified

•Consider the following example which considers how data might be lost in some system where a backup process is running
Fault Recovery
•Forward recovery
Apply repairs to a corrupted system state
•Backward recovery
Restore the system state to a known safe state
•Forward recovery is usually application specific -domain knowledge is required to compute
possible state corrections
•Backward error recovery is simpler. Details of a safe state are maintained and this replaces the
corrupted system state