Lesson 1

Although there is a well-defined academic foundation for object-oriented concepts, most developers are not aware of it or would not know what to make of it if they were. Most of the work of analysis is driven by the concepts we will cover in this module. The diagramming notation will lend precision to diagrams, but the meaning and content must be assessed against the principles of good object-oriented modeling.
Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modelling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.

If you read through the software literature and textbooks, you will find that there are as many definitions of analysis, as there are authors. Ironically, analysis is something we know we must do; and yet have no real definition for. One of the most common ways to differentiate analysis from design is to say that analysis is "what" and design is "how". This sounds compelling at first. Clearly if we can first define "what" we want the system to do, then it will be easier to define "how" the system should do it. Indeed, vast quantities of man-hours have been spent attempting to separate the "what" from the "how". It is not uncommon for a conference room full of people to descend into the endless argument regarding whether what we are currently doing is analysis or design.
Arguments like this are common because of the peculiar fact that every what is also a how", and every "how" is also a "what". The arguments cannot be decided, because both sides are actually correct. If we use the "what" vs. "how" definition of analysis and design, then every concept that is an analysis concept is also a design concept and vice versa.
What and how are associated by an equivalence relationship that leads to a recursive descent into detail. Every "how" becomes the "what" at the next level of recursion. Every "what" is just the "how" of the level above it. The number of levels is very large, and probably infinite. This means that "what" and "how" are separated by only a small amount and are virtually identical.
If we view analysis as "what" and design as "how" then they are equivalent operations that cannot be separated from each other. All analysis is design, and all design is analysis.

Before we launch into the analysis process, I need to explain some key concepts. In analysis and design, as with any syntax-oriented environment, you ensure quality by applying the proper principles and concepts more than by perfecting the use of the syntax. In fact, it is very possible to create a diagram with perfect syntax that will never work.
So the question is,

What concepts or guiding principles can we apply that will help us measure the quality of our models?

The question, "What is software quality?", is bound to generate many different answers, depending on 1) whom you ask, 2) under what circumstances, and 3) for what kind of software systems. An alternative question that is probably easier for us to get more informative answers is: "What are the characteristics for high-quality software?" In this module, we attempt to define software quality by defining the expected characteristics or properties of high-quality software. In doing so, we need to examine the different perspectives and expectations of users as well as other people involved with the development, management, marketing, and maintenance of the software products. We also need to examine the individual characteristics associated with quality and their inter-relationship, and focus our attention on the critical characteristics of functional correctness.

In this module, you will learn:

1. What it means to create an object
2. How to assess the quality of an abstraction
3. What it means to encapsulate an object
4. How to model objects using encapsulation
5. How to assess object quality using cohesion and coupling
6. How to create an object by assembling other objects using aggregation and composition
7. How to organize similar objects using generalization and specialization