(Re-)Engineering a domain model (Activity)

Overview

Title	(Re-)Engineering a Domain Model
Overview	This activity lets students develop a domain model in UML notation. This is an activity used in the Requirements Engineering course. It is based on the "Domain Models" lecture slides and can be conducted individually or in small teams.
Prerequisites
Learning Objectives	After successfully completing this activity, the learner should be able to: Develop a domain model for a system under development.
Process Skills Practiced	Information Processing

Background

In problem solving and software engineering, a domain model is a conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain.

• Background reading material:
  • "Domain Models" lecture slides
  • Domain modeling for software engineering by N. Iscoe, G.B. Williams, and G. Arango
• Rationale for this activity: Use cases and later development artifacts are easier to develop once the domain model is clearly delimited.

Directions

1. In the lecture "Domain Models" we learned about how to develop domain models for a system under development. In this activity, you will reengineer a domain model for the OpenMRS system.
2. Make a list of candidate domain classes - identify nouns.
3. Draw these classes in a UML class diagram.
4. If possible, add brief descriptions for the classes.
5. Identify any associations that are necessary.
6. Decide if some domain classes are really just attributes.
7. Where helpful, identify role names and multiplicity for associations.
8. Add any additional static rules as UML notes that cannot be conveyed with UML symbols.
9. Group diagrams/domain classes by category into packages.
10. Diagrams have to be accompanied by explanatory text. It will not be possible to transport all the information you want in a diagram with only little “bubbles” and arrows, so please write a few paragraphs that help understand how to read and understand your diagram and the goals in there. In that description, also make clear which stakeholder is the issuer of that goal.
11. Please also provide your description of the rationale for your process, at least two paragraphs of how you did it and what you found difficult or the most challenging aspect of it.

Deliverables

• A PDF of a UML domain model with explanatory text and a reflection on the work results.

Notes for Instructors

The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.

Assessment

• How will the activity be graded?
  • The deliverable will be graded as one part of the requirements specification.
• How will learning will be measured?
  • The quality of the application of the learned technique gives an indicator of how well the student has understood the technique and depending on the instructor, there can be a resubmission of the deliverable after initial feedback, so that the learning and the grade can be improved.
• How will feedback to the student be determined?
  • The student receives written feedback on their submission.
  • Submitted solutions can be discussed in class (probably anonymizing them, according to classroom code of conduct)

Assessment questions:

• Can I (picturing myself as a developer) easily understand what the domain is about?
• Do I see what the most important other systems are?
• Is the model described and illustrated to an adequate degree of detail?
• Is a description provided about the rationale and challenges?

The form of the assessment is expected to vary by assignment. One possible format is the table:

Criteria	Level 1 (fail)	Level 2 (pass)	Level 3 (good)	Level 4 (exceptional)
Completeness	Important domain elements (like other systems) are missing, description is minimalistic and incomplete.	Important domain elements are present with a basic description of everything in the diagram.	Domain elements are arranged in diagram with differentiated packages; complete description of all elements.	Domain elements are all identified and arranged in diagram with differentiated packages; all described well in detail.
Correctness	Elements are not identified and denoted or mainly incorrectly so.	Elements are identified and denoted correctly to at least 50%.	Elements are identified and denoted mostly correct and the majority of their details is accurate.	Elements are identified and denoted correctly in all their details as well as their relationships to each other.
Understandability	Diagram is missing, illegible, confusing or plain wrong.	Diagram is rudimentary but shows a clear structure of elements and their relations.	Diagram is well-structured and easy to understand in its relations between the elements.	Diagram is easy to understand, very well structured and nicely visualized.

Comments

• What should the instructor know before using this activity?
  • This activity is simple and easy to handle for most students.
• What are some likely difficulties that an instructor may encounter using this activity?
  • None encountered.

Suggestions for Open Source Community

None so far.