SASSY – Analysis, Part 4

Decomposition

One tactic that is common to any large project is to divide it into more manageable pieces. Malan and Bredemeyer describe how the complexity of a large project can be addressed by the architecture:

Intellectual Intractability

The complexity is inherent in the system being built, and may arise from broad scope or sheer size, novelty, dependencies, technologies employed, etc.

Software architecture should make the system more understandable and intellectually manageable—by providing abstractions that hide unnecessary detail, providing unifying and simplifying concepts, decomposing the system, etc.

Management Intractability

The complexity lies in the organization and processes employed in building the system, and may arise from the size of the project (number of people involved in all aspects of building the system), dependencies in the project, use of outsourcing, geographically distributed teams, etc.

Software architecture should make the development of the system easier to manage—by enhancing communication, providing better work partitioning with decreased and/or more manageable dependencies, etc.

My experience with very large projects leads me to the conclusion that the first partitions should be on political lines. This has the advantage that it also divides the stakeholders which can be a significant step towards getting a solution. All that has to happen is for the interfaces to be defined and each subproject can be worked upon independently.

This should be repeated recursively until tractable projects emerge.

A variation on the political division idea is to also include a “technical” partition in addition to the functional partitions. This is made responsible for the common aspects of the system. It can be an easy sell to the stakeholders as it reduces their individual costs, being a shared component. You can then move functions in or out of the technical sub-project as best suits the design. The stakeholders will then also gain an appreciation of the cost of having a special component, and may decide that the cheaper alternative is to modify the business process instead.

In their Attribute Driven Design technique Bass, Clements and Kazman describe the following steps for designing the architecture:

1. Choose the module to decompose. The module to start with is usually the whole system. All required inputs for this module should be available (constraints, functional requirements, quality requirements).
2. Refine the module according to these steps:
   
   1. Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this decomposition.
   2. Choose an architectural pattern that satisfies the architectural drivers. Create (or select) the patterns based on the tactics that can be used to achieve the drivers. Identify child modules required to implement the tactics.
   3. Instantiate modules and allocate functionality from the use cases and represent using multiple views.
   4. Define interfaces to the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in the interface document for each module.
   5. Verify and refine use cases and quality scenarios and make them constraints for the child modules. This step verifies that nothing important was forgotten and prepares the child modules for further decomposition or implementation.
3. Repeat the steps above for every module that needs further decomposition.
   

An ontology with its subclassing capability seems like a good fit for decomposing a system into its component modules. If SASSY fulfils its requirements the step 2c above will be significantly automated since the point of the project is to generate the various views of the system.


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.