
What is Modeling?
In relation to using Enterprise Architect, modeling can be described as graphically representing a business process or software system. The resulting model can be used to emphasize a certain aspect of the system being represented and to record, document and communicate its detail. A study of such a model can enable insight or understanding of the system.
The Modeling Platform
Enterprise Architect's modeling platform is based on the Unified Modeling Language (UML), a standard that defines rules and notations for specifying business and software systems.
For information on UML, see The UML Dictionary.
For examples of the UML models that Enterprise Architect can help you build, see Model Templates.
Building a Model
Using Enterprise Architect, you can quickly build a model using a hierarchy of packages to represent the structure and organization of the model. Each package can contain:
- Other packages
- Diagrams that represent various aspects of the equipment, environment and business processes of the system
- Elements that represent the objects and actions within the system or process, arranged in an organization defined by relationships represented by UML connectors.
The Create a Project - Quick Start topic briefly shows you how to create a diagram within a package, containing elements and connectors. Sparx Systems also provide a demonstration of quickly developing a Use Case model; to run this demonstration, click here.
For specific details of configuring and combining the components of a model, see:
Requirements Management
Gathering requirements is typically the first step in developing a solution, be it for developing a software application or for detailing a business process. Requirements are essentially 'what the system must do'. The requirements management built into Enterprise Architect provides full support for defining, organizing and managing the requirements that drive the project.
Relationship Matrix
The Relationship Matrix enables you to display and manage the relationships between the elements within selected packages. You can refine the display to show specific types of relationship between specific types of element. The Relationship Matrix is an effective and convenient method of visualizing relationships quickly and definitively.
UML Stereotypes
Stereotypes are an inbuilt mechanism for logically extending or altering the meaning, display and syntax of a model element. Different model elements have different standard stereotypes associated with them. You can also define your own stereotypes.
For further information on stereotypes, see UML Stereotypes.
UML Profiles
UML Profiles are a means of extending UML, which enables you to build models in particular domains. A Profile is a collection of additional stereotypes and Tagged Values applied to elements, attributes, methods and links, which together describe some particular modeling problem and facilitate modeling constructs in that domain.
For further information on Profiles, see UML Profiles.
UML Patterns
Patterns are groups of collaborating Objects/Classes that can be abstracted from a general set of modeling scenarios (that is, parameterized collaborations). They generally describe how to solve an abstract problem, and are an excellent means of achieving re-use and building in robustness.
For more information on Patterns, see UML Patterns.
MDG Technologies
The Model Driven Generation (MDG) Technologies enable you to access and use the resources of a specific technology within Enterprise Architect. Interfaces to some technologies, such as BPMN and Iconix Process, are integrated with Enterprise Architect, whilst interfaces to others such as Eclipse and Visual Studio can be added separately. You can also link to technologies that you have created yourself.
For more information on MDG Technologies, see MDG Technologies.
Business Modeling
Modeling the business process is an essential part of any software development process. It enables you to establish the broad outline and procedures that govern what it is a business does. As the Business Process Model typically has a broader range than just the software system being considered, it also enables you to clearly map what is in the scope of the proposed system and what is to be implemented in other ways.


