Activities and the Other Columns
Activities and the Other Columns The techniques discussed in this chapter primarily describe activitiesColumn Two elements. The external entities of data flow diagrams and the performers of processes are borrowed from Column Four (people and organizations). Data flows and stores in data flow diagrams (as well as interest by the object-oriented among us) show that Column One (data) is clearly involved in any activity modeling. The events described in Chapter 7 define essential processes. The locations in Chapter 6 provide a place for activities to take place. And the business rules described in Chapter 8 are constraints on data, but they are often expressed in terms of the activities which implement them. Activities and DataThe fact that an activity has data being fed to it on one side and produces data on the other is significant to understanding both the nature of the data and the nature of the process. Naturally, an activity diagram focuses on activities and transformations of inputs into outputs. It may not be clear from an activity model, though, whether the same data element is used by more than one activity. Especially for object-oriented design, which is oriented toward the data classes, this input/output documentation is not sufficient. If data stores are resolved to the level of object class, however, this is less of a problem, since, for each entity, you could then see either how it is produced or how it is used. Still, there are better ways to capture this information. Enter the function/entity matrix. The function/entity type matrix is a straightforward approach to linking activities and entities. Entities are lined up along one dimension of a matrix and activities are lined up along the other. It is sometimes called the CRUD matrix because, in each cell , you designate whether the entity is (C)reated, (R)etrieved, (U)pdated, or (D)eleted by the activity. Any business rule that is controlling the creation, retrieval, update, or deletion operation can be specified via the cell's annotation. (See Table 4.4 for an example.) Once this is done, the report sets the stage for an object-oriented implementation of the functions associated with each entity. From the communications among the functions associated with an entity, you can then infer the communications between the entities themselves in the object-oriented sense. Of course, creation of a function/entity type matrix is also an excellent cross check, because any entity types without activities to at least create and retrieve them are suspect, as are any activities that don't do anything with any data. Table 4.4. A Sample Function/Entity Type Matrix
Activities and LocationsWhere in the world does each activity take place? Is it always in one location, or is it replicated across the country (or across the world)? There are no formal graphic models for representing this (although creative use could be made of maps and matrices), but certainly the documentation behind each activity should do so. Examining the function hierarchy or the essential data flow diagrams from Chapter 4, we can look at each function and ask, "Where does it take place?" This is especially significant if our model is a variation on a data flow diagram, where the processes communicate with each other. Two processes that must communicate between different facilities have profound implications on the kinds of systems that can be built to support them. Each activity diagram (in whatever form), then, can be annotated as to the location or site where the activity takes place. Grouping activities by site is a useful way to understand the geographic architecture of any prospective system. Indeed, rather than representing actors, swim lanes could represent sites or geographical areas. Activities and PeopleWe have already seen that an important part of documenting activities is documenting who does each of them. Data flow diagrams at least show external entities that are people and organizations who are supplying or consuming information. They may also show the actor in each activity. The use cases that are now so popular go to the heart of the interaction between people and the activities of a business. Chapter 6 discusses use cases further. All of the activity modeling techniques (except for the function hierarchy) described in this chapter to support Row Two include references to the people or organizations performing the functions. Data flow diagramming and process modeling were described because these techniques emphasize what is being done; use cases were described in this chapter because they are concerned with the nature of the interaction. Indeed, all three of these techniques belong firmly in both columns. The activities should also be classified as Stafford Beer's System One, Two, Three, Four, or Five activities. (See Chapter 5.) Activities and Timing (Events)The secret to understanding the true nature of the functions of an organization (uncluttered by the current mechanisms in place to perform those functions) is the event as a stimulus. Recall that in several modeling techniques it was significant that communications could be either simple data or messages (triggers, events) causing an action to take place. Functions can also be divided and organized in many different ways, but the set of event types that can affect a company ultimately must be the basis for any rational organization of those functions. Activities and MotivationAn organization's mission, strategies, and tactics form the structure around which its activities are organized. These, therefore, are the top levels of any hierarchical representation of activities. As will be shown in Chapter 8, business rules are normally defined in terms of constraints on data not on processes. We have seen, however, that the detailed documentation of activities can reveal business rules. Indeed, they are often implemented by activities and restrictions on activities. The activities and the business rules must be documented together. |
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 129