In past columns we introduced and defined the basic language of object-oriented technology: inheritance, polymorphism and encapsulation. All three of these terms are used to describe design principals of application programming. However, there is more to building an application than just knowing design principles.
To build an application, you’ll need an understanding of the necessary steps. Just as you can’t run until you walk, you shouldn’t write code before you can design. The steps of building an application are called the development process, or methodology.
There are entire college courses that teach several application-development processes. Many tomes and countless articles discuss the development process in great detail, and these processes are evolving every day. It is important to find the process that works for you. This installment of Hooked on Objects will present an introduction to a development process that has proven its merits over several years. This should not be the end of your research on this topic, but merely an overview of a particular application development process.
The application objective
The first step toward creating an application should be the creation of its application objective statement. An application objective statement describes the goals of the application and what benefits it will offer. The statement should be less than a page in length and written in plain, simple language. The intent of the application objective is not to describe every piece of the problem right from the start. The development process encourages exploration of the problem domain (fancy words to describe the business issues associated with the problem) and the expansion of the problem statement.
WineTracker
To further explain the topics in this article, we will explore a fictitious application. Along the way we will introduce concrete examples of the abstract concepts that are presented. Let’s call this application WineTracker.
When we have a dinner party, we want to serve a wine that pairs well with the food. Unfortunately, we can’t always remember what wine goes with what dishes and whether we happen to have the desired bottle in the cellar. We’ve decided to turn to software to overcome this “business problem.” The application objective might begin with something as simple as the following:
“Provide a simple way to determine which wine in the collection would go with the dinner menu.”
Object-oriented analysis
Object-oriented analysis (OOA) is a term used to describe exploration of the problem domain. The first step to success is a clear understanding of the problem. The definition of use cases (see additional resource) and the creation of an analysis object model are two common activities that enhance an understanding of the problem domain.
A user-centric description of the problem through use cases helps the analysis focus upon what the application is supposed to do, not how it is supposed to do it. Use cases allow us to define how a user will interact with the application to accomplish a specific task. All too often design and technology decisions are made during the problem analysis, where in fact the analysis should attempt to be technology-independent.
Within the WineTracker application, we’ve quickly identified two use cases:
Use Case 1: “Track the contents of our wine collection from any Web browser.”
Use Case 2: “Find the bottle of wine that is right for our meal.”
Both use cases are very broad in scope. We could spend more time analyzing and improving the use cases, but that always will be true. Begin identifying use cases with broad statements and work down to detail when needed; don’t get tied down with all the details up front.
Notice these use cases specifically avoid mention of how the application is going to track and store the wine collection data. Although we do say we want to use a Web browser, in this case the Web browser is a user requirement. Including technology decisions in a use case should be avoided unless they are a part of the user’s wishes.
The next step of object-oriented analysis is the creation of an analysis object model. This model will contain the objects we identify as relevant to the application objective. With the use cases and the application objective in hand, we identify the initial application objects.
It is likely that many of the nouns in the application objective and use cases will end up as objects in your object model. In the use cases, we identified the following objects: “wine collection,” “wine bottle” and “meal.” We also want to represent ourselves as the actor, whom we’ll call “wine collector.” The analysis model will illustrate not only the objects we identify, but also the relationships that exist between those objects.
In the physical world, a wine collector has a wine collection. A wine collection has many wine bottles. A wine bottle is appropriate for a meal. In the OO world we often use pictures to represent our objects and their relationships to each other (see Figure 1).
It is not required that all objects in the analysis model end up in the actual implementation. In fact, an object analysis model could be used for development with any programming language, not just OO languages. It’s simply a starting point for application design.
Technical architecture analysis
Before design can begin, it is necessary to address those requirements that are not related to the user’s wishes. With a greater understanding of our business problem, we are ready to analyze our system for technical requirements.
It is insufficient simply to design a system to solve a business need if we don’t take into account the architectural development issues. Common issues include security, hardware, accessibility, risk, difficulty, maintainability, etc. The good news is that these common services can be developed using OO technology in a way that makes them reusable. There is no need to completely reinvent a security service for every business application under development.
Object-oriented design (OOD)
Object-oriented design (OOD) is the process of figuring out the how of the application, and experience is an important factor in creating a successful design. A good design will account for current application objectives, probable future enhancements to the current goals, expected application maintenance issues and architectural decisions made in the previous step.
There are proven object designs to many of the common design issues encountered in OO application development, several of which have been published in books and online as design patterns. Studying design patterns is a way for one to gain the expert knowledge that already has been discovered in OOD.
During OOD the object analysis model migrates to an actual object design model. Some objects will be removed, new objects will be added and attributes and behaviors of objects will be discovered. An object design model is often referred to as a static model because it represents the way objects can relate to each other.
So, how might all of this apply to WineTracker? First, look at the analysis model, problem statement and use cases listed above. Through examination of our previous work, we identify the actual objects our application will create. The four objects that we are going to consider are the WineCollector, WineCollection, WineBottle, and Meal.
The application is required to support multiple users with access from any Web browser. The user of the application — and information about that user — will be identified to our application code as the WineCollector object. To distinguish one wine collector from another, let’s assign an attribute of “name” to the WineCollector object. (For clarification, an attribute is a characteristic of an object. Examples of attributes of a person are eye color or hair color.)
The WineCollection object in the analysis model represents a relationship between the WineBottle and the WineCollector objects. It can be argued that WineCollection should be an actual object, or that a simple attribute on the WineBottle or WineCollector objects could represent the relationship.
The decision to use an object to represent the relationship should be made if you will want to know information about the relationship. If an object were used to represent the Wine Collection, it would be this object that could be used to maintain information about that relationship.
Perhaps there is a desire to know when the collection was last updated. If the relationship was not an object, this information could be placed on one of the other objects, such as WineCollector. But we’ve decided this detail is not really an attribute of a WineCollector, but rather an attribute of the collection itself.
The analysis of the Meal and the WineBottle objects is not as easy as the previous examples. Your idea of the relationship between a bottle of wine and a meal could be different from ours.
Exploring the relationship reveals several questions unanswered in our analysis. Does a bottle of wine relate to a meal? Or does a bottle of wine associate with the spices in the meal? One analysis may result in simply matching the color of a wine with the food type, such as “red wine with meat.” Another valid analysis could select bottles of wine based upon price, pairing an expensive bottle with steak and lobster but an inexpensive bottle for pasta.
It’s a given that there will be holes in the initial analysis, and that’s OK. By focusing on the design, we have discovered a weakness in the analysis. Now the analysis must be revisited. It is through a greater knowledge of the needs of the user that we will find the guidance needed to sort out the relationship between the meal and the bottle of wine. Failure to revisit the analysis could result in a system that is great at finding a cheap bottle of wine but fails to meet the expectations of the user.
The act of revisiting previous steps in the development process is often called iteration. It is natural to revisit the analysis, design and even the actual application code. The biggest challenge to overcome with iteration is the idea that you are never really done with analysis or design.
Let’s update the use cases to clarify our previous problems:
Use Case 1: “Track the contents of our wine collection from any Web browser.”
Should really be changed to:
Use Case 1.1: “Open a Web browser to the application and identify ourselves.”
Use Case 1.2: “Add new wine bottles to the collection and describe the aroma, color and particular food items for which the wine bottle would be particularly appropriate.”
Use Case 1.3: “Record that we have used a bottle and it is no longer a part of the collection.”
Use Case 1.4: “Select a wine bottle from the entire list of bottles and record that we have purchased another one. “
By revisiting your use case, you will discover more objects, attributes of existing objects and behaviors of the system. The use cases will evolve throughout the application development and every feature of your system should be traceable to a “use case” or architecture requirement.
Dynamic models
Static models are only half of the design. Dynamic modeling is a necessary step to complete the design process. Static models represent the relationships between objects; dynamic models reveal the interaction of objects when accomplishing a particular task. It is through the dynamic modeling that behaviors of objects are discovered. There are many different dynamic-modeling techniques and many different dynamic models, each with their own merits.
Sequence diagrams are one of the most common dynamic models. A sequence diagram will show the interaction between the objects in the model. They are very specific because they are intended to show the object interaction for a specific use case.
Use Case 1.2: “Record that I have used one of my bottles and it is no longer a part of my collection,” could be described in the sequence diagram in Figure 2.
This simplified sequence diagram illustrates that the user interface first obtains a reference to the WineCollection through communication with the WineCollector object. The method removeBottle() is sent to the WineCollection, which then sends the method drink() to the WineBottle.
Now it is time to begin programming. Several modeling tools that are currently on the market will actually generate the objects and their methods from your design models. Not only is analysis and design a very important step to understanding the problem, it can also jump-start the actual object creation.
That should serve as an introduction to the overall process of application development. There are many other issues relating to the development process such as testing, variations of the models, diagram semantics and application deployment.
———-
David Hoag is vice president-development and chief object guru for ObjectWave, a Chicago-based object-oriented software engineering firm. Anthony Sintes is a Sun Certified Java Developer and team member specializing in telecommunications consulting for ObjectWave. Contact them at hob@objectwave.com or visit their Web site at www.objectwave.com.
