Support for object modeling

[jmpatton2]

I have a large schema of classes and associations in EA.  I would like to use EA to model complex instances of interrelated objects, but the support for object diagrams seem to be far below the level of sophistication available in class diagrams.

Some specifics:
The schema is an existing one that uses association classes rather than individual fields within the main classes.  I believe the point of this was that changes in associations between objects would not actually change the main objects themselves.

In the class model, much of the information is readily accessible.  All the attributes are listed on the class block, and data types are denoted.  There are windows that list the available relationships between the classes and whether or not they are shown, etc.

When modeling actual objects and instances, all that seems to be available is a "Set Run State" dialog that lists only field names without any other information.  Values for attributes have to be typed in without any regard to the data type. (Text can be entered into integer attributes)
It doesn't seem possible to instantiate specific associations or association classes that match the defined schema.  Links can be drawn between any set of objects.

In essence, it seems that class diagrams are schema aware and tightly tied to the model while object diagrams are included almost as a sketching utility with little linkage to the model.

Is there some method I might be overlooking that would allow me to generate complex instantiations within EA itself.  Otherwise, it seems that I would have to use EA to forward engineer an application that would allow a user to create diagrams of instantiations.

Would profiles, stereotypes, and other such extensions offer a solution or do they simply extend the capabilities of class models only, leaving object models the same?

Does anyone have any suggestions as to how to do this?

Thanks,
-James

[jeshaw2]

I need help understanding your question.  Why do you want to model at the object level.    Objects only exist at run-time and there can be thousands of them!  In an object model, each of the thousands objects would need their own diagram element. To my mind, that is a lot of work with limited benefit.

Objects don't have Attributes, they have Slots.  Associations don't exist at the object level;  objects have Links to other objects.
Further, if you can justify modeling at the object level, why bother with class specifications?

Sorry, but I'm sooo confused...

Jim

[jmpatton2]

Here's an example.

Let's say I want to model a computer center.  At the class level, I can define a schema that describes the various classes (disk drive, RAID system, server, processor, network port, etc.) and their associations (a RAID system owns some number of disk drives, etc.)

EA lets me model this schema and can assist with developing a software application that makes use of the schema.

Now say I want to design systems using this schema.  These objects would be instantiated classes.  An object diagram could represent a physical installation of hardware with serial numbers, etc.  The number of objects and links is non-trivial, but it wouldn't be in the tens of thousands.
Since EA already has the schema model and supports object diagrams, it seems like I should be able to use that capability.  

Otherwise it seems like I use EA to model the schema and end up developing an application that's almost identical to EA that lets one drag and drop instances of the classes onto a canvas, fill in the details, and connect the links.

Another option is to transform the schema into an XML schema (XSD) and use some type of graphical XML tool to generate the instance documents.

Is that any clearer?

Thanks,
-James

[«Midnight»]

Quite correct Jim,

Perhaps James is doing something along the lines of a CWM implementation, where the M1 metamodels are often large arrays of objects.

This is the kind of thing discussed in:
http://www.amazon.com/Common-Warehouse-Metamodel-Developers-Guide/dp/0471202436/ref=pd_bbs_sr_1/102-4766819-5764933?ie=UTF8&s=books&qid=1179975726&sr=8-1
Not for the faint of heart by any means, but quite effective nonetheless.

David

[jeshaw2]

Well, I've not done anything with the CWM so I can't help with that.  But there are some aspects of what James is saying that brings UML 2.0 Composite Structure Diagrams to mind.  If that diagram type is not useful, I'll stand back and perhaps learn something new from this thread.  Also, I'm beginning to challenge my understanding of his use of the term Schema in this context.  
James, your added explanation was helpful, but I'm just not there yet.  Sorry...

[jmpatton2]

Here's a quick and very dirty example.

What I call the schema is the class diagram level:



Here is an example object diagram:



Creating the object diagram was MUCH more difficult than creating the class diagram.  It seems like it could be made much easier. Also, there is no checking for the values set in the run state, as can be seen on Bertha's disk drive.

I couldn't seem to get the association class connectors to work right in the object diagram either.

UML diagrams are a nice standard way of representing information.  I was hoping to be able to harness EA to create UML object diagrams based on a class model.

If the class model could be wrapped up in a profile or something, then EA would be the end user application for creating object models.  This is for in-house use, and the company has standardized on EA for software development. If it was easy to create correct object models, then we could just buy more EA licenses rather than having to develop and maintain a complicated application.

[jeshaw2]

Ah ha!  EA as a Product Configurator?  Very creative...

First off, read Boch on Composition Model.  Its the closest UML 'thingy' I've seen to your object model.  As a general rule, if you want to do something with EA, it is helpful be compliant with UML.

First off, your object diagram example conflates entity, an entity's specification, and an entity's identity.  I mean, is Bertha an object or a class?  If Bertha is a specification of how an offered product is configured, its a class, not an object.  On an object diagram, relations between objects and classes are generally Generalization/Specialization relationships, not <<hasA>> relationships.  If, however, Bertha is a specifically manufactured (read:  instantiated) computer, then the term Bertha is an object's identity.

Links on an object diagram are analogous to Associations on a class diagram, but they are different:

• Links are instantiations of associations
• Links only have multiplicities of [1] at each end of the link

On an object diagram, an association class appears as an association object with links to the objects being associated. The links are not drawn directly between the objects being linked; not as you have them in your object diagram. This is analogous to associative tables in Relational Theory.  That's why the association object is disassociated from the link you've drawn.

If the Composition Model is not for you, you might investigate the use of Patterns in EA.  Others here in the forum are more capable of discussing Patterns with you than I.

Sanity check time...How am I doing?
Jim

[jmpatton2]

First off, read Boch on Composition Model.  Its the closest UML 'thingy' I've seen to your object model.  As a general rule, if you want to do something with EA, it is helpful be compliant with UML.

Excellent article!  That's why I have been trying to do this in UML.  I'd like to do as much as possible with EA.

First off, your object diagram example conflates entity, an entity's specification, and an entity's identity.  I mean, is Bertha an object or a class?  If Bertha is a specification of how an offered product is configured, its a class, not an object.  On an object diagram, relations between objects and classes are generally Generalization/Specialization relationships, not <<hasA>> relationships.  If, however, Bertha is a specifically manufactured (read:  instantiated) computer, then the term Bertha is an object's identity.

Bertha is an instantiated computer.  Perhaps it should have been put in as a slot filling the "Name" attribute.

Links on an object diagram are analogous to Associations on a class diagram, but they are different:

    * Links are instantiations of associations
    * Links only have multiplicities of [1] at each end of the link

On an object diagram, an association class appears as an association object with links to the objects being associated. The links are not drawn directly between the objects being linked; not as you have them in your object diagram. This is analogous to associative tables in Relational Theory.  That's why the association object is disassociated from the link you've drawn.

Ah! Makes sense. I was wondering about that.

Now if it were only easier to create object diagrams.
You'll notice on the disk drive object linked to Bertha, there is no type enforcement or enumeration support for instantiated attributes (slots I guess?).

[jmpatton2]

First off, read Boch on Composition Model.  Its the closest UML 'thingy' I've seen to your object model.  As a general rule, if you want to do something with EA, it is helpful be compliant with UML.

I've been trying follow some of the recommendations in this article, but EA doesn't seem to match certain behaviors.

In the author's text, parts in composite objects (instances) are underlined, but EA doesn't seem to do this.  Also, it doesn't seem to instantiate connectors.

Is EA support for composite diagrams and objects missing stuff, or did the author just improvise the drawings?

Thanks,
-James

[jeshaw2]

Boch wrote his article before the UML 2.0 Specification was finalized and accepted by the OMG.  Have you reconciled what you are attempting to do with the finalized UML 2.0 specification document?  IF EA is at odds with that, you need to make a bug report to Sparks; for they assert compliance with the specification, not Boch's paper.

[KP]

In the author's text, parts in composite objects (instances) are underlined, but EA doesn't seem to do this.

Parts and instances aren't the same thing. Instance names are underlined, part names aren't.

[jmpatton2]

Then how would one create a diagram such as figure 9.26 in the UML Superstructure Specification v2.1.1 (page 192)
http://www.omg.org/docs/formal/07-02-03.pdf

[KP]

Then how would one create a diagram such as figure 9.26 in the UML Superstructure Specification v2.1.1 (page 192)
http://www.omg.org/docs/formal/07-02-03.pdf

For starters, Ctrl+Drag the Car class element from the Project Browser onto the diagram and select "Paste as Instance", then do the same thing four times for the Wheel class element.

[jmpatton2]

Ok, I'm really confused now.

From the EA Help File under:
The UML Language
UML Diagrams
 Structural Diagrams
  Composite Structure Diagram
   Properties

A property is a nested structure within a classifier, which is usually a class or an interface. The contained structure reflects instances and relationships reflected within the containing classifier. Properties can have multiplicity.

To demonstrate properties, consider the following diagram, which demonstrates some properties belonging to the library class.

There are two parts, libBooks and records, which are instances corresponding to the classes Books and Computer respectively. After dragging parts from the toolbox out to the workspace, right-click on a part and select Advanced | Set Property Type to link to a classifier.

So I create a Composite Structure Diagram and add the class "Library" to it:





Then, so that the classes Books and Computer exist, I create them in a class diagram:





Then, following the help file, I drag Parts from the toolbox onto the workspace:





Next, I set the property types accordingly:





After setting the visibility of the parts to include their type information, I get:





I then set the multiplicity of the libBooks part and create the barcode connector:





Then, to create an instance of the Library, I drag the class onto an object diagram, filling in the dialog box as follows:




And I get this:





After fixing the size, setting the feature visibility to show the types, and adding the connector I get this:




If I want to instantiate another Library, I can drag it from the project browser as before, and have to fix the formatting, visibility, and recreate the connector.

If I instead select everything, hit copy, then paste as new, it creates the new object and parts but does not create the connector/link or whatever it's called.  Isn't there some way of creating instances of configured objects?  Why can't connectors/links be replicated like the objects/parts are?

If I drag the class Books or Computer from the Project Browser another class "NewLibrary", it asks if I want them to be ports or parts.  If I drag the class onto the general diagram space as an instance, then drag it into the composite class "New Library", it shows up all nice and underlined, but when I then drag the "New Library" class onto the object diagram, the internal classes are no longer present.  They don't show up on the list of embedded elements regardless of whether or not "Show Owned/Inherited" is checked.

Is this just fundamentally a wrong approach?  It seems to follow the help file example.  Is there a better way?

[jmpatton2]

Are composite structure diagrams only partially supported?
Several books say that a main class with internal parts typed to other classes is equivalent to those other classes being connected to the main part via aggregation composite associations (black diamond notation).

EA doesn't seem to treat them the same though.  I tried some experiments with code generation, and the output never seemed to contain anything that referenced parts.

Are these things just for diagrams?