Software Design Concepts

Ashish Kumar Dwivedi

Translating the requirements model into the
design model
 Design Documents
• The data/class design transforms class models into design class
realizations and the requisite data structures required to implement the
software.
• The objects and relationships defined in the CRC diagram and the detailed
data content depicted by class attributes and other notation provide the
basis for the data design action.
• The architectural design 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.
• The interface design describes how the software communicates with
systems that interoperate with it, and with humans who use it.
• An interface implies a flow of information (e.g., data and/or control) and a
specific type of behavior. Therefore, usage scenarios and behavioral
models provide much of the information required for interface 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
behavioral models serve as the basis for component design.
 Design Concepts
• Abstraction:
– 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. An example of a procedural abstraction
would be the word open for a door. Open implies a long
sequence of procedural steps (e.g., walk to the door, reach out
and grasp knob, turn knob and pull door, step away from moving
door, etc.)
– A data abstraction is a named collection of data that describes
a data object. In the context of the procedural abstraction open,
we can define a data abstraction called door. Like any data
object, the data abstraction for door would encompass a set of
attributes that describe the door (e.g., door type, swing direction,
opening mechanism, weight, dimensions).
 Design Concepts
• Architecture:
– The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.
– 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.
– Architecture Styles, Architectural Patterns, Architectural Views

• Separation of Concern:
– 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.
– 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.
 Design Concepts
• Modularity:
– Modularity is the most common manifestation of separation of
concerns.
• Information Hiding
– The concept of modularity leads you to a fundamental question: “How
do I decompose a software solution to obtain the best set of modules?”
– 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 defines and enforces access constraints to both procedural
detail within a module and any local data structure
• 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
“single-minded” function
 Design Concepts
• Refinement:
– Stepwise refinement is a top-down design strategy, A program is
developed by successively refining levels of procedural detail.
– Refinement is actually a process of elaboration.
– Abstraction and refinement are complementary concepts
– Refinement helps you to reveal low-level details as design progresses
• Aspects
– 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”
• Refactoring
– An important design activity suggested for many agile methods
– “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
Bottom-up vs Top-down approach
• Object-oriented programming is often referred to as
a bottom-up approach because it focuses on the
creation and manipulation of small, reusable objects
or "building blocks" that can be combined to create
larger, more complex systems.
• This approach is in contrast to a top-down approach,
which focuses on breaking larger systems down into
smaller, simpler parts. The bottom-up approach is
often used in the development of software
applications, where the focus is on creating small,
modular pieces of code that can be easily reused and
combined to create more complex functionality.
Top-down vs Bottom-up approach
 Design Elements
• Data Design Elements:
– Data structure is an essential part of design
– 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
• Architectural Design Elements:
– 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 data flow diagrams or analysis
classes, their relationships and collaborations for the problem at hand; and
– (3) the availability of architectural styles
• Interface Design Elements:
– UI
– External Interface to other systems, devices, networks
– Internal Interface
Interface design
The behavior of ControlPanel will be implemented by realizing KeyPad
operations
 Design Elements
• Component-Level Design Elements:
• Deployment-Level Design Elements:
 Description
• The personal computer houses subsystems that implement
security, surveillance, home management, and communications
features.
• In addition, an external access subsystem has been designed to
manage all attempts to access the SafeHome system from an
external source.
• Software design commences as the first iteration of
requirements engineering comes to a conclusion.
• The intent of software design is to apply a set of principles,
concepts, and practices that lead to the development of a
high-quality system or product.
• The goal of design is to create a model of software that will
implement all customer requirements correctly and bring
delight to those who use it.
 Architectural Design
• Definition 1: 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.
• Definition 2: There is a distinct difference between the terms
architecture and design. A design is an instance of an
architecture like 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 ways from this
architecture using either the Java platform (Java EE) or
Microsoft platform (.NET framework).
 Importance of Architecture
• 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 Styles
• The software that is built for computer-based systems also
exhibits one of many architectural styles.
• An architectural style is a transformation that is imposed on the
design of an entire system.
• 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
 Architectural Pattern
• An architectural style is a transformation that is imposed on the
design of an entire system.
• A pattern differs from a style in several fundamental ways:
– (1) the scope of a pattern is less broad, focusing on one aspect of the
architecture rather than the architecture in its entirety;
– (2) 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)
– (3) architectural patterns tend to address specific behavioral issues
within the context of the architecture (e.g., how real-time applications
handle synchronization or interrupts)
 Taxonomy of Architectural Style
• Data-centered Architecture
 Data-centered Architecture
and Data-Flow
• 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.
• Client software accesses a central repository.
• Data-Flow is applied when input data are to be
transformed through a series of computational.
• The filter does not require knowledge of the workings of
its neighboring filters.
 Data-flow Architecture
• A pipe-and-filter pattern has a set of components, called filters, connected by
pipes that transmit data from one component to the next.
Main Program/ Subprogram and
Object-Oriented architectures
Layered Architecture
• A number of 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.
 Architectural Context Diagram
• At the architectural design level, a software architect uses an architectural
context diagram (ACD) to model the way software interacts with entities
external to its boundaries.
 Architectural Context Diagram
• Architectural context diagram for the SafeHome security function
Architectural Structure for SafeHome
with top level component
An instantiation of the security function
with component elaboration
 Transformation of Data-Flow
into Software Architecture
• First understand the system using context
diagram
• Step 1. Review the fundamental system model.
• Step 2. Review and refine data flow diagrams for the software.
• Step 3. Determine whether the DFD has transform or transaction flow
characteristics.
– Evaluating the DFD (Figure 9.13), we see data entering the software along
one incoming path and exiting along three outgoing paths.
– Therefore, an overall transform characteristic will be assumed for information
flow.
• Step 4. Isolate the transform center by specifying incoming and outgoing
flow boundaries.
– Incoming data flows along a path in which information is converted from
external to internal form; outgoing flow converts internalized data to external
form.
– Incoming and outgoing flow boundaries are open to interpretation.
Step 5. Perform “first-level
factoring.”
Step 6. Perform “second-level
factoring.”
 Step 7. Refine the first-iteration architecture
using design heuristics for improved software
quality.
 Quality Attributes
• Functionality is assessed by evaluating the feature set
and capabilities of the program
• 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
• Performance is measured by considering processing
speed, response time, resource consumption,
throughput, and efficiency.
• Supportability combines the ability to extend the program
(extensibility), adaptability, serviceability—these three
attributes represent a more common term, maintainability