Class Identification Via UseCase

I hope this would be usefull

A section from Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development

9.5. Guideline: How to Find Conceptual Classes?

Since a domain model shows conceptual classes, a central question is: How do I find them?

What are Three Strategies to Find Conceptual Classes?

Reuse or modify existing models. This is the first, best, and usually easiest approach, and where I will start if I can. There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth. Example books that I'll turn to include Analysis Patterns by Martin Fowler, Data Model Patterns by David Hay, and the Data Model Resource Book (volumes 1 and 2) by Len Silverston.

Use a category list.

Identify noun phrases.

Reusing existing models is excellent, but outside our scope. The second method, using a category list, is also useful.

Method 2: Use a Category List

We can kick-start the creation of a domain model by making a list of candidate conceptual classes. Table 9.1 contains many common categories that are usually worth considering, with an emphasis on business information system needs. The guidelines also suggest some priorities in the analysis. Examples are drawn from the 1) POS, 2) Monopoly, and 3) airline reservation domains.

Table 9.1. Conceptual Class Category List. Conceptual Class Category

Examples

business transactions

Guideline: These are critical (they involve money), so start with transactions.

Sale, Payment

Reservation

transaction line items

Guideline: Transactions often come with related line items, so consider these next.

SalesLineItem

product or service related to a transaction or transaction line item

Guideline: Transactions are for something (a product or service). Consider these next.

Item

Flight, Seat, Meal

where is the transaction recorded?

Guideline: Important.

Register, Ledger

FlightManifest

roles of people or organizations related to the transaction; actors in the use case

Guideline: We usually need to know about the parties involved in a transaction.

Cashier, Customer, Store MonopolyPlayer Passenger, Airline

place of transaction; place of service

Store

Airport, Plane, Seat

noteworthy events, often with a time or place we need to remember

Sale, Payment MonopolyGame Flight

physical objects

Guideline: This is especially relevant when creating device-control software, or simulations.

Item, Register Board, Piece, Die Airplane

descriptions of things

Guideline: See p. 147 for discussion.

ProductDescription

FlightDescription

catalogs

Guideline: Descriptions are often in a catalog.

ProductCatalog

FlightCatalog

containers of things (physical or information)

Store, Bin Board Airplane

things in a container

Item Square (in a Board) Passenger

other collaborating systems

CreditAuthorizationSystem

AirTrafficControl

records of finance, work, contracts, legal matters

Receipt, Ledger

MaintenanceLog

financial instruments

Cash, Check, LineOfCredit

TicketCredit

schedules, manuals, documents that are regularly referred to in order to perform work

DailyPriceChangeList

RepairSchedule

Method 3: Finding Conceptual Classes with Noun Phrase Identification

Another useful technique (because of its simplicity) suggested in [Abbot83] is linguistic analysis: Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes.[5]

[5] Linguistic analysis has become more sophisticated; it also goes by the name natural language modeling. See [Moreno97] for example.

Guideline

Care must be applied with this method; a mechanical noun-to-class mapping isn't possible, and words in natural languages are ambiguous.

Nevertheless, linguistic analysis is another source of inspiration. The fully dressed use cases are an excellent description to draw from for this analysis. For example, the current scenario of the Process Sale use case can be used.

Main Success Scenario (or Basic Flow):

Customer arrives at a POS checkout with goods and/or services to purchase.

Cashier starts a new sale.

Cashier enters item identifier.

System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.

Cashier repeats steps 2-3 until indicates done.

System presents total with taxes calculated.

Cashier tells Customer the total, and asks for payment.

Customer pays and System handles payment.

System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory).

System presents receipt.

Customer leaves with receipt and goods (if any).

Extensions (or Alternative Flows):

. . .

7a. Paying by cash:

Cashier enters the cash amount tendered.

System presents the balance due, and releases the cash drawer.

Cashier deposits cash tendered and returns balance in cash to Customer.

System records the cash payment.

The domain model is a visualization of noteworthy domain concepts and vocabulary. Where are those terms found? Some are in the use cases. Others are in other documents, or the minds of experts. In any event, use cases are one rich source to mine for noun phrase identification.

Some of these noun phrases are candidate conceptual classes, some may refer to conceptual classes that are ignored in this iteration (for example, "Accounting" and "commissions"), and some may be simply attributes of conceptual classes. See p. 160 for advice on distinguishing between the two.

A weakness of this approach is the imprecision of natural language; different noun phrases may represent the same conceptual class or attribute, among other ambiguities. Nevertheless, it is recommended in combination with the Conceptual Class Category List technique.

caltuntasa at 2007-7-15 3:59:54 >