Effective Analysis Practices Implemented

The aim of this chapter is to demonstrate how employing Enterprise Architect supports the Effective Analysis practices.

1. Avoid Duplication

The obvious solution to prevent duplication is reusing. In the context of Enterprise Architect, it means representing each logical artifact by a concrete EA element and referencing it from wherever it is needed. Elements are not copied to different diagrams, but they are rather only referenced, which requires each of them to have a unique id. This is straightforward as each element created in the EA's repository is assigned a unique GUID identifier, which guarantees there is no other element with the same id.
Elements can be referenced from multiple diagrams by just linking the unique instance stored in the repository. New instances of the same element are not created, which ensures that changing the name or description of the element will propagate to all diagrams instantly. The same applies to relationships.

To reuse an element stored in EA's repository, just drag&drop it to the selected diagram. When the element is dropped in the diagram, EA will ask whether to insert the element as a link or instance:

Select "Link" to reuse the existing element, and each change made to the element will also propagate to this diagram. For more information about classifiers and instances, visit this explanation in the EA user guide.

NOTE
It is important to distinguish between technical identifiers and "business" ones. Although each element in EA is unique by its GUID, this does not guarantee that the object is unique from the business point of view. EA cannot prevent creating two components called Eshop representing the very same system. For EA these are just two different elements with different ids, yet with the same name.

2. Traceability

Traceability between the two elements can basically be set by creating any relationship. But since each relationship has its own semantics, author needs to select the one which best describes the intended connection.

1. Realization

Realization is used to trace artifacts which implement specific requirement:

…or to connect artifact with its implementation:

2. Dependency

Dependency is one of the most important relationships in regard to identifying the impacts of changes. Since it expresses which element depends on which, it is greatly beneficial during impact analysis. For example, if some part of the Warehouse System is to be changed, the team needs to find out how the Eshop will be affected because according to the model, it is dependent on the Warehouse System:

Dependency is a general relationship that covers a couple of specialized relationships. They are described in the separate chapter.

3. Association

Association is used, among others, to trace element to projects and change requests which are going to modify it or which already modified it:

4. Coherence

Coherence means keeping the related elements close to each other and in a place where people would intuitively look for it. In Enterprise Architect, this could be ensured by following practices:

1. Creating relationships between elements which form some logical entity or capability

In the following example, the Generate Business Card use case is the most important part as it defines what the system must be capable of. It serves as an information hub, and the coherence is achieved by connecting the related elements which are engaged:

As you can see in the traceability window, it is easy to learn all participants and to navigate to them.

NOTE
Despite it would be great to have such traceability for all elements, it would be inefficient as it would present an enormous overhead. Creating a relationship must provide some benefit that must be greater than the effort for creating and maintaining it.*

2. Including related elements under the same structure in the repository tree

In specific cases, coherence is also achieved by storing element directly under the entity which the element is related to. For example, the following picture shows storing the individual order states directly under the related order. This way it is instantly available in the place where everybody would intuitively look for it:

Another example is placing activities which specify the use case scenario directly under the use case:

5. Multiple Views

To describe the same concept from different perspectives, the analyst must create multiple diagrams that share the same elements. In Enterprise Architect, it is an easy job thanks to the possibility to reuse elements across diagrams as described earlier in this chapter. But then it must also be possible to tell which diagrams represent the same aspect. Here again, the traceability comes to play:

This example demonstrates how to model the same aspect using two different models and how to indicate that they represent the same aspect (the trace relationships between the diagrams). The first model shows the general overview of which systems communicate with each other, while the goal of the second is to depict in which order the systems communicate to achieve the common goal.

Different Levels of Abstraction

The previous example demonstrated the description of the same aspect from two different perspectives, which is characterized by the fact that the models are on a similar level of detail.
The completely different approach must be taken when the goal is to describe the same aspect at different levels of detail. The following picture illustrates how the high-level problem in the first diagram is broken down and described in more detail in the second diagram:

6. Conventions

To make the models consistent and easily readable, they must follow at least basic conventions. It should be clear across the organization whether a screen shall be named "Create Customer" or "Creating Customer", whether the individual words shall be separated by the space or not and whether the leading character of each word shall be capital, for example. The goal is to make models look like they were created by a single person.

General Rules

1. Do not use element type in its name
2. Omit articles and pronouns
3. Always use keywords that are meaningful to the business
4. Do not use undescribed abbreviations

Writing Style

For modeling purposes, we advise using a standard writing style that preserves spaces but capitalizes words: Customer Management System, Get Total Number().
The spaces are acceptable in the analysis and design models and increase readability.

Nouns: class name, interface name, attribute name, component name

• Car
• Branch Manager
• XML Export
• HTTP Request
• BranchManager, Branch manager
• Http Request, Xml Export

Verbs: use case name, acitivty name, operation name

• Make Reservation
• Export to HTML, Get Product()
• ExportToHtml, Export To Html

Do Capitalize

• Nouns (man, bus, book)
• Adjectives (angry, lovely, small)
• Verbs (run, eat, sleep)
• Adverbs (slowly, quickly, quietly)
• Pronouns (he, she, it)
• Subordinating conjunctions (as, because, that)

Do Not Capitalize

• Articles: a, an, the
• Coordinating Conjunctions: and, but, or, for, nor, etc.
• Prepositions (fewer than five letters): on, at, to, from, by, etc.