Software Engineering-The OOA Process


The OOA process does not begin with a concern for objects. Rather, it begins with an understanding of the manner in which the system will be used—by people, if the system is human-interactive; by machines, if the system is involved in process control; or by other programs, if the system coordinates and controls applications. Once the scenario of usage has been defined, the modeling of the software begins. 

Use-Cases

Use-cases model the system from the end-user’s point of view. Created during requirements elicitation, use-cases should achieve the following objectives:
To define the functional and operational requirements of the system (product) by defining a scenario of usage that is agreed upon by the end-user and the software engineering team.
To provide a clear and unambiguous description of how the end-user and the system interact with one another.
To provide a basis for validation testing.

During OOA, use-cases serve as the basis for the first element of the analysis model. Using UML notation, a diagrammatic representation of a use-case, called a use-case diagram, can be created. Like many elements of the analysis model, the use-case diagram can be represented at many levels of abstraction. The use-case diagram contains actors and use-cases. Actors are entities that interact with the system. They can be human users or other machines or systems that have defined interfaces to the software.

To illustrate the development of a use-case diagram, we consider the use-cases for the SafeHome security system . Three actors were identified: the homeowner, sensors, and the monitoring and response subsystem. For the purpose of this example, only the homeowner is considered.
Figure depicts a high-level use-case diagram for the homeowner. Referring to figure , two use-cases are identified (represented by ovals). Each of the high-level use-cases may be elaborated with lower-level use-case diagrams. 
For example, figure below  represents a use-case diagram that elaborates the interacts function. A complete set of use-case diagrams is created for all actors. 

Class-Responsibility-Collaborator Modeling

Once basic usage scenarios have been developed for the system, it is time to identify candidate classes and indicate their responsibilities and collaborations. Classresponsibility- collaborator (CRC) modeling  provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler describes CRC modeling in the following way:

A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.

In reality, the CRC model may make use of actual or virtual index cards. The intent is to develop an organized representation of classes. Responsibilities are the attributes and operations that are relevant for the class. Stated simply, a responsibility is “anything the class knows or does” . Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility. In general, a collaboration implies either a request for information or a request for some action.

Classes

To summarize, objects manifest themselves in a variety of forms : external entities, things, occurrences, or events; roles; organizational units; places; or structures. One technique for identifying these in the context of a software problem is to perform a grammatical parse on the processing narrative for the system. All nouns become potential objects. However, not every potential object makes the cut. Six selection characteristics were defined:

1. Retained information. The potential object will be useful during analysis only if information about it must be remembered so that the system can function.

2. Needed services. The potential object must have a set of identifiable operations that can change the value of its attributes in some way.

3. Multiple attributes. During requirements analysis, the focus should be on "major" information; an object with a single attribute may, in fact, be useful during design but is probably better represented as an attribute of another object during the analysis activity.

4. Common attributes. A set of attributes can be defined for the potential object and these attributes apply to all occurrences of the object.

5. Common operations. A set of operations can be defined for the potential object and these operations apply to all occurrences of the object.

6. Essential requirements. External entities that appear in the problem space and produce or consume information that is essential to the operation of any solution for the system will almost always be defined as objects in the requirements model.

A potential object should satisfy all six of these selection characteristics if it is to be considered for inclusion in the CRC model.

Firesmith  extends this taxonomy of class types by suggesting the following additions:

Device classes model external entities such as sensors, motors, keyboards.
Property classes represent some important property of the problem environment (e.g., credit rating within the context of a mortgage loan application).
Interaction classes model interactions that occur among other objects (e.g., a purchase or a license).

In addition, objects and classes may be categorized by a set of characteristics:

Tangibility. Does the class represent a tangible thing (e.g., a keyboard or sensor) or does it represent more abstract information (e.g., a predicted outcome)?

Inclusiveness. Is the class atomic (i.e., it includes no other classes) or is it aggregate (it includes at least one nested object)?

Sequentiality. Is the class concurrent (i.e., it has its own thread of control) or sequential (it is controlled by outside resources)?

Persistence. Is the class transient (i.e., it is created and removed during program operation), temporary (it is created during program operation and removed once the program terminates), or permanent (it is stored in a database)?

Integrity. Is the class corruptible (i.e., it does not protect its resources from outside influence) or guarded (i.e., the class enforces controls on access to its resources)?

Using these class categories, the “index card” created as part of the CRC model might be extended to include the type of class and its characteristics .

Responsibilities

To summarize, attributes represent stable features of a class; that is, information about the class that must be retained to accomplish the objectives of the software specified by the customer. Attributes can often be extracted from the statement of scope or discerned from an understanding of the nature of the class. Operations can be extracted by performing a grammatical parse on the processing narrative for the system. All verbs become candidate operations. Each operation that is chosen for a class exhibits a behavior of the class.

Wirfs-Brock and her colleagues  suggest five guidelines for allocating responsibilities to classes:

1. System intelligence should be evenly distributed. Every application encompasses a certain degree of intelligence; that is, what the system knows and what it can do. This intelligence can be distributed across classes in a number of different ways. “Dumb” classes (those that have few responsibilities) can be modeled to act as servants to a few “smart” classes (those having many responsibilities. Although this approach makes the flow of control in a system straightforward, it has a few disadvantages: (1) It concentrates all intelligence within a few classes, making changes more difficult, and (2) it tends to require more classes, hence more development effort.

Therefore, system intelligence should be evenly distributed across the classes in an application. Because each object knows about and does only a few things (that are generally well focused), the cohesiveness of the system is improved. In addition, side effects due to change tend to be dampened because system intelligence has been decoupled across many objects.

To determine whether system intelligence is evenly distributed, the responsibilities noted on each CRC model index card should be evaluated to determine if any class has an extraordinarily long list of responsibilities. This indicates a concentration of intelligence. In addition, the responsibilities for each class should exhibit the same level of abstraction. For example, among the operations listed for an aggregate class called checking account a reviewer notes two responsibilities: balance-the-account and check-off-cleared-checks. The first operation (responsibility) implies a complex mathematical
and logical procedure. The second is a simple clerical activity. Since these two operations are not at the same level of abstraction, check-off-cleared- checks should be placed within the responsibilities of check-entry, a class that is encompassed by the aggregate class checking account.

2. Each responsibility should be stated as generally as possible. This guideline implies that general responsibilities (both attributes and operations) should reside high in the class hierarchy (because they are generic, they will apply to all subclasses). In addition, polymorphism should be used in an effort to define operations that generally apply to the superclass but are implemented differently in each of the subclasses.

3. Information and the behavior related to it should reside within the same class. This achieves the OO principle that we have called encapsulation . Data and the processes that manipulate the data should be packaged as a cohesive unit.

4. Information about one thing should be localized with a single class, not distributed across multiple classes. A single class should take on the responsibility for storing and manipulating a specific type of information. This responsibility should not, in general, be shared across a number of classes. If information is distributed, software becomes more difficult to maintain and more challenging to test.

5. Responsibilities should be shared among related classes, when appropriate. There are many cases in which a variety of related objects must all exhibit the same behavior at the same time. As an example, consider a video game that must display the following objects: player, player-body, player-arms, player-legs, player-head. Each of these objects has its own attributes (e.g., position, orientation, color, speed) and all must be updated and displayed as the user manipulates a joy stick. The responsibilities update and display must therefore be shared by each of the objects noted. Player knows when something has changed and update is required. It collaborates with the other objects to achieve a new position or orientation, but each object controls its own display.

Collaborations

Classes fulfill their responsibilities in one of two ways: (1) A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or (2) a class can collaborate with other classes.

Wirfs-Brock and her colleagues [WIR90] define collaborations in the following way:

Collaborations represent requests from a client to a server in fulfillment of a client responsibility. A collaboration is the embodiment of the contract between the client and the server. . . . We say that an object collaborates with another object if, to fulfill a responsibility, it needs to send the other object any messages. A single collaboration flows in one direction— representing a request from the client to the server. From the client’s point of view, each of its collaborations are associated with a particular responsibility implemented by the server.
  
Collaborations identify relationships between classes. When a set of classes all collaborate to achieve some requirement, they can be organized into a subsystem (a design issue).

Collaborations are identified by determining whether a class can fulfill each responsibility itself. If it cannot, then it needs to interact with another class. Hence, a collaboration. As an example, consider the SafeHome application. As part of the activation procedure  the control panel object must determine whether any sensors are open. A responsibility named determinesensor- status is defined. If sensors are open control panel must set a status attribute to “not ready.” Sensor information can be acquired from the sensor object. Therefore, the responsibility determine-sensor-status can be fulfilled only if control panel works in collaboration with sensor.

To help in the identification of collaborators, the analyst can examine three different generic relationships between classes : (1) the is-part-of relationship, (2) the has-knowledge-of relationship, and (3) the depends-upon relationship. By creating a class-relationship diagram , the analyst develops the connections necessary to identify these relationships. Each of the three generic relations is considered briefly in the paragraphs that follow.

All classes that are part of an aggregate class are connected to the aggregate class via an is-part-of relationship. Consider the classes defined for the video game noted earlier, the class player-body is-part-of player, as are player-arms, player-legs, and player-head.

When one class must acquire information from another class, the has-knowledgeof relationship is established. The determine-sensor-status responsibility noted earlier is an example of a has-knowledge-of relationship.

The depends-upon relationship implies that two classes have a dependency that is not achieved by has-knowledge-of or is-part-of. For example, player-head must always be connected to player-body (unless the video game is particularly violent), yet each object could exist without direct knowledge of the other. An attribute of the player-head object called center-position is determined from the center position of player-body. This information is obtained via a third object, player, that acquires it from player-body. Hence, player-head depends-upon player-body.

In all cases, the collaborator class name is recorded on the CRC model index card next to the responsibility that has spawned the collaboration. Therefore, the index card contains a list of responsibilities and the corresponding collaborations that enable the responsibilities to be fulfilled .

When a complete CRC model has been developed, the representatives from the customer and software engineering organizations can review the model using the following approach :

1. All participants in the review (of the CRC model) are given a subset of the CRC model index cards. Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate).

2. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories.

3. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. For example, a use-case for SafeHome contains the following narrative:

The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not-ready indicator implies that a sensor is open, i.e., that a door or window is open.] When the review leader comes to “control panel,” in the use-case narrative, the token is passed to the person holding the control panel index card. The phrase “implies that a sensor is open” requires that the index card contains a responsibility that will validate this implication (the responsibility determinesensor- status accomplishes this). Next to the responsibility on the index card is the collaborator sensor. The token is then passed to the sensor object.

4. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement.

5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards.

This modus operandi continues until the use-case is finished. When all use-cases (or use-case diagrams) have been reviewed, OOA continues.

Defining Structures and Hierarchies

Once classes and objects have been identified using the CRC model, the analyst begins to focus on the structure of the class model and the resultant hierarchies that arise as classes and subclasses emerge. Using UML notation, a variety of class diagrams can be created. Generalization/specialization class structures can be created for identified classes.

To illustrate, consider the sensor object defined for SafeHome, shown in figure. Here, the generalization class, sensor, is refined into a set of specializations—entry sensor, smoke sensor, and motion sensor. The attributes and operations noted for the sensor class are inherited by the specializations of the class. We have created a simple class hierarchy.

In other cases, an object represented in the initial model might actually be composed of a number of component parts that could themselves be defined as objects. These aggregate objects can be represented as a composite aggregate  and are defined using the notation represented in figure. The diamond implies an assembly relationship. It should be noted that the connecting lines may be augmented with additional symbols (not shown) to represent cardinality. These are adapted from the entity/relationship modeling notation .
 Structure representations provide the analyst with a means for partitioning the CRC model and representing that partitioning graphically. The expansion of each class provides needed detail for review and for subsequent design.

Defining Subjects and Subsystems

An analysis model for a complex application may have hundreds of classes and dozens of structures. For this reason, it is necessary to define a concise representation that is a digest of the CRC and structure models just described.

When a group of all classes collaborate among themselves to accomplish a set of cohesive responsibilities, they are often referred to as subsystems or packages (in UML terminology). Subsystems or packages are abstractions that provide a reference or pointer to more detail in the analysis model. When viewed from the outside, a subsystem can be treated as a black box that contains a set of responsibilities and that has its own (outside) collaborators. A subsystem implements one or more contracts  with its outside collaborators. A contract is a specific list of requests that collaborators can make of the subsystem.

Subsystems can be represented with the context of CRC modeling by creating a subsystem index card. The subsystem index card indicates the name of the subsystem, the contracts that the subsystem must accommodate, and the classes or (other) subsystems that support the contract.

Packages are identical to subsystems in intent and content but are represented graphically in UML. For example, assume that the control panel for SafeHome is considerably more complex , containing multiple display areas, a sophisticated key arrangement, and other features. It might be modeled as the composite aggregate structure shown in figure. If the overall requirements model contains dozens of these structures (SafeHome would not), it would be difficult to absorb the entire representation at one time. By defining a package reference as shown in the figure, the entire structure can be referenced by a single icon (the file folder). Package references can be created for any structure that has multiple objects.

At the most abstract level, the OOA model would contain only package references such as those illustrated at the top of figure below. Each of the references would be expanded into a structure. Structures for the control panel and sensor objects are shown in the figure; structures for system, sensor event and audible alarm would also be created.

The dashed arrows shown at the top of figure represent dependence relationships between the packages shown. For example, sensor depends on the status of the sensor event package. The solid arrows represent composition. In the example shown, the system package is composed of the control panel, sensor, and audible alarm packages.


Share this article :
 
Copyright © 2012. Best Online Tutorials | Source codes | Programming Languages - All Rights Reserved