This module discussed the object-oriented design process.
You learned about the differences between traditional and object-oriented programming. You should now be able to:
List some differences between traditional and object-oriented programming
Generate a list of possible classes in your system
Narrow a list of classes, keeping only those that make good classes
Define Use Cases
Requirements analysis may include a description of related domain processes;
these can be written as use cases.
Use Case Workflow
Use cases are not an object-oriented artifact, they are simply written stories.
However, they are a popular tool in requirements analysis and are an important part of the Unified Process.
For example, here is a brief version of the Play a
Dice Game use case:
Play a Dice Game: A player picks up and rolls the dice. If the
dice face value total seven, they win; otherwise, they lose.
Define a Domain Model
Object-oriented analysis is concerned with creating a description of the domain from the perspective of classification by objects. A decomposition of the domain involves an identification of the concepts, attributes, and associations that are considered noteworthy.
The result can be expressed in a domain model, which is illustrated in a set of diagrams that
show domain concepts or objects.
Define Domain Model
For example, a partial domain model is shown in Figure 2-3
Figure 2-3 Partial domain model of the dice game
C++ as an Object-Oriented Language
If you are a C programmer, you may have viewed the features covered so far in this module as convenient additions to the C language.
As the name C++ implies, in many ways the language is just a "better C." There is one major point that this view overlooks.
Unlike C, C++ is an object-oriented language, which is a more natural way to write code. If you are used to procedural languages such as C or
Fortran, you will soon be able to understand this new paradigm.
You need to shift your mindset to the object-oriented paradigm. If you already know the theory of OOP, the rest of this course will help get you up to speed on basic C++ object syntax.
Glossary
This module introduced you to the following terms:
Class:The highest-level element in an object-oriented programs; classes contain both functions (methods) and data.
Collaboration: A class's interaction with other classes to carry out all its necessary responsibilities; needed when the class by itself does not know or can not do everything it needs to know or do. The final step in object-oriented analysis is to identify the class's collaborators.
Object based:A program, such as Visual Basic, which supports classes and data abstraction but not inheritance or polymorphism.
Object-oriented language:Programming languages that support the inclusion of both data and methods in classes.
Problem domain:What the problem is that your project is supposed to help solve. Defining the problem domain is usually the first step in design, whether you use a procedural or an object-oriented design.
Procedural language:Structured programming requires well-defined flow control. A programming language that supports well-defined flow control because of a heavy reliance on procedures.
Procedure:The highest-level element in procedural, or structured design; procedures define what the program does.
The next module will discuss some characteristics of an object and the benefits and uses of both structured and object-oriented design and programming.
Choosing Classes Quiz
Click the Quiz link below to take a short multiple-choice quiz on the material covered in this module.
Choosing Classes - Quiz
