Analysis Model Structure

One of the first activities of the analysis team is to create the package hierarchy of the analysis model. As for any complex system, one natural way to attack the task of representing the problem and solution space in a comprehensible way is to "divide and conquer." The UML mechanism for this is the package. A package is nothing more than a "chunk" of the model, a piece small enough that one can understand its purpose and significance in the model. Packages contain elements of the model: classes, diagrams, components, interfaces, and so on. Every element in the model is owned by exactly one package. This does not restrain model elements from appearing in the diagrams of other packages or from participating in relationships of elements in other packages. Classes in a package can be made public or private. A public class in a package is visible to and can be used by elements outside the package. In a way, these classes represent the public interface of the package and should be chosen carefully.

Packages themselves can be divided into more packages, and hence it is possible for a model to be structured into a hierarchy of packages. The most important property of a package is that it should be comprehensible. It should be possible for a person to understand and to comprehend a package's purpose, significance, major elements, relations, and relations to elements owned by other packages.

Packages are rendered graphically as a tabbed folder. Packages have names that are unique throughout the model. Each package forms a namespace, meaning that two elements can have the same name as long as they are owned by two different packages. Packages can have relationships. The two types of relations are dependency and generalization. A dependency relationship typically means that one package depends on, or has structural knowledge of, elements in the other. This relationship is drawn with a dashed line and an arrowhead pointing to the package that the other depends on.

A generalization relationship is like generalization in classes; the subpackages represent specializations of a package. For example, a user interface package might have two subpackages: ActiveX-Enabled UI and Java-Enabled UI. Both contain elements that support the goal of providing a user interface, but each subpackage does so with a different architecture.

Throughout the process, the package can also be used to denote ownership. Typically, a package is "owned" by one analyst or designer. The classes with public visibility in the system represent the package's interface to the rest of the system. The designer is free to add classes or to alter the methods of private classes in the package without impacting the rest of the team. Changes in public classes and operations, however, need to be agreed on. A properly maintained model should be able to quickly answer the question, Who uses this class's public interface? Because packages are "owned" by team members, they are convenient units of version control and are checked out of the configuration management system by the analyst or the designer when they are being worked on.

Defining the Top-Level Model

During the use case definition activities, the use case model was divided into packages. During analysis, the same package hierarchy could be used to model the structural view of the system. It has been my experience, however, that the hierarchy of the dynamic view of the systemuse casesmay provide a start but usually falls short when defining the structural view of the systemclasses. The reason is that it is likely that certain objects participate in many use cases and packages and logically can't be assigned to a single use case package.

At the highest level, the packages are often the same, but at the lower levels of the hierarchy, there are often better ways to divide the packages. For example, the top-level use case view of an e-commerce system might comprise the following packages: Storefront, Billing, Inventory, and Site Administration. The top-level use case diagram is shown in Figure 10-2.

Figure 10-2. Top-level use case model diagram

This diagram could also be used for the top-level analysis model. At the lower levelsfor example, in the Storefront packageadditional packages may separate the principal functions of the system as available to the online user. The subpackages of Storefront (Figure 10-3) in the use case model might include packages for placing orders, tracking orders, and browsing the catalog.

Figure 10-3. Storefront use case package

On the other hand, the analysis model might have a very different Storefront package, with the following packages: Catalog, Shopping Cart, Customer Profile, and Product Customizations for engravings, color, and size. In the analysis model, the packages tend to represent things rather than actions. Dividing the analysis model to make it more manageable tends to place like thingsobjectstogether instead of behaviors.

A good way to start the analysis model is to begin with the top-level use case diagram packages. From that point on, it is best to examine the use cases and functional requirements from a fresh viewpoint and to divide the model according to similar things, or classes, of objects.

One of the most important things to remember when creating the initial package hierarchy is this: We use packages to help us manage the size and the complexity of the model itself, not what we are modeling. The intent of any model's structure is not to mirror or abstract the structure of the business but rather to structure the modeling elements that do mirror and represent the business structures. This is a very fine point and is often confused because for most systems, the business's structure happens to provide a convenient and coincidental structure for the model. If this point is not properly understood, problems will arise later in the development life cycle, when elements and packages get refactored and competing teams fight for ownership of common entities.

Ultimately, the use of packages makes the model understandable. When defining packages, you should strive to ensure that they are

• Comprehensible: An individual is expected to comprehend the package's semantics, reason for existence, major elements, and responsibilities.
• Cohesive: Logically speaking, the classes belong together. At some abstraction, all the classes in the package form a natural group.
• Loosely coupled: Generally, each class has more relations with classes in the same package than with classes outside the package.
• Shallow hierarchy: Deep hierarchies tend to be difficult to understand because each level carries its own meanings. It is best to limit the number of levels to two or three.

Starting with a good model structure is important. Because the top level and possibly second levels in the hierarchy are important for all members of the analysis and design teams to understand, this activity should be done as a group and with an experienced member of the team leading. Throughout the analysis process, team members will be creating more packages, which will be refactored often, until a relatively stable structure is achieved and serious design activities begin.

Analysis Elements

Whether building Web applications or distributed object systems, the activities of analysis are pretty much the same. Analysis focuses on the functional requirements of the system, so the fact that some or all of the system will be implemented with Web technologies is beside the fact. Unless the functional requirements state the use of a specific technology, references to architectural elements should be avoided.

Analysis begins with the analysis team's examining the use case model, the use case specifications, their scenarios, and the functional requirements of the system that are not included in the use cases. The team identifies objects and classes of objects that can collaborate to perform the required behavior of the system. Because so many books discuss objects, classes, and the principles of object-oriented software, this one will not dwell on the details of these concepts but instead will give an overview of techniques and approaches to use case analysis.

CRC Cards

CRC (Class-Responsibility-Collaboration) card exercises are a simple, low-tech way to identify classes and their responsibilities.[1] A CRC card is an index card that contains the name of a class, its responsibilities, and its collaborations, or relationships with other classes. A CRC card exercise is a team brainstorming exercise; members of the team come up with possible classes and define their responsibilities, not their attributes and operations. Classes are matched up to produce collaborations that achieve the goals mentioned in the use cases and requirements. For some, it is an excellent way to begin the process of class discovery; for others, not. If you are having a difficult time discovering classes or are getting bogged down with too many classes and their details, CRC exercises might be helpful.

[1] R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software (Englewood Cliffs, NJ: Prentice-Hall, 1990).

Role Playing

Role playing is another team-oriented mechanism useful in identifying and elaborating classes in a system. Team members play the roles of parts of the system. The roles can be users, the system itself, other systems, or even entities in the system. The group walks through scenarios in the use cases and discusses how the work of the system gets done. Each team member takes notes on the responsibilities of the role played. Role playing is often done alongside CRC card exercises.

Word Form Analysis

Word form analysis is another technique for identifying classes and objects. Use case and requirements texts are scanned for important nouns. These nouns indicate possible classes of objects. Verbs, on the other hand, indicate possible operations and processes. For example, consider the following use case fragment:

The customer tells the system that he is ready to check out. The system examines the contents of the shopping cart and produces an itemized list of all the items that are ready to be purchased. The customer confirms the order and tells the system to process the order.

Many important-sounding nouns would make good classes in the system: "customer," "shopping cart," "order," and so on. The verbs "check out" and "process" are also significant actions in the use case and are likely to be identified as operations on some of the objects.

Structural Elements

Ultimately, analysis identifies a preliminary mapping of required behavior onto structural elements, or classes, in the system. These activities begin with an examination of the use cases (Figure 10-4), especially the specification documents. At the analysis level, it is convenient to categorize all discovered objects into one of three stereotyped classes: «boundary», «control», and «entity», as suggested by Jacobson:[2]

[2] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach (Boston, MA: Addison-Wesley, 1992).

Figure 10-4. Browse Catalog use case

Stereotype	Icon
«boundary»
«control»
«entity»

Boundary classes connect users of the system to the system. In a Web application, these boundary classes are the Web pagesscreensof the system. Most systems, however, also have connections to external systemscontent management, merchant account, automated backup, and so onthat require boundary class interfaces. Control classes map to the processes that deliver the functionality of the system. Entity classes represent the persistent things of the system, such as the database. Entities are shared and have a life cycle outside any one use of the system, whereas control instances typically are created, executed, and destroyed with each invocation.

As a start, it is recommended to begin with one boundary and one controller per actor per use case.[3] With the introduction of a formal UX model, there is less emphasis on boundary classes in the analysis model, with the exception of boundaries to non-Web actors of the system. As a result, the emphasis during analysis is on entities and controllers. Figure 10-5 shows a first pass at the analysis model for browsing the catalog.

[3] This is, of course, an oversimplification but nonetheless provides at least a start when looking at a blank diagram.

Figure 10-5. First-pass analysis model for the Browse Catalog use case

In this early diagram, the most important elements are the class names, the types, and the relationships. Each class's details will soon be fleshed out by detailed examination of the use case specifications and related supplementary requirements. The class diagram in Figure 10-6 shows the first-pass diagram elaborated with operations and attributes. As a general rule, controllers don't specify attributes. Initially, their operations are based on the verb phrases in the use case specification and tend to represent functionality that the user might invoke. .Entity properties tend to be mostly attributes, although operations that organize an entity's properties can often be found on them

Figure 10-6. Elaborated analysis model elements

Behavioral Elements

The discovery and elaboration of analysis classes is helped by the construction of behavioral diagrams that form the model's use case realizations. A use case realization is an expression of a use case's flow of events in terms of objects in the system. In UML, this event flow is expressed with collaborations, each with a set of sequence and collaboration diagrams. Figure 10-7 shows the collaboration Browse Catalog Realization with a realization relationship to the use case Browse Catalog.

Figure 10-7. UML diagram showing a use case realization

A UML collaboration can realize a use case, describing the context in which the invocation of the use case executes. The collaboration describes the objects that are created, executed, and destroyed in order to execute the functionality described in the use case.

Development of the collaboration begins with the simple sequence diagram that was created when the use case was created (Figure 10-8). The System object in this diagram is replaced with the set of analysis objects in the analysis model. Messages corresponding to operations on the classes are drawn to correspond to the main narrative text alongside the scenario.

Figure 10-8. Browse Catalog use case basic flow expressed as a sequence diagram

Figure 10-9 shows the same use case scenario as Figure 10-8 does but expressed in terms of the analysis classes in Figure 10-6. I have found the exercise of documenting use case scenarios with rich collaborations an excellent mechanism for discovering early the missing and sometimes forgotten bits of required functionality necessary for the smooth execution of use case scenarios.

Figure 10-9. Browse Catalog basic flow sequence diagram elaborated with analysis objects

Collaboration diagrams are semantically the same as sequence diagrams. Nonetheless, each diagram expresses the information with a different view. Sequence diagrams focus on the time dimension: Everything is rigidly placed along the time axis vertically, from top to bottom. In collaboration diagrams, the focus is on object instances, not time. Objects in a collaboration diagram can be placed anywhere in the diagram, and a single line represents all messages from one object to another. Each message is numberedto preserve the time dimensionand they are lumped together on the one association between each object. Figure 10-10 shows the sequence diagram of Figure 10-9, converted to a collaboration diagram.

Figure 10-10. Semantically equivalent collaboration diagram of Figure 10-9

Sequence and collaboration diagrams in particular provide a critical link of traceability between the scenarios of the use cases and the structure of the classes. These diagrams can express the flow in a use case scenario in terms of the classes that will eventually implement them.

An additional diagram that is useful for mapping analysis classes into the use case model is the activity diagram. As a general rule, I create one activity diagram per use case; as a result, I have diagrams ready to elaborate with analysis controller classes. By definition, activities are an execution of behavior. Activities map reasonably well to controller classes, where each controller executes one or more activities (Figure 10-11).

Figure 10-11. Use case activity diagram elaborated with analysis objects