Agile EA Process Model

This is the basic model structure we will use to define our Agile EA Process:

(Taken from this page on the EPF Composer Tool - Architecture )

Method Content

Method content describes roles, the tasks that they perform, the work products produced by the tasks performed and supporting guidance. They can be categorized into logical groups for indexing and display purposes. Method content elements are independent of a development lifecycle. In fact, they are often reused in multiple development lifecycles.

The following UML class diagram shows the organization of the method content classes. They are generated from the uma.ecore file.


Method content can be sub-divided into the following categories.

Core Method Content - role, task and work product (artifact, outcome and deliverable)
Guidance - checklist, concept, example, guideline, estimation considerations, practice, report, reusable asset, roadmap, supporting material, template, term definition, tool mentor and whitepaper
Content Category - discipline grouping, discipline, domain, work product kind, role set grouping, role set, tool and custom category


Processes describe the development lifecycle. They define sequences of tasks performed by roles and work products produced over time. Processes are typically expressed as workflows or breakdown structures. The sequencing of the tasks within the breakdown structure usually represents different types of development lifecycles, such as waterfall, incremental, and iterative.

The following UML class diagram shows the organization of the process element classes.


UMA defines a method library as a root container for all method elements. The following UML class diagram shows the organization of the key classes in a method library instance.


The default EMF persistence implementation stores a container and all containing elements, associated by composition, in a single XMI file. Based on the above class diagram, this would produce an extremely large XMI file that stores a method library and all its containing elements. Naturally, this would lead to performance and scalability issues as a method library grows in size. To resolve these issues, the default EMF Ecore implementation is extended to optionally store the containing elements in a separate XMI file. This design allows library elements such as the method configurations, method plug-ins, method content description and processes to be persisted in their own XMI files.

The UMA meta-model defines several unidirectional associations, such as the ones between a task and a role, as depicted in the UML class diagram below. The UMA component includes an Ecore extension, called "opposite feature", to allow unidirectional associations to be queried in the reverse direction. With this extension, the system can easily query for, say, a list of tasks that is primarily performed by a role, or a list of tasks that is additionally performed by a role. There are about 50 pre-defined opposite features in the UMA component.

Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.