UML Sequence Diagrams
3. Identifying Concepts
The requirement document which is up to now including: the overview, goal, functional requirements, use cases, use case diagram and use case descriptions is the good source of information in identifying concepts. Two activities that are fundamental to the useful application of object oriented in OOA are:
- To identify as many candidate objects from the problem domain, and
- Later select those candidate objects that are significant to develop and be specified in an object model (conceptual model)
Liu suggests the following candidate concepts from the requirement document as shown in Table 3.10.
Table 3.10: Guide to Identify Concepts
Concept Category | Examples |
physical or tangible objects (or things | POST (i.e. Point-of-Sale Unit), House, Car, Sheep, People, Airplane |
places | Store, Office, Airport, Police Station |
documents, specifications, designs, or descriptions of things | Product Specification, Module Description, Flight Description |
transactions | Sale, Payment, Reservation |
roles of people | Cashier, Student, Doctor, Pilot |
containers of other things | Store, Bin, Library, Airplane |
things in a container | Item, Book, Passenger |
other computers or electromechanical systems external to our system | Credit Card Authorization System, Air-Traffic Control |
abstract noun concepts | Hunger, Acrophobia |
organizations | Sales Department, Club, Object Airline |
historic events, incidents | Sale, Robbery, Meeting, Flight, Crash, Landing |
Processes (often not represented as a concept, but may be) | Selling A Product, Booking A Seat |
rules and policies | Refund Policy, Cancellation Policy |
Catalogs | Product Catalog, Parts Catalog |
records of finance, work, contracts, legal matters | Receipt, Ledger, Employment Contract, Maintenance Log |
financial instruments and services | Line Of Credit, Stock |
manuals, books | Employee Manual, Repair Manual |
Another useful and simple technique for the identification of concepts is to identify or extract noun and noun phrases from the requirement document and consider them as candidate concepts or attributes.
Warning:
Care must be applied when these methods are used; mechanical noun-to-concept mapping is not possible, words in natural languages are ambiguous, and concept categories may include concepts which are about either attributes, events or operations which should
not be modeled as classes. We should concentrate on the objects/classes involved in the realization of the use cases.
Consider the POST system, from the use case Buy Items with Cash. We can identify some noun phrases as shown in Figure 3.8. Some of the noun phrases in the use case are candidate concepts; some may be attributes of concepts.
Figure 3.8: Selected Possible Concepts for the POST System
The following guidelines are useful when identifying concepts:
- It is better to over specify a conceptual model with lots of fine-grained concepts, than to under specify it.
- Do not exclude a concept simply because the requirements do not indicate an obvious need to remember information about it.
- It is common to miss concepts during the initial identification phase, and to discover them later during the consideration of attributes or associations, or during the design phase. When found, they are added to the conceptual model.
- Put a concept down as a candidate in the conceptual model when you are not sure it must not be included.