Module III

Design Process

SE Module III 1
Design Process

SE Module III 2
 Design Process
• Software design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the software.
• Initially, the design is represented at a high level
of abstraction—a level that can be directly
traced to the specific system objective and more
detailed data, functional, and behavioral
requirements. As design iterations occur,
subsequent refinement leads to design
representations at much lower levels of
abstraction that can translated directly into
codes.
• During the design phase each of the elements of
the requirements model such as scenario-based,
class-based, flow oriented and behavioural
elements provides information that is necessary
to create the four design models required for Translating the requirements model into the design
complete specification of design. model

SE Module III 3
 Four designs the design phase produces are:
• Data/Class Design: The data/class design (sometimes referred to as data architecting) transforms class models
into design class realizations and the requisite data structures required to implement the software at a high level
of abstraction (the customer/user's view of data). The objects and relationships defined in the class diagram and
the detailed data content depicted by class attributes and other notation provide the basis for the data design
action.
• Architectural Design: Architectural design is concerned with designing the overall structure of software
system. It defines the relationship between major structural elements of the software, the architectural styles and
design patterns that can be used to achieve the requirements defined for the system, and the constraints that
affect the way in which architecture can be implemented.
• Interface Design: The user interface design describes how the software communicates with humans who use it
and with systems that interoperate with it. The usage scenarios and behavioral models provide much of the
information required for interface design
• Component Design: The component-level design transforms structural elements of the software architecture
into a procedural description of software components. Information obtained from the class-based models, flow
models, and behavioural models serve as the basis for component design.

SE Module III 4
Software Quality Guidelines and Attributes
• Throughout the design process, the quality of the evolving design is assessed with a series of technical
reviews.

Three characteristics that serve as a guide for the evaluation of a good design :
• The design should 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 should 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.

SE Module III 5
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
• (3) can be implemented in an evolutionary fashion, 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.
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.

SE Module III 6
Quality Attributes .
• Hewlett-Packard developed a set of software quality attributes that has been given the acronym FURPS.
The FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of
the functions that are delivered, and the security of the overall system.
• Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output
results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of
the program.
• Performance is measured using processing speed, response time, resource consumption, throughput,
and efficiency.
• Supportability combines extensibility, adaptability, and serviceability. These three attributes represent a
more common term, maintainability — and in addition, testability, compatibility, configurability (the
ability to organize and control elements of the software configuration), the ease with which a system
can be installed, and the ease with which problems can be localized.

SE Module III 7
The Evolution of Software Design
• More recent emphasis in software design has been on software architecture and the design patterns that can
be used to implement software architectures and lower levels of design abstractions.
• Growing emphasis on aspect-oriented methods model-driven development , and test-driven development
emphasize techniques for achieving more effective modularity and architectural structure in the designs
that are created.
• All of these methods have a number of common characteristics:
• (1) a mechanism for the translation of the requirements model into a design representation,
• (2) a notation for representing functional components and their interfaces,
• (3) heuristics for refinement and partitioning, and
• (4) guidelines for quality assessment.

SE Module III 8
 DESIGN CONCEPTS

A set of fundamental software design concepts has evolved over the history of software engineering. Each
provides the software designer with a foundation from which more sophisticated design methods can be applied.
Each can be used to partition software into individual components, separate or data structure detail from a
conceptual representation of the software, and establish uniform criteria that define the technical quality of a
software design.

SE Module III 9
Abstraction
• At the highest level of abstraction, a solution is stated in broad terms using the language of the problem
environment.
• At lower levels of abstraction, a more detailed description of the solution is provided.
• Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a
solution.
• Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented.
• As different levels of abstraction are developed, you work to create both procedural and data abstractions. A
procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name
of a procedural abstraction implies these functions, but specific details are suppressed.
• A data abstraction is a named collection of data that describes a data object
• When you consider a modular solution to any problem, many levels of abstraction can be posed. At the highest
level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower
levels of abstraction, a more detailed description of the solution is provided. Finally, at the lowest level of
abstraction, the solution is stated in a manner that can be directly implemented. A procedural abstraction refers
to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction
implies these functions, but specific details are suppressed. A data abstraction is a named collection of data that
describes a data object.

SE Module III 10
Architecture
• Software architecture alludes to “the overall structure of the software and the ways in which that structure
provides conceptual integrity for a system”.
• In its simplest form, architecture is the structure or organization of program components (modules), the manner
in which these components interact, and the structure of data that are used by the components.
• One goal of software design is to derive an architectural rendering of a system. This rendering serves as a
framework from which more detailed design activities are conducted. A set of architectural patterns enables a
software engineer to reuse design-level concepts.
• A set of properties should be specified as part of an architectural design.
• Structural properties define “the components of a system (e.g., modules, objects, filters) and the manner in
which those components are packaged and interact with one another.”
• Extra-functional properties address “ how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.

SE Module III 11
• Given the specification of these properties, the architectural design can be represented
using one or more of a number of different models.
• Structural models represent architecture as an organized collection of program
components.
• Framework models increase the level of design abstraction by attempting to identify
repeatable architectural design frameworks (patterns) that are encountered in similar types
of applications.
• Dynamic models address the behavioral aspects of the program architecture, indicating how
the structure or system configuration may change as a function of external events.
• Process models focus on the design of the business or technical process that the system
must accommodate.
• functional models can be used to represent the functional hierarchy of a system.

SE Module III 12
Shaw and Garlan describe a set of properties as part of an architectural design:
• Structural properties. This aspect of the architectural design representation defines
the components of a system (e.g., modules, objects, filters) and the manner in which
those components are packaged and interact with one another. For example, objects
are packaged to encapsulate both data and the processing that manipulates the data
and interact via the invocation of methods.
• Extra-functional properties. The architectural design description should address
how the design architecture achieves requirements for performance, capacity,
reliability, security, adaptability, and other system characteristics.
• Families of related systems. The architectural design should draw upon repeatable
patterns that are commonly encountered in the design of families of similar systems.
In essence, the design should have the ability to reuse architectural building blocks.

SE Module III 13
 Patterns
• A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring
problem within a certain context amidst competing concerns. Stated
• A design pattern describes a design structure that solves a particular design problem within a specific
context and amid “forces” that may have an impact on the manner in which the pattern is applied and used.
• The intent of each design pattern is to provide a description that enables a designer to determine
1. whether the pattern is applicable to the current work
2. whether the pattern can be reused (hence, saving design time)
3. whether the pattern can serve as a guide for developing a similar, but functionally or structurally different
pattern.

SE Module III 14
Separation of Concerns
• Separation of concerns is a design concept that suggests that 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.
• For two problems, p1 and p2, if the perceived complexity of p1 is greater than the perceived complexity of p2, it
follows that the effort required to solve p1 is greater than the effort required to solve p2. As a general case, this
result is intuitively obvious. It does take more time to solve a difficult problem. It also follows that the perceived
complexity of two problems when they are combined is often greater than the sum of the perceived complexity
when each is taken separately. This leads to a divide-and-conquer strategy—it’s easier to solve a complex
problem when you break it into manageable pieces. This has important implications with regard to software
modularity.

SE Module III 15
 Modularity
• Software is divided into separately named and addressable components, sometimes called modules, that are
integrated to satisfy problem requirements.
• It has been stated that “modularity is the single attribute of software that allows a program to be intellectually
manageable”
• The number of control paths, span of reference, number of variables, and overall complexity would make
understanding close to impossible. 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.
• If you subdivide software indefinitely the effort required to develop it will become negligibly small!
• As the number of modules grows, the effort (cost) associated with integrating the modules also grows.
• There is a number, M, of modules that would result in minimum development cost, but we do not have the
necessary sophistication to predict M with assurance.
• Modularize a design (and the resulting program) so that development can be more easily planned;
• software increments can be defined and delivered; changes can be more easily accommodated; testing and
debugging can be conducted more efficiently, and long-term maintenance can be conducted without serious
side effects.

SE Module III 16
• the effort (cost) to develop an individual software
module does decrease as the total number of modules
increases.
• Given the same set of requirements, more modules
means smaller individual size. However, as the number
of modules grows, the effort (cost) associated with
integrating the modules also grows. These
characteristics lead to a total cost or effort curve shown
in the figure. There is a number, M, of modules that
would result in minimum development cost, but we do
not have the necessary sophistication to predict M with
assurance.
• Under modularity or over modularity should be
avoided.
• You modularize a design (and the resulting program) so
that development can be more easily planned; software
increments can be defined and delivered; changes can
be more easily accommodated; testing and debugging
can be conducted more efficiently, and long-term
maintenance can be conducted without serious side
effects.

SE Module III 17
Information Hiding
• The principle of information hiding suggests that modules be “characterized by design decisions that (each)
hides from all others.”
• Information Hiding means modules should be specified and designed so that information (algorithms and
data) contained within a module is inaccessible to other modules that have no need for such information.
• Abstraction helps to define the procedural (or informational) entities that make up the software. Hiding
defines and enforces access constraints to both procedural detail within a module and any local data
structure used by the module.
• Because most data and procedural detail are hidden from other parts of the software, inadvertent errors
introduced during modification are less likely to propagate to other locations within the software.
• Hiding implies that effective modularity can be achieved by defining a set of independent modules that
communicate with one another only that information necessary to achieve software function. Abstraction
helps to define the procedural (or informational) entities that make up the software.

SE Module III 18
Functional Independence
• The concept of functional independence is a separation of concerns, modularity, and the concepts of
abstraction and information hiding.
• Functional independence is achieved by developing modules with “ singleminded” function and an “aversion”
to excessive interaction with other modules.
• Stated another way, you should design software so that each module addresses a specific subset of
requirements and has a simple interface when viewed from other parts of the program structure.
• Software with effective modularity, that is, independent modules, is easier to develop because function can be
compartmentalized and interfaces are simplified.
• Independent modules are easier to maintain (and test) because secondary effects caused by design or code
modification are limited, error propagation is reduced, and reusable modules are possible.
• To summarize, functional independence is a key to good design, and design is the key to software quality.
Independence is assessed using two qualitative criteria: cohesion and coupling.
• Cohesion is an indication of the relative functional strength of a module.
• Coupling is an indication of the relative interdependence among modules.

SE Module III 19
• A cohesive module performs a single task, requiring little interaction with other components in
other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing.
Although you should always strive for high cohesion (i.e., single-mindedness), it is often
necessary and advisable to have a software component perform multiple functions.
• Coupling is an indication of interconnection among modules in a software structure. Coupling
depends on the interface complexity between modules, the point at which entry or reference is
made to a module, and what data pass across the interface. In software design, you should strive
for the lowest possible coupling. Simple connectivity among modules results in software that is
easier to understand and less prone to a “ripple effect”, caused when errors occur at one location
and propagate throughout a system.

SE Module III 20
Refinement
• Refinement is actually a process of elaboration.
• Begin with a statement of function, then elaborate on the original statement, providing more and
more detail as each successive refinement (elaboration) occurs. You then elaborate on the original
statement, providing more and more detail as each successive refinement (elaboration) occurs.
• Refinement helps you to reveal low-level details as design progresses.
• Stepwise refinement is a top-down design strategy. . A program is developed by successively
refining levels of procedural detail. A hierarchy is developed by decomposing a macroscopic
statement of function (a procedural abstraction) in a stepwise fashion until programming language
statements are reached.

SE Module III 21
 Aspects
• An aspect is a representation of a crosscutting concern.
• It is important to identify aspects so that the design can properly accommodate them as refinement and
modularization occur.
• In an ideal context, an aspect is implemented as a separate module (component) rather than as software
fragments that are “scattered” or “tangled” throughout many components.
• To accomplish this, the design architecture should support a mechanism for defining an aspect—a module that
enables the concern to be implemented across all other concerns that it crosscuts.
• As requirements analysis occurs, a set of “concerns” is uncovered.
• These concerns “include requirements, use cases, features, data structures, quality-of-service issues, variants,
intellectual property boundaries, collaborations, patterns and contracts”.
• Ideally, a requirements model can be organized in a way that allows you to isolate each concern (requirement) so
that it can be considered independently.
• In practice, however, some of these concerns span the entire system and cannot be easily compartmentalized.
• As design begins, requirements are refined into a modular design representation. 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”.
SE Module III 22
 Refactoring
• An important design activity suggested for many agile methods, refactoring is a reorganization
technique that simplifies the design (or code) of a component without changing its function or
behavior.
• “Refactoring is the process of changing a software system in such a way that it does not alter the
external behavior of the code [design] yet improves its internal structure.”
• When software is refactored, the existing design is examined for redundancy, unused design
elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures,
or any other design failure that can be corrected to yield a better design.
• The result will be software that is easier to integrate, easier to test, and easier to maintain.

SE Module III 23
 Object-Oriented Design Concepts
The object-oriented (OO) paradigm is widely used in modern software engineering. OO design concepts such as classes and
objects, inheritance, messages, and polymorphism, among others.
Object
• An object is a tangible, real-world entity that is an instance of a class. It's a concrete item that exists in memory and has a
unique identity. For example, in a car racing game, you wouldn't just have the concept of a "Car" but specific objects like
myRedFerrari or myBluePorsche. Each of these objects has its own unique state.
Class
• A class is a blueprint or template for creating objects. It defines the structure and behavior that all objects of that type will
have. It's a logical construct, not a physical one in memory, until an object is created from it. The class Car would define
the shared characteristics of all cars, such as having a color and a speed, and the ability to accelerate or brake.
Attributes
• Attributes are the data members of a class that describe an object's state or characteristics. They are like variables that hold
information about the object. For the Car class, attributes might include color, speed, and numberOfDoors. Each object
created from this class will have its own unique values for these attributes (e.g., [Link] = "red").
Methods
• Methods are the functions or behaviors that an object can perform. They operate on the object's data (its attributes) and
define what an object can do. For the Car class, methods could be startEngine(), accelerate(), or brake(). When you call
[Link](), you are instructing that specific object to perform the action defined in the accelerate() method,
which would likely modify its speed attribute.
SE Module III 24
Inheritance
• Object-oriented systems allow classes to be defined in terms of other classes.
• Inheritance is the process of deriving new classes (sub classes or derived classes or child classes) from existing ones (super class or
base class or parent class).
• A subclass inherits visible properties and methods from its parent. Subclasses are not limited to the state and behaviors provided to
them by their superclass.
• Subclasses can add variables and methods to the ones they inherit from the superclass.
• Subclasses can also override inherited methods and provide specialized implementations for those methods.
• Using the inheritance mechanism, the programmer can build an inheritance tree, or class hierarchy, which is as deep as needed.
Methods and variables are inherited down through the levels.
• In general, the farther down in the hierarchy a class appears, the more specialized its behavior.
• Object-oriented Design supports different types of inheritances, including single inheritance, multi-level inheritance, multiple
inheritance, multipath inheritance, hierarchical inheritance and hybrid inheritance
Polymorphism
• Polymorphism means the ability to take more than one form.
• For example, consider the operation of addition. For two numbers, the operation will generate a sum. If the operands are strings,
then the operation would produce a third string by concatenation.
• Polymorphism plays an important role in allowing objects having different internal structure to share the same external interface.
• This means that a general class operation may be accessed in the same manner even though specific actions associated with each
operation may differ.
• Polymorphism is extensively used in implementing inheritance.

SE Module III 25
• There are two types of polymorphism in object-oriented languages:
o Static Polymorphism also known as compile time polymorphism: Polymorphism that is resolved during
compiler time is known as static polymorphism. Method overloading is an example of compile time
polymorphism.
o Dynamic Polymorphism also known as runtime polymorphism: Dynamic polymorphism is a process in which
a call to an overridden method is resolved at runtime.
Message Passing
• In object-oriented languages, you can consider a running program under execution as a pool of objects where
objects are created for 'interaction' and later destroyed when their job is over.
• This interaction is based on 'messages' which are sent from one object to another asking the recipient object to apply
one of its own methods on itself and hence, forcing a change in its state.
• The objects are made to communicate or interact with each other with the help of a mechanism called message
passing.
• The methods of any object may communicate with each other by sending and receiving messages in order to change
the state of the object.
• An object may communicate with other objects by sending and receiving messages to and from their methods in
order to change either its own state or the state of other objects taking part in this communication or that of both.
• An object can both send and receive messages. The messages are sent and received by passing various variables
among specific methods using the signature of the methods. Every methods has a well-defined and structured
signature.

SE Module III 26
Design Classes
• A set of design classes that refine the analysis classes by providing design detail that will enable the classes
to be implemented, and implement a software infrastructure that supports the business solution.
Five different types of design classes, each representing a different layer of the design architecture, can be
developed.
• User interface classes define all abstractions that are necessary for human-computer interaction (HCI) and
often implement the HCI in the context of a metaphor.
• Business domain classes identify the attributes and services (methods) that are required to implement some
element of the business domain that was defined by one or more analysis classes.
• Process classes implement lower-level business abstractions required to fully manage the business domain
classes.
• Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the
software.
• System classes implement software management and control functions that enable the system to operate and
communicate within its computing environment and with the outside world.

SE Module III 27
Four characteristics of a well-formed design class:
• Complete and sufficient. A design class should be the complete encapsulation of all attributes and methods that
can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class.
• Primitiveness. Methods associated with a design class should be focused on accomplishing one service for the
class. Once the service has been implemented with a method, the class should not provide another way to
accomplish the same thing.
• High cohesion. A cohesive design class has a small, focused set of responsibilities and single-mindedly applies
attributes and methods to implement those responsibilities.
• Low coupling. Within the design model, it is necessary for design classes to collaborate with one another.
However, collaboration should be kept to an acceptable minimum.

SE Module III 28
THE DESIGN MODEL

SE Module III 29
Introduction
• The design model can be viewed in two different dimensions as illustrated in Figure.
• The process dimension indicates the evolution of the design model as design tasks are executed
as part of the software process.
• The abstraction dimension represents the level of detail as each element of the analysis model is
transformed into a design equivalent and then refined iteratively
• The elements of the design model use many of the same UML diagrams that were used in the
analysis model. The difference is that these diagrams are refined and elaborated as part of design;
more implementation-specific detail is provided, and architectural structure and style,
components that reside within the architecture, and interfaces between the components and with
the outside world are all emphasized.

SE Module III 30
SE Module III 31
Data Design Elements
• Data design (sometimes referred to as data architecting ) creates a model of data and/or
information that is represented at a high level of abstraction (the customer/user’s view of data).
• This data model is then refined into progressively more implementation-specific
representations that can be processed by the computer-based system.
• At the program-component level, the design of data structures and the associated
algorithms required to manipulate them is essential to the creation of high- quality
applications.
• At the application level, the translation of a data model (derived as part of requirements
engineering) into a database is pivotal to achieving the business objectives of a system.
• At the business level, the collection of information stored in disparate databases and
reorganized into a “data warehouse” enables data mining or knowledge discovery that can
have an impact on the success of the business itself.
• In every case, data design plays an important role.

SE Module III 32
 Architectural Design Elements
• The architectural design for software is the equivalent to the floor plan of a house.
• Architectural design elements give us an overall view of the software.
• The architectural model is derived from three sources:
1. Information about the application domain for the software to be built;
2. Specific requirements model elements such as use cases or analysis classes, their
relationships and collaborations for the problem at hand;
3. The availability of architectural styles and patterns.
The architectural design element is usually depicted as a set of interconnected subsystems,
often derived from analysis packages within the requirements model.
Each subsystem may have its own architecture (e.g., a graphical user interface might be
structured according to a preexisting architectural style for user interfaces).

SE Module III 33
Interface Design Elements
• The interface design elements for software depict information flows into and out of a
system and how it is communicated among the components defined as part of the
architecture.
• There are three important elements of interface design:
1. The user interface (UI),
2. External interfaces to other systems, devices, networks, or other producers or
consumers of information, and
3. Internal interfaces between various design components.
• These interface design elements allow the software to communicate externally and enable
internal communication and collaboration among the components that populate the
software architecture.
• UI design (increasingly called usability design ) is a major software engineering action
• Usability design incorporates aesthetic elements (e.g., layout, color, graphics, interaction
mechanisms), ergonomic elements (e.g., information layout and placement, metaphors, UI
navigation), and technical elements (e.g., UI patterns, reusable components). In general, the
UI is a unique subsystem within the overall application architecture
SE Module III 34
Component-Level Design Elements
• The component-level design transforms structural elements of the software architecture into a procedural description of
software components.
• Information obtained from the class-based models, flow models, and behavioral models serve as the basis for
component design.
• The component-level design for software fully describes the internal detail of each software component.
• To accomplish this, the component-level design defines data structures for all local data objects and algorithmic detail
for all processing that occurs within a component and an interface that allows access to all component operations
(behaviours).
• Within the context of object-oriented software engineering. a component is represented in UML diagrammatic form.
• The design details of a component can be modelled at many different levels of abstraction.
• A UML activity diagram can be used to represent processing logic.
• Detailed procedural flow for a component can be represented using either pseudocode or some other diagrammatic
form (e.g.. flowchart or box diagram).
• Algorithmic structure follows the rules established for structured programming.
• Data structures, selected based on the nature of the data objects to be processed, are usually modelled using pseudocode
or the programming language to be used for implementation.

SE Module III 35
Deployment-Level Design Elements
• Deployment-level design elements indicate how software functionality and subsystems will
be allocated within the physical computing environment that will support the software.
• For example, the elements of the SafeHome product are configured to operate within three
primary computing environments—a homebased PC, the SafeHome control panel, and a
server housed at CPI Corp. (providing Internet-based access to the system). In addition,
limited functionality may be provided with mobile platforms.
• During deployment-level design, a UML deployment diagram in descriptor form is
developed showing the computing environments and the subsystems (functionality) housed
within each computing element.
• In the descriptor form, the deployment diagram does not identify the specific computing
environment. The descriptor deployment diagram is then refined into instance form during
the latter stages of design to include the details of the specific computing environments.

SE Module III 36