This is the 12th article on the System Design and Software Architecture series. In this article, we are discussing the Software Components.
Previous articles
- Introduction to System Design and Architecture
- Values of system software
- Programming Paradigm
- Object-Oriented Programming
- Structured programming
- Functional programming
What is a Software Component?
A component is a well-defined set of modular, portable, replaceable, and reusable functionalities.
A component is a software object that intends to interact with other components, integrating a certain function or group of functions. It has a clearly defined interface and conforms to a generally recommended behavior for all components in the architecture.
A software component can be defined as a unit of composition with a specified interface and clear context dependencies. That is a software component that can deploy independently and is subject to third-party composition.
Characteristics of components
- Reusability
Components are generally designed to use again in different applications at different times. However, some components are designed for a specific purpose.
- Replaceable
Components are can freely be replaced with other similar components.
- The context is not specific
The components have been designed to function in different environments and contexts.
- Expandable
A component can be extended from existing components to provide new behaviors.
- A closed-component
The component interface represents the interface that is allowing the caller to use its functionality without revealing information about internal processes or internal variables or status.
- Independent
The components are designed with minimal dependence on the other components.
Views of a component
A component can have three different ideas – object-oriented view, traditional view, and process-related view.
Object-oriented view
- A component considers as one or more cooperation classes. Each problem domain class and infrastructure class are explained to identify all the properties. And operations relevant to its implementation. It also includes defining interfaces where classes can communicate and collaborate.
Traditional view
- It is considered a module of a program that integrates a functional element or processing logic. Also must provide an interface and data that allows it to appeal to the internal data structures and components needed to execute the processing logic.
- According to this view, instead of creating individual components from scratch. Also, the system is built from existing components. Those are maintained in a library. As software architecture is developed, components from the library are selected and used to popularize architecture.
- The User Interface (UI) component includes buttons called Grids and Controls, while the Utility component exposes a specific set of functions used in other components.
- Other common components are resource-intensive, frequently inaccessible, and must need to activate using on-time (JIT) access.
- Many of the components are distributed in Internet web applications such as Enterprise Business Applications. And Enterprise Java Beans (EJB), .NET components, and Korba components are invisible.
Conducting Component-Level Design
- Identifies all design classes that correspond to the problem domain as defined in the analytics model and the architectural model.
- Identifies all design classes that correspond to the infrastructure domain.
- Describes all design classes that have not been acquired as reusable components and specifies message descriptions.
- Identifies the appropriate interfaces for each component also describes the data types and data structures needed to implement them.
- Duplicate codes or UML activity diagrams describe the processing flow in detail in each operation.
- Describes continuous data sources (databases and files) and identifies the classes needed to manage them.
- Develop and expand behavioral representations for a class or element. This has the ability to do by expanding the UML state diagrams designed for the analytics model. And examining all usage cases relevant to the design class.
- Expands deployment diagrams to provide additional activation details.
- Indicates the location of keystrokes or components in a system by using class opportunities. Also naming specific hardware and operating system environments.
- The final decision can make using established design principles and guidelines. Also, well-experienced designers consider all (or most) of the alternative design solutions before settling on the final design model.
Advantages
- Ease of deployment – When new compatible versions become available. Also, it is easy to replace existing versions with other components or the system as a whole without any impact.
- Reduced Cost – This allows you to expand development and maintenance costs by using third-party components.
- Ease of development – Enables component public interfaces to provide defined functionality and it is allowing development without affecting other parts of the system.
- Reusable – The use of reusable components means that they can use to extend development and maintenance costs across multiple applications or systems.
- Changing technical complexity – A component changes the complexity of using a component container and its services.
- Reliability – Reusing the reliability of each component increases the reliability of the entire system as it increases the reliability of the entire system.
- System Maintenance and Evolution – Easy to modify and update activation without affecting other parts of the system.
- Independence – Independence and flexibility of components. Independent development of components from some different groups in parallel.
Stable Dependencies
- In any software system, it is important to have a very clear distinction between the components we expect to be unstable – that is, the components we expect to change most often. And the low volatile, more essential, and stable components.
Therefore, the component dependence graph should need to design to protect stable high-value components from more volatile components. For example, we do not want to affect the high level of policy or business performance of the UI change system.
- One thing that makes it difficult to modify a software component is if there are many more components based on it. Such a component is inherently stable. Ad also if it has zero or few dependencies, it is independent and easy to isolate and it is a unit test.
- If a component is stable, it is difficult to change. If it is difficult to change, it is easy to extend. This is called the static summary principle, and this principle goes hand in hand with the open/closed principle. And which states that such components just need to open for extension but closed for modification.
- On the other hand, it is relatively easy to change a component that has many dependencies and zero or very few dependencies. Such a component is unstable. All software systems require unstable components that have the ability to easily modified or exchanged for other components.
Summary
- Almost any software system is made up of small building blocks called components. Adherence to well-known best practices and a principle in software component design is an important part of solid software design and architecture.
- It is very important to have a very clear distinction between the components we expect to be volatile – that is, the components we often expect to change. And the less volatile, essential components.
- Practicing the dependent inverse principle. Especially to fully control the connections between components. And to ensure a high degree of disconnection between the essentials. And information of the software system dramatically increases the maintenance capability of the system.
- The two main characteristics of a component are the amplitude and stability of the component. The “perfect” component is extremely flexible and stable, so it is difficult to change. But it is not easily expandable and unstable, so it is not complicated to change or even exchange other components.
- Mapping component stability-extension graphs of a software system is a useful exercise.
Conclusion
Thanks for reading the article Software Components as an essential component in System design and architecture.
My articles on medium
