►FR◄ Diagram showing relationships of BOs

[MichaelQ]

I'm a visual kind of guy and being used to ER diagrams etc it's difficult to visualise the structure of an AIM app from just the list of Business Objects. It would be great if AIM could include some sort of diagramming feature which would automatically convey the relationships of business objects, laid out with connecting lines etc.

Michael

[pureist]

Huh? I visualize too.. in my mind.
Aware's data modelling and ease of conceptualizing it in your mind has to be as good and intuitive as it gets, and IMO completely negates any need whatsoever for diagramming.
The fact that you can relate two objects by simply creating an attribute in one, and defining its type as being that of another, is superb.
And thereafter, those attributes, visible whenever you review the list of attributes in those objects, forever serves as a visual reminder of the precise relationship between them,

AND, if you name the attributes appropriately and intuitively, you IMMEDIATELY know the relationship between them: owned, owner, peer, single, multiple, without having to double click on each one to open a dialog.
I agree that the configuration tool could have additional columns which show more settings for each attribute, but you can work around this by naming attributes appropriately and intuitively.

Unfortunately the configuration tool does not allow you to order the attributes hierarchically, which is an annoyance.
If you have a Customer object, then the Address attribute is going to appear in the list of attributes before Name, which creates disharmony in my mind.

So what you can do to get them to sort in a logical order is to prefix each attribute with a letter, a->z. for example, a Customer object's attributes as they would appear if I wanted such an the object:

a_CustID
b_Name
c_Address1
d_Address2
e_Suburb
f_City
g_State
h_Postcode
i_Country
j_ContactName
k_ContactNumber
l_ContactEmail
zzOrders

Any Reference Attribute (multiple) is prefixed with 'zz' to ensure it is sorted to the end cause it is usually logical that such attributes appear at the end, and the double 'z' indicates it is multiple.

The above is much easier to keep ordered in your mind than always seeing them without the prefixing:

Address1
Address2
City
CustID
ContactEmail
ContactName
ContactNumber
Country
Name
Orders
Postcode
State
Suburb

If after all the above you really want diagramming/a 'global' view 'from the helicopter', it is easy enough to take a screen print when an object and its list of attributes is on screen and paste this into a Paint file, and then cut and paste an area encompassing the object name and list of attributes into another Paint file, along with the same for all your other objects, and build a Paint file with blocks on it.

Then draw the lines yourself.

Or, in Paint just draw boxes for each object and type the attributes in the boxes which are related to others, and then draw the lines.

I reckon diagramming is superfluous.


What support should take away from your post, cause I'm sure you're not the first to think that way, is:

1. it should be possible to order the list of attributes to be in a logical order
2. there should be additional columns added showing more settings for each attribute, eg.:
...Max. length (if appropriate)
...Multiple allowed (if appropriate)
...Calculated
...Max. length
...etc.

adding these would help provide the global/helicopter view to new customers who are evaluating Aware and trying to get their head around it.

[MichaelQ]

Interesting. That would certainly help.
Are there any other recommended naming best practices?

Thanks
Michael

[pureist]

Mine are not recommended best practice naming conventions.
Mark (eagles) has a document on naming conventions. His suggested conventions don't work for me, but may for you. Send him a PM. It's worth reviewing to see if it adds to or supersedes what I suggested.

Interesting. That would certainly help.
Are there any other recommended naming best practices?
Thanks
Michael

[customaware]

Pureist is right.... these won't suit everyone but it is the principle that important. A consistent naming convention is critical. Especially for reference attributes.

I use and recommend the following prefixes for reference attributes...

ps_ Peer Single (not multiple)
pm_ Peer Multiple
os_ Owns Single
om_ Owns Multiple
ob_ Owned By

Shortcuts..

sc_


In a well structured SaaS app, effectively EVERY BO (there are some exceptions but not many) should be able to be mapped back to the Tenant BO.

Imagine....

Tenant Owns Many Country
Country Owns Many Entity
Entity Owns Many Department
Department Owns Many Resource
Resource Owns Many Booking

Usually Aware developers get into trouble by naming their attributes exactly as above.

So, if you are way down deep in the hierarchy in a Process, say at booking level and you need Bookings of a particular Tenant... You need to search and think and remember which attribute to pick....and if you have a lot of attributes in any particular BO..... you will want to shoot yourself in the head...

FIND Tenant WHERE Booking.Resource.Department.Entity.Country.Tenant=LoggedInTenant

The above is beyond painful.

But.... if the attributes were named as follows....Note.... each BO CAN ONLY BE OWNED BY A SINGLE PARENT!

Country includes attribute ob_Tenant
Entity includes attribute ob_Country
Department includes attribute ob_Entity
Resource includes attribute ob_Department
Booking includes attribute ob_Resource

When building the Process Action code you ONLY need to remember ob... nothing else

FIND Tenant WHERE Booking.ob .... immediately the inspector will show you the right path ob_Resource

followed by .ob again
followed by .ob again etc

FIND Tenant WHERE Booking.ob_Resource.ob_Department.ob_Entity.ob_Country.ob_Tenant=LoggedInTenant

you don't even have to think about what owns what.... it is clear and unambiguous.

[MichaelQ]

Very interesting.
Thank you.

Michael