Some Lessons Learned from u sing i* Modelling in Practice

RESG Meeting London, April, 2005

Some Lessons Learned fromSome Lessons Learned from

uusing i* Modelling in Practicesing i* Modelling in Practice

Oscar Pastor,Alicia Martínez, Hugo Estrada

OO-Method Group

Estudio de la Integración de Sistemas basadosen XML, CORBA y otros entornos de conectividad, para su aplicación ensistemas distribuidos y en aplicaciones de comercio electrónico

Some Lessons Learned from using i* Modelling in Practice

Outline

Using i* in a Software Production Enterprise- The advantages- The detected problems - A proposed solution

Conclusions

Introduction



IntroductionThe OO-Method approach

Problem Space Level

Automated Translation

Solution Space Level

Late Requirements

Functional Model Uses

Conceptual Model

Repository

Formal SpecificationFormal Specification

Object ModelDynamic Model Presentation Model

Navigational Model

Persistence Tier (SQL Server, ORACLE)

Application Tier (COM+, CORBA)

Interface Tier (Visual Environments, Web, XML)

Empiricism (ESE)

Obtain

A Model Driven Case Tool for Automatic Generation of Information Systems

Care Technologies, S.A.



Model Driven Approach

Introduction

Late Requirements

Functional Model Uses

Conceptual ModelObject Model

Dynamic ModelPresentation Model

Navigational Model

Obtain

Early Requirements with i*

Goal of Goal of thisthis work workAnalyze the use of i* in for representing early requirements in the context of the Model-Driven Code Generation Context of OO-Method.



Outline

Introduction

- The advantages- The detected problems - A proposed solution

Conclusions

Using i* in a Software Production Enterprise




Case studies analyzed: Workshops Management (Workshop on Requirements Engineering: WER 02) Golf Tournaments Management (Oliva Nova Golf Club) Car Rental Management (Rent a Car Denia, S.A.).

In the analysis of the i* Framework we use some projects of the CARE Technology Enterprise, S.A. as case studies. http://www.care-t.com/

http://www.care-t.com/



The strategy to face the case studies3 CARE Technologies

analysts3 CARE Technologies scholarship holders

2 PhD students


Three different groups

Experts in OO-Method Modeling. Without

knowledge in i* Modeling

With knowledge in Requirements Modeling. Without knowledge in i*

Modeling

With previous knowledge in i*

ModelingInterviews with the Clients

Represent the semantic of the Enterprise using i*

Learning the i*Methodology

Results ResultsResults

Interviews with the Clients


Learning the i*Methodology

Interviews with the Clients


Modeling ProcessN

o vi

sibi

lity

No

visi

bilit

y No visibility

No visibility

Analysis & Conclusions



Outline

Introduction Using i* in a Software Production Enterprise

- The detected problems - A proposed solution

Conclusions

The advantages



The advantages

…

Actor

Actor

Actor Actor

…

Actor The bottlenecksThe bottlenecksActors that concentrate too many dependencies needed for performing the processes.

The type of dependenciesThe type of dependenciesActors that concentrate too many goal dependencies what indicates an actor with a lot of responsibilities.

The vulnerabilitiesThe vulnerabilitiesActors that depend on another actors for fulfilling their goals.

The i* Modeling was very useful for analyzing the performance of the Enterprise. The i* analysis allowed us to determine:

The i* Modeling was a very powerful tool for representing the possibilities for reassigning the work in the Enterprise.



Outline


- The advantages

- A proposed solution Conclusions

The detected problems




Repeatability Scalability

EncapsulationUnderstandability

Traceability

Based in the analysis done with the CARE Technologies Case Studies, we have determined some of the issues associated with the use of the i* Framework in a Model Driven Context.



The detected problems (Repeatability) Repeatability)

In the current state of the i* Framework, could be complicated to decide the modeling primitives to be used for representing a specific semantic. This problem make difficult to assure an appropriated rate of repeatability in the modeling results

Repeatability: the capability of the modeling technique to repeat an output when given the same input.

Same semantic

Analyst 1 Analyst 2 Analyst 3



“Pay the registration of the Tournament”


EXAMPLE: Golf Tournament Management (GTO) Case Study

CARE Technologies scholarship holders

2 PhD students

paymentObtain

paymentPay the

registration

Register Golfers Register in theTournament

GTO Golfer

Participate in the Tournament

Pay for the

register

Obtain payment Register

Register GolfersParticipate in

the Tournament

GTO Golfer




Analyst 1 Analyst 2 Analyst 3

The repeatability is a important value in a Model-Driven Approach

Steps in the scenario of a use case

Use caseClass en the

sequencediagram

Analysis Analysis phasephase

DesignDesignphasephase

Automated Translation



The detected problems (ScalabilityScalability)

In the current state of i*could be difficult to analyze large Enterprises, because in this case, there are too many modeling elements in a same model.

…

Actor

Actor

…

Actor

…

……

…

…

Actor

Actor

Actor

Scalability: The capability of the modeling technique to function well as it scales up or down to meet the analysis needs.



Example: Car Rental Management Case Study

The detected problems (ScalabilityScalability)

This is only a fragment of the process for renting a car. This model can grow up quickly, doing very complicate their analysis.

acceptation/rejection

customer dataAnalyze the

client data

Analyze the bank credit of the client

notification of the client

bank credit

obtain the

bank credit

client data

Communicate the result

Wait for the result

Analyze the own preconditions

Formalize the

renting

register the car rented

Delivery invoice

Register the payment

Car can be rented

Borrow car to other office

To analyze availability car

Obtain rent data

Inform the availability

Analyze the car availability

Analyze availability in the office

Analyze availability In other offices

Obtain car data

Data

Answer for availability

Delivery the car

deliver car keys

deliver the car

Obtain date

car

Car keys

invoice

payment

Car data

Dates for renting

Rent a car

provide data personals

Renting the car without reservation

provide car data

obtain the invoice

pay the car

Select company

determine date for renting

select a car

obtain the car

Receive car keys

receive the car

analyze alternatives

provide data for renting

provide date

Rent a carDenia Rental

car

Bank

Customer

Associated Branches



The detected problems (Scalability-Scalability- Encapsulation)

…

…….

…

…

…

…

… …

… …

…

…

…

…

…

…

…

…….

…

…

…

…

… …

… …

…

…

…

…

… … ……

… …

OrganizationProcess 3

OrganizationalProcess 2

OrganizationalProcess 1

In the current state of i*, we don't have mechanisms for encapsulating modeling primitives. In this way, could be very complicate to determine the fragments of the model that represent each process of the Enterprise

Encapsulation: The capability of the modeling technique for providing mechanism to use abstract concepts that represent a set of more concrete concepts.

Actor

Actor

Actor

Actor



The detected problems (Scalability-Scalability- Encapsulation)

Reviews

send notifications and reviews

PcChair Sort PaperResolve

critical cases

Send Notifications and Reviews Send notifications

and reviews Obtain

notification

Author

Reviewer

PcMemberTo do quality

reviews

Assign qualifications Assign

comments Assign evaluation

Send reviews

Send reviews

ReviewsSend

reviews

To do qualityreviews

Assign qualifications

Assign comments Assign

evaluation

Send reviews

obtain quality reviews

Obtain Reviews quality

As a consequence of the lack of mechanisms for doing encapsulation, in the same model we have information of very different abstraction levels. It fact make difficult the analysis of the model.

Example: Workshop Management Case Study

to do quality reviews Notification


Goal


ReviewsSend

reviews

Activities related to the Goal



acceptation/rejection

customer dataAnalyze the

client data

Analyze the bank credit of the client

notification of the client

bank credit

obtain the

bank credit

client data

Communicate the result

Wait for the result

Analyze the own preconditions

Formalize the

renting

register the car rented

Delivery invoice

Register the payment

Car can be rented

Borrow car to other office

To analyze availability car

Obtain rent data

Inform the availability

Analyze the car availability

Analyze availability in the office

Analyze availability In other offices

Obtain car data

Data

Answer for availability

Delivery the car

deliver car keys

deliver the car

Obtain date

car

Car keys

invoice

payment

Car data

Dates for renting

Rent a car

provide data personals

Renting the car without reservation

provide car data

obtain the invoice

pay the car

Select company

determine date for renting

select a car

obtain the car

Receive car keys

receive the car

analyze alternatives

provide data for renting

provide date

Rent a carDenia Rent a car

Bank

Customer

Associa-ted

Branches

The detected problems (Scalability-Scalability- Understandability)

Understandability: The capability of the Model for being comprehensible for users, no only for its designers.

Which elements Which elements of the model are of the model are related to satisfy related to satisfy each business each business process?process?

Which elements of Which elements of the model satisfy the model satisfy each goal of the each goal of the

Enterprise?Enterprise?

How can we How can we determine which determine which are the business are the business

process process represented in the represented in the

model?model?

Where is the Where is the place for starting place for starting reading the reading the model?model?




Traceability: The capability for following the trace of a modeling element in the different phases of development.

The i* provides a lot of modeling flexibility for adding elements in each phase of modeling, however this flexibility could be negative in a Model-Driven approach, where the elements of a model must have a a precise source in a previous model.

ActorActor

…

Actor

Actor

…

……

Actor

Actor

Actor

??

??

??

??



Outline


- The advantages- The detected problems

Conclusions

The Proposed Solution



Proposed Solution: Give a partial solution for the detected problems defining extensions for the i* Framework. To do this, we propose encapsulate a set of i* modeling elements in more abstract concepts, allowing us to create the i* models

in a compositional way.

In our proposal, we have defined the Business Service as the key concept for encapsulating the semantic of the enterprise processes.

The proposed solution



Customer

The proposed solution: a service-oriented approach for i*

Business Services: A Business services is a functionality (business process) that an enterprise expose to customers.

Characteristics:

Visibility: there is an “interface” to expose certain fragment of the process to potential customers.

Request: The Enterprise provides the functionality to the customers for requesting the service.

Consumers: The consumer of the service could be organizational actors of Enterprises.

service service service

Customer Enterprise

<expose> <use>

Goal Goal Goal

GoalEnterprise

<expose><use> <use>



Business Services Business processes Business objects

The functionality that an enterprise expose to

customers

The internal behavior for satisfying the services

The objects manipulated by the service

Interface Tier Business Logic Tier Data Tier

In this approach, it is possible to represent a Business Model in a Three Tier Architecture:

The i* Three Tier Architecture

service service service

Enterprise

Customer Customer Customer

…

….

…

…

…

…

……

…

…

…

…

…

…

…

…

Customer Enterprise

…

…

…

The proposed solution: a service-oriented approach for i*



1. Creating the Global Model1. Determine the concern actors in the Enterprise

2. Determining the main goals of the Enterprise

3. Determining the services of the Enterprise

Customer Customer

Enterprise

Enterprise

Customer Customer

EnterpriseGoal

service

Customer

Goal

Customer

Goal

service

The proposed solution: a service-oriented approach for i*The steps for create a Business Service Model



2. Detailing the Business ServicesDetermining the process for starting the service.

Determining the transactional processes.

Determining the non-transactional processes.

Determining the process for finish the service

service

Goal

Goal

Enterprise CustomerTransactionT T

Enterprise CustomerStart the service

Enterprise Customer non transactional Process

Enterprise Customerfinish the service

T T

Process with transactional properties Business Services DependencyProcess without transactional properties

The proposed solution: a service-oriented approach for i*The steps for create a Business Service Model



Outline


- The advantages- The detected problems A proposed solution

Conclusions



Conclusions

1. We have explored the use of the i* Framework in the context of a Model-Driven Code Generation Method. To do this, several cases studies have been carried out in the enterprise CARE Technologies, a SpinOff project to put into practice the OO-Method approach.

2. The results of the cases studies indicate that the i* modeling is very useful for business performance analysis. The improvements done using i* guarantee the construction of a information system that helps to reorganize the organizational work.

3. We have determined that certain issues in the i* framework need to be improved. (Summarizing, the lack of mechanisms for creating a model in a compositional way.



Conclusions

4. In order to give a partial solution for some of the detected problems, we have defined extensions to the modeling primitives of i*.

5. The strategy of the proposal consists on using compositional mechanisms to create and represent an Enterprise. To do this, the concept of Business Services has been defined as an extension to the traditional business models.

6. The definition of Business Services allows us to define an i* Model in a Three-tier Architecture, using the Business Services dependency for representing the interface, the Business Process for representing the Business Logic and the Business Objects for representing the Data Model of the Enterprise.

7. With the proposed Method, it is possible to describe an Enterprise as a composition of models, where each model represents a more detailed view of the Enterprise.

Documents

Some Lessons Learned from u sing i* Modelling in Practice