Design

Engineering
By,
[Link] R. Rahude
Mapped with CO3 and CO4

Course Outcomes:
3. Plan, schedule and track the progress of the
projects.
4. Design & develop the software solutions for
the growth of society
 Software Design
•Software design is a mechanism to transform user requirements
into some suitable form, which helps the programmer in
software coding and implementation.
• It deals with representing the client's requirement, as described
in SRS (Software Requirement Specification) document, into a
form, i.e., easily implementable using programming language.
•Insoftware design, we consider the system to be a set of
components or modules with clearly defined behaviors &
boundaries.
 Objectives of Software Design
1. Correctness:Software design should be correct as per
requirement.
2. Completeness:The design should have all components like
data structures, modules, and external interfaces, etc.
3. Efficiency:Resources should be used efficiently by the
program.
4. Flexibility:Able to modify on changing needs.
5. Consistency:There should not be any inconsistency in the
design.
6. Maintainability: The design should be so simple so that it
can be easily maintainable by other designers.
[Link]
design-principles
Translating the requirements model into the design model
 THE DESIGN PROCESS

Design Guidelines:
● 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.
● The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.
● The design should provide a complete picture of the software, addressing
the data, functional, and behavioral domains from an implementation
perspective.
Quality Guidelines
1. A design should exhibit an architecture that
a. has been created using recognizable architectural styles or patterns,
b. is composed of components that exhibit good design characteristics (these are
discussed later in this chapter), and
c. can be implemented in an evolutionary fashion,2 thereby facilitating
implementation and testing.
2. A design should be modular; that is, the software should be logically partitioned into
elements or subsystems.
3. A design should contain distinct representations of data, architecture,interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional
characteristics.
1. A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
2. A design should be derived using a repeatable method that is driven by information
obtained during software requirements analysis.
3. A design should be represented using a notation that effectively communicates its
meaning.
Quality Attributes
● Functionality
● Usability
● Reliability
● Performance
● Supportability
Software Design Concepts
 Software Design Concepts
1. Abstraction
– An abstraction is a tool that enables a designer
to consider a component at an abstract level
without bothering about the internal details of
the implementation. Abstraction can be used
for existing element as well as the component
being designed.
– Here, there are two common abstraction
mechanisms
• Functional Abstraction
• Data Abstraction
 Software Design Concepts

2. Architecture
Software architecture refers to the structure
of the system, which is composed of various
components of a program/ system, the
attributes (properties) of those components
and the relationship amongst them.
– Structural models
– Framework models
– Dynamic models
– Functional models
Principles of Software Design & Concepts in Software Engineering - Computer Notes ([Link])
 Software Design Concepts

3. Patterns:
– A pattern provides a description of the solution
to a recurring design problem of some specific
domain in such a way that the solution can be
used again and again.
– Types of Design Patterns
• Architectural patterns
• Design patterns
• Idioms
 Software Design Concepts
4. Modularity:
– Modularity is achieved by dividing the software
into uniquely named and addressable
components, which are also known as modules.
–
 Software Design Concepts
5. Information Hiding:
– Modules should be specified and designed in
such a way that the data structures and
processing details of one module are not
accessible to other modules.
[Link]
[Link]
 Software Design Concepts
6. Functional independence:
– The functional independence is the concept of
separation and related to the concept of
modularity, abstraction and information hiding
• Cohesion
• Coupling
– A cohesive module performs a single task and it
requires a small interaction with the other
components in other parts of the program
– Coupling is an indication of interconnection
between modules in a structure of software
 Software Design Concepts
7. Refinement
– Stepwise refinement is a top-down design
strategy used for decomposing a system from a
high level of abstraction into a more detailed
level (lower level) of abstraction.
– A hierarchy is established by decomposing a
statement of function in a stepwise manner till
the programming language statement are
reached.
–
 Software Design Concepts
7. Refinement Example
– Every computer program comprises input, process, and output.
INPUT
– Get user’s name (string) through a prompt.
– Get user’s grade (integer from 0 to 100) through a prompt and validate.
– PROCESS
– OUTPUT
– This is the first step in refinement. The input phase can be refined further as given
here.
–
INPUT
– Get user’s name through a prompt.
– Get user’s grade through a prompt.
– While (invalid grade)
– Ask again:

PROCESS
– OUTPUT
– Note: Stepwise refinement can also be performed for PROCESS and OUTPUT phase.
 Software Design Concepts
8. Refactoring
– Refactoring can be defined as a process of
modifying a software system to improve the
internal structure of design without changing its
external behavior.
– During the refactoring process, the existing
design is checked for any type of flaws like
redundancy, poorly constructed algorithms and
data structures, etc., in order to improve the
design.
 Software Design Principles
•Software design principles are concerned with providing means
to handle the complexity of the design process effectively.
•Following are the principles of Software Design:-
1. Problem Partitioning
2. Abstraction
3. Modularity

1. Problem Partitioning:-
For small problem, we can handle the entire problem at once
but for the significant problem, divide the problems and
conquer the problem it means to divide the problem into
smaller pieces so that each piece can be captured separately.
 Software Design Principles
2. Abstraction
• An abstraction is a tool that enables a designer to
consider a component at an abstract level without
bothering about the internal details of the
implementation. Abstraction can be used for
existing element as well as the component being
designed.
• Here, there are two common abstraction
mechanisms
a. Functional Abstraction
b. Data Abstraction
3. Modularity:-
• Modularity specifies to the division of software
into separate modules which are differently
named and addressed and are integrated later on
in to obtain the completely functional software.
• It is the only property that allows a program to be
intellectually manageable.
• Single large programs are difficult to understand
and read due to a large number of reference
variables, control paths, global variables, etc.
The desirable properties of a modular system
are:
• Each module is a well-defined system that can
be used with other applications.
• Each module has single specified objectives.
• Modules can be separately compiled and
saved in the library.
• Modules should be easier to use than to build.
• Modules are simpler from outside than inside.
• [Link]
of-software-design-process-set-2/
The design Model
 The design model
• Data design: It represents the data objects and their
interrelationship in an entity-relationship diagram.
Entity-relationship consists of information required for each
entity or data objects as well as it shows the relationship
between these objects. It shows the structure of the data in
terms of the tables. It shows three type of relationship – One to
one, one to many, and many to many.
• Architectural design: It defines the relationship between major
structural elements of the software. It is about decomposing the
system into interacting components. It is expressed as a block
diagram defining an overview of the system structure – features
of the components and how these components communicate
with each other to share data. It defines the structure and
properties of the component that are involved in the system and
also the inter-relationship among these components.
• User Interfaces design: It represents how the Software
communicates with the user i.e. the behavior of the system. It
refers to the product where user interact with controls or
displays of the product. For example, Military, vehicles, aircraft,
audio equipment, computer peripherals are the areas where user
interface design is implemented. UI design becomes efficient only
after performing usability testing. This is done to test what works
and what does not work as expected. Only after making the
repair, the product is said to have an optimized interface.
• Component level design: It transforms the structural elements of
the software architecture into a procedural description of
software components. It is a perfect way to share a large amount
of data. Components need not be concerned with how data is
managed at a centralized level i.e. components need not worry
about issues like backup and security of the data.
 Pattern-based Software Design
• A software design pattern is a general, reusable
solution to a commonly occurring problem within a
given context in software design.
• It is not a finished design that can be transformed
directly into source or machine code.
• Rather, it is a description or template for how to solve
a problem that can be used in many different
situations.
• Design patterns are formalized best practices that
the programmer can use to solve common problems
when designing an application or system.
Pattern-based design
[Link]
Classification of Pattern based design
• Creational pattern
– creational design patterns are design patterns that deal with object
creation mechanisms, trying to create objects in a manner suitable to
the situation.
– The basic form of object creation could result in design problems or in
added complexity to the design.
– Creational design patterns solve this problem by somehow controlling
this object creation.
– Creational design patterns are composed of two dominant ideas. One
is encapsulating knowledge about which concrete classes the system
uses. Another is hiding how instances of these concrete classes are
created and combined.
– The creational patterns aim to separate a system from how its objects
are created, composed, and represented. They increase the system's
flexibility in terms of the what, who, how, and when of object creation
• Structural pattern
– structural design patterns are design patterns
that ease the design by identifying a simple way
to realize relationships among entities.
– Examples of Structural Patterns include:
• Adapter pattern: 'adapts' one interface for a class
into one that a client expects
• Composite pattern: a tree structure of objects where
every object has the same interface
• Pipes and filters: a chain of processes where the
output of each process is the input of the next
• Behavioral pattern
– behavioral design patterns are design patterns that
identify common communication patterns among
objects. By doing so, these patterns increase
flexibility in carrying out communication.
– Examples of this type of design pattern include:
• Blackboard design pattern: provides a computational
framework for the design and implementation of systems
that integrate large and diverse specialized modules, and
implement complex, non-deterministic control strategies
• Command pattern: Command objects encapsulate an
action and its parameters
• Mediator pattern: Provides a unified interface to a set of
interfaces in a subsystem
• Concurrency patterns
– concurrency patterns are those types of design
patterns that deal with the multi-threaded
programming paradigm.
– Examples of this class of patterns include:
• Active object:-The goal is to introduce concurrency, by
using asynchronous method invocation and a scheduler
for handling requests.[
• Readers–writer lock:-allows concurrent access for
read-only operations, write operations require exclusive
access.
• Thread pool:-maintains multiple threads waiting for tasks
to be allocated for concurrent execution by the
supervising program.
• [Link]
es16/[Link]
 Architectural design
• Architectural design is concerned with understanding how a system
should be organized and designing the overall structure of that system.
• it identifies the main structural components in a system and the
relationships between them.
• The output of the architectural design process is an architectural model
that describes how the system is organized as a set of communicating
components.
• design software architectures at two levels of abstraction
1. Architecture in the small is concerned with the architecture of individual
programs. At this level, we are concerned with the way that an individual
program is decomposed into components.
2. Architecture in the large is concerned with the architecture of complex
enterprise systems that include other systems, programs, and program
components. These enterprise systems are distributed over different
computers, which may be owned and managed by different companies.
• Three advantages of explicitly designing and
documenting software architecture:
– Stakeholder communication: Architecture may be
used as a focus of discussion by system stakeholders.
– System analysis: Well-documented architecture
enables the analysis of whether the system can meet
its non-functional requirements.
– Large-scale reuse: The architecture may be reusable
across a range of systems or entire lines of products.
• Software architecture is most often represented
using simple, informal block diagrams showing
entities and relationships.
 Architectural design decisions
• A number of common decisions span all design processes
and these decisions affect the non-functional
characteristics of the system:
– Is there a generic application architecture that can be used?
– How will the system be distributed?
– What architectural styles are appropriate?
– What approach will be used to structure the system?
– How will the system be decomposed into modules?
– What control strategy should be used?
– How will the architectural design be evaluated?
– How should the architecture be documented?
Systems in the same domain often have similar architectures that
reflect domain concepts.
• The particular architectural style should depend on
the non-functional system requirements
– Performance: localize critical operations and
minimize communications. Use large rather than
fine-grain components.
– Security: use a layered architecture with critical
assets in the inner layers.
– Safety: localize safety-critical features in a small
number of sub-systems.
– Availability: include redundant components and
mechanisms for fault tolerance.
– Maintainability: use fine-grain, replaceable
components.
More about design decisions in practical work
[Link]
-design-decisions/
 Architectural views
• 4+1 view model of software architecture:
– A logical view, which shows the key abstractions in
the system as objects or object classes.
– A process view, which shows how, at run-time, the
system is composed of interacting processes.
– A development view, which shows how the software
is decomposed for development.
– A physical view, which shows the system hardware
and how software components are distributed across
the processors in the system.
– Related using use cases or scenarios (+1).
 Architectural patterns
• Patterns are a means of representing, sharing
and reusing knowledge.
• An architectural pattern is a stylized description
of a good design practice, which has been tried
and tested in different environments.
• Patterns should include information about when
they are and when the are not useful.
• Patterns may be represented using tabular and
graphical descriptions.
•
Model-View-Controller
Layered architecture
Repository architecture
Client-server architecture
 Application architectures
• Application systems are designed to meet an organizational
need.
• As businesses have much in common, their application systems
also tend to have a common architecture that reflects the
application requirements.
• A generic application architecture is an architecture for a type of
software system that may be configured and adapted to create a
system that meets specific requirements.
• application architectures can be used as a:
– Starting point for architectural design.
– Design checklist.
– Way of organizing the work of the development team.
– Means of assessing components for reuse.
– Vocabulary for talking about application types.
• Examples of application types:
– Data processing applications:-Data driven applications that
process data in batches without explicit user intervention
during the processing.
– Transaction processing applications:-Data-centred
applications that process user requests and update
information in a system database.
– Event processing systems:-Applications where system actions
depend on interpreting events from the system's environment.
– Language processing systems:-Applications where the users'
intentions are specified in a formal language that is processed
and interpreted by the system.
[Link]
00007CS/P001067/M022567/ET/1504860540SE-MOD17-e-
[Link]
 COMPONENT LEVEL DESIGN
• A component is a modular, portable, replaceable, and
reusable set of well-defined functionality that encapsulates
its implementation and exporting it as a higher-level
interface.
• Component level design is the definition and design of
components and modules after the architectural design
phase.
• The objective of this design is to transform the design
model into functional software.
• Component-level design defines the data structures,
algorithms, interface characteristics, and communication
mechanisms allocated to each component for the system
development.
• A complete set of software components is defined during
architectural design.
Designing class based components
Component Views
• OO View – A component is a set of collaborating
classes.
• Conventional View – A component is a functional
element of a program that incorporates
processing logic, the internal data structures
required to implement the processing logic, and
an interface that enables the component to be
invoked and data to be passed to it.
CLASS ELABORATION:
Class elaboration focuses on providing a detailed
description of attributes, interfaces and methods
before the development of the system activities.
 Basic Design Principles
• The design principles for component level
design comprises of the following:
The Open-Closed Principle (OCP)
The Liskov Substitution Principle (LSP).
Dependency Inversion Principle (DIP).
The Interface Segregation Principle (ISP).
The Release Reuse Equivalency Principle
(REP).
The Common Closure Principle (CCP)
The Common Reuse Principle (CRP)
 Component-Level Design Guidelines
• Components.
– Architectural component names should be drawn
– from the problem domain and should have meaning to all
stakeholders who view the architectural model.
Interfaces.
(1) lollipop representation of an interface should be used in lieu
of
the more formal UML box and dashed arrow approach, when
diagrams grow complex;
(2) for consistency, interfaces should flow from the left-hand side of
the component
box; (3) only those interfaces that are relevant to the component
under consideration
should be shown, even if other interfaces are available.
Dependencies and Inheritance.
to model dependencies from left to right and
inheritance from bottom (derived
classes) to top (base classes).
 Cohesion & Coupling
Cohesion
• Functional.
• Layer.
• Communicational.

Coupling
Content coupling.
Common coupling.
Control coupling.
Stamp coupling.
Data coupling.
Routine call coupling.
Type use coupling.
Inclusion or import coupling.
External coupling.
• [Link]
chitecture_design/component_based_archite
[Link]
 Conducting Component-Level Design
• Step 1. Identify all design classes that
correspond to the problem domain.
• Step 2. Identify all design classes that

correspond to the infrastructure

• domain.

• Step 3. Elaborate all design classes that are

not acquired as reusable

• components.

• Step 3a. Specify message details when classes

or components collaborate.
 Conducting Component-Level Design
• Step 3b. Identify appropriate interfaces for each component.
• Step 3c. Elaborate attributes and define data types and data
structures required to implement them.
• Step 3d. Describe processing flow within each operation in detail.
• Step 4. Describe persistent data sources (databases and files) and
identify
• the classes required to manage them.
• Step 5. Develop and elaborate behavioral representations for a
class or
• component.
• Step 6. Elaborate deployment diagrams to provide additional
implementa-
• tion detail.
• Step 7. Refactor every component-level design representation
and always
• consider alternatives.
•
 Conducting Component-Level Design
Recognizes all design classes that correspond to the problem domain as defined in the
analysis model and architectural model.
• Recognizes all design classes that correspond to the infrastructure domain.
• Describes all design classes that are not acquired as reusable components, and
specifies message details.
• Identifies appropriate interfaces for each component and elaborates attributes and
defines data types and data structures required to implement them.
• Describes processing flow within each operation in detail by means of pseudo code
or UML activity diagrams.
• Describes persistent data sources (databases and files) and identifies the classes
required to manage them.
• Develop and elaborates behavioral representations for a class or component. This
can be done by elaborating the UML state diagrams created for the analysis model
and by examining all use cases that are relevant to the design class.
• Elaborates deployment diagrams to provide additional implementation detail.
• Demonstrates the location of key packages or classes of components in a system by
using class instances and designating specific hardware and operating system
environment.
• The final decision can be made by using established design principles and
guidelines. Experienced designers consider all (or most) of the alternative design
solutions before settling on the final design model.
 User Interface Design
User interface is the front-end application view to which user interacts in
order to use the software. The software becomes more popular if its user
interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interface screens
There are two types of User Interface:
• Command Line Interface: Command Line Interface provides a command
prompt, where the user types the command and feeds to the system.
The user needs to remember the syntax of the command and its use.
• Graphical User Interface: Graphical User Interface provides the simple
interactive interface to interact with the system. GUI can be a
combination of both hardware and software. Using GUI, user interprets
the software.
• [Link]
olden-rules-of-user-interface-design-7a0fe1e
150b7
The Golden Rules of User Interface Design

1. Strive for consistency

2. Enable Frequent Users to Use Shortcuts
3. Offer informative feedback
4. Design dialogs to yield closure
5. Offer Simple Error Handling
6. Permit easy reversal of actions
7. Keep users in control
8. Reduce short-term memory load
• User Interface Design Activities
• GUI Requirement Gathering - The designers may like to
have list of all functional and non-functional requirements
of GUI.
• User Analysis - The designer studies who is going to use
the software GUI.
• Task Analysis - Designers have to analyze what task is to be
done by the software solution.
• GUI Design & implementation - Designers after having
information about requirements, tasks and user
environment, design the GUI and implements into code
and embed the GUI with working or dummy software in
the background. It is then self-tested by the developers.
• Testing - GUI testing can be done in various ways.
Organization can have in-house inspection, direct
involvement of users and release of beta version are few of
them. Testing may include usability, compatibility, user
acceptance etc.
 Questions
1. Explain the quality attributes considered in software design.
2. What do you mean by cohesion and coupling in software design?
3. Give the importance of refactoring in improving quality of software.
4. Differentiate between abstraction and refinement in software.
5. Explain design principles in software engineering
6. Discuss architectural patterns in detail
7. Explain architectural views.
8. What are class based components
9. Prepare architecture diagram for the biometric authentication software
10. Prepare a class based component level diagram for the ecommerce website
11. Explain 8 golden rules of user interface design.
12. What is the necessity for a good user interface.
13. What are the design principle for reducing the user’s memory load in user interface design.
14. Explain in detail user interface design issues.
15. Explain component level design.