Concept: Subsystem and Component View |
This architectural view identifies the large-scale pieces of the system that can be done prior to the decomposition of the system into hardware and software aspects, or may refer to the large-scale software pieces, as appropriate for the project.
Relationships
Related Elements | Views Software Analysis Discipline Software Design Discipline Optimize Subsystem and Component Architecture
Main Description
The subsystem and component view identifies the large-scale pieces of the system and how they fit together. This is usually created during the systems engineering phase. A subsystem is a really big object that provides well-defined interfaces and delegates service requests to internally hidden parts. It is common that a different team "owns" each subsystem or component and develops it more-or-less independently from the other teams. This view can be used in a couple of different ways: Subsystems and components can be used to reason about systems before they are broken down into hardware and software parts. By breaking down the system into components, you remove a layer of complexity, of the entire system by focusing on specific functionality. Subsystems and components may also be used as a software-only concept. A class, function, object, etc. can represent a system component. When designing a software system, it is much easier to talk about component functionality than actual code. A system component should represent system functionality that is closely related. For example, a display component might include screen size, screen refresh rate, communication protocol, etc. A processor component might include read/write speed, storage capacity, bus connections, etc. Designing individual components at a time is much easier than trying to design the entire system at once. The subsystems or components must have well defined encapsulation boundaries and interfaces. Elements within the subsystems or components are more tightly coupled with each other than elements across subsystem or component boundaries. Each subsystem should have a well-defined functional purpose and can be expressed as a set of use cases at the subsystem or component level. It is also common that each subsystem or component be developed in its own model. Ports are commonly used between subsystems or components, but significantly less so within a subsystem or component, since ports have memory and time overhead. The subsystems and component architecture is best shown on either a class or structure diagram, with parts of the system representing these architectural elements. A component diagram is an alternative representation.
More Information
Examples | Subsystem Model Organization
IBM® Rational® Harmony™ for Embedded RealTime Development Base Concepts Plug-in Copyright