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:
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:
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:
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:
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:
Artifact description could be found here
Documentation template could be found here.
Use case
Artifact description could be found here
Documentation template could be found here
Activity
Artifact description could be found here
Documentation template could be found here
Screen
Artifact description could be found here
Documentation template could be found here
Application Component (System, Module, Submodule)
Decomposing systems to modules and decomposing modules to submodules is done using a association or composition:
Artifact description could be found here
Documentation template could be found here
Interface
Provided Interface
Artifact description could be found here
Documentation template could be found here
Table
Artifact description could be found here
Documentation template could be found here
Process
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.
Example 1: Service/function input
Example 2: Service/function output
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.
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).
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.
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.
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.
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:
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.
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.
Documentation template could be found here