Unit III
Unit III
BHOPAL
Unit-3
Software Design Process
The design phase of software development deals with transforming the customer requirements as
described in the SRS documents into a form implementable using a programming language.
The software design process can be divided into the following three levels of phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Interface Design:
Interface design is the specification of the interaction between a system and its environment. this
phase proceeds at a high level of abstraction with respect to the inner workings of the system i.e,
during interface design, the internal of the systems are completely ignored and the system is
treated as a black box. Attention is focussed on the dialogue between the target system and the
users, devices, and other systems with which it interacts. The design problem statement produced
during the problem analysis step should identify the people, other systems, and devices which are
collectively called agents.
Precise description of events in the environment, or messages from agents to which the
system must respond.
Precise description of the events or messages that the system must produce.
Specification on the data, and the formats of the data coming into and going out of the
system.
Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.
Architectural Design:
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them. In
architectural design, the overall structure of the system is chosen, but the internal details of major
components are ignored.
Issues in architectural design includes:
Gross decomposition of the systems into major components.
Allocation of functional responsibilities to components.
Component Interfaces
Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.
Detailed Design:
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
The detailed design may include:
Decomposition of major system components into program units.
Allocation of functional responsibilities to units.
User interfaces
Unit states and state changes
Data and control interaction between units
Data packaging and implementation, including issues of scope and visibility of program
elements
Algorithms and data structures
The main aim of design engineering is to generate a model which shows firmness, delight and
commodity.
Software design is an iterative process through which requirements are translated into the blueprint
for building the software.
A design is generated using the recognizable architectural styles and compose a good design
characteristic of components and it is implemented in evolutionary manner for testing.
A design of the software must be modular i.e the software must be logically partitioned into
elements.
In design, the representation of data , architecture, interface and components should be distinct.
A design must carry appropriate data structure and recognizable data patterns.
Design components must show the independent functional characteristic.
A design creates an interface that reduce the complexity of connections between the components.
A design must be derived using the repeatable method.
The notations should be use in design which can effectively communicates its meaning.
Quality attributes
The attributes of design name as 'FURPS' are as follows:
Functionality:
It evaluates the feature set and capabilities of the program.
Usability:
It is accessed by considering the factors such as human factor, overall aesthetics, consistency and
documentation.
Reliability:
It is evaluated by measuring parameters like frequency and security of failure, output result accuracy,
the mean-time-to-failure(MTTF), recovery from failure and the the program predictability.
Performance:
It is measured by considering processing speed, response time, resource consumption, throughput
and efficiency.
Supportability:
It combines the ability to extend the program, adaptability, serviceability. These three term defines
the maintainability.
Testability, compatibility and configurability are the terms using which a system can be easily
installed and found the problem easily.
Supportability also consists of more attributes such as compatibility, extensibility, fault tolerance,
modularity, reusability, robustness, security, portability, scalability.
Design concepts
The set of fundamental software design concepts are as follows:
1. Abstraction
A solution is stated in large terms using the language of the problem environment at the highest
level abstraction.
The lower level of abstraction provides a more detail description of the solution.
A sequence of instruction that contain a specific and limited function refers in a procedural
abstraction.
A collection of data that describes a data object is a data abstraction.
2. Architecture
4. Modularity
A software is separately divided into name and addressable components. Sometime they are called
as modules which integrate to satisfy the problem requirements.
Modularity is the single attribute of a software that permits a program to be managed easily.
5. Information hiding
Modules must be specified and designed so that the information like algorithm and data presented in
a module is not accessible for other modules not requiring that information.
6. Functional independence
The functional independence is the concept of separation and related to the concept of modularity,
abstraction and information hiding.
The functional independence is accessed using two criteria i.e Cohesion and coupling.
Cohesion
7. Refinement
It is a reorganization technique which simplifies the design of components without changing its
function behaviour.
Refactoring is the process of changing the software system in a way that it does not change the
external behaviour of the code still improves its internal structure.
9. Design classes
1. Class – A class defines the blue print i.e. structure and functions of an object.
2. Objects – Objects help us to decompose large systems and help us to modularize our system.
Modularity helps to divide our system into understandable components so that we can build our
system piece by piece. An object is the fundamental unit (building block) of a system which is used
to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their
parent classes.
4. Abstraction – Mechanism by which implementation details are hidden from user.
5. Encapsulation – Binding data together and protecting it from the outer world is referred to as
encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to exist in different forms.
1. Class Diagram – The most widely use UML diagram is the class diagram. It is the building block
of all object oriented software systems. We use class diagrams to depict the static structure of a
system by showing system’s classes,their methods and attributes. Class diagrams also help us
identify relationship between different classes or objects.
2. Composite Structure Diagram – We use composite structure diagrams to represent the internal
structure of a class and its interaction points with other parts of the system. A composite structure
diagram represents relationship between parts and their configuration which determine how the
classifier (class, a component, or a deployment node) behaves. They represent internal structure of a
structured classifier making the use of parts, ports, and connectors. We can also model
collaborations using composite structure diagrams. They are similar to class diagrams except they
represent individual parts in detail as compared to the entire class.
3. Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a
system and the relationship that exists between them. Since object diagrams depict behaviour when
objects have been instantiated, we are able to study the behaviour of the system at a particular
instant. An object diagram is similar to a class diagram except it shows the instances of classes in
the system. We depict actual classifiers and their relationships making the use of class diagrams. On
the other hand, an Object Diagram represents specific instances of classes and relationships
between them at a point of time.
4. Component Diagram – Component diagrams are used to represent the how the physical
components in a system have been organized. We use them for modelling implementation details.
Component Diagrams depict the structural relationship between software system elements and help
us in understanding if functional requirements have been covered by planned development.
Component Diagrams become essential to use when we design and build complex systems.
Interfaces are used by components of the system to communicate with each other.
5. Deployment Diagram – Deployment Diagrams are used to represent system hardware and its
software.It tells us what hardware components exist and what software components run on
them.We illustrate system architecture as distribution of software artifacts over distributed targets.
An artifact is the information that is generated by system software. They are primarily used when a
software is being used, distributed or deployed over multiple machines with different
configurations.
6. Package Diagram – We use Package Diagrams to depict how packages and their elements have
been organized. A package diagram simply shows us the dependencies between different packages
and internal composition of packages. Packages help us to organise UML diagrams into meaningful
groups and make the diagram easy to understand. They are primarily used to organise class and use
case diagrams.
Behavior Diagrams –
1. State Machine Diagrams – A state diagram is used to represent the condition of the system or part
of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior
using finite state transitions. State diagrams are also referred to as State machines and State-chart
Diagrams . These terms are often used interchangeably.So simply, a state diagram is used to model
the dynamic behavior of a class in response to time and changing external stimuli.
2. Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We
can also use an activity diagram to refer to the steps involved in the execution of a use case. We
model sequential and concurrent activities using activity diagrams. So, we basically depict
workflows visually using an activity diagram.An activity diagram focuses on condition of flow and
the sequence in which it happens. We describe or depict what causes a particular event using an
activity diagram.
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a part
of a system. They are widely used to illustrate the functional requirements of the system and its
interaction with external agents(actors). A use case is basically a diagram representing different
scenarios where the system can be used. A use case diagram gives us a high level view of what the
system or a part of the system does without going into implementation details.
4. Sequence Diagram – A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place.We can also use the terms event
diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in
what order the objects in a system function. These diagrams are widely used by businessmen and
software developers to document and understand requirements for new and existing systems.
5. Communication Diagram – A Communication Diagram(known as Collaboration Diagram in
UML 1.x) is used to show sequenced messages exchanged between objects. A communication
diagram focuses primarily on objects and their relationships. We can represent similar information
using Sequence diagrams,however, communication diagrams represent objects and links in a free
form.
6. Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
7. Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of actions
and helps us simplify complex interactions into simpler occurrences. It is a mixture of activity and
sequence diagrams.
Software Engineering | Architectural Design
Introduction: The software needs the architectural design to represents the design of software.
IEEE defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of these
many architectural styles.
Each style will describe a system category that consists of :
A set of components(eg: a database, computational modules) that will perform a function
required by the system.
The set of connectors will help in coordination, communication, and cooperation between
the components.
Conditions that how components can be integrated to form the system.
Semantic models that help the designer to understand the overall properties of the system.
The use of architectural styles is to establish a structure for all the components of the system.
The figure represents pipe-and-filter architecture since it uses both pipe and filter and
it has a set of components called filters connected by pipes.
Pipes are used to transmit data from one component to the next.
Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters don’t
require any knowledge of the working of neighboring filters.
If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of
sequential components to transform it.
3. Call and Return architectures: It is used to create a program that is easy to scale and
modify. Many sub-styles exist within this category. Two of them are explained below.
Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.
4. Object Oriented architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and
communication between the components are established via the message passing.
5. Layered architecture:
A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
Intermediate layers to utility services and application software functions.
The analysis and design process of a user interface is iterative and can be represented by a spiral
model. The analysis and design process of user interface consists of four framework activities.
1. User, task, environmental analysis, and modeling: Initially, the focus is based on the
profile of users who will interact with the system, i.e. understanding, skill and knowledge,
type of user, etc, based on the user’s profile users are made into categories. From each
category requirements are gathered. Based on the requirements developer understand how
to develop the interface. Once all the requirements are gathered a detailed analysis is
conducted. In the analysis part, the tasks that the user performs to establish the goals of the
system are identified, described and elaborated. The analysis of the user environment
focuses on the physical work environment. Among the questions to be asked are:
Prepared by : URMILA MAHOR
TRINITY INSTITUTE OF TECHNOLOGY AND RESEARCH
BHOPAL
DFDs. At the requirement stage, data dictionaries contains data items. Data dictionaries
include Name of the item, Aliases (Other names for items), Description / purpose, Related
data items, Range of values, Data structure definition / form.
3. Structure Charts:
It is the hierarchical representation of system which partitions the system into black boxes
(functionality is known to users but inner details are unknown). Components are read from
top to bottom and left to right. When a module calls another, it views the called module as
black box, passing required parameters and receiving results.
Pseudo Code:
Pseudo Code is system description in short English like phrases describing the function. It
use keyword and indentation. Pseudo codes are used as replacement for flow charts. It
decreases the amount of documentation required.