Question

1.      List and briefly explain the Software Architecture Design Guidelines.

2.      What are the software architect’s tasks? Briefly explain them.

3.   Name and explain four requirements elicitation techniques.

4.      What information should be included in a software architecture document (SAD) for small to medium-sized systems? Carefully explain it.

Answer 1

Q1) List and briefly explain the Software Architecture Design Guidelines

Software architecture is described as the organization of a system, where the system represents a set of components that accomplish the defined functions.

Key Design Guidelines are mentioned below:-

• Separation of Concerns - Divide the components of system into specific features so that there is no overlapping among the components functionality. This will provide high cohesion and low coupling. This approach avoids the interdependency among components of system which helps in maintaining the system easy.
• Single Responsibility Principle - Each and every module of a system should have one specific responsibility, which helps the user to clearly understand the system. It should also help with integration of the component with other components.
• Principle of Least Knowledge - Any component or object should not have the knowledge about internal details of other components. This approach avoids interdependency and helps maintainability.
• Minimize Large Design Upfront - Minimize large design upfront if the requirements of an application are unclear. If there is a possibility of modifying requirements, then avoid making a large design for whole system.
• Do not Repeat the Functionality - It specifies that functionality of the components should not to be repeated and hence a piece of code should be implemented in one component only. Duplication of functionality within a single application can make it difficult to implement changes, decrease clarity, and introduce potential inconsistencies.
• Prefer Composition over Inheritance while Reusing the Functionality - Inheritance creates dependency between children and parent classes and hence it blocks the free use of the child classes. In contrast, the composition provides a great level of freedom and reduces the inheritance hierarchies.

• Design Exceptions and Exception Handling Mechanism - Defining exceptions in advance, helps the components to manage errors or unwanted situation in an elegant manner. The exception management will be same throughout the system.

• Naming Conventions - Naming conventions should be defined in advance. They provide a consistent model that helps the users to understand the system easily. It is easier for team members to validate code written by others, and hence will increase the maintainability.

Q2) What are the software architect’s tasks? Briefly explain them?

The Role of a software architect

1. A software architect needs to interact with clients, product managers, and developers in order to envision, model and provide initial models and designs that can be built. This role also may cover the meeting potential or current customers.
2. A software architect has to constantly review the code to ensure the quality of the design by avoiding complexity, advocating clarity and to do this with the team. This usually requires hands-on work in terms of developing prototypes, contributing code or evaluating technologies.
3. The role of a software architect includes collaborative working with a degree of humility and providing mentoring as required. Such collaboration also allows the architect to become familiar with the skills and interests in the team and to share their knowledge with the rest of the team. Humility is required to ensure that all the team is listened to, as they may have more specific experience or knowledge for the problem at hand.

The most important responsibility/Task is complete technical support of the project from the moment of inception, through product release, to development of enhancements. The other tasks considered among the main ones are: -

• Identifying business requirements and requirements of the stakeholders on the project
• Designing the entire system based on the received requirements
• Choosing the system architecture and each individual component of this system at a high level
• Choosing the technologies for the implementation of each component and connections between the components
• Architectural review
• Code-review
• Writing project documentation and its support
• Creating unified development standards in the company
• Controlling the architecture during the next iteration of the system release

Q3) Name and explain four requirements elicitation techniques.

Requirements elicitation - In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering".

1. Questionnaires - Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those who will have only minor input into the overall requirements. Questionnaires can also be used when you have to gather input from dozens, hundreds, or thousands of people.

2. Prototyping - Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution — a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations.

3. Use cases - Use cases are basically stories that describe how discrete processes work. The stories include people (actors) and describe how the solution works from a user perspective. Use cases may be easier for the users to articulate, although the use cases may need to be distilled later into the more specific detailed requirements.

4. Brainstorming - On some projects, the requirements are not "uncovered" as much as they are "discovered." In other words, the solution is brand new and needs to be created as a set of ideas that people can agree to. In this type of project, simple brainstorming may be the starting point. The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like. After all the ideas are generated, the participants prioritize the ones they think are the best for this solution. The resulting consensus of best ideas is used for the initial requirements.

Q4) What information should be included in a software architecture document (SAD) for small to medium-sized systems? Carefully explain it.

SAD - The software architecture document provides a comprehensive overview of thearchitecture of the software system. It serves as a communication medium between the software architect and other project team members regarding architecturally significant decisions which have been made on the project.

It contains the mentioned below things:-

• Introduction. This can include Purpose, Glossary, Background of the project, Assumptions, References etc. I personally suggest that you explain that what kind of methodology you are following? This will avoid lots of debates, I promise!

It is very important to clear the scope of the document. Without a clear scope not only you will never know that when you are finished, you won’t be able to convince the stakeholder that the architecture is comprehensive enough and addresses all their needs.

• Architectural goals and constraints: This can include the goals, as well as your business and architectural visions. Also explain the constraints (e.g. if the business has decided to develop the software system with Microsoft .NET, it is a constraint). I would suggest that you mention the components (or modules) of the system when you mention your architectural vision. For example say that it will include Identity Management, Reporting etc. And explain what your strategy to address them is. As this section is intended to help the business people to understand your architecture, try to include clear and well-organised diagrams.

A very important item that you want to mention is the architectural principles that you are following. This is even more important when the client organization maintains a set of architectural principles.

• Quality of service requirements: Quality of service requirements address the quality attributes of the system, such as performance, scalability, security etc. These items must not be mentioned in a technical language and must not contain any details (e.g. the use of Microsoft Enterprise Library 5).
• Use Case View: Views basically come from 4+1 model so if you follow a different model you might not have it. However, it is very important that you detect key scenarios (or Use Cases) and mention them in a high-level. Again, diagrams, such as Use Case Diagram, help.
• Logical View: Logical view demonstrates the logical decomposition of the system, such as packages the build it. It will help the business people and the designers to understand the system better.
• Process View: Use activity diagrams as well as state diagrams (if necessary) to explain the key processes of the system (e.g. the process of approving a leave request).
• Deployment View: Deployment view demonstrates that how the system will work in a real production environment. I suggest that you put 2 types of diagrams: one (normal) human understandable diagram, such a Visio Diagram that shows the network, firewall, application server, database, etc. Also a UML deployment diagram that demonstrates the nodes and dependencies. This will again helps the business and technical people have same understanding of the physical structure of the system.
• Implementation View: This part is the most interesting section of the techies. I like to include the implementation options (e.g. Java and .NET) and provide a list of pros and cons for each of them. Again, technical pros and cons don’t make much sense to business people. They are mostly interested in Cost of Ownership and availability of the resources and so on. If you suggest a technology or if it has already been selected, list the products and services that are needed on a production environment (e.g. IIS 7, SQL Server 2008). Also it’ll be good to include a very high-level diagram of the system.

Desitop uss Frewa ASP NET Web 5

Also I like to explain the architectural patterns that I’m going to use. If you are including this section in the Implementation View, explain them enough so that a business person can quite understand what that pattern is for. For instance if you are using Lazy Loading patter, explain that what problem does it solve and why you are using it.

Needless to say that you have to also decide which kind of Architecture style you are suggesting, such as 3-Tier and N-Tier, Client-Server etc. Once you have declared that, explain the components of the system (Layers, Tiers and their relationships) by diagrams.

This part also must include your implementation strategy for addressing the Quality of Service Requirements, such as how will you address scaling out.

• Data View: If the application is data centric, explain the overall solution of data management (never put a database design in this part), your backup and restore strategy as well as disaster recovery strategy.

Be iterative - It is suggested that the architecture (and in result the Software Architecture Document) be developed through two or more iterations. It’s impossible to build a comprehensive architecture document in one iteration as not only Architecture has an impact on the requirements, but also architecture begins in an early stage and many of the scenarios are likely to change.

Please let me know in case of any clarifications required. Thanks!