Domain Model as UML Class Diagram with Superimposed World Diagram
and Use Case Model for Matchmaker

1. Decide on the entities in the Matchmaker world and capture them in a domain model expressed as a UML class diagram (see UML tools), as on page 21 of the slides for Classes & Concepts. Your classes are not required to have attributes or operations (methods) other than those corresponding to the use cases identified in part 2. That is, a box with only a class name suffices for most classes. Some classes will have operations for the use cases.

   Then divide these entities into the environment and the system. Superimpose this division on to the UML-class-model-expressed domain model. You can do this superimposition by drawing a shape enclosing the environment entities and another shape enclosing the system entities; then label each shape as ENV or SYS as the case may be, as on page 21 of the slides for Classes & Concepts. Alternatively, you could just mark each domain model entity with ``ENV'', ``SYS'', or both, as the case may be, as on page 47 of the same slides.

   If you have done this superimposition correctly, you should be able to see clearly which entities are in the interface.

2. Take the raw ideas generated the brainstorming session. Prune this list into a list of good ideas for features for Matchmaker program that you will be specifying. Combine these with other ideas that you may have thought about. Finally, arrive at a first draft list of the features that you think the customer will want in the Matchmaker program.

   The hardest part of this exericise is coming up with a concise, consistent, and complete set of use cases that allow the user to do what he or she needs to without having too many different ways of doing any one thing.

   Describe each feature as a use case, i.e., give a simple imperative sentence as if when the user says the imperative sentence as a command, Matchmaker will obey and do the use case.

   You do not have to develop any scenarios yet. However, your imperative sentences must be complete enough that the customer can understand what the feature does. Thus, a phrase, such as ``the questionnaire'', does not cut the mustard because it does not explain what happens with the questionnaire.

   Build a use case diagram that shows the system boundary, all actors, all use cases and that associates each use case with each actor that may do it. Use the notation of the use case diagram on page 22 of the slides for Classes & Concepts.

The two diagrams should be consistent in that

• Each actor in the use case diagram appears as a class with stereotype ``<<actor>>'' in the class diagram, and vice versa.
• Each use case in the use case diagram should appear as an operation in a class in the class diagram, and vice versa.