In our second installment of the Modeling Basics webinar series, we'll get you started with UML Class modeling in Enterprise Architect.
Using simple, hands-on examples, we'll explore how Class models can be applied to high-level information models and to software design.
In this webinar you will learn how to:
Don't miss this opportunity to learn more about Enterprise Architect
I used the Ultimate edition of Enterprise Architect, version 13.5 during the presentation. All of the features that I demonstrated, however, are available in the Professional (or higher) edition. There is no need for you to upgrade to replicate my model and the outputs I generated from the model.
Yes. Modeling of attributes is demonstrated in the presentation video from 15:04 minutes. Operations are only discussed briefly in the video from 31:52 minutes.
The available data types for attributes are determined by the Language field for the Class element that contains your attributes. Set the Language field in the Class Properties dialog to
<none>. Then open the Features dialog, by right-clicking the element and choosing Features & Properties | Attributes. You should see the UML primitive types available in the Type control of the Attributes tab. For a detailed explanation and an example of changing the Language option for an entire Package, see the presentation video from 15:37 minutes.
Related Help topics:
The scope, or visibility in UML terms, is particularly useful when defining Logical Models as it controls access to Class member variables, such as attributes and operations. For example, if an attribute has a visibility of
private, its value cannot be directly read or updated by another Class. In programming, visibility can be referred to as the access modifier, which is often represented by a similar set of visibility values defined by UML:
public, private, protected and package.
You can specify the multiplicity as
1..1. To do so, select
1.. in the Multiplicity control. Then enter
1 as the value of the upper bound.
Note: A cardinality specifies the number of items in a given collection, whereas a multiplicity in UML defines upper and lower bounds on the number of items a collection can have. Because a multiplicity is made up of two values that define these bounds, a multiplicity of 1 is actually an abbreviation for 1..1, and the cardinality of any such collection must also be 1. The same logic applies to any collection in which the upper and lower bounds are the same.
In my example model, I used the notation 0..* to mean that a webinar session can have zero or more attendees. I could have instead used *, which in UML is an abbreviation for zero or more.
If you draw the child Classes (subtypes) as boxes inside the parent Class (supertype) box, you are representing a nesting or containment relationship in Enterprise Architect and UML.
A project (.eap) file is what Enterprise Architect uses to physically store your model data. Within a single project file, you can have one or more models, each represented by a Root node. Each Root node can contain one or more View nodes. View nodes can contain a combination of Packages and diagrams.
There is no single 'right way' to define your model hierarchy. When modeling a single system, one popular approach is to use a single Root node for the system and create numerous View nodes under it. One View would be dedicated to the Use Cases for that system, another to the domain elements, another to the physical storage classes and so on. The idea is that each View node represents a different perspective, or view, of the same system.
In my project, I chose to model the agenda of my presentation using a Mind Map. This was a distinctly different model to the actual webinar domain that I modeled as an example, so I placed it in its own Root node. I modeled the elements in my domain using a single View, under the Root node named Webinar Information Model.
If I was to model some of the behavioral aspects of the webinar domain, I could create additional View nodes under the Webinar Information Model Root node. For example, I could capture the business processes that are intrinsic to the webinar domain and place them in a View named Business Processes.
The Information Model, as it stands, is devoid of any behavioral detail. As such, the model only provides a vocabulary for this domain and defines the valid static relationships between the domain elements. This is especially useful when defining common data that is exchanged between interoperable systems.
In the context of Domain Modeling, however, some would refer to this kind of pure Information Model as ‘anemic' - in other words a model that provides little benefit in aiding the design of a specific system. In particular, the Classes within the View named Domain Model do not even contain operations. Since many modelers prefer to add behavioral detail, such as UML operations, to elements in a Domain Model, the View named Domain Model in my example model should probably be renamed to something like 'Webinar Classifiers' to avoid confusion. I've made that adjustment to the model I posted in the resources section of this page.
The Logical Model is a separate model with its own elements. There is a strong correspondence between the elements in these models - in fact I copied the elements from the Information Model as new elements to expedite creation of the Logical Model.
The differences in both the purpose and detail of the models, however, mean that one cannot simply add more detail to the existing Information Model in order to generate application code. For example, the attribute types are significantly different between a PHP Logical Model and a pure Information Model in UML.
For information on how to automate the transition between different types of model, such as Logical and Domain Models, see the Help topic Model Transformation.
It would be fine to add the Enumeration into the Data Types Package or even another package devoted specifically to Enumeration elements. As for drawing the Enumeration on the diagram where the Class elements were drawn - it can be helpful to show Enumeration elements on the same diagram as, and close to, the elements that use it. This makes clear the range of allowed values for properties that are typed by the Enumeration.
Yes. For an example of changing the Language option for an entire Package and its subpackages, see the presentation video from 15:37 minutes. More information is also available in the Help topic Reset Options.
URL was modeled as a UML DataType and SessionStatus was modeled as a UML Enumeration. An Enumeration is a special kind of datatype that has Enumeration literals that define its possible values. In both cases, this definition for DataType in the UML specification applies: “instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances."
Yes. For all supported programming languages, see the Help topic Generate Source Code.
You can use the Code Generation Toolbar. This sets the default coding language for the current model, so the language is applied to all newly created Classes in the model. Other Enterprise Architect projects can have different default languages associated with them.
For details, see the Help topic Code Generation Toolbar.
You could do this when forward engineering, but it's not recommended for anything but the smallest of projects. If your model is of any realistic size and you place each element on the same diagram, it will be difficult to read and understand.
When reverse engineering, Enterprise Architect provides an option to create a diagram per Java Package. You could then combine these diagrams into one, by using Diagram Frames. For details, see the Help topic Diagram Frame.
Yes. To do so, you need to use the option to synchronize the model and code, rather than replacing or overwriting existing files. There are also more specific options you can use that determine, for example, whether Enterprise Architect will delete from the existing code any Classes or features (Class member variables or methods) that are not found in the model.
When synchronizing code, Enterprise Architect generally retains the existing code in the body of the method, while updating its signature and associated comments.
Related Help topics:
Yes, reverse engineering is supported. For details, see the Help topic Importing Source Code.
This shouldn't cause a problem, because each role name is generated as an element inside a complexType definition that represents the Class that owns the Association End in question. In the sample model, the Association relationship ends that had the same role name were owned by different Classes. The corresponding XML Schema elements are therefore generated into different complexType definitions.
Yes. Please see these webinars from our Webinar Library:
Yes. See this webinar for an example:
How to Generate Documents with Enterprise Architect - The Basics
There are no immediate plans for export to SVG.