Software Engineering I

Object-Oriented Analysis Phase

 

 

This is a semi-formal specification technique for the Object Oriented (OO) paradigm.

 

Object Oriented Analysis (OOA) consists of the following 3 steps :-

 

  1. Use-case modeling
  2. Class modeling
  3. Dynamic Modeling

 

 

 

Use-Case Modeling

 

This is also known as functional modeling.

The goal here is to determine how the various results are computed by the product (without regard to the sequencing of actions).

Here a special diagram called a use-case diagram is drawn to present the information from this analysis.

The overall functionality of the product-to-be is established in this step.

This first step is largely action oriented.

 

 

Class Modeling

 

The goal here is to determine the necessary classes and their attributes (data). This step also seeks to discover the type of inter-relationships between classes.

At the end of this step the relevant class diagrams are drawn to represent the information.

This next step is purely data oriented.

 

 

Dynamic Modeling

 

The goal of this last step is to determine the actions performed by each class or subclass.

This information will be presented in a state diagram.

This step is action oriented.

 

 

Class Modeling Techniques

 

Class modeling deals with finding classes and the data contained therein (i.e. attributes) not finding the class methods (i.e. member functions).

 

A number of techniques exist to derive what classes should be included in the product; We look briefly at two of them :-

 

 

Noun Extraction

 

This technique first defines the problem in a concise manner, preferably a single sentence. Secondly a paragraph called an “informal strategy” for solving the problem is written. Thirdly, the informal strategy statement is formalized by extracting the nouns present, excluding those that lies outside of the problem boundary, then use these nouns as the candidate classes.

We observe that abstract nouns seldom become classes as they only illustrate ideas e.g. request, movement. We make these abstract nouns, not classes, but attributes (i.e. data) of the classes.

Noun extraction provides a useful starting point but more skill and design is necessary to identify the best formulation of classes and attributes for a given problem.

 

 

Class-Responsibility-Collaboration (CRC) Cards

 

This technique seeks to codify the features of a class on a card that can later be fully examined and refined. CRC cards (, if used by experienced teams of class designers) allow weaknesses in a class design to be shown up.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Example CRC card