08-02-2013, 11:12 AM
Component-Level Design
1Component-Level.ppt (Size: 279.5 KB / Downloads: 18)
Background
Component-level design occurs after the first iteration of the architectural design
It strives to create a design model from the analysis and architectural models
The translation can open the door to subtle errors that are difficult to find and correct later
“Effective programmers should not waste their time debugging – they should not introduce bugs to start with.” Edsgar Dijkstra
A component-level design can be represented using some intermediate representation (e.g. graphical, tabular, or text-based) that can be translated into source code
The design of data structures, interfaces, and algorithms should conform to well-established guidelines to help us avoid the introduction of errors
Defined
A software component is a modular building block for computer software
It is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces
A component communicates and collaborates with
Other components
Entities outside the boundaries of the system
Three different views of a component
An object-oriented view
A conventional view
A process-related view
Object-oriented View
A component is viewed as a set of one or more collaborating classes
Each problem domain (i.e., analysis) class and infrastructure (i.e., design) class is elaborated to identify all attributes and operations that apply to its implementation
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 structure appropriate for each attribute
Design the algorithmic detail required to implement the processing logic associated with each operation
Design the mechanisms required to implement the interface to include the messaging that occurs between objects
Conventional View
A component is viewed as a functional element (i.e., a module) 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 component serves one of the following roles
A control component that coordinates the invocation of all other problem domain components
A problem domain component that implements a complete or partial function that is required by the customer
An infrastructure component that is responsible for functions that support the processing required in the problem domain
Component Packaging Principles
Release reuse equivalency principle
The granularity of reuse is the granularity of release
Group the reusable classes into packages that can be managed, upgraded, and controlled as newer versions are created
Common closure principle
Classes that change together belong together
Classes should be packaged cohesively; they should address the same functional or behavioral area on the assumption that if one class experiences a change then they all will experience a change
Common reuse principle
Classes that aren't reused together should not be grouped together
Classes that are grouped together may go through unnecessary integration and testing when they have experienced no changes but when other classes in the package have been upgraded
Cohesion
Cohesion is the “single-mindedness’ of a component
It 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
The objective is to keep cohesion as high as possible
The kinds of cohesion can be ranked in order from highest (best) to lowest (worst)
Functional
A module performs one and only one computation and then returns a result
Layer
A higher layer component accesses the services of a lower layer component
Communicational
All operations that access the same data are defined within one class
Coupling
As the amount of communication and collaboration increases between operations and classes, the complexity of the computer-based system also increases
As complexity rises, the difficulty of implementing, testing, and maintaining software also increases
Coupling is a qualitative measure of the degree to which operations and classes are connected to one another
The objective is to keep coupling as low as possible