1 / 29

Some Lessons Learned from u sing i* Modelling in Practice

Some Lessons Learned from u sing i* Modelling in Practice. Oscar Pastor, Alicia Martínez, Hugo Estrada OO-Method Group. Outline. Using i* in a Software Production Enterprise The advantages The detected problems A proposed solution Conclusions. Introduction. Introduction.

sheryl
Download Presentation

Some Lessons Learned from u sing i* Modelling in Practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Some Lessons Learned fromusing i* Modelling in Practice Oscar Pastor, Alicia Martínez, Hugo Estrada OO-Method Group RESG Meeting London, April, 2005

  2. Outline • Using i* in a Software Production Enterprise • The advantages • The detected problems • A proposed solution • Conclusions • Introduction Some Lessons Learned from using i* Modelling in Practice

  3. Introduction The OO-Method approach A Model Driven Case Tool for Automatic Generation of Information Systems Late Requirements Problem Space Level Obtain Conceptual Model Object Model Navigational Model Dynamic Model Presentation Model Functional Model Uses Automated Translation Repository Formal Specification • Application Tier(COM+, CORBA) Persistence Tier (SQL Server, ORACLE) Solution Space Level Interface Tier (Visual Environments, Web, XML) Empiricism (ESE) Care Technologies, S.A. Some Lessons Learned from using i* Modelling in Practice

  4. Introduction Goal of this work Analyze the use of i* in for representing early requirements in the context of the Model-Driven Code Generation Context of OO-Method. Early Requirements with i* Late Requirements Obtain Conceptual Model Object Model Navigational Model Dynamic Model Functional Model Presentation Model Uses Model Driven Approach Some Lessons Learned from using i* Modelling in Practice

  5. Outline • Introduction • The advantages • The detected problems • A proposed solution • Conclusions • Using i* in a Software Production Enterprise Some Lessons Learned from using i* Modelling in Practice

  6. Using i* in a Software Production Enterprise 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/ • 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.). Some Lessons Learned from using i* Modelling in Practice

  7. Modeling Process Learning the i* Methodology Learning the i* Methodology No visibility No visibility Interviews with the Clients Interviews with the Clients Interviews with the Clients Represent the semantic of the Enterprise using i* Represent the semantic of the Enterprise using i* Represent the semantic of the Enterprise using i* Results Results Results Analysis & Conclusions Using i* in a Software Production Enterprise The strategy to face the case studies 3 CARE Technologies analysts 3 CARE Technologies scholarship holders 2 PhD students 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* Modeling Three different groups Some Lessons Learned from using i* Modelling in Practice

  8. Outline • Introduction • Using i* in a Software Production Enterprise • The detected problems • A proposed solution • Conclusions • The advantages Some Lessons Learned from using i* Modelling in Practice

  9. The type of dependencies The vulnerabilities Actor The bottlenecks Actors that concentrate too many goal dependencies what indicates an actor with a lot of responsibilities. Actors that depend on another actors for fulfilling their goals. Actors that concentrate too many dependencies needed for performing the processes. … Actor Actor Actor … Actor The advantages • 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. Some Lessons Learned from using i* Modelling in Practice

  10. Outline • Introduction • Using i* in a Software Production Enterprise • The advantages • A proposed solution • Conclusions • The detected problems Some Lessons Learned from using i* Modelling in Practice

  11. The detected problems 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. • Repeatability • Scalability • Encapsulation • Understandability • Traceability Some Lessons Learned from using i* Modelling in Practice

  12. Same semantic Analyst 1 Analyst 2 Analyst 3 The detected problems (Repeatability) Repeatability:the capability of the modeling technique to repeat an output when given the same input. 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 Some Lessons Learned from using i* Modelling in Practice

  13. Participate in the Tournament Participate in the Tournament Register Golfers Register Golfers Register in the Tournament Pay for the register Pay the registration Obtain payment Obtain payment payment Register GTO GTO Golfer Golfer The detected problems (Repeatability) EXAMPLE: Golf Tournament Management (GTO) Case Study “Pay the registration of the Tournament” 2 PhD students CARE Technologies scholarship holders Some Lessons Learned from using i* Modelling in Practice

  14. Analyst 1 Analyst 2 Analyst 3 The detected problems (Repeatability) The repeatability is a important value in a Model-Driven Approach Analysis phase Automated Translation Design phase Steps in the scenario of a use case Class en the sequence diagram Use case Some Lessons Learned from using i* Modelling in Practice

  15. Actor Actor Actor … … … … … … Actor Actor Actor … The detected problems (Scalability) Scalability:The capability of the modeling technique to function well as it scales up or down to meet the analysis needs. 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. Some Lessons Learned from using i* Modelling in Practice

  16. customer data Rent a car Denia Rental car Analyze the client data Communicate the result Rent a car provide data personals acceptation/ rejection Renting the car without reservation Wait for the result Analyze the own preconditions Delivery the car obtain the car Analyze the car availability analyze alternatives Analyze the bank credit of the client Car keys deliver the car deliver car keys Receive car keys Formalize the renting Obtain car data receive the car provide data for renting Analyze availability In other offices car Delivery invoice Obtain date register the car rented obtain the invoice invoice Select company Analyze availability in the office Register the payment select a car pay the car payment determine date for renting provide car data client data Car data obtain the bank credit notification of the client bank credit provide date Dates for renting Customer Car can be rented Associated Branches Borrow car to other office Answer for availability Data Bank Obtain rent data To analyze availability car Inform the availability The detected problems (Scalability) Example:Car Rental Management Case Study This is only a fragment of the process for renting a car. This model can grow up quickly, doing very complicate their analysis. Some Lessons Learned from using i* Modelling in Practice

  17. Organizational Process 2 Organization Process 3 Organizational Process 1 The detected problems (Scalability-Encapsulation) 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 … … … … … … … … 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 Some Lessons Learned from using i* Modelling in Practice

  18. Activities related to the Goal obtain quality reviews Goal Send reviews Reviews The detected problems (Scalability-Encapsulation) Example:Workshop Management Case Study send notifications and reviews Author Obtain Reviews quality Send Notifications and Reviews PcChair Sort Paper Send notifications and reviews Resolve critical cases to do quality reviews Obtain notification Notification Send reviews obtain quality reviews obtain quality reviews Reviews Send reviews Reviews To do quality reviews PcMember To do quality reviews Send reviews Assign comments Send reviews Assign evaluation Assign qualifications Assign qualifications Assign comments Reviewer Assign evaluation 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. Some Lessons Learned from using i* Modelling in Practice

  19. How can we determine which are the business process represented in the model? Which elements of the model satisfy each goal of the Enterprise? Which elements of the model are related to satisfy each business process? customer data Rent a car Analyze the client data Denia Rent a car Where is the place for starting reading the model? Communicate the result Rent a car provide data personals acceptation/ rejection Renting the car without reservation Wait for the result Analyze the own preconditions Delivery the car obtain the car Analyze the car availability analyze alternatives Analyze the bank credit of the client Car keys deliver the car deliver car keys Receive car keys Formalize the renting Obtain car data receive the car provide data for renting Analyze availability In other offices car Delivery invoice Obtain date register the car rented obtain the invoice invoice Select company Analyze availability in the office Register the payment select a car pay the car payment determine date for renting provide car data client data Car data obtain the bank credit notification of the client bank credit provide date Customer Dates for renting Car can be rented Borrow car to other office Answer for availability Data Bank Obtain rent data To analyze availability car Inform the availability Associa-ted Branches The detected problems (Scalability-Understandability) Understandability:The capability of the Model for being comprehensible for users, no only for its designers. Some Lessons Learned from using i* Modelling in Practice

  20. Actor Actor Actor ? ? … ? Actor Actor … … ? Actor … Actor The detected problems 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. Some Lessons Learned from using i* Modelling in Practice

  21. Outline • Introduction • Using i* in a Software Production Enterprise • The advantages • The detected problems • Conclusions • The Proposed Solution Some Lessons Learned from using i* Modelling in Practice

  22. 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. Some Lessons Learned from using i* Modelling in Practice

  23. Enterprise Goal <use> <expose> service service service <expose> <use> <use> Goal Goal Goal Customer Enterprise 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. Customer Some Lessons Learned from using i* Modelling in Practice

  24. Enterprise Customer Enterprise …. … … … … … … … service service service … … … … … … … … … … … Customer Customer Customer The proposed solution: a service-oriented approach for i* In this approach, it is possible to represent a Business Model in a Three Tier Architecture: The i* Three Tier Architecture Data Tier Interface Tier Business Logic Tier Some Lessons Learned from using i* Modelling in Practice

  25. Enterprise Goal Enterprise service service Customer Customer Goal Goal Customer Customer Customer Customer The proposed solution: a service-oriented approach for i* The steps for create a Business Service Model Enterprise Some Lessons Learned from using i* Modelling in Practice

  26. Enterprise Customer Start the service non transactional Process Customer Enterprise Transaction Goal T T service Customer Enterprise Goal Enterprise Customer finish the service T T The proposed solution: a service-oriented approach for i* The steps for create a Business Service Model Process with transactional properties Business Services Dependency Process without transactional properties Some Lessons Learned from using i* Modelling in Practice

  27. Outline • Introduction • Using i* in a Software Production Enterprise • The advantages • The detected problems • A proposed solution • Conclusions Some Lessons Learned from using i* Modelling in Practice

  28. Conclusions • 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. • 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. • 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. Some Lessons Learned from using i* Modelling in Practice

  29. Conclusions • In order to give a partial solution for some of the detected problems, we have defined extensions to the modeling primitives of i*. • 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. • 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. • 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. Some Lessons Learned from using i* Modelling in Practice

More Related