One of the issues with object orientation is the very fact that it is relatively new to us. Because of its newness we are almost constantly encountering problems that require a good deal of thought to surmount. This paper is designed to expose one of the many aspects of object-oriented development, analysis and design, and to help us to find a path through that jungle.
The method of analysis and design that we will examine is called the Iterative Approach. It gets this name because the entire development process is accomplished through a series of iterations each encompassing the entire process from analysis through testing. During each of these iterations we are able to feed back information to the earlier phases of the project.
When to use an iterative approach
Martin Fowler, in his book "UML Distilled" (available at www.amazon.com), says "You should use iterative development only on those projects that you want to succeed." He is not exaggerating. There is no one who can assuredly complete any phase of the development cycle in a single pass. There are simply too many details to address at each stage of development. A methodology must be used that not only allows revisiting earlier stages, but that encourages it.
The iterative methodology does just this. It requires that large projects be broken up into smaller pieces and that each piece be developed through an iterative process of analysis, design, implementation, and testing.
Why do iterations?
Iterations allow us to focus on a subset of the complete project as we work out the details. We will often discover new problems and requirements during the process of building one of the subsystems. These new discoveries can be easily incorporated into a later iteration without requiring that the current work be discarded.
This process allows us to test each subsystem independently and assure its proper functionality. This means that when we reach the final stages of development, integration of the subsystems into a whole, we can focus the testing on the integration knowing that each subsystem has been fully tested already.
By working on the high-risk aspects of the project earlier we are able to reduce the influence of those risks on the overall project timetable.
During the implementation of the subsystems new use cases may be discovered. These new situations can easily be scheduled into a later iteration.
What is the Iterative Approach
The iterative approach is not something new and revolutionary. Many of us have been building systems this way for a long time. Martin Fowler classifies the phases of an iterative project as Inception, Elaboration, Construction, and Transition. Each of these phases constitutes a different point on the continuum to completion.
The project begins in the Inception phase. During this phase, which we will discuss in more detail later, we spend some time figuring out what the project is and whether doing it is a good idea at all. At the end of the inception phase we should have a fairly good idea of the scope of the project. The details have not yet been elicited, but the general vision of the system is there.
At this point we can make our first break up of the project into pieces. These pieces should be encapsulated enough to allow them to be built independently. Each of these pieces satisfies a subset of the complete system requirements.
A major advantage to this approach is that we can identify the risk involved with the project and apportion those risks in a managed fashion. This helps us to avoid, that so well known situation, having all of the things that could go wrong wait until the eleventh hour to begin failing. These risks can be spread across the project and dealt with independently.
Risks Categories
The risks that we face on a development project can be divided into four categories. Those categories are requirement risks, technological risks, skill risks, and political risks. Any project of a reasonable scope will have some risks associated with each of these categories. Ignoring or denying the presence of these risks is project suicide. These risks can only overcome the project if they are not managed. Managing risk requires knowing what the risk is and having a plan for dealing with it.
Let’s look at the risk categories.
Requirements Risks
The requirement category of risks includes those things that can jeopardize the early process of discovering the system requirements. We may build the best software system that anyone has ever seen for handling the logistics of toilet tissue for the armed forces of the USA, but if the need was for managing the membership of the local officer’s club our project would be a dismal failure.
Make sure we are building the right project, that is the main goal of managing the requirement risks. While this set of risks appears early in the process, it has the potential of eliciting the highest cost. Just imagine the amount of work (and cost) if we find out about the officer’s club on the day we were going to install the logistics application.
Use cases are invaluable in managing the requirement risks. Use cases will tell you the behaviors that system must accomplish. They will give a clear vision of how the system and the users will interact.
Develop a conceptual domain model of the business. The domain model should give you a clear understanding of what things with which the business interacts. A general concept of how the business works.
Then you can combine the use cases with the domain model to produce a design model.
By taking the time to identify the information needed to produce these models you will elicit detailed information from the users and business experts about the project. You will, thereby, reduce the requirement risks considerably.
Technological Risks
The first technological risk that comes to mind is related to object orientation. Is OO a new paradigm for you or your staff? If it is then there is a fairly large technological risk here. How will you deal with that risk? Will you budget for training for yourself and your staff? Will you allow for the retention of a mentor or consultant to be available for questions, meetings, and periodic system reviews?
What about the problem of new technologies? This new project requires that the reports all be published on a web site. That web site must allow for dynamic criteria for the reports. Hey, this web stuff will be fun, huh?
Yeah, lots of fun until you start trying to select the software and hardware you will use to meet the requirements. As you assess the quality of the various technologies you will need to incorporate into the project you will rapidly find that this is the next major risk.
What happens if you select the best web server software and the best remote database management software only to find out that they don’t work well together. You can be assured that any new technology you will use will cause you problems. Those problems will eat time on the project.
The solutions for these technical risks are similar to the requirement risks, training, mentoring, consultants with specific skills in those technologies.
Another method for minimizing the technological risks on the project is to build prototypes. Build many prototypes, especially for those aspects of the system that are using the most advanced and least understood technologies.
Skills Risks
Does your staff have the skills to accomplish this project? What will you do if the only person you have for the web stuff gets offered a job at ten times the salary you are paying him two weeks before the web part of the project begins?
What resources exist in the immediate area for outside help? You may need it at different points in the development.
Using a mentor can impact on these skill problems. Training is another item to consider. Again, periodic system reviews done by a recognized expert can be invaluable. Finally read as much as you can about the new technologies and provide an abundance of reading material to your staff in those areas as well.
Political Risks
Whether you want to believe it or not, every project is fraught with political risks. If you have no experience in dealing with these types of problems then get someone that does on board fast.
Political risks have the potential of completely destroying a project. Any company is full of people who have their own agendas and work very hard to realize them. Political risks can show up in any form from simple battles over the budget to downright sabotage.
You should be aware of the political environment in which the project will be carried out. Know your friends and enemies. Be aware of those folks who you can depend on to champion the project and those people who will, for whatever reasons, likely work against your efforts.
A very good book for learning a lot more about managing political risks is "Death March" by Edward Yourdan. The book is published by Prentice-Hall and has an ISBN number of 0-13-748310-4 (available at www.amazon.com).
The Phases
Let’s now work through the phases of an iterative project development cycle. You will recall that these phases are inception, elaboration, construction, and transition. We will discuss each of these in some detail. Keep in mind through the discussion that any one of these phases can be revisited at any point during the project’s development.
The first phase of inception will identify a set of subprojects to be built. Each of these subprojects will proceed through its own elaboration and construction phases. Finally the transition phase is where all of the subprojects are pulled together.
Inception
Inception is the beginning of the project. This phase can take on any of a number of different forms. It can be comprised of anything from an informal conversation over coffee to a series of well-structured meetings with a large number of people.
The purpose of this phase is to work out the rough overview of the project. Martin Fowler says, "Inception should be a few days’ work to consider if it is worth doing a few months work of deeper investigation during elaboration."
The goals of inception should be to get a good idea of the business case for the project. How much will this project improve the bottom line? Another goal is to get a feel for the scope of the project. How much will this project cost?
At the end of the inception phase the project’s sponsor has committed to no more than taking a serious look at the project.
Depending on the size of the project you may find yourself doing some degree of analysis in an effort to get a sense of the scope of the project during this phase. Inception can be anything from a brief conversation to a full-fledged feasibility analysis taking many months of work.
Elaboration
Once you have to go ahead to start the project you enter the elaboration phase. At this point you only have a very general idea of what the project is to be. Perhaps you can say;
"We will build a software application that will manage the activities of a bowling alley including the scheduling of lanes and leagues, the printing of league schedules, the scheduling of employees, the record keeping of cash collections, and the management of equipment maintenance."
Your requirements documentation may have a lot more text in it but it does not likely say very much more at this point.
The questions to be answered in this phase are, What are you actually going to build?, How are you going to build it?, and What technologies will you be using to build this?
The major focus during this phase should be on the risks that you will face. What are the things that could derail your project and how are you going to handle those? You should be identifying these risks according to how much of a potential problem they are. The bigger the risk the more attention you should pay to it.
These risks can be categorized into the groups described in the previous section. In order to find the risks you need to begin to do a detailed analysis and design of the complete system. The first place to start is with the domain model for the system. Once you have the domain model in place, then move onto to the use cases for the system, and finally combine the domain model and the use cases into a design model.
The Domain Model
The domain model is a very general picture of how the business operates. This model describes the world in which the system will exist. We need a conceptual image of the overall business, what it deals with, what things it does, how it does these things, and how all of this fits together. The domain model will show us this.
The domain model contains a minimal amount of detail. There may be many unconnected diagrams and these diagrams may be combined with freeform notes and comments. The domain model will lay the foundation for the more detailed models that follow. Figure 1 is an example of a domain model for a fictitious system.
Figure 1 – The domain model for a bowling alley management system.
Notice, in figure 1, that there is no detail inside of the identified objects. These objects are simply named and parts of their relationships are described. This model shows us a very general overview of the business and how it works.
The goal of taking this approach to development is that we will get a "big picture" of the system up front. By having this concept of the total package right from the start we can plan for the impact of each piece of the system on the other pieces.
When the domain model is in place we can proceed to identifying the use cases.
Use Cases
Martin Fowler describes use cases as "A typical interaction that a user has with the system in order to achieve some goal". Use cases provide a number of benefits to the developer. Use cases are stated as interactions that a typical user will have with the system, as such they are easily understood by the users and therefore provide for effective feed back from that group.
Use cases are the foundation for a functional specification, as they describe the things the system has to do from the perspective of the users. A use case may be a paragraph or two describing a specific activity the user will engage in with the system. Examples of use cases for a word processor might be, "make text bold", "italicize text", "copy text frorm one place to another", or "create an index to a document". These examples show that a use case can be a very small action or it can encompass a quite large and complex process.
Example of use cases for our bowling alley system might be, "The user needs to be able to schedule alleys for the leagues. There can be only one league for an alley at a given time. The time slot of a league game is 2 hours. Each league will have a number of alley’s that it requires for one set of league games", and "The user needs to print the schedules for each league". Again you can see that the range of complexity for these use cases varies greatly.
The text for a use case should be specific enough for the users to understand the idea of the case and for the developers to have an idea of what is involved in implementing the functionality.
Use cases are also diagrammed as can be seen in figure 2.
Figure 2 – A use case diagram.
In figure 2 you can see that the use case is represented by an oval with the name of the use case inside. The stick figure is called an actor and it represents the person or thing the uses the functionality. The actor may be a user or it may be another computer system or even a machine in a factory.
The use case diagram lets us see the overall picture of the use cases and how they fit together. Once we have the domain model in place and we have identified the use cases we can proceed to the design model.
The Design Model
The domain model identifies the objects that the system will encompass and the use cases are the activities the system will automate. The design model is the combination of these other two. This design model is also an abstract model in that it does not involve a high level of detail. The detailed diagrams will be produced later in the development cycle.
The purpose of this design model is to describe the combination of the information in the domain model and the behaviors of the use cases in a fashion that shows us how these things fit together. The design model also provides a reusable architecture that allows for future extensions of the system.
Figure 3 is an example of a design model for our bowling alley system. The model in figure 3 is far from complete; it is only intended to demonstrate the idea of combining the domain model with the use cases.
Figure 3 – A design model.
Notice that figure 3 has added the behaviors of the use cases to the objects of the domain model. This diagram will be expanded into actual class diagrams at a later time. Here we are trying to get a more complete overview of the entire system.
How far to go with diagrams?
When we read about system analysis and design we are constantly seeing different diagrams. There are diagrams for this and diagrams for that and what not. How many diagrams are enough and how many are too much? What else should we use besides these diagrams for communication?
Diagrams should be used when they add to the understanding of the system and they should be avoided when they cause confusion. Ward Cunningham said, "Carefully selected and well-written memos can easily substitute for traditional comprehensive design documentation. The latter rarely shines except in isolated spots. Elevate those spots…and forget about the rest".
What does this quote mean? Does it mean we should not draw diagrams? No, it means that the diagrams we do use should enhance our understanding of the system. If there is a diagram that does not enhance our understanding then we should do away with it. Most of the time a well-written memo can better and more clearly describe our point than a confusingly complex diagram. In those situations get rid of the diagram and write the memo.
When is the elaboration phase complete?
The elaboration phase of the project is finished when all of the risks associated with the project have been identified and plans for handling them exist. Along with all of the technologies having been identified and the models exist for domain, use case, and design. Also, the developers are comfortable in providing estimates for building each use case.
Each of the use cases will become one of the subprojects in the construction phase. This is where the iterations come into play. During construction we will build each use case separately and allow the experience of building each one influence the design of the others.
Construction
Once elaboration is complete we enter the phase of construction. In construction each use case will be handled as a project in itself being built through an analysis, design, coding, testing, and integration process. An iteration ends with a demo to the users of the completed subsystem.
During the construction of a use case we often will discover changes that are required to our preliminary design of other use cases. These discoveries are fed back into the respective use case designs. We may also discover new use cases that were never realized during the elaboration phase. These can be added to the project and scheduled for later construction.
As we complete the construction of each use case we will integrate it with the previously built use cases to work towards the fully integrated system. We may reenter the construction of previously completed use cases as the need arises. It is this process that gives this approach the name iterative development, as the complete system is built through a series of iterations on each subsystem.
Transition
Transition is the final phase of the iterative development approach. Transition handles those issues that were not addressed during construction. Perhaps there is some final integration to be done after all subsystems are built. A good example of a problem that would be addressed during transition is optimization for performance.
Optimization usually sacrifices clarity and ease of integration infavor of increased performance. This is not something that we want to do early in a project’s development as it will increase the difficulty in building the project. Instead we would leave optimization to the transition phase when all of the subsystems have been built and tested.
Optimization is also an elusive goal. Often we, as developers, perceive a performance problem where users will never notice it. We will also overlook a problem in performance that users will readily recognize. If we start optimizing a system before the users can tell us where it's slow we will be spending time and effort in the wrong places.
Transition can be thought of as that period of time between the release of the beta version and the final version of a project. There will likely be "bug fixes", functional enhancements, performance optimization, and other things done during this phase. Sometimes we may discover an entirely new use case that needs to be built. The iterative development approach allows us to easily process this new use case and then reenter the transition phase.
Summary
Object oriented analysis and design is often seen a huge package of complex diagrams that mean little or nothing to the users of a system. It is sometimes seen as a process that involves a large amount of theory and abstract conceptual models that really add very little to a project.
It does not have to be this way. Object oriented analysis and design can be a very pragmatic approach to system development. It does not have to be discrete phases that are never revisited. Using the iterative approach, this process can be a living and breathing aspect of system development. It can enhance our ability to meet the needs of the users and to control the risks associated with a project. When used effectively, the iterative approach can actually reduce the time required for building a project.
