4.6. Architectural Software Notation

In this section we will convey a basic familiarity with software notations that is essential for all architects. If you are very experienced with software design and the Unified Modeling Language (UML), you can safely skip this section. Understanding these notations enables you to understand the business implications of information technology. This section uses a subset of the UML including those features which are commonly used and commercially supported in computer-aided software engineering tools today. We recommend that your organization adopt UML in order to facilitate communication in general computer literacy for interpreting architectural documentation.

Before UML, there existed a large number of proprietary information technology diagrams and notations ( Figure 4.13). In fact, every authoritative practitioner of object orientation and other information technologies had their own notation—for example, Booch notation, Odell notation, object modeling technique (OMT) notation, and so forth. It was a general consensus that approximately 70% of the concepts that were being modeled through these various notations were overlapping. It took the industry many years to discover how to unify notations in these common areas and provide a way to extend the common notation to capture their specialized extension.

The unified modeling language is a consensus standard of the Object Management Group. UML is a unique standard because it is also supported by the Microsoft Corporation, which participated actively in the OMG process. It captures the common concepts from the proprietary notations in a uniform manner, and it is designed for extensibility, so that particular kinds of extensions can be defined consistent with the standard. In particular the UML standard includes extensions for business modeling and for objectory process. UML contains and represents common notational conventions for information systems models. These include object-oriented models as well as more general business process models in other forms of information representation. Authorities such as David Harel have described the creation of UML as an industry standards achievement as significant as Algol 60. Today, UML is enthusiastically supported by most object-oriented software authorities and major vendors including IBM and Microsoft.

The UML standard includes several sections. The UML notation guide is the specification that is most likely to provide benefits. The diagramed notation is defined along with a minimal set of semantics that defines the meaning of the notation. There also exists a much more elaborate semantic description of UML called the UML meta-model, a standard that provides additional details about the fine-grained issues of diagram meaning. In addition, UML includes an object constraint language, which is a textual notation using first-order logic that enables rigorous description of diagram-based constraints.

There are two categories of UML diagram types, as shown in Figure 4.14. Static diagrams represent the logical structure of information objects. Dynamic diagrams represent the behavior and activities of these objects. The static diagram types include use case diagrams, static structure diagrams, and implementation diagrams. Use case diagrams are used for enterprise viewpoint modeling and other kinds of top-down analysis to discover the key functionality of information systems. Static structure diagrams are used for information viewpoint objects as well as other important descriptions, because they identify exclusive objects and define constraints on those objects, including the object attributes, the object operation, and other characteristics. Implementation diagrams enable the description of the computational components as well as the technology objects and how they are deployed and allocated.

"Modeling is a craft and at times an art" [Rechtin 97].

Dynamic UML diagrams include interaction diagrams and state charts. Interaction diagrams represent the time-based behavior of groups of objects exchanging object-oriented messages. State chart diagrams are usually used to represent the internal states and transitions of individual objects.

Figure 4.15 represents a running example that we will use to help explain the capabilities of UML notation. In this example we are modeling various characteristics of a purchasing system. This is a contrived example, and we will only define aspects of this system which are useful for describing the features of UML. In this purchasing system we have employees who engage in the acquisition of capital equipment. We have corporate buyers who have the authority to conduct purchasing transactions, and we have vendors that manufacture and market capital equipment that the employees need.

Figure 4.16 is an example of packages, used to represent the key architecture viewpoints. A package is used to represent any grouping of UML modeling elements, much as parentheses are used to group words in sentences. In modeling tools, packages are used to represent subsidiary diagrams. Wherever a package appears, there is yet another more detailed diagram, viewable on another modeling screen or page.

Figure 4.17 is a use case diagram representing the top-level functionality of the procurement system. In this diagram we have represented the boundary of the procurement system as a UML package. UML packages appear as file folders in diagrams and usually represent the existence of an embedded diagram within a particular viewpoint. In a case tool, clicking on a package will reveal a more detailed diagram from that viewpoint of the system. In our use case we have a number of stick figures which represent actors that participate in using the system. Actors are analysis objects which in most cases are external to the system. Each of the use cases is represented by an oval in the diagram and represents some major function of the system which can be detailed later as analysis and design progresses. Dependencies between actors in use cases are represented as arrows in this diagram (Figure 4.17). The power of use case analysis is that the diagrams are simple representations of what the system does. Use case analysis forces the modelers to focus on the highest priority capabilities of the system that provide value to the users.

The second type of diagrams in UML are called static structure diagrams. Many people call them class diagrams. The purpose of static structure diagrams is to identify the concepts and constraints that are structural within the information system. Static structure diagrams contain two types of entities including classes and objects. Classes represent a specific category of behavior. Objects represent specific instances of classes. Classes and objects are represented with rectangles in the UML. Objects are distinguished because the name appearing in the top cell of the rectangle will be underlined. Whenever we have this underlined element in a UML diagram, we generally mean that we are representing an instance of that entity.

Figure 4.18 is a static structure diagram for the purchasing system. In this case we have a package which represents the purchasing communities and we have various information objects that represent various kinds of documents involved in the purchasing process. For example, there are purchase requisition documents, procurement checklist documents, and purchase order documents. Relationships between the classes are represented by lines. These lines are called associations. Another common notation shown in Figure 4.21 is a comment or note, which is represented by a rectangle with the top right corner folded in. A note is attached to one or more model elements and specifies additional constraints or semantics for the diagram.

Figure 4.19 is another static structure diagram showing the employee type class and various subclasses including employee contacts and purchasing contacts. The unique kind of association that represents inheritance is shown in Figure 4.19 as a line with an open-ended arrow. This is called a generalization association. Figure 4.20 shows major forms of associations appearing in UML. The purpose of associations is to show relationships between model entities. These relationships may be one-to-one, one-to-many, or other types of cardinality constraints. Most associations in UML diagrams are plain lines between objects and classes. An association can have a name attached to it and an identification of roles at each end of the association. Each of the roles can be identified by numbers or ranges of numbers. If the asterisk symbol is used, this means many, which denotes any number from zero to infinity.

Other types of associations include generalization for representing inheritance, dependency for showing general kinds of change relationships, aggregation for showing part-whole relationships and collections, and then composition, which is a stronger form of aggregation that implies that the life cycles of the related objects are tightly coupled. In other words, in composition, if the aggregate object is deleted, all of the objects that are part of that composition are also deleted (Figure 4.20).

Figure 4.21 is yet another static structure diagram and shows more of the details of associations and attributes and operations that UML can represent. When particular elements of UML are not explicitly represented, such as operations and attributes, that does not mean that these constraints do not exist. It simply means that in this particular model for this purpose it was not necessary to represent that constraint. Figure 4.21 shows several objects with explicit representations of attributes and operations. If the class element is represented explicitly, it has by default three compartments. The top compartment is the name of the class; the second compartment is a list of the attributes of the class. Each attribute represents state information, which may be public or private. The state information can include representation of data type and default initial values. The third compartment contains operations by default. The operations are identified by their visibility, whether they are public or private, the operation name, a parameter list, and a return type. All of these may be optionally included except for the operation name, which is required.

The static structure diagram is the most important part of UML to understand properly, because it is the richest set of descriptive features in UML and is useful for virtually any application of modeling static structure and constraints. Component diagrams are another type of static representation. Figure 4.22 is an example showing various components and dependency relationships between them. Component diagrams are analogous to the computational viewpoint objects that we described earlier. Component objects are software modules that have interfaces and dependencies upon other computational objects. Figure 4.22 shows the computational objects as rectangles with interface components.

Deployment diagrams are another form of structural representation. They are very simple and may not be sufficiently sophisticated for many of your modeling needs. We recommend the use of static structure diagrams when complex constraints need to be represented. Deployment diagrams include processor symbols, which represent independent computing elements, and device symbols which represent dependent computing elements such as peripherals. Figure 4.23 is an example of the deployment diagram. The processing elements have shaded surfaces and the device elements do not. There are associations between these deployment objects that represent various kinds of physical connections. Dynamic modeling diagrams include state chart diagrams and interaction diagrams.

Interaction diagrams come in two flavors, and these diagrams are isomorphic. In other words, for any given collaboration diagram, there is an equivalent sequence diagram which contains the same information represented differently. This applies in the reverse direction as well. Collaboration diagrams resemble ordinary static structure diagrams except that we are representing the dynamic time-base behavior of a set of objects which is executing. Within these diagrams we have ordinary UML objects, which have underlying names and messages that are directed associations between these objects.

Figure 4.24 is an example showing an execution sequence and the order of messaging of this information exchange between the object and the purchasing system. The order of object message transmission is indicated by a numbering sequence, one, two, three, and so forth. These imply a time-based dependency between these messages and how they interact with the information objects. Sequence diagrams, another very important form of UML notation, are used to convey the details of use cases and how use cases will operate as well as showing the description of the system in a manner that is readily interpreted by most users.

Sequence diagrams, like collaboration diagrams, contain objects which are rectangles with underlying names in the notation. Figure 4.25 is an example of the sequence diagram showing the purchasing system completing a purchase transaction. Notice that the messages and objects in Figure 4.25 correspond exactly to the transaction that we represented in the collaboration diagram in Figure 4.24. Each object has a dashed line extended from it which runs down the paper. This is the object life-cycle line and represents the time when the object is actively processing a particular message. The object life-cycle line runs down the page in increasing time so that we see a chronological progression of messaging between the objects.

The final type of UML diagram is the state chart. State charts represent control flows that cause state transitions. Typically, state chart diagrams represent the state of a single object and the transition between these states as the object executes. Figure 4.26 is an example of a state chart diagram for our purchase system example. In this case we are representing the states of the buyer object. The state chart represents several decision points and their representative states which are significant to the object's functioning. These states can be used to determine the overall structure of the source code for this object.

"If you can't explain it in five minutes, either you don't understand it or it doesn't work" [Rechtin 97].