Package for Class Groups

[Stasch]

Can you use a Package as a Parent Class.  For Instance, A company has many systems to run the business.  Can you indicate the company as a package, and all the systems inside as classes, or should the company be indicated as a class - how would you indicate that?

It seems to me you would use packages to notate the system types, such as Accounting, MFG, etc...  

Can in incorporate the following structure.

Company - Package
     Account System - Package
             TurboTax - Class
     MFG - Package
             MRP - Class

Is there a fine line here?

[«Midnight»]

You could use packages to indicate, as an example, subject classification. This is a very different concept of "ownership" than you encounter in a class model. More along the lines of a 'contains' rather than a 'has' relationship.

Go with classes for each (and every) business entity. Then use the appropriate connectors to describe their relationships.

Try developing the most granular classes first, even if they are only a shell at this point. Then when you build the next level 'up' you can use the lower-level classes as property types. When there are multiple instances of a property you can use multiplicities or you can open the Detail tab of the property dialog to define lower and upper bounds, collection classes, etc. Remember that when you enter a new property you must save it before you can change the Detail tab information.

HTH, David

[Roger A. Shepherd]

Stasch,

I'm not quite clear on exactly what you're trying to achieve.  You mention

A company has many systems to run the business.

and mention an example.  I'm wondering are you trying to model and then write a custom application to track this information, or are you trying to track your current company's systems within EA.  If it's the latter, I have a fair amount of experience with this.

[Stasch]

I am using EA to model the current system architecture.   I  am new at UML, and wondering what best practices I can use this this case, considering, there may be different ways we can model this.  My model will incorporate different organizations and systems within those organizations.

[«Midnight»]

Consider representing an organization (any organization) as a class. Think about the common attributes of that class - which may in turn be other classes. An (somewhat contrived) example of such an attribute is URL.

When you've got that generic picture straight, consider one of the organizations you wish to model. This is an object, an instance of the Organization class above. What makes this organization different from others are the values of the attributes. An example would be www.myaddress.com.

You'll find that you develop quite a few classes as you go, but reuse them for each instance of the Organization class. Similarly, these lower-level classes will also have many instances. You may also find that you have class hierarchies, sometimes with virtual parents and concrete child classes.

As you model several organizations you could keep them separate by using different packages, one for each. You can also use packages to keep things sane in the original class hierarchy.

Packages are a way of separating and grouping components of your model. Their meaning is what you make of it, and the groupings can be somewhat arbitrary, although they are hierarchical. This is the structure, or organization chart (pun intended), of your model. The actual structure of what you are modeling (as opposed to the model itself) comes from the classes (and other elements) you define and the relationships between them.

David