Architecture Blueprint-Software Architecture "4+1" view model

Introduction

We have seen in many articles and books that the author wants to use a single view to capture all of the system architecture essentials. By carefully observing the squares and arrows in these legends, it is not difficult to find the author's effort to express a blueprint in a single view that exceeds its expressive limit. Does the box represent a running program? Or is it a block representing the source code? Or a physical computer? Or is it just a grouping of logical functions? Does the arrow represent a compile-time dependency? Or is it a control flow? or data flow? Usually it represents a lot of things. Does the schema require only a single schema style? Sometimes the flaw in software architecture stems from the early partitioning of software or the overemphasis on individual aspects of software development: Data Engineering, operational efficiency, development strategies, and Team organization. Sometimes the architecture does not address the concerns of all "customers" (or "stakeholders", USC names). Many authors have mentioned this question: Garlan & Shaw 1, Abowd & Allen of CMU, Clements of SEI. As a supplement, we recommend that you use multiple concurrent views to organize the description of the software architecture, and each view is used only to describe a specific set of areas of interest.

Back to top of page

Schema model

Software architecture is used to deal with the design and implementation of high-level architecture. It assembles several structural elements in a carefully selected form to meet the system's main functional and performance requirements and meet other non-functional requirements such as reliability, scalability, portability, and availability. Perry and Wolfe are expressed using an exact formula, which is further modified by Boehm:

Software architecture = {element, form, Relationship/constraint}

Software architecture involves abstraction, decomposition, and composition, style, and aesthetics. We use a model that consists of multiple views or perspectives to describe it. To ultimately deal with large, challenging architectures, the model consists of five main views (see Figure 1):

• Logical views (Logical view), the design of the object model (when using an object-oriented design approach).
• Process view, which captures the concurrency and synchronization characteristics of the design.
• The physical view (physical view), which describes the software-to-hardware mapping, reflects the distributed features.
• The Development view (development view) describes the static organizational structure of the software in the development environment.

The description of the schema, that is, the various decisions made, can be organized around these four views, then described by some use cases (uses cases) or scenes (scenarios), resulting in a fifth view. As you will see, the Software Architecture section is actually evolving from these scenarios and will be discussed in the following article.

Figure 1-"4+1" view model

We apply the Perry & Wolf formula independently on each view, which defines a collection of elements (components, containers, connectors) used, captures the work form and pattern, and captures relationships and constraints, connecting the schema to certain requirements. Each view is described using its own notation-Blueprint (Blueprint), and the architect can choose a specific architectural style (architectural style) for each view, allowing multiple styles to coexist in the system.

We will take turns observing these five views to show the goals of each view: The problem of the view, the marking of the corresponding architectural blueprint, the tools for describing and managing the blueprint. And in a very simple form from the PABX design, from our work on the Alcatel commercial system (Alcatel business systems), as well as from the Air Transport Control system (air traffic control systems) to elicit some examples- Instead of defining the architecture of these systems, the intent is to describe how the views are specific and how they are labeled.

The "4+1" view model is fairly "universal", so other labeling methods and tools can be used, and other design methods can be used, especially for logic and process decomposition. However, the methods mentioned in this paper have been successfully applied in practice.

Logical Structure

Object-oriented decomposition

The logical architecture primarily supports functional requirements-the functionality that the system should provide in order to provide services to users. The system is decomposed into a series of key abstractions, (most of them) from the problem domain, expressed as an object or as a form of an object class. They take the principles of abstraction, encapsulation, and inheritance. Decomposition is not just for functional analysis, but also for identifying common mechanisms and design elements that spread across the system. We use the Rational/booch method to represent the logical schema, with the aid of class diagram and class template means 4. A class diagram is used to display a collection of classes and their logical relationships: association, use, composition, inheritance, and so on. Similar classes can be grouped into class collections. Class templates focus on individual classes, which emphasize primary class operations and identify key object characteristics. If you need to define the internal behavior of an object, use a state transition diagram or a state diagram to complete it. A public mechanism or service can be defined in the class utilities function. For highly data-driven applications, other forms of logical views, such as e-r diagrams, can be used instead of object-oriented methods (OO approach).

Representation of logical views

The notation method for logical views comes from Booch notation 4. This notation is fairly straightforward when considering only items that have architectural significance. Especially at this level of design, a lot of modification is not very important. We use Rational Rose? To support the design of the logical architecture.

Figure 2-representation of a logical blueprint

The style of the logical view

The style of the logical view adopts the object-oriented style, and its main design criterion is to try to maintain a single, consistent object model throughout the system, avoiding the technical description of sloppy classes and mechanisms on every occasion or process.

Examples of logical Structure blueprints

Figure 3 shows the main classes in the Télic PABX architecture.

Figure 3-a. Logical blueprint for Télic PABX B. Blueprint for air traffic systems

PABX establish a communication connection between the terminals. The terminal can be a telephony device, a trunk (for example, connected to a central office), a connection line (PABX to PABX Line), a telephone line, a data cable, ISDN, and so on. Different lines are supported by a different interface card. The responsibility of the line controller object is to decode and inject all the signals on the interface card, and to convert each other between the small event sets that are specific to the interface card's signal and the consistency: start, stop, digitize, etc. The Controller object hosts all real-time constraints at the same time. This class derives a number of subclasses to satisfy different interface types. The responsibility of the terminal object is to maintain the terminal state and to coordinate the services on behalf of the line. For example, it uses the Numbering Plan service to interpret dialing. Conversation represents a series of terminals in a conversation. Conversation uses translation service (directory, logical physical mapping, routing), and connection service to establish a voice path between terminals.

For a larger system that contains a large number of classes with significant architectural significance, Figure 3 B depicts the top class diagram of the air traffic management system, containing 8 classes (for example, grouping of classes).

Process architecture

Process decomposition

The process architecture takes into account some of the non-functional requirements, such as performance and availability. It solves the problem of concurrency, distribution, system integrity, fault tolerance, and how the main abstraction of a logical view fits together with the process structure-that is, on which control thread, the operation of the object is actually executed.

The process architecture can be described at several levels of abstraction, with each level addressing different issues. At the highest level, the process architecture can be seen as a logical network of independently executed communication programs (known as "processes") that are distributed across a set of hardware resources that are connected over a LAN or WAN. Multiple logical networks may coexist at the same time, sharing the same physical resources. For example, a separate logical network might be used to support the separation of offline systems from online systems, or to support the coexistence of simulated and beta versions of software.

A process is a grouping of tasks that make up an executable unit. A process represents a hierarchy (that is, start, resume, reconfigure, and close) that can be used for policy control of the process architecture. In addition, processes can continue to be duplicated in the process of increasing the distributed enhancement or usability of the processing load.

The software is divided into a series of separate tasks. The task is a separate control thread that can be dispatched individually on the processing node.

Next, we can distinguish between primary and secondary tasks. The primary task is the schema element that can be handled uniquely, and the secondary task is the local additional task (periodic activity, buffering, pausing, and so on) introduced for the reason of the implementation. They can be implemented as an Ada Task or as a lightweight thread. The main task of communication is a well-defined interactive task communication mechanism: message-based synchronization or asynchronous communication services, remote procedure calls, event broadcasts, and so on. Secondary tasks communicate by meeting or sharing memory. On the same process or processing node, the primary task should not make any assumptions about their allocation.

Message flow, process load can be evaluated based on a process blueprint, as well as using dummy loads to achieve a "hollow" process architecture and measure performance on the target system. As Filarey et al described in his Eurocontrol experiment.

Representation of process views

The process view that we are using is represented by an extension from the presentation that Booch originally recommended for the Ada task. Similarly, the notation used to focus attention on elements that are architecturally significant. (Fig. 4)

Figure 4-Process Blueprint notation

We have used Universal network architechure Services (UNAS0) products from TRW to build and implement processes and task collections (which extend their redundancy) so that they are integrated into the process networks. The UNAS contains the software Architect Lifecycle Environment (SALE) tool, which supports the above representations. SALE allows a graphical representation of the process architecture, including specification of the communication path to possible interactive tasks, which automatically generates the corresponding Ada or C + + source code from these paths. The advantage of using this method to specify and enforce a process architecture is that it is easy to modify without too much impact on the application software.

The style of the process view

Many styles can be applied to the process view. For example, using Garlan and Shaw's Taxonomy 1, we can get pipelines and filters (Pipes and filters), or client/server, as well as a variety of multiple client/single servers and multiple client/multiple server variants. For more complex systems, you can use process group methods and other labeling methods and tools similar to those described by K.birman in the ISIS system.

Examples of Process blueprints

Figure 5-télic Process blueprint for PABX (part)

All terminals are handled by a single termal process, where the termal process is driven by messages in the input queue. The Controller object is executed on a task that consists of three tasks in the control process: the low cycle rate task scans all inactive terminals (in MS) and activates the terminal in the high cycle (ten ms) scan list, where high The cycle Rate task detects any significant state changes and passes them to the Main controller task, which interprets the changes to the state and communicates by sending messages to the corresponding terminal. The communication in the Controller process is realized through shared memory.

Development architecture

subsystem decomposition

The development architecture focuses on the organization of the actual modules in the software development environment. Software is packaged into small blocks (libraries or subsystems) that can be developed by one or several developers. Subsystems can organize the composition layer structure, each layer provides a well-defined interface for the previous layer.

The development architecture of the system is expressed in modules and subsystem diagrams, showing the "output" and "input" relationships. A complete development architecture can be described only when all software elements are identified. However, you can list rules that govern the development architecture: chunking, grouping, and visibility.

In most cases, the internal requirements considered by the development architecture are related to the following factors: difficulty in development, software management, reusability and versatility, and limitations imposed by toolsets and programming languages. The development architecture view is the basis for a variety of activities, such as demand allocation, assignment of team work (or team organization), cost assessment and planning, monitoring of project progress, software reuse, portability, and security. It is the basis for building a product line.

How to express your development blueprint

Similarly, using the Booch method of deformation, only items with architectural significance are considered.

Figure 5-Development Blueprint Presentation method

The Apex development environment from Rational supports the definition and implementation of the development architecture, the layered strategy described earlier, and the implementation of design rules. Rational Rose can draw development blueprints at the module and subsystem levels and support the development of forward and reverse engineering of source code (ADA, C + +) processes.

The style of the development view

We recommend using a layered (layered) style that defines 4 to 6 subsystem layers. Each layer has a well-defined responsibility. Design rule is a subsystem that relies on the same layer or lower layer of subsystem, thus minimizes the development of the network with complex module dependency, and obtains the simple strategy of the hierarchy.

Figure 6-hughes 5 layers of the air traffic System (HATS)

Examples of development architectures

Figure 6 Represents the 5 tiered development organizational structure of the air traffic control system (air traffic control systems) product line developed by Hughes Aircraft Canada. This is the development architecture that corresponds to the logical architecture described in Figure 3 B.

The first and second tiers comprise a domain-independent distributed infrastructure that covers the entire product line and protects it from different hardware platforms, operating systems, or commercially available products such as database management systems. The third layer adds an ATC framework to the infrastructure to form a specific domain software architecture (domain-specific software architecture). Using this framework, a feature selector board can be built on the fourth level. Level 5 relies heavily on customers and products, including most user interfaces and external system interfaces. 72 subsystems are distributed on 5 levels, each containing 10 to 50 modules, and can be represented on other blueprints.

Physical architecture

Software-to-hardware mapping

The physical architecture focuses on system non-functional requirements such as availability, reliability (fault tolerance), performance (throughput), and scalability. Software runs on a computer network or processing node, and the various elements (networks, processes, tasks, and objects) that are identified need to be mapped to different nodes; we want to use different physical configurations: some for development and testing, and others for deployments in different locations and different customers. Therefore, the software-to-node mapping requires a high degree of flexibility and minimal impact on the source code.

Representation of the physical blueprint

Physical blueprints in large systems can become very confusing, so they are available in many forms, with or without mappings from the process view.

Figure 7-representation of the physical blueprint

TRW's UNAS provides a data-driven approach to map the process architecture to the physical schema, which allows for a large number of mapped changes without modifying the source code.

Example of a physical blueprint

Figure 8-PABX's physical blueprint

Figure 8 shows the possible hardware configurations for large PABX, while Figure 9 and Figure 10 Show process mappings on two different physical architectures, one for small and one large PABX. C, F and K are three different capacity computers, supporting three different operating requirements.

Figure 9-Small PABX physical architecture with process assignment

Figure 10-A large PABX physical blueprint showing the process allocation

Scene

Combine all the views

The elements of the four views work seamlessly together through a relatively small set of important scenarios (more commonly, use cases), and we describe the appropriate scripts for the scenario (the sequence of interactions between objects and processes). As Rubin and Goldberg have described, 6.

In a sense the scenario is the most important requirement abstraction, and their design uses the object scene graph and the object interaction diagram to represent 4.

This view is redundant for other views (so "+1"), but it has two effects:

• As a driver to discover architectural elements in the architecture design process, this is discussed below.
• As a validation and description feature at the end of the architecture design, it is both a view-point and a starting point for the architectural prototyping test.

Representation of the scene

Scene notation is very similar to the component logical view (see Figure 2), but it uses the connector of the procedure view to represent the interaction between objects (see Figure 4), and notice that the object instance is expressed using a solid line. As for the logical blueprint, we use Rational Rose to capture and manage the object scene.

Example of a scene

Figure 11 shows a scene fragment of a small PABX. The corresponding script is:

1. Joe's phone controller detects and verifies the transition of the off-hook state and sends a message to wake the corresponding terminal object.

2. The terminal allocates some resources and requires the controller to issue a dial tone.

3. The controller accepts dialing and passes it to the terminal.

4. The terminal uses a dialing scheme to analyze the digital stream.

5. The valid number sequence is typed and the terminal begins the session.

Figure 11-Initial scene of a local call-stage selection

The correspondence between views

The various views are not completely orthogonal or independent. The elements of a view are associated with elements in other views based on a design rule and heuristic method.

From logical view to process view

We have found several important features of the logical view architecture:

• Autonomy: Is the object active, passive, or protected?
  • The active object has the initiative to invoke other objects or its own operations, and has full control over its own operations when other objects call them.
  • The passive object cannot invoke any action on its own, and there is no control over the operation of other objects calling itself.
  • The protected object cannot invoke any action on its own initiative. But has certain control function to own operation.
• Persistence: Is the object temporary or persistent? Will they cause the process or processor to terminate?
• Dependency: Does the existence or persistence of an object depend on another object?
• Distribution: Can the state or operation of an object be accessed by many nodes in the physical schema? Or is it accessed by several processes in the process architecture?

In the logical view, we consider each object to be active, potentially "concurrency", that is, "parallel" to other objects, and we do not consider the exact degree of concurrency to be achieved. Therefore, the logical structure considers only the functional aspects of the requirements.

However, when we define the process architecture, it is impractical to implement the respective control threads (for example, Unix processes or Ada tasks) for each object due to the huge overhead involved in the current technical situation. In addition, if the objects are concurrent, they must be called in some abstract form.

On the other hand, multiple control threads are required for several reasons.

• To quickly respond to a class of external triggers, including time-related events.
• In order to take advantage of multiple CPUs in one node, or to utilize multiple nodes in a distributed system.
• To increase CPU utilization, allocate CPUs for other activities when some control threads are suspended, waiting for other activities to end (for example, when accessing other active objects from external objects).
• To prioritize activities (improve potential responsiveness).
• To support the scalability of the system (with the help of other processes that share the load).
• To isolate concerns in different areas of the software.
• To improve the usability of the system (through the Backup process).

We use both strategies to determine the degree of concurrency and define the set of processes required. Consider a range of potential physical target architectures. We can choose one of the following two forms:

• From inside to outside:
  
  Start with a logical schema: Define an agent task that will control the diversification of a single thread of multiple active objects of a class; the same agent task also performs persistence on objects that depend on an active object, several classes that need to operate on each other, or classes that require only a small amount of processing to share a single agent. This aggregation will continue until we reduce the process to a reasonable amount, while still allowing the distribution and use of the physical resources.
• From outside to Inside:
  
  Start with the physical structure: identify the external triggering of the system, define the server processes that handle the triggered client process and service-only (not initialize them), use data integrity and problem serialization (serialization) constraints to define the correct server settings, and assign objects to client and server proxies ; Identify which objects must be distributed.

The result is that the classes (and their objects) are mapped to a process in a task collection and process schema. Typically, an activity class has an agent task, and there are some transformations: for a given class, multiple proxies are used to improve throughput, or multiple classes are mapped to a single proxy because their operations are not frequently called, or to ensure that the sequence is executed.

Note that this is not a linear, deterministic process that produces the best process architecture, and it requires several iterations to get an acceptable tradeoff. There are a number of other methods, such as Birman 5 or Witt and others 7. The exact method of implementing the mapping is not covered in this article, but we illustrate it with a small example.

Figure 12 shows how a small collection of classes maps from an imaginary air traffic control system to a process.

The flight class maps to a flight proxy collection: There are many flights waiting to be processed, the frequency of external triggering is high, the response time is critical, and the load must be distributed across multiple CPUs. Also, the persistence and distribution of flight processing depends on the flight server, or a backup server using Flight server, in order to satisfy availability.

The profile and clearance of a flight always belong to a flight, although they are complex classes, but they share the process of the flight class. Flights are distributed over several other processes, especially for display and external interfaces.

The Sectorization class, establishes the airspace partition for the controller's permission assignment. Because of integrity constraints, only one agent can be processed, but you can share server procedures with the flight class: updates are infrequent.

Location and Arispace and other static aeronautical information are protected objects that are shared among several classes, are rarely updated, and are mapped to their respective servers, distributed across other processes.

Figure 12-mapping from a logical view to a process view

From logical view to Development view

Classes are typically implemented as a module, such as a type of visual part of an ADA package. A collection of closely related classes (the kind of classes) is combined into a subsystem. The definition of a subsystem must consider additional constraints, such as the team organization, the desired code size (typically 5 k or K SLOC per subsystem), the degree of reusability and commonality, and the rigorous layering basis (visibility issues), publishing policies, and configuration management. Therefore, the final result is not a view that corresponds to a logical view.

The logical view and the development view are very close, but with different points of interest. We found that the larger the project size, the greater the gap between the views. For example, if you compare Figure 3 B and Figure 6, you will find that there is not a different class-to-layer mapping for each of the corresponding classes. And if we consider the kind of "external interface"-gateway kind of class, its implementation spreads over several layers: the communication protocol is on layer 1th or below, the universal gateway mechanism is on the 2nd level, and the specific gateway is in the 5th layer subsystem.

From process view to physical view

Processes and process groups are mapped to available physical hardware with different test and deployment configurations. Birman describes the detailed mapping mode 5 in the ISIS project.

The scene is primarily associated with the logical view in the form of the class used, and the association with the process view takes into account one or more of the control threads and the interaction between objects.

Tailoring the Model

Not all software architectures require a "4+1" view. Useless views can be omitted from the schema description, such as: There is only one processor, you can omit the physical view, and if there is only one process or program, you can omit the process view. For very small systems, it is even possible that logical views are very similar to development views without the need for separate descriptions. The scenario is applicable for all situations.

Iterative process

Witt has identified 4 phases for design and architecture: sketching, organizing, materializing, and optimizing, divided into 12 step 7. They also pointed to the need for some degree of reverse engineering. And we think that this method is too "linearized" for large projects. At the end of the 4 phase, there is too little content to validate the schema. We advocate a more iterative approach, where the architecture is first instantiated, tested, measured, analyzed, and then refined in a series of iterations. In addition to reducing the risk associated with architecture, this approach has other benefits for the project: teamwork, training, deeper understanding of the architecture, in-depth procedures and tools, and so on (here is the evolution of the prototype, evolving into a system rather than a one-time experimental prototype). This iterative approach also enables the refinement, maturation and better understanding of requirements.

Scenario-driven (Scenario-driven) method

Most key features of the system are captured in the form of scenes (or use cases). Key means: The most important features, the reason for the existence of the system, or the most frequently used features, or some of the important technical risks that must be mitigated.

Start Stage:

• Select some scenarios for an iteration based on risk and importance. Scenarios can be summed up as abstractions for a number of user needs.
• Form a "scarecrow-style architecture". The scene is then "described" to identify the major abstractions (classes, mechanisms, processes, subsystems), as pointed out by Rubin and Goldberg6, to decompose into sequence pairs (objects, operations).
• The discovered architectural elements are distributed across 4 blueprints: A logical blueprint, a process blueprint, a development blueprint, and a physical blueprint.
• The architecture is then implemented, tested, and measured, and this analysis may detect some drawbacks or potential enhancement requirements.
• Capture lessons learned.

Cycle Stage:

The next iteration process begins:

• Re-evaluate the risk,
• Expands the scenario selection Board for consideration.
• Select an additional number of scenarios that mitigate risk or improve fabric coverage,

And then:

• Try to describe these scenarios in the original schema.
• Discover additional architectural elements, or sometimes need to identify the important architectural changes needed to adapt to these scenarios.
• Update 4 main views: Logical view, Process view, development view, and physical view.
• Revise the existing scene according to the changes.
• Upgrade implementation Tools (schema prototypes) to support new, expanded sets of scenes.
• Test. If possible, test under the actual target environment and load.
• The five views are then reviewed to detect potential problems with simplicity, reusability, and versatility.
• Update design guidelines and fundamentals.
• Capture lessons learned.

Terminating loops

For the actual system, the initial architectural prototypes need to evolve. The better case is that after 2 or 3 iterations, the structure becomes stable: the main abstraction has been found. Subsystems and processes have been completed, and all interfaces have been implemented. The next step is the scope of software design, which may also use similar methods and processes.

The duration of these iterations is uneven due to the size of the project being implemented, the number of participants involved in the project, their familiarity with the area and methodology, and the familiarity of the system and the development Organization, among others. Thus a smaller project iteration may last for 2-3 weeks (for example, ten K SLOC), while a large project may be 6-9 months (for example, a K-SLOC).

Documentation of schemas

The documentation generated in the architecture design can be summed up in two ways:

• A software architecture document with a structure that follows the "4+1" view (see Figure 13, a typical outline)
• Software design guidelines that capture the most important design decisions. These decisions must be adhered to to maintain the integrity of the system architecture. Figure 13-Software Architecture documentation outline

Back to top of page

Conclusion

The "4+1" view can be successfully used in many large projects, whether or not a local customization and technical adjustment has been made. In fact, it allows different "stakeholders" to identify issues that they are concerned about in the software architecture. The system engineer first touches the physical view and then turns to the process view; the end user, the customer, the data analysis expert starts with a logical view, and the project manager, Software Configurator sees the 4+1 view from the development view. Other series of views, such as Meszaros (BNR) and Hofmeister, are presented and discussed in Rational and elsewhere. Nord and Soni (SIEMENMS), Emery and Hilliard (Mitre), but we found that other views can usually be grouped into one of the 4 views we describe. For example, the Cost&schedule view can be grouped into a development view, a data view grouped into a logical view, and an execution view grouped together into a process view and a physical view.

Table 1-"4+1" View model list

Back to top of page

Thanks

The birth of the "4+1" view was attributed to colleagues working in rational, Hughes aircraft in Canada, Alcatel, and elsewhere. I am particularly grateful to the following people for their contributions: Ch. Thompson, A. Bell, M.devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec, E. Schonberg.

Architecture Blueprint-Software Architecture "4+1" view model