Modeling Tips

A model captures the essence of a system or part of a system. Modeling, as part of the software development process, reflects requirements and guides design and coding. It is very much a creative activity that communicates at a profound level.

Here are some modeling best practices.

Multiple Models with Domain Model the Key

For all but the smallest of projects, creating more than one model will produce the best overall picture of a system. Think of the separate models as "views" of the system from different perspectives. Multiple perspectives provides a more informed vision. The models are less cluttered and more cohesive.

The most important model is one that shows the "real-world" concepts of the system, the domain model. The domain model is often reflected in many of the system's subsystems, for example, the storage and user interface subsystems. An automobile as an example domain would have concepts/classes for automobile, body, engine, brakes, etc. Real-world does not necessarily mean something you can touch, like a car. A domain model for a web server, an abstract system, would encompass server, requests, responses, files, etc.

What other models are useful? For software development, the next most important models are the execution and management models. The elements of these models provide the basis for running, controling and monitoring the system (see also below).

Here is a partial list of software models:

Domain: Depicts real-world concepts of the system. These concepts are the ones with which users of the system are most familiar. They are the most obvious, e. g. a file system has files,
Execution: What fundamental mechanisms control the system's software? Processes, messages, requests, whatever drives the system is modeled here.
Management: Logging, configuration, packaging, versioning, deployment all fall here.
Persistence: Storing to a file system, formatting XML, database support.
Authentication/Authorization: How are users authenticated? What can users access? Is a user allowed to modify an object?
User Interface: Elements of the model-view-controler show how the system's UI works. A web-based system might show pages, forms, widgets, etc.
Third-party Interface/Library/Subsystem: It is often helpful to model software with which the system will interact/use. Such models make the software easier to understand and program. Multiple models may be of benefit.

Important Concepts First

Work on the most important aspects of the system first, put aside detail. This is a matter of both focus and commitment. Focus is needed for careful examination of the system and accurate creation of model elements to reflect its state and behavior. Commitment is just as important because modeling will always entail conflicting and compeating requirements and demand answers to questions of including or excluding features.

Modeling works at such a conceptual level that each element of the model has enormous weight. Decisions at modeling time have far ranging implications for development resource consumption. That this is so is mostly good news as a model can quickly convey an overall picture. The fact that detials are glossed over, though, means plenty of work ahead and model reviewers must be understanding of this. For example, adding a tag class to a photo website system domain model implies requirements for mechanisms to store, search, and display tags, all from a single box!

Modeling stimulates creativity while providing some structure to help focus on the system and communicate with others. Remember that design will follow modeling and progress by elaborating the concepts of the model. It's more important to get the important things right than belabor the details.

Cohesive and Uniform Distributition

The best tests for the quality of a given model are:

Do all the classes work together to describe the system from the particular perspective of the model? The classes all operate together to compose the behavior of the system. If a class is involved to every interaction maybe it belongs to a different perspective. Classes that are not involved enough should be moved or removed as well.
Is functionality spread (mostly) evenly across the classes of the model? If a class is carrying a heavier load than other classes perhaps it should be divided. If a class is too thin maybe it should be removed from the model, moved to another model, or not shown. This also tests that only important aspects of the system are modeled.

Use the Building Blocks

These are the elements of modeling with Modeler:

classes		Classes contain all the state and behavior. Only important classes are shown and they have simple, direct names. Attributes and operations are not necessary except where deemed illuminating. Most important and containing classes should appear higher in the diagram. No utility classes!
relationships	is-a	Indicates generalization/specialization (place general on top). These relationships are very important as they show common behavior and code sharing possibilities.
	has-a	This type of relationship usually depicts some sort of containment, composition, ownership (owner or container on top), or long-term connection. Mark as composite if associated object is intregral to or owned by the aggregating object. It is a good idea to show the multiplicities. For clarification, the relationship can be labeled with a hint of the usage (read from top to bottom class).
	dependency	A class is dependent on another class if it uses that class, i.e. invokes operations(s) on it, but does not maintain a connection to the object after its own operation completes. As with has-a relations these can be labeled to provide usage hints (read in direction of arrow).