Because learning changes everything.

Chapter 8
Requirements Modeling – A
Recommended Approach

Part Two - Mobility.

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
 Requirements Analysis
Requirements analysis
• specifies software’s operational characteristics.
• indicates software's interface with other system elements.
• establishes constraints that software must meet.

Requirements analysis allows the software engineer to:

• elaborate on basic requirements established during earlier requirement
engineering tasks.
• build models that depict the user’s needs from several different perspectives.

© McGraw Hill 2
 Requirements Models
• Scenario-based models depict requirements from the point of
view of various system “actors.”
• Class-oriented models represent object-oriented classes
(attributes and operations) and how classes collaborate to
achieve system requirements.
• Behavioral models depict how the software reacts to internal
or external “events.”
• Data models depict the information domain for the problem.
• Flow-oriented models represent functional elements of the
system and how they transform data in the system.

© McGraw Hill 3
 A Bridge

Access the text alternative for slide images.

© McGraw Hill 4
 Rules of Thumb
• The level of abstraction should be relatively high - focus on
requirements visible in problem or business domains.
• Analysis model should provide insight into information
domain, function, and behavior of the software.
• Delay consideration of infrastructure and other non-functional
models until later in the modeling activity.
• The analysis model provides value to all stakeholders keep the
model as simple as it can be.

© McGraw Hill 5
 Requirements Modeling Principles
• Principle 1. The information domain of a problem must be
represented and understood.
The information domain encompasses the data that flow into the system
(from end users, other systems, or external devices), the data that flow out of
the system (via the user interface, network interfaces, reports, graphics, and
other means), and the data stores that collect and organize the data that are
maintained permanently.

• Principle 2. The functions that the software performs must be

defined.
Software functions provide direct benefit to end users and those that
provide internal support for those features that are user visible. Some functions
transform data that flow into the system. In other cases, functions effect some
level of control over internal software processing or external system elements.
© McGraw Hill 6
 • Principle 3. The behavior of the software (as a consequence of
external events) must be represented.
The behavior of computer software is driven by its interaction with the
external environment. Input provided by end users, control data provided by an
external system, or monitoring data collected over a network all cause the
software to behave in a specific way.
• Principle 4. The models that depict information, function, and
behavior must be partitioned in a manner that uncovers detail in
a layered (or hierarchical) fashion.
Complex problems are difficult to solve in their entirety. For this reason, you
should use a divide-and-conquer strategy. A large, complex problem is divided
into subproblems until each subproblem is relatively easy to understand. This
concept is called partitioning or separation of concerns, and it is a key strategy in
requirements modeling
• Principle 5. The analysis task should move from essential
information toward implementation detail.

© McGraw Hill 7
 Scenario-Based Modeling: Actors and
Profiles
A UML actor models an entity that interacts with a system object.
• Actors may represent roles played by human stakeholders or external
hardware as they interact with system objects by exchanging information.

A UML profile provides a way of extending an existing model to

other domains or platforms.
• This might allow you to revise the model of a Web-based system and model
the system for various mobile platforms.
• Profiles might also be used to model the system from the viewpoints of
different users.

© McGraw Hill 8
 Use Cases
• Developers need more precise means of describing this
interaction before beginning to create the software
• Use case as a “contract for behavior” and more formal than a
user story.
• Use-cases are simply an aid to defining what exists outside the
system (actors) and what should be performed by the system
(use-cases).
1. What should we write about?
2. How much should we write about it?
3. How detailed should we make our description?
4. How should we organize the description?

© McGraw Hill 9
 What to Write About?
• The first two requirements engineering tasks—inception and
elicitation—provide you with the information you’ll need to
begin writing use cases.
• To begin developing a set of use cases, list the functions or
activities performed by a specific actor.
• You can obtain these from a list of required system functions,
through conversations with stakeholders, or by an evaluation of
activity diagrams developed as part of requirements modeling.
• Use cases of this type are sometimes referred to as primary
scenarios.

© McGraw Hill 10
 Alternative Interactions
Description of alternative interactions is essential to completely
understand a function described a use case.
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at this point?
• Is it possible that the actor will encounter some other behavior at this point
(for example: behavior that is invoked by some event outside the actor’s
control)?

Answers to these questions result in the creation of a set of

secondary scenarios represent alternative use cased behavior.

© McGraw Hill 11
 Defining Exceptions
An exception describes a situation (either a failure condition or
an alternative chosen by the actor) that causes the system to
exhibit somewhat different behavior.
Questions to ask:
• Are there cases in which some “validation function” occurs during this use
case?
• Are there cases in which a supporting function (or actor) will fail to
respond appropriately?
• Can poor system performance result in unexpected or improper user
actions?

© McGraw Hill 12
 Documenting Use Cases
• What are the main tasks or functions that are performed by the
actor?
• What system information will the actor acquire, produce or
change?
• Will the actor have to inform the system about changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
• What are the preconditions, triggers, exceptions, and open
issues?

© McGraw Hill 13
 Use Case Diagram

Access the text alternative for slide images.

© McGraw Hill 14
 Use Case Diagram
● Each modeling notation has limitations, and the UML use case
is no exception. Like any other form of written description, a
use case is only as good as its author(s).
● If the description is unclear, the use case can be misleading or
ambiguous.
● It focuses on function and behavioral requirements and is
generally inappropriate for nonfunctional requirements.
● For situations in which the requirements model must have
significant detail and precision (e.g., safety critical systems), a
use case may not be sufficient

© McGraw Hill 15
 Class-Based Modeling
Class-based modeling represents:
• objects that the system will manipulate.
• operations (also called methods or services) that will be applied to the objects
to effect the manipulation.
• relationships (some hierarchical) between the objects.
• collaborations that occur between the classes that are defined.

The elements of a class-based model include classes and objects,

attributes, operations, CRC models, UML class diagrams.

© McGraw Hill 16
 Identifying Analysis Classes
Examining the usage scenarios developed as part of the
requirements model and perform a "grammatical parse“.
• Classes are determined by underlining each noun or noun phrase and entering
it into a simple table.
• Synonyms should be noted.
• If the class (noun) is required to implement a solution, then it is part of the
solution space; otherwise, if a class is necessary only to describe a solution, it
is part of the problem space.

But what should we look for once all of the nouns have been
isolated?

© McGraw Hill 17
 Potential Analysis Classes
• External entities (for example: other systems, devices, people) that produce
or consume information.
• Things (for example: reports, displays, letters, signals) that are part of the
information domain for the problem.
• Occurrences or events that occur within the context of system operation.
• Roles played by people who interact with the system.
• Organizational units that are relevant to an application.
• Places that establish the context of the problem and overall function.
• Structures (for example: sensors, four-wheeled vehicles, or computers) that
define a class of objects or related classes of objects.

© McGraw Hill 18
 Analysis Class Selection
• Retained information. Potential class will be useful during analysis only if
information about it must be remembered.
• Needed services. Potential class must have a set of identifiable operations
that can change the value of its attributes in some way.
• Multiple attributes. Focus should be on "major" information; a class with a
single attribute may be better represented as an attribute of another class.
• Common attributes. A set of attributes can be defined for the potential class
and the attributes apply to all instances of the class.
• Common operations. A set of operations can be defined for the potential
class and the operations apply to all instances of the class.
• Essential requirements. External entities that appear in the problem space
and produce or consume information essential to the solution will usually be
defined as analysis classes in the model.

© McGraw Hill 19
 Defining Attributes
• Attributes describe a class that has been selected for inclusion
in the analysis model.
• It is the attributes that define the class—that clarify what is
meant by the class in the context of the problem space.
• To develop a meaningful set of attributes for an analysis class,
you should study each use case and select those “things” that
reasonably “belong” to the class.
• What data items(composite and/or elementary) fully define this
class in the context of the problem at hand?

© McGraw Hill 20
 Defining Operations
• Operations define the behavior of an object.
• Operations they can generally be divided into four broad categories:
1. Operations that manipulate data in some way.
2. Operations that perform a computation.
3. Operations that inquire about the state.
4. Operations that monitor an object for the occurrence of a controlling
event.
• These functions are accomplished by operating on attributes and/or
associations.
• Therefore, an operation must have “knowledge” of the class attributes and
associations.

© McGraw Hill 21
 CRC Modeling
• Class-responsibility-collaborator (CRC) modeling provides a
simple means for identifying and organizing the classes that are
relevant to system or product requirements.
• A CRC model is really a collection of standard index cards that
represent classes.
• The cards are divided into three sections:
1. Along the top of the card you write the name of the class.
2. list the class responsibilities on the left.
3. list the collaborators on the right.

© McGraw Hill 22
 CRC Cards

Access the text alternative for slide images.

© McGraw Hill 23
 CRC Model Review Process
1. All stakeholders in the review (of the CRC model) are given a subset of
the CRC model index cards. No reviewer should have two cards that
collaborate.
2. The review leader reads the use case deliberately. As the review leader
comes to a named object, she passes a token to the person holding the
corresponding class index card.
3. When the token is passed, the holder of the class card is asked to describe
the responsibilities noted on the card. The group determines whether one
of the responsibilities satisfies the use case requirement.
4. If an error is found, modifications are made to the cards. This may include
the definition of new classes (CRC index cards) or revising lists of
responsibilities or collaborations on existing cards.

© McGraw Hill 24
 Functional Modeling
• The functional model addresses two application processing
elements:
1. user-observable functionality that is delivered by the app to
end users.
2. operations contained within analysis classes that implement
behaviors associated with the class.
• UML activity diagrams can be used to represent processing
details.
• UML activity diagram supplements a use case by providing a
graphical representation of the flow of interaction within a
specific scenario.

© McGraw Hill 25
 Activity Diagram 1

Access the text alternative for slide images.

© McGraw Hill 26
 Activity Diagram 1

● An activity diagram is like a flowchart.

● It uses rounded rectangles to imply a specific system function.
● Arrows to represent flow through the system,
● Decision diamonds to depict a branching decision (each arrow
emanating from the diamond is labeled),
● Solid horizontal lines to indicate that parallel activities are
occurring.

© McGraw Hill 27
 Sequence Diagram 1

• The UML sequence diagram can be used for behavioral

modeling.
• Sequence diagrams can also be used to show how events cause
transitions from object to object.
• Once events have been identified by examining a use case, the
modeler creates a sequence diagram—a representation of how
events cause flow from one object to another as a function of
time.
• Sequence diagram is a shorthand version of a use case.

© McGraw Hill 28
 Sequence Diagram 2

Access the text alternative for slide images.

© McGraw Hill 29
 Behavioral Modeling
• A behavioral model indicates how software will respond to
internal or external events or stimuli.
• This information is useful in the creation of an effective design
for the system to be built.
• UML activity diagrams can be used to model how system
elements respond to internal events.
• UML state diagrams can be used to model how system
elements respond to external events.

© McGraw Hill 30
 Creating Behavioral Models
1. Evaluate all use cases to fully understand the sequence of
interaction within the system.
2. Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
3. Create a sequence diagram for each use case.
4. Build a state diagram for the system.
5. Review the behavioral model for accuracy and consistency.

© McGraw Hill 31
 Identifying Events
• A use case represents a sequence of activities that involves
actors and the system.
• An event occurs whenever the system and an actor exchange
information.
• An event is not the information that has been exchanged, but
rather the fact that information has been exchanged.
• A use case needs to be examined for points of information
exchange.
• Events are used to trigger state transitions.

© McGraw Hill 32
 State Diagram

Access the text alternative for slide images.

© McGraw Hill 33
 State Diagram
● An action occurs concurrently with the state transition or
because of it and generally involves one or more operations
(responsibilities) of the object.
● For example, the action connected to the password entered
event is an operation named validatePassword() that accesses a
password object and performs a digit-by-digit comparison to
validate the entered password.

© McGraw Hill 34
 Activity Diagram 2

Access the text alternative for slide images.

© McGraw Hill 35
 Swimlane Diagrams
• The UML swimlane diagram is a useful variation of the
activity diagram that allows you to represent the flow of
activities described by the use case.
• Swimlane diagrams indicate which actor (if there are multiple
actors involved in a specific use case) or analysis class has
responsibility for the action described by an activity rectangle.
• Responsibilities are represented as parallel segments that
divide the diagram vertically, like the lanes in a swimming
pool.

© McGraw Hill 36
 Swimlane Diagram

Access the text alternative for slide images.

© McGraw Hill 37
 Swimlane Diagram
● The activity diagram is rearranged so that activities associated
with an analysis class fall inside the swimlane for that class.
● For example, the Interface class represents the user interface as
seen by the homeowner.
● Use cases, along with the activity and swimlane diagrams, are
procedurally oriented.
● Taken together they can be used to represent the way various
actors invoke specific functions (or other procedural steps) to
meet the requirements of the system.

© McGraw Hill 38
 Summary
● The objective of requirements modeling is to create a variety of
representations that describe what the customer requires, establish a
basis for the creation of a software design, and define a set of
requirements that can be validated once the software is built.
● The requirements model bridges the gap between a system-level
description that describes overall system and business functionality and a
software design.
● Scenario-based models depict software requirements from the user’s
point of view.
● Class-based modeling uses information derived from use cases and other
written application descriptions to identify analysis classes.
● A set of class-responsibility-collaborator index cards can be used to
define relationships between classes.
● Behavioral modeling during requirements analysis depicts dynamic
behavior of the software.
© McGraw Hill 39
Because learning changes everything. ®

www.mheducation.com

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
 Accessibility Content: Text Alternatives for Images

© McGraw Hill 41
 A Bridge – Text Alternative
Return to parent-slide containing images.

An illustration displays a bridge. Three circles represent the system

description, analysis model, and design model. The analysis model
overlaps with the system description, and the design model.

Return to parent-slide containing images.

© McGraw Hill 42
 Use Case Diagram – Text Alternative
Return to parent-slide containing images.

An illustration displays a case diagram. The homeowner is

connected to the three use cases of a safehome. The use cases are,
access camera surveillance via the internet, configures safehome
system parameters, and sets alar. The access camera surveillance
via the internet is further connected to cameras.

Return to parent-slide containing images.

© McGraw Hill 43
 CRC Cards – Text Alternative
Return to parent-slide containing images.

An illustration displays CRC cards. The title reads class: floor plan.
The space below the title reads description. The card is further
divided into two columns titled responsibility, and collaborator. The
responsibility reads defines floor plan name or type; manages floor
plan positioning; scales floor plan for display; incorporates walls,
door, and windows, and shows position of video cameras. The
collaborator reads, wall on the column corresponding to
incorporates wall, doors, and windows; and camera in the column
respective to shows position of video cameras.

Return to parent-slide containing images.

© McGraw Hill 44
 Activity Diagram – Text Alternative 1

Return to parent-slide containing images.

A flowchart displays an activity diagram. The diagram starts with

two possibilities, camera not in use, and camera in use. If the
camera in use, get current camera user, and then report camera in
use and home of current user. If the camera not in use, the request
camera lock. If the camera lock is available, then report camera
now locked for user. If the lock is unavailable, then report camera
unavailable.

Return to parent-slide containing images.

© McGraw Hill 45
 Sequence Diagram – Text 2

Alternative Return to parent-slide containing images.

The sequence diagram has four life lines which are labeled, from left to
right, homeowner, control panel, system and sensors. When the system is
ready the homeowner enters a password which is relayed to the control
panel. The control panel begins by reading the message and then
performs a compare of the password entered. When comparing the
control panel sends a lookup request to the system which return a result.
If the password is correct the system sends an activation request to the
sensors which over a duration sends a successful activation message to
the control panel which further the relays the successful activation
message to the homeowner. If the password entered is wrong the
homeowner has a maximum number of three tries to enter the correct
password. If the three tries are exceeded the system is locked. Locked
system has looped timer.

Return to parent-slide containing images.

© McGraw Hill 46
 State Diagram – Text Alternative
Return to parent-slide containing images.

The state diagram shows an initial state of the process. After the key is hit
the diagram shows a reading state. The reading state transitions the
entered password to a comparing state. The comparing state is a shown as
a class with a validate password operation. The comparing state has a
loop, if password equals incorrect and number of tries greater than
maximum number of tries. When number of tries exceeds maximum
number of tries the comparing state transitions to a locked state. A locked
state has a loop with timer greater than locked time. When timer greater
than locked time the locked state transitions back to the reading state. If
the password entered is correct the comparing state transitions to a
selecting state. Upon a successful activation selecting state transitions
back to the reading state.

Return to parent-slide containing images.

© McGraw Hill 47
 Activity Diagram – Text Alternative 2

Return to parent-slide containing images.

The activity diagram begins with an initial state. The next activity state is enter
password and user ID. This initiates a condition. If a password and ID are valid
and if a password and ID are invalid. If invalid, then prompt for reentry activity.
This entails another condition. If input tries remain the process loops back to the
initial condition at enter password and ID if no input tries remain the process
reaches an end state. If in the initial condition the valid ID and password were
entered the next activity is select major function here other functions may also be
selected. After this next activity is select surveillance. After selecting
surveillance, the user can choose thumbnail views or select a specific camera.
Selecting thumbnail, leads to select specific camera thumbnails and selecting a
specific camera leads to select camera icon. Both, select specific camera
thumbnails and select camera icon lead to view camera in output in labeled
window. This leads to prompt for another view. This leads to two condition. First
exit this function which leads to a final state or see another camera which loops
back to the condition under select surveillance.

Return to parent-slide containing images.

© McGraw Hill 48
 Swimlane Diagram – Text Alternative
Return to parent-slide containing images.

The swimlane diagram is illustrated within a table. The three column headings of the table
are: homeowner, camera and interface. The flow begins with an initial state in
homeowner. The next activity state is enter password and user I D. This initiates a
condition in the interface. If a password and ID are valid and if a password and ID are
invalid. If invalid, then prompt for reentry activity. This entails another condition also
within interface. If input tries remain the process loops back to the initial condition at
enter password and ID if no input tries remain the process reaches an end state. If in the
initial condition the valid ID and password were entered the next activity is select major
function, under homeowner, here other functions may also be selected. After this next
activity is select surveillance. After selecting surveillance, the user can choose thumbnail
views or select a specific camera. Selecting thumbnail, leads to select specific camera
thumbnails and selecting a specific camera leads to select camera icon. Both, select
specific camera thumbnails and select camera icon lead to, the activity, generate video
output, under the column camera. Generate video output leads to view camera in output in
labeled window, under homeowner. This leads to prompt for another view under interface.
This leads to two conditions. First exit this function which leads to a final state or see
another camera which loops back to the condition under select surveillance.

Return to parent-slide containing images.

© McGraw Hill 49
 Because learning changes everything.®

Chapter 9
Design Concepts

Part Two - Modeling

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
 Design
● Design is pivotal to successful software engineering.
● Some developers are tempted to begin programming once the
use cases have been created, without regard to how the software
components needed to implement the use cases relate to one
another
● It is possible to do analysis, design, and implementation
iteratively by creating several software increments.

© McGraw Hill 2
 Software Design
• Encompasses the set of principles, concepts, and practices that
lead to the development of a high quality system or product.
• Design principles establish and overriding philosophy that guides
the designer as the work is performed.
• Design concepts must be understood before the mechanics of
design practice are applied.
• Software design practices change continuously as new methods,
better analysis, and broader understanding evolve.

© McGraw Hill 3
 Software Engineering Design
• Data/Class design – transforms analysis classes into
implementation classes and data structures.
• Architectural design – defines relationships among the major
software structural elements.
• Interface design – defines how software elements, hardware
elements, and end-users communicate.
• Component-level design – transforms structural elements into
procedural descriptions of software components.

© McGraw Hill 4
 Mapping Requirements Model to
Design Model

Access the text alternative for slide images.

© McGraw Hill 5
 Design and Quality
● The importance of software design can be stated with a single
word—quality.
● It is a place where quality is fostered in software engineering.
● Provides representation of software that can be assessed for
quality.
● Design is the only way that you can accurately translate
stakeholders’ requirements into a finished software product or
system.
● Software design serves as the foundation for all the software
engineering and software support activities that follow.
● Without design, you risk building an unstable system.

© McGraw Hill 6
 Design and Quality
• The design must implement all of the explicit requirements
contained in the analysis model, and it must accommodate all of
the implicit requirements desired by the customer.
• The design should be a readable, understandable guide for those
who generate code and for those who test and subsequently
support the software.
• The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from an
implementation perspective.

© McGraw Hill 7
 Quality Guidelines
1. A design should exhibit an architecture (a) created using recognizable
architectural styles or patterns, (b) composed of well designed components
(c) implemented in an evolutionary fashion.
2. A design should be modular.
3. A design should contain distinct representations of data, architecture,
interfaces, and components.
4. A design should lead to data structures that are drawn from recognizable data
patterns.
5. A design should contain functionally independent components.
6. A design should lead to interfaces that reduce the complexity of connections
between components and the external environment.
7. A design should be derived using a repeatable method that is driven by
software requirements analysis.
8. A design should be represented using meaningful notation.

© McGraw Hill 8
 Common Design Characteristics
Each new software design methodology introduces unique
heuristics and notions – yet they each contain:
1. A mechanism for the translating the requirements model into a
design representation.
2. A notation for representing functional components and their
interfaces.
3. Heuristics for refinement and partitioning.
4. Guidelines for quality assessment.

© McGraw Hill 9
 Design Concepts 1

• Abstraction – data (named collection of data describing data

object), procedural (name sequence of instructions with specific
and limited function).
• At the highest level of abstraction, a solution is stated in broad terms using the
language of the problem environment (e.g., a user story).
• At lower levels of abstraction, a more detailed description of the solution is
provided.
• Problem-oriented terminology is coupled with implementation-oriented
terminology to state a solution (e.g., use case).
• Finally, at the lowest level of abstraction, the solution is stated in a manner that can
be directly implemented (e.g., pseudocode).

• Architecture - overall structure or organization of software

components, ways components interact, and structure of data
used by components.

© McGraw Hill 10
 Design Concepts 2

• Design Patterns - describe a design structure that solves a

well-defined design problem within a specific context.
• 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
• Separation of concerns - any complex problem can be more
easily handled if it is subdivided into pieces.
• A concern is a feature or behavior that is specified as part of the requirements
model for the software.
• By separating concerns into smaller and therefore more manageable pieces, a
problem takes less effort and time to solve.
• Modularity—compartmentalization of data and function.
• Software is divided into separately named and addressable components, sometimes
called modules, that are integrated to satisfy problem requirements.

© McGraw Hill 11
 Modularity and Software Cost

Access the text alternative for slide images.

© McGraw Hill 12
 Design Concepts 3

• Information Hiding - controlled interfaces which define and

enforces access to component procedural detail and any local
data structure used by the component.
• Hiding defines and enforces access constraints to both procedural detail within a
module and any local data structure used by the module

• Functional independence - single-minded (high cohesion)

components with aversion to excessive interaction with other
components (low coupling).
• Is a direct outgrowth of separation of concerns, modularity, and the concepts of
abstraction and information hiding. In landmark papers on software design, each
allude to refinement techniques that enhance module independence.

© McGraw Hill 13
 Design Concepts 4

• Stepwise Refinement – incremental elaboration of detail for all

abstractions.
• Successively refining levels of procedural detail is a good way to develop an
application. 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 a process of elaboration.
• Refactoring—a reorganization technique that simplifies the
design without changing functionality.
• 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.
• Design Classes—provide design detail that will enable analysis
classes to be implemented.

© McGraw Hill 14
 Design Class Example

Access the text alternative for slide images.

© McGraw Hill 15
 Design Class Characteristics
• Complete - includes all necessary attributes and methods) and
sufficient (contains only those methods needed to achieve class
intent).
• Primitiveness – each class method focuses on providing one
service. Once the service has been implemented with a method,
the class should not provide another way to accomplish the same
thing.
• High cohesion – small, focused, single-minded classes.
• Low coupling – class collaboration kept to minimum.If a design
model is highly coupled (all design classes collaborate with all
other design classes), the system is difficult to implement, to test,
and to maintain over time.

© McGraw Hill 16
 Information Hiding
• Reduces the likelihood of “side effects.”
• Limits the global impact of local design decisions.
• Emphasizes communication through controlled interfaces.
• Discourages the use of global data.
• Leads to encapsulation—an attribute of high quality design.
• Results in higher quality software.

© McGraw Hill 17
 Architecture Properties
• Structural properties. This aspect of the architectural design
representation defines the components of a system (for example,
modules, objects, filters) and the manner in components are
packaged and interact with one another.
• Extra-functional properties. The architectural design
description should address how the design architecture achieves
requirements for performance, capacity, reliability, security,
adaptability, and other characteristics.
• Families of related systems. The architectural design should
draw upon repeatable patterns (building blocks) often
encountered in the design of similar systems.

© McGraw Hill 18
 Design Pattern Template
Pattern name - describes the essence of the pattern in a short but expressive name

Intent - describes the pattern and what it does

Also-known-as - lists any synonyms for the pattern

Motivation - provides an example of the problem

Applicability - notes specific design situations in which the pattern is applicable

Structure - describes the classes that are required to implement the pattern

Participants - describes the responsibilities of the classes that are required to implement the pattern

Collaborations - describes how the participants collaborate to carry out their responsibilities

Consequences - describes the “design forces” that affect the pattern and the potential trade-offs that
must be considered when the pattern is implemented

Related patterns - cross-references related design patterns

© McGraw Hill 19
 Design Model

Access the text alternative for slide images.

© McGraw Hill 20
 Design Modeling Principles 1

• Principle #1. Design should be traceable to the requirements

model.
• Principle #2. Always consider the architecture of the system to
be built.
• Principle #3. Design of data is as important as design of
processing functions.
• Principle #4. Interfaces (both internal and external) must be
designed with care.
• Principle #5. User interface design should be tuned to the needs
of the end-user and stress ease of use.

© McGraw Hill 21
 Design Modeling Principles 2

• Principle #6. Component-level design should be functionally

independent.
• Principle #7. Components should be loosely coupled to each
other than the environment.
• Principle #8. Design representations (models) should be easily
understandable.
• Principle #9. The design should be developed iteratively.
• Principle #10. Creation of a design model does not preclude
using an agile approach.

© McGraw Hill 22
 Data Design Elements
Data model – data objects and database architectures.
• Examines data objects independently of processing.
• Focuses attention on the data domain.
• Creates a model at the customer’s level of abstraction.
• Indicates how data objects relate to one another.

Data object can be an external entity, a thing, an event, a place, a

role, an organizational unit, or a structure.
Data objects contain a set of attributes that act as an quality,
characteristic, or descriptor of the object.
Data objects may be connected to one another in many different
ways.

© McGraw Hill 23
 Architectural Design Elements
Architectural design for software - equivalent to the floor plan for a
house.
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 analysis classes and
their relationships (collaborations) for the problem at hand, and
• Availability of architectural patterns and styles.

© McGraw Hill 24
 Interface Design Elements
Interface is a set of operations that describes the externally
observable behavior of a class and provides access to its public
operations.
Important elements:
• User interface (UI).
• External interfaces to other systems.
• Internal interfaces between various design components.

UI or User Experience (UX) is a major engineering action to ensure

the creation on usable software products.
Internal and external interfaces should incorporate both error
checking and appropriate security features.

© McGraw Hill 25
 Interface Model for Control Panel

Access the text alternative for slide images.

© McGraw Hill 26
 Component-Level Design Elements
Describes the internal detail of each software component.
Defines:
• Data structures for all local data objects.
• Algorithmic detail for all component processing functions.
• Interface that allows access to all component operations.

Modeled using UML component diagrams.

© McGraw Hill 27
 Deployment Design Elements
Indicates how software functionality and subsystems will be
allocated within the physical computing environment.
Modeled using UML deployment diagrams.
• Descriptor form deployment diagrams - show the computing environment but
does not indicate configuration details.
• Instance form deployment diagrams - identify specific hardware
configurations and are developed in the latter stages of design.

© McGraw Hill 28
 UML Deployment Instance Diagram

Access the text alternative for slide images.

© McGraw Hill 29
Because learning changes everything. ®

www.mheducation.com

© 2020 McGraw-Hill Education. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw-Hill Education.
 Accessibility Content: Text Alternatives for Images

© McGraw Hill 31
 Mapping Requirements Model to
Design Model – Text Alternative
Return to parent-slide containing images.

An illustration maps requirement model to design model. The requirement or

analysis model is has three components, Behavioral elements, class-based
elements, and scenario-based elements. The behavioral elements contain state
diagrams, actively diagrams. The class-based elements contain class diagrams,
analysis packages, CRC models, and collaboration diagrams. The scenario-based
elements contain, use cases - test, use case diagrams, swim line diagrams, and
sequence diagrams. The Design model is pyramid shaped with four levels from
top to bottom as component - level design, interface design, architectural design,
and data or class design. The components of the analysis model connect to
different levels in the design model as follow. The behavioral elements, and class
based elements are connected to the component level design. Behavioral
elements and scenario based elements are connected to the interface design. The
class based elements are connected to the architectural design and data or class
design level.

Return to parent-slide containing images.

© McGraw Hill 32
 Modularity and Software Cost – Text
Alternative
Return to parent-slide containing images.

A graph plots cost of effort versus number of modules. The plotted graph has
three curves labeled: total software cost, cost to integrate, and cost per module.
The curve for cost to ingrate rises from the origin and approaches a hypothetical
vertical asymptote. The cost per module curve falls from the positive y axis
approaching the positive x axis. The x axis acts as the horizontal asymptote for
the curve. The curve for total software cost falls and rises between the upper
intersection of the two curves: cost per module and cost to integrate. A region
label M is the region of minimum cost and comprises of the region contained
between two dotted vertical lines which are plotted on either sides of the two
intersecting curves.

Return to parent-slide containing images.

© McGraw Hill 33
 Design Class Example – Text
Alternative
Return to parent-slide containing images.

The diagram shows a design class example. The various class names in the
diagram are as follow: wall segment, window, segment, floorplan and camera.
The attributes and operation for each class are as follow. Segment, attributes are:
start coordinate and end coordinate. The operations are: get type and draw.
Floorplan attributes are: type and outside dimension. The operations are: add
camera, add wall, add window delete segment and draw. Camera, attributes are:
type, ID, field view, pan angle and zoom setting. The relationship in the class
diagram is as follow: segment has an inheritance relationship with wall segment
and window. Floorplan has an aggregation relationship with segment with
exactly one cardinality. Floorplan has one to many association with camera.

Return to parent-slide containing images.

© McGraw Hill 34
 Design Model – Text Alternative
Return to parent-slide containing images.

The design model is explained in a graphical representation. The y axis plots abstraction dimension
which range from low to high. The design model is plotted in the low region and analysis model is
plotted in the high region. The x axis plots process dimension for architecture elements, interface
elements, component level elements and deployment level elements. For architecture elements the flow
from high to low is as follows. In the high range under the analysis model the components are: class
diagrams, analysis packages, CRC models, collaboration diagrams and processing narratives. Between
high and low for analysis model the components are: design class realization, subsystems, and
collaboration diagrams. The low components under design model are: refinements to design class
realizations, subsystems and collaboration diagrams. For interface elements only the components under
the analysis model are used. The components ranging from high to low are: uses cases-text, use case
diagrams, swimlane diagrams, processing narratives, state diagrams, and sequence diagrams. The
mid-range components are: technical interface design, navigation design and GUI design. For
component level elements, under the analysis model, the components ranging from high to low are:
Class diagrams, analysis packages, CRC models, collaboration diagrams, processing narratives, state
diagrams, and sequence diagrams. The mid-range components are: components diagrams, design classes,
activity diagrams, and sequence diagrams. The low components under design model are: refinements to
component diagrams, design classes, activity diagrams, and sequence diagrams. For deployment level
elements, under the analysis model, the requirements ranging from high to low are: constraints,
interoperability and targets and configuration. The low components under design model are: design class
realizations, subsystems, collaboration diagrams, design classes, activity diagrams, and sequence
diagrams. This leads to the deployment diagrams.

Return to parent-slide containing images.

© McGraw Hill 35
 Interface Model for Control Panel –
Text Alternative
Return to parent-slide containing images.

A class diagram for an interface model for control panel. A tablet or a

smartphone has dependency relationship with the keypad. The keypad has an
association with the control panel. The control panel has realization relationship
with the keypad interface. The control panel has the following attributes and
operations. Attributes: LCD display, LED indicators, keypad characteristics,
speaker and wireless interface. Operations: read key stroke, decode key, display
status, light LEDs, send control message. The keypad interface has the following
operations: read key stroke and decode key.

Return to parent-slide containing images.

© McGraw Hill 36
 UML Deployment Instance Diagram
– Text Alternative
Return to parent-slide containing images.

An illustration displays UML development instance diagram. The three classes

are: control panel, CPI server, and personal computer. The personal computer
contains external access, security, surveillance, home management, and
communication. The external access of the personal computer is connected to the
security of the control panel, and home owner access of the CPI server.

Return to parent-slide containing images.

© McGraw Hill 37
 Because learning changes everything.®

Chapter 10
Architectural Design – A
Recommended Approach

Part Two - Modeling

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
 What is Software Architecture?
The architecture is not the operational software, 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.

© McGraw Hill 2
 Why is Software Architecture
Important?
• Software architecture provides a representation that facilitates
communication among all stakeholders interested in the
development of a computer-based system.
• Architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows.
• Architecture constitutes a relatively small, intellectually
graspable mode of how the system is structured and how its
components work together.

© McGraw Hill 3
 Architectural Descriptions
The IEEE Computer Society has proposed IEEE-Std-42010-2011, Systems and
Software Engineering – Architecture Description.
Describes the use of architecture viewpoints, architecture frameworks, and architecture
description languages as a means of codifying the conventions and common practices
for architectural description.

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

of products to document an architecture.”
• An architecture description shall identify the system stakeholders having concerns
considered fundamental to the architecture of the system-of-interest.
• These concerns shall be considered when applicable and identified in the architecture
description: system purpose, suitability of the architecture, feasibility of constructing
and deploying the system, risks and impacts of the system, and the maintainability and
evolvability of the system.

© McGraw Hill 4
 Architecture Decision Documentation
1. Determine information items needed for each decision.
2. Define links between each decision and appropriate
requirements.
3. Provide mechanisms to change status when alternative decisions
need to be evaluated.
4. Define prerequisite relationships among decisions to support
traceability.
5. Link significant decisions to architectural views resulting from
decisions.
6. Document and communicate all decisions as they are made.

© McGraw Hill 5
 Agility and Architecture
• To avoid rework, user stories are used to create and evolve an
architectural model (walking skeleton) before beginning any
coding.
• Use models which allow software architects to add user stories to
the evolving storyboard and works with the product owner to
prioritize the architectural stories as “sprints” (work units) are
planned.
• Well-run agile projects include delivery of architectural
documentation during each sprint.
• After the sprint is completed, the architect reviews the working
prototype for quality before the team presents it to the
stakeholders in a formal sprint review.

© McGraw Hill 6
 Architectural Styles
Each style describes a system category that encompasses:
1. set of components (for example: a database, computational
modules) that perform a function required by a system.
2. set of connectors that enable “communication, coordination
and cooperation” among components.
3. constraints that define how components can be integrated to
form the system.
4. semantic models that enable a designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts.

© McGraw Hill 7
 Data Centered Architecture

Access the text alternative for slide images.

© McGraw Hill 8
 Data Centered Architecture
● A data store resides at the centre of architecture and is accessed
by other components that update, add, delete or otherwise
modify data within 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.
● 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

© McGraw Hill 9
 Data Flow Architecture

Access the text alternative for slide images.

© McGraw Hill 10
 Data Flow Architecture
● 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.
● However, the filter does not require knowledge of the workings
of its neighboring filters.

© McGraw Hill 11
 Call-and-Return Architecture

Access the text alternative for slide images.

© McGraw Hill 12
 Call-and-Return Architecture
● This architectural style enables you to achieve a program
structure that is relatively easy to modify and scale.
○ Main program/subprogram architectures. This classic
program structure decomposes function into a control
hierarchy where a “main” program invokes several program
components, which in turn may invoke still other
components.
○ Remote procedure call architectures. The components of a
main program/ subprogram architecture are distributed
across multiple computers on a network.

© McGraw Hill 13
 Object-Oriented Architecture

Access the text alternative for slide images.

© McGraw Hill 14
 Object-Oriented Architecture
● 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.
● Contains a UML communication diagram that shows the
message passing for the login portion of a system implemented
using an object-oriented architecture.

© McGraw Hill 15
 Layered Architecture

Access the text alternative for slide images.

© McGraw Hill 16
 Layered Architecture
● 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.

© McGraw Hill 17
 Model View Controller Architecture

Access the text alternative for slide images.

© McGraw Hill 18
 Model View Controller Architecture
● MVC suggested mobile infrastructure models often used in
Web development.
● The model contains all application-specific content and
processing logic.
● The view contains all interface-specific functions and enables
the presentation of content and processing logic required by the
end user.
● The controller manages access to the model and the view and
coordinates the flow of data between them.
● User requests are handled by the controller. The controller also
selects the view object that is applicable based on the user
request. Once the type of request is determined, a behavior
request is transmitted to the model, which implements the
functionality or retrieves the content required to accommodate
the request.
© McGraw Hill 19
 Architectural Organization and
Refinement 1

Control.
• How is control managed within the architecture?
• Does a distinct control hierarchy exist, and if so, what is the role
of components within this control hierarchy?
• How do components transfer control within the system?
• How is control shared among components?
• What is the control topology (that is, the geometric form that the
control takes)?
• Is control synchronized, or do components operate
asynchronously?

© McGraw Hill 20
 Architectural Organization and
Refinement 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?
• Do data components exist, and if so, what is their role?
• How do functional components interact with data components?
• Are data components passive or active?
• How do data and control interact within the system?

© McGraw Hill 21
 Architectural Considerations
• Economy – software is uncluttered and relies on abstraction to
reduce unnecessary detail.
• Visibility – Architectural decisions and their justifications should
be obvious to software engineers who review.
• Spacing – Separation of concerns in a design without
introducing hidden dependencies.
• Symmetry – Architectural symmetry implies that a system is
consistent and balanced in its attributes.
• Emergence – Emergent, self-organized behavior and control are
key to creating scalable, efficient, and economic software
architectures.

© McGraw Hill 22
 Architectural Design
The software must be placed into context.
• The design should define the external entities (other systems, devices,
people) that the software interacts with and the nature of the
interaction.
A set of architectural archetypes should be identified.
• An archetype is an abstraction (similar to a class) that represents one
element of system behavior.
The designer specifies the structure of the system by defining and
refining software components that implement each archetype.

© McGraw Hill 23
 Architecture Context Diagram

Access the text alternative for slide images.

© McGraw Hill 24
 Architecture Context Diagram
● The overall SafeHome product controller and the Internet-based
system are both superordinate to the security function and are
shown above the function.
● The surveillance function is a peer system and uses (is used by)
the home security function in later versions of the product.
● The homeowner and control panels are actors that produce and
consume information that is, respectively, used and produced
by the security software.
● Finally, sensors are used by the security software and are shown
as subordinate to it

© McGraw Hill 25
 SafeHome Security Function Archetype

Access the text alternative for slide images.

© McGraw Hill 26
 SafeHome Top-Level Component
Architecture

Access the text alternative for slide images.

© McGraw Hill 27
 SafeHome Refined Component
Architecture

Access the text alternative for slide images.

© McGraw Hill 28
 Architectural Tradeoff Analysis
1. Collect scenarios.
2. Elicit requirements, constraints, environment description.
3. Describe the architectural styles/patterns that have been chosen
to address the scenarios and requirements using one of these
views: module, process, data flow.
4. Evaluate quality attributes by considering each one in isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis (conducted in step 5).

© McGraw Hill 29
 Architectural Reviews
• Assess the ability of the software architecture to meet the
systems quality requirements and identify potential risks.

• Have the potential to reduce project costs by detecting design

problems early.

• Often make use of experience-based reviews, prototype

evaluation, and scenario reviews, and checklists.

© McGraw Hill 30
 Pattern-based Architectural Reviews
1. Identify and discuss the quality attributes by walking through
the use cases.
2. Discuss a diagram of system’s architecture in relation to its
requirements.
3. Identify the architecture patterns used and match the system’s
structure to the patterns’ structure.
4. Use existing documentation and use cases to determine each
pattern’s effect on quality attributes.
5. Identify all quality issues raised by architecture patterns used in
the design.
6. Develop a short summary of issues uncovered during the
meeting and make revisions to the walking skeleton.

© McGraw Hill 31
Because learning changes everything. ®

www.mheducation.com

© 2020 McGraw-Hill Education. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw-Hill Education.
 Accessibility Content: Text Alternatives for Images

© McGraw Hill 33
 Data Centered Architecture – Text Alternative
Return to parent-slide containing images.

An illustration displays a data centered architecture. The diagram

reads data store (repository or blackboard), multiple client
softwares placed around it are connected to the data store.

Return to parent-slide containing images.

© McGraw Hill 34
 Data Flow Architecture – Text Alternative
Return to parent-slide containing images.

The diagram shows a data flow architecture. Each rectangular

component is the architecture is labeled a filter and the connecting
arrows between the filters are labeled pipes. The data flow is read
in the right to left direction.

Return to parent-slide containing images.

© McGraw Hill 35
 Call Return Architecture – Text Alternative
Return to parent-slide containing images.

A flowchart displays call return architecture. The main program is

connected to three controller subprograms. Each controller
subprograms are connected to two application subprograms each.
These two subprograms again constitutes an application
subprogram.

Return to parent-slide containing images.

© McGraw Hill 36
 Object-Oriented Architecture – Text
Alternative
Return to parent-slide containing images.

The diagram shows an object oriented architecture. An actor

connects to a security logon and requests logon and enters name
password on logon. The security logon has an internal loop that
relays: display, display message, and display logon. If the security
logon is valid, the actor accesses the account data base. After
selecting the user type the actor accessed the system.

Return to parent-slide containing images.

© McGraw Hill 37
 Layered Architecture – Text Alternative
Return to parent-slide containing images.

An illustration displays layered architecture. The circular diagram

has four layers: core layer, utility layer, application layer, and user
interface layer from inner to outer level. The outer level is in a
semicircle form. Each layer has components displayed with squares
which are decreasing in number from outer to inner layers.

Return to parent-slide containing images.

© McGraw Hill 38
 Model View Controller Architecture – Text
Alternative
Return to parent-slide containing images.

The diagram shows a model view controller architecture. The

architecture contains three section. The client, the server and the external
data. A client accessed a browser. The browser connects to the server via
two paths. the server contains controller, model and view. The browser
sends a user request or data to the controller or the browser accesses HT
ML data in the view. The controller manages user requests, selects model
behavior and selects view response. The view prepares data from model,
requests update from model and presents view selected by controller.
The model, encapsulates functionality, encapsulates content objects and
incorporates all web app states. The controller sends a view selection to
view and sends a sends a state change behavior request to model. View
receives the data from model and sends an updated request to model.
Model has a two data exchange with external data.

Return to parent-slide containing images.

© McGraw Hill 39
 Architecture Context Diagram – Text
Alternative
Return to parent-slide containing images.

The diagram shows an architecture context design. A central target

system in this case a security function. The security function uses
the following external entities. Homeowner, control panel, safe
home product, internet based system, surveillance function, and
sensors.

Return to parent-slide containing images.

© McGraw Hill 40
 SafeHome Security Function Archetype – Text
Alternative
Return to parent-slide containing images.

The diagram shows the safehome security function archetype: The

archetypal class connections from bottom to top are as follow:
detector and indicator connect to the node. The node connects to
the controller. The controller communicates in a loop with itself.

Return to parent-slide containing images.

© McGraw Hill 41
 SafeHome Top-Level Component Architecture –
Text Alternative
Return to parent-slide containing images.

The safe-home top-level component architecture from bottom to

top is as follows: at level 5 the control panel processing, detector
management and alarm processing connect to the security on level
3. At level 4, GUI and the internet interface connect to the external
communication management on level 2. At level 3, security,
surveillance and home management connect to the safe home
executive at level 1. At level 2, external communication
management connects to the safe home executive at level 1

Return to parent-slide containing images.

© McGraw Hill 42
 SafeHome Refined Component Architecture –
Text Alternative
Return to parent-slide containing images.

The safe-home refined component architecture from bottom to top is as

follows: at level 7 the sensor connects to the scheduler on level 6. The
components on level 6 are: keypad processing, CP display functions,
scheduler, phone communication and alarm. Keypad processing and CP
display functions connect to the control panel processing. Scheduler
connects to the detector management. Phone communication and alarm
connect to the alarm processing. All connections are from level 6 to
level 5. At level 5 the control panel processing, detector management
and alarm processing connect to the security on level 3. At level 4, GUI
and the internet interface connect to the external communication
management on level 2. At level 3, security, surveillance and home
management connect to the safe home executive at level 1. At level 2,
external communication management connects to the safe home
executive at level 1
Return to parent-slide containing images.
© McGraw Hill 43
 Because learning changes everything.®

Chapter 11
Component-Level Design

Part Two - Modeling

© 2020 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
 What is a component? 1

• OMG Unified Modeling Language Specification defines a

component as
“… a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.””
• Object-Oriented view: 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 part
of the design elaboration, all interfaces that enable the classes to
communicate and collaborate with other design classes must also be defined.
To accomplish this, you begin with the analysis model and elaborate
analysis classes (for components that relate to the problem domain) and
infrastructure classes (for components that provide support services for the
problem domain).

© McGraw Hill 2
 What is a component? 2

• Traditional view: a component contains processing logic, internal data

structures that are required to implement the processing logic, and an interface
that enables the component to be invoked and data to be passed to it.A
traditional component, also called a module, resides within the software
architecture and serves one of three important roles: (1) a control component
that coordinates the invocation of all other problem domain components, (2) a
problem domain component that implements a complete or partial function
that is required by the customer, or (3) an infrastructure component that is
responsible for functions that support the processing required in the problem
domain.
• Process-related view: building systems out of reusable software
components or design patterns selected from a catalog (component-based
software engineering). Because 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

© McGraw Hill 3
 Class-based Component-Level Design

Access the text alternative for slide images.

© McGraw Hill 4
 Traditional Component-Level Design 1

Access the text alternative for slide images.

© McGraw Hill 5
 Basic Component Design Principles
• Open-Closed Principle (OCP). “A module [component] should be open for
extension but closed for modification. Stated simply, you should specify the
component in a way that allows it to be extended (within the functional domain that it
addresses) without the need to make internal (code or logic-level) modifications to
the component itself.

• Liskov Substitution Principle (LSP). “Subclasses should be substitutable

for their base classes.A “contract” is a precondition that must be true before the
component uses a base class and a postcondition that should be true after the
component uses a base class. When you create derived classes, be sure they conform
to the pre- and postconditions.

• Dependency Inversion Principle (DIP). “Depend on abstractions. Do not

depend on concretions.”The more a component depends on other concrete
components (rather than on abstractions such as an interface), the more difficult it
will be to extend. Just remember that code is the ultimate concretion.

© McGraw Hill 6
 Basic Component Design Principles
• Interface Segregation Principle (ISP). “Many client-specific interfaces are
better than one general purpose interface. There are many instances in which
multiple client components use the operations provided by a server class. ISP suggests
that you should create a specialized interface to serve each major category of clients.
• Release Reuse Equivalency Principle (REP). “The granule of reuse is the
granule of release.”When classes or components are designed for reuse, an implicit
contract is established between the developer of the reusable entity and the people who
will use it. The developer commits to establish a release control system that supports
and maintains older versions of the entity while the users slowly upgrade to the most
current version. Rather than addressing each class individually.
• Common Closure Principle (CCP). “Classes that change together belong
together.”Classes should be packaged cohesively. That is, when classes are packaged
as part of a design, they should address the same functional or behavioral area.
• Common Reuse Principle (CRP). “Classes that aren’t reused together
should not be grouped together.”When one or more classes with a package
changes, the release number of the package changes. All other classes or packages that
rely on the package that has been changed must now update to the most recent release
of the package and be tested to ensure that the new release operated without incident.

© McGraw Hill 7
 Component-Level Design Guidelines
• Components - Naming conventions should be established for
components that are specified as part of the architectural model
and then refined and elaborated as part of the component-level
model.Architectural component names should be drawn from the
problem domain and should have meaning to all stakeholders
who view the architectural model.
• Interfaces - provide important information about communication
and collaboration (as well as helping us to achieve the O PC).
• Dependencies and Inheritance – For readability, it is a good
idea to model dependencies from left to right and inheritance
from bottom (derived classes) to top (base classes).

© McGraw Hill 8
 Cohesion
Traditional view - the “single-mindedness” of a module.
Object-Oriented view - cohesion implies that a component
encapsulates only attributes and operations that are closely related
to one another and the component itself.
Levels of cohesion:
• Functional - module performs one and only one computation.
• Layer - occurs when a higher layer accesses the services of a lower layer,
but lower layers do not access higher layers. Eg- SafeHome security
function requirement to make an outgoing phone call if an alarm is sensed.
• Communicational - All operations that access the same data are defined
within one class.

© McGraw Hill 9
 Coupling
Traditional view - degree to which a component is connected to
other components and to the external world.
Object-Oriented view - qualitative measure of the degree to
which classes are connected to one another.
Levels of coupling.
• Content - occurs when one component “surreptitiously modifies data that is
internal to another component.
• Control – occurs when control flags a passed to components to requests
alternate behaviors when invoked.
• External - occurs when a component communicates or collaborates with
infrastructure components.

© McGraw Hill 10
 Problem Domain
● The problem domain represents the area or subject matter that a
system or software application is designed to address.
● It focuses on the specific problem or set of problems that the
software is intended to solve.
● In software development, understanding the problem domain is
crucial for defining requirements, designing solutions, and
implementing features that directly address the needs of users
or stakeholders.
● It includes the business rules, processes, and requirements that
are relevant to the application or system.

© McGraw Hill 11
 Infrastructure Domain
● The infrastructure domain, on the other hand, deals with the
underlying technical foundation and components that support
the software or system.
● This includes hardware, networking, servers, databases,
operating systems, and other technical aspects necessary for the
functioning and deployment of the software.
● Infrastructure domain considerations are more focused on the
technical and operational aspects of the system, ensuring that it
has the necessary resources, scalability, security, and
performance to meet the requirements of the problem domain.

© McGraw Hill 12
 Component-Level Design 1

• Step 1. Identify all design classes that correspond to the problem

domain.
• Step 2. Identify all design classes that correspond to the
infrastructure domain.
• Step 3. Elaborate all design classes that are not acquired as
reusable components.
• Step 3a. Specify message details when classes or component
collaborate.
• Step 3b. Identify appropriate interfaces for each component.

© McGraw Hill 13
 Collaboration Diagram with Message Detail

Access the text alternative for slide images.

© McGraw Hill 14
 Define Interfaces

Access the text alternative for slide images.

© McGraw Hill 15
 Component-Level Design 2

• Step 3c. Elaborate attributes and define data types and data
structures required to implement them.
• Step 3d. Describe processing flow within each operation in
detail.
• 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.
• Step 6. Elaborate deployment diagrams to provide additional
implementation detail.
• Step 7. Factor every component-level design representation and
always consider alternatives.

© McGraw Hill 16
 Describe Processing Flow

Access the text alternative for slide images.

© McGraw Hill 17
 Elaborate Behavioral Representations

Access the text alternative for slide images.

© McGraw Hill 18
 Component-Level Design for WebApps
WebApp component is:
1. a well-defined cohesive function that manipulates content or
provides computational or data processing for an end-user, or.
2. a cohesive package of content and functionality that provides
end-user with some required capability.

Component-level design for WebApps often incorporates elements

of content design and functional design.

© McGraw Hill 19
 WebApp Content Design
Focuses on content objects and the manner in which they may be packaged for
presentation to a WebApp end-user
Consider a Web-based video surveillance capability within
SafeHomeAssured.com potential content components can be defined for the
video surveillance capability:
1. the content objects that represent the space layout (the floor plan) with
additional icons representing the location of sensors and video cameras;
2. the collection of thumbnail video captures (each an separate data object), and
3. the streaming video window for a specific camera.

Each of these components can be separately named and manipulated as a

package.

© McGraw Hill 20
 WebApp Functional Design
Modern Web applications deliver increasingly sophisticated processing
functions that:
1. perform localized processing to generate content and navigation capability
in a dynamic fashion;
2. provide computation or data processing capability that is appropriate for
the WebApp’s business domain;
3. provide sophisticated database query and access, or.
4. establish data interfaces with external corporate systems.
To achieve these (and many other) capabilities, you will design and construct
WebApp functional components that are identical in form to software
components for conventional software.

© McGraw Hill 21
 Component-Level Design for Mobile Apps
Thin web-based client.
• Interface layer only on device.
• Business and data layers implemented using web or cloud
services.
Rich client.
• All three layers (interface, business, data) implemented on
device.
• Subject to mobile device limitations.

© McGraw Hill 22
 Traditional Component-Level Design 2

• Design of processing logic is governed by the basic principles

of algorithm design and structured programming.
• Design of data structures is defined by the data model
developed for the system.
• Design of interfaces is governed by the collaborations that a
component must effect.

© McGraw Hill 23
 Component-Based Software Engineering (CBSE)
The software team asks:
• Are commercial off-the-shelf (COTS) components available to
implement the requirement?
• Are internally-developed reusable components available to
implement the requirement?
• Are the interfaces for available components compatible within
the architecture of the system to be built?

Access the text alternative for slide images.

© McGraw Hill 24
 CBSE Benefits
• Reduced lead time. It is faster to build complete applications from a pool of
existing components.
• Greater return on investment (ROI). Sometimes savings can be realized by
purchasing components rather than redeveloping the same functionality
in-house.
• Leveraged costs of developing components. Reusing components in
multiple applications allows the costs to be spread over multiple projects.
• Enhanced quality. Components are reused and tested in many different
applications.
• Maintenance of component-based applications. With careful engineering, it
can be relatively easy to replace obsolete components with new or enhanced
components.

© McGraw Hill 25
 CBSE Risks
• Component selection risks. It is difficult to predict component behavior for
black-box components, or there may be poor mapping of user requirements to
the component architectural design.
• Component integration risks. There is a lack of interoperability standards
between components; this often requires the creation of “wrapper code” to
interface components.
• Quality risks. Unknown design assumptions made for the components makes
testing more difficult, and this can affect system safety, performance, and
reliability.
• Security risks. A system can be used in unintended ways, and system
vulnerabilities can be caused by integrating components in untested
combinations.
• System evolution risks. Updated components may be incompatible with user
requirements or contain additional undocumented features.

© McGraw Hill 26
 Component Refactoring
• Most developers would agree that refactoring components to
improve quality is a good practice.
• It is hard to convince management to expend resources fixing
components that are working correctly rather than adding new
functionality to them,
• Changing software and failing to document the changes can lead
to increasing technical debt.
• Reducing this technical debt often involves architectural
refactoring, which is generally perceived by developers as both
costly and risky.
• Developers can make of tools to examine change histories to
identify the most cost effective refactoring opportunities,

© McGraw Hill 27
Because learning changes everything. ®

www.mheducation.com

© 2020 McGraw-Hill Education. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw-Hill Education.
 Accessibility Content: Text Alternatives for Images

© McGraw Hill 29
 Class-based Component-Level Design – Text
Alternative
Return to parent-slide containing images.

The illustration shows a class-based component level design. The

diagram has two class levels. The first is labeled Analysis class and
has the class (print job) with the attributes and operations. The
second class is labeled elaborated class and also has a class (print
job). The class has more attributes and operations. The class also
has two interfaces labeled compute job and initiate job. The
analysis class links to the design component labeled print job and
which relays the process to the elaborated design class.

Return to parent-slide containing images.

© McGraw Hill 30
 Traditional Component-Level Design – 1

Text Alternative Return to parent-slide containing images.

The diagram shows a traditional component-level design. The

diagram has 4 levels. The components and the connections in each
level from bottom to top are. Level: 4 compute page cost; compute
paper cost; compute production cost; check priority; pass job to
production. Level 3: develop job cost; build work order; send job to
production. Level 2: read print job data; select job management
function. Level 1: job management system. The connections are as
follow: compute page cost; compute paper cost; compute
production cost connect to develop job cost. Check priority; pass
job to production connect to send job to production. Develop job
cost; build work order; send job to production connect to select job
management function. Read print job data; select job management
function connect to job management system.
Return to parent-slide containing images.
© McGraw Hill 31
 Collaboration Diagram with Message Detail –
Text Alternative
Return to parent-slide containing images.

The diagram shows a collaboration diagram with message detail. A

production job collaborates with work order and job queue.
Production job relays a message, build job with work order number
to work order. Production job relays a message, submit job with
work order number to job queue.

Return to parent-slide containing images.

© McGraw Hill 32
 Define Interfaces – Text Alternative
Return to parent-slide containing images.

The flow diagram shows how to define interfaces. The diagram

shows two classes on the left: work order and job queue. The
classes have appropriate attributes and a check priority operation.
work order accesses cost from data base. Work order relays a build
job order to production job while job queue relays a submit job
order to production job component. Production job relays an
initiate job order to print job component. The print job component
also has a compute job order.

Return to parent-slide containing images.

© McGraw Hill 33
 Describe Processing Flow – Text Alternative
Return to parent-slide containing images.

The diagram shows how to describe a process flow. The flow starts
with an initial state. The next process are: validate attributes input,
access paper D B for weight, (this returns base cost per page),
paper cost per page equals base cost per page. The next flow in the
diagram shows three conditions: if size = B; if size = C; and if size
= D. Each cost returns a paper cost per page. B = 1,2; C = 1.4; D =
1.6. The next flow in the diagram is a condition for color. If color is
custom, then paper cost per page = 1.14 and if color is standard.
The process then returns the final paper cost per page. End state.

Return to parent-slide containing images.

© McGraw Hill 34
 Elaborate Behavioral Representations –
Text Alternative
Return to parent-slide containing images.

The diagram shows a process flow with elaborate behavioral

representation. From an initial state the process flows to a building
job data class which has varying attributes. If the data input is
incomplete the process loops back and repeats. When data input is
completed then display user options. The next class is computing
job cost which further has multiple attributes. If job cost is
accepted, then costumer is authorized and system gets an electronic
signature. The next class is forming job with its attributes. If deliver
date is accepted customer is authorized and job estimate is printed.
The next class is submitting job which has attributes. If job is
submitted that means all authorizations are acquired the print work
order.

Return to parent-slide containing images.

© McGraw Hill 35
 Component-Based Software Engineering
(CBSE) – Text Alternative
Return to parent-slide containing images.

A component-based software engineering (cbse) has the following

flow: outline system requirement, identify candidate components,
modify requirements according to discovered components, identify
candidate components and compose components to create system.

Return to parent-slide containing images.

© McGraw Hill 36