UNIT-4

Design Engineering

1
Design
 Software design is a process to transform user requirements
into some suitable form, which helps the programmer in
software coding and implementation.
 The software design phase is the first step in SDLC (Software
Design Life Cycle), which moves the concentration from the
problem domain to the solution domain.

2
Design and Quality
 the design must implement all of the explicit
requirements contained in the analysis model,
and it must accommodate all of the implicit
requirements desired by the customer.
 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.

3
Quality Guidelines
1. A design should exhibit an architecture that (1) has been created using
recognizable architectural styles or patterns, (2) is composed of components
that exhibit good design characteristics and (3) can be implemented in an
evolutionary fashion
1. For smaller systems, design can sometimes be developed linearly.
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.
6. A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
7. A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.
8. A design should be represented using a notation that effectively communicates
its meaning.

4
Fundamental Concepts
 Abstraction—data, procedure, control
 Architecture—the overall structure of the software
 Patterns—”conveys the essence” of a proven design solution
 Separation of concerns—any complex problem can be more easily
handled if it is subdivided into pieces
 Modularity—compartmentalization of data and function
 Hiding—controlled interfaces
 Functional independence—single-minded function and low coupling
 Refinement—elaboration of detail for all abstractions
 Aspects—a mechanism for understanding how global requirements
affect design
 Refactoring—a reorganization technique that simplifies the design
 OO design concepts—Appendix II
 Design Classes—provide design detail that will enable analysis
classes to be implemented

5
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
1. Functional Abstraction
2. Data Abstraction
Functional Abstraction
 A module is specified by the method it performs.
 The details of the algorithm to accomplish the functions are not visible to the user
of the function.
 Functional abstraction forms the basis for Function oriented design
approaches.
Data Abstraction
 Details of the data elements are not visible to the users of data. Data Abstraction
forms the basis for Object Oriented design approaches.

6
Architecture
“The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.”
•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.

7
Patterns
The pattern simply means a repeated form or design in which the
same shape is repeated several times to form a pattern.
Design Pattern Template
Pattern name—describes the essence of the pattern in a short but
expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is
applicable
Structure—describes the classes that are required to implement the
pattern
Participants—describes the responsibilities of the classes that are
required to implement the pattern
Collaborations—describes how the participants collaborate to carry out
their responsibilities
Consequences—describes the “design forces” that affect the pattern and
the potential trade-offs that must be considered when the pattern is
implemented
Related patterns—cross-references related design patterns 8
Pattern types

9
Patterns
Prototype : A fully initialized instance to be copied or cloned
Builder - Separates the construction of a complex object from its
representation so that the same construction process can create different
representations.
Example : A software development team that creates new software using a
variety of libraries and frameworks.

Singleton - A class of which only a single instance can exist

Example : President of a country

Factory Method - Creates a family of object types.

Example : In an organisation HR works as factory method. Here
development team request type of resource need to HR. Based on request
type, HR provide resource to Development team.

10
Separation of Concerns
 Any complex problem can be more easily
handled if it is subdivided into pieces that can
each be solved and/or optimized independently
 A concern is a feature or behavior that is
specified as part of the requirements model for
the software
 By separating concerns into smaller, and
therefore more manageable pieces, a problem
takes less effort and time to solve.

11
Modularity
 “Modularity is the single attribute of software that allows
a program to be intellectually manageable".
 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.
 In almost all instances, you should break the design into
many modules, hoping to make understanding easier
and as a consequence, reduce the cost required to build
the software.

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

13
Why Information Hiding?
 reduces the likelihood of “side effects”
 limits the global impact of local design
decisions
 emphasizes communication through
controlled interfaces
 discourages the use of global data
 leads to encapsulation—an attribute of
high quality design
 results in higher quality software

14
Functional Independence
 Functional independence is achieved by developing
functions that perform only one kind of task and do not
excessively interact with other modules.
 It is measured using two criteria:

 Cohesion: It measures the relative function strength of a

module. cohesion is the internal glue that keeps the
module together. A good software design will have high
cohesion.

 Coupling: It measures the relative interdependence

among modules. Coupling is the measure of the degree
of interdependence between the modules. A good
software will have low coupling.
15
Functional Independence

16
 Disadvantages of high
coupling:
Disadvantages of high coupling:
 Increased complexity: High coupling increases the
interdependence between modules, making the
system more complex and difficult to understand.
 Reduced flexibility: High coupling makes it more
difficult to modify or replace individual components
without affecting the entire system.
 Decreased modularity: High coupling makes it more
difficult to develop and test modules in isolation,
reducing the modularity and reusability of code.

17
 Disadvantages of low
cohesion:
Disadvantages of low cohesion:
 Increased code duplication: Low cohesion can lead to
the duplication of code, as elements that belong
together are split into separate modules.
 Reduced functionality: Low cohesion can result in
modules that lack a clear purpose and contain
elements that don’t belong together, reducing their
functionality and making them harder to maintain.
 Difficulty in understanding the module: Low cohesion
can make it harder for developers to understand the
purpose and behavior of a module, leading to errors
and a lack of clarity. 18
Refinement
 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.
 Abstraction is concerned with hiding lower levels of
detail; it moves from lower to higher levels.
 Refinement is the movement from higher levels of
detail to lower levels. 19
Aspects
 Consider two requirements, A and B. Requirement A crosscuts
requirement B “if a software decomposition [refinement] has been
chosen in which B cannot be satisfied without taking A into account.
 A concern is a feature or behavior that is specified as part of the
requirements model for the software.
 An aspect is a representation of a crosscutting concern.
 Cross-cutting concerns are parts of a program that rely on or must
affect many other parts of the system.
 The concerns include : requirements, use cases, features, data
structures, quality-of-service issues, variants, intellectual property
boundaries, collaborations, patterns and contracts.
 Concerns span the entire system and cannot be easily
compartmentalized. Consider two requirements, A and B.
Requirement A crosscuts requirement B. ie. B cannot be satisfied
without taking A into account
20
Refactoring
 Refactoring in software design means reconstructing the
design to reduce complexity and simplify it without
affecting the behavior or its functions.
 You get the following benefits from refactoring:
1. Code size is often reduced
2. Confusing code is restructured into simpler code
When do we refactor?
 Before you add new features, make sure your design
and current code is “good” this will help the new code be
easier to write.
 When you need to fix a bug
 When you do a peer review
 During a code review
21
OO Design Concepts
 Class and Object
 Design classes
 Inheritance—all responsibilities of a superclass is
immediately inherited by all subclasses
 Messages—stimulate some behavior to occur in the
receiving object
 Polymorphism—a characteristic that greatly reduces the
effort required to extend the design

22
Design Classes
 Analysis classes are refined during design to become entity
classes
 In the class diagram, there are model classes as Control
classes, Entity Classes, and Boundary Classes.
 Boundary classes are developed during design to create the
interface (e.g., interactive screen or printed reports) that the user
sees and interacts with as the software is used.
 Boundary Classes: Boundary classes represent the interaction
points between the system and its environment. They are
responsible for handling the interaction between the system and its
users or other external systems. Boundary classes encapsulate
the user interface, input/output operations, and communication
protocols that enable the system to communicate with its
environment
 Boundary classes are designed with the responsibility of managing
the way entity objects are represented to users. .

23
Design Classes
 Controller classes are designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from
entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or between the user
and the application
 Control Classes: Control Classes are those classes that contain the
application logic or the control flow logic of the system.
 They are responsible for coordinating and controlling the interactions
between different objects or components of the system.
 Control classes implement the business rules of the application and
perform the necessary operations to accomplish the defined use
cases.

24
Design Classes
 Entity Classes: Entity Classes are classes that represent real-world
objects or concepts within a domain.
 They encapsulate the data associated with the objects and provide the
methods to manipulate that data. Entity Classes also define the
relationships between different objects in the system.
 In summary, Control classes encapsulate system logic,
 Entity classes encapsulate real-world objects or
concepts, and
 Boundary classes represent the interaction points
between the system and its environment.

25
Design Model Elements
Data design elements
Data design is the first design activity, which results in less complex,
modular and efficient program structure. The information domain
model developed during analysis phase is transformed into data
structures needed for implementing the software.
 The data design element produced a model of data that represent a
high level of abstraction.
 This model is then more refined into more implementation specific
representation which is processed by the computer based system.
 The structure of data is the most important part of the software design.
Architectural design elements
 The architecture design elements provides us overall view of the
system.
 The architectural design element is generally represented as a set of
interconnected subsystem that are derived from analysis packages in
the requirement model.

26
Design Model Elements
Interface design elements
 The interface design elements for software represents the
information flow within it and out of the system.
 They communicate between the components defined as part of
architecture.

 Following are the important elements of the interface design:

1. The user interface
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.

27
Golden rules of user interface design

 Make user interfaces consistent

 Allow users to navigate easily via shortcuts
 Provide informative feedback
 Design dialog to yield closure
 Prevent error as much as possible
 Allow users ways to reverse their actions easily
 Support internal locus of control
 Minimize memory load

28
 Golden rules of user interface design

 Make user interfaces consistent

Consistency is important in user interface design, as it helps users to
understand and learn how to use an application. Consistent design
elements such as icons, color schemes, and navigation menus should be
used throughout the application.
Consistency in UI design is concerned with making sure elements in a
user interface are uniform.
 Allow users to navigate easily via shortcuts
Expert users, or users who frequent your website or use your product
regularly, need shortcuts to move quickly through the interface.
Just like how most Windows users make use of the shortcut CTRL + C to
quickly copy text and CTRL + V to paste it, you need to make navigation
and operating user interfaces easy through shortcuts.

29
 Golden rules of user interface design

 Provide informative feedback

 Provide feedback through readable UI copy for all user moves.
 For example, when users are asked to create a password, your UI
should offer information on how strong it should be by either giving an
example of a strong password or using symbols that demonstrate how
strong the user’s password currently is.

 A great example is DropBox’s signup form. It shows the strength of a

user’s password through a sleek bar. When I added just my name in
the password field, it signaled how weak my password was through
that one bar.

30
 Golden rules of user interface design

 Design dialog to yield closure

Sequences of actions should be organized into groups with a
beginning, middle, and end.
Informative feedback at the completion of a group of actions gives
users the satisfaction of accomplishment, a sense of relief, a
signal to drop contingency plans from their minds, and an indicator
to prepare for the next group of actions.”
A great example is taking users to a Thank You page with a
summary after they complete an order, informing them it’s
confirmed.

31
 Golden rules of user interface design

 Prevent error as much as possible

Make the UI as easy to use as possible by preventing
serious user errors. This is also where usability
testing comes in. As a designer, you need to ensure
everything works as intended by testing the design with
users before launching.

32
 Golden rules of user interface design

 Support internal locus of control

 Experienced users strongly desire the sense that they are in charge of
the interface and that the interface responds to their actions. They
don’t want surprises or changes in familiar behavior, and they are
annoyed by tedious data-entry sequences, difficulty in obtaining
necessary information, and inability to produce their desired
result,” says Shneiderman.
 A great example of keeping users in control is when someone is about
to exit Microsoft Office and is asked by the system if they’re sure they
want to exit without saving their work. Not only does this make the
user feel in control, but it also ensures that in case of an accidental
exit, their work is not lost.

33
 Golden rules of user interface design

Minimize memory load

 A key rule for making user interfaces easy for people to use is
minimizing cognitive load. Cognitive load (or memory load) can reduce
a user’s capacity to perform important tasks, so it’s critical that
computers take over the burden of memory from them as much as
they can.
 For instance, don’t make users re-enter personal information every
time they’re buying from your website or add their email address and
name every time they log into your website.
 While designing, always choose recognition over recall to enable
users to complete their tasks quickly and without hassle

34
Design Model Elements
Component level diagram elements
 The component level design for software is similar to the set of
detailed specification of each room in a house.
 The component level design for the software completely describes
the internal details of the each software component.
 The processing of data structure occurs in a component and an
interface which allows all the component operations.
 In a context of object-oriented software engineering, a component
shown in a UML diagram.
 The UML diagram is used to represent the processing logic.

35
Design Model Elements
Deployment level design elements
 The deployment level design element shows the software
functionality and subsystem that allocated in the physical
computing environment which support the software.
 Following figure shows three computing environment as shown.
These are the personal computer, the CPI server and the Control
panel.

36
Component Level Design
 Component-based architecture focuses on the
decomposition of the design into individual
functional or logical components that represent
well-defined communication interfaces
containing methods, events, and properties.
 The primary objective of component-based
architecture is to ensure component
reusability.
 A component is a software object, intended to
interact with other components, encapsulating
certain functionality or a set of functionalities.
37
Component Based Design Principles
 The software system is decomposed into reusable, cohesive, and encapsulated
component units.

Examples of reusable software components include1:Libraries: These are

collections of pre-built functions or classes that can be called from within an
application.
 Frameworks: Frameworks are collections of reusable components that are
designed to work together to support the development of a specific type of
application.
 Modules: Modules are self-contained units of code that can be imported and used
in other applications
 Reusable components can be requirements specifications, design documents,
source code, user interfaces, user documentation, or any other items associated
with software2.

38
Component Based Design Principles
 Each component has its own interface that specifies required ports and provided
ports; each component hides its detailed implementation.
 A component should be extended without the need to make internal code or
design modifications to the existing parts of the component.
 Depend on abstractions component do not depend on other concrete
components, which increase difficulty in expendability.
 Connectors connected components, specifying and ruling the interaction among
components. The interaction type is specified by the interfaces of the
components.

 Data encapsulation is a familiar property in object-oriented programming. It is not

only useful for modelling things in the real world, but it also facilitates reuse by
enabling the creation of multiple instances of the same class, each with its own
identity and private data

39
Component Level Design Guidelines
 Attains architectural component names from the problem
domain and ensures that they have meaning to all
stakeholders who view the architectural model.
 Extracts the business process entities that can exist
independently without any associated dependency on other
entities.
 Recognizes and discover these independent entities as
new components.
 Uses infrastructure component names that reflect their
implementation-specific meaning.
 Models any dependencies from left to right and inheritance
from top (base class) to bottom (derived classes).
 Model any component dependencies as interfaces rather
than representing them as a direct component-to-
component dependency.
40
Component Level Design Steps
 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.

41
Deployment Level Design
 The main purpose of the deployment diagram is to represent how
software is installed on the hardware component.
 Deployment diagrams are important for visualizing, specifying, and
documenting embedded, client/server, and distributed systems and
also for managing executable systems through forward and reverse
engineering.
 It depicts in what manner a software interacts with hardware to
perform its execution.
 The deployment diagram consist of the following notations:
1. A component
2. An artifact
3. An interface
4. A node

42
Software Architecture
 The architecture of a system describes its major components,
their relationships (structures), and how they interact with each
other.
 Software architecture and design includes several contributory
factors such as Business strategy, quality attributes, human
dynamics, design, and IT environment.

43
Why Architecture?
The architecture is not the operational software. Rather,
it is a representation that enables a 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
Why is Architecture Important?
 Representations of software architecture are an enabler
for communication between all parties (stakeholders)
interested in the development of a computer-based
system.
 The architecture highlights early design decisions that
will have a profound impact on all software engineering
work that follows and, as important, on the ultimate
success of the system as an operational entity.
 Architecture “constitutes a relatively small, intellectually
graspable mode of how the system is structured and
how its components work together”.

45
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 by analyzing the
known properties of its constituent parts.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures

46
Data-Centered Architecture
 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.
 This data-centered architecture will promote integrability.

47
Data-Centered Architecture

48
Data-Centered Architecture
Advantage of Data centered architecture
 Repository of data is independent of clients

 Client work independent of each other

 It may be simple to add additional clients.

 Modification can be very easy

49
 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. 50
Data-Flow Architecture
Advantages of Data Flow architecture
 It encourages upkeep, repurposing, and
modification.
 With this design, concurrent execution is supported.
The disadvantage of Data Flow architecture
 It frequently degenerates to batch sequential
system
 Data flow architecture does not allow applications
that require greater user engagement.
 It is not easy to coordinate two different but related
streams

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

52
Call and Return architectures

53
Call and Return architectures
1. Architecture of the main program or subprogram:

 The program is broken down into smaller components

and organized in a hierarchical fashion. The main
program, which is separated into subprograms in the
hierarchy, invokes several software components.
2. Architecture for Remote Procedure Calls

 The main program or subprogram’s components are

scattered throughout a network of several computers.
 The basic objective is to raise performance.

54
Object Oriented architecture
 Object-Oriented Architecture is an important concept for
developing software. It is a design paradigm based on the
division of responsibilities for an application or system into
individual reusable and self-sufficient objects
 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-oriented architecture An architecture in
which everything (processes, files, I/O operations, etc.) is
represented as an object. Objects are data structures in
memory that may be manipulated by the total system
(hardware and software); they provide a high-level
description that allows for a high-level user interface
55
Object Oriented architecture
Characteristics of Object Oriented architecture
 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture
 It enables the designer to separate a challenge into a
collection of autonomous objects.
 Other objects are aware of the implementation details of
the object, allowing changes to be made without having
an impact on other objects.
.

56
Object Oriented architecture
.

57
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.
 One common example of this architectural style is OSI-
ISO (Open Systems Interconnection-International
Organisation for Standardisation) communication
system.
58
Layered Architecture

59
Thank You…

60