J.E.D.I
4.6 Component-level Design
The Component-level Design defines the data structure, algorithms, interface characteristics, and communication mechanism allocated to each software component.
A component is the building block for developing computer software. It is a replaceable and almost independent part of a software that fulfills a clear function in the context of a
well-defined architecture.
In object-oriented software engineering, a component is a set of collaborating classes that fulfills a particular functional requirement of the software. It can be independently
developed. Each class in the component should be fully defined to include all attributes and operations related to the implementation. It is important that all interfaces and
messages that allow classes within the component to communicate and collaborate be defined.
4.6.1 Basic Component Design Principles
Four basic principles are used for designing components. They are used to guide the software engineer in developing components that are more flexible and amenable to
change and reduces the propagation of side effects when change do occur.
1. The Open-Close Principle. When defining modules or components, they should be open for extension but they should not be modifiable. The software engineer should
define a component such that it can be extended without the need to modify the internal structure and behavior of the component. Abstractions in the target
programming language supports this principles.
2. Liskov Substitution Principle. The derived class or subclass can be a substitute for the base class. If a class is dependent on a base class, that class can use any derived
class as a substitute for the base class. This principle enforces that any derived class should comply with any implied contract between the base class and any component
that uses it.
3. Dependency Principle. Classes should depend on abstraction; not on concretions. The more a component depends on other concrete components, the more difficult it can be
extended. 4. Interface Segregation Principle. Software engineers are encouraged to develop client-
specific interface rather than a single general purpose interface. Only operations specific to a particular client should be defined in the client-specific interface. This
minimizes inheriting irrelevant operations to the client.
4.6.2 Component-level Design Guidelines
This guideline is applied to the design of the component, its interface, its dependencies and inheritance.
1. Component • Architectural component names should come from the problem domain and is
easily understood by the stakeholders, particularly, the end-users. As an example, a component called Athlete is clear to any one reading the
component.
• Implementation component name should come from the implementation
Software Engineering 190
J.E.D.I
specific name. As an example, PCLAthlete is the persistent class list for the athletes.
• Use stereotypes to identity the nature of the component such as table, database or screen.
2. Interfaces • The canonical representation of the interface is recommended when the
diagram becomes complex. • They should flow from the left-hand side of the implementing component.
• Show only the interfaces that are relevant to the component under consideration.
3. Dependencies and Inheritance • Dependencies should be modeled from left to right.
• Inheritance should be modeled from bottom subclass or derived class to top superclass or base class.
• Component interdependence are modeled from interface to interface rather than component to component.
4.6.3 Component Diagram
Kategori