The primary objective of this document is to provide a standard format for the designing of an 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 a software. Requirement analysis will give an idea about the various aspects that is to be built into the system and these aspects are the building steps to the architecture of the system.

2 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 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 their 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 resources.

3 REQUIREMENTS

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

FUNCTIONAL REQUIREMENTS

NON-FUNCTIONAL REQUIREMENTS

PRIORITY REQUIREMENTS

It is good practice to prioritise 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 which discusses the major requirements of the system or in other words the requirements which has 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 analysed 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 adoption of a new pattern or convenient combining of multiple patterns if required, without too much hassle.

4 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.

5 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 visualising 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.

5.1 LOGICAL VIEW

The logical view is to support the functional requirements of the system. It is also known as the design view and is closer to the implementation of the software. Thus, this view is mainly for the understanding of the developers. UML class diagram can be used to represent this view. Following is an example of a logical view and it shows a part of a certain system which handles student admissions and other such student and university administration interactions.

5.2 DEVELOPMENT VIEW

In this view we take into consideration the various modules and subsystems present in the system to be designed. A basic UML package diagram of the system can represent this view. Following is an example of the development view of the system mentioned in the logical view section.

5.3 PROCESS VIEW

The process view is to support the non-functional requirements like availability and performance. This view takes into consideration various interactions between the processes and the program flow. Activity diagrams can be constructed to represent this view. Following is such an example.

5.4 PHYSICAL VIEW

Physical view is to provide a view of the integration of the software along with the hardware. This mapping can be represented using UML deployment diagram.

5.5 SCENARIOS

The numerous use cases that a system will have is represented in this view. The UML use case diagram can represent this view. Following is one such example and it is a view of the system from the earlier examples.

6 EVALUATION

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 architecture “Architecture 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 chances of detecting any defects in an organised manner. The method demands evaluation of the architecture from the point of views of an entire team involved with the construction of the system.

Most of the APIs now-a-days incorporate oauth 2.0 authentication. It is not as complicated as it may seem at times, provided the right links and documentation are found. Microsoft APIs are extremely helpful and useful, but to access them from a third party application is when its needed, for the entire process of registration and access token retrieval, to be followed; to comply with the oauth authentication in place.

The first step, as hundreds of websites mentions, is to register the application. To be a little more comprehensive on this point, I would like to mention that it is not required to deploy any kind of code or application into the registration portal.

The registration process is a way of letting Microsoft know that a particular app is going to access its APIs. It is a good practice to name the app appropriately as it will appear on the screen when the application, that is being developed, navigates to the login page.

Application id is the client id which is needed to be provided in the headers when requests are made for authorisation code and access token.Continue reading →

No matter how terrifying a monster is, humans always try to find the silver bullet, to bring the inexplicabilities of the monster to a level of comprehension. Software is referred to as such a monster because its ever expanding level of complexity brings with it, multifarious issues which themselves are monstrous in their own accord.

The inherent properties of a modern software system are conformity, changeability, complexity and invisibility. Conformity is a necessary evil and normally has no logic to it but, for organisational restrictions. Changeability again is a constant sword hanging over software systems. Complexity of software systems is rather interesting as it is desired and not accidental and yet constitutes most of the monstrosity of software systems. By invisibility I refer to the fact that that there isnt any tool that can physically and convincingly represent a software system and this limits us in ways nothing else does.

Lets backtrack to when abacus had just been invented, we thought this was definitely an answer to the egregious calculations. As calculations became more and more complicated, seeking an answer led us to the beautiful concept of object oriented programming. It was a moment of celebration for developers all over the world as they thought- finally we have our solution. OOP with its modularity, reusability, reliability, maintainability etc. definitely addressed a lot of issues. However, software is abstract and a conceptual entity and hence visualisation of its impact and its challenges is indefinitely and inherently complex. We have now come a long way and invented supercomputers like IBM,�Sequoia, Cray,�Titan, NUDT,�Tianhe-2, and yet we are not close to our silver bullet. OOP, however, many would argue, is the closest thing to a silver bullet in the software world.Continue reading →