Top Community Contributors
Introducing RepoDoc, a document generator for Enterprise Architect
Written by Archimetes
SysML 1.4 reference card
Written by Guillaume
Enterprise Architect User Group: London 2017
Written by DT_Sam
Enterprise Architect identified for Agile Development and DevOps: SD Times In-depth Feature
Written by sparxsystems
Panorama 360 Insurance and Wealth Management Enterprise Business Framework is available on Amazon
Written by Pierre Gagne
RepoDoc, a call for testing
Written by ArchimetesRead more...
We are Profiling EA Users
Written by sparxsystems
Managing a student project with Enterprise Architect - Part 4
Written by doug rosenberg
We have often to do with EA models we’ve never seen before. In such cases, you have either to click through the project tree (can be confusing and time-robbing) or you use some pre-defined Model Views.
The picture bellow shows how it could look like on your machine when you’ve read the article to the end.
The feature could be very helpful also in other situations and we wonder why it’s used so rarely. Using Model Views you can create access points to any elements you want independently from its position in the project browser. It can be compared with database views if you are familiar with databases.
The only thing which is a bit annoying while creating a view, you have to create a model search first. If you use the Query Builder, the created search can be used as a basis for a view without any problems. In case the functionality of the Query Builder is insufficient and you need to create an SQL query, it has to fulfill some criteria. Within your query, you need to define three fields: CLASSGUID, CLASSTABLE and CLASSTYPE, as shown in the following example:
SELECT ea_guid AS CLASSGUID, 't_diagram' as CLASSTABLE, Diagram_Type AS CLASSTYPE, Name, [Version], Author, Stereotype, CreatedDate, Diagram_Type, ModifiedDate
WHERE t_diagram.Diagram_Type = 'Statechart'
ORDER BY ModifiedDate ASC
Diagram Views help a lot to explore unknown projects. Thus, we have created views for all common diagram types.
Feel free to download and to use them: Searches and Views
First step – open Model Search / Find in Project dialog and import the xml file that contains the definition of searches:
Second step – activate Model Views window and import the xml file that contains the definition of views:
Creating a Diagram
In this latest instalment in the series Phil Chudley will be looking at the basics involved in creating a diagram using Enterprise Architect.
As always all of our videos are available right now via our YouTube channel ... and don't forget to subscribe!
This article was originally published on Bellekens.com
Seven ways to organise your EA models so that other people can understand them
1 A Package is not a Bucket
Some rules for Packages:
2 Notes, notes, notes
3 Single-purpose Packages
4 Different things get different stereotypes
5 Status is everything, or Somewhere to Play
6 Public and Private diagrams
7 Pick a meta-model, write it down, and stick to it
It is no coincidence that the package element in UML is represented by a folder icon, similar to directories in a file system Graphical User Interface (GUI). Packages are used to organize the elements of a model just as folders are used to organize files. The contents of a package are any kind of element that is part of a model, including other packages. Beyond that description there's not much more information on how to use packages in the UML specification. Since they are a general grouping thing, it is up to usage scenarios to suggest what the best practices are for using packages. There are some practices that apply in most situations, and more that depend upon the modeling methodology or the purpose of the model.
First and foremost, use packages to organize your model, regardless of the model purpose. Even the most trivial model quickly becomes unmanageable without some kind of organization. There is no single correct way to organize a model. A modeler may choose to organize around process or product or some combination of the two. Second, use the package diagram to provide visualizations of that organization. The model browser view below illustrates how even a simple model can begin to be confusing with no organization of the model elements.
In addition to being able to gather like items together to allow modelers to focus their attention on relevant elements and make those elements easier to find in the browser, packages provide a namespace for the elements they contain. Namespaces allow modelers to create unambiguous named references to each of the elements in a model. This is useful in situations such as when a modeler is evolving a system and creating an as-is and a to-be system model. It is natural to have elements named the same in each model. In order to disambiguate elements with the same name, they can be placed in different packages so that the fully-qualified names are different.
Packages can be placed on a UML package diagram. The modeler might choose to do this to present a high-level view of a model or to show relationships among the packages of elements. Three different package diagrams representing the model organization shown above are presented here. Each of these diagrams uses the optional diagram frame, showing the diagram type (pkg) and diagram name (Use Case View). Note that although the diagram and the package have the same name (Use Case View) this is not required. In the first diagram, the two high-level packages are shown. As with many other modeling situations, only the details we need are presented, and the details of the package contents are elided.
In the second diagram, the packages contained in the Actors package are shown. The labels on the Human and Non-Human package describe the namespace of the containing package. The containment relationship also serves to describe the namespace. In this example, the fully qualified name of the Actor Operator is Use Case View::Actors::Human::Operator.
In the third diagram, the contents of the packages are shown embedded in the package elements. This representation is the third presentation option found in the UML specification.
Your package diagrams will in all likelihood be some combination of each of these styles, as will your choice of organizing principles. Choose the one that is appropriate for its intended use.