Tutorials (exercises)

EPF is still a very young release but at the same time very promising. We have to wait until september for the first official release. For EPF I made a tutorial that gives an overview on EPF and the tool implementing it that is called EPF Composer. The first part of the tutorial guides the user step by step in creating method contents like roles, tasks and work products. The second part is concerned with processes and here I was showing an example how to extend the OpenUP process with some activities from COMET requirements modelling.

COMET requirements modelling

The Use Case Model describes the Product in terms of actors, use cases and scenario descriptions. The Use Case Model consist of two main parts:

• The System Boundary Model, which identifies the Product under consideration (area of concern) and describes the Product boundaries as well as the main services offered by the Product.
• The Use Case Scenario model, which includes more detailed descriptions of the Product resulting from further analysis using the common use case detailing technique, by diving into a use case discovering new use cases and actors. Use case scenarios are also described in this work product.

In EPF Composer we are going to create a Requirement Model Library which is going to include the configuration and the plug-in. As described before the method content are locatet in the plug-in and it they describe what is to be produced, the necessary skills required and the step-by-step explanations describing how specific development goals are achieved. These method content descriptions are independent of a development lifecycle. This lifecycle is described in the process. Processes take the method content elements and relate them into semi-ordered sequences that are customized to specific types of projects.

Step 1: Create method content

To create a method content for requirement modeling in Comet, we are not creating a method from scratch, but extending the OpenUP/Basic iterative development process.

Before starting, an important issue in EMF Composer is the viewing perspective. EMF composer proposes two viewing perspectives:

• The Authoring Perspective provides views and functions to navigate and author method content and processes. You must be in the Authoring Perspective to create or modify any element types. The Authoring Perspective contains two Views: the Library View and the Configuration View.
• The Browsing Perspective allows you to preview and navigate through a Method Configuration without making any changes

Make sure that the right configuration is chosen in the drop down box above the library view.

The first step is to create a method plug-in which we are going to name for comet_requirement. Make sure that you are in the Authoring Perspective.

The plug-must be included in the configuration and this is done by dubbel clicking on the configuration and selecting the Plug-in and Package selection window above properties.

In the new created plug-in you can find the method contents and the processes. In the method content choose Content Packages and by right clicking on it choose to create a new content package. The new content packages we created in this example is called use case models and from the figure you can see that it automatically includes roles, tasks, work products and guidance.

Step 2: Create work products

Work product is a general term for task inputs and outputs, descriptions of content elements that are used to define anything used, produced, or modified by a task. The three types of work product are artifacts, deliverables and outcomes. A short description for these work products will be that:

• an artifact is a tangible work product that is consumed, produced, or modified by tasks
• a deliverable is a collection of work products, usually artifacts
• and an outcome is an intangible work product that may be a result or state

In this example we are going to create an artifact (1).

• (2) After a new artifact is selected by rightclicking on the work products under use case models, the artifact editor is displayed. In the editor we can see the name and presentation name field, which can be seen as the name of the file and the name in the publishing presentation. Here we can also see fields for purpose or description.
• (3) In a browsing prespective this artifact is published as an html page. As seen in the picture in this example we created two work products that are the System Boundary Model and the Use Case Scenario Model

Step 3: Create roles

• (1) A Role defines a set of related skills, competencies, and responsibilities of an individual or individuals. Under roles in the use case models package we are going to create a role named ifi_student .
• (2)In the same way as for the creation of a work product a name, presentation name and description must be writen. In the role editor we can also specify the skills for this role or its assignment approaches.

• (3) Now we can assign the work products to this role by changing to the Work Producs window above the Properties view. The task that we created can be added here.
• (4) And here we can see a preview of the role ifi_student.

Step 4: Create tasks

• (1) A task is an assignable unit of work. Every task is assigned to a specific role. The granularity of a task is generally a few hours to a few days and usually affects one or only a small umber of work products.
• (2) Like the work product and role editor, the task editor has the standard fields for namem presentation name, description and purpose.
• (3) A task can have a series of steps that detail how to perform that task. The Step Editor allows you to:
  • Create a new step
  • Remove a step
  • Move a step up the list
  • Move a step down the list
  • In our example we created four possible steps in creating a system boundary model.

• (4) This part of the editor allows you to define the roles that perform the task. You should select a role as the Performing Role for this task. You can also add one or more roles as Additional Performers. We created another role in here that is called ifi_assistent_teacher and this should be an additional performer in this task.
• (5) This part of the editor allows you to define the work products that are inputs and outputs for this task. You can select any number of work products as Mandatory Inputs, Optional Inputs, and Outputs. To add a work product, click the appropriate add button, select the work products you want to add, and then click ok.We defined the context statement from bussiness modeling to be an optional input for this task.

• (6) And the total picture of the task is shown in the preview tab.

Step 5: The method contents

After creating the task for making the scenario models, here is the result of using EMF Composer for defining the method content in the Comet Requirement Modeling. In the screen we can see the definition of the role Ifi Student with the tasks he/she performs, the work products that is responsible for and the skills needed to fullfill this role.

Step 6: Working with processes

In Process Authoring the process engineer defines additional lifecycle elements such as Activities (summary tasks), Phases , Iterations and Milestones , that can then be used to compose the core elements into processes. A complete process corresponding to a project plan or a phase we call a Delivery Process . We can also create smaller more granular sections of process, termed Capability Patterns that can be used as building blocks to more easily compose delivery processes.

The COMET metodology describes four phases in its lifecycle. The first is the Inception Phase in which bussiness model contents are created and the developers start working on the requirement modeling. In the second phase, Elaboration phase the developers continue in refining the bussiness model, but the center of attention in this phase is requirements modeling. The definition of architecture is also started in this phase. The Specification&Construction phase include refining of the requirements, full definition of the architecture and modeling the product in PSM level. The last phase, the Transition is defined as a smothly deployment of the robust system.

A process can be created from scratch or extend another predefined process in a standard method. Since COMET is inspired from RUP(and many other methodologies) we decided to use the predefined processes in a basic OpenUP library that is shiped together with EMF Composer. In our example we are going to create to activities that will extend the Manage Requirements activity in the Elaboration phase.

• (1) As seen in the picture the new activities are Identify System Boundaries and Detail scenarios. In the property view it is shown that they are an extend to OpenUP_basic/elaboration_phase

Now as you can see in the screenshot of EMF Composer the Process editor is more complex than the method content editors. The first tab, description is standard like the others with name, presentation name and description. In this example we are more interesting in the work breakdown structure that is a hierarchical breakdown of work, such as activities, tasks, and steps, defining a process.

The other tabs above the properties view are:

• (2) Team Allocation tab shows the activities in the capability pattern and the roles that are the performers of the tasks in the activities. In the Manage Requirements activity there are four role descriptors (links to roles). The analyst and stakeholder are roles defined in OpenUP while Ifi Student and Ifi Asistent Teacher are performers of the tasks created in this example.

• (3) Work Product Usage tab shows the activities in the capability pattern and the work products that are input and outputs of the tasks in the activities. Here we can find the System Boundary Model and Use Case Scenario Model that are artifact descriptors linked to the artifacts created and other artifacts descriptors from OpenUP.
• (4) Consolidated View shows the full set of information for each activity in the Capability Pattern. It shows the tasks, work products and roles within each activity.

Step 7: Create a delivery process

• (1) Under processes in comet_requirement plug-in right click on the delivery process and then new-> delivery process.
• (2) A new window will appear and request the name of the delivery process and the configuration which should be the same as the one we were working on, in this case the OpenUP.

Step 8: Create a phase

A Phase is a special type of activity that represents a significant period in a project, ending with a major management checkpoint, milestone or set of deliverables. An Elaboration phase is created as an example(remeber that Inception is the first phase).

Step 9: Create an activity

• Activities represent the key building blocks for processes. Activities represent a grouping of breakdown elements such as other activities, task descriptors, role descriptors, work product descriptors, and milestones.
• In the property view we can change the characteristics of the activity, like if it has multible occurrences, is repeatable and so on

Step 10: Applying capability patterns

When developing a process, it is not necessary to develop the process from scratch, adding descriptors one by one. You can reuse existing capability patterns or even capability pattern parts to individually customize the pattern's content to the particular situation for which it is applied. A capability pattern must be applied to one specific activity in a process.

One of the advantages of EMF Composer is its ability to reuse and extend other methods and plugins. As we described before since COMET is using some of the concepts included in UP, we are going to structure our example as an extention of the existing Manage Requirement activity in the Elaboration phase.

After extending the Elaboration Iteration[n], this activity includes now different other activities described in OpenUpBasic. This are listed as a break down structure with the names in green color.

Step 11: Create a task description

• (1) Task descriptors populate the work breakdown structure’s activity. They are linked to the task created in the method content. In the same way as with artifacts, roles needs to be assigned to tasks descriptors. Work products must be set as inputs or outputs and steps be described. This is done through the Roles, Work Products and Steps tabs.
• (2) In our example the Detail scenario task descriptors is primarly performed by an IFI Student and assisted by an IFI Assistent Professor
• (3) As seen in the picture, the System Boundary Model is a mandatory input for this task descriptor. Steps are defined in the same way as with the artifact editor.