DESIGNING AN ARCHITECTURE FOR A SOFTWARE SYSTEM

Author

mirketa

February 2, 2018

The primary objective of this document is to provide a standard format for the designing of architecture for any software. The first step in the Software development lifecycle is always requirement gathering as without that it is not possible to start building software. Requirement analysis will give an idea about the various aspects that are to be built into the system and these aspects are the building steps to the architecture of the system.

System

The Attribute Driven Design (ADD) method is an approach to defining a software architecture by basing the design process on the quality attributes the software has to fulfill. It is a recursive decomposition process where, at each stage in the decomposition, attribute primitives are chosen to satisfy a set of quality scenarios and then functionality is allocated to instantiate the component and connector types provided by the primitives. (Wojcik, R., Bachmann, F., Bass, L., Clements, P., Merson, P., Nord, R., & Wood, B. (2006))

The ADD approach is a straightforward and efficient way of defining an architecture and it facilitates consideration of every aspect of the architecture separately while decomposition. This makes it easier for modifications to occur while the architecture is being designed, allowing the formation of a more complete design.

2.1 Assumptions

As every system has its own set of requirements, they also have their own set of assumptions which refers to the various preconditions basing on which the entire SDLC is driven forward. It is absolutely necessary that all the preconditions are validated and checked with all the stakeholders in order to avoid rework and waste of resource.

Requirements

As already mentioned, requirement gathering is the only step that can kick start the design and development of a system. Types of the requirement that are needed to be taken care of are:

1. FUNCTIONAL REQUIREMENTS
2. NON-FUNCTIONAL REQUIREMENTS
3. PRIORITY REQUIREMENTS

It is good practice to prioritize all the requirements right at the beginning.

3.2 Design Constraints

Under this section, all the possible concerns related to the system can be discussed. For eg “ security concerns, performance overheads, memory constraints, etc.

3.3 Architectural Drivers

This is the section that discusses the major requirements of the system or in other words the requirements which have the most impact on the system. These requirements are known as architectural drivers and before deciding on a particular architectural design, it is absolutely crucial that these requirements are analyzed to see if a particular design is better suited to allow convenient implementation.

The requirement section should also validate and justify the use of a particular design over others to allow flexibility of the system as this facilitates the adoption of a new pattern or convenient combining of multiple patterns if required, without too much hassle.

Patterns Styles

Patterns and Styles are architectural design decisions concerning a specific problem and a development context respectively. Most systems consist of multiple styles and patterns instead of just one as this is more advantageous. Every aspect of the system is to be considered separately as well as together to make the perfect design decision about the patterns and styles to be used.

View

Representation of the various modules, components, and other elements of the system to be designed along with their relationships is taken care of in Views. All the stakeholders, developers and everyone involved in designing and implementing the system has a different way of visualizing the system and view models are used to create relevant representations for everyone involved. The 4+1 view model is most widely used and following are its various sections.

Conclusion

Evaluation is another crucial step for architecture design as this can clarify and shortcomings a design might have and also clarifies all the requirements in relation to the design chosen. For the evaluation of the architecture, the Tradeoff Analysis Method can be used. This is a very widely used evaluation technique and it takes into consideration every step of the architecture development process, therefore, increasing the chances of detecting any defects in an organized manner. The method demands an evaluation of the architecture from the point of view of an entire team involved with the construction of the system.

Pranshu Goyal, Director of Products at Mirekta, states: “We envision DSM to be used by every small to a medium-sized organization dealing with bad data and want to get rid of duplicates easily with no cost. We have faced issues dealing with duplicates in our organization. That inspired us to make a solution that is not only simple to use but can be used widely to make the organization’s data clean to make them more efficient and productive. We want DSM to be a solution for every organization looking for duplicate management capability better than the Salesforce out-of-the-box solution with no additional cost.”