From Requirements to Classes

Requirements are not object-oriented: they resemble declarative statements.
Transition
- from functional requirements
- to objects
is the most difficult and critical task in the process of object-oriented analysis and design.
Methodology associated with this transition has to be scalable, and
has to make provisions for structuring and prioritizing of requirements.

Analysis of use cases leads to discovery of classes and relationships.
Validity of classes and their relationships can be questioned (tested) through
analysis of use cases.

Entity objects:
- model the information that should survive a use case.
- model the behavior related to this information.
Interface objects:
- model the information and behavior dependent on the interface to the system.
Control objects:
- model the functionality not tied to other types of objects.

It is often difficult to decide whether some information should be modeled as
- an attribute of some object, or
- as a separate entity object.
Information which will always be handled separately, as one entity, should be modeled as an entity object.
Information which is strongly coupled to other information and never used separately, should be modeled as an attribute of an entity object.

Tangible object: corresponds to a thing existing in physical sense, such as
a keyboard, a valve, a sensor, etc...
Role: an abstraction of an assignment or purpose of
a person, organization, or physical object.
For example, instructor, student, input file, auditing agency, etc...
Incident: an abstraction of an event, occurrence, such as
a meeting, an interrupt, an error, etc...
Interaction: an object resulting from associations between objects.
For example, a course registration, a club membership, etc...
Specification: represents a rule, a standard, or criteria.
For example, a recipe, graduation requirements, etc...

Descriptive: provide characteristics of the object:

    student.GPA,
    person.age,
    account.balance ...

Naming: provide name or label:

    person.SSN,
    student.ID,
    person.name, ...

Referential: tie objects together:

    property.owner,
    student.transcript, ...

Measures level of inter-module dependence.
Represents strength of the forces external to the module pulling it towards other modules.
For our use these forces are logical as oppose to physical.

Property of an abstraction capturing...

...all necessary characteristics of an object...

...to be useful across a domain of problems.
Problem domain is an area of expertise describing a group or a class of problems.

Property of an abstraction that provides only those services (operations),
which cannot be obtained by sequences of other services (operations),
already provided by this abstraction.
Another interpretation:
- Class should provide to its clients only the operations
  requiring the access to its implementation (its state).

Choice of the relationships between classes
- reflects the distribution of responsibilities
- relates to the choice and placement of operations.
Heuristics used in choosing relationships are aimed at achieving loose coupling
of classes and objects.
In particular:
- Methods of a class should not depend on the structure of any other class.
- Method should send messages to objects of as few different classes as possible.

Choice of implementation involves the choice of:
- module (package, file, ...)
- structure (state representation: array, linked list, ...)
- implementation of methods (the algorithms used.)