Unit 3

Chapter 1: Design
Concepts
▪Design engineering encompasses the set of principles, concepts, and practices that
lead to the development of a high quality system or product.

▪The goal of design engineering is to produce a model or representation that

exhibits firmness, commodity and delight.

▪To accomplish this, a designer must practice diversification and then convergence.
⮚ The designer selects from design components, component solutions, and
knowledge available through catalogs, textbooks, and experience.
⮚ The designer then chooses the elements from this collection that meet the
requirements defined by requirements engineering and analysis modeling.
⮚ Convergence occurs as alternatives are considered and rejected until one
particular configuration of components is chosen.
▪Each element of the analysis model provides information that is necessary to
create the four design models.

⮚ The data/class design transforms analysis classes into design classes along with
the data structures required to implement the software.

⮚ The architectural design defines the relationship between major structural

elements of the software; architectural styles and design patterns help achieve the
requirements defined for the system.

⮚ The interface design describes how the software communicates with systems that
interoperate with it and with humans that use it.
⮚ The component-level design transforms structural elements of the software
architecture into a procedural description of software components.
What is the work product?
▪A design model that encompasses architectural, interface, component-level, and
deployment representations is the primary work product that is produced during
software design.
The Design Process:

▪Software design is an iterative process through which requirements are translated

into a blueprint for constructing the software

▪Design begins at a high level of abstraction that can be directly traced back to the
data, functional, and behavioral requirements

▪As design iteration occurs, subsequent refinement leads to design representations

at much lower levels of abstraction.
Software Quality Guidelines and Attributes:

▪McGlaughlin suggests three characteristics that serve as a guide for the evaluation
of a good design :

1. 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.
2. The design should be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
3. The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.
▪How is each of these goals achieved?

Quality Guidelines:

▪In order to evaluate the quality of a design representation, you and other members
of the software team must establish technical criteria for good design.
i. 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.
⮚ Can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing.
ii. A design should be modular; that is, the software should be logically partitioned
into elements or subsystems.

iii. A design should contain distinct representations of data, architecture, interfaces,

and components.

iv. A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.

v. A design should lead to components that exhibit independent functional

characteristics

vi. A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
vii. A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.

viii. A design should be represented using a notation that effectively communicates

its meaning.

Quality Attributes:

▪The FURPS quality attributes represent a target for all software design:
1. 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.
2. Usability is assessed by considering human factors overall aesthetics,
consistency, and documentation.
3. 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.
4. Performance is measured using processing speed, response time, resource
consumption, throughput, and efficiency.
5. Supportability combines extensibility, adaptability, and serviceability.
(maintainability) and in addition, testability, compatibility, configurability, the ease
with which a system can be installed, and the ease with which problems can be
localized.
The Evolution of Software Design:

▪The evolution of software design is a continuing process.

▪Early design work concentrated on criteria for the development of modular

programs and methods for refining software structures in a top-down “structured”
manner.

▪Newer design approaches - an object-oriented approach.

▪More recent emphasis - software architecture and the design patterns.

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

▪Each software design method introduces unique heuristics and notation.

▪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.
Design Concepts:

▪Each provides the software designer with a foundation from which more
sophisticated design methods can be applied.

▪Each helps:
i. define criteria that can be used to partition software into individual components,
ii. separate or data structure detail from a conceptual representation of the
software, and
iii. establish uniform criteria that define the technical quality of a software design.
1. Abstraction:

▪Modular solution to the problem – exists – man levels of abstraction.

▪Higher level of abstraction and lower-level of abstraction.

▪Problem-oriented terminology + implementation-oriented terminology=> to state

a solution.

▪Different levels of abstraction are developed, you create both procedural and data
abstractions.
▪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: 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 defi ne 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).

▪It follows that the procedural abstraction open would make use of information
contained in the attributes of the data abstraction door.
2. Architecture:

▪Software architecture alludes to “the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system”.

▪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 – to derive an architectural rendering of a system.

▪A set of properties that should be specified as part of an architectural design:

i. Structural properties – Ex: modules, objects, filters.
ii. Extra-functional properties.
iii. Families of related systems
▪Given the specification of these properties, the architectural design can be
represented using one or more of a number of different models.
i. Structural models.
ii. Framework models.
iii. Dynamic models.
iv. Process models
v. Functional models.

▪A number of different architectural description languages (ADLs) have been

developed to represent these models.
3. Patterns:

▪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), and
(3)whether the pattern can serve as a guide for developing a similar, but functionally
or structurally different pattern.
4. Separation of Concerns:

▪It 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.

▪Complexity of problem when combined - when taken separately – divide-and-

conquer strategy.

▪Separation of concerns is manifested in other related design concepts: modularity,

aspects, functional independence, and refinement.
5. Modularity
▪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.

▪Monolithic software - The number of control paths, span of reference, number of

variables, and overall complexity would make understanding close to impossible.

▪Separation of concerns – Problems.

▪Useful qualitative guidance from the figure.

▪You should modularize, but care should be taken to stay in the vicinity of M.

▪Undermodularity or overmodularity should be avoided.

▪But how do you know the vicinity of M ?

▪How modular should you make software?

▪The answers: require an understanding of other design concepts

Why modularize a design?

▪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.
6. The 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?”

▪The principle of information hiding suggests that modules be “characterized by

design decisions that (each) hides from all others.”

▪Abstraction helps to defi ne 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.
7. 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.

▪Why independence?
⮚ Software with effective modularity 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.

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

▪ Coupling is an indication of interconnection among modules in a software structure.

8. Refinement:

▪Stepwise refinement is a top-down design strategy originally proposed by Niklaus

Wirth.
▪An application 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.

9. Aspects:

▪ As requirements analysis occurs, a set of “concerns” is uncovered.

▪ These concerns:
1. requirements,
2. use cases,
3. features,
4. data structures,
5. Quality of service issues,
6. variants,
7. intellectual property boundaries,
8. collaborations,
9. patterns and contracts
▪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”.
10. Refactoring

▪ A refactoring is a reorganization technique that simplifies the design (or code) of a

component without changing its function or behavior.

▪ Fowler defines refactoring in the following manner: “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:

i. examined for redundancy,
ii. unused design elements,
iii. inefficient or unnecessary algorithms,
iv. poorly constructed or inappropriate data structures, or
v. any other design failure that can be corrected to yield a better design.
11. Object-Oriented Design Concepts:

▪OO design concepts such as classes and objects, inheritance, messages, and
polymorphism, among others.

12. Design Classes:

▪The analysis model defines a set of analysis classes.

▪Each of these classes describes some element of the problem domain, focusing on
aspects of the problem that are user visible.

▪The level of abstraction of an analysis class is relatively high.

▪As the design model evolves, you will defi ne 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.
i. 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.

ii. 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.
iii. Persistent classes represent data stores (e.g., a database) that will persist beyond
the execution of the software.

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

v. Process classes implement lower-level business abstractions required to fully

manage the business domain classes.
▪Each design class define four characteristics of a well-formed design class:
i. Complete and sufficient.
▪Contains the complete encapsulation of all attributes and methods that exist for the
class

▪Contains only those methods that are sufficient to achieve the intent of the class
Ex: class Scene and all attributes and methods.

ii. Primitiveness.
▪Each method of a class focuses on accomplishing one service for the class
Ex: the class VideoClip for video editing software might have attributes and to
indicate the start and end points of the clip. The methods, setStart-Point() and
setEndPoint(), provide the only means for establishing start and end points for the
clip.
iii. High cohesion.
▪The class has a small, focused set of responsibilities and single-mindedly applies
attributes and methods to implement those responsibilities
▪For example, the class VideoClip might contain a set of methods for editing the
video clip. As long as each method focuses solely on attributes associated with the
video clip, cohesion is maintained.

iv. Low coupling:

▪Collaboration of the class with other classes is kept to an acceptable minimum

▪Each class should have limited knowledge of other classes in other subsystems
▪The restriction – the Law of Demeter suggests that a method should only send
messages to methods in neighboring classes.
13. Dependency Inversion
▪The structure of many older software architectures is hierarchical.

▪At the top of the architecture, “control” components rely on lower-level “worker”
components to perform various cohesive tasks.

▪Consider a simple program with three components. The intent of the program is
to read keyboard strokes and then print the result to a printer.

▪A control module, C , coordinates two other modules—a keystroke reader module,

R , and a module that writes to a printer, W .

▪The design of the program is coupled because C is highly dependent on R and W .

▪To remove the level of dependence that exists, the “worker” modules R and W
should be invoked from the control module S using abstractions.

▪object-oriented software engineering, abstractions are implemented as abstract

classes, R* and W*.

▪These abstract classes could then be used to invoke worker classes that perform
any read and write function.

▪Therefore a copy class, C, invokes abstract classes, R* and W*, and the abstract
class points to the appropriate worker-class (e.g., the R* class might point to a
read() operation within a keyboard class in one context and a read() operation
within a sensor class in another.
▪ This approach reduces coupling and improves the testability of a design.

14. Design for Test:

▪ There is an ongoing chicken-and-egg debate about whether software design or test case
design should come first.

▪ But if design comes first, then the design (and code) must be developed with seams —
locations in the detailed design.

▪ Sometimes referred to as “test hooks,” seams must be consciously designed at the

component level.

▪ In short, you need to provide appropriate test affordances—factoring your design in a way
that lets test code interrogate and control the running system.
The Design Model:

▪The design model can be viewed in two different dimensions: Process and
Abstraction dimension.

▪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.
Data Design Elements:
▪Like other software engineering activities, data design creates a model of data
and/or information that is represented at a high level of abstraction.

▪This data model is then refined into progressively more implementation-specific

representations that can be processed by the computer-based system.

▪Importance of the architecture of the data - architecture of the software that must
process it.

▪The structure of data has always been an important part of software

design.
▪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 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.
Architectural Design Elements:
▪The architectural design for software is the equivalent to the floor plan of a house.

▪The floor plan depicts the overall layout of the rooms; their size, shape, and
relationship to one another; and the doors and windows that allow movement into
and out of the rooms.

▪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:
(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; and
(3)the availability of architectural styles.

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

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.
▪Use: allow the software to communicate externally and enable internal
communication and collaboration among the components that populate the
software architecture.

▪UI design (also called usability design ) is a major software engineering action.

▪Usability design incorporates:

i. aesthetic elements (e.g., layout, color, graphics, interaction mechanisms),
ii. ergonomic elements (e.g., information layout and placement, metaphors, UI
navigation), and
iii. technical elements (e.g., UI patterns, reusable components).
▪The design of external interfaces requires definitive information about the entity to
which information is sent or received.

▪In every case, this information should be collected during requirements

engineering and verified once the interface design commences.

▪The design of external interfaces should incorporate error checking and

appropriate security features.
▪The design of internal interfaces is closely aligned with component-level design.

▪Design realizations of analysis classes represent all operations and the messaging
schemes required to enable communication and collaboration between operations
in various classes.

▪Each message must be designed to accommodate the requisite information transfer

and the specific functional requirements of the operation that has been requested.
Component-Level Design Elements:

▪The component-level design for software fully describes the internal detail of each
software component.

▪The component-level design for software is the equivalent to a set of detailed

drawings (and specifications).

▪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 as shown in Figure:
▪The design details of a component can be modeled at many different levels of
abstraction.
i. A UML activity diagram can be used to represent processing logic.
ii. Detailed procedural flow for a component can be represented using either
pseudocode or some other diagrammatic form (e.g., flowchart or box diagram).

▪Data structures, selected based on the nature of the data objects to be processed,
are usually modeled using pseudocode or the programming language to be used
for implementation.
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.

▪Ex: 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).
▪During design, a UML deployment diagram is developed and then refined
as shown in Figure:
▪Descriptor form- the deployment diagram shows the computing environment but
does not explicitly indicate configuration details.

▪These details are provided when the deployment diagram is revisited in instance
form during the latter stages of design or as construction begins.
Chapter 2:
Architectural Design
What is Architecture Design!

▪“The architecture of a system is a comprehensive framework that describes its

form and structure its components and how they fit together.”
- Jerrold Grochow

▪Bass, Clements, and Kazman define this elusive term in the following way:
“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 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.

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”.
Architectural Descriptions:

▪The IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended

Practice for Architectural Description of Software-Intensive System, [IEE00]
▪ to establish a conceptual framework and vocabulary for use during the design of software architecture,
▪ to provide detailed guidelines for representing an architectural description, and
▪ to encourage sound architectural design practices.

▪The IEEE Standard defines an architectural description (AD) as a “a collection of

products to document an architecture.”
▪ The description itself is represented using multiple views, where each view is “a representation of a whole
system from the perspective of a related set of [stakeholder] concerns.”
 Architectural Styles

Indo Sarcenic styles Tudor architecture styles

Gothic Revival Architecture Baroque architecture

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.
A Brief Taxonomy of Architectural Styles:

▪ Data-centered architectures
▪ Data flow architectures
▪ Call and return architectures
▪ Object-oriented architectures
▪ Layered architectures
Data-Centered Architecture:
▪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. 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.

▪ A variation on this approach transforms the repository into a “blackboard” that

sends notifications to client software when data of interest to the client changes.
▪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 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.

▪If the data flow degenerates into a single line of transforms, it is termed batch
sequential.

▪This structure accepts a batch of data and then applies a series of sequential
components (filters) to transform it.
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:

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

ii. Remote procedure call architectures: The components of a main

program/subprogram architecture are distributed across multiple computers on a
network.
Layered architectures:

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

▪In many cases, more than one pattern might be appropriate and alternative
architectural styles can be designed and evaluated.
Ex: a layered style (appropriate for most systems) can be combined with a data-
centered architecture in many database applications.
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.
Architectural Patterns:
▪As the requirements model is developed, you’ll notice that the software must
address a number of broad problems that span the entire application.

▪For example, the requirements model for virtually every e-commerce application
is faced with the following problem:

i. How do we offer a broad array of goods to many different customers and allow
those customers to purchase our goods online?

▪The requirements model also defines a context in which this question must
be answered.
▪For example, an e-commerce business that sells golf equipment to consumers will
operate in a different context than an e-commerce business that sells high-priced
industrial equipment to medium and large corporations.

▪In addition, a set of limitations and constraints may affect the way you address the
problem to be solved.

▪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.
Organization and Refinement:
▪The design process often leaves you with a number of architectural alternatives, it
is important to establish a set of design criteria that can be used to assess an
architectural design that is derived.

▪The following questions provide insight into an architectural style:

1. Control. How is control managed within the architecture?
2. Does a distinct control hierarchy exist, and if so, what is the role of components
within this control hierarchy?
3. How do components transfer control within the system?
4. How is control shared among components?
5. What is the control topology (i.e., the geometric form that the control takes)?
6. Is control synchronized or do components operate asynchronously?
2. Data.
▪How are data communicated between components?
▪Is the flow of data continuous, or are data objects passed to the system
sporadically?
▪What is the mode of data transfer (i.e., are data passed from one component to
another or are data available globally to be shared among system components)?
▪Do data components (e.g., a blackboard or repository) exist, and if so, what is their
role?
▪How do functional components interact with data components?
▪Are data components passive or active (i.e., does the data component actively
interact with other components in the system)?
▪How do data and control interact within the system?
▪These questions provide the designer with an early assessment of design quality
and lay the foundation for more detailed analysis of the architecture.
Architectural Design:

▪As architectural design begins, context must be established.

▪To accomplish this, the external entities (e.g., other systems, devices, people) that
interact with the software and the nature of their interaction are described.

▪Information from requirement model.

▪Once context is modelled 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.

▪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:

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

▪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:

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

▪It is also an abstraction from a class of programs with a common structure and
includes class-specific design strategies and a collection of example program
designs and implementations.

▪In many cases, archetypes can be derived by examining the analysis classes
defined as part of the requirements model.
▪The design of SafeHome home security function, the following archetypes are
defined:
▪Node. Represents a cohesive collection of input and output elements of the home
security function. For example, a node might be composed of
(1) various sensors and
(2) a variety of alarm (output) indicators.
▪Detector. An abstraction that encompasses all sensing equipment that feeds
information into the target system.
▪Indicator. An abstraction that represents all mechanisms (e.g., alarm siren,
flashing lights, bell) for indicating that an alarm condition is occurring.
▪Controller. An abstraction that depicts the mechanism that allows the arming or
disarming of a node. If controllers reside on a network, they have the ability to
communicate with one another.
Refining the Architecture into Components:

▪Based on the archetypes, the architectural designer refines the software

architecture into components to illustrate the overall structure and architectural
style of the system.

▪These components are derived from various sources:

i. The application domain provides application components, which are the
domain classes in the analysis model that represent entities in the real world.
ii. The infrastructure domain provides design components (i.e., design classes)
that enable application components but have no business connection.
Ex: memory management, communication, database, and task management
iii. The interfaces in the ACD imply one or more specialized components that
process the data that flow across the interface.

▪A UML class diagram can represent the classes of the refined architecture and
their relationships.

Functionality:
-External communication management
-Control panel processing
-Detector management
-alarm processing
Describing Instantiations of the System:
▪The architectural design that has been modeled to this point is still relatively high
level.

▪The context of the system has been represented, archetypes that indicate the
important abstractions within the problem domain have been defined, the overall
structure of the system is apparent, and the major software components have been
identified.

▪One more thing to do - further refinement (recall that all design is iterative) is still
necessary.
▪To accomplish this, an actual instantiation of the architecture is developed.

▪Meaning the architecture is applied to a specific problem with the intent of

demonstrating that the structure and components are appropriate.
▪For example, the detector management component interacts with a scheduler
infrastructure component that implements polling of each sensor object used by
the security system.
Architectural Design for Web Apps:

▪WebApps are client-server applications typically structured using multilayered

architectures, including
i. a user interface or view layer,
ii. a controller layer which directs the flow of information to and from the client
browser based on a set of business rules, and
iii. a content or model layer that may also contain the business rules for the
WebApp.
▪The user interface for a WebApp is designed around the characteristics of the web
browser running on the client machine (usually a personal computer or mobile
device).

▪Data layers reside on a server.

▪Business rules can be implemented using a server-based scripting language such

as PHP or a client-based scripting language such as javascript.

▪An architect will examine requirements for security and usability to determine
which features should be allocated to the client or server.
▪The architectural design of a WebApp is also influenced by the structure (linear or
nonlinear) of the content that needs to be accessed by the client.

▪The architectural components (Web pages) of a WebApp are designed to allow

control to be passed to other system components, allowing very flexible navigation
structures.

▪The physical location of media and other content resources also influences the
architectural choices made by software engineers.
Architectural Design for Mobile Apps:

▪Mobile apps are typically structured using multilayered architectures, including:

i. a user interface layer,
ii. a business layer, and
iii. a data layer.

▪With mobile apps you have the choice of building a thin Web-based client or a
rich client.

▪With a thin client, only the user interface resides on the mobile device, whereas
the business and data layers reside on a server.
▪With a rich client all three layers may reside on the mobile device itself.

▪Mobile devices differ from one another in terms:

i. their physical characteristics (e.g., screen sizes, input devices),
ii. software (e.g., operating systems, language support), and
iii. hardware (e.g., memory, network connections).

▪Each of these attributes shapes the direction of the architectural alternatives that
can be selected.
▪A number of considerations that can influence the architectural design of a mobile
app:

(1) the type of web client (thin or rich) to be built,

(2) the categories of devices (e.g., smartphones, tablets) that are supported,
(3) the degree of connectivity (occasional or persistent) required,
(4) the bandwidth required,
(5) the constraints imposed by the mobile platform,
(6) the degree to which reuse and maintainability are important, and
(7) device resource constraints (e.g., battery life, memory size, processor speed).
Chapter 3:Component level design
▪Component-level design defines the data structures, algorithms, interface
characteristics, and communication mechanisms allocated to each component for
the system development.

▪A complete set of software components is defined during architectural design. But

the internal data structures and processing details of each component are not
represented at a level of abstraction that is close to code.

▪Component-level design defines the data structures, algorithms, interface

characteristics, and communication mechanisms allocated to each component.
Why is it important?
▪You have to be able to determine whether the software will work before you build
it.

▪The component-level design represents the software in a way that allows you to
review the details of the design for correctness and consistency with other design
representations (i.e., the data, architectural, and interface designs).

▪It provides a means for assessing whether data structures, interfaces, and
algorithms will work.
What is the work product?

▪The design for each component, represented in graphical, tabular, or text-based

notation, is the primary work product produced during component-level design.

▪According to Object Management Group UML specification component is

expressed as, “A modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.”
▪An Object-oriented view
▪The Traditional View
▪The Process Related View

1. An Object-oriented view
▪In a context of OO software engineering, a component contains a set of
collaborating classes.

▪Each class within a component has been fully elaborated to include all attributes
and operations that are relevant to its implementation.

▪As a part of the design elaboration, all interfaces that enable the classes to
communicate and collaborate with other design classes must be defined
▪Ex: To illustrate this process of design elaboration, consider software to be built
for a sophisticated print shop.

▪The overall intent of the software is to collect the customer’s requirements at the
front counter, cost a print job, and then pass the job on to an automated production
facility.

▪During requirements engineering, an analysis class called PrintJob was derived.

▪The attributes and operations defined during analysis are noted at the top of
Figure.

▪During architectural design, PrintJob is defined as a component within the

software architecture and is represented using the shorthand UML notation 2
shown in the middle right of the figure.
▪Note that PrintJob has two interfaces, computeJob, which provides job costing
capability, and initiateJob, which passes the job along to the production facility.

▪Component-level design begins at this point. The details of the component

PrintJob must be elaborated to provide sufficient information to guide
implementation.

▪The original analysis class is elaborated to flesh out all attributes and operations
required to implement the class as the component PrintJob.

▪Referring to the lower right portion of Figure the elaborated design class PrintJob
contains more detailed attribute information as well as an expanded description of
operations required to implement the component.
▪The interfaces compute-Job and initiateJob imply communication and
collaboration with other components.

▪For example, the operation computePageCost() (part of the computeJob interface)

might collaborate with a PricingTable component that contains job pricing
information.

▪The checkPriority() operation (part of the initiateJob interface) might collaborate

with a JobQueue component to determine the types and priorities of jobs
currently awaiting production.
2. The Traditional View:

▪In the context of traditional software engineering, a component is a functional

element of a program that incorporates:
i. processing logic,
ii. the internal data structure required to implement processing logic, and
iii. interface that enables the component to be invoked and data to be passed to it.
▪It is also called module resides within the software architecture and serves one of
the three important roles as:
⮚A control component that coordinates the invocation of all other problem
domain components.

⮚A problem domain component that implements a complete or partial function

that is required by the customer.

⮚An infrastructure component that is responsible for the functions that support
the processing required in the problem domain.
▪Like object-oriented components, traditional software components are derived
from the analysis model.

▪In this case, however, the component elaboration element of the analysis model
serves as the basis for the derivation.

▪Each component represented the component hierarchy is mapped into a module

hierarchy.

▪Control components (modules) reside near the top of the hierarchy (program
architecture), and problem domain components tend to reside toward the bottom of
the hierarchy.
▪To achieve effective modularity, design concepts like functional independence are
applied as components are elaborated.

3. A Process-Related View

▪The object-oriented and traditional views of component-level design assume that

the component is being designed from scratch.

▪Meaning - you have to create a new component based on specifications derived

from the requirements model.

▪Another approach - a catalog of proven design or code-level components is made

available to you as design work proceeds.
▪As the software architecture is developed, you choose components or design
patterns from the catalog and use them to populate the architecture.

▪These components have been created with reusability in mind, a complete

description of their interface, the function(s) they perform, and the communication
and collaboration they require are all available to you.
Designing Class-based Components:
▪Component-level design draws on information developed as part of the
requirements model and represented as part of the architectural model.

▪ When an object-oriented software engineering approach is chosen, component-

level design focuses on the elaboration of problem domain specific classes and the
definition and refinement of infrastructure classes contained in the requirements
model.

▪The detailed description of the attributes, operations, and interfaces used by these
classes is the design detail required as a precursor to the construction activity.
Designing Class-Based Components:

▪Basic Design Principles

▪Component-Level Design Guidelines
▪Cohesion
▪Coupling
Basic Design Principles:

▪The Open-Closed Principle (OCP) : “A module should be open for extension but
closed for modification”. The component should be extended without the need to
make internal modifications (logic level / code) to the component itself.

▪The Liskov Substitution Principle (LSP) : “Subclasses should be substitutable

for their base classes”. A component that uses a base class should continue to
function properly if a class derived from the base class is passed to the component
instead.
▪Dependency Inversion Principle (DIP): “Depend on abstractions. Do not depend
on concretions.” Abstractions are the place where a design can be extended
without great complication. The more a components depends on the concrete
components, the more difficult it will be to extend.

▪The Interface Segregation Principle (ISP): “Many client-specific interfaces are

better than one general purpose interface.” We should create a specialized interface
to serve each major category of clients
Packaging Principles:

▪The Release Reuse Equivalency Principle (REP): “The granule of reuse is the
granule of release.” It is advisable to group reusable classes into packages that can
be managed and controlled as newer versions evolve

▪The Common Closure Principle (CCP) : “Classes that change together belong
together.” When classes are packaged as a part of a design, they should address the
same functional or behavioral area. (classes should be packaged cohesively)

▪The Common Reuse Principle (CRP) : “Classes that aren’t reused together
should not be grouped together.” So only classes that are reused together should
be included within a package
Component-Level Design Guidelines:

▪Component
▪Naming conventions
▪Interfaces
▪Only those interfaces that are relevant to the component under consideration
should be shown.
▪Dependencies and Inheritance
▪Dependencies should be modeled from left to right and inheritance should be
modeled from bottom to top.
Cohesion:

▪Singlemindedness.

▪ Types of cohesion
▪ Functional : Exhibited by operations, this level of cohesion occurs when a
component performs a targeted computation and then returns a result
▪ Layer : Exhibited by packages, components, and classes, this type of
cohesion occurs when higher layer accesses the services of a lower layer but
lower layer do not access higher level
▪ Communicational: All the operations that access the same data are defined
within one class. Such classes focus on the data in question, accessing and
storing it.
Coupling:
▪Coupling is a qualitative measure of the degree to which classes are connected to
one another.
▪Coupling categories:
▪Content coupling: Occurs when one component modifies data that is internal to
another component (violates information hiding)
▪Common coupling: Occurs when a number of components all make use of a
global variable
▪Control coupling: Occurs when operation A() invokes operation B() and passes
control flag to B
▪Stamp coupling: Occurs when class B is declared as a type for an argument of
an operation of class A
▪Data coupling: Occurs when operations pass long strings of data arguments
▪Routine call coupling: Occurs when one operation invokes another
▪Type use coupling: Occurs when component A uses a data type defined in component B
▪Inclusion or import coupling: Occurs when component A imports or includes a
package or content of component B.
▪External coupling: Occurs when a component communicates or collaborates
with infrastructure components (O.S functions, telecommunication function).
Conducting Component-level Design:

Step 1. Identify all design classes that correspond to the problem domain. Using
the requirements and architectural model, each analysis class and architectural
component is elaborated.

Step 2. Identify all design classes that correspond to the infrastructure domain.
▪Classes and components in this category include GUI components (often available
as reusable components), operating system components, and object and data
management components.
Step 3. Elaborate all design classes that are not acquired as reusable
components.
▪Elaboration requires that all interfaces, attributes, and operations necessary to
implement the class be described in detail.

▪Design heuristics (e.g., component cohesion and coupling) must be considered as

this task is conducted.

Step 3a. Specify message details when classes or components collaborate.

▪The requirements model makes use of a collaboration diagram to show how
analysis classes collaborate with one another.
Step 3b. Identify appropriate interfaces for each component. Within the context
of component-level design, a UML interface is “a group of externally visible (i.e.,
public) operations.

Step 3c. Elaborate attributes and define data types and data structures
required to implement them.
▪UML defines an attribute’s data type using the following syntax:
name : type-expression 5 initial-value {property string}
▪where
i. name is the attribute name,
ii. type expression is the data type, initial value is the value that the attribute takes
when an object is created, and
iii. property-string defines a property or characteristic of the attribute.
Step 3d. Describe processing flow within each operation in detail.
▪This may be accomplished using a programming language-based pseudocode or
with a UML activity diagram.

Step 4. Describe persistent data sources (databases and files) and identify the
classes required to manage them.

Step 5. Develop and elaborate behavioral representations for a class or

component.
▪The dynamic behavior of an object is affected by events that are external to it and
the current state of the object.
▪To understand the dynamic behavior of an object, one should examine all use
cases that are relevant to the design class throughout its life.
Step 6. Elaborate deployment diagrams to provide additional implementation
detail.
▪During component-level design, deployment diagrams can be elaborated to
represent the location of key packages of components.

Step 7. Refactor every component-level design representation and always

consider alternatives.
▪Develop alternatives and consider each carefully, using the design principles and
concepts