We present here a basic preview of the modeling process that we advocate, and which we're going to 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, or the alternative case study problem statements included as Appendix B. Think about the different categories of users that will be interacting with the system, and the various situations in which they'll each use it, to make sure that you uncover any not-so-obvious requirements that may 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 these 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.)
Test the model to ensure that it does indeed meet all of 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 may find yourself carrying some of them out in parallel, or in "shuffled" order. For example, contemplating the behavioral aspects of a model may 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—then a good rule of thumb is that a project team should spend no more than 10 to 20 percent of its time on form, 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 may be made.
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 PowerPoint may be good enough; for that matter, you may 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, and so you may 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.
We make it a practice not to mention specific tools, vendors, versions, etc., in this book, as they change much too rapidly. As soon as a software product is mentioned in print, we're virtually guaranteed that it will either change names, change vendors who market it, or disappear completely!
There are many arguments in favor of using CASE tools; several of the more compelling are as follows.
CASE tools provide a quick drag-and-drop way to create visual models. Rather than trying to render a given notation with a generic drawing tool, where 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 rather than having to painstakingly fabricate it from simpler drawing components.
CASE tools produce "intelligent" drawings that enforce the syntax rules of a particular notation. This is in contrast to a generic drawing package, which will pretty much let you draw whatever you like, 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 will prevent you from making syntactic errors, but as we discuss a little later, they may 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, should you find a need to do so.
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 may or may not wish to avail yourself of this feature, however, for the following reasons:
With most tools, you're unable to edit the generated code externally to the tool, because the tool will then be "unaware" of the changes that you've made, meaning that the next time the code is generated, your changes will be overwritten and obliterated.
This has implications for reusing code from other projects, as well: make sure that your tool of choice allows you to import and introduce software components that didn't originate within the tool.
It's sometimes better in the end to write your code from scratch, for even though it may take a bit longer at the outset, it often is much easier to manage such code over the lifetime of the project, and you avoid becoming "enslaved" to a particular modeling tool for ongoing code maintenance. In the worst-case scenario, the tool vendor goes out of business, and you're left with an unsupported product and perhaps unsupportable project.
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 after reviewing the change with your users decide that you'd prefer to return to the way things were previously, it's trivial 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.
Some CASE tools support multiple graphical notations, enabling you to initially create a diagram in one notation but to then convert the diagram to another notation quickly and effortlessly.
This doesn't always occur flawlessly, however; things can get lost in the translation if the two notations don't have a one-for-one match in terms of notational components; it's not unusual to have to do some minor cleanup after the fact.
Some tools even support customizable or "do it yourself" notational paradigms, should you wish to either embellish a standard notation such as UML or to invent a new notation from scratch.
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 where 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 (e.g., as XML).
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.
Although we've 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're going to drift away from C#, because we 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!