- Tips and Tricks
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.
|4 [+2] points|
In Task 02 you created a use case diagram like the following:
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.
|14 = 4+1+2+2+2+3 points|
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.
a) Apply the archetypes (
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
Payment take place at separate moments or time intervals.
b) Add the appropriate archetypes to the classes
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.
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:
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.
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.
[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.
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.