Class Identification Via UseCase

Question

Hi Friends.......
I know that use case is use for the purpose of requirment gatheringMy questios are
1---->How to Identify Classes through USE cases.
2----->Is Use Case is High Level Design
Thanks and Reagrd

Answer 1

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.