Author Topic: Attribute Values on a Domain Model (Read 12516 times)

Dorian Workman · « **on:** March 05, 2009, 06:08:34 pm »

I am a Business Analyst and am drawing class diagrams to model the business domain. I identify attributes of business objects, and I want to know how I define an attribute's 'domain', i.e. its permitted values, in EA.

The notation I was taught was to put the attribute's domain in square brackets right after its name, e.g.:

Bank Account.status [Open, Closed] - i.e. a Bank Account's status may only be either Open or Closed.

Does EA support defining an attribute's domain in some separate field in the class properties somewhere, or do I need to just include the square brackets and everything inside them in the Name field of the attribute?

Thanks in advance!

Geert Bellekens · « **Reply #1 on:** March 05, 2009, 07:11:50 pm »

The "domain" of an attribute is kept in the Type field.
For a limited set of distinct values you can create an Enumeration. The enumeration holds the values that can be used (e.g. "Open" and "Closed")
Your attribute then has the enumeration as type.
For types with unlimited or very large number of allowed values (such as integer between 0 and 500) you could do two things:

Create a Datatype that inherits from Integer and has a constraint to limit the possible values to the required range. Then use this datatype as the type of your attribute.
Make your attribute as a plain Integer and add a constraint on the attribute to limits its allowed values from 0 to 500

Dorian Workman · « **Reply #2 on:** March 06, 2009, 06:48:05 am »

Thanks Geert. Do you think it is acceptable in an analysis model to simply enter the allowed values directly into the Type field, so they display on the diagram like this?: http://screencast.com/t/pdGjJiQ4Wc

Thanks again.

Geert Bellekens · « **Reply #3 on:** March 06, 2009, 07:03:34 am »

Well, I guess that depends on the what you intend to do with the model and to whom it is targeted.
If your analysis model will only be used to communicate with non-technical Business Users then yes, maybe. I doubt they will have trouble with the fact that the types are in fact not defined.
If you want to use this model as a specification for the developers to follow then no!

Also be aware that what you are doing is in fact not UML compliant, so anyway you might want to document your variation to UML for the ones that come after you.

Dorian Workman · « **Reply #4 on:** March 06, 2009, 08:55:58 am »

Thanks Geert. I am only trying to express the business domain to business people, however technical people will read this (not build upon it though), so I don't want to mislead or confuse people.

There must be a better way to define the list of values that an attribute can have... I think I will just put it in the Attribute Notes field for now, at least that way I am not semantically incorrect.

Thanks again.

Dorian Workman · « **Reply #5 on:** December 04, 2009, 08:24:27 am »

Quote

The "domain" of an attribute is kept in the Type field.
For a limited set of distinct values you can create an Enumeration. The enumeration holds the values that can be used (e.g. "Open" and "Closed")
Your attribute then has the enumeration as type.
For types with unlimited or very large number of allowed values (such as integer between 0 and 500) you could do two things:
Create a Datatype that inherits from Integer and has a constraint to limit the possible values to the required range. Then use this datatype as the type of your attribute.
Make your attribute as a plain Integer and add a constraint on the attribute to limits its allowed values from 0 to 500

Hi Geert,

It's been a while, but I realize now what you were saying in this post. Sorry I wasn't quite with you last time. Does what I've done here match what you're saying please? (I don't know what the actual Claim Status values are yet...)

Thanks.

Geert Bellekens · « **Reply #6 on:** December 04, 2009, 10:33:21 am »

Dorian,

Yes, that looks fine, except for the association to the enumeration "Claim Status".
That is kind of double up. You already have the type of the attribute that links you "Claim" class to the enumeration.
If you want to express the relation between the two classes its better to use a dependency and not an association.

Geert

Dorian Workman · « **Reply #7 on:** December 04, 2009, 11:05:30 am »

Thanks I'll make that change. Appreciate your quick response.

Dorian Workman · « **Reply #8 on:** December 05, 2009, 03:40:47 am »

A related question please Geert (I realize this should probably be in the UML board but figured I should continue this post...)

Can an Enumeration have Attributes? I am trying to express that a Treatment Plan has an Initial Treatment (which is a finite set of values; an enumeration), but then that Initial Treatment itself has attributes, which in turn are enumerations.

Have I modeled this correctly please? It doesn't quite 'feel' right...

Thanks.

Geert Bellekens · « **Reply #9 on:** December 05, 2009, 04:53:20 am »

No, Enumerations don't normally have have attributes.
At my client we call what you need a "Code List".
I think I answered your question in this post:

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1259036724/1#1

Geert

Dorian Workman · « **Reply #10 on:** December 07, 2009, 05:57:34 am »

Thats's perfect thanks Geert.

Eve · « **Reply #11 on:** December 07, 2009, 08:59:14 am »

UML allows enumerations to own attributes. They extend DataType which has associations for ownedAttribute and ownedOperation. The only programming language that I know that supports this is Java. (And java has attributes and operations on enumeration literals)

Although, certainly it isn't normal.

Dorian Workman · « **Reply #12 on:** December 29, 2009, 03:15:48 am »

Quote

No, Enumerations don't normally have have attributes.
At my client we call what you need a "Code List".
I think I answered your question in this post:

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1259036724/1#1

Geert

Hi Geert,

I must admit I don't think I fully grasp the meta-model you posted here: http://hosted.umlcanvas.org/Meta_enum (I am an Analyst not a Developer, so please forgive me...). I think I grasped enough to update my model though.

If you take a look at the diagram below, I am trying to capture that when a Contact Role of type "Employee" is selected by the user (for example), there is additional info pertinent only to that Contact Role type of Employee that must be captured. That additional info is modeled in the Employee class, which is linked to the Contact Role Type enumeration class using a Dependency.

Is this correct please? Thanks.

beginner · « **Reply #13 on:** December 29, 2009, 07:00:11 am »

Hi Dorian,
this looks great. Would you share a secret and tell me how you you created these open rectangles near the attributes??

Thanks and cheers,

b.

Dorian Workman · « **Reply #14 on:** December 29, 2009, 07:14:46 am »

Sure.

1. Make sure you have EA v7.5 or greater (doesn't work pre-7.5).
2. Create a connector between any two classes.
3. Right-click on the end of the connector closest to the class where you want the open rectangle to appear and select 'Link to Element Feature'.
4. Select 'Attribute', and then the specific Attribute you want.

Voila.

Sparx Systems Forum

News: