Design Experience Report

Group 9

 

This document describes the group's experience using the various design techniques we learned in CS-552. First, we describe how we applied each approach during the development of our course project, a derivative of the well-known Battleships game. Then, we discuss our opinions of the technique. Finally, we analyze what we consider to be the pros and cons of each method.

 

Noun/Verb Analysis

 

Usage

At the start of the project we did an extensive noun/verb analysis. We poured over the game description and came up with several pages of potential domain participants. Then, we eliminated the participants that did not seem useful or we duplicated elsewhere in the analysis. This left us with a very large list of domain members.

 

Opinion

This technique was very helpful in creating a large domain. This gave us a lot of ideas for our initial domain model. The members that were generated here ultimately became our classes and objects. This technique shaped our entire design and it forced the implementation to directly match the game concepts.

 

Technique Pros/Cons

This technique is a good starting point to aid in determining what the domain will be and is very helpful in broadening the domain. It ultimately has a significant impact on the design direction.

 

Using this technique can be a time consuming effort. A large number of the nouns and verbs from our initial analysis were never used. It does not help to define some of the internal classes that are needed to make the game work. At this stage, most of the concepts are still very vague so it is hard to determine the usefulness of each participant.

 

 

CRC Cards

 

Usage

We did not use CRC cards in the development of our class project.

 

Opinion

CRC Cards appear to be a very useful technique. We just learned about them too late in the process to make effective use of them.

 

Technique Pros/Cons

This technique appears to be very helpful for determining how the domain participants will interact. It provides a way to communicate a vision of how each of the use cases will function in practice. It also helps to locate some domain participants that are more internal to the system, which may have not been revealed during the noun/verb analysis.

 

 

Class Diagrams

 

Usage

We made extensive use of class diagrams to develop a model of how our project would look. We developed an initial class diagram that represented our domain. Later, the model evolved into an implementation level diagram that was used to begin developing the game engine. A final class diagram was created to use as system documentation.

 

Opinion

Class diagrams are a very useful technique. They should be considered a required tool in object-oriented design and analysis. They really assisted us in the process of coming up with a solid design that could be carried forth into implementation.

 

Technique Pros/Cons

The diagrams do a great job of defining how the components are related. They provide a framework for how to think about the design. They also help communicate the design to other designers and developers.

 

Class diagrams do not provide much detail related to how the system will actually work. The notation is a bit cumbersome to learn.

 

 

Use Cases

 

Usage

We developed use cases at the beginning of the project to use as a guide in the rest of the design process.

 

Opinion

The use cases seemed to help initially determine how the system would work from the user perspective. Knowing what the user needs was helpful in designing the system. They we not particularly useful in the actual implementation. However, they came back into use for the testing phase as a check to verify that the final system matched the user expectations.

 

Technique Pros/Cons

Use cases are a good tool for determining what the user expects from the system. They are a good communication medium that ensures everyone has the same ideas about what the system will do. They ultimately provide a good measurement tool for determining how well the system meets the user's needs.

 

They are not suited to determining, in detail, what the system will do in response to a user interaction. The systems inner working are intentionally left out.

 

Robustness Analysis

 

Usage

We drew up a robustness diagram for each use case.

 

Opinion

The purpose of the robustness diagram is to bridge the gaps between class and sequence diagrams. We have had previous experience with this transition and it can be challenging. However, in this situation, we would have been more comfortable going directly to sequence diagrams. We already had a good idea about how we wanted to approach the system. Therefore, the robustness diagrams were more of an exercise than a tool. We believe that there are many situations when these diagrams can be very useful.

 

Technique Pros/Cons

This technique is a good intermediate step between class and sequence diagrams. It is particularly useful for large or complex class diagrams. The rules for component interaction are useful for approaching the design. They force you to think about aspects of the system that may not have been considered. These diagrams are especially useful for determining what internal classes may be needed to make the design function correctly.

 

The notation is not intuitive. For smaller projects, they may not be as useful because the designs are more straightforward.

 

Sequence Diagrams

 

Usage

We mapped out a large number of processes using sequence diagrams. All of our use cases and robustness diagrams had associated sequence diagrams.

 

Opinion

We consider these diagrams another essential part of good object-oriented design. They do an excellent job of communicating how objects interact. We found them to be invaluable for hashing out the way the program would work and sharing that information with multiple developers. This way everyone has a solid understanding of how the system will function before beginning coding.

 

Technique Pros/Cons

Defining how the objects communicate is an important step that the sequence diagram handles well. It illustrates important information about how the program will work. As with other design tools, it provides a good framework for determining how the system should be set up.

 

This is strictly a development tool. The notation is likely too complex for use with clients. It also does not necessarily describe what each message will need to do. You need to get to pseudo-code level to get a real idea of what each message does.

 

 

Design Patterns

 

 

Usage

We made use of Design Patterns whenever possible in our application. There are several instances of the Singleton and Observer patterns.

 

Opinion

We found the design patterns to be a very important. Knowing about the available patterns before undertaking the project helped us incorporate them into our project when they made sense. Unfortunately, we were only aware of a handful of patterns and only intimately familiar with two patterns. This meant that there might have been other opportunities to take advantage of patterns that we did not consider.

 

Technique Pros/Cons

Having a good understanding of the various design patterns helps ensure that you do not spend time trying to solve problems that have already been solved. They provide a cookbook of typical solutions that have been applied in many situations.

 

The downfall is that you really need to know about them in advance. The only way to know about them is study each pattern in some detail. You never know if there is a perfectly suitable pattern that you either do not know about or cannot locate.