Home > Articles

Object-Oriented Analysis and Design

  • Print
  • + Share This
Just knowing an object-oriented language isn't enough to create object systems. You also have to learn to "think in objects." This chapter explains why it's important to understand what it means to truly be "object-oriented" and how you can build your business by using object-orientation from top to bottom.
This chapter is from the book

Le temps est un grand professeur, mais malheureusement il tue tous ses élèves (Time is a great teacher, but unfortunately it kills all its pupils.)

Hector Berlioz


  • Describe the book goals and scope.

  • Define object-oriented analysis and design (OOA/D).

  • Illustrate a brief OOA/D example.

  • Overview UML and visual agile modeling.

1.1 What Will You Learn? Is it Useful?

What does it mean to have a good object design? This book is a tool to help developers and students learn core skills in object-oriented analysis and design (OOA/D). These skills are essential for the creation of well-designed, robust, and maintainable software using OO technologies and languages such as Java or C#.

The proverb "owning a hammer doesn't make one an architect" is especially true with respect to object technology. Knowing an object-oriented language (such as Java) is a necessary but insufficient first step to create object systems. Knowing how to "think in objects" is critical!

This is an introduction to OOA/D while applying the Unified Modeling Language (UML) and patterns. And, to iterative development, using an agile approach to the Unified Process as an example iterative process. It is not meant as an advanced text; it emphasizes mastery of the fundamentals, such as how to assign responsibilities to objects, frequently used UML notation, and common design patterns. At the same time, mostly in later chapters, the material progresses to some intermediate-level topics, such as framework design and architectural analysis.

UML vs. Thinking in Objects

The book is not just about UML. The UML is a standard diagramming notation. Common notation is useful, but there are more important OO things to learn— especially, how to think in objects. The UML is not OOA/D or a method, it is just diagramming notation. It's useless to learn UML and perhaps a UML CASE tool, but not really know how to create an excellent OO design, or evaluate and improve an existing one. This is the hard and important skill. Consequently, this book is an introduction to object design.

Yet, we need a language for OOA/D and "software blueprints," both as a tool of thought and as a form of communication. Therefore, this book explores how to apply the UML in the service of doing OOA/D, and covers frequently used UML.

OOD: Principles and Patterns

How should responsibilities be allocated to classes of objects? How should objects collaborate? What classes should do what? These are critical questions in the design of a system, and this book teaches the classic OO design metaphor: responsibility-driven design. Also, certain tried-and-true solutions to design problems can be (and have been) expressed as best-practice principles, heuristics, or patterns—named problem-solution formulas that codify exemplary design principles. This book, by teaching how to apply patterns or principles, supports quicker learning and skillful use of these fundamental object design idioms.

Case Studies

This introduction to OOA/D is illustrated in some ongoing case studies that are followed throughout the book, going deep enough into the analysis and design so that some of the gory details of what must be considered and solved in a realistic problem are considered, and solved.

Use Cases

OOD (and all software design) is strongly related to the prerequisite activity of requirements analysis, which often includes writing use cases. Therefore, the case study begins with an introduction to these topics, even though they are not specifically object-oriented.

Iterative Development, Agile Modeling, and an Agile UP

Given many possible activities from requirements through to implementation, how should a developer or team proceed? Requirements analysis and OOA/D needs to be presented and practiced in the context of some development process. In this case, an agile (light, flexible) approach to the well-known Unified Process (UP) is used as the sample iterative development process within which these topics are introduced. However, the analysis and design topics that are covered are common to many approaches, and learning them in the context of an agile UP does not invalidate their applicability to other methods, such as Scrum, Feature-Driven Development, Lean Development, Crystal Methods, and so on.

In conclusion, this book helps a student or developer:

  • Apply principles and patterns to create better object designs.

  • Iteratively follow a set of common activities in analysis and design, based on an agile approach to the UP as an example.

  • Create frequently used diagrams in the UML notation.

It illustrates this in the context of long-running case studies that evolve over several iterations.

01fig01.gifFigure 1.1 Topics and skills covered.

Many Other Skills Are Important!

This isn't the Compleate Booke of Software; it's primarily an introduction to OOA/D, UML, and iterative development, while touching on related subjects. Building software involves myriad other skills and steps; for example, usability engineering, user interface design, and database design are critical to success.

  • + Share This
  • 🔖 Save To Your Account