07-12-2023

Analysis, Design Concepts and

Principles

By
Dr. MK Jayanthi Kannan, B.E.,M.E.,MS.,MBA.,M.Phil., Ph.D.,
Professor School of Computing Science and Engineering,
AB 104, 8.30am- 5.pm
VIT Bhopal University, Bhopal-Indore Highway,
Kothrikalan, Madhya Pradesh - 466114.
email: jayanthi.m@vitbhopal.ac.in, Emp Id : 100600
Ph: +91 6379397594

SOFTWARE ENGINEERING
Analysis, Design Concepts and Principles

• Analysis, Design Concepts and Principles

Systems Engineering
- Modular Design
 – Architectural Design,
Architectural styles
 – User Interface Design.

1
 07-12-2023

SYSTEMS ENGINEERING

• Designing, implementing, deploying and operating systems which

include hardware, software and people.

What is a system?
• A purposeful collection of inter-related components working together
towards some common objective.

• A system may include software, mechanical, electrical and electronic

hardware and be operated by people.

• System components are dependent on other

system components

• The properties and behaviour of system components are inextricably

inter-mingled

2
 07-12-2023

The system engineering process

• Usually follows a ‘waterfall’ model because of the need for parallel
development of different parts of the system

– Little scope for iteration between phases because hardware changes are
very expensive. Software may have to compensate for hardware
problems

• Inevitably involves engineers from different disciplines who must work

together

– Much scope for misunderstanding here. Different disciplines use a

different vocabulary and much negotiation is required. Engineers may
have personal agendas to fulfil

The system engineering process

Requirements System
definition decommissioning

System System
design evolution

Sub-system System
development installation

System
integration

3
 07-12-2023

System requirements definition

• Three types of requirement defined at this stage

– Abstract functional requirements. System functions are defined in an

abstract way

– System properties. Non-functional requirements for the system in

general are defined

– Undesirable characteristics. Unacceptable system behaviour is specified

• Should also define overall organisational objectives for the system

System objectives
• Functional objectives

– To provide a fire and intruder alarm system for the building which will
provide internal and external warning of fire or unauthorized intrusion

• Organisational objectives

– To ensure that the normal functioning of work carried out in the

building is not seriously disrupted by events such as fire and
unauthorized intrusion

4
 07-12-2023

System requirements problems

• Changing as the system is being specified

• Must anticipate hardware/communications

developments over the lifetime of the system

• Hard to define non-functional requirements

(particularly) without an impression of
component structure of the system.

The system design process

• Partition requirements
– Organise requirements into related groups
• Identify sub-systems
– Identify a set of sub-systems which collectively can meet the system
requirements
• Assign requirements to sub-systems
– Causes particular problems when COTS are integrated
• Specify sub-system functionality
• Define sub-system interfaces
– Critical activity for parallel sub-system development

5
 07-12-2023

The system design process

Partition Define sub-system

requirements interfaces

Identify Specify sub-system

sub-systems functionality

Assignrequirements
tosub-systems

System design problems

• Requirements partitioning to hardware,
software and human components may involve a lot of negotiation

• Difficult design problems are often assumed to be readily solved using

software

• Hardware platforms may be inappropriate for

software requirements so software must compensate for this

6
 07-12-2023

Sub-system development
• Typically parallel projects developing the
hardware, software and communications

• May involve some COTS (Commercial Off-the-Shelf) systems

procurement

• Lack of communication across implementation

teams

• Bureaucratic and slow mechanism for

proposing system changes means that the development schedule may be
extended because of the need for rework

System integration
• The process of putting hardware, software and
people together to make a system

• Should be tackled incrementally so that sub-systems are integrated one at

a time

• Interface problems between sub-systems are usually found at this stage

• May be problems with uncoordinated deliveries

of system components

7
 07-12-2023

System installation
• Environmental assumptions may be incorrect

• May be human resistance to the introduction of

a new system

• System may have to coexist with alternative

systems for some time

• May be physical installation problems (e.g.

cabling problems)

• Operator training has to be identified

System operation
• Will bring unforeseen requirements to light

• Users may use the system in a way which is

not anticipated by system designers

• May reveal problems in the interaction with

other systems

• Physical problems of incompatibility

• Data conversion problems

• Increased operator error rate because of inconsistent interfaces

8
 07-12-2023

System evolution
• Large systems have a long lifetime. They must evolve to meet changing
requirements
• Evolution is inherently costly
– Changes must be analysed from a technical and business perspective
– Sub-systems interact so unanticipated problems can arise
– There is rarely a rationale for original design decisions
– System structure is corrupted as changes are made to it
• Existing systems which must be maintained are sometimes called legacy
systems

System decommissioning
• Taking the system out of service after its useful lifetime

• May require removal of materials (e.g. dangerous chemicals) which pollute

the environment

– Should be planned for in the system design by encapsulation

• May require data to be restructured and converted to be used in some other

system

9
 07-12-2023

System procurement
• Acquiring a system for an organization to meet some need

• Some system specification and architectural design is usually necessary

before procurement

– You need a specification to let a contract for system development

– The specification may allow you to buy a commercial off-the-shelf

(COTS) system. Almost always cheaper than developing a system

from scratch

The system procurement process

Off-the-shelf
systemavailable
Adapt Choose Issue request Choose
requirements system for bids supplier

Survey market for

existing systems

Issue request Select Negotiate Let contract for

totender tender contract development
Bespoke system
required

10
 07-12-2023

Procurement issues
• Requirements may have to be modified to match the capabilities of off-the-

shelf components

• The requirements specification may be part of the contract for the

development of the system

• There is usually a contract negotiation period to agree changes after the

contractor to build a system has been selected

Contractors and sub-contractors

• The procurement of large hardware/software systems is usually based

around some principal contractor

• Sub-contracts are issued to other suppliers to supply parts of the system

• Customer liases with the principal contractor and does not deal directly

with sub-contractors

11
 07-12-2023

Contractor/Sub-contractor model
System
customer

Principal
contractor

Sub-contractor 1 Sub-contractor 2 Sub-contr actor 3

Key points
• System engineering involves input from a range of disciplines

• Emergent properties are properties that are characteristic of the system

as a whole and not its component parts

• System architectural models show major sub-systems and inter-

connections. They are usually described using block diagrams

12
 07-12-2023

Key points
• System component types are sensor, actuator, computation, co-ordination,

communication and interface

• The systems engineering process is usually a waterfall model and includes

specification, design, development and integration.

• System procurement is concerned with deciding which system to buy and

who to buy it from

Conclusion
• Systems engineering is hard! There will never be an easy answer to the
problems of complex system development
• Software engineers do not have all the answers
but may be better at taking a systems
viewpoint
• Disciplines need to recognise each others
strengths and actively rather than reluctantly
cooperate in the systems engineering process

13
 07-12-2023

Analysis Concept

REQUIREMENTS ANALYSIS
Requirements analysis provides the software designer with a representation of
information, function, and behavior that can be translated to data, architectural,
interface, and component-level designs.
Finally, the requirements specification provides the developer and the
customer with the means to assess quality once software is built. Software
requirements analysis may be divided into five areas of effort:
1. Problem recognition,
2. Evaluation and synthesis,
3. Modeling,
4. Specification, and
5. Review.

14
 07-12-2023

Analysis Principles
 Investigators have identified analysis problems and their causes and have
developed a variety of modeling notations and corresponding sets
of heuristics to overcome them.
 Each analysis method has a unique point of view.
 All analysis methods are related by a set of operational principles.

 The information domain of a problem must be represented and understood.

 The functions that the software is to perform must be defined.

 The behavior of the software (as a consequence of external events) must
be represented.

Analysis Principles
 The models that depict information function and behavior must be
partitioned in a manner that uncovers detail in a layered (or hierarchical)
fashion.
 The analysis process should move from essential information toward
implementation detail.
 The various analysis principles are
o The Information Domain
o Modeling
o Partitioning
o Implementation Views

15
 07-12-2023

Design Process and Concepts

Design Process and Concepts…

• The data design transforms the information domain model
created during analysis into the data structures that will be
required to implement the software.
• The data objects and relationships defined in the entity
relationship diagram and the detailed data content depicted in the
data dictionary provide the basis for the data design activity.

16
 07-12-2023

Design Process and Concepts…

• The architectural design defines the relationship between major
structural elements of the software, the “design patterns” that can be
used to achieve the requirements that have been defined for the system,
and the constraints that affect the way in which architectural design
patterns can be applied.

• The architectural design representation the framework of a

computer-based system.

Design Process and Concepts…

• The interface design describes how the software communicates
within itself, with systems that interoperate with it, and with humans
who use it. An interface implies a flow of information (e.g., data and/or
control) and a specific type of behavior.

• Therefore, data and control flow diagrams provide much of the

information required for interface design.

17
 07-12-2023

Design Process and Concepts…

• The component-level design transforms structural elements of the
software architecture into a procedural description of software
components. Information obtained from the PSPEC, CSPEC, and
STD serve as the basis for component design.

Design Principles
 The design process should not suffer from “tunnel vision.”

 The design should be traceable to the analysis model.

 The design should not reinvent the wheel.

 The design should “minimize the intellectual distance” between
the software and the problem as it exists in the real world.

 The design should exhibit uniformity and integration.

18
 07-12-2023

Design Principles
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when
aberrant data, events, or operating conditions are encountered.

 Design is not coding, coding is not design.

 The design should be assessed for quality as it is being created, not

after the fact.

 The design should be reviewed to minimize conceptual (semantic)

errors.

MODULAR DESIGN

• Modularization is the decomposition of a system into subcomponents or small

units.

• A module is a collection of instructions & data structure.

• Modules should be such that it can be separately compiled & stored.

• Module should be such that it can be used by other modules.

• It makes process of debugging, testing, integration of system easy

19
 07-12-2023

Criteria to evaluate a Program module

Function decomposition approach- Software is partitioned into independent modules so that each
module is small enough to be manageable.
Objectives of modular software design :
– Functional partitioning into discrete scalable , reusable modules.
– Rigorous use of well-defined modular interface.
– Ease of change to achieve technology transparency and to the extent possible make use of industry standards
for key interfaces.

• Modularity is the principle of keeping separate the various unrelated aspects of a system, so that each
aspect can be studied in isolation (also called separation of concerns).
• If the principle is applied well, each resulting module will have a single purpose and will be
relatively independent of the others.
• Each module will be easy to understand and develop easier to locate faults (because there are fewer
suspect modules per fault).
• Easier to change the system (because a change to one module affects relatively few other modules)

MODULAR DESIGN
• Modular design unintentionally follows the rules of ‘divide and conquer’ problem-
solving strategy this is because there are many other benefits attached with the
modular design of a software.
• Advantage of modularization:
– Smaller components are easier to maintain
– Program can be divided based on functional aspects
– Desired level of abstraction can be brought in the program
– Components with high cohesion can be re-used again.
– Concurrent execution can be made possible
– Desired from security aspect

20
 07-12-2023

DESIGN HEURISTIC

• Heuristics are a valuable tools for identifying design forces and evaluating design
quality.
• The main goal of heuristic evaluations is to identify any problems associated with
the design of user interfaces.
• Heuristic evaluations are one of the most informal methods of usability inspection
in the field of human-computer interaction.
• There are many sets of usability design heuristics; they are not mutually exclusive
and cover many of the same aspects of user interface design.

ARCHITECTURAL DESIGN

• SOFTWARE ARCHITECTURE : The software architecture of a program or

computing system is the structure or structures of the system, which comprise the
software components, the externally visible properties of those components, and the
relationships among them.

21
 07-12-2023

Architectural Design
• Architectural context diagrams model shows how software interacts with
external entities

• Architectural types are classes or patterns that represent an abstraction critical

to the system

• Architectural components are derived from the application domain, the

infrastructure, and the interface.

43

Why Architecture?
• “The architecture of a system is a comprehensive framework that describes its form
and structure—its components and how they fit together.”

• Architecture is a representation of a system that enables the software engineer to:

1. analyze the effectiveness of the design in meeting its stated requirements,

2. consider architectural alternatives at a stage when making design changes is

still relatively easy, and

3. reduce the risks associated with the construction of the software.

44

22
 07-12-2023

Architectural Styles
• Each style describes a system category that encompasses:
1. a set of components (e.g., a database, computational modules)
that perform a function required by a system,

2. a set of connectors that enable “communication, coordination,

and cooperation” among components,

3. constraints that define how components can be integrated to form

the system, and

4. semantic models that enable a designer to understand the overall

properties of a system.

45

Specific Styles
• Data-centered architecture

• Data flow architecture

• Call and return architecture

• Object-oriented architecture

• Layered architecture

46

23
 07-12-2023

Data-Centered Architecture
A data store (e.g., a file or database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise
modify data within the store.

47

Data-Flow Architecture

48

24
 07-12-2023

Data-Flow Architecture
•This architecture is applied when input data are to be transformed through a
series of computational or manipulative components into output data.
•A pipe-and-filter pattern has a set of components, called filters, connected by
pipes that transmit data from one component to the next.
•Each filter works independently of those components upstream and
downstream, is designed to expect data input of a certain form, and produces
data output (to the next filter) of a specified form.

Call and Return Architecture

50

25
 07-12-2023

•Main program/subprogram architectures. This classic program structure decomposes

function into a control hierarchy where a “main” program invokes a number of
program components that in turn may invoke still other components.
• Remote procedure call architectures. The components of a main
program/subprogram architecture are distributed across multiple computers on a
network.

Object-Oriented Architecture

52

26
 07-12-2023

Layered Architecture

53

Architectural Patterns
• Concurrency
– operating system process management
– task scheduler
• Persistence
– database management system
– application level persistence
• Distribution
– broker

54

27
 07-12-2023

USER INTERFACE DESIGN

Interface Design

Easy to learn?

Easy to use?

Easy to understand?

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by
Roger Pressman.

Interface Design
Typical Design Errors

•Lack of consistency

•Too much memorization

•No guidance / help

•No context sensitivity

•Poor response

•Arcane/unfriendly

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright
56
2009 by Roger Pressman.

28
 07-12-2023

Golden Rules

• Place the user in control

• Reduce the user’s memory load
• Make the interface consistent

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright
2009 by Roger Pressman. 57

Place the User in Control

•Define interaction modes in a way that does not force a user into unnecessary
or undesired actions.

•Provide for flexible interaction.

•Allow user interaction to be interruptible and undoable.

•Streamline interaction as skill levels advance and allow the interaction to be

customized.

•Hide technical internals from the casual user.

•Design for direct interaction with objects that appear on the screen.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright
2009 by Roger Pressman. 58

29
 07-12-2023

Reduce the User’s Memory Load

Reduce demand on short-term memory.

Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a
real world metaphor.
Disclose information in a progressive fashion.

These slides are designed to accompany Software Engineering:

A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides
59
copyright 2009 by Roger Pressman.

Make the Interface Consistent

Allow the user to put the current task into a
meaningful context.
Maintain consistency across a family of
applications.
If past interactive models have created user
expectations, do not make changes unless there is
a compelling reason to do so.

These slides are designed to accompany Software Engineering:

A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides
copyright 2009 by Roger Pressman. 60

30
 07-12-2023

User Interface Design Models

• User model — a profile of all end users of the system

• Design model — a design realization of the user model

• Mental model (system perception) — the user’s mental image of

what the interface is

• Implementation model — the interface “look and feel” coupled

with supporting information that describe interface syntax and
semantics

These slides are designed to accompany Software Engineering:

A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides
copyright 2009 by Roger Pressman. 61

User Interface Design Process

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger 62
Pressman.

31
 07-12-2023

Interface Analysis

• Interface analysis means understanding

(1) the people (end-users) who will interact with the system through the
interface;

(2) the tasks that end-users must perform to do their work,

(3) the content that is presented as part of the interface

(4) the environment in which these tasks will be conducted.

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright
2009 by Roger Pressman. 63

User Analysis
• Are users trained professionals, technician, clerical, or manufacturing
workers?
• What level of formal education does the average user have?
• Are the users capable of learning from written materials or have they
expressed a desire for classroom training?
• Are users expert typists or keyboard phobic?
• What is the age range of the user community?
• Will the users be represented predominately by one gender?
• How are users compensated for the work they perform?
• Do users work normal office hours or do they work until the job is done?
• Is the software to be an integral part of the work users do or will it be used
only occasionally?
• What is the primary spoken language among users?
• What are the consequences if a user makes a mistake using the system?
• Are users experts in the subject matter that is addressed by the system?
• Do users want to know about the technology the sits behind the interface?
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides
64
copyright 2009 by Roger Pressman.

32
 07-12-2023

Task Analysis and Modeling

• Answers the following questions …
– What work will the user perform in specific circumstances?
– What tasks and subtasks will be performed as the user does the work?
– What specific problem domain objects will the user manipulate as work is
performed?
– What is the sequence of work tasks—the workflow?
– What is the hierarchy of tasks?
• Use-cases define basic interaction
• Task elaboration refines interactive tasks
• Object elaboration identifies interface objects (classes)
• Workflow analysis defines how a work process is completed when several people
(and roles) are involved

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill,
2009) Slides copyright 2009 by Roger Pressman.

Analysis of Display Content

• Are different types of data assigned to consistent geographic locations on the
screen (e.g., photos always appear in the upper right hand corner)?
• Can the user customize the screen location for content?
• Is proper on-screen identification assigned to all content?
• If a large report is to be presented, how should it be partitioned for ease of
understanding?
• Will mechanisms be available for moving directly to summary information for
large collections of data.
• Will graphical output be scaled to fit within the bounds of the display device that
is used?
• How will color to be used to enhance understanding?
• How will error messages and warning be presented to the user?

These slides are designed to

accompany Software
Engineering: A Practitioner’s
66
Approach, 7/e (McGraw-Hill,
2009) Slides copyright 2009 by

33
 07-12-2023

Interface Design Steps

• Using information developed during interface analysis, define interface
objects and actions (operations).

• Define events (user actions) that will cause the state of the user interface to
change. Model this behavior.

• Depict each interface state as it will actually look to the end-user.

• Indicate how the user interprets the state of the system from information
provided through the interface.

These slides are designed to

accompany Software
Engineering: A Practitioner’s
67
Approach, 7/e (McGraw-Hill,
2009) Slides copyright 2009 by

Design Issues

• Response time

• Help facilities

• Error handling

• Menu and command labeling

• Application accessibility

• Internationalization

These slides are designed to

accompany Software
Engineering: A Practitioner’s
68
Approach, 7/e (McGraw-Hill,
2009) Slides copyright 2009 by

34
 07-12-2023

REAL TIME SOFTWARE DESIGN

• 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.

• Timely response is an important factor in all embedded systems but, in

some cases, very fast response is not necessary.
• A real-time system is as a stimulus/response system.
• Given a particular input stimulus, the system must produce a
corresponding response.

Stimuli fall into two classes:

1. Periodic stimuli: These occur at predictable time intervals.
– For example, the system may examine a sensor every 50 milliseconds and take action
(respond) depending on that sensor value (the stimulus).

2. Aperiodic stimuli :These occur irregularly. They are usually signalled using
the computer's interrupt mechanism. An example of such a stimulus would
be an interrupt indicating that an VO transfer was complete and that data
was available in a buffer.

35
 07-12-2023

General model of Real Time System

System Design

36
 07-12-2023

There are several interleaved stages in this design process:

1. Identify the Stimuli that the system must process and the associated responses.
2. For each stimulus and associated response, identify the timing constraints that
apply to both stimulus and response processing.
3. Choose: an execution platform for the system: the hardware and the real-time
operating system to be used. Factors that influence these choices include the
timing constraints on the system, limitations on power available, the experience
of the development team and the price target for the delivered system.
4. Aggregate the stimulus and response processing into a number of concurrent
processes. A good rule of thumb in real-time systems design is to associate a
process with each class of stimulus and response as shown in Figure
5. For each stimulus and response, design algorithms to carry out the required
computations.
Algorithm designs often have to be developed relatively early in the
design process to give an indication of the amount of processing required and
the time required to complete that processing.
6. DeSign a scheduling system that will ensure that processes are started in time
to meet their deadlines.

Real-time System Design

• System design develops the architectural
detail required to build a system or product.
• The system design process encompasses the
following activities:
• Partition the analysis model into subsystems.
• Identify concurrency that is dictated by the
problem.
• Allocate subsystems to processors and tasks.

37
 07-12-2023

Real-time System Design…

 Develop a design for the user interface.

 Choose a basic strategy for implementing data management.

 Identify global resources and the control mechanisms required to access them.
 Design an appropriate control mechanism for the system, including task
management.

 Design both the hardware and the software associated with system.
 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.

Real-time Executives
• Real-time executives are specialized operating systems which
manage the processes in the RTS

• Responsible for process management and resource (processor

and memory) allocation

• May be based on a standard RTE kernel which is used unchanged

or modified for a particular application

• Does not include facilities such as file management

38
 07-12-2023

Real-time Executive Components

Real-time operating systems

• A real-time operating system manages processes and resource allocation in a real-
time system.
• RTOS include:
1. A real-time clock This provides information to schedule processes periodically.
2. An interrupt handler This manages aperiodic requests for service.
3. A scheduler This component is responsible for examining the processes that
can be executed and choosing one of these for execution.
4. A resource manager Given a process that is scheduled for execution, the
resource manager allocates appropriate memory and processor resources.
5. A dispatcher This component is responsible for starting the execution of a process.

39
 07-12-2023

Components of RTOS

Monitoring And Control System.

• These check sensors providing information about the system’s environment and
take actions depending on the sensor reading.

• Monitoring systems take action when some exceptional sensor value is detected.

• Control systems continuously control hardware actuators depending on the value of

associated sensors.
• A monitoring process collects and integrate: the data before passing it to a control
process, which makes decisions based on this data and sends appropriate control
commands to the equipment control processes.

40
 07-12-2023

Generic architecture for a monitoring and control system

Example
• Sensors
– Movement detectors, window sensors, door sensors.
– 50 window sensors, 30 door sensors and 200 movement
detectors
– Voltage drop sensor
• Actions
– When an intruder is detected, police are called
automatically.
– Lights are switched on in rooms with active sensors.
– An audible alarm is switched on.
– The system switches automatically to backup power when
a voltage drop is detected.

41
 07-12-2023

Data Acquisition System

• Data acquisition systems collect data from sensors for subsequent

processing and analysis.

• These systems are used in circumstances where the sensors are collecting
lots of data from the system's environment and it isn't possible or
necessary to process the data collected in real-time.

• Data acquisition systems are commonly used in scientific experiments and

process control systems where physical processes, such as a chemical
n:action, happen very quickly.

42
 07-12-2023

• In data acquisition systems, the sensors may be generating data very

quickly, and the key problem is to ensure that a sensor reading is collected
before the sensor value changes.
• The essential feature of the architecture of data acquisition systems is that
each group of sensors has three processes associated with it.
• These are the sensor process that interfaces with the sensor and converts
analogue data to digital values if necessary, a buffer process, and a process
that consumes the data and carries out further processing.

43