Portaview — Constructing Object Models with UML++

The following task provides students with a case description that is supposed to confront students with modeling challenges commonly encountered in modeling practice. The case description follows the L.I.C.I.A. guidelines proposed in Maier and Kadziolka (2026). Students themselves must identify instance-level information as such and construct adequate abstractions over them. Two variants of the case description exists, variant A and variant B. The video explains key modeling decisions for variant B in German. Further educational materials for UML++ and UML-MX are available here.

• • Download Case Description Variant A: English, German
  • Download Case Description Variant B: English, German
  • Download Reference Solution for Variant B as PDF: English (with additional objects), German
  • Download Reference Solution for Variant B as UML++ Model for XModeler^ML: English (with additional objects), German

 

The L.I.C.I.A Guidlines

In the following, each of the five L.I.C.I.A. guidelines is listed and an example from the Portaview case description illustrating the respective guidelines is provided. A more comprehensive justification and description of each guideline is provided in Maier and Kadziolka (2026).

L – Label Ambiguity

Guideline: The case description should include ambiguous references to domain concepts.

Example in Portaview: References to the concept of an account are ambiguous, employing in the English translation to the terms ‘user,’ ‘account,’ and ‘channel.’

 

I – Irrelevant Domain Information

Guideline: The case description should contain domain information not required for the modeling
problem at hand.

Example in Portaview: Information about the Portaview platform itself or about users watching videos is irrelevant to the UML class diagram.

 

C – Construct Ambiguity

Guideline: The case description should avoid a clear mapping between domain information and modeling constructs.

Example in Portaview: The representation of subscriptions as a modeling construct is left ambiguous; they can be represented either as a self-referential association between users or as a separate class associated to a user class.

 

I – Incomplete Domain Information

Guideline: The case description should leave some aspects of a modeling solution unspecified.

Example in Portaview: Multiplicities for some associations, such as between playlists and videos, are left unspecified.

 

A – Abstraction Level Entanglement

Guideline: The case description should include information referring to different levels of abstraction.

Example in Portaview: Information about the start date and monthly fee of subscriptions is provided through the specific subscription of Denise to Jestful71.

 

References

 

Initial Observations of Student Solutions for Portaview Case Description

To explore the educational implications of the L.I.C.I.A. guidelines, we conducted three sets of exploratory studies over multiple semesters using the Portaview case descriptions. In Case Study I, 29 students completed variant A as a home assignment using XModelerᴹᴸ and FMMLx. In the Think-Aloud Study, 12 students were given 30 minutes to complete variant B using UML-MX while their modeling process was monitored through screen recordings and tool logs. In Case Study II, 30 students completed variant B as a home assignment using UML-MX.

In total, we collected 71 submissions. However, the 12 submissions received as part of the Think-Aloud Study must be interpreted carefully, as the 30-minute time limit turned out to be too short for students to provide reflected modeling solutions.

The table below provides an overview of key modeling flaws and their number of occurrences for each iteration of the study. Note that not every counted flaw expresses an inadequate modeling solution; some detected flaws indicate generally noticeable deviations from our envisioned reference solution.

 

Guideline	Detected Modeling Flaw	Case Study I (n=29)		Case Study II (n=30)		Think-Aloud Study (n=12)		Total (n=71)
		Number	%	Number	%	Number	%	Number	%
Label Ambiguity	inadequate reconstruction of ambiguously referenced domain concepts	16	55.2%	12	40.0%	8	66.7%	36	50.7%
Irrelevant Domain Information	irrelevant class(es) added	4	13.8%	1	3.3%	7	58.3%	12	16.9%
	irrelevant association(s) added	11	37.9%	4	13.3%	4	33.3%	19	26.8%
Construct Ambiguity	concept incorrectly modeled as attribute	4	13.8%	9	30.0%	7	58.3%	20	28.2%
	missing attributes indicated in case description	6	20.7%	12	40.0%	12	100%	30	42.3%
	incorrect modeling of self-referential class with additional properties (here: modeling of subscriptions)	15	51.7%	22	73.3%	12	100%	47	66.2%
	generalization indicated in description modeled incorrectly	12	41.2%	16	53.3%	1	8.3%	29	40.8%
Incomplete Domain Information	added attributes not mentioned in case description	19	65.5%	9	30.0%	4	33.3%	32	45.1%
	more restrictive multiplicities for associations than intended	16	55.2%	12	40.0%	2	16.7%	30	42.3%
	indicated generalization not added	8	27.6%	9	30.0%	4	33.3%	21	29.6%
Abstraction Level Entanglement	inadequate data type for attribute	9	31.0%	16	53.3%	6	50.0%	31	43.7%
	attribute not modeled despite instance information	11	37.9%	9	30.0%	12	100%	32	45.1%
	operation not modeled despite instance information	24	82.8%	26	86.7%	12	100%	62	87.3%
	induced faulty multiplicities of associations	7	24.1%	4	13.3%	0	0.0%	11	15.5%

 

Flaws Related to Guideline ‘Label Ambiguity’

Approximately half of the submissions (50.7%) reconstructed the ambiguously referenced concepts ‘user,’ ‘account,’ and ‘channel’ differently from the reference solution. Students frequently introduced separate classes for these concepts or overused generalization relationships to handle ambiguously referenced concepts.

 

Flaws Related to Guideline ‘Irrelevant Domain Information’

In contrast, flaws related to irrelevant domain information occurred less frequently. Only 16.9% of submissions added a class representing the platform Portaview, while 26.8% added irrelevant associations, most prominently a ‘watches’ association between users and videos.

 

Flaws Related to Guideline ‘Construct Ambiguity’

Construct ambiguity produced the largest variety in the submitted solutions. Students differed in deciding whether domain concepts should be represented as classes, associations, or attributes. Many submissions accounted for short videos by adding a Boolean attribute to a video class instead of adding a separate subclass for short videos. Several submissions missed attributes that were indicated in the case description but not stated explicitly. Many students also struggled immensely with adequately modeling user subscriptions; we consider a total of 66.2% of submitted solutions flawed in this regard.

 

Flaws Related to Guideline ‘Incomplete Domain Information’

Regarding incomplete domain information, students regularly completed missing information by making their own modeling assumptions. For example, some submissions added attributes for playlist IDs or user registration dates. At the same time, students did not always make adequate assumptions about the domain. A total of 42.3% of submissions specified association multiplicities more restrictively than intended.

 

Flaws Related to Guideline ‘Abstraction Level Entanglement’

Finally, abstraction level entanglement was reflected in flaws when abstracting from instance-level information. Inadequate data types occurred in 43.7% of submissions, while 45.1% missed attributes and 87.3% missed operations indicated by instance-level information. Moreover, 15.5% of submissions missed multiplicities implied by the provided instances.

 

Overall, these initial observations suggest that the modeling decisions introduced in the case description because of the L.I.C.I.A. guidelines are not straightforward for all students. While the frequency and intensity of observed modeling flaws may vary in other teaching contexts, our initial observations indicate that L.I.C.I.A. case descriptions can help uncover them.