Brief Introduction

Enterprise Architect is used to model business, technology and engineering systems. You create models for a variety of reasons including specifying requirements, analyzing design options, describing architecture, designing programming classes and databases, documenting an existing system and much more. All the artifacts associated with these models are stored in the repository, not as files, but in tables in a relational database. These models can all be stored and accessed from a single repository, sometimes called a project. The repository can be of two fundamental types:

File-based Database - such as SQLite *.qeax files, Firebird *.feap files or MS Access *.eapx files
Server-based RDBMS - such as MS SQL Server MySQL, PostgreSQL or Oracle

Enterprise Architect makes connections to these databases

An Enterprise Architect Project is a repository for storing, manipulating and managing one or more models. A single repository can contain many models, and a Repository can be either file based, hosted in a larger DBMS system or based in the Cloud.

Concepts

Concept	Detail	See also
Project	A project can contain a single model, or a number of models, each of which defines a particular system or process. A model contains the diagrams, elements, relationships and associated metadata that define the structure and function of the system or process. These components are organized into a hierarchy of Packages, which help to group and manage related components.	Managing Connections to Projects Project Shortcuts The Modeling Team
Model	Different aspects of the process or system - or their development - are defined by Model Packages, which you generate from templates specifically structured to support the aspects that the Model Packages represent, such as requirements or deployment. You can generate these templated Packages at any level of the hierarchy, but as they are created with their own content they are more useful at the top levels.	Model Wizard
View	The top-level Packages in a model can also be Views, which represent partitions of the model that you define yourself. You can start with standard Views such as Class or Component, or create whatever partitions are appropriate to your model.	Views
Example Project Structure	Each View or Model Package contains Packages; the Use Case Model Package contains: Actors and Primary Use Cases It also contains the Use Case diagram, which could be an overview of the Package structure or function. Each Package itself can contain one or more diagrams, one or more Packages, and several elements; the Primary Use Cases Package contains the: Primary UCDiagram Customer Setup Package Use Case1 element Use Case2 element Each subordinate Package also contains diagrams, elements and (if necessary) further Packages; the elements are related by connectors created in the diagrams, and each element and connector has properties, attributes, operations and extensions defined in the respective 'Properties' dialogs. Note that models do not have to be constructed this way. Depending on the methodology you are following and information you need to model, the project structure might look completely different. In addition, many architectural frameworks such as TOGAF and ArchiMate specify their own project structure as part of their overall solution architecture.