The purpose of component level design is to define data structures, algorithms, interface characteristics, and communication mechanisms for each software component identified in the architectural design. Component level design occurs after the data, architectural, and interface designs are established. The component-level design represents the software in a way that allows the designer to review it for correctness and consistency, before it is built. The work product produced is a design for each software component, represented using graphical, tabular, or text-based notation. Design walkthroughs are conducted to determine correctness of the data transformation or control transformation allocated to each component during earlier design steps.
Component Definitions
A component is a modular, deployable, replaceable part of a system that encapsulates implementation and exposes a set of interfaces
Object-oriented view is that a component contains a set of collaborating classes
Traditional view is that a component (or module) resides in the software and serves one of three roles
Control components coordinate invocation of all other problem domain components
Problem domain components implement a function required by the customer
Infrastructure components are responsible for functions needed to support the processing required in a domain application
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 and the definition of infrastructure classes
Detailed description of class attributes, operations, and interfaces is required prior to beginning construction activities
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 and inheritance from bottom (derived classes) to top (base classes)
Component interdependencies should be represented by interfaces rather that component to component dependencies
Cohesion
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 required same data are grouped in 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
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 Component Level Design
Identify all design classes that correspond to the problem domain.
Identify all design classes that correspond to the infrastructure domain.
Elaborate all design classes that are not acquired as reusable components.
Specify message details when classes or components collaborate.
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.
Identify persistent data sources (databases and files) and identify the classes required to manage them.
Develop and elaborate behavioral representations for each class or component.
Elaborate deployment diagrams to provide additional implementation detail.
Factor every component-level diagram representation and consider alternatives.
Object Constraint Language (OCL)
Complements UML by allowing a software engineer to use formal grammar and syntax to construct unambiguous statements about design model element
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
Conventional or 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
Only three control structures are required: sequence, condition (if-then-else), and 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
Program Design Language 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
