6.4 Architectural Views


In this section, we discuss a variety of views and explain how each is used. The three basic views correspond to the three ways an architect thinks about a system. These basic views include a static view based on modules, a dynamic view based on components and connectors, and a view that displays the mapping between software and hardware.

Each element in each view type has a collection of properties. For example, a potential property of a component is that it is a "client." Associated with "clients" are "servers." Associated with clients and servers are "protocols of interaction." These properties are usually associated with design decisions. To deal with these groups of associated properties, we identify specific subviews of one of the three basic view types.

The layered view is an example of a view type associated with design decisions. Here the properties of interest involve the relation allowed-to-use. Modules are allowed to use other modules only if the two modules satisfy a certain set of constraints. These constraints restrict the property values of the modules involved. The association with design decisions reflects the fact that not every system is layered. It makes sense to represent a system in a layered view only if it is, in fact, layered. This is true for all of the subviews that we discuss.

Our list of subviews is not exhaustive. Every cohesive set of design decisions, such as embodied in architectural styles [Shaw 96, Bass 98], leads to a view for representing those decisions. Because architects tend to think in terms of architectural styles and patterns, subviews are created for common architectural styles and patterns.

Module Views

A module is a software implementation unit that provides a coherent unit of functionality. A module can be a class, a collection of classes, a layer, or any decomposition of the set of code. Every module has a collection of properties, such as responsibilities, visibility information, and author. Modules have relationships, such as is-part-of or inherits-from.

UML provides a variety of constructs that represent different kinds of modules. Figure 6-1 shows some examples of UML notation. Packages can be used to group functionality. The subsystem construct can be used if the specification of interfaces and behavior is required.

Figure 6-1. Examples of UML module notations

graphics/06fig01.gif

Figure 6-2 denotes important UML relations in the module view. From left to right, the diagrams read as follows : Module B is part of module A, module D depends on module C, and module F is a type of module E.

Figure 6-2. Examples of UML relation notations

graphics/06fig02.gif

Decomposition View

This view represents the decomposition of the code into systems, subsystems, subsubsystems, and so forth. This view also represents a top-down view of the system. (The terms system and subsystem also have runtime interpretations and so need to be clarified in a particular context.)

The decomposition view gives an overall view of the system and its pieces. This view is particularly useful for education and manager-level communication and is often the basis of work assignments and completion measures.

In UML, the subsystem construct can represent modules that contain other modules. The class box is normally used for the leaves of the decomposition. Subsystems are both a package and a classifier. As a package, subsystems can be decomposed and hence are suitable for aggregating modules. As a classifier, subsystems encapsulate their contents and can provide an explicit interface.

Aggregation is depicted in one of three ways in UML:

  1. Modules may be nested inside one another, as in a package (see Figure 6-3A).

    Figure 6-3. Decomposition in UML with (A) nesting and (B) arcs

  2. A succession of two, possibly linked, diagrams can be shown, with the second depicting the contents of a module shown in the first.

  3. An arc denoting composition is drawn between the parent and the children (see Figure 6-3B). In UML, composition is a form of aggregation that implies strong ownership: Parts live and die with the whole. So if module A is composed of modules B and C, B or C cannot exist without the presence of A. If A is destroyed at runtime, so are B and C. Thus, UML's composition relation has implications beyond the structuring of the implementation units. The relation also endows the elements with a runtime property. As an architect, you should be comfortable with this property before using UML's composition relation.

Generalization View

The generalization view shows how various code units relate to one another. Typically, this view represents the class hierarchy and inheritance structure.

This view is used mainly to express object-oriented designs. It can support a variety of forms of maintenance. Reuse is frequently based on classes. New functions are often added by modifying old functions.

Expressing generalization lies at the heart of UML. Modules are shown as classes, although they may also be shown as subsystems, as discussed in the decomposition style. Figure 6-4 shows the basic notation available in UML. UML provides two line styles to show generalization. These two diagrams are semantically identical. UML allows an ellipsis ( ) in place of a submodule. This indicates that a module can have more children than shown and that additional ones are likely.

Figure 6-4. Documenting generalization in UML

graphics/06fig04.gif

Layered View

The layered view organizes the code as disjoint layers. Code in the higher layers is allowed to use code in a lower layer according to predefined rules: for example, allowed to use code only in the next lower layer, allowed to use code in any lower layer, or allowed to use code in the lower layers or in a utility layer.

This view shows how the code is decomposed into levels of abstraction. Typically, the lowest layer involves those portions of the system close to the hardware, including the operating system. The next layer might involve database management, the layer above that might involve business logic, and the layer above that the user interface.

The layered view is used for education and to support reuse; code in lower layers is likely more flexible. This view can also support portability. Having hardware-dependent code localized in a single layer, for example, supports changing the hardware without affecting the rest of the system.

Sadly, UML has no built-in primitive corresponding to a layer. However, simple ”nonsegmented ”layers can be represented in UML by using packages, as shown in Figure 6-5. A package organizes elements into groups. UML has predefined kinds of packages for systems and subsystems. We can introduce an additional package for layers by defining it as a stereotype of package. The dependency between packages is allowed-to-use. Layers are designated by using the package notation with the stereotype name <<layer>> preceding the name of the layer or by introducing a new visual form, such as a shaded rectangle.

Figure 6-5. A simple representation of layers in UML

graphics/06fig05.gif

Component-and-Connector Views

Unlike static views, dynamic views are expressed as components that have some runtime presence, such as processes, objects, clients, servers, and data stores. Additionally, component-and-connector (C&C) views include connectors that also have a runtime presence and act as the pathways of interaction, such as communication links and protocols, information flows, and access to shared storage. Often, these interactions are carried out using a complex infrastructure, such as middleware frameworks, distributed communication channels, and process schedulers .

A C&C view depicts runtime entities in action. Within such a view, there may be many instances of the same component type. Drawing on an analogy from object-oriented systems, C&C views are similar to object, or collaboration, diagrams. One strategy for documenting C&C views using UML is to represent component types with UML classes and component instances with objects. Although there are several other strategies, and associated rationale for choosing among them, a complete explanation is too detailed for our purposes here. For a treatment of these strategies, see [Garlan 02].

Figure 6-6 shows a graphical representation of a component-and-connector view of a runtime client/server architecture for a simple bank.

Figure 6-6. A simple C&C view

graphics/06fig06.gif

This figure, backed up by its supporting documentation, presents a bird's-eye view of the system during runtime. The system contains a shared repository of customer accounts ( Account DB ) accessed by two servers ( Account Server-main and Account Server-backup ) and an administrative database application ( Admin ). A set of client tellers ( Client Teller 1 .. Client Teller N ) can interact with the account repository servers, embodying a client/server style. These client components communicate among themselves , publishing and subscribing to events. The two servers, we learn from the supporting documentation, enhance reliability: If the main server goes down, the backup takes over. Finally, the Admin component allows an administrator to access, and presumably maintain, the shared data store.

Each type of connector in this figure represents a different form of interaction among the connected parts. The client/server connector allows a set of concurrent clients to retrieve data synchronously via service requests . This variant of the client/server style supports transparent failover to a backup server. The database access connector supports authenticated administrative access for monitoring and maintaining the database. The publish/subscribe connector supports asynchronous announcement and notification of events.

Each connector represents a complex form of interaction, requiring nontrivial implementation mechanisms. For example, the client/server connector type represents an interaction protocol that prescribes how clients start a client/server session, constraints on ordering of requests, how/when failover is achieved, and how sessions are terminated . Its implementation will probably involve runtime mechanisms to detect when a server has gone down, queue client requests, handle attachment and detachment of clients, and provide other client services. Connectors can involve more than two participants .

C&C diagrams may also make it possible to qualitatively and quantitatively analyze system properties, such as performance, reliability, and security. For instance, the design decision that causes the administrative interface to be the only way to change the database schema would have a positive impact on the security of the system. But it also might have implications on administratability or concurrency; for example, does the use of the administrative interface lock out the servers? Similarly, by knowing properties about the reliability of the individual servers, one could produce numeric estimates of the overall reliability of the system, using some form of reliability analysis.

Some things to notice about this figure follow.

  • It acts as a key to the associated supporting documentation, which is not shown.

  • It is simple enough to comprehend immediately.

  • It is explicit about its vocabulary of component and connector types.

  • It provides a key to discussions about the number and kinds of interfaces on its components and connectors.

  • It uses abstractions for its components and for its connectors, concentrating on application functionality rather than on implementation mechanisms.

The documentation that contained the graphic shown in this figure elaborates on the elements shown. Supporting documentation should explain how Account Server-backup increases the reliability of the overall system. An expanded figure, not shown, might focus on the main account server, its backup, and the client/server connection.

Notation

The class concept is perhaps the most natural candidate for representing component types in UML. The type/instance relationship in an architectural description is a close match to the class/object relationship in a UML model. Properties of architectural components can be represented as class attributes or with associations; behavior can be described with behavioral models.

Using the class concept in UML causes problems in representing connectors and systems. Problems result from the lack of a match with UML concepts and the requirement to be more precise about the type of connection between components. [2] Problems also arise in modeling systems. In UML, a package represents a set of elements that may be imported into another context but not a structure per se. In contrast, a system in an architecture design is a structure with defined subparts.

[2] Restrictions in using UML to represent components and connectors are partially driving UML 2.0, as mentioned in the introduction to this chapter.

Several notations can be used for representing a portion of component and connector interactions. They include use case maps, sequence diagrams, collaboration diagrams, and message sequence charts .

Use Case Maps

Use case maps are used to visualize execution paths through a set of elements from a bird's-eye view [Buhr 96]. The fairly intuitive notation communicates how a system works ”or is supposed to work ”without too much detail.

Use case maps can be derived from informal requirements or from use cases, if they are available. Responsibilities need to be stated or inferred from these requirements. Separate use case maps can be created for individual system functions or even for individual scenarios. However, the notation's strength resides in integrating related scenarios. In such cases, use case maps can illustrate concurrency, such as resource consumption problems ”multiple paths using one element ”or possible deadlock situations ”two paths in opposite directions through at least two of the same elements.

If you ever followed a discussion of developers trying to answer concurrency-related questions, such as, "Does an element need to be locked?" or "Is there potential for deadlock?" you may have seen them drawing a picture similar to the sketch shown in Figure 6-7. The circles denote system elements. Each line denotes a path of activity through the elements. This type of informal notation is useful in answering such questions and illustrates a need for the well-defined equivalent found in use case maps.

Figure 6-7. Informal notation for activity paths through system elements

graphics/06fig07.gif

The basic idea behind use case maps is captured by the phrase causal paths cutting across organizational structures. An execution path in a use case map describes how elements are ordered according to their responsibilities. When it enters an element (a box), an execution path (a line) states that this element now does its part to achieve the system's functionality. A responsibility that is assigned to the path while within an element defines it as a responsibility of the element.

The use case map notation includes many other symbols for such features as timers and timeouts; data containers; interactions between execution paths, such as aborting; and goals, which are useful when describing agent-oriented elements. An example of a use case map for an order placement in RSS is shown in Figure 6-8.

Figure 6-8. Use case map for order placement in RSS

graphics/06fig08.gif

Sequence Diagrams

Sequence diagrams document a sequence of interactions over time. These diagrams present a collaboration of instances of elements, with interactions between them arranged in time sequence. In particular, a sequence diagram shows only the instances participating in the scenario being documented. A sequence diagram has two dimensions, with the vertical dimension representing time and the horizontal dimension representing instances. In a sequence diagram, relationships among the objects, such as those found in a module view, are not shown.

Sequence diagrams nicely support picturing dependent interactions: in other words, they show which stimulus follows another stimulus. However, they are not explicit in showing concurrency. Although a sequence diagram shows instances as concurrent units, no assumptions can be made about ordering, as for example, when a sequence diagram depicts an instance sending messages at the "same time" to different instances.

It might be intended that the interactions shown in various sequence diagrams can be performed independently of one another. If this is the intention , it should be noted somewhere. It is not appropriate to document independent behaviors within the same sequence diagram.

Figure 6-9 shows a sequence diagram for order placement in RSS. A stimulus is shown as a horizontal arrow. For example, the arrow labeled verifyStock() depicts a message sent from the Order Management module to the Inventory module. The direction of the arrow defines the producer ”start of the arrow ”and the consumer ”end of the arrow ”of the stimulus. A stimulus usually has a name that describes the stimulus and usually maps to a resource in the interface of the consumer instance. A stimulus can be drawn as a dotted line to indicate that it describes a return of control to the sender.

Figure 6-9. Sequence diagram for order placement in RSS

graphics/06fig09.gif

UML's sequence chart notation supports more features than we have illustrated . For example, interactions can be documented using various types of arrows to indicate more specific semantics for the communication, such as synchronous, asynchronous, periodic, and aperiodic types of communication. In addition, forms of flow control, such as decisions and iteration, can be depicted in various ways. For the sake of clarity, it is recommended to avoid too much logic in the diagram.

A constraint language, such as the UML's Object Constraint Language (OCL) can be used to add more information. OCL statements can be attached to the arrow and become recurrence values of the action attached to the stimulus.

Collaboration Diagrams

A collaboration diagram shows ordered interactions among elements. Whereas a sequence diagram shows order using a time-line-like mechanism, a collaboration diagram shows a graph of interacting elements and annotates each interaction with a number denoting order.

Collaboration diagrams are useful when the task is to verify that an architecture can fulfill the functional requirements. Such diagrams are not useful for understanding concurrent actions, as in performance analysis.

Figure 6-10 shows a simple collaboration diagram for order placement in the current RSS, given that the product is out of stock but that funds are available. Interactions are labeled by arrows attached to links ”lines ”between the instances ”boxes. The direction of the arrow identifies the sender and the receiver of each interaction. Special types of arrows, such as a half-headed arrow, depict different kinds of communication, including asynchronous, synchronous, and timeout.

Figure 6-10. Collaboration diagram for order placement in RSS

graphics/06fig10.gif

Sequence numbers can be added to interactions to show order. Subnumbering shows nested stimuli and/or parallelism. For example, the interaction with a sequence number 2.1 is the first interaction sent as a result of receiving stimulus number 2. The letter a in interaction 4.a means that another stimulus, 4.b, can be performed in parallel. This numbering scheme may be useful for showing sequences and parallelism, but it tends to make a diagram unreadable.

A collaboration diagram also shows relationships, or links, among the elements. Links show relationships between structural instances. Links between the same instances in different collaboration diagrams can show different aspects of relationships between the same structural elements. Links between instances have no direction. A link states only that the connected instances can interact. If a more accurate definition is required, additional documentation, possibly a textual description, must be introduced.

Collaboration diagrams express similar information as sequence diagrams. Whereas sequence diagrams show time explicitly, collaboration diagrams use numbers to indicate time. Some users prefer collaboration diagrams because they show element relationships, whereas sequence diagrams do not show these relations if connected elements do not interact in the scenario depicted in the sequence diagram.

Deployment View

The deployment view incorporates hardware elements, including processing nodes, communication channels, memory stores, and data stores. The software elements in this view are usually processes. This view describes how processes are allocated to hardware and the resulting message traffic.

The deployment view is used to analyze performance, security, and reliability. This view also provides a basis for estimating the cost of deployment of a single node. Figure 6-11 illustrates a sample deployment diagram for RSS, showing that multiple instances of the RSS component can run on a single Unisys OS 2200 server. Each instance communicates with a different database to support one or more retail locations. Clients from each retail location communicate with the RSS instance responsible for supporting their location.

Figure 6-11. A UML deployment view for RSS

graphics/06fig11.gif

In UML, a deployment diagram is a graph of nodes connected by communication associations. Nodes may contain component instances, indicating that the component lives or runs on the node. Components may contain objects, indicating that the object is part of the component. Components are connected by dashed-arrow dependencies, possibly through interfaces. This shows that one component uses another component's services. A stereotype may be used to indicate the precise dependency, if needed. The deployment type diagram may also show which components run on which nodes, by using dashed arrows with the stereotype «supports ».

A node is a runtime physical object that represents a processing resource. A node generally has at least a memory capability and often a processing capability. Nodes include not only computing devices but also human resources or mechanical processing resources. Nodes may be types or instances. Runtime computational instances, both objects and component instances, may reside on node instances. A node is shown as a figure that looks like a three-dimensional view of a cube. A node type has a type name. A node instance has a name and a type name. The node may have an underlined name string in it or below it.

Dashed-arrow dependencies show the capability of a node type to support a component type. A stereotype may be used to state the precise kind of dependency.

Component instances and objects may be contained within node instance symbols, indicating that the items reside on the node instances. Containment may also be shown by aggregation or composition association paths.

Nodes may be connected by associations to other nodes. An association between nodes shows a communication path between the nodes. The association may have a stereotype to indicate the nature of the communication path: for example, the kind of channel or network.

Symbols may be nested within the node symbol. Such nesting maps either into a composition association between a node class and constituent classes or into a composition link between a node object and constituent objects.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net