OO Programming  «Prev  Next»
Lesson 6

OO Design Process Conclusion

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:
  1. List some differences between traditional and object-oriented programming
  2. Generate a list of possible classes in your system
  3. 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 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
Define Domain Model


For example, a partial domain model is shown in Figure 2-3
Define Domain Model
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:
  1. 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.
  2. Object based:A program, such as Visual Basic, which supports classes and data abstraction but not inheritance or polymorphism.
  3. Object-oriented language:Programming languages that support the inclusion of both data and methods in classes.
  4. 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.
  5. 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.
  6. 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

SEMrush Software