madhavrao… » Software Architecture
How can components identified while designing System Architecture be connected?
It depends on whether this system/components are of the shelf (buy) or been developed by bespoke development (build).
In situation they are ready made of the shelf components, what are the integration points and mechanism available. Can each of the components integrate and work cohesively or some bespoke development is required to be done to do necessary plumbing.
If all of the components are developed from scratch, it affects overall development and testing time. In case its off the shelf component, than it might not be exactly tailored to our needs and also may not be easy to integrate in our environment.
Components should be connected as loosely as possible to each other, so that they can be replaced with new enhanced components in future if required, without breaking solution. But there are situation where this is not possible, and we end up doing trade-off analysis to identify which components do we choose for the identified functionality. It helps if we have identify multiple components for implementing particular functionality or else we end up in situation of “beggars do not have choice”.
How do we ensure completeness of the solution once designed?
In my earlier post I had explained in four lines how system can be decomposed into components, but then how exactly can we ensure our designed system matches the requirements of the client. Well for this we need to track it (requirements).
While decomposing solution into logical components we arrive at logical components by divided requirements (functional and non-functional) into logical group and further dividing them into groups. For ensuring completeness of the solution, we need a process to track down which requirement are going to be satisfied by which component.
Once we have mapping of requirements to components all we need is to check if all requirements are taken care of. If not then we need to check feasibility of adjusting missed requirements into any of the identified components or identify new component to meet the missed requirements.
While designing/defining system architecture, how do we decompose system into components/sub-systems?
- System design is driven by requirements.
- Requirements are of two types, functional and non-functional.
We got the first decomposition criteria. - Functional and Non-Functional requirements can be further divided into logical groups, which further may be divided into logical groups.
- Logical group which further cannot be or may not be considered to be further decomposed into logical group is a component.
What is Software Architecture?
There are many definitions available for this. My personal favorite is one available at http://www.bredemeyer.com/whatis.htm
Software Architecture is set of decisions made by Software Architect while designing the Software. Set of decisions which are architecturally significant, and it varies from scenario to scenario.
Software Architecture is commonly defined in terms of components and connectors. Components are identified and assigned responsibilities. Connectors are component interconnections which specify communication and control mechanism, and support all component interactions needed to accomplish system behavior.
In defining Architecture, following things are considered:
- System decomposition into components/sub-systems
- Completeness of the System by connecting decomposed components/Sub-systems
- Interconnections of decomposed components/sub-system
- Cross cutting Concerns (non-functional requirements)