CoUML

This article or section is currently under construction

In principle, someone is working on it and there should be a better version in a not so distant future.
If you want to modify this page, please discuss it with the person working on it (see the "history")

Draft

Definition

coUML is a UML-based educational modeling language that can be used in any stage of the course design and development process where visual models and structured descriptions of the current and planned design are useful to the design team.

coUML is a learning design language based on UML. It uses existing formalisms and adds its own extensions.

The language

Overview

Requirements

According to Derntl & Motschnig, 2007:156), CoUML emerged from practise i.e. it is rooted in the authors' own practice. coUML emerged in a timespan over several years and was published in 2007 with the following requirements and needs:

• Support for local and temporal activities, including decisions and concurrency
• Activities can be modelled at different levels of detail
• Roles can be attached to activities
• Most learning activities "consume" or "produce" documents of various kinds
• Learning goals can be modeled and linked to activities
• Activities can be tagged either "web-based", "blended" or "presential".

coUML modeling artifacts

coUML models a course design with thre kinds of artifacts:

(1) Primary:

• The course activity model (CAM) describes the course's activities. The CAM uses an extension of UML activity diagrams.
• The optional concurrent course structure model (CSM) describes more complex course designs. This CSM describes module dependencies with arrows (like in a UML class diagram).

(2) Secondary:

• A Roles model describes roles (e.g. tutor, student) and optionally relations between roles. Role are described with use case diagrams.
• The goals model explicitly state learning goals and optionally their relationship. Learning goals are described with elements of UML class diagrams.
• The documents model can list the documents used and optionally attach documents to roles (i.e. producers and consumers).

(3) Auxiliary:

• The Course Package Model (CPM) includes an optional high-level description of the course, i.e. a tabular fact sheet: Course name, summary, structure, presence mode, online support, participants, teaching staff, instructional strategy, and a list of included coUML CAM and CSM models.

coUML use and recommended procedures

According to Derntl & Motschnig, 2007:159-260), coUML can be used in several ways

(1) To model completed course design implies for exampels the following steps:

1. Create the CAM, i.e. the activities' model first.
2. Create secondary models, i.e. role, goal and documents models according to available information.
3. Refine the CAM to include elements from step 2.
4. Create a CSM (course structure overview model) for the final CAM
5. Create the CPM overview model

(2) The authors (159-160 also claim that coUML could support the ADDIE model:

1. Analysis phase: The CPM fact sheet can be used to write down the inital map. Also initial sketches of course structure, activities structures, gloals roles can be made with CSM/CAM
2. Design Phase: Can use all of the coUML modeling artifacts
3. Development Phase: Developers can use the models made in the design phase, i.e. they represent the contract between instructional designers and developers.
4. Implementation Phase: In particular the CAM and the document model can be used to prepare trainers (and students).
5. Evaluation Phase: Evaluation procedures can be informed by the goals model and be modeled with CAM.

The course package model (CPM)

The course package model (CPM) is both an overview and an entry point to all coUML artifacts created for a course design. It's mainly a fact sheet, but it also is modeled as something that includes other packages, i.e. models.

The fact sheet

The CPM fact sheet includes typically eight parameters that are described in two colums. A designer may leave out a parameter or add his own if needed.

Course package model fact sheet overview

Course name
Summary	Description
Structure	Verbal Description of the blocks or modules, e.g. their number
Presence mode	List one or more of: blended, presential and on-line
Online support	Describes the learning environment and other tools
Participants	Number of students and their typical background.
Teaching staff	List of ...
Instructional strategy	Verbal description of a global strategy and the various types of module strategies (if there are)
coUML models	List of models used (same information as in the CPM class diagram.

The formal model of the CPM just includes the list of created coUML models as in this figure.

CPM Class diagram model

We are not sure if this is really interesting information to a designer.

Secondary models

These models can be created, but must not. As you can see, even a very simple document model such as the one that we use for our Flash courses in this wiki, becomes fairly complex.

Roles modeling

Roles can modeled with UML class diagrams that show various relations between participants. In particular, there are three types of relationships.:

• Aggregation, e.g. a group that is composed of 4 students
• Generalization, e.g. Instructor and Tutors are Teaching persons
• Depencencies, e.g. a Tutor supports the Instructor or Supertutor monitors the tutors

In the simple figure below, we model the following actors and relationships:

• The instructor assigns tasks to the class (UML stereotype = "assign tasks"
• the tutor supports the instructor
• the tutor helps the class
• he class is decomposed in groups and the groups in students (aggreations)

Class diagram of roles model

Goals modeling

The Goal model can describe learning goals and their relationships. It can later be integrated in the CAM model. There exist the following relationships:

• Aggregation: A goal can be decomposed in subgoals. Drawings are lines with a lozenge
• Dependency: One goal plays a role in achieving the other. Such relations are drawn with dashed dependency arrows and labelled with two sorts of stereotypes:
  • <<require>> means that a goal requires another one to achieved first
  • <<support>> means that working towards a goal can support the achievement of another.
• Generalization: A goal is refined by more specific goals, e.g. "writing research papers" includes the more specialized "writing an empirical research paper". The general properties of writing research papers also apply to the more specific kinds of papers.

The following diagrams shows a simple hierarchy of goals for part of a Flash course. For instance:

• In order to create a Flash movie clip, one should learn how to draw simple shapes, how to create symbol instances and creating animations
• Knowing how to draw simple shapes supports doing animations.
• In order to created a guided motion animation, a learner must know how to use the pen tool
• There exist three kinds of motion animations: Frame-by-frame, motion tweening and guided motion tweening.

Example class diagram of a partial goals model

Notice: Top left corners of goals can include a simple identifier, e.g. a number or letter.

Documents modelling

The document model should show a structured overview of all documents provided, used and created in a course. It also can include roles (users). Again, each document is modeled as a class. Relationships that can be expressed are of two types:

• Grouping, e.g. related kinds of documents.
• Aggregation, e.g. chapter, sections, sub-sections
• Dependencies
  • role to document dependency: user is creator or providor
  • document to role dependency: user is consumer (or addressee)
  • bidirectional dependency: user is both provider and consumer

The following example shows a package for a Flash course. It includes four kinds of documents:

• Flash tutorials in this wiki
• *.fla code examples on a web server that are associated with Flash tutorials. (Actually not shown here, there are other files)
• Syllabus pages. Each week's program and activities are in a different wiki page. Each of these pages must point to tutorials
• Discussion pages. For each syllbus page there is a discussion page. This relationship is not shown here.

We also model three types of users:

• The instructor writes flash tutorials and creates fla code examples. Since all these elements are done by the teaching team itself, it probably would have been better to just draw an arrow to the "Flash tutorials" grouping box. Same for the teaching assistant.
• The teacher creates the course program, but the assistant only should read it.
• Students can read, but also modify flash tutorials, but not the examples

Example class diagram of a partial goals model

Notice:

• coUML uses dotted lines between roles and documents (i.e. UML dependencies) to model relationships. We used associations instead for practical reasons. Solid lines are easier to read and they can be bi-directional. Dependencies cannot in our drawing tool.
• The example above is far from being complete. E.g. the flash files that students produce and upload as well as their little reports are missing from the model.

In addition (or alternatively) a designer can create a tabular overview of documents.

Course document list
ID	Name	Type	Provider	Deadline
1	Flash drawing tutorial	Wiki page	Instructor	Week 1
2	Flash fbf tutorial	Wiki page	Instructor	Week 2

The course Activity Model (CAM)

The CAM is the most important artifact of a coUML model. The number and depth of activities to be modeled is completely open to the designer. CAM uses an extension of UML activity diagrams.

This CAM model uses a number of syntax elements:

(1) A single starting Node

This node that is labelled with the name of the activity (e.g. the module name or course name) represents the beginning of an activity and is connected with an activity node.

(2) One or more End Nodes

An end node models the official end of an activity and it must be connected to an activity node (see below)

(3) Activities

Activities are performed by roles (e.g. the teacher or a student) and represents either a relatively elemental task or a more complex task that doesn't need modeling. See also sub-activities below. There exist three kinds of activities:

• Web-based
• Presential
• Blended

(4) Subactivities

(5) Transitions

(6) Decisions

(7) Concurrency

(8) Temporal constraints

In addition a CAM model can be extended with secondary artifacts, i.e.

(9) Roles.

• Are modelled with SwinLines

(10) Documents

(11) Goals

Discussion

(To be written).

• Somewhere the authors claim that coUML is a pedagogically neutral language. This may be true in theory, but defintely not in practice. UML is closely related to the way Java programmers think and this has an impact on how relations can be specified.

For instance, in the document model, it is not possible to state that a teacher writes and provides a document and that learners should make small corrections in the documents. An other example are swimlines that can depict roles but not role switching very well.

• Even simple pedagogies may become very complex when spelled out with coUML. A good compromise of detail must be found. However, without details, a model can not be compiled (as for exemple in a learning design editor).

Links

• Beauty and Precision in Instructional Design (slides). Derntl, Michael; Pat Parrish & Luca Botturi, EdMedia 2008.

• The Person-Centered e-Learning Pattern Repository. If you browser through this site, you will find several kinds of diagrams, in particular UML activity diagrams that describe various kinds of pedagogical scenarios. Since the first publication about coUML is more recent, some of these diagrams may not be fully coUML compatible, but I don't know. Anyhow, look at this website if you are interested in modeling various kinds of educational scenarios and teaching models - Daniel K. Schneider 11:11, 16 January 2009 (UTC)

Bibliography

• Derntl Michael & Renate Motschnig (2007). coUML - A Visual Language for Modeling Cooperative Environments. in L. Botturi & T. Stubbs, Handbook of Visual Languages for Instructional Design: Theories and Practices, Information Science Reference, 155-184. ISBN 1599047292. (This handbook is fairly expensive and there don't seem to be alternatives for the moment to learn about coUML, except looking at somewhat older publications and the The Person-Centered e-Learning Pattern Repository we site.

• Botturi, Luca; Daniel Burgos, Manuel Caeiro, Michael Derntl, Rob Koper, Patrick Parrish, Tim Sodhi, Colin Tattersal (2007). Comparing Visual Instructional Design Languages, A Case Study, in L. Botturi & T. Stubbs, Handbook of Visual Languages for Instructional Design: Theories and Practices, Information Science Reference, 155-184. ISBN 1599047292

• Derntl, M. & Botturi, L. (2006). Essential Use Cases for Pedagogical Patterns. Computer Science Education, 16 (2), 137-156

• Derntl, M. & Motschnig-Pitrik, R. (2005). The Role of Structure, Patterns, and People in Blended Learning. The Internet and Higher Education, 8 (2), 111-130

• Derntl, M., & Motschnig-Pitrik, R. (2003). Employing Patterns for Web-Based, Person-Centered Learning: Concept and First Experiences. Proceedings of ED-MEDIA 2003 - World Conference on Educational Multimedia, Hypermedia & Telecommunications, Honolulu, HI, USA.

• Motschnig-Pitrik, R., & Derntl, M. (2005). Learning Process Models as Mediators between Didactical Practice and Web Support. Proceedings of Conceptual Modeling - ER 2005: 24th International Conference on Conceptual Modeling, Klagenfurt, Austria, LNCS 3716, Springer Verlag, pp. 112-127.

Acknowledgement: This article or part of this article has been written during a collaboration with the EducTice group of INRP, which attributed a visiting grant to DKS in january 2009.