Chapter 10

 Component-Level Design
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
 What is a Component?
 OMG Unified Modeling Language Specification [OMG01]
defines a component as
 “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a
set of interfaces.””
 OO view: a component contains a set of collaborating
classes
 Conventional view: a component contains processing
logic, the 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2
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
 Interfaces
 Interfaces provide important information about
communication and collaboration (as well as helping
us to achieve the OPC)
 Dependencies and Inheritance
 it is a good idea to model dependencies from left to
right and inheritance from bottom (derived classes)
to top (base classes).

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 3
 Cohesion
 Conventional view:
 the “single-mindedness” of a module
 OO view:
 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
 Levels of cohesion
 Functional
 Layer
 Communicational
 Sequential
 Procedural
 Temporal
 utility

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
 Coupling
 Conventional view:
 The degree to which a component is connected to other
components and to the external world
 OO view:
 a qualitative measure of the degree to which classes are
connected to one another
 Level of coupling
 Content
 Common
 Control
 Stamp
 Data
 Routine call
 Type use
 Inclusion or import
 External

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
Component-Based Development
 When faced with the possibility of reuse, 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?
 At the same time, they are faced with the
following impediments to reuse ...

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Impediments to Reuse
 Few companies and organizations have anything that even slightly
resembles a comprehensive software reusability plan.
 Although an increasing number of software vendors currently sell
tools or components that provide direct assistance for software
reuse, the majority of software developers do not use them.
 Relatively little training is available to help software engineers and
managers understand and apply reuse.
 Many software practitioners continue to believe that reuse is “more
trouble than it’s worth.”
 Many companies continue to encourage of software development
methodologies which do not facilitate reuse
 Few companies provide an incentives to produce reusable program
components.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
The CBSE Process
Domain Engineering

Software Reusable
Domain
Analysis Architecture Artifact
Development Development

Repository
Domain Structural Reusable
model Model Artifacts/
Components

Software Engineering

System Specification
Analysis & Construction
User Design
Requirements

Analysis
System Application
& Design
Spec Models Software

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
 Domain Engineering
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 the sample.
5. Develop an analysis model for the objects.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9
Identifying Reusable Components
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the
domain?
• Is the component hardware-dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a non-reusable component so that it becomes
reusable?
• Is the component reusable in many implementations with only
minor changes?
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield reusable
components?
• How valid is component decomposition for reuse?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Component-Based SE
 a library of components must be available
 components should have a consistent
structure
 a standard should exist, e.g.,
 OMG/CORBA
 Microsoft COM
 Sun JavaBeans

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11
CBSE Activities
 Component qualification
 Component adaptation
 Component composition
 Component update

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
 Qualification
Before a component can be used, you must consider:

• application programming interface (API)

• development and integration tools required by the
component
• run-time requirements including resource usage (e.g.,
memory or storage), timing or speed, and network protocol
• service requirements including operating system interfaces
and support from other components
• security features including access controls and authentication
protocol
• embedded design assumptions including the use of specific
numerical or non-numerical algorithms
• exception handling

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
 Adaptation
The implication of “easy integration” is:
(1) that consistent methods of resource
management have been implemented for all
components in the library;
(2) that common activities such as data
management exist for all components, and
(3) that interfaces within the architecture and
with the external environment have been
implemented in a consistent manner.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
 Composition
 An infrastructure must be established to bind
components together
 Architectural ingredients for composition include:
 Data exchange model
 Automation
 Structured storage
 Underlying object model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
OMG/ CORBA
 The Object Management Group has published a common
object request broker architecture (OMG/CORBA).
 An object request broker (ORB) provides services that
enable reusable components (objects) to communicate with
other components, regardless of their location within a
system.
 Integration of CORBA components (without modification)
within a system is assured if an interface definition language
(IDL) interface is created for every component.
 Objects within the client application request one or more
services from the ORB server. Requests are made via an
IDL or dynamically at run time.
 An interface repository contains all necessary information
about the service’s request and response formats.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
ORB Architecture
Interface Client
Repository

Client
Dynamic ORB
IDL
Invocation interface
Stubs

Server
LAN
Objects
ORB Core

ORB Server Object

interface IDL Adapter
Stubs Interface
Repository

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Microsoft COM
 The component object model (COM) provides a
specification for using components produced by
various vendors within a single application running
under the Windows operating system.
 COM encompasses two elements:
 COM interfaces (implemented as COM objects)
 a set of mechanisms for registering and passing messages
between COM interfaces.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Sun JavaBeans
 The JavaBeans component system is a portable,
platform independent CBSE infrastructure
developed using the Java programming language.
 The JavaBeans component system encompasses a
set of tools, called the Bean Development Kit
(BDK), that allows developers to
 analyze how existing Beans (components) work
 customize their behavior and appearance
 establish mechanisms for coordination and
communication
 develop custom Beans for use in a specific application
 test and evaluate Bean behavior.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
Classification
 Enumerated classification—components are
described by defining a hierarchical structure
in which classes and varying levels of
subclasses of software components are
defined
 Faceted classification—a domain area is
analyzed and a set of basic descriptive
features are identified
 Attribute-value classification—a set of
attributes are defined for all components in a
domain area

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20
Indexing

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 21
The Reuse Environment
 A component database capable of storing software
components and the classification information
necessary to retrieve them.
 A library management system that provides access
to the database.
 A software component retrieval system (e.g., an
object request broker) that enables a client
application to retrieve components and services
from the library server.
 CBSE tools that support the integration of reused
components into a new design or implementation.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 22