Fundamentals of Object Oriented Analysis and Design - Classifications - Part 04

 The following are the notes from Object Oriented Analysis and Design 3rd edition.

In object-oriented design recognizing sameness among things allows us to expose commonality among within key abstractions and mechanisms leading to smaller applications and simplified architectures.

Identification of classes and objects is challenging part in object-oriented analysis and design as this involves both discovery and invention. Through discovery key abstraction and mechanisms are found that form vocabulary of problem domain. Through invention new generalized abstractions and mechanisms that define how objects collaborate are found. Both are the tools of classification and the purpose is to group things that have common structures and exhibit common behavior.

Classification helps us find generalization/specialization/aggregation hierarchies among classes. By recognizing common pattern of interaction among objects, mechanisms are discovered that serve as blueprint of implementation. Classification also guides about modularization. Certain classes and objects might be placed in same or different module based on sameness found in the declarations.

The boundaries that distinguish one object from other is not always crisply defined but fuzzy. The Parallels of Classification is also found in the disciplines of biology. For example, The most general category in a biological taxonomy is the kingdom, followed in order of increasing specialization, by phylum, subphylum, class, order, family, genus, and, finally, species.

Classification is the means whereby we order knowledge.

Different criteria for classifying same animal yield different results. Therefore, results of classification are highly dependent on the reason for classification.

Incremental and iterative classification affects creation class and object hierarchies in complex systems. It’s practical to assert a class structure early during the design and later revise it over time. The quality of the classification can be seen only after the clients use it.

Different observers will classify the same object in different ways.

There is no perfect classification – it depends on the perspective of the observer. Also intelligent classification requires a tremendous insight.

There are three types of classification theories:

1. Classical categorization
2. Conceptual Clustering
3. Prototype Theory

Classical categorization

Classical approach uses related properties as criteria for sameness among objects. Specifically, one can divide objects into disjoint sets depending on presence or absence of the property. Example, married or unmarried people.   Not applicable are tall or skinny people.

The most useful set of properties are those that don’t interact much. For example, color, size, style etc. a dress can be of any style/color/size. Properties may include also observable behavior. Example, birds fly, fish swim etc.

Particular property that should be considered is highly domain specific. For example, make of a car may be important for a car showroom inventory control software but not for traffic light control software. Therefore, there is no absolute measure of classification for a given system.

Classic Classification may not work in every case. For example, some birds like emu or ostrich cannot fly. Chairs may not have 4 legs, a table may be square, round, rectangle etc. Therefore, it’s almost impossible to make a list of properties for a natural category that excludes some examples and includes some for the same category.

Conceptual Clustering

Is a variation of classical categorization where classes (clusters of entities) are first generated formulating conceptual description of these classes and then classifying the entities on the basis of description. For example, take the concept of “happy song” which is more than a property. It’s difficult to measure “happiness” of a song empirically. However, if a song is indeed happy then it needs to be placed under this category. Therefore, conceptual clustering is probabilistic clustering of objects.

Conceptual clustering is closely related to fuzzy(multivalued) set theory where objects belong to more than one group in varying levels of fitness. Conceptual clustering makes best judgement of classification based on best fit.

The diagram below contains ten items, labeled A to J, each of which represents a train. Each train includes an engine (on the right) and from two to four cars, each shaped differently and holding different loads. Before reading further, spend the next few minutes arranging these trains into any number of groups you deem meaningful. For example, you might create three groups: one for trains whose engines have all black wheels, one for trains whose engines have all white wheels, and one for trains whose engines have black and white wheels.

A Problem of Classification

Prototype Theory

There are abstractions that are not bound by a set of properties or concepts. A class of objects is represented by a prototypical object and an object can belong to this category only if it resembles this prototype in significant ways. For example, “game” in general is not bound by properties that applies to all games. However, there are category of games exists that are united by family of resemblance. Yet this category is not fixed and can be extended as new games can be developed and added to this category as long as they resemble other games in this category.

Similarly different type of chair such as wheelchair, beanbag are called chairs not because they share some properties with the prototype rather they bear sufficient family resemblance to the prototype. In fact, there need not exist fixed properties for the prototype chair at all.

Interactional properties are significant in determining family resemblance to a prototype and are central to the idea of prototype theory.

Application

In practice for object-oriented design all the three practices are relevant.

First start off with classical categorization where classes and objects are scooped per properties relevant to the problem domain; here structures and behaviors are identified. Next, objects are clustered based on concepts by focusing on the behavior of collaborating objects. Further, classification of objects is considered based on association where clusters of objects are defined based on their similarities with a prototype object.

Therefore, object-oriented analysis uses all the three classification methods that instills theoretical foundation by providing pragmatic practices and rules of thumb to identify classes and objects in problem domain.

Object oriented analysis

The difference between object-oriented analysis and design are quite fuzzy even though their focusses are quite distinct. The purpose of object-oriented analysis is to create a model analyzing the problem domain and discovering classes and objects from its vocabulary. In object-oriented design abstractions and mechanisms are invented from the model to provide blueprint for the implementation.

Classical Approaches

Following approaches use classical approach for deriving classes and objects from problem domain:

Candidate classes and objects come from one of the following sources:

Sources	Examples
Tangible things	Cars, telemetry data, pressure sensors
Roles	Mother, teacher, politician
Events	Landing, interrupt, request
Interactions	Loan, meeting, intersection

Database Modeling:

Sources	Examples
People	Humans who carry out some function
Places	Areas set aside for people or things
Things	Physical objects, or groups of objects, that are tangible
Organizations	Formally organized collections of people, resources, facilities, and capabilities having a defined mission, whose existence is largely independent of individuals
Concepts	Principles or ideas not tangible per se; used to organize or keep track of business activities and/or communications
Events	Things that happen, usually to something else at a given date and time, or as steps in an ordered sequence

 Another set of sources of potential objects:

Sources	Examples
Structure	“Is a” and “part of” relationships
Other systems	External systems with which the application interacts
Devices	Devices with which the application interacts
Events remembered	A historical event that must be recorded
Roles played	The different roles users play in interacting with the application
Locations	Physical locations, offices, and sites important to the application
Organizational units	Physical locations, offices, and sites important to the application

 At a higher level of abstraction, the subject areas are a group of classes that relate to higher level system function.

Behavior Analysis

Dynamic behavior can be used as source of classes and objects. This is similar to conceptual clustering. Classes are formed from group of objects that exhibit similar behavior.

Responsibilities convey purpose of an object and its place in the system. In other words, responsibility of an object is all the services it provides for all the contract it supports. Therefore, hierarchy of classes are formed based common responsibilities from entities. Base classes are formed to have general responsibilities and derived classes are formed to have specialized responsibilities.

Another method is to derive a set of classes and objects from system functions. In this approach a study of the system is made and system behaviors are understood. Next, these behaviors are applied to the parts of the system. The Initiator and participants are made as objects. The behavioral responsibilities are made as roles of the objects.

This resembles closely to the concept of function points. It’s defined as one end user business function. A function point is any relevant outwardly visible or testable behavior of the system.

Domain Analysis

Domain analysis attempts to discover classes and objects that are common to all application within a given domain such as patient record tracking, bond trading etc. Domain analysis can be defined as an attempt to identify objects, functions, relationships that domain experts believe important to the domain.

Following steps can be used during domain analysis:

• Construct a strawman generic model of the domain by consulting with domain experts.
• Examine the current system under the domain and represent it in a common format.
• Understand similarities and differences between the systems by consulting domain experts.
• Refine the generic model to accommodate the existing system.

A domain expert has immense experience with the problem domain and can speaks vocabulary of the problem domain.

Use Case Analysis

An use case can be defined as behaviorally related set of transactions performed by an actor in dialog with the system to provide some measurable value to the actor.

Use case analysis can be performed during early requirement analysis phase where end users, domain experts and development team enumerate the scenarios that are fundamental to the systems operation. (No elaboration needed). These scenarios collectively describe the system functions of the application.  Analysis then proceeds with the study of each scenario using storyboarding technique. As each scenario is studied, objects that participates in the scenario are identified, their responsibilities and how they collaborate with another objects in terms of invoking actions on each other. In this manner the team is forced to craft a clear separation of concerns among all abstractions. As the development continues, these scenarios are expanded to consider exceptional situations and secondary system behaviors. These secondary system behaviors introduce new abstractions or add/modify/reassign responsibilities in the existing abstractions. Scenarios also serve as basis for tests.

CRC Cards

CRC stands for Class/Responsibilities/Collaborators. CRC cards have proven to be useful development tool that facilitates brainstorming and enhance communication among developers. A CRC card is 3x5 card where name of the class is written on the top, responsibilities are written top half and collaborators on the bottom half. Each card is Ilustre one class. As the team walks through the scenario, add new responsibilities to an existing class, group a set of responsibilities to form a new class, divide the responsibilities into fine grained ones and perhaps distribute it to a new class.

CRC Cards can be spatially arranged to represent patterns of collaborations. As seen from the dynamic semantics of the scenario, the cards are arranged to show flow of the messages among prototypical instances of the class; from the static semantic of the scenario, the cards are arranged to represent generalization/specialization and aggregation hierarchies among classes.

Informal English Description

An alternative is to write English description of the problem or part of the problem where nouns and verbs are underlined. The nouns form the candidate objects and verbs form the candidate operations on the object. One important advantage is that it works in the vocabulary of the problem domain but it has language set limitations.

Structured Analysis

Some organizations have tried to use CASE tools as for front end of object-oriented analysis and design but it’s not recommended.

Key Abstractions and Mechanisms

A key abstraction is a class or object that forms part of the vocabulary of the problem domain. The primary value of finding such abstractions is that they give boundaries to our problem. They highlight the things that are in the system and therefore are relevant to the design and suppress things that are outside to the system.

The term mechanism is used to describe any structure whereby objects collaborate to perform some behavior that satisfy the requirement of a problem. While design of a class embodies the knowledge how an individual object should behave, mechanism is a design decision on how a group of objects should cooperate. Mechanism therefore represents patterns of behavior.

The following discuss identification and refinement of key abstractions and behavior.

Identifying key abstractions

Identification of key abstractions is highly domain specific. It involves two processes: discovery and invention. Through discovery, abstraction used by domain experts are recognized. Through invention new classes are created that are not necessarily part of problem domain but are useful artifacts in the design or implementation. For example, for an accountant key abstraction could be general ledger, account receivables, account payables etc. these words are part of the vocabulary of the problem domain. A developer of the system should also introduce new ones such as database, schema etc. These key abstractions are artifacts of the particular design, not of the problem domain.

The candidate key abstractions should be evaluated according to the metrics.

How are objects of this class are created?

Can objects of this class be copied/destroyed?

What operations can be done on such objects?

If there are no good answers, probably the concept was not clean to start with.

Given a new abstraction, it must be placed in context of existing class or object hierarchies. Practically speaking this neither top down or bottom-up activity. Classes are not created with hierarchy in mind. In practice, several unrelated classes are created and grouped together by commonality. Common attributes are placed in a base class. After several iterations hierarchy is created. For example, we may find general sub class and move it up in the hierarchy thus increasing degree of sharing. This is called class promotion. On other hand, there could be another class which is too general to make it a base class because of big semantic gap. This is called grain size conflict. The goal is to find cohesive yet loosely coupled abstractions.

Following should be considered while naming abstractions:

• The object names should be taken from problem domain recognized by domain users.
• Object names should be made with proper noun phrases such as thesensor.
• Class names should be made with common noun phrase such as sensor
• Modifier operations should be made with active verb such as moveLeft
• Selector operations should imply query or should be verbed such as tobe. Isopen,  extentof
• Use of underscore (_) is personal choice

Classes and objects should be at the right level of abstraction: neither too high nor too low.

Identifying Mechanisms

In a  four wheeler automobile, the requirement is when brake pedal is pushed the car should stop and when not pushed car should  move. How it’s implemented is not driver’s concern. In other words which mechanism is used is purely a design decision. It’s also illegal for an object to deviate outside the boundaries of a mechanism. For example, pushing gas pedal for example turn on the lights.

Key abstractions reflect the vocabulary of the problem domain and mechanisms reflect the soul of the design. During design process a developer should not only consider how the individual classes are designed but also how the instances of these work with each other. The use of these scenarios drives this analysis process.

Mechanisms are the means whereby objects collaborate to provide some higher-level behavior

Once developer decides a pattern of collaboration, work is distributed among many objects by defining methods in their respectable classes. The protocol of a class encompasses all the methods to satisfy all the behavior and all the mechanisms of its instances.

Summary

■ The identification of classes and objects is a fundamental issue in object-oriented analysis and design; identification involves both discovery and invention.

■ Classification is fundamentally a problem of clustering.

■ Classification is an incremental and iterative process, made difficult because a given set of objects may be classified in many equally proper ways.

■ The three approaches to classification include classical categorization (classification by properties), conceptual clustering (classification by concepts),and prototype theory (classification by association with a prototype).

■ Scenarios are a powerful tool of object-oriented analysis and can be used in approaches such as classical analysis, behavior analysis, domain analysis, and use case analysis.

■ Key abstractions reflect the vocabulary of the problem domain and may either be discovered from the problem domain or invented as part of the design.

■ Mechanisms denote strategic design decisions regarding the collaborative activity of many different kinds of objects.