INTRODUCTION
Business Performance Management (BPM) (1-4) has emerged as a
critical discipline to enable enterprises to manage their business
solutions in an on demand fashion. Gartner has coined the term business
activity monitoring (BAM) (3) and predicts significant growth in this
area. With such wide interest, the market has been flooded with
terminology similar to BAM, creating some confusion. It is not the
intent of this paper to attempt to clarify this confusion; we direct the
reader to Reference 2, which describes in detail the IBM BPM approach
and how it is positioned with respect to competing terminology. Even
before Gartner drew attention to the need large enterprises had for BAM,
Stephan Haeckel of the IBM Advanced Business Institute described in his
book the transformation from a make-and-sell organization to a
sense-and-respond organization. (5) Inspired by Haeckel's work and
market needs, various IBM divisions have been developing methodologies,
frameworks, tools, and software components to support adaptive
enterprises. IBM Research has been active in the development of this
technology and has sponsored several pilot projects (6,7) to better
understand its applicability and benefits.
From the IBM point of view, (1,2) a BPM system is an on demand
platform for business performance monitoring and control. It takes data
monitored from targeted business solutions and events, invokes BPM
services, and renders actions back to the target business solutions. The
BPM reference architecture and its components are described in Reference
2, p. 37. The BPM architecture for our solution closely follows the
reference architecture.
Originally, models were used in software development solely for the
purpose of documentation and presentation. The advent of extensible
tools (8,9) brought about Model Driven Development ** (MDD **). With it,
users could create new notations to express an artifact in a model and
attach software components to it. This ability makes it possible to
automate the transformation of user-annotated enhanced models into
deployed code and services. In recent years, new emphasis in research
and development has focused on MDD (10,11) as an alternative to
traditional software development methodology.
Once BPM systems are implemented, they are very hard to change
because they are engineered as software development solutions that are
linear and rigid or because the monitoring solution derives from process
models. Solutions derived from processes are flexible but not
comprehensive enough to include the nonprocess metrics needed to
represent the full state of a business. Thus, a BPM approach not based
on models can fall short of fully meeting business needs.
The abstraction of the BPM solution to higher-level models, as we
propose, overcomes the shortcomings of BPM alone. It enables business
analysts and system architects to contribute directly to the solution.
The MDD approach to BPM means that business goals can be defined
independent of an information technology (IT) platform. Business-level
models either provide linkage to or can be automatically transformed
directly to IT-level models using transformation routines. MDD can
quickly reflect changing business goals and monitoring needs through
models. This paper explains our modeling approach to BPM and
demonstrates the ease of use of our modeling framework. We also describe
the modeling annotations of various artifacts that make up the BPM
solution and the process of automating the production of code from model
to deployment.
OVERVIEW OF OUR APPROACH
We have developed a technology framework and software platform to
represent a BPM solution by using formal BPM models in a top-down
fashion. We have also developed model software components that can be
attached to a modeling tool and that can automate the transformation of
BPM models into deployable code.
The BPM modeling framework is a refinement and augmentation of the
observation metamodel. At a high level, it captures the following
aspects of a BPM solution: information gathering from real-time business
events and other data sources, information aggregation to calculate
business metrics, recognition of situations warranting business actions,
and the invocation of actions that address the situations detected.
To enable the representation of a solution using models, we
decompose various aspects of BPM into smaller manageable components,
called BPM elements. These elements, together with their operational
semantics, comprise the BPM metamodel. The elements are designed with
ease of use in mind and are at the same time rich enough to represent a
complete BPM solution. To represent BPM elements, we chose Unified
Modeling Language ** (UML **) with UML Version 2.0 (UML2) profiles (12)
for extension. We selected IBM Rational * Software Architect (RSA),
which supports UML model extensions. Figure 1 represents the various BPM
elements and their relationships with one another. Together, they
collectively comprise the BPM metamodel.
[FIGURE 1 OMITTED]
The UML representation of the metamodel helps if one is designing a
solution from the beginning, but if someone has an existing solution in
some representation and does not want to start with BPM UML models, we
also provide a representation of the BPM metamodel as an Extensible
Markup Language (XML) definition. (13) This enables users to transform
their solution into an XML representation.
A BPM solution as a UML model can be created with the elements
shown in Figure 1 by using the RSA modeling tool. One can then use the
software component plug-in to perform an automated trans formation of
the model into a deployment module (e.g., a monitor runtime, data
warehouse, or dashboard module). The automated transformation hides the
complex inner workings of the transformations that create intermediate
metamodels. The code is generated based on these intermediate models and
finally packaged for deployment. One can make changes to the
intermediate models to further augment the model if desired, but
normally it is not needed. One also has the choice to go back to the UML
model and make changes as needed. This can be an iterative process until
a satisfactory version of the model is created. With MDD, business
analysts can visually design BPM solutions without development team
involvement.
Figure 2 shows the BPM tooling flow and user roles. In the modeling
stage, one can start with either an XML editor or RSA. Both approaches
can generate an observation model (OM), represented in the XML Metadata
Interchange (XMI **) format. (14) In this paper, we focus on using the
RSA approach.
[FIGURE 2 OMITTED]
Once the model is created, the transformation generates
intermediate models, such as the OM and the data warehouse model. The
intermediate models then generate code. In the figure, we show
observation, action, and visibility code being generated. The code
generated then generates what we call a deployment module, and each
module contains multiple services.
The next step is to deploy these service components to their
respective runtime environments. Figure 3 shows input sources and the
deployment of BPM components, including their respective software. (The
indicated execution steps are discussed later in the section on sample
scenario execution.)
[FIGURE 3 OMITTED]
Input sources are modeled in UML. (Later we describe how to
represent such input sources.) If an ad hoc event is input, then the
data is sent through the event infrastructure, which could be, for
example, an Enterprise Service Bus (ESB) (15) or Common Event
Infrastructure (CEI) (16) (our choice). BPM services is a collection of
runtime services and their deployment scripts generated from the BPM
models. The BPM services collectively process incoming data, correlate
and compute metrics, evaluate business or IT situations, send alert
notifications through preferred channels, and store processed data in an
operational data store (ODS). The Extraction, Transformation, and
Loading (ETL) service processes data by pulling it from the ODS on a
periodic basis, transforming the data, and storing transformed data in
the data warehouse. The management dashboard retrieves data from the
data warehouse and generates reports.
Advantages of the MDD approach
Our MDD approach to BPM has advantages over general IT systems
development because the expressive power of our BPM metamodel is
purposely restricted to generic and relatively simple con structs, such
as metrics, maps, dimensions, business events, situations, and actions
(Figure 1). By restricting the expressive power, we assure that a
well-defined, nonambiguous solution is generated. In addition, our model
takes a holistic view of monitoring requirements and can represent them
with formal models. Our solution also performs basic model validation to
assure that the BPM elements used are semantically correct and can be
automatically transformed into deployable code. Our solution is
deterministic and repetitive and supports the iterative MDD approach. It
also generates a default dashboard component that can be deployed on the
IBM DB2 * Alphablox (17); hence, one can view the output of a modeled
solution and change or add features to the models.
This basic approach has been further refined and the software
transformation components made more robust by implementing the solution
on many IBM Research projects, such as Distributed Enterprise Services
(DES) and On Demand Distributed Computing Services (ODCS). MDD BPM is
still in an early stage of development, but is expected to continue
gaining wider acceptance. The work we are presenting is part of the
larger Model Driven Business Transformation (MDBT) toolkit effort within
IBM Research. The MDBT toolkit with instruction documents is available
to download.
Related work
Due to its high-level abstraction and code reuse feature, the MDD
methodology has been widely applied in related areas such as software
reuse, (18,19) reverse engineering, (20) and user interface design. (21)
The benefits of adopting MDD include reduced software development time,
enhanced code quality, and improved code maintenance. (10,22)
There are also numerous related works about business processes.
Widely considered as an extension of a workflow management system,
business process management enables the management and analysis of
operational business processes. (23) Most recent work has focused on
modeling business processes, consistency checking for model integration,
and composing Web services and business processes by using the
model-driven approach. (24-26) Recently, model transformation has
received much attention because it can bridge between source models and
target models. (22,27) Though there are many standards defining
individual models, there is no one model transformation standard.
Domain-specific languages (28-30) and UML profiles have been defined and
used to express the transformation logic or mapping rules.
Our work focuses on a generic model-driven framework that aims at
code customization, code reuse, merging multiple models, and constraint
validation. Due to the well-defined BPM observation metamodel and the
many strict constraints imposed by it, we chose to deal with the model
transformation and mapping the code after the code-generation phase for
both the source model and target model. We used the well-developed
Eclipse Modeling Framework (EMF) (31) to generate model manipulation
code for instantiating in-memory model instances, which have strong
built-in validations.
To better understand our technology framework, we used the IBM DES
project as an example and a generalized scenario.
SAMPLE SCENARIO
The IBM DES pilot project was the first to demonstrate the BPM
solution using UML models and MDD techniques. We describe DES and then a
sample scenario known as service delivery.
Large enterprises with a number of relatively homogeneous but
independently operating sites at which the central value of the
enterprise is created are referred to as distributed enterprises.
Examples are national retail chains or banks with many branch offices.
Each property operates in many ways as an independent business but with
varying degrees of central ownership, shared resources, and business
function. Such enterprises have a project management office (PMO) that
centrally serves the needs of the distributed customers, promotes the
efficient use of resources, and manages costs by using economies of
scale. This scenario is called the service delivery model, and a
generalized business process for such a model is shown in Figure 4. The
business operations were defined as an artifact(32,33) based model, a
business modeling technique particularly suited to direct business goal
mapping and business integration. The operational model of the business
consists of the steps required to achieve operational goals and the flow
of business artifacts through them.
[FIGURE 4 OMITTED]
The goal of delivering a complete service to a customer site on an
agreed-upon schedule is captured in the DES operational delivery model.
Actually, it involves two interacting sets of goals: satisfying customer
needs and performing specific services to that end. This leads to three
primary artifacts:
1. Schedule--An attachment to a statement of work for services and
equipment delivered to a particular site. The schedule is the primary
artifact for customer delivery interactions. Services defined in the
schedule include a delivery plan organized by task. The task information
maintained in the schedule represents units of work required to complete
the schedule, including service provision and equipment delivery.
2. Supplier task--A unit of work performed by a service provider.
3. Project--A set of schedules.
Process monitoring, measurement, and metric information can be
obtained by monitoring the process events generated at probe points
within tasks and repositories. Figure 4 shows the event source probe
points E1, E2, and E3. These events must contain sufficient information
for correlation and metric calculation. The BPM technique can be used to
provide sophisticated real-time notification of complex patterns of
events. An entire suite of composite metrics can be updated at the end
of each business event.
GUIDELINES FOR IMPLEMENTING A BPM SOLUTION
Based on our experiences with DES and several other projects, we
have developed a set of guidelines that can ease the task of designing
and developing a complex BPM solution (Table 1). Although the guidelines
are expressed as six steps, we recognize that it might take several
iterations of design and development before an optimal level of solution
maturity is achieved and business monitoring requirements are met. It is
advisable to start with a project of small scope with few metrics, but
important enough for stakeholders to measure the success of BPM
technology.
Step 1: To gather requirements, the end user of the solution and
the sources of the input data for the BPM runtime system are determined,
and the reports that the end user would like to see on the dashboard are
identified. It is also necessary to identify the metrics (business
goals) that the end user wants to monitor, the business conditions that
must be detected, and the actions that may need to be taken. Some
metrics may be related to one another; others may need sophisticated
calculation. Gather all such information at this stage. The input data
sources might be well-defined business processes that emit (generate)
business events, existing data warehouses, or operational databases. It
is important that an agreement is reached with the stakeholders
regarding the business goals and how these goals are defined and
calculated.
In the DES scenario, the input data sources are business events.
The end users are of two types, operational and executive. For
operational metrics, we selected the following key performance
indicators (KPIs):
[] Total number of schedules or tasks by status (planned, live,
completed, or canceled)
[] Total outstanding schedules or tasks at the project level
[] Time span between when schedules and tasks are planned and their
actual completion time
[] Total time between plan and completion at the project level
Executive-level metrics might be total service-level agreement
(SLA) violations and the total number of pending schedules. Metric
results can be displayed on the dashboard in real time and one can probe
more deeply for finer detail and see broader aggregate views.
Step 2: The requirements are analyzed to identify the elements
needed for the BPM model. These might include events, KPIs, metrics,
management contexts, business conditions, and reports. One needs to
identify appropriate metrics and their relationships with other metrics
and the management context.
In the case of the sample scenario, the events identified were
ScheduleEvent and TaskOrderEvent. The management contexts identified
were bySchedule, byTaskOrder, and byProject. Similarly, metrics and
business conditions need to be defined without ambiguity because the BPM
solution is modeled based on these elements. Later, we show the BPM
elements in a requirement model.
Step 3: BPM requirements are modeled using RSA with extended UML2
profiles for BPM elements. For clarity, it is a good idea to create an
individual model for each management context identified in Step 2. One
might need to go back to Steps 1 and 2 while modeling the solution. The
models created in this step are the OMs. The details of how models are
created are given in subsequent sections.
Step 4: To augment the OM, the expressions that are needed to
calculate metrics or to add business conditions or outbound events in
response to changing business situations are provided. Also, it is
determined whether there is a need for data warehousing. If so, the
appropriate data warehouse model needs to be created, based on the OM
created in Step 3.
Step 5: The transformation of the models is performed by selecting
the transformation menu in RSA. The transformation results in the
generation of intermediate models in the output folder. Usually one does
not need to perform any updates at this stage, but if there are certain
complex needs that could not be addressed by means of our model
framework, this would be the time to reflect those changes in the
intermediate models. This step may also be of use if non-modeled BPM
solutions are transformed to our intermediate models and there is a need
for updating.
Step 6: From the intermediate models, the Platform-Specific Model,
code, and deployment scripts are generated. The person managing the
deployment then deploys the various components in the appropriate
environment (Figure 3).
BPM MODELS
In the previous sections, we introduced our approach at a very high
level and provided guidelines to define and use BPM modeling. In this
section, we discuss core BPM models, such as the OM and the data
warehouse, in detail with the help of our DES sample scenario.
Observation model
This section is divided into four parts: general terms the BPM
elements use to create OMs, definition of the requirement model using
the DES sample scenario, a brief discussion on mapping the requirement
model to the OM, and a discussion on optimizing the OM for execution.
Elements and OM detail
The main modeling elements are shown in Figure 1. A core model
element is ManagementContext. Each ManagementContext element represents
a business artifact that needs to be monitored and controlled or
managed. A business artifact may be monitored at either the instance
level (e.g., the processing time of individual customer orders) or at
the aggregate level (e.g., the average processing time of all customer
orders). If only instance-level monitoring is required, one
ManagementContext element may suffice to define all observables
(metrics) for the same kind of monitored entity. If aggregate-level
monitoring is desired, multiple ManagementContext elements may need to
be defined, representing the artifact instances and different
granularities of the artifact aggregate, respectively.
A ManagementContext element encapsulates the state and behavior of
the managed artifact. The state in a ManagementContext element consists
of a collection of metrics. Different instances of the same
ManagementContext element are uniquely identified by a key metric.
Metrics are typed and may be computed via maps. There are two special
kinds of metrics: situations and timers. Situations are Boolean-type
metrics that define business conditions warranting actions or attention.
Timers are a special kind of metric that behaves like a stopwatch. The
value of a timer is updated when the timer is started, stopped, or
reset.
A ManagementContext element subscribes to BusinessEvents that
report state changes of the managed entity. Such a subscription is
specified in an EventContextLink, which defines the filtering and
correlation constraints for BusinessEvents of a particular type that are
received in a ManagementContext element.
The state of a ManagementContext element may be mapped to elements
in a data warehouse for online analytical processing. A Dimension
defines a dimension table in the warehouse, which could be preexisting
or created from scratch. A MeasureDimensionLink maps a numeric metric
(measure) to a column in the dimension table. An AttributeDimensionLink
maps a categorical metric to a column in the dimension table for the
purpose of populating the column with the metric value.
DecisionMaps and BusinessActions specify the control on managed
entities. They are part of a ManagementContext and are triggered by
Situations. A DecisionMap selects among alternative BusinessActions. A
BusinessAction is a logical container for actions to be undertaken to
resolve the situation at hand. Payoff Functions can be associated with a
BusinessAction to calculate the cost of executing the action in terms of
money or duration.
ManagementContext elements can form a parent-child
ContextRelationship. A parent context may represent a
"superordinate" entity or an aggregate. A parentKey map
dictates how the key metric of the parent context can be computed from
the state of the child context.
Requirement model using sample scenario
From the BPM requirement point of view, the most important question
one can ask is, "What do we want to monitor and what notifications
do we want to receive?" It could be as simple as monitoring items
such as revenue and cost or tracking a forecasted revenue against an
actual revenue and having an e-mail sent when a monitored metric
violates a threshold. For our sample scenario, the four KPI artifacts we
identified were listed earlier under Step 1.
Other business artifacts, such as sites, task orders, schedules,
and time, characterize these monitoring metrics. The expressions used to
calculate the monitored metrics must also be known. (Each characteristic
could lead to multiple combinations with monitored artifacts for
measurement purposes, but only a few are deemed important from the user
perspective.) We identified three management contexts for our sample
scenario: bySchedule, byTaskOrder, and byProject. The following input
data, from an underlying business process system, flows into the BPM
system in the form of the business events: ScheduleEvent and TaskEvent.
Figure 5, Part 1 represents the two management contexts bySchedule
(child) and byProject (parent-aggregation). This figure follows the
guidelines in the IBM business-observation-metamodel specification and
extensions explained in the previous section. Shown are the monitored
metrics, events, maps, and other elements that were identified during
Steps 1 and 2.
[FIGURE 5 OMITTED]
Conditions can be monitored and defined accordingly. For instance,
in the bySchedule management context, the SLASituation element was
identified to represent the business situation if the condition TimeDiff
metric crosses a threshold value. If the condition is set to true, then
an outbound event called SLAViolationEvent is generated.
The other management context could be represented similarly to
Figure 5, Part 1. Such graphic representation of the models plays an
important role in creating OMs by using RSA and UML2 profiles.
Sample scenario: How to create a UML OM
We now discuss in brief how requirements are actually modeled. We
assume the BPM profiles have been imported into the model workspace and
that a general user has a basic understanding of using UML and profiles,
(12) as it is beyond the scope of this paper to review standard language
detail. For simplicity, we model only one management context:
bySchedule.
Figure 5, Part 2 shows the sample scenario representing the
bySchedule OM by using UML2 profiles. We refer to Figure 5, Part 1 while
we create the UML Model in the following five steps:
Step 1: Define ManagementContext class. Using the RSA model editor,
(8) we start by defining a class that represents the management context
bySchedule. Next, we apply the stereotype
<>.
Step 2: Define BusinessEvent class. Define a class called
ScheduleEvent and stereotype it as <>. The
BPM runtime will receive these events as input. There is a simple
association link stereotyped as <> between
the ScheduleEvent class and the bySchedule management context. The
attribute of this stereotype determines the system logic for the
incoming event during the runtime. The attributes are
noCorrelationMatches=0(createNewContext),
oneCorrelationMatch=2(deliverToAny), and
multipleCorrelationMatches=4(raiseException). It also has a business
rule constraint of type event correlation that determines the
correlation predicates for creating a new management context instance in
the runtime.
Step 3: Define Metric class and mappings. Define all classes for
the monitored metrics and stereotype them as <>.
Figure 5, Part 1 is an excellent reference for the list of monitored
metrics that need to be modeled. Each metric class has an attribute
called "value", and its type determines the data type of the
attribute. At this point a composition association is defined between
the metrics and the management context, as shown in Figure 5, Part 2.
The stereotype metric has properties that need their values to be
populated, such as keepHistory, multiplicity, partOfKey and readOnly. If
there is a need to maintain the history of any monitored metric, then
the value of keepHistory must be set to 1. In Figure 5, Part 1,
scheduleID represents the part of the correlation key (ispkey=true) for
the current management context; hence, the partOfkey property is set to
true. To calculate the value of the metric, an operation is added and
stereotyped as <
ReturnResult, select the Create New expression and enter the
expression in the general body of the element. The evaluation expression
could look like current time--bySchedule.startTime.value. One also needs
to define a trigger condition for this map to be evaluated. One such
condition could be the arrival of the business event with a status
metric value of actual. (One needs to refer to the BPM profiles document
to understand the expressions supported in the current release.)
Step 4: Define Situation class. Create a class called SLASituation
and stereotype it as <>. Next, define the gating
condition for each situation. Add an operation, for example, condition,
and stereotype it as <
Step 5: Define appropriate links with other elements. Define all
the other ManagementContext elements similarly. Then, each
ManagementContext element should be linked to its parent contexts
through a directed association stereotyped to ContextRelationship, as
shown in Figure 5, Part 2. For each relationship, the following
stereotype properties also need to be specified:
parentContextAutoCreated, parentContextMandatory,
parentContextTerminationCascades, and Primarykey.
Model-driven adaptive data purging
The OM describes the processing path of inbound events and the
resulting actions. In particular, it includes filtering conditions for
business events based on which events are considered relevant with
respect to possible management contexts. Without the knowledge derived
from the OM, general filters need to be placed in the network at the
emitters or in the event bus. The monitor subscribes to events that pass
these filters. Clearly, several problems can result from this approach.
They include lack of scalability with respect to event sources and
monitors, contention at the event databases during event storage and
query, and, in general, inefficient use of network and computational
resources.
To address these shortcomings, we developed a technology for
model-driven adaptive data purging. The advantage of this approach is
that it automates the placement of filters throughout the network and
restricts event flow to the relevant events. Most importantly, we are
now able to automatically place the right filters on the right
components. These filters are derived from the OM before its activation
and are directly relevant to the active monitors. The following steps
are necessary for adaptive data purging:
[] Extract filtering conditions from the OM.
[] Decide on the semantics and the placement of subscriptions in
the system. The conditions extracted in the previous step are analyzed
against knowledge about the topology, available resources, and the
processing capabilities of components.
[] Communicate the subscription plan to components and ensure that
they are able to process the assigned subscriptions.
[] Ensure subscription plan validity.
[] Activate subscriptions.
Without model-driven adaptive data purging, the knowledge from
events flows from emitters to the consumer, which is the OM runtime
system. Our technique allows for knowledge of the OM used by the monitor
to flow back upstream in the event flow to facilitate the placement of
tighter filters on the right components of the system.
Data warehouse metamodel
Data warehouses are crucial as a store for historical artifacts and
to support analytics. Their design is a highly disciplined skill; data
warehouse (34,35) creation takes considerable time and effort and is
mostly a manual process. Nonetheless, many times the data represented in
a data warehouse is not connected to or directly representative of
business models, and it can be difficult for stakeholders to analyze the
data. Such designs are also not adaptive; with changing business models,
redesigns are required. With the advent of BPM came a need for a data
warehouse that can adapt in real time.
To automate the process of creating a simple and adaptive data
warehouse and to also preserve linkages with business models, a data
warehouse metamodel is proposed. We briefly describe both the data
warehouse and schema generation in the next subsections. We also define
other artifacts generated for analytics purposes, such as IBM DB2 Cube
Views (36) models for OLAP, (34) which are used for default dashboard
generation.
The data warehouse metamodel (DWMM) provides for capturing specific
information about the structure of the data warehouse and the semantics
of the business models that it represents. Thus, an instance of the
metamodel is a DWMM that represents information at two levels of
abstraction: at the logical level, the model keeps information about all
the measures and dimensions in the warehouse and their
interrelationships; at the physical level, the model supplies details
about the specific physical representation of the measures and
dimensions in the database. Note that the logical part of the metadata
model contains enough information for the automatic generation of the
physical part, which is populated at schema-generation time.
Using XML Schema, the high-level structure of the DWMM is as
follows. The root element bpmschema contains a sequence of four
subelements that represent types of information. At the logical level,
dimensions are represented by DimensionDefinition, information about the
measures is stored in MeasureDim elements, and the relationships between
measures and dimensions are specified by MeasureToDimension elements. At
the physical level, the elements of type MetaFactTableGroup store
details about the physical representation of measures in tables. The
information related to the business models is also stored within the
subelements, providing the bridge between business model elements and
data artifacts in the data warehouse.
UML model
Figure 6 shows another BPM model that represents the DWMM. To begin
building this model, select the metrics (defined earlier in Figure 5,
Part 2) that are of interest to the storage purposes in this view. To
build this model, one needs to understand dimensions and facts. A
dimension is a group of metrics related by some hierarchy; for example,
for the time dimension, day, month, and year are related as
parent-child. A fact is a metric that is measurable. For analysis, a
fact metric is meaningful with a context; for example, revenue for a
given product by month. In this case, revenue is a fact metric, and
product and month are dimension attributes. The steps in the design of
the BPM data warehouse model proceed with this concept in mind.
[FIGURE 6 OMITTED]
Step 1: Create a Dimension class and metrics as its attributes.
This step identifies the groups of metrics that are related, creates a
class, and stereotypes it as <>; for example,
ScheduleDim as shown in the figure. The stereotype has attributes such
as isExisting = false, which means a new dimension (dynamic), and
isPopul