A.3 Architectural representations

1. Simple, informal block diagrams showing entities and relationships are the most frequently

used method for documenting software architectures.

2. But these have been criticised because they lack semantics, do not show the types of

relationships between entities nor the visible properties of entities in the architecture.

3. Depends on the use of architectural models.The requirements for model semantics depends

on how the models are used.

5.2.2 Architectural design decisions A.1 Architectural design decisions

1. 2. 3. 4. 5. 6. 7. 8.

Is there a generic application architecture that can be used? How will the system be distributed?

What architectural styles are appropriate?

What approach will be used to structure the system? How will the system be decomposed into modules? What control strategy should be used?

How will the architectural design be evaluated? How should the architecture be documented?

A.2 Architecture and system characteristics

B.1

Performance

Localise critical operations and minimise communications. Use large rather than fine-grain components.

B.2 B.3 B.4 B.5

Security Safety Availability Maintainability

Use a layered architecture with critical assets in the inner layers. Localise safety-critical features in a small number of sub-systems. Include redundant components and mechanisms for fault tolerance. Use fine-grain, replaceable components.

5.2.3 Architectural views A.1 Architectural views

1. What views or perspectives are useful when designing and documenting a system’s

architecture?

2. What notations should be used for describing architectural models?

3. Each architectural model only shows one view or perspective of the system.

A.2 4 + 1 view model of software architecture

1. A logical view, which shows the key abstractions in the system as objects or object classes.

Page 45 of 91

2. A process view, which shows how, at run-time, the system is composed of interacting

processes.

3. A development view, which shows how the software is decomposed for development.

4. A physical view, which shows the system hardware and how software components are

distributed across the processors in the system. 5. Related using use cases or scenarios (+1)

5.3 Architectural patterns

5.3.1 Architectural patterns

1. Patterns are a means of representing, sharing and reusing knowledge.

2. An architectural pattern is a stylized description of good design practice, which has been tried

and tested in different environments.

3. Patterns should include information about when they are and when the are not useful. 4. Patterns may be represented using tabular and graphical descriptions.

5.3.2 The Model-View-Controller (MVC) pattern A.1 The Model-View-Controller (MVC) pattern

Name Description MVC (Model-View-Controller) Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. See Figure 6.3. Figure 6.4 shows the architecture of a web-based application system organized using the MVC pattern. Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown. Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes made in one representation shown in all of them. Can involve additional code and code complexity when the data model and interactions are simple. Example When used Advantages Disadvantages

A.2 The organization of the Model-View-Controller

Page 46 of 91

A.3 Web application architecture using the MVC pattern

5.3.3 Layered architecture A.1 Layered architecture

1. Used to model the interfacing of sub-systems.

2. Organises the system into a set of layers (or abstract machines) each of which provide a set of

services.

3. Supports the incremental development of sub-systems in different layers. When a layer

interface changes, only the adjacent layer is affected.

A.2 The Layered architecture pattern

Page 47 of 91

Name Description Layered architecture Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. See Figure 6.6. A layered model of a system for sharing copyright documents held in different libraries, as shown in Figure 6.7. Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security. Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system. In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer. Example When used Advantages Disadvantages A.3 A generic layered architecture

A.4 The architecture of the LIBSYS system

Page 48 of 91