Design Engineering

Unit3
• 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 chose
 • Component-level Design

• (Class-based model, Flow-oriented model

• Behavioral model)

• Interface Design

• (Scenario-based model, Flow-oriented model

• Behavioral model)

• Architectural Design

• (Class-based model, Flow-oriented model)

• Data/Class Design

• (Class-based model, Behavioral model)

• 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
 Quality Role
• The importance of design is quality
• Design is the place where quality is fostered
– Provides representations of software that can be assessed for quality
– Accurately translates a customer's requirements into a finished software product or system
– Serves as the foundation for all software engineering activities that follow
• Without design, we risk building an unstable system that
– Will fail when small changes are made
– May be difficult to test
– Cannot be assessed for quality later in the software process when time is short and most of
the budget has been spent
• The quality of the design is assessed through a series of formal technical reviews or design
walkthroughs
 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 behavioural requirements
– As design iteration occurs, subsequent refinement leads to design representations at much lower
levels of abstraction.
• The design model can be assessed for quality and be improved before code is generated and tests are
conducted
– Does the design contain errors, inconsistencies, or omissions?
– Are there better design alternatives?
– Can the design be implemented within the constraints, schedule, and cost that have been
established?
 Characteristics for the evaluation of good design:
• The design must implement all of the explicit requirements contained in requirement
model
– It must also accommodate all of the implicit requirements desired by the
customer/stakeholders.
• The design must be a readable, understandable guide for those who generate code, and
for those who test and support the software
• The design should provide a complete picture of the software, addressing the data,
functional, and behavioural domains from an implementation perspective.
 Design Quality Guidelines

1) A design should exhibit an architecture that

a) Has been created using recognizable architectural styles or patterns
b) Is composed of components that exhibit good design characteristics
c) Can be implemented in an evolutionary fashion, thereby facilitating implementation and testing

2) A design should be modular; that is, the software should be logically partitioned into elements or
subsystems

3) A design should contain distinct representations of data, architecture, interfaces, and components

4) A design should lead to data structures that are appropriate for the classes to be implemented and
are drawn from recognizable data patterns
5) A design should lead to components that exhibit independent functional
characteristics
6) A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment
7) A design should be derived using a repeatable method that is driven by information
obtained during software requirements analysis
8) A design should be represented using a notation that effectively communicates its
meaning
 Design Principles
• The design process should not suffer from ‘tunnel vision.’
• The design should “minimize the intellectual distance” between the software and the problem as it
exists in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently, even when aberrant data, events, or operating
conditions are encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being created, not after the fact.
• The design should be reviewed to minimize conceptual (semantic) errors.
 Design Concepts
• Abstraction
– Procedural abstraction – a sequence of instructions that have a specific and limited function
– Data abstraction – a named collection of data that describes a data object.
Procedural Abstraction
 Architecture
• “The overall structure of the software and the ways in which that structure
provides conceptual integrity for a system.”
• One goal of Software design: To derive an architectural rendering of a
system. This rendering serves as a framework from which more detailed
design activities are conducted.
• A set of architectural patterns enable a software engineer to reuse design
level concepts.
• Design can be represented as :
• Structural Models
 Defines the components of a system (e.g., modules, objects, filters) and
 How the components are packaged and interact with one another
• Framework Models
 Increase level of abstraction
• Dynamic Models and Process Models
 Predicts behavioral and reliability aspects
• Functional Models
 Depicts functional Hierarchy.
 Pattern
• Pattern describes a design structure that solves a particular design problem within a
specific context and that may have an impact on the manner in which the pattern is
applied and used.
• It provide description that enables a designer to determine:
1. Whether the pattern is applicable to current work
2. Whether the pattern can be reused
3. Whether the pattern can serve as a guide for developing a similar, but functionally or
structured different pattern.
 Modularity
• In this concept, software is divided into separately named and addressable components
called modules.
• Follows “divide and conquer” concept, a complex problem is broken down into several
manageable pieces.
• Let p 1 and p 2 be two program parts, and E the effort to solve the problem.
• Then, E(p1 +p2 ) > E(p 1 )+E(p 2 ), often >>
• A need to divide software into optimal sized modules.
• Makes software intellectually manageable so as to grasp the control paths, span of
reference, number of variables, and overall complexity
 Information Hiding
– The designing of modules so that the algorithms and local data contained within
them are inaccessible to other modules
– This enforces access constraints to both procedural (i.e., implementation) detail and
local data structures
 Information Hiding(Benefits)

• 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
 Functional Independence
– Modules that have a "single-minded" function and an aversion to excessive interaction with other
modules
– High cohesion – a module performs only a single task
– Low coupling – a module has the lowest amount of connection needed with other modules
 Refinement
• Refinement is a process of elaboration
• It is a top-down design strategy
• A program is developed by successfully refining levels of procedural details.

– Development of a program by successively refining levels of procedure detail

– Complements abstraction, which enables a designer to specify procedure and data
and yet suppress low-level details
 Refactoring

– A reorganization technique that simplifies the design (or internal code

structure) of a component without changing its function or external
behavior
– Removes redundancy, unused design elements, inefficient or unnecessary
algorithms, poorly constructed or inappropriate data structures, or any
other design failures
 Design Classes
– Refines the analysis classes by providing design detail that will enable
the classes to be implemented
– Creates a new set of design classes that implement a software
infrastructure to support the business solution
 Types of Design Classes
• User interface classes – define all abstractions necessary for human-computer interaction
(usually via metaphors of real-world objects).
• Business domain classes – refined from analysis classes; identify attributes and services
(methods) that are required to implement some element of the business domain.
• Process classes – implement business abstractions required to fully manage the business
domain classes.
• Persistent classes – represent data stores (e.g., a database) that will persist beyond the
execution of the software.
• System classes – implement software management and control functions that enable the
system to operate and communicate within its computing environment and the outside world.
 Characteristics of a Well-Formed Design Class
• 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
• Primitiveness
– Each method of a class focuses on accomplishing one service for the class
• High cohesion
– The class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement
those responsibilities
• 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
Design Model:

• The design model can be viewed in two different dimensions

– The process dimension indicates the evolution of the design model as design task
are executed as a part of software process.
– The abstraction dimension represents the level of detail as each element of the
analysis model is transformed into the design model and then iteratively refined
• Elements of the design model use many of the same UML diagrams used in the
analysis model
– The diagrams are refined and elaborated as part of the design
– More implementation-specific detail is provided
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architecture
Design Model
• Design model elements are not always developed in a sequential fashion
– Preliminary architectural design sets the stage
– It is followed by interface design and component-level design, which often occur in parallel
• The design model has the following layered elements
– Data/class design
– Architectural design
– Interface design
– Component-level design
• A fifth element that follows all of
the others is deployment-level design Component-level Design

Interface Design

Architectural Design

Data/Class Design
Data design Elements

• The data design element produced a model of data that represent a high level of
abstraction.
• This model is then more refined into more implementation specific representation
which is processed by the computer based system.
• The structure of data is the most important part of the software design.
• The structure of data can be viewed at three levels, namely, program component level,
application level, and business level.
• At the program component level, the design of data structures and the algorithms
required to manipulate them is necessary, if high-quality software is desired.

• At the application level, it is crucial to convert the data model into a database so that
the specific business objectives of a system could be achieved.

• At the business level, the collection of information stored in different databases should
be reorganized into data warehouse, which enables data mining that has an influential
impact on the business.
Architectural design elements
• The architecture design elements provides us overall view of the system.
• The architectural design element is generally represented as a set of
interconnected subsystem that are derived from analysis packages in the
requirement model.
The architecture model is derived from following sources:
• The information about the application domain to built the software.
• Requirement model elements like data flow diagram or analysis classes,
relationship and collaboration between them.
• The architectural style and pattern as per availability.
Interface design elements
• The interface design elements for software represents the information flow within it
and out of the system.
• They communicate between the components defined as part of architecture.
• Following are the important elements of the interface design:
1. The user interface
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.
Component level diagram elements
• The component level design for software is similar to the set of detailed specification of
each room in a house.
• The component level design for the software completely describes the internal details of
the each software component.
• The processing of data structure occurs in a component and an interface which allows all
the component operations.
• In a context of object-oriented software engineering, a component shown in a UML
diagram.
• The UML diagram is used to represent the processing logic.
Deployment level design elements
• The deployment level design element shows the software functionality and subsystem
that allocated in the physical computing environment which support the software.
• Following figure shows  three computing environment as shown. These are the personal
computer, the CPI server and the Control panel.
ARCHITECTURAL DESIGN

UNIT 3
 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
• Data-centered architectures: A data store (e.g., a file or database) resides at
the center of this architecture and is accessed frequently by other components
that update, add, delete, or otherwise modify data within the store.

• 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 Architecture
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 Architecture
• Call and return architectures:
This architectural style enables you to achieve a program structure that
is relatively easy to modify and scale. A number of substyles exist within this
category:

• Main program/subprogram architectures : This classic program structure

decomposes function into a control hierarchy where a “main” program invokes a
number of program components that in turn may invoke still other components.

• Remote procedure call architectures: The components of a main

program/subprogram architecture are distributed across multiple computers on a
network.
Layered Architecture
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.
For example, a layered style (appropriate for most systems) can be
combined with a data-centered architecture in many database applications.
 Architectural Patterns
• An architectural pattern is a general, reusable solution to a commonly occurring
problem in software architecture within a given context. Architectural patterns are
similar to software design pattern but have a broader scope.

Different patterns:

•Layered pattern •Peer-to-peer pattern

•Client-server pattern •Event-bus pattern
•Master-slave pattern •Model-view-controller pattern
•Pipe-filter pattern •Blackboard pattern
•Broker pattern •Interpreter pattern
• Concurrency—applications must handle multiple tasks in a manner that simulates
parallelism .
– operating system process management pattern
– task scheduler pattern
• Persistence—Data persists if it survives past the execution of the process that created it. Two
patterns are common:
– a database management system pattern that applies the storage and retrieval capability of
a DBMS to the application architecture
– an application level persistence pattern that builds persistence features into the
application architecture
• Distribution— the manner in which systems or components within systems communicate
with one another in a distributed environment
– A broker acts as a ‘middle-man’ between the client component and a server component.
 Mapping Data Flow to Architecture
• Transform Mapping
1. Review the fundamental system model.
2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or transaction flow characteristics.
4. Isolate the transform center by specifying incoming and outgoing flow boundaries.
5. Perform “first-level factoring”
6. Perform “second-level factoring”
7. Refine the first-iteration architecture using design heuristics for improved software quality.
 Organization and Refinement
• Because 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
access an architectural design that is derived.
• The following questions provide insight into an architectural style :
• Control :
How is control managed within the architecture?
Does a distinct control hierarchy exist, and if so, what is a role of components within
the system?
• Data : How are data communicated between components? What is a mode of transfer?
 Architectural Design
1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system
 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
 Architectural Context Diagram
• Model how software (target system) interacts with entities external to its boundaries in terms of
superordianate, subordinate, and peer-level systems and actors.

75
• Use an architectural context diagram (ACD) that shows
– The identification and flow of all information into and out of a system
– The specification of all interfaces
– Any relevant support processing from/by other systems

• An ACD models the manner in which software interacts with entities external to its boundaries

• An ACD identifies systems that interoperate with the target system

– Super-ordinate systems
• Use target system as part of some higher level processing scheme
– Sub-ordinate systems
• Used by target system and provide necessary data or processing
– Peer-level systems
• Interact on a peer-to-peer basis with target system to produce or consume data
– Actors
• People or devices that interact with target system to produce or consume data
 2. Define Archetypes

• Archetypes indicate the important abstractions within the problem

domain (i.e., they model information)
• 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
• Only a relatively small set of archetypes is required in order to design even relatively
complex systems
• The target system architecture is composed of these archetypes
– They represent stable elements of the architecture
– They may be instantiated in different ways based on the behavior of the system

– They can be derived from the analysis class model

• The archetypes and their relationships can be illustrated in a UML class diagram
 Archetype
Co n t r o lle r

c o m m u n ic a t e s wit h

No d e

De t e c t o r In d ic a t o r

Fig u r e 1 0 . 7 UML r e la t io n s h ip s f o r S a f e Ho m e s e c u r it y f u n c t io n a r c h e t yp e s
( a d a p t e d f r o m [ BOS 0 0 ] )
• Node : Represents a cohesive collection of input and output elements of the home
security function ex: 1. various sensors 2. variety of alarm indicators
• Detector: An abstraction that encompasses all sensing equipment that feeds
information into the target system.
• Indicator: An abstraction that represents all mechanisms 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 controller resides on network, they have the ability to
communicate with one another
 3. Refine 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

– The application domain provides application components, which are the domain classes in
the analysis model that represent entities in the real world
– The infrastructure domain provides design components (i.e., design classes) that enable
application components but have no business connection
• Examples: memory management, communication, database, and task management
 – 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
 Component Architecture

Sa fe Hom e
Exe c ut ive

Func t ion
se le c t ion

Ext e rn al
Co m m u n icat io n
Man ag e m e n t

Se c urit y Surve illa nc e Hom e

m a na ge m e nt

GUI Int e rne t

Int e rfa c e

Cont r o l de t e c t o r a la r m
pa ne l ma na ge m e nt pr oc e s s ing
pr oc e s s ing
 S a fe Ho m e
Exe c ut ive

Ex t e r n a l
C o m m u n ic a t io n
Ma n a g e m e n t

S e c urit y

GUI Int e rne t

Int e rfa c e

Co n t ro l d e t e ct o r a la rm
p an e l m an ag e m e n t p ro c e s s in g
p ro c e s s in g

Ke y p a d
p ro c e s s in g s c h e d u le r phone
c o m m u n ic a t io n

CP d is p la y
fu n c t io n s
a la rm

ssss
eee
en
nn
nsso
ssoo
or
rrr
ss
s ee
e nn
n sss
oo
o rrr
ss
eenn ss
oo rr
 4. Describe Instantiations of the System
• An actual instantiation of the architecture is developed by applying it to a
specific problem
• This demonstrates that the architectural structure, style and components are
appropriate
• A UML component diagram can be used to represent this instantiation
Component level design
 What is Component?

• 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.
• According to OMG 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

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
a n a ly s is c la s s

P ri n t J o b

n u m b e rO f P a g e s
n u m b e rO f S i d e s
p a p e rT y p e
m a g n if ic a t io n
p ro d u c t i o n F e a t u re s
d e s ig n c o m p o n e n t
c o m p u t e J o b Co s t ( ) c o m p u t e Jo b
p a s s J o b t o P ri n t e r( )

P ri n t J o b

in it ia t e J o b

< < in t e r f a c e > > e la b o ra t e d d e s ig n c la s s

co m p u t eJ o b
P r in t J o b
c omput e Pa ge C os t ( ) numbe r Of Pa ge s
c omput e Pa pe r C os t ( ) numbe r Of Side s
c omput e Pr odC os t ( ) pa pe r Type
c omput e Tot a lJ obC os t ( ) pa pe r W e ight
pa pe r Siz e
pa pe r C olor
ma gnif ic a t ion
c olor Re quir e me nt s
pr oduc t ionFe a t ur e s
c olla t ionOpt ions
bindingOpt ions
c ove r St oc k
< < in t e r f a c e > > ble e d
in it ia t e J o b pr ior it y
t ot a lJ obC os t
buildW or kOr de r ( ) W Onumbe r
c he c kPr ior it y ( )
pa s s J obt o Pr oduc t ion( ) c omput e Pa ge C os t ( )
c omput e Pa pe r C os t ( )
c omput e Pr odC os t ( )
c omput e Tot a lJ obC os t ( )
buildW or kOr de r ( )
c he c kPr ior it y ( )
pa s s J obt o Pr oduc t ion( )
 The Traditional View
• In the context of traditional software engineering, a component is a
functional element of a program that incorporates processing logic, the
internal data structure required to implement processing logic, and
interface that enables the component to be invoked and data to be passed
to it
• It is also called module resides within the s.w 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
 The Process Related View
• Build systems that make use of existing software components or design patterns
• A catalog of proven design or code-level component is made available as design work
proceeds
• As the software architecture is developed, choose a component design or code level
components or design patterns from the catalog and use them to populate the
architecture.
• A complete description of interface, the function the component perform, and required
communication and collaboration are all available
 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
• 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 operations that access the same data are defined within one
class
– Common coupling : Occurs when a number of components all make use of a global
variable
 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
– 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)
 Steps for Conducting Component Level Design

• Identify all design classes that correspond to the problem domain

• Identify all design classes that correspond to the infrastructure domain: GUI
components, OS components, and data management components
• Elaborate all design classes that are not obtain as reusable components
– Specify message details when classes or components collaborate (messages passed
between objects)
– Identify appropriate interfaces for each component
 – Elaborate attributes and define data types and data structures required to implement
them.
• Describe processing flow within each operation in detail (pseudocode / activity diagram)
• Describe persistent data stores and identify the classes required to manage them
• Develop and elaborate behavioral representation for a class or a component: statechart is
used. Example (how states are changed from one to another)
• Elaborate deployment diagrams to provide additional implementation detail
• Refactor every component-level design representation and always considers alternatives