Part I. Software Architecture Viewtypes and Styles

I Software Architecture Viewtypes and Styles

Chapters 15 present the three viewtypesmodule, component-and-connector, and allocationin detail with several common styles of each. Here we introduce those styles and the organization we use to describe them.

I 1 Viewtypes and Style Catalog

I.1.1 Module Viewtype

We begin by discussing the module viewtype. A module is a code unit that implements a set of responsibilities. A module can be a class, a collection of classes, a layer, or any decomposition of the code unit. Every module has a collection of properties assigned to it. These properties are intended to express the important information associated with the module, as well as constraints on the module. Sample properties are responsibilities, visibility information, and author. Modules have relations to one another. Example relations are is part of or inherits from.

The module viewtype contains several styles.

  • The decomposition style represents the decomposition of the code into systems, subsystems, subsubsystems, and so on. This style represents a top-down view of the system. (The term system or subsystem also has a runtime interpretation, and so its use needs to be clarified in a particular context.) This style, used to give an overall view of the system and its pieces to stakeholders, is particularly useful for education and manager-level communication. This style helps new members of the development team understand what their roles are in terms of code development and is often the basis of work assignments and completion measures.
  • The uses style depends on the uses relation, which is a special form of the depends-on relation. A unit of software P1 is said to use another unit, P2, if the correctness of P1 depends on P2 being correct as well. This style tells developers which other modules must exist for their portion of the system to correctly execute. This style supports incremental development, as it enables the identification of useful system subsets that can be fielded early.
  • The generalization style shows how different code units are related to one another, as in a class hierarchy: Which classes inherit from which other classes can be determined by looking at the generalization style. This style is commonly used to express object-oriented designs, as well as to support a variety of forms of maintenance. Reuse is frequently based on classes, new functions are often added by modifying old functions, and the portion of the code to be repaired in the case of an error is usually specified in terms of classes.
  • The layered style organizes the code into disjoint layers where code in higher layers is allowed to use code in lower layers according to predefined rules. For example, rules may stipulate that only code in the next lower layer may be used, that code in any lower layer may be used, or that code in the lower layers or in a utility layer may be used. This style is used to show how code is decomposed in virtual machines. Typically, the lower levels involve those portions of the system close to the hardware, including the operating system, whereas the higher layers contain more application-dependent software. The layered style is used for education and to support reuse. This style is also used to support portability. Having hardware-dependent code localized, for ex-ample, supports changing the hardware.

DEFINITION

A layer is a collection of code that forms a virtual machine and that interacts with other layers only according to predefined rules.

I.1.2 Component-and-Connector Viewtype

Styles in the component-and-connector viewtype express runtime behavior. They are described in terms of components and connectors. A component is one of the principal processing units of the executing system; a connector is an interaction mechanism for the components. Objects, processes, or collections of objects may all be components. Connectors include pipes, repositories, and sockets. Middleware can be viewed as a connector between the components that use the middleware. Components and connectors can be decomposed into other components and connectors. The decomposition of a component may include connectors and vice versa. Decomposing middlewarea connector, for examplewill yield various components and additional connectors. Components and connectors also have properties that can be used to assist with the analysis. We discuss six component-and-connector styles.

  • The pipe-and-filter style is one in which the pattern of interaction is characterized by successive transformations of data. Data arrives at a filter, is transformed, and is passed through the pipe to the next filter in the pipeline. Examples of such systems are signal-processing systems and UNIX pipes.
  • The shared-data style centers on the retention of persistent data. Multiple elements access the persistent data, which is retained in at least one repository. Database systems and knowledge-based systems are examples of shared-data styles. One characteristic of a shared-data style is how the consumer of data can discover that data of interest is available.
  • The publish-subscribe style is characterized by components that interact by announcing events. Components may subscribe to a set of events. This style is commonly used to decouple message producers and consumers. This decoupling allows deferring the binding of producers and consumers of messages until runtime, and hence supports the modification of these producers and consumers.
  • The client-server style shows components interacting by requesting services of other components. The essence of this style is that communication is typically paired. A request for service from a client is paired with the provision of that service. Servers in this style provide a set of services through one or more interfaces, and clients use zero or more services provided by other servers in the system. There may be one central server or several distributed ones. Examples of client-server systems include: (1) window systems that partition the system according to client application and screen server, (2) name directory services that partition according to name resolver and name server, (3) two-tier database systems that partition the system according to clients and data, and (4) distributed Web-based systems that partition the system according to such concerns as client applications, business logic, and data management services.
  • The peer-to-peer style is characterized by direct component interaction of peers exchanging services. Peer-to-peer communication is a kind of request/reply interaction without the asymmetry found in the client-server style. That is, any component can, in principle, interact with any other component by requesting its services. Thus, connectors in this style may involve complex bidirectional protocols of interaction reflecting the two-way communication that may exist between two or more peer-to-peer components. Examples of peer-to-peer systems include architectures that are based on distributed object infrastructure, such as CORBA, COM+, and Java RMI (remote method invocation). More generally, runtime architectural views of object systems, such as shown in collaboration diagrams, are often examples of this C&C style.
  • The communicating-processes style is distinguished by the interaction of concurrently executing components through various connector mechanisms. Examples of the connector mechanisms are synchronization, message passing, data exchange, start, stop, and so forth. Communicating processes are common in most large systems and necessary in all distributed systems. Thus, for most systems, the communicating-processes style is appropriate for understanding any behavior associated with concurrency.

I.1.3 Allocation Viewtype

The allocation viewtype includes the following styles. Each allocation style describes the mapping of software units to elements of the environment (the hardware, the file systems, or the development team).

  • The deployment style maps processes to hardware elements: processing nodes, communication channels, memory stores, and data stores. The software elements in this style are usually processes. This style, used to describe how processes are allocated to hardware and the resulting message traffic, is used for analysis of performance, security, and reliability and provides a basis for estimating the cost of deployment of a single node.
  • The implementation style maps modules of a module viewtype to a development infrastructure. Elements of the implementation style are modules and configuration entities. This style is used to describe how modules are mapped to entities within the configuration management system, as well as to manage versions and branches and to coordinate multi-team development.
  • The work assignment style maps modules of a module viewtype to human development teams. Elements of the work assignment style are modules and development teams. The style is used to describe which teams are responsible for which elements of the work-breakdown structure, as well as to inform schedule and budget estimates.

I.2 Style Guides: A Standard Organization for Documenting a Style

All of the viewtype and style descriptions in Chapters 15 follow the same outline that constitutes the standard organization of a style guide.

  1. Overview. The overview explains why this viewtype/style is useful for documenting a software architecture. It discusses what it is about a system that the viewtype/style addresses and how it supports reasoning about and analysis of systems.
  2. Elements, relations, and properties

    1. DEFINITION

      An element is the architectural building block that is native to a viewtype/style.

      Elements are the architectural building blocks native to the viewtype/style. The description of elements tells what role elements play in an architecture and furnishes guidelines for effective documentation of the elements in views.

    2. DEFINITION

      A relation determines how elements cooperate to accomplish the work of a system.

      Relations determine how the elements work together to accomplish the work of the system. The discussion names the relations among elements and provides rules on how elements can and cannot be related.

    3. DEFINITION

      A property is additional information about elements and relations.

      Properties are additional information about the elements and their associated relations. When an architect documents a view, the properties will be given values. For example, properties of a layeran element of the layered style, which is in the module viewtypeinclude the layer's name, the units of software the layer contains, and the nature of the virtual machine that the layer provides. A layered view will, for each layer, specify its name, the unit of software it contains, and the virtual machine it provides. Thus, the existence of a property in a viewtype/style imparts an obligation to the architect, when documenting a corresponding view, to fill in that property. The viewtypes and styles of Chapters 15 are described with a set of properties likely to be useful for each. But the architect should compile his or her own list of properties when adopting a style, and include that list in the documentation.

  3. What it's for and not for. This section describes the kind of reasoning supported and, just as important, the kind of reasoning not supported by views in the viewtype or the style. This section describes typical users and their use of the resulting views in order to help the architect understand to what purpose(s) a view in this viewtype or style may be put.
  4. Notations. Descriptions are given of graphical and/or textual representations that are available to document views in the viewtype/style. Different notations will also support the conveyance of different kinds of information in the primary presentation.
  5. Relation to other views. This section describes how views in the viewtype/style might be related to those in different viewtypes or even in different styles in the same viewtype. For example, views in two styles might convey slightly different but related information about a system, and the architect will need a way to choose which one to use. This section might also include warnings about other views with which a particular view is often confused, to the detriment of the system and its stakeholders. Finally, this section might include a suggestion about useful mappings that can be built by combining a view in this viewtype with another.
  6. Examples. This section provides or points to an example of a system documented in the given style.

Software Architectures and Documentation

Part I. Software Architecture Viewtypes and Styles

The Module Viewtype

Styles of the Module Viewtype

The Component-and-Connector Viewtype

Styles of the Component-and-Connector Viewtype

The Allocation Viewtype and Styles

Part II. Software Architecture Documentation in Practice

Advanced Concepts

Documenting Software Interfaces

Documenting Behavior

Choosing the Views

Building the Documentation Package

Other Views and Beyond

Rationale, Background, and Design Constraints

References



Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152

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