The OOA applies an object-oriented view to the problem. The easiest way to do this is to pick out all of the nouns in the RAD. Each noun is usually an object. Through out nouns that aren't substantive objects. The next step is to write a detailed description of each object, no matter how trivial it may seem or how much you take this object for granted. Each object must be completely and succinctly documented. This is called a data dictionary. Next, look for overlap between objects and remove objects that are not important to the problem domain. For example, take out user interface components. You will deal with those separately. Once you have removed unnecessary objects, identify their attributes and methods. More often than not, you will find that some of the objects you have are merely attributes of other objects. Next, establish relationships between objects. For example, an employee works for a company. Here, both company and individual are objects. An individual works for a company. A company employs an individual. A company has many workers. An individual usually works for a single company. Here, we have both defining and numerical (cardinality) relationships. Find such relationships between your objects, and define the cardinality, eg. one-to-one, one-to-many, many-to-many.

The next step of the OOA is to do the same thing with your UIS. The user interface and underlying application subsystems should be completely independent of one another. In fact, you should be able to design and develop your interface and your underlying application independently of one another. You should make your user interface classes as generic as possible, and subclass off of them to get application-specific behavior. For example, to make a list of colors you would probably use a generic List object. A List has a series of text string labels for each choice, lets the user make a choice, activates some function when such a choice is made, allows the user to add an item to the list, delete one, and so on. So far, you could use this List object in almost any application that requires a List interface object. However, for a color selector, you may want to show the actual color in the rectangular slot where you usually show the textual name of the color. In this case, design the object hierarchy such that most of the functionality is encapsulated in the List object, but then subclass a ColorList class to present the colors rather than the textual labels. Design interactive objects in a similar way: allow an application to register actions with an object rather than defining that an object performs specific tasks. Most of the appearance and functionality is then abstracted away from the end user in a particular program. This way you can share an object between applications, and assign application-specific behavior with registration rather than explicit coding.

If you are not using an object oriented programming language like C++ or Java, you can still use object oriented design techniques. However, if you prefer, you can write a High Level Design document in place of the OOA. The HLD accomplishes many of the same goals, but from a non-OO approach.

The OOA has:

data dictionary defining exactly what each object represents (in English)
class diagrams showing the name, attributes, and methods of each class
relationships between the classes, depicting graphically and textually
a set of class diagrams and data dictionary for the application domain
a set of class diagrams and data dictionary for the interface domain
end-user readability

The HLD has:

detailed breakdown of technical solution in subsystems
descriptions of data structures and operations required for eachs subsystem
detailed interaction between subsystems, including interface subsystem(s)

The OOA and HLD do not have:

algorithms
implementation details
Software Documentation Guidelines


©2006 Ziost Technologies. All rights reserved. Terms of Use \| Privacy Statement \| Links