Release date: Wednesday, 31.10.12 - Due date: Monday, 05.11.12, 16:00

If we call a task or a sub task “optional” it means, that you can earn extra points by solving it, but you do not loose points by not solving it.

In Task 02 you created a use case diagram like the following:

Use Case Diagram for Task 02

Complete Use Case Diagram for the Commenting Feature of the MMM

We suggest that a use case diagram is a reasonable starting point to discuss possible smaller systems, i.e. systems that support only some of the use cases. If we would ignore the dependencies, you each subset of the use cases would describe another system. How many would that be? As we have five use cases, the number of possible subsets is 2^5=32. (Here we counted the “empty system” and the full system as well.)

Still, we have to respect the dependencies. For example we can not select the “Add Comment” Use Case without the “Authenticate” Use Case, as “Add Comment” depends (by including it) on “Authenticate”. We can as well not select “Explain Temporary Ban” without “Authenticate”, as “Explain Temporary Ban” depends (by extending it) on “Authenticate”.

a) Name a subset of the use cases, that would respect the given dependencies.

b) Name two subsets of the use cases, respecting the dependencies, that could be seen as useful systems. (If you already suggested a useful subset in a) you may repeat it.) Describe in one or two sentences the overall functionality of these systems.

c) (optional) How many subsets of the use cases, respecting the dependencies, are there?

The task should give you experience, how easy it can be to develop a broad picture of a system if you postpone the implementation details till the time it is required. Develop an Airport Management System. Please use only plain text.

1. Name the actors and the goals they want to achieve with this system. Structure these goals into a hierarchy (kite till sea level). [For this exercise: Should be 2 to 6 actors, with 7 to 15 goals in total]
2. Pick two of the user goals at “sea level” (i.e. goals that can be fulfilled with one interaction sequence between actor and the system, corresponds to use cases), and describe the steps by which the actor achieves these goals.
3. List all extension conditions that could occur during one of these two interactions.
4. Describe for two extension conditions how you could handle them.
5. Write one summary use case that describes how a user can achieve a summary goal with a sequence of user goals.

In case you are using astah community for your models, you may use our file as a start.

The following class diagram for a hotel domain was created by a co-worker and should be enriched.

First class diagram for a hotel domain

Domain Object Model for hotels, Version for colorization

a) Apply the archetypes (moment-interval, mi-detail, role, party, place, thing, description) to the classes. Add a note to each class explaining why you have chosen the archetype. If the archetype of a class is unclear, list the arguments against each archetype.

Below you find a new domain model created by your co-worker. He already expressed that Reservation, Renting, Invoice, and Payment take place at separate moments or time intervals.

Second class diagram for a hotel domain

Domain Object Model for hotels, Version with colors

b) Add the appropriate archetypes to the classes Person and Room. If later on required you may add further classes with appropriate archetype.

c) It should be possible that the person who reserves rooms and receives the invoice is different from the persons who actually stay there. Express this in the model.

d) Till now only the Invoice has details, but it makes sense for almost all other classes: Add the missing mi-detail classes. Review your model and add missing classes and associations.

e) Sometimes a request for reservation occurs even before the reservation. Add a class WaitingReservationRequest with the appropriate archetype and the associations.

f) Add the missing multiplicties to the associations.

We will revisit Formal Concept Analysis in January.

In the lecture we discussed the the binary relation “Thing is handled in Use Case” could be represented as a lattice.

In the following task you explore the same approach for the relation “Boundary, Controller or Entity is part of Use Case Realization”. The following example illustrates this idea. The example is based on our sample solution for Task 04.

"Boundary, Controller or Entity is part of Use Case Realization" Relation

The realization of the use case “Add Comment”	The relation “Boundary, Controller or Entity is part of Use Case Realization”. The column for the realization of “Add Comment” is highlighted
Concept lattice generated by ConceptExplorer based on this relation.

Download the ConceptExplorer, unzip the file, start the program (the batch file or shell script conexp) and load the Context File. You can solve the first five questions without the tool, but it is probably faster with its help.

Give in the sense of slide 33 respectively 34 one example of:

• A general use case realization
• A specific use case realization
• A particular entity
• A common entity

We assume that one of your suggestions in Task 09 b) would be to leave the use cases “Explain temporary ban” and “Handle Offensive Comment” aside. It would be nice if we could accordingly just leave the classes that realize only these two use cases aside.

• There is only one boundary class and one controller class that is only required by these two use cases. Which are they? How do you see this in the lattice?

The lattice tells us as well, that the entity “Ban” is part of the realization of other use cases. But, it doesn't make any sense in the system without the two uses, we want to leave aside.

• Let us assume that we don't need the entity “Ban” for the realization of “Authenticate”. Change the formal context accordingly.
• Let us assume as well, that instead having the controller “Explain Temporary Ban” in the realization of “Authenticate” we could have the controller “Authenticate” in the realization of “Explain Temporary Ban”. Change the formal context accordingly.

• Regenerate the lattice. Explain how you can see, that you can now easily leave “Ban” (and more) aside. Make a screenshot of the lattice and submit it as part of the solution.

[This task is about football but the original text named it soccer.]

Data and Reality is a classical book about data modeling that goes deep into the conceptual challenges of creating a database that represents reality.

The "Soccer" Database

Consider a database scoring statistics for a soccer team, both on a positions basis 
and on an individual basis. The database might have representatives for 36 things: 
11 positions and 25 players. When Joe Smith, playing halfback, scores a goal, the 
data about two things is modified: the number of goals by Joe Smith, and the number 
of goals by a halfback. That human figure standing on the field is represented as 
(and is) two things: Joe Smith and a halfback.

[...] Suppose Joe switches to fullback, and scored another goal. Did the same thing 
make those two goals? Yes: Joe Smith made both. No: one was mad by a halfback, the 
other by a fullback.

[...]

If the file only had data about player positions, then the same physical object would 
be treated as being different things at different times. Joe is sometimes a halfback 
and sometimes a fullback. From the perspective of this file, his activities are being 
performed by two different entities.

Task: Create a domain object model for the described situation using modeling in color. Include the operation to calculate the number of goals per game for a given person and the operation to calculate the number of goals for a given position.

Note: Data and Reality describes many deep and timeless modeling challenges. Many of which can quite clearly be handled with the modeling in color approach.