![]() |
Site Archive (Complete) | |||
|
ABOUT US |
CONTACT |
ADVERTISE |
SUBSCRIBE |
SOURCE CODE |
CURRENT PRINT ISSUE |
NEWSLETTERS
|
RESOURCES
|
BLOGS
|
PODCASTS
|
CAREERS
|
||||
April 04, 2008
ISIS and the Eclipse Process FrameworkPierre Berlandier
The extensive and flexible framework provided by EPF let ILOG structure its methodology along several dimensions
Pierre Berlandier is a Principal Consultant at ILOG, where he has designed and developed numerous rules-based applications. These applications include expert systems for configuration and design of manufactured artifacts, real-time intelligent agents for the telecommunication industry, and business rules applications for the financial services and insurance industry.
A software development methodology describes who does what, how, and when to produce a software product. In this regard, the Eclipse Process Framework (EPF) provides a general formalism to:
EPF also provides a clean separation between the definition of the methodology elements and their presentation to the methodology users.
EPF encapsulates meaningful and related method and process contents in method plug-ins. The contents of plug-ins can then be extended or modified by other plug-ins. EPF provides a set of exemplary processes, the main one being OpenUP.
Content Definition
Figure 1 is a simplified view of the key EPF method elements and their relationships. The framework provides many more artifacts and relationships flavors and nuances:
[Click image to view at full size]
Figure 1: Method elements and their relationships.
The design of a methodology in EPF starts by creating the above elements and their relationships (a.k.a. "associations") within a method library using the EPF Composer, an integrated development environment (IDE) built on top of the Eclipse platform.
A set of attributes, taking the form of pure textual information or Rich Text, describe each element:
The above elements come together in an organized way through the definition of Processes (Capability Patterns or Delivery Processes), which provide the concepts of Work Breakdown Structure, Team Allocation, and Work Product Usage.
EPF then allows grouping the different elements by categories: Standard and custom categories. Standard categories are split into the pre-defined software methodology concepts of Disciplines, Domains, Work Product Kinds, Role Sets, and Tools. For example, you can create a "Project Data" category under the Work Product Kinds standard category and use it to qualify work products such as test results, problem reports, weekly status reports, and the like.
In contrast, custom categories are unconstrained hierarchical, ordered collections of method elements. Their main use is to compose configurations that are published as final methodology content. A standard use of a custom category is to present the different methodology elements according to different chosen points of view. Figure 2 shows an example of a custom category which presents the components of a process by grouping an introduction, a set of concepts, the set of disciplines, roles, delivery processes and work product kinds.
[Click image to view at full size]
Figure 2: Sample custom Category
Variability
Plug-in entities bring together EPF method elements packages and processes. A plug-in can reference another plug-in so that its element definitions can reuse and extend the content of the referenced plug-in. This mechanism allows customizing the standard OpenUP content and tailoring it to the specific needs of an organization.
Method elements have a Content Variability section where the user can define how an element relates to another one, either from the same plug-in or, more often, from one of the referenced plug-ins. The variability definition can have different semantics, that can be roughly described as follows:
The concept of variability with its various semantics has been key in allowing the ISIS (ILOG Solution Implementation Standard) methodology to:
Configuration
Configurations define which previously created elements should be published to the methodology users. A simple way to think about a configuration is as a set of views, each being materialized as a tab in the methodology web portal and presenting the contents of a custom category.
Configurations allow for some filtering on what to publish by selecting in each plug-in, which categories (standard or custom) should participate or should be removed from the published material. The concept of configuration allows the flexibility of building different, targeted instances of a methodology, based on the same compendium of material, with minimal investment.
|
|
||||||||||||||||||||||||||||
|
|