MODELING COMPONENT

LEVEL DESIGN

OBJECTIVES:
WHAT IS A COMPONENT?
DESIGNING CLASS BASED COMPONNETS
CONSTRUCTING COMPONNET LEVEL DESIGN
DESIGNING CONVENTIONAL COMPONENTS
• Component level design defines the data structures, algorithms,
interface, characteristics and communication mechanisms allocated to
each and every component.
• A complete set of software components are defined during the
architectural design.
 But internal data structures and processing details of each component

are represented at component level design.

 Component level design occurs after the data, architectural and

interface designs are established.

 What is a component?

Component:
 A component is a modular, deployable and replaceable part of a
system that encapsulates implementation and exposes set of
interfaces.
A software component is a modular building block for
computer software.
The meaning of the component will differ depending
upon the point of view software engineer who use it.
Three important view are
 An object oriented view
 A process related view
 Conventional view
 An object oriented view of a component

 A component is viewed as a set of collaborating classes.

 Each class is elaborated to include attributes and operations.
 Problem domain(analysis) classes and infrastructure(design)
classes are elaborated to identify attributes and operations.
 This also involves defining the interfaces that enable classes to
communicate and collaborate.
 This elaboration activity is applied to every component defined as
part of the architectural design.
 Once this is completed the following steps are performed.
 Provide further elaboration of each attribute, operation and interface
 Specify the data structures appropriate for each attribute.
 Design algorithmic details required to implement processing logic associated
with each operation.
 Design mechanism required to implement interface to messaging that occurs
between data objects.
 Conventional view of a component

 In conventional view, a component is a functional element of a program that

incorporates
 The processing logic
 The internal data structures that are required to implement the processing logic
 An interface that enables the component to be invoked and data to be passed to it.
 A conventional component also called module serves one of the following roles
 A control component that coordinates all problem domain components

 A problem domain components that implements a complete or partial function required by

the customer.
 An infrastructure domain component that is responsible for supporting problem domain
classes
 Conventional software components are derived from the DFDs in the analysis
model.
 Each bubble represented at a lowest levels of DFD is mapped into a module.
 The following steps are performed for each bubble.
 Define interfaces
 Define data structures
 Design the algorithm.
consider the module ComputePageCost. The intent of this module is to compute the printing
cost per page based on specifications provided by the customer. Data required to perform this
function are: number of pages in the document, total number of documents to be
produced, one- or two-side printing, color requirements, and size requirements.
 Process related view of the component

In this view components are selected from the

library and used to populate architecture, after that
the software architecture is formulated.
Because the components in the library have been
created with reuse in mind and each contains the
following.
 A complete description of their interface
 The functions they perform
 The communication and collaboration they required.
 Designing class based components(object oriented design)

 When an object oriented software engineering approach is

chosen component level design focuses on the elaboration

of analysis classes (problem domain classes) and the
definition and refinement of infrastructure classes.
 The detailed description of attributes and operations and

interfaces used by these classes is the required design detail

for construction activity.
 Basic design Principles for Designing Class-based Components:
 Open-Closed Principle (OCP) - class should be open for extension but closed for
modification.
 Liskov Substitution Principle (LSP) - subclasses should be substitutable for their
base classes. Any class derived from a base class must honor any implied contract
between the base class and the components that use it.
 Dependency Inversion Principle (DIP) - depend on abstractions. Do not depend
on concretions. Don’t depend on concrete components. Depend on abstractions
such as interfaces.
 Interface Segregation Principle (ISP) - many client specific interfaces are better
than one general purpose interface
 Release Reuse Equivalency Principle (REP) - the granule of reuse is the granule of
release
 Common Closure Principle (CCP) - classes that change together belong together
 Common Reuse Principle (CRP) - classes that can't be used together should not
be grouped together
 Component-Level Design Guidelines:
 Components
 Establish naming conventions during architectural modeling.
 Architectural component names should have meaning to stakeholders.
 Infrastructure component names should reflect implementation specific
meanings.
 Use of UML stereotypes may help identify the nature of components
 Interfaces
 Use lollipop representation rather than formal UML box and arrow
notation.
 For consistency ,interfaces should flow from the left-hand side of the
component box.
 Show only the interfaces relevant to the component under construction

 Dependencies and inheritance

 For improved readability, model the dependencies from left to right and
inheritance from bottom (derived classes) to top (base classes).
 Component interdependencies should be represented by interfaces rather
that component to component dependencies
 Cohesion:

 Cohesion is described as “single mindedness” of a component. Within the context of

component level design for object oriented system cohesion implies that a

component or a class encapsulates only attributes and operations that

are closely related to one another and to class or component itself.

 There are number of different types of cohesion.

 Utility cohesion

 Components, classes, or operations that exists within the same category are grouped together.

 Temporal cohesion

 Operations that are performed to reflect a specific behavior or state are grouped together.
 Procedural cohesion
 Components are grouped to allow one can be invoked immediately after
the preceding one was invoked with or without passing data
 Communicational cohesion
 All operations that access the same data are defined within one class.
 Sequential cohesion
 Components or operations are grouped in a manner that allows the first
to provide input to the next and so on.
 Layer cohesion
 This type of cohesion occurs when a higher level layer accesses the
services of a lower layer, but lower level layers do not access higher level
layer services
 Functional cohesion
 This cohesion occurs when a module performs one and only one function.
Coupling:
 Coupling is a qualitative measure of the degree to which classes are
connected to one another.
 As classes become more interdependent coupling increases.
 An important objective in component level design is to keep
coupling as low as possible.
The following are the different types of coupling.
 Data coupling
 Occurs when long strings of arguments are passed between components
 Stamp coupling
 Occurs when Class B is declared as a type of argument of operation of a Class A
 Control coupling
 Occurs when operation A() invokes operation B() and passes control to B().
 External coupling:
 Occurs when a component communicates or collaborates with infrastructure
component (e.g., database, operating system functions)
 Common coupling :
 Occurs when several components make use of a global variable
 Content coupling
 Occurs when one component modifies the data that is internal to another
component.
 Routine call coupling:
 Occurs when one operation invokes another operations.

 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 the content of
component B.
Conducting component level design(object oriented systems)

 The designer must transform information from analysis model and

architectural model into a design representation that provides
sufficient details to guide the construction activity.
 The following steps represent a typical task set for component level
design when it is applied for object oriented systems.
 Step1: Identify all design classes that correspond to the problem
domain.
 Step2: Identify all design classes that correspond to the
infrastructure domain.
 Step3: Elaborate all design classes
 Step 3a: Specify message details when classes or components
collaborate.
 Step 3b: Identify appropriate interfaces for each component.
 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: Identify persistent data sources (databases and files) and
identify the classes required to manage them.
 Step 5: Develop and elaborate behavioral representations for each class
or component.
 Step 6: Elaborate deployment diagrams to provide additional
implementation detail.
 Step 7: Factor every component-level diagram representation and
consider alternatives.
 Object constrained language(OCL)

 The OCL provides formal grammar and syntax to

construct unambiguous statements about various design
model elements (e.g classes, objects, events, messages,
interfaces etc..)
 The simple OCL language statements are constructed
from four parts.
 Context: defines the situation in which the statement is valid.
 A property: that represents some characteristics of the context(e.g
if context is class, a property might be a attribute)
 An operation: an arithmetic operation that manipulate a property.
 key words(e.g if, else, then, and , or , not) that are used to specify
conditional expressions.
 Designing conventional components

Conventional component design requires the

representation of data structures , interfaces and
algorithms for a module to guide in the generation of
source code.

To accomplish this the designer uses one of a

number of design notations that represent a
component in either graphical, tabular or text
based formats.
 Structured programming is an important component level
design technique.
 Structured programming contains number of logical constructs.
 Those are fundamental constructs to structured programming.
 Sequence
 Condition
 repetition
 Sequence implements processing steps in the algorithm.
 Condition provides the facility for selected processing based on
some logical occurrence.
 Repetition allows for looping.
 Graphical design notation:
 The activity diagrams allows a designer to represent sequence, condition and
repetition – all elements of structured programming.
 In this a box is used to indicate a processing step.
 A diamond represents a logical condition
 Arrow shows the flow of control.
 Sequence is represented as two processing boxes connected by a line(arrow)
of control.
 Condition, also called if-then-else is depicted as a decision diamond that it
true causes then part processing to occur, and if false invokes else part.
 Repetition is represented two different forms “ do while” and “ repeat until”.
 The selection construct is an extension of if-then -else
 The structured programming constructs should make it easier to understand
the design.
Tabular design notation:
 In many applications, a module may be required to evaluate a complex
combination of conditions and select appropriate actions based on these
conditions.
 Decision tables provide a notation that translates actions and conditions
into tabular form.
 The decision table is divided into four quadrants. The upper left quadrant
contains a list of all conditions.
 The lower left quadrant contains a list of all actions.
 The right quadrant form a matrix that indicate condition combinations and
actions.
 The following steps are applied to develop a decision table.
 List all actions
 List all conditions
 Define rules by indicating what actions occurs for set of conditions.
Tabular design notation figure
 Program design language(PDL):

 PDL also called structured English or pseudo code is “ a pidgin

language in that it uses the vocabulary of one language and overall
syntax of another (SPL).
 The difference between PDL and real programming language lies in the
use of narrative text(i.e English) embedded within PDL statements.
 Because of this, PDL cannot be compiled.
 However tools can translate PDL into programming language skeleton
and/or graphical representation of design