-
What
-
Choose a domain/topic for your homework.
Create a conceptual model of that domain using UML Class Diagrams and a structured textual description (see e.g. this data specification) of what is represented in the domain model.
The consecutive homework parts will then be governed by this conceptual model.
Quantitative requirements:
- 5 to 8 classes
-
Each class 2 to 4 attributes, some with multiplicity
0..*.
Attributes inherited from a parent class in an inheritance hierarchy count as well, i.e. it is ok not to create attributes for a child class if parent class already has 2 to 4.
- At least 4 associations. Include association end multiplicities
0..*, 0..1, 1..1
-
How
-
Use a tool that allows you to draw UML Class Diagrams and export them, ideally as SVG, PNG if SVG not possible.
For example, diagrams.net, PlantUML or LucidChart.
Beware that the free version of LucidChart does not support "copy as new" functionality.
The homework is to be turned in via the study system by a group leader.
- A zipped file named
NPRG036-<groupID>-HW1.zip, e.g. NPRG036-T1G4-HW1.zip
- Folder
1 containing domain.svg (or .png) with the image of the conceptual model and domain.txt in UTF-8 containing the structured textual description of the domain model.
-
Common mistakes
-
-
Some of you were still thinking about data in terms of an application, and what the application means, instead of focusing on what the data represents in the real world.
-
Attributes should be primitive values (strings, dates, booleans) of the real world entity represented by the class.
When they are more complex, they typically represent another real world entity and its primitive attributes.
-
Common mistake was including attribute of another real world entity, which should be solved by introducing a new class and a relationship to it.
Typically something, which exists independently of the current entity, and has a label.
For instance, "country" attribute of a "customer".
Country exists independently of the customer.
Country name is an attribute of the "country" real world entity, not of the "customer".
"Customer" lives in a country - is a relationship.
-
Using
1..* multiplicities means that the source entity cannot exist in your data without at least one relationship to the other entity.
For instance, having a food producer connected to their items sold in an e-shop this way means, that when their last item from the e-shop is removed, data about the producer needs to be removed as well.
I.e. there cannot be data about any producers, which (even temporarily) do not have any items... might be problematic.
-
Diagram description should not be a free-text story about what I can see in the diagram. The diagram description needs to
- briefly introduce the domain using a paragraph of text, so that I know what it will be about, and then
- be structured, so that when I am interested in a certain class/attribute/relationship, I can easily find it in the description. See this data specification.
-
Usage of different relationship type/shape than discussed in the tutorial. We use only
- association, i.e. simple line with no shape at the ends, with multiplicity specified at each end, and a name of the association, and
- generalization, i.e. a line with an empty triangle pointing at the more general class, with no name and no multiplicity
Other shapes will not be accepted.