for each software component identified in the architectural design define
data structures
algorithms
interface characteristics
communication mechanisms
occurs after the data, architectural, and interface designs are established
represents the software in a way that allows the designer to review it for
correctness and consistency, before it is built
work product is a design for each software component, represented using
graphical, tabular, or text-based notation.
design walkthroughs are conducted to determine correctness
object-oriented view
a component contains a set of collaborating classes
traditional view
a component (or module) serves one of three roles
problem domain components implement a function required by the customer
control components coordinate invocation of all other problem domain
components
infrastructure components are responsible for functions needed to
support the problem domain components
a component consists of
logic
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
process-related view
emphasizes building systems out of existing components chosen from a
catalog of reusable components as a means of populating the architecture
Object-Oriented Component Design
focuses on
the elaboration of domain specific analysis classes
the definition of infrastructure classes
prior to beginning construction activities we need detailed descriptions
of
class attributes
operations
interfaces
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
Dependency Inversion Principle (DIP) - depend on abstractions, do
not depend on concretions
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
for improved readability model
dependencies from left to right
inheritance from bottom (derived classes) to top (base classes)
component interdependencies should be represented by interfaces
rather that component to component dependencies
cohesion
a component or class encapsulates only attributes and operations
that are closely related to one another and to the class or component
itself
utility cohesion - components grouped within the same category but
are otherwise unrelated
temporal cohesion - operations are performed to reflect a specific
behavior or state
procedural cohesion - components grouped to allow one be invoked
immediately after the preceding one was invoked with or without passing
data
communicational cohesion - operations that require the same data
are grouped in the same class
sequential cohesion - components grouped to allow input to be passed
from first to second and so on
layer cohesion - exhibited by package components 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 - module performs one and only one function
coupling
a qualitative measure of the degree to which classes are connected
to one another
data coupling - occurs when long strings of arguments are passed
between components
stamp coupling - occurs when parts of larger data structures are
passed between components
control coupling - occurs when one component passes control flags
as arguments to another
external coupling - occurs when a component communicates or collaborates
with in infrastructure component (e.g., database)
common coupling - occurs when several components make use of a global
variable
content coupling - occurs when one component surreptitiously modifies
internal data in another component
routine call coupling - occurs when one operator invokes another
type use coupling - occurs when one component uses a data type defined
in another
inclusion or import coupling - occurs when one component imports
a package or uses the content of another
conducting object-oriented component level design
collaboration diagram with messaging
refactoring
activity diagram
state diagram
Object Constraint Language (OCL)
complements UML by allowing a software engineer to use formal grammar
and syntax to construct unambiguous statements about design model
elements
parts of OCL language statements
a context that denotes the limited situation in which the statement
is valid
a property representing some characteristics of the context
an operation that manipulates or qualifies a property
keywords used to specify conditional expressions
Structured Component Design
each block of code has a single entry at the top
each block of code has a single exit at the bottom
oly three control structures are required:
sequence
condition (if-then-else)
repetition (looping)
reduces program complexity by enhancing readability, testability, and
maintainability
design notation
flowcharts - arrows for flow of control, diamonds for decisions,
rectangles for processes
decision table - subsets of system conditions and actions are associated
with each other to define the rules for processing inputs and events
Program Design Language (PDL) - structured English or pseudocode
used to describe processing details
PDL characteristics
fixed syntax with keywords providing for representation
of all structured constructs, data declarations, and module
definitions
free syntax of natural language for describing processing
features
data declaration facilities for simple and complex data
structures
subprogram definition and invocation facilities
design notation assessment criteria
modularity - notation supports development of modular software
overall simplicity - easy to learn, easy to use, easy to
write
ease of editing - easy to modify design representation when
changes are necessary
machine readability - notation can be input directly into
a computer-based development system
maintainability - maintenance of the configuration usually
involves maintenance of the procedural design representation
structure enforcement - enforces the use of structured programming
constructs
automatic processing - allows the designer to verify the
correctness and quality of the design
data representation - ability to represent local and global
data directly