Component-level design occurs after the first iteration of architectural design has been completed. At this stage, the overall data and program structure of the software has been established.
A component is defined in UML as: “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” However, different developers/engineers will have their own minor changes to the definition.
In an object oriented view, each component can be considered a class.
In the context of traditional software engineering, a component is a functional element of a program that incorporates 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.
The Liskov Substitution Principle (LSP).
“Subclasses should be substitutable for their base classes” [Mar00]. This design principle, originally proposed by Barbara Liskov [Lis88], suggests that a component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead.
The Interface Segregation Principle (ISP).
“Many client-specific interfaces are better than one general purpose interface” [Mar00]. There are many instances in which multiple client components use the operations provided by a server class. ISP suggests that you should create a specialized interface to serve each major category of clients.
Component Level Design was originally found on Access 2 Learn
