Chapter :11
Component-Level Design
What is Component?
•A component is a modular building block for
computer software.
•A component is a modular, deployable, and
replaceable part of a system that encapsulates
implementation and exposes a set of interfaces.
•Because components reside within the software
architecture, they must communicate and
collaborate with other components and with entities
that exist outside the boundaries of the software.
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.
• To accomplish this, begin with requirements model
and elaborate analysis classes and infrastructure
classes.
The Traditional View
• In the context of traditional software engineering,
a component is a functional element of a program
that incorporates 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:
(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
(3)An infrastructure component that is responsible
for the functions that support the processing
required in the problem domain.
• Traditional components are derived from the
analysis model the analysis model.
• The data flow oriented element of the analysis
model serve as a basis for the derivation.
• Each transform (bubble) represented at the
lowest level of the data flow diagram is mapped
into a module hierarchy.
• Control components reside near the top of the
hierarchy and problem domain components tend
to reside toward the bottom of the hierarchy.
• To achieve effective modularity, design concepts
like functional independence are applied as
components are elaborated.
The Process Related View
• There is a need to 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
Four basic design principles are applicable to
component level design and have been adopted
when object-oriented software engineering is
applied.
• The Open-Closed Principle : “A module should
be open for extension but closed for modification”.
The component should be extended without the
need to make internal modifications to the
component itself.
• The Liskov Substitution Principle : “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 : “Depend on
abstractions. Do not depend on constructions.”
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 : “Many
client-specific interfaces are better than one
general purpose interface.” Multiple clients
components use the operations provided by a
server class. We should create a specialized
interface to serve each major category of clients.
Packaging Principles
• The Release Reuse Equivalency Principle :
“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 : “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.
• The Common Reuse Principle : “Classes that
aren’t reused together should not be grouped
together.” If classes are not grouped cohesively, it
is possible that a class with no relationship to
other classes within a package is changed. So
only classes that are reused together should be
included within a package.
Component-Level Design Guidelines
A set of pragmatic design guidelines can be applied
as component-level design proceeds.
1) Component :
Naming conventions should be established for
components that are specified as part of the
architectural model and then refined and
elaborated as a part of the component-level
model.
Use stereotypes to help identify the nature of
components at a detailed design level.
2) Interfaces :
Interfaces should flow from the left-hand side of
component box.
Only those interfaces that are relevant to the
component under consideration should be shown.
3) Dependencies and Inheritance :
Dependencies should be modeled from left to
right and inheritance should be modeled from
bottom to top.
Cohesion
•
In a context of component-level design for OO
system, cohesion implies that a component or
class encapsulates only attributes and operations
that are closely related to one another and to the
class or component itself.
• A number of different types of cohesion
1) Functional : Exhibited by operations, this level of
cohesion occurs when a component performs a
targeted computation and then returns a result.
2) Layer : Exhibited by packages, components, and
classes, this type of cohesion occurs when higher
layer accesses
Cohesion
•
In a context of component-level design for OO
system, cohesion implies that a component or
class encapsulates only attributes and operations
that are closely related to one another and to the
class or component itself.
• A number of different types of cohesion
1) Functional : Exhibited by operations, this level of
cohesion occurs when a component performs a
targeted computation and then returns a result.
2) Layer : Exhibited by packages, components, and
classes, this type of cohesion occurs when higher
layer accesses the service of a lower layer,
but lower layer do not access higher layers .
3) Communicational : All operations that access the
same data are defined within one class.
•
Classes and components that exhibit functional,
layer and communicational cohesion are relatively
easy to implement, test and maintain.
Coupling
•
Coupling is a qualitative measure of the degree to
which classes are connected to one another.
•
Coupling categories :
1) Content coupling : Occurs when one component
modifies data that is internal to another
component.
2) Common coupling : Occurs when a number of
components all make use of a global variable.
3) Control coupling : Occurs when operation A()
invokes operation B() and passes control flag to
B.
4) Stamp coupling : Occurs when class B is declared as
a type for an argument of an operation of class A.
5) Data coupling : Occurs when operations pass long
strings of data arguments.
6) Routine call coupling : Occurs when one operation
invokes another.
7) Type use coupling : Occurs when component A uses
a data type defined in component B.
8) Inclusion or import coupling : Occurs when
component A imports or includes a package or
content of component B.
9)External coupling : Occurs when a component
communicates or collaborates with infrastructure
components.
Conducting Component Level Design
The following steps represent a typical task set for
component-level design, when it is applied for
OO system.
1) Identify all design classes that correspond to
the problem domain : Using the requirements
and architectural model, each analysis class
and architectural component is elaborated.
2) Identify all design classes that correspond to
the infrastructure domain : Classes and
components in this category include GUI
components, OS components, and object and
data management components.
3)Elaborate all design classes that are not
acquired as reusable components.
a.) Specify message details when classes or
components collaborate: It is sometimes useful
to show the details of these collaboration by
specifying the structure of the messages that
are passed between objects.
b.) Identify appropriate interfaces for each
component.
c.) Elaborate attributes and define data types and
data structures required to implement them.
d.) Describe processing flow within each operation
in detail.
4)Describe and elaborate behavioral representation
for class or component : Databases and files
normally transcend the design description of
individual components.
5) Develop and elaborate behavioral representation
for a class or a component : The transition
between states are represented using statechart.
6)Elaborate deployment diagrams to provide
additional implementation detail.
7) Refactor every component-level design
representation and always considers alternatives.
Component Level Design For WebApps
Content Design At The Component Level
•
Content design at component level focuses on
content objects and the manner in which they
may be packaged for presentation to a WebApp
end user.
•
The formality of content design at component
level should be tuned to the characteristics of
the WebApp to be built.
Functional Design At The Component Lev
•
WebApp functionality is delivered as a series of
components developed in parallel with the
information architecture to ensure that they are
consistent.
•
During architectural design, WebApp content and
functionality are combined to create a functional
architecture,
•
A functional architecture is a representation of the
functional domain of the WebApp and describes
the key functional components in WebApp and
how these components interact with each other.
Designing Traditional Component
Graphical Design Notation
• Activity diagram or the flowchart provides useful
pictorial patterns that depict procedural detail.
• The activity diagram allows to represent sequence,
condition, and repetition.
• Flow chart:
• Box: used to indicate processing step.
• Diamond: represents logical condition
• Arrow: shows flow of control.
• Flow chart constructs: (figure 10.10)
Tabular Design Notation
• In many software application, a module may be
required to evaluate a complex combination of
conditions and select appropriate actions based
on these conditions.
• Decision table provides a notation that translates
actions and conditions into tabular form.
• It is made of four sections:
(1)Condition statements
(2) Condition entries
(3) Action statements
(4) Action entries
General Form of Decision Table
Condition
Decision rules
Condition statements
Condition entries
Action statements
Action entries
• Example
Program Design Language
• PDL is also called Structured English or pseudo code.
• The difference between PDL and real programming
language lies in the use of narrative text(e.g English)
embedded directly within PDL statements.
• Basic PDL syntax should include constructs for
component definition, interface desc., data
declaration, condition and repetition constructs, I/O
constructs etc.
• Example
Component Based Development
• Component-based software engineering is a process
that emphasizes the design and construction of
computer-based systems using reusable software
components.
Domain Engineering
• The intent of domain engineering is to identify,
construct, catalog, and disseminate a set of software
components that have applicability to existing and
future software in a particular application domain.
•
The steps in the process are defined as :
1) Define the domain to be investigated.
2) Categorize the items extracted from the domain.
3) Collect a representative sample of applications in the
domain.
4) Analyze each application in sample and define
analysis classes.
5) Develop a requirements model for the classes.
Component Qualification, Adaptation, and
Composition
Component Qualification
• Component qualification ensures that a candidate
component will perform the function required, will
properly fit into architectural style, and will exhibit the
quality characteristics that are required for the
application.
• In addition to interface description, many other factors
considered during component qualification are:
API, Development and integration tools, Exception
handling etc.
Component Adaptation
• In reality, even after a component has been qualified
for use within an application architecture, conflicts may
occur in one or more of the areas.
• To avoid these conflicts, an adaptation technique
called Component Wrapping is used.
• When a software team has a full access to the internal
design and code for a component white-box wrapping
is applied.
• Gray-box wrapping is applied when component library
provides a component extension language or API that
enables conflicts to be removed or masked.
• Black-box wrapping requires the introduction of preand post processing at the component interface to
remove or mask conflicts.
Component Composition
• The component composition task assembles qualified,
adapted, and engineered components to populate the
architecture established for an application.
• To accomplish this, an infrastructure must be
established to bind the components into an
operational system.
• The infrastructure provides a model for the
coordination of components and specific services that
enable components to coordinate with one another
and perform common tasks.
• Standard for component software
1)OMG/CORBA : An object request broker (ORB)
provides a variety of services that enable reusable
components to communicate with other components.
2)Microsoft COM and .NET : Microsoft has developed a
component object model (COM) that provides a
specification for using components produced by
various vendors within a single application running
under the Windows OS. The .NET framework
encompasses COM and provides a reusable class
library that covers a wide array of application domains.
3)Sun JavaBeans Components : The JavaBeans
component system encompasses a set of tools, called
Bean Development Kit (BDK), that allows developers
to (i) analyze how existing beans work, (ii) customize
their behavior and appearance, (iii) establish
mechanism for coordination and communication, (iv)
develop custom beans for use in a specific application
and (5) test and evaluate Bean behavior.
Analysis And Design For Reuse
• Although CBSE process encourages the use of
existing components, there are times when new
components must be developed and integrated with
existing COTS and in-house components.
• New components should be engineered for reuse.
• Design concepts such as abstraction, hiding,
functional independence all contribute to the creation
of software components that are reusable.
• Key issues that form a basis for design for reuse:
1) Standard Data : The application domain should be
investigated and standard global data structures
should be identified. All design components can be
characterized to make use of these standard data
structure.
2) Standard interface protocols : Three levels of
interface protocol should be established : the nature
of intramodular interfaces, the design of external
technical interfaces, and human-computer interface.
3) Program templates : An architectural style is chosen
and can serve as a template for architectural design
of a new software.
Classifying and Retrieving Components
• Tens of thousands of reusable software components
reside in component repository. But how to find out the
one that is needed?
• A reusable component can be described using 3C
model – concept, content and context.
• The concept is a description of what the component
does.
• The content is information that is hidden from casual
users and need be known only to those who intend to
modify or test the component.
•
The context places the reusable software component
within its domain of applicability.
•
Classification enables you to find and retrieve
candidate reusable components but reusable
environment must exist.
• Characteristics of reusable environment are :
1) A component database capable of storing software
components and the classification information
necessary to retrieve them.
2) A library management system that provides access
to the database.
3) A software component retrieval system that enables a
client application to retrieve components and
services from the library server.
4) CBSE tools that support the integration of reused
components into a new design or implementation.
The reuse library is one element of a larger software
repository and provides facilities for the storage of
software components and a wide variety of reusable
work products (e.g. designs, patterns, frameworks).
The library encompasses a database and the tools that
are necessary to query the database and retrieve
components from it.