Unit-3

Topics
• Design Engineering
• Design process and Design quality
• Design concepts, the design model
• Creating an architectural design
• Software architecture
• Data design
• Architectural styles and patterns
• Architectural Design
• Conceptual model of UML
• Basic structural modelling
• Types of relationships
• Types of diagrams
Introduction
• The process of creating software methods, functions, objects, and the
general structure and interaction of your code such that the resulting
functionality meets the needs of your users is known as software
design.
• Software design is a vital activity during the process of software
development.
• Software design serves as a basis for code generation & testing.so
software design is intermediate process which translates the analysis
model to design model.
Design process and Design quality
Software design is an iterative process using which the user requirements can be
translated into the software product.
Characteristics of good design:
• The good design should implement all the requirements specified by the customer
even if there are some implicit requirements of the software product then those
requirements should also be implemented by the software design.
• The design should be simple enough so that the software can ebe understood
easily by the developers,testers and customers.
• The design should be comphrensive. That means it should provide complete
picture of software.
Quality guidelines:
In order to evaluate the quality of a design representation, the software team must
establish technical criteria for good design. Guide lines are as follows
• A design should exhibit an architecture that
➢has been created using recognizable architectural styles or patterns,
➢is composed of components that exhibit good design characteristics (these are
discussed later in this chapter),
➢can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing.
• A design should be modular; that is, the software should be logically partitioned
into elements or subsystems.
• A design should contain distinct representations of data, architecture, interfaces,
and components.
• A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
• A design should lead to components that exhibit independent functional
characteristics.
• A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
• A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.
• A design should be represented using a notation that effectively communicates its
meaning.
Design Quality in Software Engineering:
Design quality in software engineering refers to the characteristics of a software
system that make it effective, efficient, reliable, and maintainable. Several factors
contribute to design quality in software engineering:
• Modularity: The software should be modular, with components that can be
developed, tested, and maintained independently. Modularity enhances
maintainability and code reusability.
• Scalability: The software should be scalable, capable of handling increased load
or user base without significant performance degradation.
• Reliability: The software should be reliable and robust, performing consistently
under various conditions and handling errors gracefully.
• Performance: The software should be optimized for speed and resource usage,
ensuring efficient operation even under high loads.
• Usability: The user interface and overall user experience should be intuitive,
making it easy for users to interact with the software.
• Security: The software should be secure, protecting against unauthorized access,
data breaches, and other security threats.
• Maintainability: The software should be easy to maintain and update. Clean
code, good documentation, and adherence to coding standards contribute to
maintainability.
• Flexibility: The design should be flexible, allowing for future changes and
enhancements without requiring a complete overhaul of the system.
• Testability: The software should be designed in a way that facilitates testing. This
includes the ability to isolate components for unit testing and providing hooks for
automated testing.
Design concepts
Design concepts in software engineering encompass a wide range of principles, patterns, and
practices that guide the process of creating software solutions. These concepts help software
engineers design systems that are efficient, maintainable, scalable, and reliable. Here are some
fundamental design concepts in software engineering:
Abstraction:
• Definition: Hiding complex implementation details and showing only the necessary features of an
object.
• Importance: Simplifies the system's architecture, making it easier to understand and work with.
• 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
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. A
set of architectural patterns enables a software engineer to solve common design
problems.
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.
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
• whether the pattern is applicable to the current work
• whether the pattern can be reused (hence, saving design time)
• whether the pattern can serve as a guide for developing a similar, but functionally
or structurally different pattern.
Modularity:
• Definition: Breaking down a software system into smaller, self-contained
modules.
• Importance: Enhances maintainability, reusability, and collaboration among
developers.
Modularity is the most common manifestation of separation of concerns. 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! Unfortunately, other forces come into
play, causing this conclusion to be (sadly) invalid. Referring to Figure
8.2, 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.
• The curves shown in Figure 8.2 do provide useful qualitative guidance when modularity is
considered. You should modularize, but care should be taken to stay in the vicinity of M.
Undermodularity or overmodularity 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.
• Information Hiding: The principle of information hiding suggests that modules be “characterized
by design decisions that (each) hides from all others.” In other words, 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.
• 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.
Hiding defines and enforces access constraints to both procedural detail within a module and any
local data structure used by the module. The use of information hiding as a design criterion for
modular systems provides the greatest benefits when modifications are required during testing and
later during software maintenance. 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.
• Functional Independence: The concept of functional independence is a direct outgrowth of
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. 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.
•
• 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.
•
• Refinement: 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.

Refinement is actually a process of elaboration begins with a statement of function (or description of
information) that is defined at a high level of abstraction. 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.

• Refactoring: An important design activity for many agile methods is refactoring 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.
• Design Classes: As the design model evolves, you will define 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). In many cases, HCI occurs within the context of a metaphor (e.g., a checkbook, an order
form, a fax machine), and the design classes for the interface may be visual representations of the
elements of the metaphor.

Business domain classes are often refinements of the analysis classes. The classes identify the
attributes and services (methods) that are required to implement some element of the business
domain.
• 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.
Design model
• The design model can be viewed in two different dimensions as illustrated in
Figure 8.4. 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. Referring to
Figure 8.4, the dashed line indicates the boundary between the analysis and design
models. The analysis model slowly blends into the design and a clear distinction is
less obvious.

• The elements of the design model use 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.
• You should note, however, that model
elements indicated along the
horizontal axis are not always
developed in a sequential fashion. The
deployment model is usually delayed
until the design has been fully
developed.
• Architectural Design Elements: The architectural design for software is the equivalent to the
floor plan of a house. The floor plan gives us an overall view of the house. Architectural
design elements give us an overall view of the software. The architectural model is derived from
three sources:
• information about the application domain for the software to be built;
• specific requirements model elements such as data flow diagrams or analysis classes, their
relationships and collaborations for the problem at hand; and
• the availability of architectural styles and patterns.
• The architectural design element is usually depicted as a set of interconnected subsystems,
• Each subsystem may have it’s own architecture
 SOFTWARE ARCHITECTURE

• Software architecture must model the structure of a system and the manner in
which data and procedural components collaborate with one another.
• The software architecture of a program or computing system is the structure or
structures of the system, which comprise software components, the externally
visible properties of those components, and the relationships among them.
• The architecture is not the operational software. Rather, it is a representation that
enables you to
• analyze the effectiveness of the design in meeting its stated requirements
• architectural alternatives at a stage when making design changes is still relatively
easy
• reduce the risks associated with the construction of the software.
• There is a distinct difference between the terms architecture and design. A design is an instance of
an architecture similar to an object being an instance of a class. For example, consider the client-
server architecture. I can design a network-centric software system in many different ways from
this architecture using either the Java platform (Java EE) or Microsoft platform (.NET framework).
So, there is one architecture, but many designs can be created based on that architecture.
Architectural design focuses on the representation of the structure of software components, their
properties, and interactions.
Why Is Architecture Important?
Three key reasons that software architecture is 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 model of how
the system is
• structured and how its components work together”.
Architectural genre
• The architectural genre will often dictate the specific architectural approach to the structure that
must be built. In the context of architectural design, genre implies a specific category within the
overall software domain. Within each category, you encounter a number of subcategories. For
example, within the genre of buildings, you would encounter the following general styles: houses,
condos, apartment buildings, office buildings, industrial building, warehouses, and so on.
suggests the following architectural genres for
software-based systems:
• Artificial intelligence—Systems that simulate or augment human cognition, locomotion, or other
organic processes.
• Commercial and nonprofit—Systems that are fundamental to the operation of a business
enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing data, for
connecting users of that data, or for presenting data at the edge of an infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia artifacts.
• Devices—Systems that interact with the physical world to provide some point service for an
individual.
• Entertainment and sports—Systems that manage public events or that provide a large group
entertainment experience.
• Financial—Systems that provide the infrastructure for transferring and managing money and other
securities.
• Games—Systems that provide an entertainment experience for individuals or groups.
• Government—Systems that support the conduct and operations of a local, state, federal, global, or
other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical research.
• Military—Systems for consultation, communications, command, control, and intelligence (C4I) as
well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic software services.
• Platforms—Systems that sit just above operating systems to provide advanced services.
• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point service.
ARCHITECTURAL STYLES
Architectural style describes a system category that encompasses
• a set of components (e.g., a database, computational modules) that perform a function required by a
system;
• a set of connectors that enable “communication, coordination and cooperation” among
• components;
• constraints that define how components can be integrated to form the system; and
• semantic models that enable a designer to understand the overall properties of a system by
analyzing the known properties of its constituent parts.
An architectural style is a transformation that is imposed on the design of an entire system. The intent
is to establish a structure for all components of the system.
An architectural pattern, like an architectural style, imposes a
transformation on the design of an architecture. However, a pattern
differs from a style in a number of fundamental ways:
• the scope of a pattern is less broad, focusing on one aspect of the
architecture rather than the architecture in its entirety;
• a pattern imposes a rule on the architecture, describing how the
software will handle some aspect of its functionality at the
infrastructure level (e.g., concurrency)
• architectural patterns tend to address specific behavioral issues within
the context of the architecture (e.g., how real-time applications handle
synchronization or interrupts).
• Patterns can be used in conjunction with an architectural style to shape
the overall structure of a system.
• Data-centered architectures. A data store (e.g., a file or database) resides at the
center of this architecture and is accessed frequently by other components that
update, add, delete, or otherwise modify data within the store. Figure 9.1
illustrates a typical data-centered style. Client software accesses a central
repository. In some cases the data repository is passive. That is, client software
accesses the data independent of any changes to the data or the actions of other
client software. Data-centered architectures promote integrability. That is, existing
components can be changed and new client components added to the architecture
without concern about other clients (because the client components operate
independently). In addition, data can be passed among clients using the blackboard
mechanism (i.e., the blackboard component serves to coordinate the transfer of
information between clients). Client components independently execute processes.
• Data-flow architectures. This architecture is applied when input data are to be
transformed through a series of computational or manipulative components into
output data. A pipe-and-filter pattern (Figure 9.2) has a set of components, called
filters, connected by pipes that transmit data from one component to the next.
Each filter works independently of those components upstream and downstream,
is designed to expect data input of a certain form, and produces data output (to the
next filter) of a specified form. However, the filter does not require knowledge of
the workings of its neighboring filters.
• Call and return architectures. This architectural style enables you to achieve a
program structure that is relatively easy to modify and scale. A number of
substyles exist within this category:
• Main program/subprogram architectures. This classic program structure
decomposes function into a control hierarchy where a “main” program invokes a
number of program components that in turn may invoke still other components.
Figure 9.3 illustrates an architecture of this type.
• Remote procedure call architectures. The components of a main
program/subprogram architecture are distributed across multiple computers on a
network.
• Object-oriented architectures. The components of a system
encapsulate data and the operations that must be applied to
manipulate the data. Communication and coordination between
components are accomplished via message passing.
• Layered architectures. The basic structure of a layered architecture is illustrated
in Figure 9.4. A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine instruction set. At the
outer layer, components service user interface operations. At the inner layer,
components perform operating system interfacing. Intermediate layers provide
utility services and application software functions. These architectural styles are
only a small subset of those available. Once requirements engineering uncovers
the characteristics and constraints of the system to be built, the architectural style
and/or combination of patterns that best fits those characteristics and constraints
can be chosen. For example, a layered style (appropriate for most systems) can be
combined with a data- centered architecture in many database applications.
• Architectural Patterns: Architectural patterns address an application-specific problem within a
specific context and under a set of limitations and constraints. The pattern proposes an architectural
solution that can serve as the basis for architectural design.
• For example, the overall architectural style for an application might be call-and-return or object-
oriented. But within that style, you will encounter a set of common problems that might best be
addressed with specific architectural patterns.
ARCHITECTURAL DESIGN

• The design should define the external entities (other systems, devices, people) that the software
interacts with and the nature of the interaction. This information can generally be acquired from the
requirements model and all other information gathered during requirements engineering. Once
context is modeled and all external software interfaces have been described, you can identify a set
of architectural archetypes. An archetype is an abstraction (similar to a class) that represents one
element of system behavior. The set of archetypes provides a collection of abstractions that must be
modeled architecturally if the system is to be constructed, but the archetypes themselves do not
provide enough implementation detail.

• Therefore, the designer specifies the structure of the system by defining and refining software
components that implement each archetype. This process continues iteratively until a complete
architectural structure has been derived.
• Representing the System in Context: Architectural context represents how the software interacts
with entities external to its boundaries. At the architectural design level, a software architect uses
an architectural context diagram (ACD) to model the manner in which software interacts with
entities external to its boundaries. The generic structure of the architectural context diagram is
illustrated in Figure 9.5. Referring to the figure, systems that interoperate with the target system are
represented as
• Superordinate systems—those systems that use the target system as part of some higher-level
processing scheme.
• Subordinate systems—those systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality.
• Peer-level systems—those systems that interact on a peer-to-peer basis (i.e.,information is either
produced or consumed by the peers and the target system.
• Actors—entities (people, devices) that interact with the target system by producing or consuming
information that is necessary for requisite processing. Each of these external entities communicates
with the target system through an interface (the small shaded rectangles).
Defining Archetypes: Archetypes are the abstract building blocks of an architectural design. An
archetype is a class or pattern that represents a core abstraction that is critical to the design of an
architecture for the target system. In general, a relatively small set of archetypes is required to design
even relatively complex systems. The target system architecture is composed of these archetypes,
which represent stable elements of the architecture but may be instantiated many different ways
based on the behavior of the system. The following are the archetypes for safeHome: Node, Detector,
Indicator., Controller.
Refining the Architecture into Components: As the software architecture is refined into
components, the structure of the system begins to emerge. The architecture must accommodate many
infrastructure components that enable application components but have no business connection to the
application domain. For example, memory management components, communication components,
database components, and task management components are often integrated into the software
architecture.
• As an example for SafeHome home security, the set of top-level components that address the
following functionality:
• External communication management—coordinates communication of the security function with
external entities such as other Internet-based systems and external alarm notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the system.
• Alarm processing—verifies and acts on all alarm conditions.
Each of these top-level components would have to be elaborated iteratively and then positioned
within the overall SafeHome architecture.