Module 3: Design

Engineering
By Ms. Rujuta Vartak
Software design
• Software design encompasses the set of principles, concepts, and
practices that lead to the development of a high-quality system or
product.
• Design is what almost every engineer wants to do. It is the place where
creativity rules—where stakeholder requirements, business needs, and
technical considerations all come together in the formulation of a
product or system.
• Design creates a representation or model of the software, but unlike
the requirements model (that focuses on describing required data,
function, and behavior), the design model provides detail about
software architecture, data structures, interfaces, and components
that are necessary to implement the system.
Design Process & Quality
• Design Process Software design is an iterative process through which
requirements are translated into a blueprint for constructing the software.
• Software Quality Guidelines and Attributes Throughout the design process, the
quality of the evolving design is assessed with a series of technical reviews
suggests three characteristics that serve as a guide for the evaluation of a good
design:
1. The design must implement all of the explicit requirements contained in the
requirements model, and it must accommodate all of the implicit requirements
desired by stakeholders.
2. The design must be a readable, understandable guide for those who generate code
and for those who test and subsequently support the software.
3. The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.
• Each of these characteristics is actually a goal of the design process.
Software Design Process
• Software design is process of transform user requirements into
some suitable form, which helps the programmer in software
coding and implementation.
• It tries to fulfil the requirements mentioned in SRS.

• 3 levels of Phases of design

• 1. Interface design
• 2. Architectural design
• 3. Detailed design
Objectives of Software Design
1. Correctness
2. Completeness
3. Efficiency
4. Flexibility
5. Consistency
6. Maintainability
Software Quality Attributes
• Functionality
• Usability
• Reliability
• Performance
• Supportability
Design Concept
1. Abstraction
• Abstraction is used to hide background details or unnecessary
implementation about the data. So that user see only required
data.
• Abstraction simply means to hide the details to reduce
complexity and increases efficiency or quality.
• Type 1. Procedural Abstraction: one is hidden group another is
visible group of functionalities.
• Type 2. Data Abstraction: Collection of data that described
data objects.
• Show representation data and hide manipulation data.
2. Architecture
• Architecture simply means a technique to design a structure of
something. Architecture in designing software is a concept that
focuses on various elements and the data of the structure. These
components interact with each other and use the data of the
structure in architecture.
• Structural Properties: Architectural design represent different
types of components, modules, objects and relationship between
these.
• Extra-functional Properties: How design architecture achieve
requirements of performance, capacity, Reliability, Security,
adaptability and other system Characteristics
• Families of related system: The architectural design should draw
relatable patterns. They have ability to reuse repeatable blocks.
3. Design Patterns
• The pattern simply means a repeated form or design in which
the same shape is repeated several times to form a pattern.
The pattern in the design process means the repetition of a
solution to a common recurring problem within a certain
context.
4. Modularity
• Modularity simply means dividing the system or project into
smaller parts to reduce the complexity of the system or project.
In the same way, modularity in design means subdividing a
system into smaller parts so that these parts can be created
independently and then use these parts in different systems to
perform different functions.
• After developing the modules , they are integrated together to
meet the software requirements.
• Modularizing a design helps to effective development
accommodate changes easily, conduct testing, debugging
efficiently and conduct maintenance work easily.
5. Information Hiding
• Information hiding simply means to hide the information so
that it cannot be accessed by an unwanted party. In software
design, information hiding is achieved by designing the
modules in a manner that the information gathered or
contained in one module is hidden and can’t be accessed by
any other modules.
6. Refinement- (removes impurities)
• Stepwise refinement is a top-down design approach.
• Refinement simply means to refine something to remove any
impurities if present and increase the quality. The refinement
concept of software design is actually a process of developing
or presenting the software or system in a detailed manner that
means to elaborate a system or software. Refinement is very
necessary to find out any error if present and then to reduce it.
7. Refactoring-( Reconstruct
something )
• Refactoring simply means reconstructing something in such a
way that it does not affect the behavior of any other features.
Refactoring in software design means reconstructing the
design to reduce complexity and simplify it without impacting
the behavior or its functions. Fowler has defined refactoring as
“the process of changing a software system in a way that it
won’t impact the behavior of the design and improves the
internal structure”.
 The design model
• Design modeling in software engineering represents the features of the software that helps engineer to
develop it effectively, the architecture, the user interface, and the component level detail.
• Design modeling provides a variety of different views of the system like architecture plan for home or
building.
• Different methods like data-driven, pattern-driven, or object-oriented methods are used for constructing
the design model. All these methods use set of design principles for designing a model.
Types of
design model
• 1. Data Design Model
• 2. User Interface Model
• 3. Architectural Design Model
• 4. Component Level design
element
Architectural Design
• 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.
Design Decisions
• 1. Performance
• If performance is a critical requirement, the architecture should be
designed to localize critical operations within a small number of
components, with these components all deployed on the same
computer rather than distributed across the network.
• 2. Security
If security is a critical requirement, a layered structure for the
architecture should be used, with the most critical assets protected in
the innermost layers, with a high level of security validation applied to
these layers
• 3. Safety
• If safety is a critical requirement, the architecture should be designed
• so that safety-related operations are all located in either a single
• component or in a small number ofcomponents.
• This reduces the costs and problems of safety validation and makesit
• possible to provide related protection systems that can safely shut
• down the system in the event of failure.
• 4. Availability
• If availability is a critical requirement, the architecture should be
• designed to include redundant components so that itis possible to
• replace and update components without stopping thesystem.
• 5. Maintainability
• If maintainability is a critical requirement, the system
architecture should be designed using fine-grain, self-contained
components that may readily be changed. Producers of data
should be separated from consumers and shared data structures
should be avoided.
Taxonomy of Architectural Style
◼ Data-centered architectures
◼ There is a central data server which is accessed by clients
◼ Data flow architectures
◼ Data travels through a series of components
◼ Call and return architectures
◼ Classical
◼ Object-oriented architectures
◼ Modern style. Components pass messages
◼ Layered architectures
◼ High-level to machine level
Data-Centered architectures
•A data store will reside at the center of this architecture and is accessed frequently by the other
components that update, add, delete or modify the data present within the store.
•The figure illustrates a typical data centered style. The client software access a central repository.
Variation of this approach are used to transform the repository into a blackboard when data related
to client or data of interest for the client change the notifications to client software.
Data Flow Architecture
• This kind of architecture is used when input data is transformed into
output data through a series of computational manipulative components.
• 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 lines.
• Pipes are used to transmitting 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.
Diagram
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.
• Object
• Class
• Encapsulation
• Abstraction
• Inheritance
• Polymorphism
• Message Passing
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.
Layered Architecture
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.
Call and Return architectures:
“4+1” View model
“4 + 1” views in modeling system
Architecture
1. Logical View
• The Logical View, often referred to as the “Class Diagram,” is the first of the “4 +
1” views. It primarily focuses on the static structure of the system. This view
deals with the essential components of the system, such as classes, objects,
relationships, and their attributes. Class diagrams visually represent the classes
and their associations in the system, helping to understand how various
components interact with one another. This view provides insights into the
overall design and organization of the system’s functionality.
2.Process View
• The Process View, also known as the “Activity Diagram,” delves into the dynamic
aspects of the system. It describes the system’s behavior and the flow of
control between various activities or processes. Activity diagrams are
particularly helpful in illustrating how different components of the system
collaborate to accomplish specific tasks or use cases. This view is crucial for
understanding the sequence of actions and interactions in the system, making
it an essential tool for system designers and developers.
Continue..
3.Physical View
• The Physical View, represented by the “Deployment Diagram,” provides insights
into how the system’s software components are deployed on hardware
infrastructure. It includes details about servers, nodes, and their
interconnections. Deployment diagrams help in addressing questions related
to scalability, fault tolerance, and resource allocation. This view ensures that
the system architecture aligns with the physical constraints and requirements
of the deployment environment.
4.Development View
• The Development View, also known as the “Component Diagram,” focuses on
the organization of software components and their relationships within the
development environment. It is instrumental in mapping the software
architecture to the actual implementation, making it easier for development
teams to understand how different modules are distributed across the
codebase. This view aids in managing the development process, ensuring that
software components are developed, tested, and integrated efficiently
Continue..
• 5. Use Case View
• The fifth view in the “4 + 1” model is the Use Case View.
While the other four views primarily concentrate on the
internal aspects of the system, the Use Case View
emphasizes the system’s functionality from the user’s
perspective. Use case diagrams depict how users
interact with the system, showcasing various scenarios
and the corresponding system responses. This view
helps in defining and validating system requirements,
ensuring that the architecture aligns with the end-users’
needs and expectations.
Class Diagram (Library Management)
Activity
Diagram
Deployment
Diagram
Component Diagram
Use-case
Diagram
Modeling Component Level Design
• What is a Component?
• A component is a modular, portable, replaceable, and reusable set of
well-defined functionalities.

• What is a Component level Design?

• The component-based architecture focuses on breaking the software design into small
individual modules.
• The purpose of component-level design is to define data structures, algorithms,
interface characteristics, and communication mechanisms for each software
component identified in the architectural design.
• Component-level design occurs after the data and architectural designs are
established.
• The component-level design represents the software in a way that allows the
designer to review it for correctness and consistency, before it is built.
Benefits of component Design
Steps of Component Level Design
Component Design Example
Component Design View
Coupling
Types of Coupling
Cohesion
Types of Cohesion
Continue..
Why high cohesive and low coupling generate good design ?

Module 3
User Interface Design
Types of User Interface
Continu..
User Interface Design Process
• 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 requirement’s 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.
• 2. Interface Design
• The goal of this phase is to define the set of interface objects
and actions i.e., control mechanisms that enable the user to
perform desired tasks. Indicate how these control mechanisms
affect the system. Specify the action sequence of tasks and
subtasks, also called a user scenario. Indicate the state of the
system when the user performs a particular task. Always
follow the three golden rules stated by Theo Mandel. Design
issues such as response time, command and action structure,
error handling, and help facilities are considered as the design
model is refined. This phase serves as the foundation for the
implementation phase.
• 3. Interface Construction and Implementation
• The implementation activity begins with the creation of a prototype
(model) that enables usage scenarios to be evaluated. As iterative
design process continues a User Interface toolkit that allows the
creation of windows, menus, device interaction, error messages,
commands, and many other elements of an interactive environment
can be used for completing the construction of an interface.
• 4. Interface Validation
• This phase focuses on testing the interface. The interface should be
in such a way that it should be able to perform tasks correctly, and
it should be able to handle a variety of tasks. It should achieve all
the user’s requirements. It should be easy to use and easy to learn.
Users should accept the interface as a useful one in their work.
The Golden Rules
Continue..
Interface Design Steps
Interface Analysis
Continu..
Design Evaluation
Design Evaluation Cycle