Previous Section Next Section

The Approach

Typically, the approach at this point in the development cycle is straightforward. Similar to the business-level modeling, for each of the system use cases a textual flow of events should be developed (in much more detail than what was done in use case development), followed by a sequence diagram. From these a class diagram will be developed. But how do you go from the use cases and sequence diagrams to a class diagram? Development approaches that start at the system level (that is, no business modeling) usually have very general guidelines to 揹iscover?the candidate classes for the class diagram. While these guidelines can work and are simple to understand (for example, 揚ick out all the nouns in the problem statement and make them the candidate classes? it often produces a class model that poses many questions, especially for the developers who are new to this type of approach.

However, having done the earlier business-level work, the EAB team will have an advantage. Previously we saw how the information from the business models can be used to 損reload?the system use case model, thus giving that model's development a jump start. Now we will see the same effect as information from the system use case model is used to jump-start the development of the class diagrams of the system. For example, since we used sequence diagrams to elaborate the business object model, these can be brought forward to provide a framework for more detailed sequence diagrams for the system model.

Involving the Database Team

Similarly, concepts used by the database developers can be used to jump-start your class model. Many database developers work with the concept of user views. These views basically depict how the various users access the data to accomplish the task at hand. Indeed, one could argue that a user view is a simpler form of a business object model.

Database Designer

As the sequence diagrams are updated or newly created, ensure that they are elaborated well because they too may serve a dual purpose. Once your database design is created, the sequence diagrams can be used to validate your database design to ensure that the database can support the needs of the users. After all, the sequence diagrams are a good depiction of the data used, in what sequence, by the users as they execute a 搕ransaction?with the system. During detailed database design, tables may be merged, split, or deleted. Does the data the users need still exist and can they get access to it? The sequence diagrams can help you validate the database before you go 搇ive.?Sequence diagrams also help you begin to understand the need for indexes. By understanding how the communication among objects occurs, and eventually among tables through sequence diagrams, you get a preview of what columns are accessed and how often and where indexes may be suitable.

Why not build the user views from the existing business models we have developed and use them as the start of the class model? Such initial class models will have only passive classes in them, but that is all right since they are serving only as a framework upon which to build梐nother jump start. An additional advantage to this approach, if you are using visual modeling tools to automate your design process, is that all of the relationships among these elements being brought forward will be maintained and the integrity of the design will remain intact.

Previous Section Next Section