A StarUML MetaModel

JSON

Assume we use StarUML create a project called HR:

StarUML saves the project in a file called hr.mdj. This file contains a single JSON object that reflects the tree-like structure depicted in the explorer panel to the right of the diagram. You can get a collapsible/expandable look at this huge object by pasting the contents of the file into a JSON formatter/validator.

Here's the basic structure of the JSON object contained in hr.mdj:

{

   "_type": "Project",
   "_id": "AAAAAAFF+h6SjaM2Hec=",
   "name": "HR",
   "ownedElements": [
      {
         "_type": "UMLModel",
         "_id": "AAAAAAFF+qBWK6M3Z8Y=",
         "_parent": {
            "$ref": "AAAAAAFF+h6SjaM2Hec="
         },
         "name": "entities",
         "ownedElements": [...]
      }
   ]
}

We can see that the top-level JSON object, which represents the entire project, has four fields: _type, _id, name ("HR"), and an array of owned elements.

The array contains a single JSON object representing the project's only model: entities. It too has _type, _id, name, and ownedElements fields as well as a _parent field containing a reference to the _id field of its owner, the HR project.

The entities model owns five elements corresponding to main (the class diagram) and the four classes: Company, Employee, Programmer, and Manager.

The class diagram object is long and complicated. For each box, arrow, and label in the diagram it describes in detail things like position, size, color, font, etc. Fortunately, we can skip this part. We're concerned with logic not geometry.

Next come the four class objects. Here's the JSON object representing the Employee class. Notice that it has arrays holding its owned elements (only the association to the Manager class), its attributes (salary, name, and id), and its operations (job and nextID).

{
   "_type": "UMLClass",
   "_id": "AAAAAAFLhnPAnH64Mg8=",
   "_parent": { "$ref": "AAAAAAFF+qBWK6M3Z8Y=" },
   "name": "Employee",
   "ownedElements": [...],
   "visibility": "public",
   "attributes": [...],
   "operations": [...],
   "isAbstract": true,
   "isFinalSpecialization": false,
   "isLeaf": false,
   "isActive": false
}

Our Employer-Manager association doesn't have a name (although it could). Here's what it looks like:

{
   "_type": "UMLAssociation",
   "_id": "AAAAAAFLhn7ApIEXikk=",
   "_parent": { "$ref": "AAAAAAFLhnPAnH64Mg8=" },
   "end1": {...},
   "end2": {...},
   "visibility": "public",
   "isDerived": false
}

Recall that each association has two endpoints. End1 is the side connected to the Employee class, end2 connects to the Manager class. The reference number is the id of the associated class: Here's the end2 object:

{
   "_type": "UMLAssociationEnd",
   "_id": "AAAAAAFLhn7ApIEZWH8=",
   "_parent": { "$ref": "AAAAAAFLhn7ApIEXikk=" },
   "name": "boss",
   "reference": { "$ref": "AAAAAAFLhnRuDX7f/d0=" },
   "visibility": "protected",
   "navigable": true,
   "aggregation": "none",
   "multiplicity": "0..1",
   "isReadOnly": false,
   "isOrdered": false,
   "isUnique": false,
   "isDerived": false,
   "isID": false
}

Here's the salary attribute:

{
   "_type": "UMLAttribute",
   "_id": "AAAAAAFLhnUQgX8HarU=",
   "_parent": { "$ref": "AAAAAAFLhnPAnH64Mg8=" },
   "name": "salary",
   "visibility": "protected",
   "isStatic": false,
   "isLeaf": false,
   "type": "double",
   "isReadOnly": false,
   "isOrdered": false,
   "isUnique": false,
   "isDerived": false,
   "aggregation": "none",
   "isID": false
}

Here's the nextID operation, it contains an array of parameters:

{
   "_type": "UMLOperation",
   "_id": "AAAAAAFLhncCz38rbt0=",
   "_parent": { "$ref": "AAAAAAFLhnPAnH64Mg8=" },
   "name": "nextID",
   "visibility": "private",
   "isStatic": true,
   "isLeaf": false,
   "parameters": [...]
   "concurrency": "sequential",
   "isQuery": false,
   "isAbstract": false
}

The return type of an operation is considered to be a parameter with direction = "return":

{
   "_type": "UMLParameter",
   "_id": "AAAAAAFLhnclH38yalQ=",
   "_parent": { "$ref": "AAAAAAFLhncCz38rbt0=" },
   "visibility": "public",
   "isStatic": false,
   "isLeaf": false,
   "type": "int",
   "isReadOnly": false,
   "isOrdered": false,
   "isUnique": false,
   "direction": "return"
}

A UML Meta-Model

Use StarUML to create a UML meta-model. Your model should include classes for each of the types mentioned above. Each class should contain the attributes mentioned above. References should translate into associations. Do not include diagrams in your model. If more information is needed, simply create a diagram and look at the JSON representation.

Hints:

It might be helpful to introduce an abstract UMLElement class. For example, here's a start to my model:

If a diagram gets too busy, break it into several diagrams (but not too many). Remember: the same element can be included in multiple diagrams. Don't be tempted to replicate any elements.