8.2. Our Object Modeling Process in a Nutshell
We present here a basic preview of the modeling process that we advocate and will illustrate in depth throughout the remainder of Part Two of the book:
Begin by obtaining or writing a narrative problem statement, similar to the Student Registration System (SRS) problem statement presented in the introduction. Think about the different categories of users that will be interacting with the system, and the various situations in which each will use it, to make sure that you uncover any not-so-obvious requirements that might have been missed. (We'll discuss a technique for doing this—known as use case modeling—in Chapter 9.)
Handle the data side of the application by identifying the different classes of real-world objects that your application will need to be concerned with and determine how they interrelate. (We'll illustrate the process of creating a class diagram in Chapter 10.)
Handle the functional side of the application by studying how objects need to collaborate to accomplish the system's mission, determining what behaviors/responsibilities will be required of each class. (We'll illustrate the process of modeling the behavioral aspects of an OO system in Chapter 11.) The emphasis of code development should usually be on behavior-driven design. After the desired behaviors are identified, many of the required classes will appear as a byproduct.
Test the model to ensure that it does indeed meet all the original requirements. (We'll discuss testing in Chapter 12.)
You'll see plenty of examples of each of these techniques in the chapters to follow and will get an opportunity to practice these techniques based on the hands-on exercises suggested at the end of each chapter. Armed with a solid model of the SRS, you'll then be ready to render the model into C# code, which is the subject of Part Three of the book.
Note that these process steps need not be performed in strictly sequential fashion. In fact, as you become comfortable with each of the steps, you might find yourself carrying some of them out in parallel, or in shuffled order. For example, contemplating the behavioral aspects of a model might bring to light new data requirements. In fact, for all but the most trivial models, it's commonplace to iterate through these steps multiple times, dialing in increased levels of understanding (hence more detail in the model and supporting documentation) with each iteration.
It's also important to note that the formality of the process should be adjusted to the size of the project team and the complexity of the requirements. If we separate the form of using a methodology from the substance of what that methodology produces in the way of artifacts—models, documentation, code, and so on—a good rule of thumb is that a project team should spend no more than 10 to 20 percent of its time on form and 80 to 90 percent on substance. If the team finds itself spending so much time on form that little or no progress is being made on substance, it's time to reevaluate the methodology and its various components to see where simplifying adjustments or improvements to efficiency can be made.
8.2.1. Thoughts Regarding Object Modeling Software Tools
It's worthwhile to spend a little bit of time talking about the pros and cons of using an object modeling software tool. For purposes of learning how to produce models, a generic drawing tool such as Microsoft Paint, Visio, or Eclipse can be good enough; for that matter, you might simply want to sketch your models using paper and pencil. But, getting some hands-on experience with using a tool specifically designed for object modeling will better prepare you for your first "industrial-strength" project, so you might wish to acquire one before embarking upon the next chapter. You'll find information about various object modeling software tools, including links to free or evaluation copies of software, at http://objectstart.com.
Object modeling tools fall under the general heading of Computer-Aided Software Engineering (CASE) tools, which afford us with many advantages, but aren't without their drawbacks.
8.2.1.1. The Advantages of Using CASE Tools
There are many arguments in favor of using CASE tools; several of the more compelling are as follows.
8.2.1.1.1. Ease of Use
CASE tools provide a quick drag-and-drop way to create visual models. Instead of trying to render a given notation with a generic drawing tool, in which your basic drawing components are simple lines, arrows, text, boxes, and other geometric shapes, CASE tools provide one or more palettes of prefabricated graphical components specific to the supported notation. For example, you can drag and drop the graphical representation for a class instead of having to painstakingly fabricate it from simpler drawing components.
8.2.1.1.2. Added Information Content
CASE tools produce "intelligent" drawings that enforce the syntax rules of a particular notation. This is in contrast to a generic drawing package, which lets you draw almost anything you like, regardless of whether it adheres to the notational syntax or not.
The controls imposed by a CASE tool can be a mixed blessing: on the plus side, they prevent you from making syntactic errors, but (as we discuss a little later) they might also prevent you from making desired adjustments to the notation.
Also, information about the classes reflected in a diagram—their names, attributes, methods, and relationships—is typically stored in a repository that underlies the diagram. Most CASE tools provide documentation-generation features based upon this repository, enabling you to automatically generate project documentation such as a data dictionary report, a type of report that we'll discuss in Chapter 10. Some tools even allow you to tap into this repository programmatically if you find a need to do so.
8.2.1.1.3. Consistency Checking
CASE tools can identify discrepancies between various design diagrams, such as a class in a sequence diagram that's missing from the class diagram.
8.2.1.1.4. Automated Code Generation
Most CASE tools provide code-generation capabilities, enabling you to transition from a diagram to skeletal C# (or other) code with the push of a button. You might or might not want to avail yourself of this feature, however, because the code that is generated might not meet team/corporate standards (depending on how much control the CASE tool gives you as to the structure that the generated code takes).
When you're first learning a language, it's sometimes better to write your code from scratch. You'll learn more about a given programming language and come up to speed on it faster if you do. Using a CASE tool or other integrated development environment (IDE) is a bit like riding a bike with training wheels. It's easier at first, but you don't really know how to ride a bike (or write code) until you take the training wheels off and do it yourself. It's the author's experience that you gain a lot by writing it yourself, particularly when it comes to processes such as learning how to debug code.
8.2.1.1.5. Project Management Aids
Many CASE tools provide some sort of version control, enabling you to maintain different generations of the same model. If you make a change to your model, but then decide that you prefer to return to the way things were previously after reviewing the change with your users, it's easy to do if version control is in place.
CASE tools also often provide configuration management/team collaboration capabilities to enable a group of modelers to easily share in the creation of a single model.
8.2.1.2. Some Drawbacks of CASE Tools
CASE tools aren't without their drawbacks, however:
CASE tools can be expensive; it's not unusual for a high-end CASE tool to cost hundreds or even thousands of dollars per "seat."
CASE tools can sometimes be inflexible—we talk about adapting processes, notations, and tools to suit your own needs throughout Part Two of the book, but tools don't always cooperate! We'll point out in upcoming chapters some specific examples of situations in which you might want to bend the notation a little bit if your CASE tool will accommodate it.
You run the risk of getting "locked into" a particular vendor's product if the CASE tool in question can't export your model in a vendor-neutral fashion (as XML, for example).
It's easy to get caught up with form over substance! This is true of any automated tool—even a word processor tends to lure people into spending more time on the cosmetics of a document than is warranted, long after the substantive content is rock solid.
Generally speaking, however, the pros of using an OO CASE tool significantly outweigh the cons—consider the cons as words to the wise on how to successfully apply a tool to your modeling efforts.
8.2.2. A Reminder
Although we said it several times already in this book, it's important to remind you that the process of object modeling is language neutral. We presented C# syntax in Part One of the book because our ultimate goal is to make you comfortable with both object modeling and C# programming. In Part Two of the book, however, we'll drift away from C# temporarily because you truly are at a point where the concepts you'll be learning are just as applicable to C# as they are to Java, or C++, or any other OO programming language. But, never fear—we'll return to C# "big time" in Part Three!