Component-Lavel Design for Traditional Software Component
A component is a modular building block for computer software. More formally, the OMG Unified Modeling Language Specification [OMG03a] defines a component as “. . . a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”
A traditional component, also called a module, resides within the software architecture.
(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 functions that support the processing required in the problem domain.
traditional software components are derived from the analysis model.
Control components (modules) reside near the top of the hierarchy, and problem domain components tend to reside toward the bottom of the hierarchy.
A set of data flow diagrams would be derived during requirements modeling. Assume that these are mapped into architecture.
Each box represents a software component.
Structure chart for a traditional system
The module interface is defined explicitly. That is, each data or control object that flows across the interface is represented.
The data structures that are used internal to the module are defined. The algorithm that allows the module to accomplish its intended function is designed using the stepwise refinement approach.
The behavior of the module is sometimes represented using a state diagram.
consider the module ComputePageCost. The intent of this module is to compute the printing cost per page based on specifications provided by the customer. Data required to perform this function are: number of pages in the document, total number of documents to be produced, one- or two-side printing, color requirements, and size requirements.
These data are passed to ComputePageCost via the module’s interface.