Software Architecture [ Wase ]

Birla Institute of Technology & Science, Pilani

Work Integrated Learning Programmes Division

First Semester 2017 – 2018

COMPRE EXAM (Regular)

 

Q1. Choose the most appropriate architectural pattern (one) for the 5 descriptions below. Motivate for your choices (give reasons for choosing the pattern): [5 Marks]

1. Wants to split a system into a number of computationally independent execution structures (groups of software and hardware) such as database, business logic, web interface and client, connected by some communication media. The structure is chosen to provide a specific server environment optimized for operational requirements and resource usage.
2. Wants to set up a set of equal distributed computational entities that are connected via a common protocol to share their services and provide high availability and scalability.
3. Wants a system that can be divided into reusable, loosely coupled components that can be flexibly combined and arranged to transform between various data formats.
4. Wants a distributed system with a structure that enables that service users do not need to know the nature or location of service providers.
5. Wants a system that quickly can analyze enormous volumes of data by sorting the data and then analyzing the grouped data.

Answer:

1 Multi-tier

2 Peer-to-peer

3 Pipe-and-filter

4 Broker

5 Map-Reduce

 

Q2. Present a general and a specific scalability requirement in the form of a Quality Attribute Scenario [2 Marks]

A concrete scalability quality attribute scenario:

Source system owner

Stimulus request to accommodate five times more concurrent users

Artifact the main server cluster

Environment normal operation

Response increase the number of servers no more than sixfold, without recompiling the software

Response measure performance as measured by average number of typical requests processed per minute may not drop more than 10%

Q3. In the Service Oriented Architecture style there is a strong decoupling between functionality and implementation, throughout the application lifecycle. Applications are built by combining or connecting services. Explain why and how this architecture facilitates [4 Marks]

1. (1) reuse of existing software components;
2. (1) independent development.

 

Answer:

In SOA, application components depend on each other only through the service interface. No details of an implementation may be used or be visible.

(a) There are two elements of reuse. Once a service (interface) is defined, the only thing that needs to be done to use an existing piece of software is to map the service interface to this software, typically by building an adapter. Secondly, services can be reused in many different applications since they do not contain knowledge about their application context. One remark on the latter is in place: a service may use other services.

(b) This relies on the same separation between service definition and implementation. By defining and using only the service interface, the implementation of the service becomes irrelevant for the service user. For example, by defining the UPnP interface, the implementation behind is it entirely invisible and can be developed by independent parties. One might also replace one implementation by the other.

 

Q4. Read the description of the Cricket-Ticket system below and do an architectural design using the attribute-driven design (ADD) method. [25 Marks]

Your answer should include: • Architectural drivers • Architectural tactics and patterns • A logical view • Interfaces • Verification of the architecture

Note that you should only describe the logical view and only do one level of decomposition!

Motivate for your choices and state your assumptions.

 The Cricket-Ticket System (CTS) is a system where the users can buy tickets using credit cards to cricket matches in India over the Internet using a Web-browser. The user can look at information about future matches from cricket teams from all over India, and see if there are any available seats. The information about the cricket matches is retrieved from various servers with different interfaces provided by the different teams. Note that the teams in India will change every year. It is critical that the TSS is available to the users all the time, and it cannot be unavailable for more than 2 minutes a week. Before important games, such as Champion League games, it is important that the system does not break down even if over 40000 users try to get tickets at the same time

Answer:

Step 1. Choose module to decompose: The CTS

Step 2a. Choose architectural drivers:

AD1: The system cannot be down more than 2 minutes a week (availability)

AD2: The system should provide secure electronic payment (security)

AD3: The system should be able to communicate with various team servers (modifiability)

AD4: The system must handle 40,000 simultaneous users (performance)

Step 2b. Choose architectural patterns:

Tactics for security: Firewall for server, autorize users, authenticate users, Payment handled by third-party and usage of secure connection (e.g. https)

Tactics for modifiability: Divide the functionality into coherent units and plan for changeable interfaces for external systems.

Tactics for performance: Use replication of the server to ensure support for many users, and cache data from team servers.

Tactics for availability: Use replication of the server to cope with downtime.

Architectural patterns: Use a kind of a model-view controller pattern where the view and the controller is represented in the user interface part and the model is the database. Replication is used on server and database for higher performance and availability. Separation of concern is used to provide modifiability (separate core functionality and external interfaces), and a separate part dealing with secure computation and interfaces.

Step 2c. Instantiate Modules and Allocate Functionality Applied architectural patterns and instantiated functionality for match browsing, seats browsing, and ticket booking. Also added a data manager that takes care of caching of data from external systems (stored in database).

Step 2d. Define Interfaces of the Child Modules Interfaces between the server and the external parts of the system:

• Between User interface and user clients: HTML over HTTP

• Between External system interface and External Team server: XML over HTTP • Between Data manager and Database server: SQL over HTTP

• Between Ticket payment and External payment service: encrypted binary over HTTPS Interfaces within the server: • The User interface class provides display methods that uses other classes:

• displayMatch()

• displaySeats()

• displayBooking()

The Ticket payment class offer the method payTicket (used by the Ticket booking class) The Data manager class offers methods that are used by three other classes:

• getMatchInformation()

• getSeatsInformation()

• getBookingInformation()

The External system interface class, offers a more general method for accessing information from external team servers:

• getInformation()

Step 2e. Verify Use Cases and Quality Scenarios Check that functional requirements are covered:

• The user can get information about future matches: Match browsing class • The user can get information about available seats: Seats browsing class

• The users can buy tickets: Ticket booking and Ticket payment classes Check architectural drivers:

• AD1: The system cannot be down more than 2 minutes a week (availability): Replication of the server and the database, and caching of external servers.

• AD2: The system should provide secure electronic payment (security): Use secure computation in Ticket payment class, use secure transfer (https) and secure external payment service.

• AD3: The system should be able to communicate with various team servers (modifiability): Supported through the External system interface class.

• AD4: The system must handle 40,000 simultaneous users (performance): Replication of the server and database, and caching of external servers.

 

Q5. Read the description below and do the following:

5.1 Identify the most important quality attribute(s) and the architectural drivers for the system described below [4 Marks]

5.2 Choose and describe suitable architectural tactics for the problem described below, and describe how the tactics affect the quality attributes [5 Marks]

5.3 Create architecture views of the system described below. The architecture must be described in two views according to the 4+1 view model: Process and Logical view [15 marks]

Motivate for your choice of quality attributes, architectural drivers and the architectural tactics used in your architecture.

Software for House Alarm System: The software described here is software for controlling an alarm system sold to households. The software should be able to run different configurations consisting of sensors from various producers, variations in types of displays and keyboard/button configurations. The different configurations also represent different price segments from the very simple and cheap alarm systems to the expensive and advanced. The software system is supports both smoke (fire) and movement sensors (theft). In normal mode, the system is running on electrical power from a standard power socket in the wall. However, in case a power outage, the system can operate on battery power. All the sensors are powered by the system. In case of a detection of fire or theft, the system will start a siren (alarm sound) and the display information about what caused the alarm, in what area of the house. How the information is shown is dependent on the capabilities of the display used in the system from only simple text to graphical description of the situation. For the more expensive configurations, the system can call the fire department or a security company through a telephone connection. The system can also be set up to call the mobile phone of the owner of the house. The system will also warn the security company if the alarm system is running on battery. The software is running on custom made computer with a CPU, memory and various input/output interfaces.

Answer:

 

5.1 Most important quality attribute(s) and architectural drivers for the system: This system is a product line system with many variations of configurations. In addition, such a system must be reliable as it concerns safety of the users. The two most important quality attributes for this system are availability and modifiability. Architectural drivers for the system:

• The architecture must provide high availability because the system can possibly save lives or keep people out of danger.
• The architecture must provide interfaces that can handle various types of sensors.
• The architecture must be able to support various types of displays and keyboard/button configurations.
• The architecture must be flexible in such way that it provides different types of functionality based on the price segment of the product.
• The architecture must be able to automatically switch to battery-operated mode in case of a power outage.

5.2 Choose and describe suitable architectural tactics and describe how the tactics affect the quality attributes: This solution will focus on the most important architectural tactics to achieve improved availability and modifiability:

• Heartbeat (availability): The system should provide a heartbeat functionality to ensure that the system is running and alive (availability). The system should consist of a separate hardware unit (monitor) that has a battery backup hardware so it will never die in case of power outage. The main system will send a heartbeat signal in fixed time intervals (e.g. every second) to the separate heartbeat listener unit. If this unit does not get any heartbeat signal within some time (e.g. 5 seconds), the main unit will be restarted. If this fails, the main system will switch to battery power and restarted.
• State resynchronization (availability): The heartbeat signal sent from main unit to the monitor unit consists of the state information of the main unit. This makes it possible for the monitor unit to reinitiate the main unit in previous state.
• Exceptions (availability): Exceptions can be used to detect faults in the main unit and should be sent to the monitor unit. The monitor unit can restart the main unit, if the main unit is in an unstable state.
• Use model-view controller (modifiability): By using the model-view controller approach, it is possible to provide support for various displays and keyboard/buttons configuration in the same architecture.
• Use an intermediary (modifiability): To support the variation in sensors, intermediaries can be used to represent the different sensors to provide the same interface for different sensors into the system. Here it is possible to use the template method design pattern, where the core functionality of the sensors are provided in a template class and where subclasses represents the different types of sensors.
• Separate core functionality and advanced functionality (modifiability): Since the functionality provided by the system can vary depending on the price segment of the system, the core functionality of all systems should be separated from the more advanced functionality provided by the more advanced systems.

5.3 Architecture