Artifacts

The combination of storing documentation components in Enterprise Architect's repository and documenting them in Confluence requires integrating those tools using a middleware. The tool can take an element from the EA repository and generate a Confluence page for it. To achieve this, we must tell it what type of artifact the specific repository element represents.
For example, mapping the use case EA element to the use case artifact in the middleware triggers generating a use case wiki page specification:

aa

Artifacts With Dedicated Element

The mapping is not explicitly needed for all artifacts. Since some elements implicitly represent the concrete artifact, the middleware is then able to guess the artifact and create mapping automatically. For example, the UML use case element will be mapped to the Use Case artifact.

Requirement

EA Requirement element could be mapped directly to the Requirement artifact:

aa

Requirements Structure

To streamline the maintenance of the requirements, the analyst should keep the requirements organized and structure them according to their levels of detail. A way to achieve that is by creating a link between requirements to indicate the parent-child relationships using aggregation. This allows organizing requirements from the high-level to more detailed, to identify dependencies between them and generate requirements hierarchy:

aa

Requirements Granularity

Capturing each requirement as a separate EA element comes with many benefits. Since such a requirement is a standalone entity, it could be linked to other elements using relationships, and its textual description could be supplemented with additional structured metadata. However, this approach increases the overhead needed to manage the large amount of standalone requirement objects. Therefore, the analyst should be looking for the right balance between the benefits of having requirements in the form of elements and the amount of work required to manage them.

So if it is not worth creating an element for the specific requirement, how should it be documented? A simple approach is to describe it with the text and add it as a note to the parent requirement:

aa

Artifact description could be found here
Documentation template could be found here

Business Rule

Although Enterprise Architect has a dedicated Business Rule element, it is unfortunately not available in all editions. The way to overcome this inconvenience is to create a requirement element and attach "business rule" stereotype to it. This forces Enterprise Architect to change the type of the element to Business Rule:

aa

Artifact description could be found here
Documentation template could be found here.

Use case

aa

Artifact description could be found here
Documentation template could be found here

Activity

aa

Artifact description could be found here
Documentation template could be found here

Screen

aa

Artifact description could be found here
Documentation template could be found here

Application Component (System, Module, Submodule)

aa

Decomposing systems to modules and decomposing modules to submodules is done using a association or composition:

aa

Artifact description could be found here
Documentation template could be found here

Interface

aa

Provided Interface

aa

Artifact description could be found here
Documentation template could be found here

Table

aa

Artifact description could be found here
Documentation template could be found here

Process

aa

Artifact description could be found here
Documentation template could be found here

Artifacts Without Dedicated Element

Unlike artifacts listed in the previous section, which all have a corresponding element in EA, the following artifacts do not represent real elements but rather "logical concepts". This is why they do not match with any existing element and are mapped to elements with which they at least share similar attributes.

Data Object

Representing a general data structure, a data object is best described using a class element. It allows modeling the individual data items with class attributes that define their meaning and their data types.

aa

Example 1: Service/function input

aa

Example 2: Service/function output

aa

Artifact description could be found here
Documentation template could be found here

Data File

A data file is a real artifact that is produced or consumed by the system, so it is represented with the artifact element.

aa

The essential information to keep for every data file is who produces/consumes the file and what is its data structure. This is achieved by linking the file to the appropriate artifacts.

Artifact description could be found here
Documentation template could be found here

Function

A function represents the internal behavior of the application component. It may accept some input and produce an output. It is modeled as an operation of the component (system, module, submodule).

aa

Artifact description could be found here
Documentation template could be found here

Service

Service is an internal function exposed to the environment. It shares the same characteristics with the function, so it is also modeled as operation. The only difference is that service is always exposed through a defined application component interface, so the operation is owned by the interface and not by the application component itself.

aa

Artifact description could be found here
Documentation template could be found here

Document

Documents are represented by the artifact element. If the document is filled with data, it is also important to include the data object which is used for generating the dynamic content.

aa

Artifact description could be found here
Documentation template could be found here

Term

Terms are represented by the artifact element. The textual description of the term is stored in the element's note.

aa

Since some terms could be part of the business domain and documenting them both as terms and as parts of the business domain could lead to duplications, it is a convenient approach not to describe the domain entity directly, but reference the term instead:

aa

Artifact description could be found here
Documentation template could be found here

Privilege

A privilege is a concrete instance of something the user could do, so it is modeled as an object.

aa

Artifact description could be found here
Documentation template could be found here

Project

A project is a concrete instance of some planned activity, so it is modeled as an object.

aa

Documentation template could be found here