COMET. Component and Model-based development Methodology. Adapted from COMET I and COMBINE. COMET Methodology Handbook

Transcription

1 COMET Component and Model-based development Methodology Adapted from COMET I and COMBINE COMET Methodology Handbook Business, Requirements, Architecture and Platform modelling documentation Date: 05. April 2004 Authors: Arne-Jørgen Berre, Brian Elvesæter, Jan Øyvind Aagedal, Jon Oldevik, Arnor Solberg, Bjørn Nordmoen (WesternGeco) Affiliation: SINTEF ICT Version: 2.4

2 TABLE OF CONTENTS INTRODUCTION...2. OBJECT-ORIENTED COMPONENT-BASED PRODUCT FAMILIES/PRODUCT LINES ARCHITECTURE-CENTRIC USING REFERENCE MODELS A COOKBOOK UML-BASED USE CASE-DRIVEN ARCHITECTURE DRIVEN MODEL-DRIVEN ITERATIVE AND INCREMENTAL...3. MODEL-DRIVEN APPROACH COMET OVERVIEW MODEL ARCHITECTURE Recursive System Architectures PIMs vs PSMs DEVELOPMENT ACTIVITIES Models and process activities Summary of the process Work Contexts DEVELOPMENT PHASES Inception phase Elaboration phase Construction phase Transition phase BUSINESS MODELLING INTRODUCTION MODELLING FRAMEWORK FOR THE BUSINESS MODEL THE CONTEXT STATEMENT Modelling Objectives Methods and Techniques Deliverables and Notation THE VISION STATEMENT Modelling Objectives Methods and Techniques Deliverables and Notation RISK ANALYSIS Modelling Objectives Methods and Techniques Deliverables and Notation THE GOAL MODEL Modelling Objectives Methods and Techniques Deliverables and Notation THE COMMUNITY MODEL THE BUSINESS PROCESS & ROLES MODEL Modelling Objectives Methods and Techniques Deliverables and Notation...44 Page 2 of 93

3 3.9 THE BUSINESS RESOURCE MODEL Modelling Objectives Methods and Techniques Deliverables and Notation WORK ANALYSIS REFINEMENT MODEL (WARM) Modelling Objectives Methods and Techniques Deliverables and Notation REQUIREMENTS MODELLING INTRODUCTION USE CASE MODEL System Boundary Model Use Case Scenario Model PROTOTYPE Goals Methods and techniques Deliverables and notation NON-FUNCTIONAL REQUIREMENTS Goals Methods and techniques Deliverables and notation REFERENCE ARCHITECTURE ANALYSIS Goal Methods and techniques Deliverables and notation ARCHITECTURE MODELLING INTRODUCTION COMPONENT STRUCTURE MODEL Goals Methods and techniques Deliverables and notation Example COMPONENT INTERACTION MODEL Goals Methods and techniques Deliverables and notation Example: UML sequence diagram Example: Workflow Model COMPONENT INTERFACE MODEL Goals Methods and techniques Deliverables and notation Example COMPONENT INFORMATION MODEL Goals Methods and techniques Deliverables and notation Examples PIM DATA TYPES What are the requirements for types? What is the problem ISO Primitive datatypes...72 Page 3 of 93

4 5.6.5 Subtypes and extended types Generated datatypes Defined datatypes Applying types in PIM modelling PLATFORM-SPECIFIC MODELLING INTRODUCTION PLATFORM PROFILE MODEL Goals Related model artefacts Methods and techniques Deliverables and notation Examples COMPONENT IMPLEMENTATION MODEL Goals Related model artefacts Methods and techniques Deliverables and notation UMT CONFIGURATION MODEL The platform-independent architecture model Implicit PSM Implicit PSM in a UML tool (PIM annotation) Implicit PSM in UMT Considerations DEPLOYMENT MODEL Goal Methods and techniques Client and server Deliverables and notation APPENDIX A: BUSINESS METAMODEL & UML PROFILE INTRODUCTION STRUCTURING CONCEPTS BASIC BUSINESS MODELLING CONCEPTS Actor Resource Artifact Resource Behavioural Policy Business Message Business Process Business Rule Community Enabled by Enabling behaviour Event Goal Resource Resource as Artefact Resource in Role Role Step WORK ANALYSIS REFINEMENT CONCEPTS Business Service Extended Step Human (user) Human Step...89 Page 4 of 93

5 7.4.5 Human/ Tool Immediate Step Other system Product System Tool Step Workflow UML profile UML MAPPING Stereotypes Icons VALIDATION RULES PREDEFINED VIEWS TRANSFORMATION RULES APPENDIX B: REQUIREMENTS METAMODEL & UML PROFILE MODEL STRUCTURE Examples USE CASE EXTENSIONS Examples VALIDATION RULES PREDEFINED VIEWS Examples TRANSFORMATION FROM REQUIREMENTS MODEL TO ARCHITECTURE MODEL Transformation specification APPENDIX C: ARCHITECTURE METAMODEL & UML PROFILE THE COMBINE 4+2 TIER REFERENCE ARCHITECTURE COMPONENT TYPES Tier Components Composite Components Workflow Components TYPE LIBRARIES Examples OTHER STEREOTYPES VALIDATION RULES PREDEFINED VIEWS Examples APPENDIX D: PLATFORM SPECIFIC METAMODEL & UML PROFILE COMBINE PLATFORM SPECIFIC METAMODEL: SERVLET AND EJB EXAMPLE...7 APPENDIX E: WESTERNGECO BUSINESS MODEL EXAMPLE...8. SCOPING STATEMENTS Context Statement Vision for Change Risk Analysis GOAL MODEL THE TENDER BID PROCESS Receive ITT & Prepare for bidding Make Tender Submit Tender Survey Booking BUSINESS RESOURCES...30 Page 5 of 93

6 2 APPENDIX F: WESTERNGECO REQUIREMENTS MODEL EXAMPLE PRODUCT VISION AND DESCRIPTION Vision Description Background and Motivation USE CASES What is a Use Case System Boundary model Definition of actors (User groups) Summary list of use cases Global quality requirements SUBSYSTEM GROUPING The Booking-Editor The Booking-Viewer The Subscription-Editor The Global-Schedule-Service The Subscription-Service THE BOOKING-EDITOR USE CASE DESCRIPTIONS Use Case : Book tender/lead Use case 2: Update booking status Use case 5: Reschedule jobs Use case 7a: View local schedule Use case 5: Import from global schedule Use case 6: Export to global schedule THE BOOKING-VIEWER USE CASE DESCRIPTIONS Use case 7b: View global schedule THE SUBSCRIPTION-EDITOR USE CASE DESCRIPTIONS Use case 2: Subscribe to notification THE GLOBAL-SCHEDULE-SERVICE USE CASE DESCRIPTIONS Use case 0: Add/remove users & rights Use case : Add/remove vessels Use case 7: Synchronize and save schedule Use case 8: Assemble and deliver schedule THE SUBSCRIPTION-SERVICE USE CASE DESCRIPTIONS Use case 9: Check for subscriptions & notify Use case 20: Update list of available subscriptions Use case 2: Save/remove subscriptions APPENDIX G: WESTERNGECO ARCHITECTURE MODEL EXAMPLE REFERENCE ARCHITECTURE ANALYSIS Survey Booking Subsystem Grouping Use Case Model Component Identification Component Interfaces THE BOOKING EDITOR TOOL DESCRIPTION User Service THE BOOKING VIEWER TOOL DESCRIPTION User Service THE SUBSCRIPTION EDITOR TOOL DESCRIPTION User Service THE BOOKING SERVICE BUSINESS SERVICE DESCRIPTION Interface Specification THE SUBSCRIPTION SERVICE BUSINESS SERVICE DESCRIPTION Interface Specification THE ACTIVITY INFO RESOURCE SERVICE DESCRIPTION...60 Page 6 of 93

7 3.7. Activity Info Model The Activity Info Resource Service description APPENDIX H: WESTERNGECO PLATFORM SPECIFIC MODEL EXAMPLE TECHNOLOGY DISCUSSION DETAILED DESIGN THE BOOKING EDITOR TOOL DESIGN Graphical User Interface BCE Analysis Use case : Book tender/lead Use case 2: Update booking status Use case 7a: View schedule BCE to Class Mappings Internal Class Design THE BOOKING VIEWER TOOL DESIGN Graphical User Interface BCE Analysis BCE to Class Mappings Internal Class Design THE SUBSCRIPTION EDITOR TOOL DESIGN BCE Analysis Internal Class Design THE BOOKING SERVICE BUSINESS SERVICE DESIGN BCE Analysis Internal Class Design THE SUBSCRIPTION SERVICE BUSINESS SERVICE DESIGN BCE Analysis Internal Class Design EJB IMPLEMENTATION Servlet Implementation BookingServiceEJB implementation ActivityInfoEJB implementation...87 Page 7 of 93

8 TABLE OF FIGURES FIGURE : OMG MDA...4 FIGURE 2: MODEL ARCHITECTURE...6 FIGURE 3: SYSTEM LEVELS...7 FIGURE 4: APPLICATION STRUCTURE...8 FIGURE 5: THE ACTIVITY VIEW OF DEVELOPMENT PROCESS MODEL...20 FIGURE 6: COMPONENT CENTRE METHODOLOGY IN A NUTSHELL...22 FIGURE 7: BUSINESS MODEL STRUCTURING CONCEPTS...28 FIGURE 8: PACKAGE STRUCTURE FOR BUSINESS MODEL...29 FIGURE 9: RISK ANALYSIS - IMPORTANCE CONTROL SQUARE...33 FIGURE 0: GOAL MODEL FOR THE COMPONENT CENTRE...35 FIGURE : LINKING GOALS TO PROCESSES...38 FIGURE 2: LINKING PROCESSES TO GOALS...38 FIGURE 3: INITIAL BUSINESS MODEL STRUCTURE...39 FIGURE 4: EXAMPLE ACTIVITYGRAPH...40 FIGURE 5: EXAMPLE PROCESS STRUCTURE DIAGRAM...42 FIGURE 6: COMMUNITIES DETAILING ACTOR-RESOURCES AND PROCESSES...43 FIGURE 7: SUMMARY OF DECOMPOSITION APPROACH...44 FIGURE 8: WARM CONCEPTS RESOURCE...46 FIGURE 9: WARM CONCEPTS STEP...47 FIGURE 20: REQUIREMENTS MODEL WORK PRODUCTS...49 FIGURE 2: SYSTEM BOUNDARY EXAMPLE MEETING ROOM EXAMPLE...52 FIGURE 22: USE CASE DETAILING EXAMPLE...53 FIGURE 23: USE CASE DETAILING EXAMPLE...54 FIGURE 24: USE CASE SCENARIO EXAMPLE...54 FIGURE 25: SUBSYSTEM GROUPING EXAMPLE...57 FIGURE 26 ARCHITECTURE MODEL WORK PRODUCTS...59 FIGURE 27: COMPONENT INTERFACE AND DESIGN PACKAGES...60 FIGURE 28: STRUCTURAL COMPONENT MODEL FOR THE BUATESTCLIENT...63 FIGURE 29: EXAMPLE UML SEQUENCE DIAGRAM IN THE COMPONENT INTERACTION MODEL...64 FIGURE 30: EXAMPLE BUILT-UP AREA SERVICE INTERNAL WORKFLOW MODEL...65 FIGURE 3: EXAMPLE BUILT-UP AREA INTERFACE AND INFORMATION MODEL...68 FIGURE 32: EXAMPLE COMPONENT INFORMATION MODEL EXAMPLE (METADATA)...70 FIGURE 33: EXAMPLE COMPONENT INFORMATION MODEL EXAMPLE (CITY AND ROAD)...70 FIGURE 34: PLATFORM SPECIFIC WORK PRODUCTS...75 FIGURE 35: EXAMPLE OF A PLATFORM SPECIFIC MODEL FOR EJB...77 FIGURE 36: ARCHITECTURE MODEL EXAMPLE...79 FIGURE 37: TAGGED ARCHITECTURE MODEL...80 FIGURE 38: EXAMPLE UMT WITH PLATFORM PROPERTIES...8 FIGURE 39: VARIOUS SPLITS BETWEEN CLIENT AND SERVER FIGURE 40: PACKAGE DEPENDENCIES...84 FIGURE 4: TOP LEVEL MODEL STRUCTURE...84 FIGURE 42: BASIC CONCEPTUAL MODEL...85 FIGURE 43: WARM CONCEPTS STEP...88 FIGURE 44: WARM CONCEPTS ACTOR RESOURCE...88 FIGURE 45: REPRESENTING BUSINESS MODELLING CONCEPTS WITH UML...90 FIGURE 46: STEREOTYPES FOR BUSINESS MODELLING...9 FIGURE 47: PRINCIPLE ICONS USED IN BUSINESS MODELLING...93 FIGURE 48: STRUCTURING CONCEPTS STRUCTURE...95 FIGURE 49: MODEL STRUCTURE EXAMPLE...96 FIGURE 50: REQUIREMENTS METAMODEL...97 FIGURE 5: PILOT USE CASE MODEL SURVEYBOOKING...98 FIGURE 52: ACTORS VIEW...99 Page 8 of 93

9 FIGURE 53: SYSTEM VIEW...00 FIGURE 54: SUBSYSTEM VIEW...00 FIGURE 55: EXAMPLE FROM USE CASE MODELS TO ARCHITECTURE...0 FIGURE 56: EXAMPLE FEATURE MAP...02 FIGURE 57: EXAMPLE OCL CONSTRAINTS...02 FIGURE 58: REFERRING TO METAMODEL RELATIONS...03 FIGURE 59: ADDING PROPERTIES IN A FEATUREMAP...03 FIGURE 60: THE 4+2 TIER ARCHITECTURE...04 FIGURE 6: COMPONENT TYPES...05 FIGURE 62: COMPONENT DISTRIBUTION...06 FIGURE 63: COMPONENT INTERACTION...06 FIGURE 64: COMPONENT COMPOSITIONS...09 FIGURE 65: WORKFLOW INTERACTIONS...0 FIGURE 66: TYPE LIBRARY EXAMPLE... FIGURE 67: DETAILED INTERFACE VIEW...3 FIGURE 68: INTERFACE INFORMATION EXAMPLE...4 FIGURE 69: COMPONENT COLLABORATION VIEW EXAMPLE...5 FIGURE 70: COMBINE PSM...7 FIGURE 7: TENDER BID CONTEXT DIAGRAM...9 FIGURE 72: TENDER BID SCOPE IN MARINE ACQUISITION PROCESS...20 FIGURE 73: TENDER BID GOAL STRUCTURE...22 FIGURE 74: TENDER BID PROCESS OVERVIEW...23 FIGURE 75: RECEIVE ITT & PREPARE FOR BIDDING ACTIVITY DIAGRAM...24 FIGURE 76: GOALS SUPPORTED BY STEPS IN RECEIVE ITT & PREPARE FOR BIDDING PROCESS...24 FIGURE 77: MAKE TENDER ACTIVITY DIAGRAM...26 FIGURE 78: HOW THE PROCESS STEPS IN MAKE TENDER SUPPORTS THE GOALS...27 FIGURE 79: SUBMIT TENDER ACTIVITY DIAGRAM...29 FIGURE 80: BUSINESS INFORMATION DIAGRAM...3 FIGURE 8: EXCEL BASED VESSEL SCHEDULE AS TODAY...33 FIGURE 82: SURVEY BOOKING MAIN USE CASES...34 FIGURE 83: SURVEY BOOKING SUBSYSTEM GROUPING USE CASES...36 FIGURE 84: BOOKING EDITOR USE CASES...37 FIGURE 85: BOOKING VIEWER USE CASES...42 FIGURE 86: SUBSCRIPTION EDITOR USE CASES...43 FIGURE 87: GLOBAL SCHEDULE SERVICE USE CASES...44 FIGURE 88: SUBSCRIPTION SERVICE USE CASES...46 FIGURE 89: SURVEY BOOKING SUBSYSTEM GROUPING USE CASES...48 FIGURE 90: SURVEY BOOKING REFERENCE ARCHITECTURE ANALYSIS...49 FIGURE 9: SURVEY BOOKING COMPONENT STRUCTURE...50 FIGURE 92: BOOKING EDITOR COMPONENT STRUCTURE...5 FIGURE 93: BOOKING EDITOR BUSINESS RESOURCE ANALYSIS...52 FIGURE 94: BUSINESS RESOURCE MODEL MAPPING TO ACTIVITY INFO MODEL...53 FIGURE 95: USER SERVICE INTERFACE OPERATIONS...54 FIGURE 96: USER SERVICE INTERFACE INFORMATION...55 FIGURE 97: BOOKING VIEWER COMPONENT STRUCTURE...56 FIGURE 98: USER SERVICE INTERFACE OPERATIONS...56 FIGURE 99: SUBSCRIPTION EDITOR COMPONENT STRUCTURE...57 FIGURE 00: USER SERVICE INTERFACE OPERATIONS...57 FIGURE 0: USER SERVICE INTERFACE INFORMATION...57 FIGURE 02: BOOKING SERVICE COMPONENT STRUCTURE...58 FIGURE 03: BOOKING SERVICE INTERFACE OPERATIONS...58 FIGURE 04: BOOKING SERVICE INTERFACE INFORMATION...59 FIGURE 05: SUBSCRIPTION SERVICE COMPONENT STRUCTURE...59 FIGURE 06: INTERFACE OPERATIONS FOR INOTIFY AND ISUBSCRIPTION...60 FIGURE 07: SUBSCRIPTION SERVICE INTERFACE INFORMATION...60 Page 9 of 93

10 FIGURE 08: ACTIVITY INFO MODEL...6 FIGURE 09: ACTIVITY INFO COMPONENT STRUCTURE...62 FIGURE 0: ACTIVITYINFO INTERFACE OPERATIONS...62 FIGURE : GUI SCHEDULE...64 FIGURE 2: BOOKING EDITOR USE CASES...65 FIGURE 3: BOOKING EDITOR BCE ANALYSIS DIAGRAM...66 FIGURE 4: BOOK TENDER/LEAD SEQUENCE DIAGRAM FOR PRIMARY SCENARIO...68 FIGURE 5: BOOK TENDER/LEAD SEQUENCE DIAGRAM FOR ALTERNATIVE SCENARIO C...69 FIGURE 6: UPDATE BOOKING STATUS SEQUENCE DIAGRAM FOR PRIMARY SCENARIO...70 FIGURE 7: VIEW SCHEDULE SEQUENCE DIAGRAM FOR ALTERNATIVE SCENARIO A...7 FIGURE 8: BOOKING EDITOR CLIENT CLASS DIAGRAM FROM ANALYSIS...7 FIGURE 9: BOOKING EDITOR INTERNAL DESIGN...72 FIGURE 20: BOOKING VIEWER USE CASES...73 FIGURE 2: BOOKING VIEWER BCE ANALYSIS DIAGRAM...73 FIGURE 22: BOOKING VIEWER CLIENT CLASS DIAGRAM FROM ANALYSIS...74 FIGURE 23: BOOKING VIEWER INTERNAL DESIGN...75 FIGURE 24: SUBSCRIPTION EDITOR USE CASES...75 FIGURE 25: SUBSCRIPTION EDITOR BCE ANALYSIS DIAGRAM...76 FIGURE 26: SUBSCRIPTION EDITOR INTERNAL DESIGN...76 FIGURE 27: BOOKING SERVICE USE CASES...77 FIGURE 28: BOOKING SERVICE BCE ANALYSIS DIAGRAM...77 FIGURE 29: BOOKING SERVICE INTERNAL DESIGN...78 FIGURE 30: BUSINESS RESOURCE MAPPING TO ACTIVITY INFO MODEL FOR BOOKING DATA...78 FIGURE 3: SUBSCRIPTION SERVICE USE CASE DIAGRAM...79 FIGURE 32: SUBSCRIPTION SERVICE BCE ANALYSIS DIAGRAM...79 FIGURE 33: SUBSCRIPTION SERVICE COMPONENT DESIGN...80 FIGURE 34: SURVEY BOOKING APPLICATION COMPONENT ARCHITECTURE...8 FIGURE 35: DESIGN OF SERVLET COMMUNICATION...8 FIGURE 36: DEPLOYMENT OF SERVLET COMMUNICATION...82 FIGURE 37: BOOKINGSERVICEEJB COMPONENT ARCHITECTURE...82 FIGURE 38: REVISED DESIGN OF SERVLET COMMUNICATION...83 FIGURE 39: REVISED DEPLOYMENT OF SERVLET COMMUNICATION...84 FIGURE 40: DESIGN PATTERN FOR WRAPPING EJBS...84 FIGURE 4: DETAILED DESIGN OF BOOKINGSERVICEEJB...85 FIGURE 42: APPLICATION ADMINISTRATOR...86 FIGURE 43: GRAPHICAL APPLICATION BUILDER...87 FIGURE 44: ACTIVITYINFOEJB COMPONENT ARCHITECTURE...87 FIGURE 45: REVISED DESIGN OF SERVLET COMMUNICATION...88 FIGURE 46: REVISED DEPLOYMENT OF SERVLET COMMUNICATION...89 FIGURE 47: DESIGN PATTERN FOR DOUBLE-WRAPPING EJBS...89 FIGURE 48: DETAILED DESIGN OF ACTIVITYINFOEJB...9 FIGURE 49: APPLICATION DEPLOYMENT TOOL BUILDING AN EAR...92 FIGURE 50: APPLICATION DEPLOYMENT TOOL CONFIGURING AN EJB...92 FIGURE 5: APPLICATION DEPLOYMENT TOOL REMOTE DEPLOYMENT...93 Page 0 of 93

11 PREFACE This document describes the models and the modelling process for the COMET methodology: Chapter gives a short background introduction. Chapter 2 presents the COMET methodology. Chapters 3 6 describe the business, requirements, architecture and platform-specific modelling activities of the COMET methodology. Chapters 7 0 describe the business, requirements, architecture and platformspecific metamodels and UML profiles defined in the COMET. Chapters 4 describe the business, requirements, architecture and platformspecific models of the WesternGeco pilot case in the COMBINE project. Page of 93

12 Introduction This document describes the COMET method. It describes a process, a set of techniques and modelling guidelines, which aim to guide COMET users through the development process. The method described in this provides guidelines for specifying and implementing products, system, and components. The process and techniques described here is based on the method developed in the COMBINE project. COMET = COmponent and Model based development METhodology and COMET = COMbine METhodology. The process is a structured set of development methods, procedures and modelling techniques that are used for the specification, development, testing and deployment of products, systems, or components. (The term product later in the document will be used as to mean product, system, or component.) The current focus of this document is on the specification and development aspects. This document is a living document, which will be updated alongside new requirements and experiences from COMET users. This document is accompanied by the COMET toolset document, describing the available tool-support for the methodology. This document describes the COMET methodology. COMET follows a use-case driven, model-focused approach aimed at supporting the process of developing and maintaining products and product families.. Object-oriented COMET is an object-oriented analysis and design methodology. The object-oriented paradigm for modelling is followed, which means that the real world as well as the software systems are viewed and modelled as a set of collaborating objects. The methodology encourages using business objects representing business concepts during the analysis, design and implementation phases. Following the object-oriented paradigm COMET is in contrast to structured analysis based methodologies, which tend to see software systems as a hierarchy of functions operating on common data..2 Component-based One of the driving values behind COMET is the belief that information systems can and should be assembled from components. COMET describes methods and techniques that encourage use of components and business objects as building blocks to build open, flexible and dynamic software systems. There is a strong belief that systems based on self contained components with a sound system architecture will be easier to maintain and evolve..3 Product families/product lines COMET provides a method for development within a product family context..4 Architecture-centric using reference models COMET encourages reusability within product families with the reference model concept. A reference model provides a means of standardising concepts, models, and patterns, and provides a framework for reuse within a domain. Page 2 of 93

13 .5 A cookbook COMET is a stepwise description that gives practical guidelines of how to analyse, design, and implement software systems that is based on business objects. The focus is on systems running in a distributed, component based environment..6 UML-based UML is the preferred notation for the analysis and design models in COMET, and UML is used in examples throughout this handbook. The primary reason is that UML is a widely accepted international standard for expressing object-oriented analysis and design models and is supported by many tools and embraces by many users. Tools supporting UML may be used to support COMET..7 Use Case-driven COMET is a use case driven methodology. Use cases specify interfaces to a system under consideration. Agreed use cases can be seen as formal contracts between the system and it s environment. In COMET these contracts drives the system development process through analysis design and testing. The use cases are also key information when planning a development project and partitioning in increments..8 Architecture driven COMET has a basis reference architecture that it supports..9 Model-driven COMET has defined a set of models that separate concerns and partition the complexities of the total system. Modern software systems and the problems they solve are far too complex for any human being to understand as a whole. COMET therefore has a set of models that allows developers to view and contemplate both the problem domain and the software systems at different levels of abstraction and from different points of view. The COMET models are the deliverables produced by the activities performed during the software engineering processes. These models identify and set focus for the activities and thereby drive the development process. There are models of the problem domain to aid the understanding and expression of what to develop (analysis models). There are models of the software solution to aid the understanding and expression of how to implement it (design models). There are also models of the running system to aid the separating of the implementation according to logical layers of the reference architecture (implementation models). A fundamental idea is to build a complete picture by synthesising from partial models. This is recommended in various forms at all levels of model building..0 Iterative and incremental The classical waterfall process model for software development recommends that software is developed in a breadth first fashion in the sense that first all requirements are defined and agreed upon, then a design for the entire system is developed and then the system is implemented, tested and debugged and finally delivered to the users. Iterative process models split the development into a set of iterations. Each iteration produces a usable system, which is experimented with and reworked and improved in the next iteration until an acceptable system emerges. Incremental process models split the system into components and then implement and integrate component by component. COMET recommends a combination of Page 3 of 93

14 iterative and incremental development, where an initial statement of requirements in the form of a Use Case model is developed in the beginning. Then the system is designed and implemented in increments, one or a few use-cases at a time. Each increment should result in a usable system.. Model-driven approach Within the OMG (Object Management Group) ( the notation of model-driven development is manifested in one of their most recent efforts, called the model-driven architecture (MDA) ( The goal of the MDA is to provide the basic concepts for doing platform-independent architecture modelling and provide the means for transforming these models to platformspecific models or implementation code. The MDA will have impact on how we think about models different model abstraction levels. It will also influence the tool support for the model-driven way of thinking. OMG defines MDA as the following. Model-Driven Architecture (MDA) is an approach to the full lifecycle integration of enterprise systems comprised of software, hardware, humans, and business practices. It provides a systematic framework to understand, design, operate, and evolve all aspects of such enterprise systems, using engineering methods and tools. MDA is based on modeling different aspects and levels of abstraction of a system, and exploiting interrelationships between these models. Figure depicts the conceptual model of OMG s MDA. Figure : OMG MDA The main idea in MDA is to describe systems in a platform-independent manner in what is called a platform-independent model (PIM) in the MDA. From this model, transformations (or mappings) to different platform-specific models (PIM) are defined. The core technologies of the OMG MDA are the UML modelling language, the Meta Object Facility (MOF) and the Common Warehouse Metamodel (CMW). UML provides the baseline for modelling. MOF provides the basis for defining metamodels and model Page 4 of 93

15 repositories. CWM provides the standard foundation data warehousing and data integration. This document will focus on the usage of UML for architecture modelling and the UML extension mechanisms to achieve platform specialisations. Page 5 of 93

16 2 COMET Overview 2. Model Architecture The component centre development process is model driven. There are four models involved: The Business Model, the Requirements Model, the Architecture Model and the Platform Specific Model. These models contain work products that provide the viewpoint specifications for the component-based system or the individual component that is being developed. The models with their work products are the outcome of the system development activities. Figure 2 shows the model architecture and depicts the relations between the model world and the real world (where the COMBINE reference architecture represents the developed system). Figure 2: Model Architecture The details of each model are described in sections Recursive System Architectures The target of consideration during modelling is often referred to as system. System is used to denote entities on many levels, from virtual enterprises where clusters of businesses compose the system down to software objects where collections of data types and operations on these constitute the system. These system levels are related. A virtual Page 6 of 93

17 enterprise consists of interacting businesses and a business consists of interacting actors and technical systems. A software system, one kind of technical system, consists of software components, a software component consists of interacting software objects, and, finally, a software object consists of data types and operations on these. The levels mentioned here are well-established levels, but these are not the only levels that exist. In fact, one can have an arbitrary number of levels by using recursion. For instance, a business may consist of businesses or a technical system may consist of technical systems. Figure 3 shows the common system levels. The curled arrows pointing back to the same level illustrate the recursion. Business2 Business Business3 Business4 Virtual enterprise Decomposition Actor SW System Actor2 HW system Business Decomposition Component Component2 Component3 Component4 Software system Decomposition Object3 Object4 Object Object2 Software component Decomposition Data type Data type2 Operation Data type3 Software object Figure 3: System Levels For software development, two very important levels are the business level and the software system level. The business level contains human actors and technical systems, some of which are software systems. Models on the business level involving a software system depict the intended use of this software system by the actors. In other words, the collection of business models that involve a software system gives the functional requirements for that system. Models on the business level are therefore of paramount importance in software development to ensure that business needs are catered for by the software systems. However, if these models are not related to the software system level they loose much of their value. The software systems in the business models should be decomposed into a configuration of interacting software components so that the software system requirements are met by this configuration. The properties of the software system as specified at the business level (i.e., the requirements) should be at least the same as the properties of the chosen configuration of software components on the software system level. By at least the same as we mean that any property specified at the business level must also be a property of the configuration of software components. This configuration may however have additional properties that are not specified at the business level. In other words, a software system may do more than specified in its requirements. Page 7 of 93

18 Using the system hierarchy model presented above, we assign the software system to be developed as the target system. The context system for the software system is the business, which should be described in the business model and addressed in the requirements models. The software system itself is represented as an application component. The building blocks of the application component are software components. The software components themselves can be further decomposed recursively in terms of smaller-grain components. Figure 4 shows a typical application structure consisting of tool, business service and resource service components. The tool can be further decomposed into user interface and user service components. Application Tool UserService-UserInterface IUser-Interface IInterface-User UserService UserInterface IUser-Business UserService-BusinessService IBusiness-User BusinessS ervice-resources ervice BusinessService IBusiness-Resource IResource-Business ResourceService Figure 4: Application structure In developing new applications one should ideally be able to use or reuse existing software components. The recursive structure allows reuse at various levels of refinement. In order to be able to compose systems from components, one must have a clear description of the collaboration between the components available for reuse. With relationship to the similar recursive nature of the KobrA methodology, our experiences has shown that is can be useful to specialise the use of notations and techniques for different system levels. Page 8 of 93

19 The current focus of the COMET methodology is from the Business system defining the context for a software system, and for the first level of components for that system. For the Business system level we have found it useful for business people to have a business process and activity focus rather than a component collaboration focus, and for the system specification we have found it useful to utilize the principles of use case modelling PIMs vs PSMs A platform-independent model (PIM) is expressed in terms of business, requirements and architecture models. COMET defines two types of platform-independent models: A specificationally complete PIM defines a complete model of the system specification the external architectural structure and behaviour of a component system in terms of a business model, a requirements model and an architecture model as defined by COMET. A computationally complete PIM which adds to a specificationally complete PIM a definition of the system realization the internal design structure and behaviour of a component system in terms of a design model. The design model is expressed using an action semantics language. The term PIM in COMET is typically used to mean a specificationally complete model. Currently, COMET does not advocate a design model expressed in a programming language independent action semantics language. Instead, the algorithmic logic of a component is implemented in a given (set of) programming language(s) as part of the platform-specific model. 2.2 Development Activities An overview of the development process for a Product is shown in Figure 5. This diagram shows the activities performed, and the models produced. This approach is very similar to the Unified Software Development Process. Page 9 of 93

20 Process activities Business modelling Inception Phases Organisation along time Elaboration Construction Transition Requirements modelling Analysis & design (Architecture model) Implementation (Platform Specific Model) Test Supporting activities Project management Work product management Iterations: preliminary iteration(s) iter. # iter. #2 iter. #n iter. #n+ iter. #n+2 iter. #m iter. #m+ Review milestones: Concept Review Prototype Iteration Launch Technical Audit Product Commit Demonstrator Iteration Launch Demonstrator Iteration Launch Demo / Delivery Beta Test Launch Acceptance Meeting Figure 5: The activity view of development process model There are four phases in the development process of any Product of the Component Centre: the Inception Phase, the Elaboration Phase, the Construction Phase and the Transition Phase. The completion of a phase means that the Product under development has reached a certain degree of completeness and thus represents a major milestone of the project. The milestones are shown at the bottom of Figure 5. There are two kinds of activities in the Development Process: process activities and supporting activities. Process activities are activities that are directly related to the system development tasks. They are requirements capture, analysis & design, implementation and test. Supporting activities are activities that support the process activities to ensure that they are carried out effectively and efficiently. They are project management and work product management The completion of each phase represents a major milestone of the software development process. The relative importance of the process activities varies during the life cycle of a development project. In early phases, business modelling, requirements specification and architecture level design tend to dominate, while in later phases the majority of the work is on component design, implementation and testing. This is illustrated in Figure 5, where the curves indicate the effort on each activity as a function of time. Note that the figure shows an example. Exactly how these curves will look depends on the type of project. In more explorative projects for instance, where the requirements and architecture is difficult to stabilise early, significant effort on requirements analysis and Page 20 of 93

21 architectural design may persist all the way to the end of the project. In more straightforward projects, on the other hand, these activities will be more or less completed after the first two phases Models and process activities The models described in Section 2. define the work products of the Development Process activities identified in Figure 5. The Development Process approach is to be understood as a pattern, in the sense that it defines a set of guidelines with ample room for variation, rather than a fixed recipe that can be followed slavishly. This is necessary since each company and each project is unique and must be able to tailor the model to its specific needs. In principle, all the models can be considered during every phase and iteration, with the exception of the Transition Phase, where the Business Model and the Requirements Model should be stable: if new requirements are identified at this stage of the development process, for example because of changes in the business, it is recommended that these are elaborated in another project. Nevertheless, all the work products are not necessarily considered during each phase. For instance should the overall architecture design become stable during the Elaboration phase there would be minor changes on the this model during the construction phase. Remember that each iteration is an increment of the final product under development Summary of the process The Component Centre Development Process involves building a set of models and their associated work products, following the iterative and incremental process paradigm. Except from some work products in the business model and the other requirement work product, the work products are UML-based, and each work product is presented with one or more UML diagrams. Figure 6 depicts this and shows the Development Process in a nutshell. Page 2 of 93

22 Figure 6: Component centre methodology in a nutshell The figure shows all Component Centre development process work products. The icons indicate the associated UML diagram(s) or nature of deliverable for each work product and the arrows show the most common path through the set of work products within an iteration. Starting from the upper left we have the Business model which includes the context statement, vision for change, and risk analysis as well as more formal models of the goals, processes & roles and business resources. The icons indicate use of UML class diagrams for modelling goals and business resources, and UML activity graphs and collaborations for modelling business processes and roles. The Work Analysis Refinement model (WARM) is a refinement of the business process & roles model to identify the required behaviour of the Product under development. In the Requirements model, the use case diagrams are associated with both the system boundary model and the use case scenario model. UML sequence diagrams or activity graphs are used for detailing the use case scenarios. Prototypes might be might be developed for various reasons, such as HCI mock-ups, as a vehicle to get fruitful interaction with end users, or for testing the architecture etc. The Other Requirements work product is typically expressed in text. The BCE model is modelled using UML class diagram with the boundary, control and entity stereotypes. In the Architecture model, the component structure model uses the package concept of UML and UML class diagram. The component interaction model defines the component interaction using UML sequence diagram and/or UML collaboration diagram. The interface model specifies the interface signatures, pre and post conditions for the operations and the abstract Page 22 of 93

23 information model represented by the interface. These are modelled using UML class diagram, as well as using prose text and/or OCL. The platform specific model is typically expressed using UML class diagram and programming languages as well as documentation in various forms (user manual, reference guide, comments within the code etc) Work Contexts Four different work contexts are defined to aid a system developer using the COMBINE Component Centre approach.. The Business Modelling work context (BusinessModule) defines tool support for developing business models according to the concepts defined in the business metamodel. 2. The Requirements Modelling work context (RequirementsModule) defines tool support for developing requirements models according to the concepts defined in the requirements metamodel. 3. The Architecture Modelling work context (ArchitectureModule) defines tool support for developing architecture models according to the concepts defined in the base component metamodel and the architecture metamodel. 4. Finally, for each specific platform there should be defined a Platform-specific design modelling work context (PSMDesignModule) for implementing the platform-specific model. As much technology specific infrastructure as possible should be automatically generated and hidden from the design developer. In order to develop a complete PIM, it is essential that the UML modelling tool supports the three first work contexts. The fourth work context should ideally be provided as part of an integrated development environment (IDE) supporting both UML modelling and programming language implementation, but can also provided as a third-party tool. In COMET, the platform-specific design modelling work context is supported by code generation (in UMT) and IDE tools integrated with the UML modelling tool. 2.3 Development Phases The COMET methodology addresses how to develop a new Application Component. This might be when you: want to automate tasks and processes that until now have been executed manually want to perform tasks and processes in a new way, e.g., based on a Business Process Reengineering activity The suggested procedure for developing a new Application Component concerning the four phases is described below Inception phase. Interview users and key stakeholders, study any competing solutions that might exist. 2. Unless one already exists, develop an as is Use Case Model based on information gathered from step (one iteration, focus on System Boundary Model part). Page 23 of 93

24 3. Derive the context and identify the use cases and actors using the use case technique. Make a first version of the to be System Boundary Model: a. Context statement, (derive what is necessary. An informal rich picture or a full Context Business Model) b. Identify actors c. Identify use cases and associate extra requirements 4. Make a first draft of the: a. Vision for change b. Risk analysis (concentrate on identifying and analyze the business risks at this stage) c. Goal model, (link to top level process(es)) 5. Identify the main business resources (Business Resource Model) 6. Start deriving the business processes (Business Process Model). This step and the one above are conducted together: a. Identify and study the main business processes b. Identify which activities are performed entirely by a human, by a human supported by a tool, or entirely and automatically by the Product being developed (as part of the system). This is known as Work Analysis Refinement modelling (WARM) 7. Make a prototype if necessary to: a. Sell the idea b. Communicate with stakeholders (e.g. discuss requirements) c. Reduce business risks 8. Align the Business Model and the System Boundary Model 9. Derive Concept Deliverable including the project proposal 0. Iteration review Iterate the steps in this phase until the business risks are under control (normally one or two iterations) - or Stop if there is a decision from a review not to proceed Elaboration phase. Refine the Vision for change, Context statement and Risk analysis (focus on technical risks), 2. Refine and detail the use case model using the use case template 3. Update and refine the Business Process Model and Business Resource Model if needed: a. Derive and update the relationships between the Use Case model and the Business Model (goals, activities and resources) 4. Start on identifying subsystems and components either by: a. Organize the use cases into subsystems (application, tool and business service components (typically in that order) applying the reference architecture analysis: b. Or identify the tool and user tier components using the use case model, and the other COMBINE components applying the work element analysis Page 24 of 93

25 5. Derive the overall static architecture/component structure (Component Structure and Internal Design) based on previous step and extra requirements (quality of service requirements). Extra requirements are picked from the Use Case Model (use case template) a. Additional strategies for subsystem design might also be used. 6. Start on deriving the interfaces of the components and the component collaboration (Interface and Interaction Specification) either by: a. Specify the interface contract (operations, protocol and semantics)as well as the abstract information model (entities) visible through the interface by analyzing the use-case scenario descriptions. The entities might also be identified from the Business Resource Model. b. Specify the Interface contract and the entities using the work element analysis. 7. Make prototype(s) (might evolve to be the first increment of the system) to: a. Test the architecture b. Reduce technical risks c. Communicate with stakeholders (e.g. discuss requirements) 8. Consolidate the results from the steps of the phase to prepare the Elaboration deliverable including the Product Development Plan defining the increments for the Construction Phase (risk driven - use case or a couple of use cases per increment). 9. Iteration review Iterate the steps in this phase until the technical risks are under control (normally two or three iterations) - or Stop if there is a decision from a review not to proceed Construction phase. Review the Construction Authorisation (for the first increment) or the Product Evaluation (for the subsequent increments. a. Requirements management (store, prioritize and maintain) b. Model updates (Business Model and Requirements Model) c. Product development plan updates (risk driven increment plan, use case or a couple of use cases per increment) 2. Evolve the Interface and Interaction Specification for the current increment 3. Design the internals of the components. Use BCE or other design/architectural patterns. 4. Revise the Component Structure if necessary 5. Implement increment: a. UMT configuration b. Code generation c. Implementation d. Plan and test deployment 6. Integrate and test Product increment. 7. Product evaluation (Increment review) Iterate the steps in this phase until the requirements are met. Deliver the planned increments - or Stop if there is a decision from a review not to proceed. Iterations are determined by the increments defined by the Product Development Plan Page 25 of 93

26 2.3.4 Transition phase. Review Transition Authorization (for first iteration) or Acceptance Evaluation for subsequent iterations and decide Product modifications required. 2. Implement Product modifications 3. Deploy Product at designated site. Integrate and test 4. Iteration review Iterate the steps in this phase until the system is accepted (deployed and stable) Page 26 of 93

27 3 Business Modelling 3. Introduction The Business Model is used to express the part played by the Product (system or component) being developed in the context of the business that will fund its development (or purchase it) and use it. It also provides elements that link extremely well to the Architecture Model. The Business Model includes goals, business processes, steps within business processes, roles and resources. The scope (or domain) of the model is any part of the world defined as interesting for a company, organisation or others, and which has some impact on the required behaviour or other characteristic of the Product. The business model might be broadly or narrowly scoped, e.g. describing the entire business of a company or describing the immediate environment and context of a Product under consideration. Thus, the business model is recursive in the sense that some business models might detail aspects of another more broadly scoped/higher level business model. The set of work products of a business model is outlined below. A Business Model consists of the work products listed below. A set of Scoping Statements, consisting of the following: o The context statement, which defines the scope and positions this business model in its context. o Vision for change, which describes what to improve, the motivation (i.e. what is wrong with the current situation), a description or indication of what the improvements might be and a gap analysis. o Risk analysis, which identifies the business and technical risks related to a development project for the proposed Product. A Goal model, which describes the business goals that will be met by implementing and then using the Product. A Community model, in which is prepared through a combination of three modelling activities: o Business Process and Role Modelling, which prepares a behavioural model that defines, in terms of roles and steps, the business processes of the domain which are relevant to the Product, and which will enable the goals to be met, and gives a full definition of the roles in the business, including those fulfilled by the Application Components which are to be developed. o Business Resource Modelling which prepares an information model that identifies and defines the concepts of the domain that are relevant to the Product, including the actors that do things, and the artifacts that have things done to or with them. o Work Analysis Refinement Modelling (WARM) which further refines the Resource model and the Process model by categorising resources by the kind of role they play (e.g. Human user, tool, business service, etc), and by identifying, for every step in the Process model, the responsibility in the system for performing it. The WARM activity also allows identification of Work Elements, which are used by the Architecture Modeller (or mapping tool) to derive its first-cut component model. Note that the WARM is not a separate model as such, merely refinement of a model from an earlier stage in the process. Page 27 of 93

28 It is most important to note that the above structure is only a structure. It should not be thought of as defining the sequence of activities for developing these work products. Thus, for example, although the Context Statement and Vision for Change would obviously be started and well developed before significant development of the other elements takes place, they are not cast in stone at the beginning of the project, and may be revised at any time subsequently. Similarly the Goal model may be revised as the Business Process and Resource models are developed. Finally, and most commonly, the Business Process model and the Resource model are almost invariably developed in parallel. 3.2 Modelling framework for the Business Model Of the Business Modelling work products, some are formal models and some are documents, but all should be stored as packages within the context of the single platform independent model (PIM) of the Product. The exact mechanism for doing this will vary from tool to tool, but most tools provide the facility for a model element to be linked to a document. Thus, those work products that are documents may be represented by a single package with a link to the document. The figure below illustrates the structuring concepts of the business model. Figure 7: Business Model Structuring Concepts The figure below shows a suggested package structure where a Business Model is part of a full Platform Independent Model. Page 28 of 93

29 3.3 The Context Statement 3.3. Modelling Objectives Figure 8: Package structure for Business Model The purpose of the Context Statement is to define the scope of a business model and to position it in its context. This may be done by identifying relationships to some other business models or by developing and getting agreement to a more informal representation of the target business being modelled in its environment. This informal representation takes the form of a domain picture aiming to give an overall understanding of the domain. It focuses on describing stakeholders and their relationships and identifies stakeholders concerns. It typically covers key value-chains and information flows. The emphasis is on the process of building it, agreeing it with subject matter experts and thereby understanding the context. Thus, it may not be maintained in subsequent phases of the development of the Product Methods and Techniques The first step in developing any business model is to identify and record the names of all people who will have an interest in having the Product developed or in its use, the business stakeholders, together with the nature of their interest. This list may change over time but should always include representatives of all having an interest in the Product in any way. The following are examples of business stakeholders who should be involved: people who will authorise funding for development of the Product; people who are responsible for design and maintenance of the business processes to be supported by the Product; people who will use the Product; people who will be responsible for the acceptance of the Product; people who will be responsible for managing operation of the Product Page 29 of 93

30 The approach taken to developing a Context Statement depends on the existence or not of some higher level business model of which the new model forms a part. Whatever the approach, however, the process consists of fact finding, discussion and agreement with all business stakeholders, using one or more small workshops or interviews followed by one or more feed-back sessions at which draft models are presented and walked through. It is most important not to get bogged down in detail at this stage, and therefore it may be that the workshops or interviews are very short, and they may, where the Context Statement can be agreed, be combined with the workshops and interviews used to develop the later business modelling work products. However, it is equally important that the full scope (and limitations to scope) of the project is clearly understood, and that all stakeholders agree to this. In all events, progression to subsequent business modelling work products should not commence until this agreement is reached, even if only informally. Where no higher level model exists, an informal representation of the context of the Component to be developed may be prepared. This may use Use Case modelling techniques as described under Requirements Modelling. Alternatively the concepts of a Rich Picture may be used. This is a highly informal modelling technique, and subtle nuances of meaning should be avoided or disregarded. The key point is the understanding of the business context that all share at the end of the exercise, to which end it may only be said about the resultant model that the business context is something like this. Informality and lack of rigour at this stage does not matter, as it will be added in the other business modelling work products. Thus, where a Rich Picture is used for this Work Product, it should be remembered that it will be superseded by the more formal models that are later developed. A Rich Picture should not form any part of a delivered Product s formal documentation. Where a higher level model exists, then the Context Statement would be prepared through a process of examination of the higher level model in order to identify those items that have any impact on the business model being produced. Thus it would identify, for further detailing: all roles that appear in, or interact with roles that appear in, the business model being produced; all actors associated with those roles; all resources associated with those roles Deliverables and Notation The notation used for the Context Statement depends on the existence or not of a higher level Business Model. Where that exists, the notation will be the notation of the subsets of that model used. Where no higher level model exists, the notation may be a Rich Picture or a set of Use Cases. In all cases, it will be accompanied by a list giving details of all Business Stakeholders. 3.4 The Vision Statement This work product is a statement of what to improve, the motivation (i.e. what is wrong with the current situation), a description or indication of what the improvements might be and a gap analysis (a clear understanding of difference between the current and desired situations). Page 30 of 93

31 3.4. Modelling Objectives This work product adds detail to the scope given in the Context Statement, so that Business Stakeholders can make informed judgements about approving the (appropriate phase of) development of the Product Methods and Techniques This document would be produced by a series of meetings, and the preparation and circulation drafts until agreement on its content is achieved by the Business Stakeholders identified at the start of the Project Deliverables and Notation The vision for change document is short and describes what the Product will be and why it is needed. It will consist of some or all of the following elements: General business/product vision and goals, including background explaining why the Product is needed; Business opportunities and business benefits; Product description and technical business vision how the Product might be deployed and used; Presentation material summarising the above. 3.5 Risk Analysis The risk analysis describes marketing factors that might influence the product, good or bad, and things that are required that are not described in the business vision and product description work product. An estimate of the anticipated return of investment (ROI) is also part of this work product Modelling Objectives The objective of the Risk Analysis is to identify all risks to the project and ensure that suitable contingency plans are in place Methods and Techniques The approach to developing the risk analysis is to examine all possible ways that the programme, from development through to the Product s in service life, might go wrong, and to identify the level of risk involved (probability of a bad thing happening), the cost that would be incurred if it happened, and contingency plans to reduce that cost to acceptable levels. All types of risk should be considered, including commercial risk (failure to give the intended return on investment), business risk (impact on the business of failure of the Product, either before or after deployment), programme risk (failure to deliver on time), development risk (Product development is more difficult or costly than expected) and support risk (high cost of user support or maintenance because of Product fragility). Factors to be considered when investigating and considering risks are dependent of the type of Product being developed, and this also influences how much effort to use on the risk analysis. The following questions should be asked: Does the Product concern any critical or core part of the business? What is the size of the investment? What is the size of the project? Page 3 of 93

32 Is it crucial to follow up the idea in order to stay in business? When doing risk analysis, start with making a list of risk factors. Be creative and brainstorm a lot when creating this list. Some issues that typically should be considered are: What market and market trends that will influence the project? Who and what are the competition? What are the strengths and weakness of the competitors? What are the technology dependencies? Are there Legacy systems to interface with? What is the expected time frame for the product? How many users will there be? What are the availability requirements? What is the likely steady state and peak number of transactions? Be sure to include all the things that can go wrong; only writing down things that you would like to happen is a sure recipe for disaster. Some common examples of things that might go wrong are: Lack of user acceptance Dependence on a technology that changes Not fast enough to market Development team not experienced enough Too many users Too short a schedule Too fast to market Supplier failure to deliver a product that we are dependent on. Take the list of risks and eliminate extremes or those for which effectively no plan can be made (such as a comet hitting the Earth), and prioritise the rest. The importance/control square shown in the figure below might be used to prioritise the risks. In this square the risks are categorised based on their importance and to what extent it might be controlled. Typically market trends are important but hard to control, while handling many simultaneous users might be of high or low importance, but is easier to control. Easier to control means that it is a risk that is independent of external actors and processes, so it is up to you to decide to deal with it. The risks within each square should again be prioritised, for instance sequentially or with a number showing the degree of importance. For each a statement should be prepared explaining, depending on the control level possible, the measures to be taken to reduce the probability of the risk occurring, or the measures to be taken to reduce the impact in the event that it does. As part of the risk analysis, put together and maintain a list of assumptions. These are decisions made with little or no hard data. Assumptions are based on gut feel or experience. This list should be reviewed regularly, if possible try to get some hard data to base the decisions Page 32 of 93

33 Figure 9: Risk analysis - Importance control square A Return On Investment (ROI) document may also be part of the risk analysis, and is created by using appropriate economic models. The business vision, product description and the list of risks serves as input on the early iterations. In later iterations analysing the evolving use case model (function point analysis) are done for estimating the amount of investment. Involving people that are experienced with doing ROI analysis is important. During the inception phase the first risk analysis is created. The list of risks will typically evolve and change through all phases of the project. The risk analysis is important when deciding which use cases to implement in the different iterations of the construction phase. Following a risk driven system development approach implies development of the use cases associated with the highest risks early Deliverables and Notation The deliverables of the risk analysis work product are: A document with categorised and prioritised list of risks and preventative measures. A document listing the assumptions A Return On Investment (ROI) document 3.6 The Goal Model 3.6. Modelling Objectives The purpose of the Goal Model is to agree with the Business Stakeholders (see Context Statement) the business goals that will be met by implementing and then using the Product, so that a set of required high level business processes can be identified for further analysis in the Business Process Model. Once produced and agreed, the goal model serves as a reference, throughout the Product's life, that ensures that a full assessment may be made of all the business implications of any proposed changes to the Product which have any impact on the business processes it supports Methods and Techniques The goal model describes a loose hierarchy of goals of the business within the particular area of concern, starting with the goals of a Business Stakeholder in developing or buying the Product, and leading to the detailed business goals met by the Product or its users when using it. Page 33 of 93

34 The Goal Model is discovered by a process of workshops and interviews involving all stakeholders (as identified in development of the Context Statement). The initial question is "What is the desired state of affairs that we wish to bring about as a result of implementation of the Product?" There may be one or a (small) number of answers to this question, and the implications of these answers may lead to further refining questions of the form "If that is our high level goal, what, if any, sub-goals can we identify, the attainment of which will further that primary goal?", and by this means a quasi-hierarchical set of goals is identified and detailed. Goals must be achievable, preferably measurable, and not self-evident, and should have clear and detailed implications. It should be reasonable (but not necessarily appropriate, and almost certainly not correct) to assert an alternative. The implications should be expressible in terms of a set of sub-goals or enabling processes. Thus "to have total customer satisfaction" is probably not a useful goal, as it is neither achievable nor measurable, and the alternative (no customer satisfaction) could hardly be argued. A more useful goal in this case might be of the form "95% of all customer complaints are resolved to the customer's satisfaction within 2 hours". One of the key aims of Goal modelling is to identify the things that have to happen in the business for the goals to be met. These are the enabling processes which form the starting point of the Business Process model Deliverables and Notation The Goal Model is the first part of the Business Model to be produced using the UML based business modelling conceptual model. Initially it may take the form of text but it must then be represented in a UML model as a loose hierarchy of classes each stereotyped as <<Goal>> and presented in a class diagram. The figure below shows a view on the goals of the Component Centre. Page 34 of 93

35 3.7 The Community Model Figure 0: Goal Model for the Component Centre The Community Model is a container for that part of the Business model that details the business processes and business resources that are relevant to the Product. It is called "Community Model" because the concept of Community (which represents a collection of resources working together, in one or more processes, to achieve one or more goals) is the key to performing recursive, parallel, and decomposition of both behaviour and structure, essential for successful business process modelling. Thus the model's primary structure is of a set of communities, each of which is itself structured in terms of what it is (resources) and what it does (processes). The first step in preparing the Community Model, and the contained Business Process and Resource models, is to create a package to contain the Community model, and, within it, a further package, stereotyped as <<Community>>, to represent the top level community. Within this <<Community>> package, create two further packages to contain respectively, the Resources visible at this top level, and the enabling behaviours that support the goals defined in the Goal model. The Community Model is prepared through a combination of three modelling activities: Business Process and Role Modelling, which prepares a behavioural model that defines, in terms of roles and steps, the business processes of the domain which are relevant to the Product, and which will enable the goals to be met, and gives a full Page 35 of 93

36 definition of the roles in the business, including those fulfilled by the Application Components which are to be developed. Business Resource Modelling, which prepares an information model that identifies and defines the concepts of the domain that are relevant to the Product, including the actors that do things, and the artefacts that have things done to or with them. Work Analysis Refinement Modelling (WARM) which further refines the Resource model and the Process model by categorising resources by the kind of role they play (e.g. Human user, tool, business service, etc), and by identifying, for every step in the Process model the responsibility in the system for performing it. Note that the WARM is not a separate model as such, merely refinement of a model from an earlier stage in the process. An important refinement is Work Element Analysis, which identifies groupings of the business processes and resources that map to major resources-as-artefacts, and also to sets of processes typically carried out by a single department or division in the business. Given the CBD nature of the Architecture Model, these "work elements" are good candidates for a first-cut component design. 3.8 The Business Process & Roles Model The Business Process and Roles model (generally called the Business Process or Process model) defines the business processes of the domain which are relevant to the Product, and which will enable the goals to be met, and: the roles of the resources that perform those processes. This model may be at a number of levels of detail, from a high level description of the business processes down to the WARM, which is a set of detailed specifications for the business services that each IT element in the Product will provide. It includes a full definition of the roles in the business, focusing on those fulfilled by the system or component to be developed. The Business Process and Roles model is generally prepared at the same time as the associated Business Resource model. To build a Business Process model the Business Modelling Conceptual Model (or metamodel) is used. Each business process is defined in terms of its steps, and each step performed by a resource at a higher level of detail may then be treated as a process performed by a community (of resources) and further analysed at a lower level of detail. Eventually, using the WARM concepts of Human Step, Tool Step and Immediate Step, "leaf" steps will be defined, and assigned to specific elements of the Product to be developed. The time to stop analysing is when, by analysing the processes, the Product's role in them is defined, and when there are no more questions about the business to be answered Modelling Objectives The objective of the Business Process Model is to identify and detail all the business processes supported by the Product to the extent necessary to detail the roles of the Product (and its components, i.e. Application Components, Business Service Components and Tool Components). Page 36 of 93

37 3.8.2 Methods and Techniques The Business Process Model is derived through a set of activities that encompass brainstorming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool Derive initial process model from the goal model The Business Process Model is derived directly from the Goal Model. Goals may be thought of as high level statements of the things that have to happen in a business, each expressed as an outcome, but in a way that leaves unspecified how that outcome is to be made to occur. As goal analysis proceeds, the analyst becomes aware that he or she is increasingly describing not so much a desired outcome as the means by which a higher level outcome is to be achieved, namely an enabling behaviour. The distinction between goal and behaviour to achieve a goal is inevitably blurred and to some extent subjective. The key thing to remember is that, whereas a goal is some desired state of affairs, a behaviour is a specification for something that happens, the end result of which is the desired state of affairs. Thus, the first step in creating the Business Process Model will be the identification of the enabling behaviours that have to happen for each goal to be achieved. Initially this is done through a brain-storming process and production of an unstructured list of enabling behaviours for each goal. This list is then consolidated into a single set of enabling behaviours that, together, support all goals. This is the starting point for the Business Process Model which may then be entered into the tool using the Business Process Modelling Profile. Each Enabling Behaviour is entered into the package containing the business processes in the top level Community model (see modelling framework) as a Class stereotyped either as <<Business Process>>, where it can clearly be seen that this behaviour can be represented as a set of steps with a defined beginning and end, or, where no such approach is apparent, as a <<Behavioural Policy>>. The distinction between the two kinds of Enabling Behaviour may be subjective. The key point is that Business Processes should be capable of being expressed as a set of structured steps, each performed by some actor (resource) representing a concrete person, a machine (e.g. an IT system) or a collection of people and/ or machines. Associations, stereotyped as <<Enabled by>>, are then created between each goal and each of the Enabling Behaviours that supports it. The result is a network of relationships that shows both which Enabling Behaviours support each goal, and which goals are supported by each Enabling Behaviour. A complete diagram representing all these relationships may be drawn, but would probably be too complex to be useful. The figures below show an example taken from the Business Model for the Component Centre. The first figure shows the Enabling Behaviours that support the goal to "Meet Market needs with IT business solutions". Page 37 of 93

38 Figure : Linking Goals to Processes The figure below shows the goals supported by one of the business processes that support the goal "Meet Market needs with IT business solutions", namely "Product Development Process". Figure 2: Linking Processes to Goals In general, it may be expected that Behavioural Policies constrain Business Processes, and, although they represent behaviours, they cannot, in the model, be further detailed to identify steps that the Product performs. Their presence in the model is, therefore, initially to assist in detailing the business processes, and, subsequently, to show that all the goals identified are properly achieved by some behaviour, and that, where this behaviour is supported by the Product, it is represented in business processes that are fully detailed to the level necessary to identify the Product's role in the Business, as constrained by the Behavioural Policies Detailing of Business Processes and Resources Each business process that involves the Product in any way has to be detailed to the extent that, when the model is complete, the Product's role in that business process is fully understood and specified. In general (but not exclusively), the reason for detailing a process is because the actorresource that performs that process is a composite that includes the Product being modelled together with some other resources, not part of this development, such as a user or an Page 38 of 93

39 interfacing system or component. Thus, it is necessary to detail both the process itself and the structure of actor resource that performs that process, and the method for detailing processes is one in which both concepts are decomposed in parallel. In short, the process being detailed (which may be some step in a higher level process), a thing that has to happen, is considered as consisting of a set of steps, and: the thing that performs that higher level step, an actor resource, is considered, at a more detailed level, as a community of resources each fulfilling a role, each role being responsible for one or more of the steps in the detailed process. Note that the "sequence" or focus of doing the two decompositions listed above may be either the behaviour (processes) of the resource or its structure. It may, in a full model, be a mixture of the two. In some circumstances it may be the case that the structure and broad roles of the constituents of an actor-resource are pre-defined, in which case the appropriate approach may be to say, at the commencement of detailing some business process, "Let us examine the roles played by this organisational entity (modelled as an actor-resource), and, concurrently, examine the detail of the processes in which it is involved." Alternatively, in some circumstances, it may be more appropriate to say, "We know this thing has to happen, and that this high level actor-resource makes it happen; let us examine the way it happens (i.e. the things that are done), and then identify a suitable structure for the high level actor-resource to support it." Doing this in UML.4 is not straightforward, but a means of doing so, using the Business Modelling Module in the COMBINE Profile has been detailed. The step-by-step method for developing a process model is described in the following paragraphs. It is assumed that a Business model with the basic structure of Context Statements, Goal Model and Community Model has been prepared, and that the Goal modelling has been completed to identify all the top level processes in which the Product is involved, and that the (goal driven) enabling behaviours have been identified included in the model. The resulting initial model will be of the form shown below. Figure 3: Initial Business Model Structure. For each Business Process, attach an ActivityGraph, with associated Activity Diagram, both with the same name as the Business Process, to contain: Page 39 of 93

40 a. the steps of the process, as SubActivityStates, stereotyped as <<Step>> b. the resources in roles responsible for performing those steps, as Partitions, stereotyped as <<ResourceAsRole>> c. the information flows between steps, as ObjectFlowStates, stereotyped as <<ResourceAsArtifact>>. 2. For each ObjectFlowState, identify or create a class, in the Business Resource Model, stereotyped as <<Resource>> and set it as the Base Class. 3. Similarly, for each Partition, identify or create an actor, in the Business Resource Model, stereotyped as <<ActorResource>> and set it as the "Represented Object". An example of the ActivityGraph for one of the Processes is in shown below. Figure 4: Example ActivityGraph When this has been done for all enabling behaviours that have been categorised as business processes, the top level process model may be thought of as complete. However, it is unlikely that this will be in sufficient detail to identify the required behaviour (as steps) of the Product under development, so further decomposition will be required. In general, further Page 40 of 93

41 decomposition is always required so long as there are unexpanded steps, of business significance, which are performed by some resource that is a composite of the Product and some other resource, such as a user or an interfacing component, not part of this development. In this process of decomposition, as mentioned above, the focus may be on the structure, or on the behaviour, or, across a full model, a combination of the two. Here we describe the decomposition process where the focus is on the structure, i.e. the intention is to examine the role of a composite resource and detail the behaviour of its components. Here we take the case where we know the structure of the business resource that performs the processes being detailed, and intend to base the structure of the model (at least at this level of detail) around that structure. 4. Create a package, stereotyped as <<Community>>, that represents one of the resources we wish to detail fulfilling all its roles in the higher level Community of which it is a member, and name it appropriately so that it identifies both the resource to which it maps and the behaviour being detailed. This is an instance of the link "represents" between the concepts "Resource as Role" and "Community" in the Profile model. For model management purposes and ease of comprehension of the model, create two packages within this Community package, to contain, respectively, the business processes that the resource mapping to the community performs, and the resources which comprise this community. 5. For each Step performed by the higher level ResourceAsRole to which this community maps, create, within the namespace of the business processes package of this <<Community>>, a class stereotyped as <<BusinessProcess>>, with the same name as the Step concerned. Attach an ActivityGraph, and an associated Activity Diagram, to this class, both also with the same name as the Step being detailed. 6. Repeat steps and 2 above, to detail this process. 7. Repeat steps 4, 5 and 6 above, for all resources at this level of the model in which the Product is involved (i.e. has some step to perform). Additionally, and optionally, the structure of each process may be represented in a class model, as follows: 8. Create a class diagram for each process, and represent on it, its component steps (as classes stereotyped as <<BusinessProcess>>, each associated with a Composition to the parent process, and the actors that perform them, as shown in the figure below. Note that this is a convenience diagram, used to assist in understanding or presenting the model. It is optional, and there are no essential links from this part of the model to any other part of the PIM. Page 4 of 93

42 Figure 5: Example Process Structure diagram The result at this point, after one such cycle of decomposition, might look like the figure below. Page 42 of 93

43 Figure 6: Communities detailing Actor-resources and Processes In this example model, a development from the initial business model structure, in the top level community "The Business" we have identified two business processes: P and P2 (which support the Goals), two actor-resources, Fred's Group and Joe's Group, and two other resources, Resource and Resource 2, which appear as artefacts in Process P. At this point only P has been detailed, in an ActivityGraph, which has identified a number of steps, including Steps and 3 which are performed by Fred's Group. Decomposition, in order to identify the required behaviour of the Product that is the focus of this model, has concentrated initially on the two actor-resources, and communities representing each of these have been created within the Business Processes package of the higher-level community. Thus there is a community representing Fred's Group and its behaviour in the top level processes (noting that only P has been detailed as yet), and another community representing Joe's Group and its behaviour in those processes. Within each of these second level communities we have a process package, where we identify the processes performed by the resource that maps to the community (in the case of Fred's Group there are, at this point, P Step and P Step 3; it is likely that there will be some steps of Process P2 that will be included when P2 is detailed). We also have a resource package that includes the resources (performers and artifacts) that are required for the processes to be executed. The decomposition process, and the relationships between model elements, is summarised in the diagram below. Page 43 of 93

44 Figure 7: Summary of Decomposition approach The process of decomposition as described above is carried out until all processes are detailed to the extent that no step in the model is performed by any composite resource that includes both the Product and some resource that is not the Product. Where the focus for decomposition is a process and its steps, the equivalent procedure (to detail a step, in an ActivityGraph representing a Process in some higher level community) is essentially the same, with the exception that the lower level community that is used for the container of the detail will only contain those processes that are relevant to some particular part of the model. Under such circumstances there may be more than on community that maps to a single higher level actor-resource Deliverables and Notation The Business Process Model is delivered as one or more packages in the overall UML model for the Product. 3.9 The Business Resource Model 3.9. Modelling Objectives The Business Resource Model is an information model that identifies and defines the main things (and concepts) of the domain that are relevant to the Product, these being, in general, those things that do things in the business (including the Product itself), and those things that have things done to or with them, and details the relationships between these concepts. Page 44 of 93

45 A Product comprises a complete and consistent set of models for the Product, namely Business Model, Requirements Model, Architecture Model and one or more Platform Specific Model together with the corresponding Executables Methods and Techniques The Business Resource Model is generally prepared at the same time as the associated Business Process & Roles model, and methods and techniques used are similar, i.e. activities that include brain-storming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool. The Resources that are of concern to the business will mostly, but not entirely, be discovered from consideration of the things that have to happen in the business (as contained in the Business Process Model). All resources either make those things happen, or are involved in those things that happen, in that, what happens, happens to them. In addition, reference should be made to, and consistency maintained with, the Context Statement, since that is a representation at a high level of all the main things of interest to the Product. The set of business concepts are then refined into a class model, at the level of detail being considered which defines the interesting attributes of and relationships between all the resources (both actors and artefacts) identified in the Business Process Model. The conceptual model used is the same as for the Business Process model, namely the Business Modelling Conceptual Model, with additional freedom to add any relevant associations, attributes and state machines, as provided by standard UML. Packaging of this class model is a modelling choice, but dependencies can be reduced by confining resources to the communities with which they are involved. Thus, each «Community» package would contain two packages, one with the relevant Business Process Model, the other with the relevant Business Resource Model Deliverables and Notation The Business Resource Model takes the form of a UML class model as part of the PIM for the Product (see the example model structure). In cases where it is useful it may be accompanied by state machine models for any of the resources modelled. 3.0 Work Analysis Refinement Model (WARM) 3.0. Modelling Objectives As its name suggests, the WARM is a refinement of the basic Business model which concentrates on "Work Analysis", i.e., which kinds of resources do which kind of work. Specifically, it concentrates on those resources that will form part of the Product being developed, and the behaviour (expressed as Steps in Processes) that they will be required to exhibit Methods and Techniques The WARM is not a separate model, or even a separately identifiable element in a model. It is a final refinement of both the Business Process & Roles model and the Business Resource model, (both, themselves, distributed amongst a variety of Community models), in which the Steps in the Business Process model are refined and assigned to specific refined Actor Page 45 of 93

46 Resources. It is from this part of the model that the role, in the business, of a particular IT element, can be ascertained. The WARM concepts that specialise Actor Resource are illustrated in the figure below: Figure 8: WARM Concepts Resource Resources are refined to identify the IT elements that fulfil roles in the business, as follows: A Product in the WARM is an actor resource that fulfils a role in the business and maps to the executable part of a Product. A Business Service is a Resource with a role in the business, and represents an IT element that maps to a Business Service Component in the corresponding Architecture model. A Workflow is an actor resource that maps to a Workflow Definition in a corresponding Architecture model which contains the business logic of a process and determines the sequencing of steps within any instance of that process. A Human/Tool is an actor resource with a role in the business that is fulfilled by a human working with an IT element that maps to a Tool Component in the corresponding Architecture model An Other System is an actor resource that represents an external automatic system that fulfils a role in the Business Process Model In addition, so that the model can be complete, we identify: A Human (user) is an actor resource that represents a human that fulfils a role in the Business Process Model. The System represents the complete IT facility that supports the business including all Products and the Infrastructure. Page 46 of 93

47 The WARM concepts that specialise the business process modelling concept of Step are illustrated below: Figure 9: WARM Concepts Step In WARM refinement of the Business Process model, the kinds of step performed by resources in the model are further categorised as follows: A Human Step is a step performed by a human with no involvement of the Product being modelled. An Extended Step is a Step in which the intermediate states are of interest to the business, and may have to be remembered. This may be either because there are business reasons for such interest, or because other factors, including technology, require that the business be concerned. An extended step is a candidate for choreography by a Workflow. A Tool Step is a step performed by a human user interacting with a tool that is part of the Product. The human user will use some form of interactive device (e.g. a GUI) to interact with the Product. A Tool Step is a candidate for realisation by a Tool Component. An Immediate Step is a Step that is required to complete as soon as possible, and whose intermediate states are of no concern to the business. It is performed autonomously, with no intervention from a human. An Immediate Step may be mapped to an Operation on a Business Service Component (Process) in the Architecture Model. Each such operation on a Business Service Component in the Architecture will run in an ACID transaction, thereby either completing or leaving state as it was. The Name of the step is the verb or verb phrase that describes the process (for example, "Modify Customer record"). If a resource is specified as part of the name or description (for example "Modify Customer using Info from Sales Person") then the model should identify the relevant Resources. Page 47 of 93

48 3.0.3 Deliverables and Notation As explained above, the WARM is not a separate model, but an extension to and refinement of the Business Process model and the Business Resource model. Thus the deliverables and notations are as for those models. Page 48 of 93

49 4 Requirements Modelling 4. Introduction The requirements model identifies the system requirements. These include functional requirements, non-functional requirements (quality of service) and constraints. Non-functional requirements are statements concerning performance, availability, security, reliability and so forth. There are also other requirements specifying constraints that will have impact on the system to be developed, for instance available resources, special customer preferences, company strategy etc. Use cases and scenario descriptions are used to capture the functional requirements. These use cases and scenario descriptions are also used to structure some of the non-functional requirements and constraints. Figure 20 shows the work products of the requirements model. : Registrator registerclub : Secretariat Application clubexists registerclub : ClubRegister Prototypes System Boundary Model Use case scenario Model Arnor er en kul type Dette er et forsøk på å fylle denne kommenten med text Non-functional requirements Figure 20: Requirements model work products The Requirements Model contains the following work products: The Use Case Model. 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: o 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. o 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. Prototype. One or more prototypes may be produced during development of the Product, in order to test understanding of the requirement, or particular aspects of the design (e.g. HCI). Non-functional requirements. This work product identifies constraints, general requirements and other kinds of non-functional requirements not fitting into the previous work products of the requirements model. o Non-functional requirements can be made part of the use case model as these kinds of requirements are associated with use cases according to the use case template. General non-functional requirements that apply for the whole system Page 49 of 93

50 are associated with the system boundary which is also included in the use case model. BCE model: This work product provides the link between the Requirements model and the Architecture mode and is the output of a technique used to derive the system domain models (architecture model and platforms specific model) from the business domain models (the Business model and the Requirements model). 4.2 Use Case Model The Use Case Model consists of the System Boundary Model and the Use Case Scenario model System Boundary Model The System Boundary Model describes the system boundaries, the actors and their responsibilities, and the services offered by the system. Interactions between the system and its environment are identified and might also be detailed by modelling stimuli and responses using UML sequence diagrams Goals The System Boundary Model should: Identify and describe system boundaries, main services and actors. Assure a common understanding of the system and its purpose. Identify interactions between the system and its environment Methods and techniques The starting point for the development of the System Boundary Model is provided by the Business Model work products, the Context Statement, Vision for Change, Business Process and Role Model and Business Resource Model. Other important sources are the business stakeholders, who should be involved when determining the system boundary model. Defining the boundaries of the system means finding out what is inside the system and what is outside the system (the outside is what the system interfaces with). The boundaries of the system are determined by the roles of the system in the Business Model. In the System Boundary Model, the boundaries of the system are defined in terms of actors and use cases. The actors are outside the system and represent the roles in the Business Model that interact with the system roles (roles inside the system boundary); the use cases are inside and represent the behaviour of the system roles. Thus, UML actors are used to denote anything that interfaces with the system. Some examples are people, software, hardware devices, data stores or networks. In the model we let each UML actor define a particular role and thereby abstract the actual person or software system currently fulfilling the role. Hence, several actors may represent one physical person, because that person takes on different roles with regard to the system. On the other hand, one actor might represent several physical people, because they all take on the same role with regard to the system. Each role specifying interactions with the system may be represented by one or more actors (hence, roles are recursive). To help in defining actors the following questions might be helpful to elaborate: Who uses the system? Page 50 of 93

51 Who maintains the system? What other systems use this system? Who gets information from the system? Who provides information to the system? Does anything happen automatically at present time? Who starts up and shuts down the system? Each actor needs a descriptive name and a brief description that is one or two sentences long. This description should define the role represented by the actor with regard to the system. Identify use cases: When the main actors are identified, the next step is to go through the list of actors and identify use cases for each one. Use cases describe things that the actors want the system to do. At this stage, people that will play roles defined by the actors should be involved. To help identify use cases the following questions might be helpful to elaborate: What services are required from the system by the actor? Which events are/will be initiated by the actor, and which events are the actor interested in? Which events occur and who is/will be notified about them? When dealing with existing systems, go through the list of actors and identify what services the system actually provides. Important sources of information would then be the user manuals, other documentation, source code, table structures and information gathered by studying system behaviour at runtime. Relate to goals! The use cases should be related to goals, this because the purpose of the use cases should be to attain goals. It is important to be able to answer why to each use case. If you can't give a good answer to the "why-question", then it is probably not a proper use case. The relation to the goals is implicitly the answer to the why question. Describe stimuli and responses for the use cases identified. Each actor communicates with the system through a set of use cases in order to reach their goals. The stimuli/response describe the stimuli sent to the system by the actor, and the responses back from the system. We can use UML sequence diagrams to model the most important stimuli/responses Deliverables and notation The work product contains the following: UML Use Case diagram showing the system boundary, the actors and the actors responsibilities. UML Use Case diagram exploring the system boundary use case that identifies the needs. Each use case should be numbered for later reference General extra requirements that applies for the complete system are associated with the System Boundary Example Figure 2 shows an example of parts of a system boundary for a meeting room booking example, which is described in a UML use case diagram. The actors represent initiating system actors or external systems used by the meeting reservation system (e.g. the information system). Page 5 of 93

52 Meeting Reservation System Make Meeting Reservation <<include>> M eeting Organizer Change Meeting Reservation <<include>> <<include>> Send Meeting Information Information System Cancel Meeting Reservation <<include>> <<include>> Respond to Meeting Invitiation Change Meeting Response Meeting Attendee View Meeting Information Organisation Information System View Resource Calendar Login Figure 2: System Boundary Example Meeting Room Example Use Case Scenario Model The Use Case Scenario Model digs into the identified use cases and describes these in detail. The COMET method describes a use case template that is used as a vehicle for this detailing Goals The Use Case Scenario Model should Capture and describe all system services in detail Methods and techniques The major input to determining the Use Case Scenario model is System Boundary Model, but the Business Model work products and early versions of the Architecture Model are also valuable input. The use case template is the baseline for developing the Use Case Scenario Model. Each use case identified in the System Boundary Model is detailed using the use case template. The use case template consists of the following parts: Part Use case identification The UML use case diagram Goals Actors/Roles Description of scenarios (formal) Pre and post Description Use case no. xx <name>. Each use case are identified for later reference UML use case diagram for the actual use case. The diagram should include extend and include relationships if there is any. Description of the goal(s) for the use case, derived from the Goal Model in the Business Model. Preferred notation is prose text. Description of the roles involved in the use case and their responsibilities. Preferred notation is prose text. Description of the use case scenarios. This includes the primary scenario and related secondary scenarios. The scenarios are described using UML Activity diagram and/or UML sequence diagram. Description of the pre and post conditions for the use case. The post condition will often Page 52 of 93

53 conditions Non-functional requirements correspond to the goals. Preferred notation is prose text. UML state diagram might also be used to describe pre and post conditions as well as intermediate states of a use case. OCL might be also be used to specify pre and post conditions Description of non-functional requirements for this use case. These are described using text in the UML documentation field for the element in question. Table : Use case template The description part of the template describes scenarios. A scenario is an elaboration of a use case. Use cases are statements of system services. Scenarios add more detail and describe factors that may result in behavioural variations of a given use case. A Scenario describes the behaviour of the system in a particular situation. The use cases and the set of all scenarios together constitute the complete description of the services of a system. Scenarios are constructed by taking the use case and identifying possible different outcomes and different conditions that may result in different sets of scenarios. Non-functional requirements are the collection of system requirements that are not directly related to what the system should do. It is important that the derived use cases are proper use cases in the sense that they are meaningful from a business point of view and are not influenced by a specific system or a solution. For instance if you are designing a cashier machine, insert credit card and give your pin code are not proper use cases. Identify yourself is however, much better. In fact insert credit card and give your pin code is just one way of accomplishing the Identify yourself use case. Similarly use cases such as getname, getid, sortlist and insertcoin are not proper use cases. It is important that the use cases are carefully developed. They should not go into the details of a collaboration, but be related to the goal of the collaboration. Examples of proper use cases are: getpayment, registerparticipant and gethairdressed Deliverables and notation The use case scenario model will consist of a set of filled-in use case templates describing the identified use cases. The notation is according to the use case template described above Example The figures below show examples of use case detailing (Figure 22 and Figure 23) and an example of a scenario for a use case (Figure 24). Meeting Reservation System Meeting Organizer <<include>> Make Meeting Reservation <<include>> Check requirements Information System Send Meeting Information Organisation Information System Figure 22: Use Case detailing example Page 53 of 93

54 Meeting Reservation System Remove Resource Resource Administrator <<extend>> Handle Existing Reservation Conflicts <<include>> Information System Send Reservation Conflict Information Figure 23: Use Case detailing example Meeting Organizer: Meeting Reservation System: Describe reservation requirements Reservation requirements: Create meeting reservation suggestions Meeting schedule suggestions: Select and reserve suggestion Suggestion: Create reservation Reservation: Update reservation with invitation info Store reservation and send invitations Figure 24: Use Case scenario example 4.3 Prototype The Prototypes are part of the requirements model. Prototyping is very important to be able to reduce technical risks and to ensure end user involvement. Prototypes are commonly used to emphasise the UI, test critical use cases and test risky parts of the architecture. It is common to build some prototypes during the elaboration phase to try out some ideas or to determine if a high risk feature is possible. As a result of the prototyping effort, you may decide that a certain feature is not feasible and remove it from the project. If that feature is key to the project it might even be decided to abandon the project Goals The prototypes should seek to: Reduce technical risks Page 54 of 93

55 Reduce the possibility of getting end user dissatisfaction Methods and techniques Important input when determining the prototypes are the use case model, the architecture design and the risk analysis. What to include in the prototype and how to implement it is dependent of the purpose. If the main purpose is to emphasise the UI, choose the main use cases and design the UI. It is recommended to use tools that let you visually design a UI. It is easy and fast and to design UI's using such tools and you will often be able to reuse parts of the UI code in the real system. Implementing some UI event handling and some dummy data to simulate parts of the real system is often a good idea. This is also easily done with RAD tools. If the main purpose is to test the architecture or parts of the architecture, choose a use case or a set of use cases that emphasise the wanted parts. Implement what is needed to be able to test the architecture. Sometimes it is more convenient to make tests regardless of the use cases; however implementing use cases are preferred because it gives more valuable experiences. In addition parts of the work might be reused directly in the actual system. If the main purpose is to test some core use cases that comprise some risk. Implement those use cases, focusing on the risky parts. Note that during the construction phase a set of increments are developed. Following a risk driven approach, the first iterations and increments incorporate the most risky parts of the system. What to include in a prototype and what to be left for the first increments should be elaborated. It is not any straightforward answers to this, however seek to avoid letting the elaboration phase last to long. The elaboration phase should approximately be 20 to 25% of the total project. However, at the end of the elaboration phase it is vital to be able to answer if it is possible to develop the system within a reasonable cost and time frame Deliverables and notation Prototypes and related code are typical deliverables from this work product. They are documented in separate UML models. It has also been shown to be useful to start writing on the user manual at this stage, to better understand both the functional requirements and requirements regarding user-friendliness. 4.4 Non-functional requirements This work product describes non-functional requirements that do not fit into the use case template. For instance, some non-functional requirements may be general for the whole system to be developed. These are described separately instead of being described with every use case. The distribution aspect of the system as well as interoperation with legacy systems and different software and hardware components might also be better described separate from the use cases. See information on Quality specification in Modeling QoS: Towards a UML Profile Goals The Non-functional Requirements work product should describe non-functional requirements that do not fit into the use case template. Page 55 of 93

56 4.4.2 Methods and techniques This work product serves to be able to describe all remaining non-functional requirements, whatever they may be. A list of things to consider is as follows: Performance, uptime, availability, security, scalability, distribution, legacy interaction, use of any particular hardware and software components, usability, accuracy, robustness, expandability, change tolerance, maintainability, portability and reliability. To be able to identify the required distribution handling, it might be convenient to model the actual physical distribution. One possible technique for modelling distribution is to use UML packages representing distribution locations and locate things (resources, roles, processes/steps) in their respective location (i.e. defining a «distribution unit» package). Also external constraints, conditions, decisions, rules and so on that will have impact on the system development project, and thereby indirectly on the system to develop, are described in this work product. Examples are budget, available resources, time constraints, strategic decisions, use of standards, enterprise policy, enterprise culture, political situation etc Deliverables and notation Usually a document describing non-functional requirements is the deliverable from this work product. Free text along with convenient illustrations will mainly be used to describe these general non-functional requirements. UML may be used at convenience. 4.5 Reference Architecture Analysis The Reference architecture analysis is the first step in modelling the architecture, representing an intermediate step between Business Domain Models (Business Model and Requirements Model) and the architecture design. The key source for the analysis is the Use Case Model. Thus, The Reference Architecture Analysis is developed using a use case driven approach and provides the basis for the initial development of the Architecture Model Goal The Reference Architecture Analysis should provide the link between analysis and design, in particular the link between the Use Case Model and the Architecture Model Methods and techniques Recall the Reference Architecture with associated tiers and component types. The first step of this analysis, (typically executed as part of developing the first increment of the Architecture Model) you analyse the System Boundary part of the Use Case Model with regards to the Reference Architecture. The System Boundary corresponds to the boundaries of the component of concern for the actual project. E.g., in projects concerning building or replacing an Application Component the System Boundary represents the Application Component of concern, where the actors is what's outside the Application component and the Use Cases is what's provided by the application component.. After the identification of this "main" component the next step is to analyze the System Boundary Model with respect to its set of use cases and actors. The aim of this task is to divide the System Boundary Model into a set of subsystems. Each subsystem will cover a collection of the System Boundary use cases. Thus, a subsystem contains a subset of the use Page 56 of 93

57 cases of the System Boundary Model. Remark that the subsystems are non-exclusive, implying that a use case might be part of more than one subsystem. The result of this task is a functional decomposition of the main component. It is visualized using by group the use cases of the System Boundary use case diagram adding system boundaries representing the subsystems (example See figure below). Figure 25: Subsystem grouping example The actors/roles are important when it comes to obtaining the most appropriate decomposition as they group related use cases. Thus, the subsystem grouping are related to the actors/roles, and the subsystem design should strive to have as few relationships between actors and subsystems as possible. Related use cases and especially use cases that typically are executed in sequence should be provided by one subsystem. Recall that the subsystems might be overlapping when it comes to the use cases. In some cases you might have projects concerning a set of Application Components. In such cases the described technique are applied recursively having subsystems representing Application Components. Also subsystems might again be decomposed into subsystems) The subsystems are typically associated one to one with tool components as both seek to provide related end user functionality. A tool component is defined as functional part of the system, which enable end users to fulfil a task or a set of related tasks. When defining a set of reasonable tools a rule of thumb is typically to have tools providing the support required to fulfil the responsibility of a role or a set of roles. The end user prefers to have few tools, which are efficient and tailored to what they need to do in order to fulfil their responsibility. Thus, derive the tools based on the subsystem decomposition. Other inputs are the System Boundary Model and the corresponding use case scenarios as well as the WARM analysis. The ideal situation would probably be to have a tool dedicated for each Human Role of the System Boundary Model. However, the typical situation is that you will end up with tools supporting more than one role and also several tools supporting one role. The granularity of the actors/roles is an issue in this respect. Defining very fine granular roles it would typically Page 57 of 93

58 be impractical to have one tool supporting each role, however, this situation will typically lead to a situation where each role only interact with one tool. On the other hand defining course grained roles you will more often end up with several tools supporting one role. Thus, the role design is crucial and will have major impact on the system design. An important input to the subsystem design is also the knowledge of the typical usage patterns, as a standard requirement for every system is to deliver efficient services and support to the end users. To derive further components the subsequent step is to continue applying the Reference Architecture with associated tiers and component types on the Subsystem design and associated Use Case Scenarios. A scenario is typically initiated by an actor interacting with a tool. Analyse the scenario and identify the services required (Business Services /controllers) as well as the information objects required (Business Entities). The Resource Service components need to provide the required information objects. The information objects are identified by analysing the dataflow taking place in the use case scenario. Also the Business Resource Model might be used as input for identifying the entities. Having overlapping subsystems (one use case appear in several subsystems), the actual use case typically should appear as a service at the Business layer and be provided by one Business Service component. The control of flow as well as a convenient categorization of services is provided by the Business Services. Thus, analysing the scenarios is a main task when identifying Business Service components. Typically the Business Services provide more generic services than the Tool components. Also a Business Service are typically used by a set of tool components By applying the Reference Architecture Analysis you get the initial version of the Component Structure and it is derived using the Use Case Model and also the Business Model as input. This technique reduces the gap between the Business Domain model and the System Domain models and visualise the traces between the two domains Deliverables and notation First version of the Component Structure and Internal Design. It is recommended to derive two views, one using the bus architecture pattern (Object Management Architecture pattern) and the other a Component Structure without the Bus component. The latter will typically be evolved further by assigning interfaces, interface dependencies etc. Both should apply the COMBINE Component stereotypes. Page 58 of 93

59 5 Architecture Modelling 5. Introduction The Architecture Model describes the overall architecture of the system and its partitioning into components in terms of collaborations of components and subsystems, component structures, component interactions, and component interfaces and protocols. It describes two aspects of the component collaboration, namely the static (structure) and dynamic (behaviour). The structural model describes the components, their dependencies, and their interfaces; the dynamic model describes the component interactions and protocols. The result is to define components in terms of what interfaces they provide, what interfaces they use, and how these interfaces should be used (protocol). Figure 26 shows the models (work products) that may be part of an architecture model specification. Subsystem Subsystem 2 : Registrator : Secretariat : ClubRegister Application registerclub clubexists registerclub Arnor er en kul type Dette er et forsøk på å fylle denne kommenten med text Subsystem4 Subsystem3 Component structure model Component interaction model Interface model Information model Figure 26 Architecture model work products The component structure model describes the high-level components and their interdependencies. The component interaction model describes the interactions between the high-level components. The interface model describes the details of the component interfaces, i.e. their operations and detailed behaviour The information model describes the information structures that are conveyed through component interfaces. The information model may be included in the Interface Model if convenient. The following working method is recommended:. Begin with identifying coarse-grained components and their inter-dependencies. Express components and dependencies in UML class diagrams. (Component Structure Model) 2. Decompose composite components into sub-components. (Component Structure Model) 3. Investigate how components should interact. Produce UML sequence diagrams and detailed activity diagrams according to WARM. (Component Interaction Model) 4. Elaborate the interface(s) of each component. Express these in UML interface diagrams. In UML, an interface is assigned to a component by a realises relationship, i.e. the component realises a certain set of interfaces. (Interface Model) Page 59 of 93

60 5. Use results from 3 and 4 to enhance the Component Structure Model. 6. From the present results, elaborate models of the information passed through the component interfaces. (Interface Model) 7. Repeat from 2 until sufficient detail level is reached. That means, the work products shall be suitable as basis for programming, or as input to code generation tools. If sufficiently specified, the following work products are candidates for automatic code generation: the Component Interaction Model the Interface/information Model When completed, the Component Model should be arranged as a UML package, containing detailed information about the components, their dependencies, interactions, interfaces and information structures. Each component should be stereotyped according to the reference architecture described in Appendix C: Architecture Metamodel & UML Profile. A component needs to be specified. This is done using one or more of the models (work products) specified in the beginning of this chapter. However, it is important to differentiate between the public interface of a component and its internal design. This can be done by organising the models into two separate packages. Figure 27 shows an example of a Business Service, called BuiltUpAreaService. Notice that the package and the component have the same name. The BuiltUpAreaService package has two packages called ComponentInterface and ComponentDesign. The ComponentInterface package contains the component s interface and information models, and public interaction models. The ComponentDesign pacakge contains the component structure model and the internal interaction models of the component. It is not necessary that the packages should have the names specified here. However, in order to recognize which packages are part of the internal design and which packages which defines the public interfaces the following two stereotypes should be used on the package level. <<ComponentInterface>> for public interfaces and interaction models. <<ComponentDesign>> for internal structure and interaction models. 5.2 Component Structure Model 5.2. Goals Figure 27: Component interface and design packages The purpose of the Component Structure Model is to understand and describe the components that together build up the product, the dependencies between the components, the interfaces they offer, and their use/access of other components through their interfaces. The Component Structure Model should document: Page 60 of 93

61 The software (and hardware) architecture represented by the components that comprise the product. The purpose of a system architecture specification is to subdivide the system into comprehensible units that represent meaningful groupings with respect to some criteria; The dependencies between components, and the interfaces realised and required by them Methods and techniques Input is the identified information objects in the Business Model. The result is a model describing the components and the relationships between them. This is expressed in UML class diagrams. The component structure should be modelled through several iterations. The timing by which the modeller discovers and describes the details of component collaborations will vary depending on system familiarity. A modeller familiar with existing components and their functionality may prefer to start early with defining the interfaces for components, and describing the component interactions. For modellers less familiar with the system, or the system being a new one, it is natural to discover the interfaces and interactions through analysis of the use cases described for the system. A small-increment approach combining top-down and bottom-up work, is probably a good strategy for elaborating component structures. The 4+2 reference architecture and the set of predefined component types are used as baseline for the architecture modelling. Start with identifying the Application component(s) and associated tool components. A tool is defined as functional part of the system, which enable end users to fulfil a task or a set of related tasks. When defining a set of reasonable tools a rule of thumb is typically to have tools providing the support required to fulfil the responsibility of a role or a set of roles. The end user prefers to have few tools, which are efficient and tailored to what they need to do in order to fulfil their responsibility. Thus, derive the tools using the System Boundary Model and the corresponding use case analysis models. In many cases it is useful to have a tool dedicated for each Human Role of the System Boundary Model. However, sometimes you will have a tool supporting more than one role. The Reference Architecture Analysis describes this part in more detail. Continue with identifying Business Service and Resource Service components providing services and resources required by the tool components. The main input when developing this model is the results of the Reference Architecture Analysis and/or the Work Element Analysis. These techniques represent the first step of mapping the business/analysis models into architecture design. The Reference Architecture Analysis transforms the Use Case Model into actual components in the 4+2 tiers of the reference architecture. Work Elements in the Business Model can be mapped directly to give "first cut" Business Service and Application components. These tend to give business services that are enterprise-scope, and not constrained to specific needs a a particular Tool component. Typically the set of tool components are identified first, then the component structure in the remaining tiers are derived. However, since the focus of the reference architecture analysis mainly focus on functional requirements, account must be taken of the non-functional requirements in designing component structure of the system. The component structure should be modelled in several iterations. Do not attempt to describe the whole world in a giant leap. It is also important to keep the component structure descriptions at a relatively high level, i.e. do not get lost in too much detail the goal is to model the big picture. Page 6 of 93

62 There are many factors that might be considered when dividing into components. Below is a list of different strategies that might be used to support and constraint the process: Functionality and usage Technology. This includes for instance network, component infrastructure, reference architecture, distribution mechanisms, operating system, data storage frameworks and standards that should be followed. Organization. This might be how the development team is organized or how the end users are organized. Distribution. This includes distribution of people, equipment and systems; both at build time (development environment) and run time (end user environment). Use case actors. Grouping of functionality based on the actors of the use cases. Physical nodes. What nodes are available, and where are the locations. Parallel work. How to subdivide to maximize parallel work, this might be during in build time and/or run time. Non-functional requirements such as availability, performance, security, scalability etc. When developing the architecture model start off by identifying the biggest components. These are the main parts of the system under consideration. According to the set of component types, these are the Application components and then the embraced Tool, Business Service and Resource Service components. After the overall structure is derived through a couple of iterations it's time to dig into these large grained components and derive their internal design. The Tool components comprise UI components and a User Service component (in most cases its only one User Service component for one Tool component, but a Tool component might include more than one User Service component). A tool might also include "local" Resource Service components, as to have a local cache for global data as wells as for storing tool specific data as part of the tool component. Resource Service components at the client side (including data storage) is typically used for getting a self reliant client. Synchronization with the global Resource Service are then typically done regularly. The User Service component will provide the services derived from the set of use cases associated with this Tool. The internals of the UserService, BusinessService and ResourceService are derived. These are all leaf components according to the set of component types defined in COMBINE. These components are made up of classes and smaller grained not infrastructure aware "components". In COMBINE we differ between these larger grained infrastructure aware components that compose the overall architecture of the system and these smaller grained components used as to envelop the system and glue the system together. Examples of these kinds of components are UI components and Utilities. Utility components are components that package some reusable business algorithms like calculation of gain share. When driving the internal structure of components use architectural and design patterns to derive a good design in the same way as the reference architecture are used to structure the overall architecture. The BCE pattern separating the Boundary- Control and Entity parts of a component are recommended as a convenient architectural pattern to use for structuring the the internal design of the components. Page 62 of 93

63 5.2.3 Deliverables and notation The Component Structure Model contains one or more UML class diagrams describing component dependencies and interface. The notation used is stereotyped UML classes Example Figure 28 shows an example of a Component Structure Model. It consists of two components: A tool component BUATestClient, and a Business component BuiltUpAreaService. We can see from the model that the test client uses an interface called BUA which the business service exposes. The business servcie is also dependent of three other interfaces. BUATestClient BUA BuiltUpAreaService Basic_WFS Cluster Circumscribe Figure 28: Structural component model for the BUATestClient Interfaces are illustrates using the UML interface icon (lollipop). An interface is provided by a component (modelled as a UML class) and is used by other components (UML classes) 5.3 Component Interaction Model 5.3. Goals The Component Interaction Model focuses on the collaboration between components for the purpose of offering services. Components may join efforts: A component C may offer a certain service, but may be dependent of other components services to accomplish it. Such dependencies are detailed and documented in the Component Interaction Model. The WARM models are further refined into Workflow models. The workflow between the components needs to be described with respect to responsibility, delegation of work, transfer of control etc. The Workflow model will be input to automatic code generation Methods and techniques The protocols that are required for a component to be able to offer a service or fulfil its task will be implicitly modelled in the interaction specifications. The complete collaboration might also be regarded as a protocol, which shall be followed in order to succeed in offering Page 63 of 93

64 the service denoted by the use case. The complete protocol specification for a component is modelled in the Interface Model. Note that during the component interaction analysis and the component interaction modelling, also the required operations are identified. These operations are required in the sense that the components cannot fulfil their obligations without them Deliverables and notation The Component Structure Model provides important input to this model, and vice versa. Also, the Use Case Model (if present) may provide valuable input. Two expected flows of control need to be documented. On the one hand is the control flow in the traditional client-server environment. This is expressed in a UML sequence diagram and/or collaboration diagram. On the other hand is the more flexible control delegation that enables service chaining. This is expressed in a UML activity diagram enhanced with WARM concepts. UML sequence diagram / collaboration diagram: This diagram aids the modeller in identifying the components interfaces, which are to be further detailed in the Component Interface Model. UML activity diagram (Workflow model): This diagram does not expose interfaces, but provides a detailed view of the various steps to be executed. Human tasks, tool tasks and system services are included. This work product is supposed to be subject to automatic code generation Example: UML sequence diagram The example in Figure 29 depicts the high-level interactions between the components in a UML sequence diagram. The components are modelled as objects. :BuiltUpAreaService buildingservice:basic_wfs clusterservice:cluster circumscribeservice:circumscribe getfeature builingcollection cluster [foreach cluster]circumscribe Figure 29: Example UML sequence diagram in the Component Interaction Model Example: Workflow Model Figure 30 shows a detailed Workflow model of the steps and information necessary to generate a built-up Area. Page 64 of 93

65 bua:builtupareaservice area:box minarea:real ReceiveGenerateBUARequest FindBuildingService GetBuildingFeatures service:wfsservice buildings:featurecollection maxdistance:real clusters:featurecollection CreateBuiltUp Areas CreateBuildingClusters ForEachCluster [next cluster] CircumscribeCluster [area < minarea] [area >= minarea] ReturnBuiltUpAreas result:buacollection CreateBuiltUpArea Figure 30: Example Built-up Area Service internal Workflow model Figure 30 shows an activity diagram of the internal activities of the Built-up Area Service. It consists of the following steps. ReceiveGenerateBUARequest prepares the request and logs the usage. The FindBuildingService activity uses the input area to identify the appropriate WFS service by invoking a registry web service. The GetBuildingFeatures activity invokes a Web service call to the WFS enabled building service. The CreateBuildingClusters uses a service providing the Cluster interface to generate clusters of points. The CreateBuiltUpAreas is a composed activity which creates a polygon for each of the clusters found and a built-up Area feature for the polygons that matches the minimum Area requirement. The ReturnBuiltUpAreas activity returns the newly created built-up Areas and performs necessary logging of the performance of the service. Each of these tasks will require an operation in the domain object, which in this case is internal to the BuiltUpArea Business Service. Page 65 of 93

66 5.4 Component Interface Model 5.4. Goals The Component Interface Model (or interface model) describes the interfaces of each of the identified components. Together with details of how components collaborate (from the Component Interaction Model), the Component Interface Model describes the contracts for components. The interface specification model should capture and describe all system services in detail. This includes the interfaces with their operations and protocols. The details of the information passed through an interface are modelled as part of the Component Information Model Methods and techniques Input to the Component Interface Model is the identified information objects in the Business Process Model and the business resource model, the requirements Use Case Model, and the Component Structure Model. The stimuli/response (façade) description in the Use Case Model is of particular interest. The stimuli/response is typically the operation signatures of the client components. The component interface checklist gives guidance when developing the Component Interface Model. The interfaces are modelled in UML class diagrams. The interfaces are stereotyped as Interface. Operation signatures are modelled as class operations. The model is created and documented in accordance with the following checklist: (for each interface) Interface identification Purpose Operation signatures Scenarios (link) Pre and post conditions, if this is important to convey interface semantics. Non-functional requirements Protocols Description The name of the interface. This is part of the UML representation of the interface. (A common convention is to prefix interfaces with the letter I.) The purpose of this particular interface. What is the responsibility represented by this interface. (Identify which use case/requirement the interface is related to, if these are modelled.) This can be described in the UML documentation field for the interface. The signature of each operation (in a UML interface). See operation template below. Relation to component interaction diagram that describe the operation behaviour. Pre- and post-conditions can be described in the UML documentation field for the operation, either as prose text or in more formal OCL (Object Constraint Language) specifications. Description of non-functional requirements for each interface/operation. The protocol(s) defined for the interface. Table 2: Component interface checklist For every operation or attribute in the interface the following checklist should be used when describing the interface content. (for each operation) Name Signature Description Input parameters Description Fully scoped name of the operation or attribute. This in order to uniquely identify the operation or attribute. The name of the operation including the parameter list. A description of the purpose of the operation Description of the different input parameters for the Page 66 of 93

67 Output parameters Return value Preconditions Postconditions Exceptions Non-functional requirements operation. Description of the different output parameters in the parameter list for the operation. A description of the return value of the operation if applicable. Description of preconditions for this operation to function as intended. Preconditions can be described in plain text or preferably in OCL. Description of post conditions for this operation, i.e. what has changed in the system if the operation executes successfully. Post conditions can be described in plain text or preferably in OCL. What exceptions the operation may raise. Operation-specific non-functional requirements, if any. Table 3: Operation description checklist In addition, the interface model will be related to the Component Information Model, in that (some of) its parameters will occur as types/classes there. The Interface Model is modelled in terms of UML interfaces within UML class diagrams. The interfaces are related to the components implementing them and should be detailed by interface templates. This relationship is modelled as a realise relationship between the component and the interface. The information flowing through an interface in terms of parameters should be represented in the Component Information Model Deliverables and notation Documented UML class diagrams with the Interfaces that are related to the component/s realising them. As for the format of this deliverable a paper report is sufficient, but a more dynamic format such as hypertext is preferable. The documentation should be generated from the documented models. An example of such a format is the documentation generated by the JavaDoc program. Such tools exist also for other languages such as IDL Example The example in Figure 3 shows a combined interface and information model. Page 67 of 93

68 BUA +generatebua(in area:box,in minarea:real,in maxdistance:real):buacollection Box Real BUACollection 0.. featurem ember BuiltupArea Figure 3: Example Built-up Area interface and information model 5.5 Component information model The Component Information Model is presented as a set of UML class diagrams describing the information model for the associated component that is visible through the operations of each of the identified interfaces Goals The Component Information Model contains the definition of the information that is passed through the operations of each of the identified interfaces. The interface may be realised by one or more components Methods and techniques When a Requirements Model with a Use Case Model exists, this is a good starting point for identifying types in the Component Information Model. Actors/objects from the sequence diagrams are good candidates for being information types. Also, things passed and returned as input and result can be candidates for objects. Conceptually, it is useful to think of what is communicated (objects and values), who are communicating (components with interfaces), and how are they communicating (through operations). The Component Information Model should describe the structure of object types/classes that are part of an interface/feature. These object types are the types of the objects passed/received through the interface. Only non-basic types are described (i.e. types other than Integer, Boolean, etc.). These complex types (entity-types/data-types/features) are modelled using UML class diagrams with relevant operations, attributes and associations. To increase readability, it is often useful to incorporate the component interface in the diagrams describing its contents. The Component Information Model is a conceptual model representing the things accessible from an interface - it does not suggest any realisation of these. A rule of thumb for identifying the information types is to look for the nouns and subjects within the area of concern. Some common categories of these are: Page 68 of 93

69 Actors (that are represented in the system) Person Organisation Group System/subsystem Resources (that are communicated or used by the system) Information (e.g. a reservation) Products (of the system) The details of component interfaces in the Component Information Model often represent concepts, entities or services known in the business. The knowledge of domain experts will often be useful when describing this model. Given the Component Information Model, boundary conditions for each information object should be investigated. In addition, constraints specific to individual object types will be included in this model. To verify the correctness, content and completeness of an information model, it is useful to create instance diagrams. The modelling of instance diagrams often reveal the need for remodelling, correcting and/or further detailing of the information model. Especially, the need for constraining the information model. The constraints are specified using OCL (Object Constraining Language). OCL is part of UML standard. The class model contains the parts of the structure model that require specification of constraints on the state at specific points in time. The constraints in OCL should be accompanied by textual explanations describing the intentions of the formal OCL constraints in natural language Deliverables and notation The Component Information Model should contain a set of UML class diagrams representing the types/classes with attributes and relationships. The information detailed here represents information offered by component services of a product. Constraints are written in OCL. The Component Information Model should be platform independent, i.e. it should use the standard platform-independent data types and omit detailed technology details. The instance models show the usage of the Component Information Model Examples Figure 32 shows an information model extract of a structure of data type classes that represents metadata that is returned by a web map server. Page 69 of 93

70 <<DataTy pe>> MetadataBase <<Dat atype>> ExtendedMetadat abase <<Dat atype>> ServiceMetadata + onlineresource : OnlineResource + fees [0..] : String + accessconstraints [0..] : String <<DataType>> OnlineResource (from Web Service Basic Data) <<DataType>> Person + contactperson : String + contactorganization : String +contactinformation 0.. <<DataType>> Address <<Dat atype>> ContactInformation + addresstype : String +contactpersonprimary+ contactposition [0..] : String + address : String +contactaddress + contactvoicetelephone [0..] : String + city : String contacrfacsimiletelephone [0..] : String + contactelectronicmailaddress [0..} : String stateorprovince : String + postcode : String + country : String Figure 32: Example Component Information Model example (metadata) Figure 33 shows a structure of features that uses the ISO 907 geometry model. +cit ymember CityMember CityModel datecreated : Date Road classification : CharacterString number : CharacterString lineargeometry : GM_Curve speedlimit : SpeedLimit type : RoadType River centerlineof : GM_Curve Mountain elevation : Integer <<Enumeration>> SpeedLimit <<Enumeration>> RoadType F E R K S P G Figure 33: Example Component Information Model example (City and road) 5.6 PIM Data Types The COMBINE Component Centre has adopted the MDA concepts of Platform Independent Modelling (PIM) and Platform Specific Modelling (PSM). The Business Model, the Requirements Model and the Business Model are all Platform Independent. At least in the Architecture Model there is a need to include types in the models. This might be a need also Page 70 of 93

71 in the other PIM's for instance if you want to specify attributes in the Business Resource Model. To keep these PIM's platform independent also in this aspect the types used should also be independent of any specific platform or language. Thus, it is a need to define a set of platform independent types to be used. A possible way is of course to agree to use the type set defined for a specific platform or in a specific language (E.g. Java) and then specify mappings from these to the set of relevant platforms. Another choice is use OMG's IDL which is an ISO standard. (IDL is the CORBA types though). In the following this subject are discussed as go give an idea of what might be defined as a PIM datatype set for a domain, a productline or a product family, as well as what might be used What are the requirements for types? Prerequisite: UML is the preferred language for platform-independent modelling (PIMmodelling). Base types: There must be a small set of base types that represents the basic needs for identifying types for model properties. Constructed types: It must be possible to construct more complex data types from simple ones (base types). Platform independence: The types for PIM modelling should be independent of any target platform or language and not assume any specific representation for a type. Constraints on types: Constraints for types should be supported. Types as parameters what are their semantics? What is the problem Although the goal is to achieve technology independence (platform, language) when doing platform-independent modelling, a certain set of types must be chosen as basis for modelling. It is easy to choose the type system of an existing language, perhaps based on the assumed target implementation language. Types in existing languages subsume certain characteristic that is not ideal for supporting a platform-independent model. For example, they often define the range for a type, e.g. in ISO IDL (Interface Definition Language) that an integer has a 32- bit representation. We would like our type system to be de-coupled from any particular implementation of the type. ISO/IEC 0404 Language-independent datatypes defines a set of data types that are independent of any target implementation. These might be used as a basis for a type system for PIMs ISO 0404 Some definitions from ISO 0404:996 ( Datatype: a set of distinct values, characterized by properties of those values and by operations on those values. Datatype generator: an operation on datatypes, as objects distinct from their values, which generates new datatypes. Primitive datatype: an identifiable datatype that cannot be decomposed into other identifiable datatypes without loss of all semantics associated with the datatype. Parametric datatype: a datatype on which a datatype generator operates to produce a generated-datatype. Page 7 of 93

72 ISO 0404 distinguish between these kinds of data types: Primitive datatypes, subtypes and extended types, generated datatypes, aggregate datatypes, and defined datatypes. An overview of these types is given below, although not in full detail. Consult the ISO 0404 standard for a complete description of these types Primitive datatypes The following primitive datatypes are defined: Boolean: Boolean is the mathematical datatype associated with two-valued logic (true, false). State: State is a family of datatypes, each of which comprises a finite number of distinguished but unordered values (type switch = state (on, off);) Enumerated: Enumerated is a family of datatypes, each of which comprises a finite number of distinguished values having an intrinsic order. Character: Character is a family of datatypes whose value spaces are character-sets. Ordinal: Ordinal is the datatype of the ordinal numbers, as distinct from the quantifying numbers (datatype Integer). Ordinal is the infinite enumerated datatype. ( first, second, third, etc.) Date-and-time: Date-and-Time is a family of datatypes whose values are points in time to various common resolutions: year, month, day, hour, minute, second, and fractions thereof. Integer: Integer is the mathematical datatype comprising the exact integral values. Rational: Rational is the mathematical datatype comprising the "rational numbers". Scaled: Scaled is a family of datatypes whose value spaces are subsets of the rational value space, each individual datatype having a fixed denominator, but the scaled datatypes possess the concept of approximate value. Real: Real is a family of datatypes that are computational approximations to the mathematical datatype comprising the "real numbers". Specifically, each real datatype designates a collection of mathematical real values which are known to certain applications to some finite precision and must be distinguishable to at least that precision in those applications. Complex: Complex is a family of datatypes, each of which is a computational approximation to the mathematical datatype comprising the "complex numbers". Specifically, each complex datatype designates a collection of mathematical complex values which are known to certain applications to some finite precision and must be distinguishable to at least that precision in those applications. Void: Void is the datatype representing an object whose presence is syntactically or semantically required, but carries no information in a given instance Subtypes and extended types A subtype is a datatype derived from an existing datatype, designated the base datatype, by restricting the value space to a subset of that of the base datatype whilst maintaining all characterizing operations. Subtypes are created by a kind of datatype generator that is unusual in that its only function is to define the relationship between the value spaces of the base datatype and the subtype. Range creates a subtype of any ordered datatype by placing new upper and/or lower bounds on the value space. Select creates a subtype of any exact datatype by enumerating the values in the subtype value-space Page 72 of 93

73 Excluding creates a subtype of any exact datatype by enumerating the values which are to be excluded in constructing the subtype value-space. Size creates a subtype of any Sequence, Set, Bag or Table datatype by specifying bounds on the number of elements any value of the base datatype may contain. Explicit subtyping identifies a datatype as a subtype of the base datatype and defines the construction procedure for the subset value space in terms of LI datatypes or datatype generators. Extended creates a datatype whose value-space contains the value-space of the base datatype as a proper subset Generated datatypes A generated datatype is a datatype resulting from an application of a datatype generator. A datatype generator is a conceptual operation on one or more datatypes which yields a datatype. A datatype generator operates on datatypes to generate a datatype, rather than on values to generate a value. The datatypes on which a datatype generator operates are said to be its parametric or component datatypes. The generated datatype is semantically dependent on the parametric datatypes, but has its own characterizing operations. An important characteristic of all datatype generators is that the generator can be applied to many different parametric datatypes. The Pointer and Procedure generators generate datatypes whose values are atomic, while Choice and the generators of aggregate datatypes generate datatypes whose values admit of decomposition. A generated-type designates a generated datatype. The generated datatypes are Pointer, Choice, Procedure, and Aggregate. We will look at the aggregated data types here: Aggregate datatypes An aggregate datatype is a generated datatype each of whose values is, in principle, made up of values of the component datatypes. Record: Record generates a datatype, called a record datatype, whose values are heterogeneous aggregations of values of component datatypes, each aggregation having one value for each component datatype, keyed by a fixed "field-identifier". Set: Set generates a datatype, called a set datatype, whose value-space is the set of all subsets of the value space of the element datatype, with operations appropriate to the mathematical set. Bag: Bag generates a datatype, called a bag datatype, whose values are collections of instances of values from the element datatype. Multiple instances of the same value may occur in a given collection; and the ordering of the value instances is not significant. Sequence: Sequence generates a datatype, called a sequence datatype, whose values are ordered sequences of values from the element datatype. The ordering is imposed on the values and not intrinsic in the underlying datatype; the same value may occur more than once in a given sequence. Array: Array generates a datatype, called an array datatype, whose values are associations between the product space of one or more finite datatypes, designated the index datatypes, and the value space of the element datatype, such that every value in the product space of the index datatypes associates to exactly one value of the element datatype. Table: Table generates a datatype, called a table datatype, whose values are collections of values in the product space of one or more field datatypes, such that Page 73 of 93

74 each value in the product space represents an association among the values of its fields. Although the field datatypes may be infinite, any given value of a table datatype contains a finite number of associations Defined datatypes A defined datatype is a datatype defined by a type-declaration. It is denoted syntactically by a type-reference, with the following syntax: A type-declaration defines a new type-identifier to refer to a datatype or a datatype generator. A datatype declaration may be used to accomplish any of the following: to rename an existing datatype or name an existing datatype which has a complex syntax, or as the syntactic component of the definition of a new datatype, or as the syntactic component of the definition of a new datatype generator. Among the defined datatypes in 404 are Natural number, Bit, Character string, and more. Natural number:natural number is the datatype of the cardinal or natural numbers Bit: Bit is the datatype representing the finite field of two symbols designated "0", the additive identity, and "", the multiplicative identity Character string: Character string is a family of datatypes which represent strings of symbols from standard character-sets Applying types in PIM modelling The assumed language for PIM modelling is UML. How do we integrate the set of standard types into out UML modelling framework? The set of chosen base types can be used as types for UML attributes, parameters, and return values for operations. Which subset of types do we need? A subset (or all) the base types and some of the defined datatypes (e.g. character string). A subset of the subtypes/extended types (e.g. range) is relevant to include. A subset of the supported generated datatypes is relevant to include, e.g. the aggregate types (record, bag, set, sequence, array, table). How do we represent the different datatypes in UML? The simple base types can be used directly. Enumerates (enumerations) and state must be defined as UML datatypes. Named datatypes can be defined as UML datatypes. (How is their base defined?) Subtypes and extended types like range can be used directly as types in attribute/operation declarations or as part of a type definition. The aggregate datatypes Set, Bag, Array, Sequence, Table can be used directly as types in attribute/operation declarations or as part of a type definition. Page 74 of 93

75 6 Platform-specific modelling 6. Introduction As the name indicates this model defines the result of mapping the component model to an implementation on a particular infrastructure. Figure 34 illustrates the work products in the platform specific model. Applications Platform profile model Business components General components OS HW Component Implementation Model Figure 34: Platform specific work products The Platform-specific Model contains the following work products: The Platform Profile Model (explicit PSM), which specifies the system in alignment to the actual technology profile for the specific platform. The Component Implementation Model, which describes the implementation of the component specifications in a given programming language, and the deployment properties/configurations for the target computing platform (hardware, operating system, etc.) in which the system is to run. In addition two other work products may be developed: UMT Configuration Model (Implicit PSM in a code generator tool) The Deployment Model should describe the deployment properties/configurations for the target computing platform (hardware, operating system, etc.) in which the Product is to run. 6.2 Platform profile model 6.2. Goals The purpose of this model is to specify the system in alignment to the actual technology profile for the specific platform (e.g. based on the UML profile for EJB) Related model artefacts The Business Model and the Requirements Model, but especially the Architecture Model serves as input. Page 75 of 93

76 6.2.3 Methods and techniques A component environment might be any technology environment capable of realising a set of components, following the rules of conformity within that specific environment. This can be a distributed object environment (CORBA, COM, EJB), a messaging environment (JMS, MQSeries), etc. It includes a set of available infrastructure services (transaction support, security, naming, concurrency, and so on) on which the application component can depend in that environment. Some main issues when mapping to these kinds of target technology are (many of these aspects are controlled by the technology profile chosen): Technology type: A classification of a range of technologies based on a set of technology criteria. Examples are object-oriented programming languages (e.g. Java, Smalltalk, Delphi), function-oriented programming languages (e.g. Lisp), database types (relational, object-oriented, etc.), database access mechanisms (e.g. JDBC, ODBC, SQL), interaction types (see below), and more. Interaction type: A specialisation of technology type, covering aspects of interaction mechanisms, i.e. how one component interacts with another, i.e. a set of message types describing how a component interacts with other components. Message: Usually a short communication transmitted by words, signals, or other means from one person, station, or group to another. Here used for a message sent from one (software) component to a set of others. Message type: Type of message, a part of interaction type. Classifier for the types of messages that can be sent from a component to another. An example is a synchronous message. Communication mechanism: The mechanism by which a component sends a message to other components, e.g. Java RMI, socket, or RPC. Operation parameter type, kind (in/out/in-out/return) and reference restrictions Type system Error and exception handling mechanisms Interface inheritance and support restrictions Operation sequence Interface properties Object creation mechanisms Event handling Transaction handling Security and general QoS These aspects can be part of a platform specific profile like the EJB-profile. This profile defines how a platform specific model should be structured for an EJB environment. Ideally, the platform specific model should be fully generated by the modelling tool. In practise it will most often be partially generated, and possibly refined by the user Deliverables and notation The platform profile model consists of a set of UML models according to the chosen technology profile Examples Figure 35 depicts an example of a Platform Profile Model according to the EJB profile. Page 76 of 93

77 EJBObject <<EJBRemoteInterface>> ResourceManager EJBHome <<EJBSessionHomeInterface>> ResourceManagerHome <<EJBCreateMethod>> create() <<EJBRealizeHome>> <<EJBRemoteMethod>> deleteresource() <<EJBRemoteMethod>> findresourcesall() <<EJBRemoteMethod>> createresource() <<EJBRemoteMethod>> findresourcesbyname() <<EJBRemoteMethod>> findresourcesbytype() <<EJBRemoteMethod>> addschedule() <<EJBRemoteMethod>> isavailable() <<EJBRealizeRemote>> SessionBean context : SessionContext ejbactivate() ejbpassivate() ejbremove() setsessioncontext() getsessioncontext() ejbcreate() <<EJBImplementation>> ResourceManagerBean Figure 35: Example of a platform specific model for EJB 6.3 Component Implementation Model 6.3. Goals The purpose of this model is to deliver an implemented, compiled, and running Product according to the end users requirements. The Component Implementation Model describes the implementation of the component specifications in a given programming language, and the deployment properties/configurations for the target computing platform (hardware, operating system, etc.) in which the product is to run Related model artefacts This model takes the Platform Profile Model as input to the Component Implementation Model Methods and techniques This model takes the Platform Profile Model as input and refines it to an actual implementation in a programming language of choice. For certain component environments such as EJB, which is a language extension of Java, the programming language is given in advance. Other environments such as CORBA component model is language portable and can be implemented in many supported programming languages. Page 77 of 93

78 In refining the implementation, modelling tools should be used on the platform specific model to automatically generate a mapping to the component implementation model. The generated model may be used as the actual implementation, but in many cases the model needs to be refined further by experienced programming language developers. It is important that further refinements of the Component Implementation Model should be developed using a model-driven approach, meaning that the UML model should be regarded as the source, and must always reflect the latest version of the source code. Some existing tools on the market, e.g. TogetherSoft's "Together Control Center" (see already supports this approach. Ideally, new functionality/features should be introduced in the models and included by the implementation, either by code generation (if the tool supports it) or manually. This is called model driven development. This should be introduced in the platform independent model and propagated to other models as necessary. Of course, bottom up inclusion of features should also be allowed. New features must then be reflected in the models Deliverables and notation The Component Implementation Model consists of a set of UML diagrams and implementation code that describes: Programming language implementation: UML class diagrams that show the structure of the implementation in the chosen programming language, and implementation code that implements those models. Deployment model: UML deployment diagrams that show the structure of the deployment with accompanying property/configuration descriptions. 6.4 UMT Configuration Model 6.4. The platform-independent architecture model The baseline for the PSM mapping is the architecture model, which is an artefact produced during architecture modelling. It describes the product components, and their provided and required interfaces. The architeture model is not concerned with platform-specific details, such as communication protocols, realsation mechanisms etc. The figure below shows an example of a high-level architecture model, describing a set of components with provided and required interfaces. Page 78 of 93

79 Figure 36: Architecture Model Example We have identified two ways of specifying the platform-specific details of a product; an implicit and an explicit way. In COMBINE we use the implicit way supported by the UMT code generation tool. The explicit way defines refinements of the architecture models that are specific to the target platform, for instance by using a specific platform UML profile for modelling. An example of this is to apply the UML EJB profile and create an EJB architecture model in UML, which in turn is reflected in the implementation. The implicit way does not refine the architecture model to platform level using model refinements. Instead, we can tag model elements with target platform information, which is used by code generation tools to generate the platform architecture. The tagging can be done either in the modelling environment (the UML tool) using for example tagged values, or in the code generation tool platform properties Implicit PSM The implicit PSM is based using simple properties that identify the essential platform properties that enables components to be transformed to the correct target platform, given that a transformation tool (code generator) is familier with the set of platform patterns used. For example, we might introduce a property for a BusinessService component named 'EJB', which signifies to the code generator that this component shall be mapped to an EJB component. Another example is associating properties with a component's interface. One interface might for example be available as Web Service, EJB and Servlet. The Code Generator must know how to perform the mapping to these platforms. Page 79 of 93

80 6.4.3 Implicit PSM in a UML tool (PIM annotation) In a UML tool, Tagged Values (Extended Properties) can be used to attach platform information to the components and its interfaces, as shown in the figure below (the tagged values are visualised in notes.) Implicit PSM in UMT Figure 37: Tagged Architecture Model If the UML model is kept strictly independent of technology, without tags that indicate target platform, this information may be added within an external code generation tool, for example UMT. In UMT, properties may be associated with model elements. These properties can be platform parameters that control the output of a code generation process. The figure below shows UMT with platform-specific properties associated with the IBookingService interface of the Business Service Component. Page 80 of 93

81 Figure 38: Example UMT with platform properties The properties defined within UMT can be used by the code generator templates that process the model and generates the platform specific implementation code. Configuration in the UMT (or another code generation tool) to define the PSM mapping might be used in combination with an annotated UML model, where the annotation is done on the PIM model to attach platform specific information. This PSM information might then be utilized in the code generator tool to aim automatic configuration before executing the code generation Considerations In the context of the Component Centre a component environment is the most relevant target technology. A component environment might be any technology environment capable of realizing a set of components, following the rules of conformity within that specific environment. This can be a distributed object environment (J2EE, CORBA,.Net, EJB), a messaging environment (JMS, MQSeries), etc. Each technology environment includes a set of available infrastructure services (transaction support, security, naming, concurrency, and so on) on which the application component can depend in that environment. Some main issues when mapping to these kinds of target technology are: Technology type: A classification of a range of technologies based on a set of technology criteria. Examples are object-oriented programming languages (e.g. Java, Smalltalk, Delphi), function-oriented programming languages (e.g. Lisp), database types (relational, object-oriented, etc.), database access mechanisms (e.g. JDBC, ODBC, SQL), interaction types (see below), and more. Page 8 of 93

82 Interaction type: A specialisation of technology type, covering aspects of interaction mechanisms, i.e. how one component interacts with another, i.e. a set of message types describing how a component interacts with other components. Message: A usually short communication transmitted by words, signals, or other means from one person, station, or group to another. Here used for a message sent from one (software) component to a set of others. Message type: Type of message, a part of interaction type. Classifier for the types of messages that can be sent from a component to another. An example is a synchronous message. Communication mechanism: The mechanism by which a component sends a message to other components, e.g. Java RMI, socket, or RPC. Operation parameter type, kind (in/out/inout/return) and reference restrictions Type system Error and exception handling mechanisms Interface inheritance and support restrictions Operation sequence Interface properties Object creation mechanisms Event handling Transaction handling Security and general QoS 6.5 Deployment Model 6.5. Goal The Deployment Model should describe the deployment properties/configurations for the target computing platform (hardware, operating system, etc.) in which the Product is to run Methods and techniques To deploy a product there are typically some constraints that need to be taken into account. Typically there is already a hardware infrastructure in place (machinery, networks etc) as well as associated software infrastructure (OS, communication protocols etc). The possibilities to add or change the already existing infrastructure will vary. However, the product will typically also set some requirements to the execution environment, both when it comes to hardware and software. Thus, the infrastructure at hand will set constraints on how to deploy the product and the product will have a set of requirements to the infrastructure in which it will be deployed. The reference architecture will also constrain the deployment as it indicates the logical distribution of the set of components. Thus, when the infrastructure is in place, deploy the components of the product using the the Component Structure the reference architecture as guidance. Important aspect that should be described as part of the Deployment Model is: Distribution of the components Integration with other products and actors Page 82 of 93

83 6.5.3 Client and server Figure 39: Various splits between client and server. Figure 39 shows the Gartner Group's reference model for client/server systems which presents 5 different ways to split the client and server part (illustrated by the diagonal line), related to a separation of a system into three logical parts: Presentation, Application Logic and Data Management. The split depends typically on what kind of machinery and devices that will be used. In some situation this will vary and the system is required to dynamically adapt to the actual environment. E.g., the client device might be both a PC and a Palm or a mobile phone Deliverables and notation The Deployment Model consists of UML deployment diagrams that show the structure of the deployment with accompanying property/configuration descriptions. Page 83 of 93

84 7 Appendix A: Business Metamodel & UML Profile 7. Introduction The business modelling conceptual model and notation describes the concepts used to model a Component Centre product concentrating on its characteristics as they impact on the business it supports. Structuring Concepts Basic Business modelling concepts Work Analysis Refinement Profiling model 7.2 Structuring concepts Figure 40: Package dependencies Figure 4 shows the structuring concepts for the business model, which contains the different sub models for a business model. Business Model.. in context of Vision for change Scoping Statement 0.. context for Context Business Model Context statement Risk analysis Goal model Community model.. Business Process & Roles Model refined by refines.. Business Resource Model refines refined by Work analysis Refinement Figure 4: Top Level Model structure Page 84 of 93

85 7.3 Basic Business Modelling Concepts The business supported by a Component Centre product is described in terms of the goals of the business, the processes that are required to meet the goals, the roles in the business, and the resources, which, by fulfilling roles, perform those processes. A community structures groups of resources with common goal. Figure 42 depicts the business concepts and the structural relationship between them, and the following sections describe the concepts. Enabled by Artifact Resource.. Community.. resource in resource subject for.. artifact has resources Resource has.. constrained by Actor Resource Resource as Artefact represents objective of executes Resource in Role fulfils subgoals constrains modelled as.. artifact in Goal.. constrains Business Rule met by.. constrains.. actor for constrained by Role fulfilled by behaviour of.. constrained by.. performed by to meet.. identifier for.... identified by Business Process.. recipient.... sender.. results in issued to received by Business Message represented information flow result of Enabling behaviour.. constrains constrained by 0.. model of modelled as 0.. Step affected by.. generates concerns Figure 42: Basic Conceptual Model Behavioural Policy is generated by affects Event 7.3. Actor Resource An Actor Resource is a Resource that performs some behaviour in the model Artifact Resource An Artifact Resource is a Resource that is the subject of some behaviour It specialises the concept Resource Behavioural Policy A behaviour that is necessary to enable the achievement of at least one goal, that cannot, for whatever reason, including modelling purpose, be represented as a set of steps with a defined start point and end points. It specialises the concept Enabling behaviour Business Message A Business Message is the information or control flow, between 2 roles, that results from a step. Page 85 of 93

86 7.3.5 Business Process A Business Process is an enabling behaviour that is expressed a set of partially ordered steps. A process may itself be considered as a step in some higher order process. It specialises the concept Enabling behaviour Business Rule A business rule is a declarative constraint or extension to any instance of resource, role or business process, or combination of the three, that has business impact, expressed in natural language Community A Community is a collection of resources working together, in one or more processes, to achieve one or more goals Enabled by Enabled by is a relationship concept that categorises an association in a model between a goal (modelled as a UML class) and an Enabling Behaviour (also modelled as a class) in which the goal is enabled by the associated behaviour Enabling behaviour An Enabling behaviour is what is required to happen for one or more goals to be achieved Event An event represents something that happens in the environment of the business or component being modelled. An event may affect a set of processes and a process may generate events. An occurred event may also have effect on a defined business goal. It specialises the concept Step Goal A Goal is the purpose that a community has in executing a Business process Resource A resource represents a thing that fulfils a role in the business and can be either an actor for or an artifact in a step of a business process. There are many kinds of resource, e.g. different passive and active resource. One kind of active resource is a business actor, which typically is responsible for a business activity. Work products/ artifacts are examples of passive resources, which typically are input to and output from business steps Resource as Artefact A Resource as Artifact is a representation in the model of the aspects of a Resource that are the subject of a step in a process. Page 86 of 93

87 7.3.4 Resource in Role A Resource in Role is the behaviour of a resource when performing one or more steps in a process Role A role is a name for a behaviour, with a responsibility; represents the behaviour of a resource in performing one or more steps in a business process Step A step is something that happens or is done within a process that contributes toward the achievement of the goal of the process. The resource performing the step may itself be modelled as a community and the step may be considered as a process of that community and, as such, be decomposed into steps. 7.4 Work Analysis Refinement Concepts This section describes the additional business modelling concepts needed to complete a business model so that the IT components can be identified. This activity within business modelling is termed the Work Analysis Refinement Modelling (WARM). WARM refines instances of two basic business modelling concepts, Steps (Figure 43), and Actor Resource (Figure 44) Business Service A Business Service is a Resource with a role in the business, and represents an IT element that maps to a Business Service Component in the corresponding Architecture model. It specialises the concept Actor Resource Extended Step An Extended Step is a Step in which the intermediate states are of interest to the business, and may have to be remembered. This may be either because there are business reasons for such interest, or because other factors, including technology, require that the business be concerned. An extended step is a candidate for choreography by a Workflow. It specialises the concept Step. Page 87 of 93

88 Step Extended Step Immediate Step Human Step choreographed by.. Tool Step performed by.. performed by.. performed by.. performs.. choreographs 0.. performs.. performs.. Human (user) Workflow Human/ Tool Business Service Figure 43: WARM Concepts Step Actor Resource System Other system.. Human (user).. Product Human/ Tool.... Workflow Business Service Figure 44: WARM Concepts Actor Resource Page 88 of 93

89 7.4.3 Human (user) A Human (user) is an actor resource that represents a human that fulfils a role in the Business Process Model. It specialises the concept Actor Resource Human Step A Human Step is a step performed by a human with no involvement of the Product being modelled. It specialises the concept Step Human/ Tool A Human/ Tool is an actor resource with a role in the business that is fulfilled by human working with an IT element that maps to a Tool Component in the corresponding Architecture model It specialises the concept Actor Resource Immediate Step An Immediate Step is a Step that is required to complete as soon as possible, and whose intermediate states are of no concern to the business. It is performed autonomously, with no intervention from a human An Immediate Step may be mapped to an Operation on a Business Service Component (Process) in the Architecture Model. Each such operation on a Business Service Component in the Architecture will run in an ACID transaction, thereby either completing or leaving state as it was. The Name of the step is the verb or verb phrase that describes the process (for example, "Modify Customer record"). If a resource is specified as part of the name or description (for example "Modify Customer using Info from Sales Person") then the model should identify the relevant Resources. It specialises the concept Step Other system An Other System is an actor resource that represents an external automatic system that fulfils a role in the Business Process Model. It specialises the concept Actor Resource Product A Product is an actor resource that fulfils a role in the business and maps to the executable Product as defined in the CC Information model (q.v.). It specialises the concept Actor Resource System The System represents the complete IT facility that supports the business including all Products and the Infrastructure. Page 89 of 93

90 7.4.0 Tool Step A Tool Step is a step performed by a human user interacting with a tool that is part of the Product. The human user will use some form of interactive device (e.g. a GUI) to interact with the Product. A Tool Step is a candidate for realisation by a Tool Component. It specialises the concept Step Workflow A Workflow is an actor resource that maps to a Workflow Definition in a corresponding Architecture model which contains the business logic of a process and determines the sequencing of steps within any instance of that process. It specialises the concept Actor Resource UML profile The UML profile defines the stereotypes that Combine Component Centre will use for business modelling. These are derived from the conceptual models above. Figure 45 shows how business modelling (including work analysis) concepts are represented with UML.4 metaclasses. This diagram includes certain (meta-)associations, that are implicit in the UML metamodel, between BM concepts (as instances of UML metaclasses) and other UML metaclasses. These are shown to indicate refinements of such UML metaassociations that limit their use in a model. This association, which indicates that colaborations are only created for classes which are stereotyped as Business Process, is an example. UML::Package UML::Class UML::ClassifierRole represents context for UML::Collaboration.. Community Artifact Resource.. Business Process context for context for Behavioural Policy Goal UML::Actor UML::Comment UML::Message Role.. UML::ActivityGraph Human (user) Actor Resource Business Rule Other system Human/ Tool Business Service Business Message UML::Partition.. UML::SubActivityState UML::Association modelled as 0.. UML::ObjectFlowState Resource in Role Step Enabled by Resource as Artefact Extended Step Immediate Step Tool Step Human Step This diagram identifies the way the business modelling concepts are represented with UML.4 metaclasses Figure 45: Representing Business Modelling Concepts with UML Page 90 of 93

91 Figure 46 shows the stereotypes required and the business modelling concepts they represent. This diagram shows the stereotypes required and the business modelling concepts they represent. UML::Package Business Model Context statement Goal model UML::Comment Vision for change Community model Business Resource Model Risk analysis Business Process & Roles Model Community Business Rule UML::ClassifierRole UML::Message UML::Class UML::SubActivityState Role Business Message Goal Business Process Step UML::Partition UML::ObjectFlowState Artifact Resource Behavioural Policy Resource in Role Resource as Artefact UML::Actor Extended Step Immediate Step Human Step Tool Step Actor Resource Business Service Human/ Tool Human (user) Other system Figure 46: Stereotypes for Business Modelling 7.5 UML Mapping 7.5. Stereotypes The UML profile defines the stereotypes that Combine Component Centre will use for business modelling. These are derived from the meta-models above, al-though not all concepts are represented as stereotypes. Concept UML correspondence Icons (see associated folder Business Modelling Icons) Business Package None model <<BusinessModel>> Context Package None statement <<ContextStatement>> Vision for Package None Change <<VisionForChange>> Risk analysis Package None <<RiskAnalysis>> Goal model Package None <<GoalModel>> Community model Package <<CommunityModel>> None Page 9 of 93

92 Concept UML correspondence Icons (see associated folder Business Modelling Icons) Business resource model Package <<BusinessResourceModel>> None Business process & Roles model Community Goal Business process Behavioural policy Artifact Resource Actor Resource Product Business Service Human/ Tool Human (user) Other System Workflow Step Package <<BusinessProcessAndRoleModel>> Package <<Community>> Class <<Goal>> Class <<BusinessProcess>> Class <<BehaviouralPolicy>> Class <<ArtifactResource>> Actor <<ActorResource>> Actor <<Product>> Actor <<BusinessService>> Actor <<HumanTool>> Actor <<Human>> Actor <<OtherSystem>> Actor <<Workflow>> SubActivityState <<AtomicStep>> Extended Step SubActivityState <<ExtendedStep>> Immediate SubActivityState Step <<ImmediateStep>> Human Step Tool Step Resource in role SubActivityState <<HumanStep>> SubActivityState <<ToolStep>> Partition <<ResourceInRole>> None Large: combine_community.bmp Small: combine_communitysmall.bmp Explorer combine_communityexplorer.bmp Large: combine_goal.bmp Small: combine_goalsmall.bmp Explorer: combine_goalexplorer.bmp Large: combine_businessprocess.bmp Small: combine_businessprocessexplorer.bmp Explorer: combine_businessprocessexplorer.bmp as for Business Process Large: combine_resource.bmp Small: combine_resourcesmall.bmp Explorer: combine_resourceexplorer.bmp Large: combine_actorresource.bmp Small: combine_actorresourcesmall.bmp Explorer: combine_actorresourceexplorer.bmp Large: combine_businessservice.bmp Small: combine_businessservicesmall.bmp Explorer: combine_businessserviceexplorer.bmp Large: combine_businessservice.bmp Small: combine_businessservicesmall.bmp Explorer: combine_businessserviceexplorer.bmp Large: combine_humantool.bmp Small: combine_humantoolsmall.bmp Explorer: combine_humantoolexplorer.bmp As for Actor Resource As for Business Service Large: combine_workflow.bmp Small: combine_workflowsmall.bmp Explorer: combine_workflowexplorer.bmp Large: combine_businessstep.bmp Small: combine_businessstepsmall.bmp Explorer: combine_businessstepexplorer.bmp As for Step Large: combine_immediatestep.bmp Small: combine_immediatestepsmall.bmp Explorer: combine_immediatestepexplorer.bmp Large: combine_humanstep.bmp Small: combine_humanstepsmall.bmp Explorer: combine_humanstepexplorer.bmp Large: combine_toolstep.bmp Small: combine_toolstepsmall.bmp Explorer: combine_toolstepexplorer.bmp Large: None Small: ResourceAsRoleSmall.bmp Explorer: ResourceAsRoleExplorer.bmp Page 92 of 93

93 Concept UML correspondence Icons (see associated folder Business Modelling Icons) Resource as ObjectFlowState Large: None artefact <<ResourceAsArtefact>> Small: ResourceAsArtifactSmall.bmp Explorer: ResourceAsArtifactExplorer.bmp Role ClassifierRole None <<Role>> Business Message None Message <<BusinessMessage>> Enabled by Association <<EnabledBy>> None Business Rule Comment None <<BusinessRule>> Icons Figure 47 shows the principle icons used for business modelling. 7.6 Validation rules Figure 47: Principle Icons used in Business Modelling Name MetaClass Description Check Goal model Package Checks that each goal is achieved by at least one business process Check Community Package Checks that each business process achieves at least one goal Check Business Process AG ActivityGraph Checks that each step is under the responsibility of one role Page 93 of 93

94 7.7 Predefined views Name MetaClass Description Context Statement View Package Displays the main functions of a system and the main interacting actors Process and goal Package Displays the goals achieved by the business process structure Goal structure Package Displays the goal hierarchy Business process structure Package Displays the business process of a Community, related resources and roles 7.8 Transformation Rules TransformStep_to_UseCase: Creates a use case in a desired package from a business step defined in the business model. A traceability link is automatically generated between the step and the use case. o Right click on a business step(an ActionState stereotyped by <<Step>>) o Select the menu item "Business Module->Transform this step to a use case" o Select in the new GUI the package where the use case has to be generated TransformRole_to_Actor: Creates an actor in the desired package from a Resource_in_Role defined in the business model. A traceability link is automatically generated between the Resource_in_Role and the actor. o Same steps as the previous command(right click on a Partition) CreateBusinessModel: Create a default business model. Packages : Vision for change, Context statement, Risk analysis, etc. are automatically created. The command is launched by right-clicking on a Package then select "Business Module->Create a Business Model" Create Community from a Resource in Role: Create a community to detail the behaviour and structure of a Resource filling a particular role. We need to be able to click on a Partition (representing a Resource in Role), create a package stereotyped as «Community» with the default name: <name of Partition>, and within that Package, create a class, stereotyped as «BusinessProcess», for each «Step» in that partition. Set traceability links, represented community, from the Partition to the resultant «Community» Package. Create Community from a Step: Create a community to detail a Step in a Business Process. We need to be able to click on a SubActivityState (representing a Step in a Partition (representing a Resource in Role), create a package stereotyped as «Community» with the default name: <name of Partition> doing <name of SubActivityState>, and within that Package, create a class, stereotyped as «BusinessProcess», for the «Step». Set traceability links, represented community, from the Partition, and from the SubActivityState to the resultant Package. Page 94 of 93

95 8 Appendix B: Requirements Metamodel & UML Profile The Combine Component Centre has defined a profile supporting the user in structuring and documenting requirements. This profile is an extension of the business metamodel. The profile is provided as help for the user in structuring requirements and bridging the business model and the system architecture for the purpose of obtaining requirement documents. It includes a set of helper tools for the user to guide the definition of, and mapping between, goals, requirements, dictionary terms, and use cases. These tools are included in the modelling tool, which supports automatic generation of requirement documents based on the profile concepts. The main concepts defined in the profile are structuring concepts for Dictionary, Requirements, and Use Cases. The dictionary is used to identify the vocabulary for the domain. The requirements are used to capture system requirements that respond to goals from the business model. Use cases are used to formalise the requirements. Currently, the requirements metamodel is an informal tool that helps the user to structure a specification, and maintain traceability between business goals, requirements, and use cases. 8. Model Structure A requirements model is structured as shown in Figure 48. The contents of these models are described in the COMBINE methodology (WP3). Requirements Model System Vision 0.. sv sbm p System Boundary 0.. System Boundary Model use cases BCE Analysis Model 0.. bem ucs Use Case Scenarios Prototype Use case Analysis Scenario or 0.. scenarios Other Requirements Requirement Figure 48: Structuring Concepts Structure Page 95 of 93

96 The System Vision contains a high-level textual description, which captures the overall ideas of the product. The System Boundary model is a high-level use case model, which captures the roles and responsibilities of the system. The BCE (Boundary, Control, Entity) Analysis Model is a technique (and an artefact) that details use cases into more detailed analysis diagrams, represented by UML classes/interfaces. The Use Case scenarios describe the scenarios of each system use case, with text and UML interaction/sequence diagrams. Other requirements are described in terms of formal/informal text, each of these requirements are associated with one or more use cases. Other requirements that apply for the complete product are associated with the System Boundary Model. Prototypes are pieces of code, GUI sniplets etc. that tests and illustrates design principles and requirements. 8.. Examples Figure 49: Model Structure Example The left hand side of Figure 49 shows an example of the structure of a Requirements Model. The right hand side of Figure 49 shows the decomposition of the System Boundary Model into its subsystems with subsystem use cases and actors. 8.2 Use Case Extensions Figure 50 shows the requirements metamodel, which is an extension to the use case concept of UML. It relates a use case with interacting roles, scenarios that detail the use case, conditions for the use case, goals for the use case, and the requirements represented by the use case. Page 96 of 93

97 Requirement <<comment>> From BM concep tual model Goal Non-functional Requirement Functional Requirement.. met_by scoped_by specified_by Manage to_meet Use case Id : Use case identification p riority : Priority scopes sp ecifies interacted_with interacter Role <<comment>> From the BM conceptual model managed_resource usecase scenario constrained_with HumanRole SystemRole EventRole Resource ScenarioDescription Condition Use case identification Priority Pre Post Figure 50: Requirements metamodel Requirements metamodel concepts are defined as follows: Concept Extended properties Semantics UML mapping Icon (Large Small Role Human Role System Role Event Role A role is a name for a behaviour, with a responsibility. For more elaborate description see section Specifies that this role is played by a human Specifies that this role is played by a system Used to model initiator of Explorer) Actor - Actor <<HumanRole>> Actor <<SystemRole>> Actor <<EventRole>> events. E.g. a timer Use Case Use Case - id Use case identification Note <<id>> priority The priority of the use case Note <<priority>> Goal ScenarioDescription A goal is the purpose of the use case in the context of the business and the actual community A goal may be described in terms of a goal hierarchy, where the achievement of each goal can be described in terms of achievement of a set of child goals (sub-goals). For more elaborate description see section Description of the use case scenarios using UML sequence diagrams or UML activity diagram Condition There are two types of Note Class <<Goal>> Behaviour::Interactions - SystemIcon EventIcon Page 97 of 93

98 Resource Non-functional Requirement Manage 8.2. Examples conditions, preconditions and post conditions. They describe required states before and after use case execution A resource represents the things that fulfil roles in the business. For more elaborate description see section Description of non functional requirements. This is a type of use case that typically manages a Business Resource. E.g. in a meeting room example there might be a resource management use case performed by the Resource Manager role. The use case indicates handling the resources like room, equipment, participants etc. Will be transformed to CRUD operations in the AM. <<PreCondition>>, Note <<PostCondition>> Note <<NonFuncReq>> Use Case <<Manage>> SurveyBooking <<EventRole>> Rumour. Book tender/lead <<include>> 3. Ask for confirmation <<SystemRole>> Introspection 4. Confirm job <<include>> 5. Reschedule job <<HumanRole>> Sales 2. Update booking status <<extend>> 8. Automated schedule updates 9. Notification <<include>> 7. View schedule <<include>> 2. Subscribe to notification <<HumanRole>> Operation <<HumanRole>> Marine Management <<include>> 6. Update work-order (Import/Export) <<Manage>> 0. Manage users & rights <<Manage>>. Manage vessels <<HumanRole>> Admin Figure 5: Pilot Use Case Model SurveyBooking Figure 5 is an example of a use case model that uses the <<HumanRole>>, <<SystemRole>>, <<EventRole>> and <<Manage>> stereotypes. Page 98 of 93

99 8.3 Validation rules Name MetaClass Description Check Use Case Scenarios Package Checks that each use case (recursively within the called package) has a primary scenario description.. Check Actors Package Checks that each actor (recursively) has a dependency to a business actor/resource. Checks that each actor has a description. Check Model Structure Package Checks the first level package structure of a requirements model. 8.4 Predefined views Name MetaClass Description Actors View Package Displays the actors of the package (not recursively), their descriptions and traceability link (Use link to the corresponding business actor/resource). System View Package Displays the top-level actors and use cases belonging to the selected system. Subsystem View Package Displays the child use cases belonging to the subsystems of the selected package Examples <<description>> The sales department is responsible for costing a survey and to initially book it on a vessel or region in case of a lead. Sales account managers, sales supervisors and sales managers are members of this group. Sales Technical Support Marine Management Operation Management Introspection Administrator <<description>> A support role is needed to promote the input of competitor information. This role needs to access the system to obtain status on what is being added and by who. <<HumanRole>> Sales <<description>> Marine management will be responsible to confirm the booking of surveys onto a vessel. Regional marine management, business managers and global marine <<HumanRole>> Support management are part of this group. <<description>> Operations will be responsible for the survey preparation and execution. Operations managers, vessel supervisors and party chiefs are the main members <<HumanRole>> Marine Management of this group. In addition there are several service groups which will also be included in this group: Operational support (Technical services), personnel management, accounting. <<HumanRole>> Operation <<description>> Introspection has two tasks. For the booking and booking validation process it shall inform about vessel configurations, which it can get from the vessel descriptions. <<SystemRole>> Introspection In addition the actual progress is extracted from Introspection to keep the schedule up to date. <<description>> <<HumanRole>> Admin A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. Figure 52 shows an example of Actors View. Figure 52: Actors View Page 99 of 93

100 SurveyBooking <<EventRole>> Rumour. Book tender/lead <<include>> 3. Ask for confirmation <<SystemRole>> Introspection 4. Confirm job <<include>> 5. Reschedule job <<HumanRole>> Sales 2. Update booking status <<extend>> 8. Automated schedule updates <<include>> 9. Notification 7. View schedule <<include>> 2. Subscribe to notification <<HumanRole>> Operation <<HumanRole>> Marine Management <<include>> 6. Update work-order (Import/Export) <<Manage>> 0. Manage users & rights <<Manage>>. Manage vessels <<HumanRole>> Admin Figure 53 shows an example of System View. Figure 53: System View BookingEditor Book tender/lead Edit booking <<HumanRole>> Sales View local schedule Export/Import global schedule ScheduleViewer View global schedule GlobalScheduleService <<HumanRole>> Operation EventSubscription Event subscription Figure 54: Subsystem View Figure 54 shows an example of Subsystem View. Page 00 of 93

101 8.5 Transformation from requirements model to architecture model We see a possibility of transforming the requirements model to a first draft of the architecture model, for example by generating a UserService for each actor (which we see is quite common the case). However, the transformation is a one-way transformation from requirement model to architecture model. It will constrain the models unnecessarily, especially the requirement model, to maintain a round trip transformation between the requirements model and the architecture model. The following transformations are possible:. Map each actor to a UserService and create an Interface as a provided interface of the actor. For each of the use cases that the actor relates to add a corresponding operation to the Interface. Naming conventions: Use the Actor name to name the UserService and the same for the interface prefixed with an I. The operations should be named according to the use cases. 2. Map each <<Manage>> use case to a BusinessService providing CRUD operations as well as find and collection operations for the Resource(s) that are related to the <<Manage>> use case. Naming conventions: use the resource name prefixed with Manage Possible way to handle extends and includes relationships:. Include -> reuseable UserService with interface providing the include service or an operation in the interface of the extended UserService. 2. Extends-> Operation in the interface of the extended UserService 8.5. Transformation specification MOF have defined a metamodel for modeltransformations below we have specified the transformation rules for the Actor to UserService mapping based on this scheme. Figure 55 describes a simple transformation from a UML use case model to an architecture model with UserService components (classifiers) with interfaces. Actor <<source>> a Actor-2-UserServiceMap UserS ervice <<target>> us map2userservice map2interface <<target>> if Interface /feature Use Case <<source>> uc <<target>> op Operation map2operation Figure 55: Example from use case models to architecture Page 0 of 93

102 The transformation map Actor-2-UserServiceMap has one type of source object, an Actor. This signifies that the extent of actors in the source model is input for this transformation (one at a time). Source and target objects are modelled in terms of associations to types from the source and target metamodels, respectively. Source and target associations can be named, which signify named references to the source/target objects. A target association signifies the creation of one instance of the target type. From the example, the target UserService signifies a creation of a UserService object. The references to these objects have global scope and can be used in, for example, FeatureMaps in the specification. The classifier maps are either part of the transformation map or other classifier maps, defined through aggregate associations. An association defines a transformation path that implicitly (or explicitly, through OCL statements) carries source objects. When no constraint is specified, the sources of the owner become sources for the contained element (classifier map). Figure 56 depicts a detailing of the transformation, which includes simple feature maps. A feature map is modelled as an attribute and may contain assignments or action specifications. An assignment typically maps basic properties of the source, to basic properties of the target, e.g. their names. An action specification is a more complex operation that e.g. adds a realisation dependency to a target object. <<TransformationM ap>> Actor-2-UserS ervicemap <<ClassifierMap>> map2userservice us.name=a.name : FeatureM ap <<ClassifierMap>> map2interface if.name = 'I'+a.name : FeatureM ap Figure 56: Example feature map OCL constraints are used to constrain the input domain for a transformation class, based on the context of the owner. Typically, these define selection criteria for the set of objects to be handled by the receiving transformation class. OCL constraints are assigned to the associations between transformation classes. In the example in Figure 57, the OCL constraint on the association selects all use cases an actor communicates with. <<ClassifierMap>> map2interface if.name = 'I'+a.name : FeatureMap Use Case self.oppositeassociationends.forall (a a.participant.ocltypeof(usecase)) <<source>> uc <<ClassifierMap>> map2operation op.name = uc.name : FeatureMap <<target>> op Operation Figure 57: Example OCL constraints Page 02 of 93

103 In addition to transforming simple properties within FeatureMaps, more complex operations are needed to transform relational features, like adding an operation to an interface. Two different methods are used to support this. The first one is implicitly performed, by adding properties by referring relations from the metamodel, as in Figure 58. <<target>> if Interface map2interface <<target>> op /feature Operation map2operation Figure 58: Referring to metamodel relations The second way is to specify feature maps that add a relationship to the target object, as shown in Figure 59. UserS ervice <<target>> us map2userservice us.name=a.name : FeatureMap us.clientdependency.add (Realization (if)) : FeatureMap Figure 59: Adding properties in a FeatureMap The feature map accesses the properties of the target object and imposes an addition of a feature, e.g. a new realisation, as in the example. The add operation is assumed to be handled by the target object. Page 03 of 93

104 9 Appendix C: Architecture Metamodel & UML Profile This UML profile defines the stereotypes that COMBINE Component Centre will use for modelling the system architecture, which includes the components, their interfaces and relationships as well as their properties. The UML 2.0 standardisation process and the OMG EDOC standard provide the input for this version of COMBINE Component architecture meta-model and notation. The COMBINE project wants to establish the basis for architecture modelling in terms of the generally available elements within UML.4 and UML 2.0 with input from UML for EDOC. This basis is extended to support the COMBINE architecture modelling requirements using UML standard extension mechanisms (stereotypes, tagged values and the object constraint language). The COMBINE extensions are delivered as a set of profiles. 9. The COMBINE 4+2 Tier Reference Architecture The basis of the Combine component architecture is a generic system architecture, or reference architecture. The reference architecture defines a set of logical tiers, each of which consists of a set of components (Figure 60). Workflow Service Domain User Service Domain Business Service Domain User Interface Tier User Service Tier User Resource Service Tier Business Service Tier Resource Service Tier RA Presentation Tier User Dialog Tier LA LS RA Component Infrastructure & Workflow Engine (Microworkflow) Legacy Key LA LS Component Local Adapter Local Storage RA Resource Adapter Database Inter-component communication Figure 60: The 4+2 tier architecture The 4+2 tier reference architecture is separated into a local single user-space, called the user service domain, and a shared transactional business-space called the business service domain. As Figure 60 indicates, the user service domain consists potentially of four local tiers and the business service domain consists of two shared tiers. The 4+2 tiers are as follows: The user interface tier provides presentation and user dialog logic. Sometimes, it is useful to make the presentation and user dialog separation explicitly, in particular to support reuse of user dialog on multiple platforms with different graphical capabilities, e.g. Web, PDA and Mobile phones. The user service tier provides the user s model, which may include user session logic and user-side representations of processes and information. It is an abstraction for a set of business services, making the business service provision (and the communication mechanisms) transparent to the user interface tier. The user resource service tier provides local persistence services. It is only present if persistence capabilities are required by components in the user service tier, e.g. to Page 04 of 93

105 support disconnected or off-line operations, or to provide smart caching mechanisms. Access to the local storage is provided by local adapters, which typically are APIs to file storage or light-weight single-user databases. The business service tier provides components that represent business functionality and pervasive functionality (vertical vs. horizontal services). This tier provides enterprise-level services, and is responsible for protecting the integrity of enterprise resources at the business logic level. Components in this tier can be process-oriented, entity-oriented or workflow-oriented. For performance reasons, entity-oriented components are typically not exposed outside of this tier. The resource service tier provides global persistence services, typically in the form of databases. Resource adapters (e.g. JDBC or ODBC drivers) provide access, search and update services to databases and its data stored in a database management system (DBMS) like Oracle or Sybase. 9.2 Component Types The figure below shows the component types of the architecture. ComponentPart Component.. Composite Component Tier Component Workflow Component Tool Component User Interface Component Application Component User Service Component User Resource Service Component Business Service Component Resource Service Component Figure 6: Component types We have two abstract component types, tier components and composite components Tier Components The tier components are the smallest building blocks components that reside in their corresponding distribution tier. Page 05 of 93

106 Tier Component User Service Domain 0.. User Interface Tier 0.. User Service Tier 0.. User Resource Service Tier 0.. uiparts usparts urspart User Interface Component User Service Component User Resource Service Component Business Service Domain Business Service Tier Resource Service Tier bsparts rsparts Business Service Component Resource Service Component Figure 62: Component distribution Tier components interact with each other according to the figure below. User Interface Component <<comment>> Recommended to have a one-tomany relationship, thus a single business service incapsulates and hides its own data schema according to good OO design. /access /event /access /event /access /access /event User Resource Service Component 0.. User Service Component /event /access /event Business Service Component /access /event Resource Service Component Figure 63: Component Interaction The tier components are defined as follows: Concept Extended properties Semantics UML mapping Icon (Large Small Explorer) User Interface Specification User interface specification. Package <<UserInterface- Explorer: User Interface Component User interface components reside in the user interface tier and provide presentation and/or user Specification>> Class <<User- Interface>> Large: Page 06 of 93

107 User Service Specification User Service Component User Resource Service Specification User Resource Service Component dialog logic. In the current version of the meta-model we do not focus on the separation of presentation and user dialog in the user interface tier. Thus the term user interface components are used both places. A User Interface Component is any component used by a tool to provide interactive services for an end user. A User Interface Components accesses User Service Components to provide the necessary business functionality for the end user. User service specification. User service components reside in the user service tier and provide user-specific abstractions of a set of business services. User service compo-nent can be either processoriented or entity-oriented. A User Service Component provides an abstraction from the business service tier. It provides middleware transparency for the client-side. This decreases complexity for client developers. A User Service Component packages a service and a set of entities. The service represents the functionality available to a client. The entities represent the information abstractions available through the service. The entity within a user service is a local, session-specific representation of business entity concepts. The entities packaged by a user service component are denoted user entities. A user service may subscribe to events from the business service tier. User resource service specification. User resource service compo-nents reside in the user resource service tier and provide local persistence services. A User Resource Component provides resource (typically data) services to a given User Service Component. Package <<UserService- Specification>> Class <<User- Service>> Package <<User- Resource- Service- Specification>> Class <<User- Resource- Service>> Small: Explorer: Explorer: Large: Small: Explorer: Explorer: Large: Small: Explorer: Business Service Specification Business service specification. Package <<Business- Service- Specification>> Explorer: Page 07 of 93

108 Business Service Component Resource Service Specification Resource Service Component is transactional network addressable Business service components reside in the business service tier and provide implementation of a (set of) business services. Business service component can be either process-oriented or entity-oriented. A Business Service Component provides business functionality for User Service Components and thus implements business logic. A Business Service Component has transactional responsibility and has ownership of the information available through that service. Information is represented by entities (business entities). A business service can provide and subscribe events. It provides access to a set of entities. A business service component encapsulates the management of the entities it owns, but may also provide access to entities managed by other business service components. A business service component may be dedicated to management of a single (or more) entities. Typically, this is a good design if an entity needs to be accessed by many business service components. Resource service specification. Resource service components reside in the resource service tier and provide data storage capabilities. A Resource Service Component provides access to underlying resource providers, e.g. a data store. It provides the necessary interfaces to store, retrieve, and query information from a resource provider. These may also be described, if it seems necessary to explicitly capture specifics of persistent resource storage design, e.g. because the logical business entity model differs greatly from the data storage design. Class <<Business- Service>> Tagged value {is transactional} Tagged value {network addressable} Package <<Resource- Service>> Class <<Resource- Service>> Large: Small: Explorer: Explorer: Large: Small: Explorer: Page 08 of 93

109 9.2.2 Composite Components The composite components are made up of a set of tier components. applparts Application Component toolparts tparts Tool Component uiparts bsparts User Interface Component Business Service Component usparts rsparts User Service Component ursparts User Resource Service Component 0.. Resource Service Component Figure 64: Component compositions Tool Component Application Specification The composite components are defined as follows: Concept Extended properties Semantics UML mapping Icon (Large Small Explorer) Tool Specification Tool specification. Package <<Tool- Explorer: User- InterfacePart User- ServicePart Tool component represents a logical client-side component, consisting of user interface, user service, and user resource service components. A Tool Component is a composition or usage of a set of user interface and user service components. A tool component implicitly accesses a set of business service components via its user service components. A tool component represents functionality that supports a particular business role in a set of use cases; as such, it is closely linked to the business and the business specification. Application specification. Specification>> Class <<Tool>> Dependency <<uses>> on UserInterface Dependency <<uses>> on UserService Package <<Application- Specification>> Large: Small: Explorer: Explorer: Application Application component is a Class Large: Page 09 of 93

110 Component ToolPart Business- ServicePart Resource- ServicePart business level component, which provides end-user functionality within a business do-main. An application aggregates sets of tool, business service, interworking work-flow and resource service components. An Application component is a compound component providing business services to business users. These are providing using a combination of tool components, business service components, and resource service components. Business service components and resource service components are accessed implicitly through a tool's usages. An application component logically contains the tool components, business service components, and resource service components <<Application>> Dependency <<uses>> on Tool Dependency <<uses>> on BusinessService Dependency <<uses>> on ResourceService Small: Explorer: Workflow Components Workflow components (as used here) are application-specific (contains business workflow definition) and resides in the in the workflow service domain. The workflow service domain is orthogonal to the user service and business service domains. Figure 65 shows how workflow components relate to architectural concepts. User Interface Component <<comment>> Recommended to have a one-tomany relationship, thus a single business service incapsulates and hides its own data schema according to good OO design. /access /event /access /event /access User Resource Service Component /access /event 0.. User Service Component /event /access /event /workflowaccess Workflow Component Business Service Component /workflowaccess /access /event Resource Service Component /workflowaccess Figure 65: Workflow interactions Page 0 of 93

111 The workflow components are defined as follows: Concept Workflow Definition Extended properties workflow monitoring workflow history workflow synchronisation 9.3 Type Libraries Semantics UML mapping Icon (Large Small Explorer) Workflow definition specifies the Class business-oriented workflow that is <<Workflowinterpreted and executed by the Definition>> workflow engine (the microworkflow components). A Workflow Component is the specification of a workflow that is executed or interpreted by a Workflow Engine. The specification may be source code (compiled before execution) or script that is interpreted at run-time. Tagged value {workflow monitoring} Tagged value {workflow history} Tagged value {workflow synchronization} Type libraries define various data types and primitive classes that are used in the architecture extending the simple, primitive types supported by UML such as string, float, integer, etc. By modelling type libraries, we enforce a single source platform-independent type system that can be mapped to various specific technology or programming language libraries. Concept Type Library 9.3. Examples Extended properties Semantics UML mapping Icon (Large Small Explorer) Type libraries define various Package - datatypes and primitive classes that <<TypeLibrary>> are used in the architecture extending the simple, primitive types supported by UML such as string, float, integer, etc. <<TypeLibrary>> BaseDataTypes Calendar Dictionary Date Hashtable Properties Figure 66: Type Library Example Figure 66 shows an example of a simple Type Library that defines primitive base data types. Page of 93

112 9.4 Other Stereotypes Other stereotypes: Concept publishes subscribes oneway requestresponse notification Operation <<requestresponse>> solicitresponse Extended properties Semantics UML mapping Icon (Large Small Explorer) Dependency - <<publishes>> from a business service component to an event or message Dependency - <<subscribes>> from a business service component to an event Operation that indicates directed, Operation - oneway request with no return <<one-way>> values. Operation that indicates directed request with return value. Operation that indicates oneway notification of event, where a client is notified of an event. Implies a receiving notification/listener interface on the client side. Operation that indicates a two-way notfication with response, where a client is notified of an event and can respond to that event. Implied a receiving notification/listener interface on the client side. Operation <<notification>> Operation <<solicitresponse>> Validation rules Validation rules are composed of a set of metrics (m), which qualifies the model, and absolute constraints (c), which can invalidate the system if the model does not meet the criteria. Name MetaClass Description Check User Interface Specification Package A UserInterface can only access UserService or an interface thereof. Check User Service Specification Package A UserService can only access BusinessService or an interface thereof. Check Business Service Specification Package A BusinessService can only access other BusinessService components and ResourceService component or an interface Check Component Structure Package thereof. Checks that the component is modelled according to the component model management structure. 9.6 Predefined views Name MetaClass Description Component Interface View (detailed & non-detailed) Package Displays the interfaces of the selected component specification package. Interface Information View interface Displays the information model of the selected interface class (return values, parameters, ) Page 2 of 93

113 Collaboration Specification View Component Dependencies View Component Specification View 9.6. Examples Package Package Package Displays the collaborations and dependencies between the subcomponents of the component package. Displays the external dependencies of the selected component specification. Displays all visible properties (interfaces, return values, ) of the selected component specification. IOrgUnitRelation +getorgunits(): [] OrgUnit +getorgunits(in atype:string): [] OrgUnit +getorgunit(in atype:string,in aname:string):orgunit +getorgunittypes(): [] string +getorgunitnames(in atype:string): [] string IActivityInfo +WRITE : integer= +READ : integer=2 +NAME : string=name +TYPE : string=type +PARENT : string=parent +CLASSNAME : string=classname +DAILYREPORT : string=dailyreport +RELATION : string=relation +REPORT : string=report +PARAMETER_SET : string=parameterset +ACTIVITY : string=activity +PROJECT : string=project +SUBPROJECT : string=subproject +ORGUNIT : string=orgunit +ROOT : string=root +addorgunit(in anorgunit:orgunit):boolean +removeorgunit(in atype:string,in aname:string):boolean +addreportactivity(in anorgunit:orgunit,in anactivity:activity):boolean +removereportactivity(in anorgunit:orgunit,in anactivity:activity):boolean +createorgunit(in atype:string,in aname:string):orgunit +createreport(in atype:string,in aname:string):report +createactivity(in atype:string,in aname:string):activity +createproject(in atype:string,in aname:string):project +createparameterset(in atype:string,in aname:string):orgunit +begintransaction(in transtype:integer):boolean +committransaction():boolean +aborttransaction() +activetransaction():boolean ActivityInfo Figure 67: Detailed Interface View Figure 67 shows a detailed view of the provided interfaces. Page 3 of 93

114 <<Entity>> ActivityObject modified : boolean starttime : undefined endtime : undefined <<PrimaryKeyField>> name : string equals() parameters <<Entity>> ParameterS et subparametersets parent activity <<Entity>> Activity category : string orgunits group : string orgunits <<Entity>> OrgUnit type : string name : string parent suborgunits orgunits <<Entity>> Project parent subprojects reports <<Entity>> Report activities reports comment : string description : string duration : real production : string getproject() subactivities parent <<interface>> IActivityInfo WRITE : integer READ : integer NAME : string TYPE : string PARENT : string CLASSNAME : string DAILYREPORT : string RELATION : string REPORT : string PARAMETER_SET : string ACTIVITY : string PROJECT : string SUBPROJECT : string ORGUNIT : string ROOT : string createorgunit() createreport() createactivity() createproject() createparameterset() addorgunit() removeorgunit() addreportactivity() removereportactivity() begintransaction() committransaction() aborttransaction() activetransaction() Figure 68: Interface Information Example Figure 68 shows the information elements exposed by an interface. Page 4 of 93

115 BookingEditor BookingViewer ActivityViewer IBookingServiceUsage IBookingService <<requires>> BookingService IActivityInfo ActivityInfo <<requires>> IActivityInfoUsage IActivityInfoDatabase ActivityInfoDatabase Figure 69: Component Collaboration View Example Figure 69 shows an example of Component Collaboration View. Page 5 of 93

116 0 Appendix D: Platform Specific Metamodel & UML Profile The platform-specific metamodel defines a representation of system architecture on specific technology platforms. There is not a given single metamodel for platform specific architectures, but rather different ones for different technologies and technology reference architectures. An example of a platform specific metamodel is the EJB metamodel. The Java Community Process has defined a UML profile for EJB in JSR 26. Java Community Process, UML profile for EJB, JSR 26, This defines a way of representing EJB architectures in terms of UML. In COMBINE, this profile is not appropriate, since we need additional concepts in our target architecture. (One of) the platform-specific metamodels in COMBINE, uses servlets and EJB 2.0 concepts. This is not covered by the JSR 26. In addition, our modelling approach does not require that platform-specific models are explicitly modelled in UML. Instead, an implicit mapping can be done from the platformindependent model. 0. COMBINE Platform Specific metamodel: Servlet and EJB The COMBINE platform specific model is combining EJB. and 2.0 technologies with Servlet technology for communication between client and server. Figure 70 gives an overview of the conceptual PSM model. Page 6 of 93

117 JavaClass ServletClient <<description>> All concrete classes inherits from JavaClass. Interfaces inherit from Java Interface. HttpS ervlet ServletTunnellingClient ServletTunnellingServer Tool ServletProxy invokes IServerInterface ServletStub proxies IClientInterface EJBClient invokes BusinessServiceImpl javax.ejb.ejbobject BusinessServiceRemote realizes Business Service Component javax.ejb.ejbhome BusinessServiceHome javax.ejb.sessionbean access_entities EJBLocalHome EJBEntityBean Figure 70: COMBINE PSM A client tool will use a Servlet communication proxy, which is generated from a model by the code generation tool. The communication on the client-side is further hidden from the client by the UserService component (from the logical architecture), which is the interface the client sees. The servlets client uses http tunnelling to communicate with a servlet server, which delegates business service requests to a business service implementation. A server (a BusinessServiceImpl) is a realisation of a Business Service Component. It is an EJB SessionBean. The entities of that are part of a component are realised by entity beans with EJB LocalInterfaces. They can be managed as components in the EJB container, whilst only value types (value copies of the entity beans) are returned to the client. 0.2 Example An example of this mapping can be seen in the code of the WesternGeco pilot case, the SurveyBooking case. Page 7 of 93

118 Appendix E: WesternGeco Business Model Example This document describes the business context for the Survey Booking application that is going to be developed. The aim of this document is to describe how and where this application fits in the business operation for WesternGeco. The business context of a software system under consideration is described using a formal model, called the business model. This document presents two business models, which have been developed according to the COMBINE methodology. The Survey Booking is going to support the Tender Bid business context within WesternGeco.. Scoping Statements.. Context Statement Beginning 2000 it was decided to phase out and replace the suite of business support tools used in the Tender bidding process in the Marine Acquisition Business segment. These tools were based on Excel technology and did not support the needs in a distributed 7by24 organization. Also after 0 years of evolution, pushing spreadsheet functionality beyond its limits, these tools were hard to maintain. The decision was to reengineer this tool-suite based on the Introspection business tool platform, which was based on Web and Java technology. The first priority was to look at The Survey Booking Tool and The Survey Costing Tool. The Survey Booking tool will help to administer the utilization of the seismic vessels and will be used to book a survey or tender onto a vessel. It will give an overview over the current workload and also which vessel qualifies for the job. The Survey Costing tool is used to calculate the cost and revenue of a potent ional survey. The focus in this document will be on the Survey Booking tool. Figure 7 shows the stakeholders involved in the Tender Bid process and what they want to get from the Survey Booking Tool. Page 8 of 93

119 <<description>> The sales department is responsible for costing a survey and to initially book it on a vessel or region in case of a lead. Sales account managers, sales supervisors and sales managers are members of this group. Introspection <<description>> Introspection has two tasks. For the booking and booking validation process it shall inform about vessel configurations, which it can get from the vessel descriptions. In addition the actual progress is extracted from Introspection to keep the schedule up to date. Maritime Manager AccountManager SurveyBooking Operations <<description>> Operations will be responsible for the survey preparation and execution. Operations managers, vessel supervisors and party chiefs are the main members of this group. In addition there are several service groups which will also be included in this group: Operational support (Technical services), personnel management, accounting. <<description>> Marine management will be responsible to confirm the booking of surveys onto a vessel. Regional marine management, business managers and global marine management are part of this group. Support Administrator <<description>> A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. <<description>> A support role is needed to promote the input of competitor information. This role needs to access the system to obtain status on what is being added and by who. Figure 7: Tender Bid context diagram The stakeholders in the Tender Bid context are as follows: Stakeholder Description AccountManager The sales department is responsible for costing a survey and to initially book it on a vessel or region in case of a lead. Sales account managers, sales supervisors and sales managers are members of this group. Introspection Introspection has two tasks. For the booking and booking validation process it shall inform about vessel configurations, which it can get from the vessel descriptions. In addition the actual progress is extracted from Introspection to keep the schedule up to date. Operations Operations will be responsible for the survey preparation and execution. They need detailed information on the vessel schedule to plan the start-up of a survey. Operations managers, vessel supervisors and party chiefs are the main members of this group. In addition there are several service groups which will also be included in this group. Operational support (Technical services), personnel management, accounting. Administrator A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. Support A support role is needed to promote the input of competitor information. This role needs to access the system to obtain status on what is being added and by whom. Marine Marine management will be responsible to confirm the booking of surveys onto a vessel. Managment Regional marine management, business managers and global marine management are part of this group. The activity diagram below shows how the Tender Bid process fits within the higher order Marine Acquisition process, which consists of five major steps. The first two steps with associated information flow, coloured green, define the scope of the Tender Bid business context. The steps are as follows: PreSales is the business process that aims to sell the WesternGeco resources with the goal of winning profitable bids. If the presales process succeeds, WesternGeco will be better prepared when an Invitation to Tender (ITT) is received. Page 9 of 93

120 Tender Bid is the business process that analyses the ITT. If the ITT seems profitable, an offer is made by WesternGeco to the issuer of the ITT. If the bid is won, a Seismic Work Order is issued to the Operations. If the bid is lost, the information is archived and the process ends. :Sales & Marine Management :Operations PreSales [no bid] [qualified bid] <<ResourceAsArtefact>> :ITT Tender Bid [won] [lost] <<ResourceAsArtefact>> :SWO Survey Preparation Survey Execution Survey Close Figure 72: Tender Bid scope in Marine Acquisition process..2 Vision for Change The survey-booking tool is a web-based and highly automated tool to support the process around booking of vessel time for potential surveys. Page 20 of 93

121 Its main task will be: Schedule leads and surveys Send automatic warnings on changes and conflicts Inform about current resource usage and potential backlog..2. Description The survey-booking tool will help to administer the utilization of our vessels. It will mainly benefit three user groups; Sales, operations and marine management. Sales will use it to book a survey or tender onto a vessel. The survey-booking tool will give an overview over the current workload and also which vessel qualifies for the job. Sales will make booking suggestions to management, which then need to be confirmed by the global marine management. For operations the booking tool should work as a planning aid. It will automatically warn about changes and it will have detailed job information available on-line. Marine management will be able to use the booking tool to assess the current resource usage, confirm survey bookings and to reschedule jobs. The survey-booking tool will be web based and automatically updated with the current progress rates from Introspection. A consequence of this approach is that there needs to be one global master schedule. In order to visualize alternative scenarios each user can create private schedules...3 Risk Analysis The table below describes risks that are identified in the project. There are no major risks involved. This system is strongly wanted by the users/client. The development team is very experienced in this kind of systems, and the relationship between the client/users and the development team is very good. Issue Security Competition Technology Multi-user & transactions Risk statement The system will contain very business sensitive information and must implement a very strict access-control mechanism The sales community is in the process of introducing a CRM system. Need to carefully define the border between these two systems The Web and Java based technology from the Introspection base-line has already proven itself The system must support multiple users in a distributed organization to work in parallel and synchronize their schedules into one common global schedule Number of users Uptime Development group Performance There will be approx users accessing the system each day The system should support a 7by24 hour operation. The development group from the Introspection team is very experienced in web & java based distributed technology The system must support an efficient communication protocol between the clients and the server Page 2 of 93

122 .2 Goal Model The purpose of the Goal Model is to agree with the Business Stakeholders the business goals that will be met by implementing and then using the Survey Booking System. A goal structure for the Tender Bid business context is shown in the class diagram below. Make a profitable bid Proper legal assesment Sound cost estimates Proper technical assesment Optimize fleet utilization Easy access to historical information Updated cost-models Updated own schedule Updated competitor schedule Figure 73: Tender Bid goal structure Goals are structured in a hierarchy. All leaf goals should be explicitly supported by one or more business processes. We will show these links below when we describe the processes of the business. The goals are as follows: Goal Make a profitable bid Proper legal assessment Sound cost estimates Easy access to historical information Updated cost-models Capability/Technical assessment Optimize fleet utilization Updated own schedule Updated competitor schedule.3 The Tender Bid Process Description This is the top-level goal. Obviously, one only wants to bid on contracts that will be profitable to WesternGeco. A bid must be assessed for legal issues. In order to see if a bid will be profitable it is important to be able to make sound cost estimates. Historical information is important in order to make viable cost-models. Updated cost-models must be available for use. A capability/technical assessment must be done to see if WesternGeco has the capability and technology to handle the contract. For example, in some cases a ship must be technically upgraded to handle the contract and this must be taken into consideration. Effective planning needs an updated schedule It s important to track the competitors in order to price the bid favourable, as well as learning about reasons for lost bids. The tender bid process is a fairly large process that involves several people and software tools. The process can be broken down into three more manageable sub- processes. The three subprocesses, depicted in Figure 74, are: Page 22 of 93

123 . The Receive ITT & Prepare for bidding subprocess describes how to handle an incoming ITT and the decision to bid. 2. The Make Tender subprocess describes the steps involved in creating a tender. 3. The Submit Tender subprocess describes the steps for submitting a tender to the client. Receive ITT & Prepare for bidding [continue] Make Tender [continue] [stop] [stop] Submit Tender Figure 74: Tender Bid process overview Each of these three subprocesses will be elaborated below. Page 23 of 93

124 .3. Receive ITT & Prepare for bidding :Oil Company :Secretary :AccountManager :Manager Send ITT itt:itt Archive ITT ITT received Check ITT booking:booking Create or update booking Check Competitor Schedule {Surve Bookin {Oth tool} {Surve Bookin Create business review form brf:businessreviewform Bid approval Make Tender {End of survey booking} [Cancel bid] Figure 75: Receive ITT & Prepare for bidding activity diagram Figure 75 shows an activity diagram that describes the Receive ITT & Prepare for bidding subprocess. Each swim lane in the diagram corresponds with an actor in the business. The activities in each swim lane reflect the work that each actor is responsible for. The Toolstep business steps are annotated with the name of the identified application component. Make a profitable bid Proper legal assesment Sound cost estimates Proper technical assesment Optimize fleet utilization Create business review form Easy access to historical information Updated cost-models Updated own schedule Updated competitor schedule Create or update booking Check competitor schedule Figure 76: Goals supported by steps in Receive ITT & Prepare for bidding process Figure 76 shows how the process steps in the Make Tender process supports the goals of the business. Page 24 of 93

125 A description of the activities are given in the table below: Activity Description Check ITT Tender is received. Check we have full document. Note deadline for response, how many copies client requires and where to send it. Send acknowledgement to client requesting extension to deadline if necessary. Request electronic copy if not already received. Send internal note to management, operations, technical, exploration services detailing requirements and scope of work. Check Competitor Check competitor schedule and talk to fellow account managers to see what they Schedule know about competitor activity. Create Business Read tender and note main details on Business Review Form: scope, required Review Form configuration, preferred timing, and assess likely competitors. Bid Approval Comment tender with Exploration Manager to confirm we should bid, the business review form is the basis of this discussion. Discuss approximate price levels with exploration manager. If we decide not to bid then inform client and our own people that we will "no bid". Page 25 of 93

126 .3.2 Make Tender :AccountManager :Manager :Reviewer {Surve Costin {Oth tool} Survey Costing Distribute ITT for review Part_of:ITT cpp:costpriceproposal [?cost approved] [?cost too high] Approve cost [?Not approved] feedback:reviewfeedback Review ITT Evaluate feedback [No issues] [Too high cost] [cost issues] Resolve issues Compile Tender recalculate cost {Surve Costin [cost ok] tender:tender Approve Tender Submit Tender [decide to send] [decide not to send] {End of survey booking} Figure 77: Make Tender activity diagram Figure 77 shows an activity diagram that describes the Make Tender subprocess. Each swim lane in the diagram corresponds with an actor in the business. The activities in each swim lane reflect the work that each actor is responsible for. Page 26 of 93

127 Make a profitable bid Proper legal assesment Sound cost estimates Proper technical assesment Optimize fleet utilization Resolve issues Review ITT Approve cost Easy access to historical information Updated cost-models Updated own schedule Updated competitor schedule Survey Costing Recalculate cost Figure 78: How the process steps in Make Tender supports the goals Figure 78 shows how the process steps in the Make Tender process supports the goals of the business. A description of the activities are given in the table below: Activity Distribute ITT for review Description If we bid then prepare to distribute the tender for review. Tender distribution is much easier if the clients have supplied an electronic document, otherwise it has to be copied and faxed/mailed. Tender review involves operations manager, legal, tax, source group, instrumentation(now OTC regional technical support in EAM), navigation, seismic QC and data processing if processing is also requested in the tender (we should bid processing anyway). Send a brief summary of the work by to relevant person in each technical department and attach the document to be reviewed, including a date by which they should respond. Legal have their own special requirements and need a lot of information up front about the likely risks (for insurance) and expected revenue. Tax want to know where the work will be and how much we will earn. Client may send a seismic section from the survey area with the tender, explain their objectives and ask us to comment on their proposed acquisition parameters, this is a job for geo-support. Clients will often request that we answer their own QHSE questionnaires. Page 27 of 93

128 Survey Costing Make price proposal with autobaf using business review summary sheet. Taking as a starting point our success or otherwise in recent tenders together with the exploration manager we decide a price level at which to aim in terms of monthly revenue or price per square kilometre. Most of the Autobaf inputs come from the tender invitation. Autobaf works by first calculating the cost of the survey (duration) including fixed monthly vessel costs and the additional so called 3rd party costs. For third party costs I may need help from marine operations (chase vessels, helicopters, fuel prices) Navigation technical support will give me rates for navigation signals together with their tender feedback Seismic QC will give me a price for the QC required by the tender in their feedback. Next step is to define the survey definition, again most inputs will be in the tender invitation but I will consult Introspection for historical weather downtime statistics and seismic interference in the survey area. If the client has forgotten to put some critical parameters in the tender invitation then I will make direct contact to get the necessary information. If I am uncertain about mobilisation times for a particular configuration or steaming time to a certain survey area then I will either consult introspection to look at previous work, or I will consult marine operations direct, vessel supervisors or the operations managers. If I am in any doubt about vessel capacity I will consult the operations manager, and similarly if I am unsure about availability of pool equipment such as streamers, then I will contact the pool manager. I may consult a party chief direct if I know someone that can help me or know of a particular boat with experience relevant to the bid I am working on. Defining the survey definition in Autobaf will establish total costs for the survey. Next I put a price on the survey paying attention to the expected monthly income for the vessel and the final price per sqkm. Internally Geco focus on monthly revenue, while our clients focus on the cost per sqkm, so we need to be conscious of both. During this process I frequently refer back to previous recent bids where I know approximately the rates at which the bid was won or lost. Approve Cost When I am satisfied with the proposal I set up a meeting with the exploration manager to discuss prices and make my proposals to him. If he agrees he will then seek approval from his own manager who may request a further meeting, if he disagrees then I will repeat the exercise in line with his recommendations. At this meeting we also agree on which vessel to bid and what timing we will offer. We will consult our own vessel schedule and competitor information. Evaluate Feedback Within a week of sending the tender for review I will normally receive feedback in the form of an and attachments from all reviewers. After reading through the feedback I have to decide whether to incorporate all the feedback in the tender of not. To make this assessment I will call the individual reviewer and discuss the controversial issues with them directly. Some feedback may imply additional costs which were not previously allowed for and may require that I go back to Autobaf to recalculate the rates. Page 28 of 93

129 Compile Tender By this stage I should have all I need to compile the tender.basic contents of a tender are: Covering letter (legal entity, timing, vessel proposed) A technical proposal of how we will do the work and summary of acquisition parameters An estimation of how long the work will take subject to configuration (from autobaf) A summary of previous experience from Introspection Rates as already computed and an estimate of total survey costs A description of the vessel offered, maritime and technical details Proposed source and signatures from technical support Proposal for a navigation Proposal for seismic QC Proposal for data processing if requested List of technical and legal contractual exceptions Requested or standard QHSE information Organisation diagrams for marine sales and marine operations.3.3 Submit Tender :Oil Company :AccountManager :Operations Review Tender tender:tender Update booking status to tender sent response:bidresponse Update booking status to bid won or lost Survey Preparation Figure 79: Submit Tender activity diagram Figure 79 shows an activity diagram that describes the Submit Tender subprocess. Each swim lane in the diagram corresponds with an actor in the business. The activities in each swim lane reflect the work that each actor is responsible for..3.4 Survey Booking The activity diagrams also show the results of the WARM analysis, annotating activities either as human, immediate or tool supported. The Survey Booking system is an application component. Each of the tool supported activities that are described in the Tender Bid process activity diagram are linked against a software tool. Within a process several different tool can be used. Activities that are linked against the Survey Booking application form the basis of the business requirements for the Survey Booking system. This is further detailed in a separate Requirements Model. Page 29 of 93

130 The previous Tender Bid process activity diagrams shows that the Survey Booking application is used in the following Tool supported business steps. Receive ITT & prepare for bidding o Create or Update booking o Check competitor schedule Submit tender o Update booking status to tender sent o Update booking status to bid won or lost The other activities that are linked against other tools and those that are manually operated should not be completely overlooked when developing a new software system or improving an existing software system. Investigation should conclude: If any of the manual steps could be supported by the new or improved tool Synergy effect between different tools (can they be combined or replaced) For instance, improvement of the existing costing tool that is used in the Survey Costing activity is now being planned. This tool should integrate easily with the existing product line..4 Business Resources The Business Resource Model identifies and defines the main concepts of the domain that are relevant to the Survey Booking System. Information resources are modelled using classes and class diagrams. Page 30 of 93

131 LocalS chedule GlobalS chedule Configuration Client <<shall use>> Schedule corp_code : undefined Crew SWO Booking start : undefined end : undefined summary : undefined <<located in>> <<located in>> Vessel <<owns>> Capacity Company Job Country Area/region Tender/Lead Survey Phase WesternGeco Competitor Figure 80: Business information diagram The most important business resources are described in the table below. Resource SWO Booking Job Schedule Vessel Description A SWO is short for seismic work order, which contains the details of the contracted work to carry out for a client. A booking is an allocation of crew and vessel resources within WesternGeco that is to carry out a SWO in a specific country or region. A job represents the current status of a booking. Tender/Lead means that this booking represents a rumour. A booking of vessels and crew in this case is thus only planned, not actual. Survey means that this booking represents an actual contract, a won bid. Resource allocation has to be planned and carried out. In addition, lost and finished are other status flags that are assigned to jobs. A schedule contains a set of bookings. There exists a global schedule that contains the actual and planned bookings. In addition, every sales person can have their own local schedules that are synchronized at regular intervals with the global schedule. A vessel represents a seismic ship. Page 3 of 93

132 2 Appendix F: WesternGeco Requirements Model Example 2. Product Vision and Description 2.. Vision The survey-booking tool is a web-based and highly automated tool to support the process around booking of vessel time for potential surveys. Its main task will be: Schedule leads and surveys Send automatic warnings on changes and conflicts Inform about current resource usage and potential backlog 2..2 Description The survey-booking tool will help to administer the utilization of our vessels. It will mainly benefit three user groups; Sales, operations and marine management. Sales will use it to book a survey or tender onto a vessel. The survey-booking tool will give an overview over the current workload and also which vessel qualifies for the job. Sales will make booking suggestions to management, which then need to be confirmed by the global marine management. For operations the booking tool should work as a planning aid. It will automatically warn about changes and it will have detailed job information available on-line. Marine management will be able to use the booking tool to assess the current resource usage, confirm survey bookings and to reschedule jobs. The survey-booking tool will be web based and automatically updated with the current progress rates from Introspection. A consequence of this approach is that there needs to be one global master schedule. In order to visualize alternative scenarios each user can create private schedules. The main display part will look like today's vessel scheduler (see Figure 8). This display is proven and appreciated by many users. Page 32 of 93

133 2..3 Background and Motivation Figure 8: Excel based vessel schedule as today Beginning 2000 it was decided to give all business application tools a real development home at OTC. Now we are about to create a set of business application tools. The new surveycosting tool will be the main component, but this tool needs a couple of helper applications like for example the survey-booking tool. This document specifies the requirements and high-level use cases for the survey-booking tool. The survey-booking tool is a complete redesign of the vessel schedule. We tried to design it as a 'light' tool, without too much intelligence. The intelligence to the system will be more a part of the survey-costing tool. The advantage of this design is that we can deliver the survey-booking tool fairly fast. We have the luxury of owning a good old version, the current excel based vessel schedule. This version will stand for a lot of the requirements. It was introduced about 5 years ago by R. Walker and has been improved a couple of times. However, it is now no longer sufficient for the global Web environment. 2.2 Use Cases 2.2. What is a Use Case With the presentations of use cases in this document we want to follow a quite widely followed model on how to engineer a project. Use cases are part of a structured approach to capture all interactions a system should do and at the same time define all interacting user groups and systems. Page 33 of 93

134 The use cases describe how actors interact with the system. Actors can be users or other systems, which normally extract or import information. In this document a high level view of the use cases is presented. The main aim at this point is to assure that all use cases have been found and all actors were identified System Boundary model. Book tender/lead <<include>> 2. Update booking status <<include>> <<include>> SurveyBooking 8. Automated schedule updates <<include>> 2. S ubscribe to notification 9. Notify Introspection Sales 3. Ask for confirmation <<include>> 4. Confirm job Operations <<include>> 5. Reschedule job Marine Management 6. Update work-order (SWO) 3. View market-share and forecast reports 7. View schedule 0. Add/remove users & rights Administrator Support 4. View competitor input report(s). Add/remove vessels Figure 82: Survey Booking main use cases In bold the use cases which are of highest priority, which are the target for the first version Definition of actors (User groups) Sales The sales department is responsible for costing a survey and to initially book it on a vessel or region in case of a lead. Sales account managers, sales supervisors and sales managers are members of this group Operations Operations will be responsible for the survey preparation and execution. Operations managers, vessel supervisors and party chiefs are the main members of this group. In addition there are several service groups which will also be included in this group: Operational support (Technical services), personnel management, accounting Marine management Marine management will be responsible to confirm the booking of surveys onto a vessel. Page 34 of 93

135 Regional marine management, business managers and global marine management are part of this group Introspection Introspection has two tasks. For the booking and booking validation process it shall inform about vessel configurations, which it can get from the vessel descriptions. In addition the actual progress is extracted from Introspection to keep the schedule up to date Administrator A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names Support A support role is needed to promote the input of competitor information. This role needs to access the system to obtain status on what is being added and by whom Summary list of use cases Name Description Actors. Book tender/lead Book a tender onto a vessel Book a lead onto an area. Sales Management 2. Update booking Move unsuccessful tenders to competitor schedule, keep Sales status lead/tender status up-to-date and confirm successful tenders. 3. Ask for confirmation Check if confirmation is necessary, ask for confirmation if "All" necessary, notify otherwise. 4. Confirm Job Confirm the booking which sales proposed Management 5. Reschedule job Move jobs in time or to another vessel. Sales Management 6. Update work-order (SWO) Associated with each survey is a SWO, which needs to be filled in. The SWO keeps the survey specific information Sales Operations 7. View schedule Get an overview over the current status and be able to extract "All" some survey and vessel specific information. Check with access policy to determine what can be shown. 8. Automated schedule Update status on current survey. Is it progressing as indicated in Introspection updates the booking tool? 9. Notify Notify users who requested notification "All" 0. Add/remove users and rights Administer the user's access rights and notification whishes Administrator. Add/remove Vessels Administer the active vessels Administrator 2. Subscribe to Specify the criteria's to be used for sending a notification. "All" notification 3. View market-share and forecast reports Extract information about own and competitor vessels to calculate market-share. Calculate capacity forecast based on Management and Sales (provided 4. View competitor input report(s) Global quality requirements information on leads and bids submitted. Extract information on what is being added/modified to the competitor schedule and by whom. The system must run on Netscape and preferably also on MS Internet Explorer. access rights) Support Page 35 of 93

136 2.3 Subsystem grouping The figure below shows how the use-cases are grouped into subsystems. This grouping is based on an analysis of the usage of the system by the different actors and also by applying the COMBINE reference architecture model. These subsystems are going to be implemented as different components. BookingEditor. Book tender/lead Introspection GlobalScheduleService 7a. View local schedule 5. Reschedule job 8. Assemble and deliver schedule 2. Update booking status <<include>> 7. Synchronize and save schedule ActivityInfo Sales 5. Import from global schedule <<include>> 0. Add/remove users & rights 6. Export to global schedule <<include>>. Add/remove vessels BookingViewer <<include>> Administrator 7b. View global schedule SubscriptionService Marine Management 9. Check for subscriptions & notify SubscriptionEditor 2. Subscribe to notification <<include>> 20. Update list of available subscriptions SubscriptionInfo Operations 2. Save/remove subscriptions 2.3. The Booking-Editor Figure 83: Survey Booking subsystem grouping use cases The Booking-Editor is a tool-component and is used by the sales community. This component contains most of the use-cases for sales and supports the need to run offline. It also restricts the ability to manipulate the information to sales only as defined in a very strict access-right list. In order to run in an offline modus we have introduced two new use-cases (5. Import global schedule, 6. Export global schedule). These use-cases will talk to a server-side businessservice component called The GlobalScheduleService The Booking-Viewer The Booking-Viewer is a tool-component used by all actors. The access-rights will be controlled by access-lists (LDAP). This component is a web-based client and gives viewer functionality only. Page 36 of 93

137 2.3.3 The Subscription-Editor The Subscription-Editor is a tool-component used by all actors. The access-rights will be controlled by access-lists (LDAP). This component is a web-based client that gives the possibility to monitor (via ) different business-events (state-changes) in the booking schedule. The Subscription-Editor stores the information in a server-side business-servicecomponent called The SubscriptionService The Global-Schedule-Service The Global-schedule-service is a business-service-component that serves the Booking-Editorand the Booking-Viewer tool-components. It contains two use-cases: 7) Synchronize and save schedule, 8) Assemble and deliver schedule. These two use-cases talks to a resource component called Activity-Info which already exists (reused) and is shown as an actor in the figure The Subscription-Service The Subscription-service is a business-service component that implements the server-side functionality of the Subscription-editor. It contains two use-cases: 9) Save/Remove subscription, 20) Check for subscriptions and notify. 2.4 The Booking-Editor Use Case descriptions BookingEditor. Book tender/lead 2. Update booking status Sales 5. Reschedule job Introspection 5. Import from global schedule 6. Export to global schedule GlobalScheduleService 7a. View local schedule Figure 84: Booking Editor use cases Page 37 of 93

138 2.4. Use Case : Book tender/lead Primary scenario Use case Book tender/lead Priority Goal Book tender onto a vessel or lead onto an area Actors Sales (initiating), Introspection (involved) Pre-conditions None. Post-conditions Global booking OK and information about who made the booking logged in database. Façade - Quality - requirements Scenario Book from scratch using full featured tool. Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Create new private schedule. A local setup is used to identify which regions, vessels, competitors should be included in the private schedule. 3 Synchronize with global schedule. (use-case 5) 4 Fill in job-form 4. Client, area, time, time constraints and configuration. 4.2 Booking status (rumor, lead, tender received, bid submitted, bid won/lost, survey running/halted, survey completed, booking cancelled) In case of lead/bid submitted, a qualifier indicating likelihood of becoming a tender/winning bid (in %) is required (0, 25, 50, 75, 00). 4.3 Booking type (Seismic acquisition, travel, port call, yard, lay-up, test) 5 Select vessel from list (not required for booking status rumor, lead, tender received and bid submitted). System can show a ranked list of vessels if working online (provided from Introspection based on vessel description). Ranking criteria are: Configuration, availability, area and cost 6 Create booking in private schedule 7 Save private schedule. 8 Export booking to global schedule (use-case 6) 8. Confirm export of changes in local schedule 8.2 Bid base number will be given from the system and inserted into the global and private schedule 9 Notify interested parties (Use case 9) Alternative scenario A Use case Book tender/lead Priority Goal Book tender onto a vessel or lead onto an area Actors Sales (initiating), Introspection (involved) Pre-conditions Successful online login must have been performed to generate local authorization data. Post-conditions Local booking created. Export to global schedule not yet performed. Façade - Quality - requirements Scenario Book in existing private schedule using full featured tool. Description Step Action Login & authorize on offline version. Use local authorization. 2 Open private schedule. 3 Step 3-7 of primary scenario. Page 38 of 93

139 2.4.2 Use case 2: Update booking status Primary scenario Use case 2 Update booking status Priority Goal Move unsuccessful tenders to competitor schedule, keep lead/tender status up-to-date and confirm successful tenders. Actors Sales Pre-conditions Booking exists in private schedule Post-conditions Global booking changes OK and information about who changed the booking status logged in database. Façade - Quality - requirements Scenario Update existing booking using full-featured tool. Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Open existing private schedule. 3 If needed, synchronize with global schedule. 4 Select actual booking 5 Update information if necessary 5. Reschedule (use-case 5) 5.2 Update work-order (use-case 6) 6 Change booking status (rumor, lead, tender received, bid submitted, bid won/lost, survey running, survey halted, survey completed, cancelled) 6. In case of lead/bid submitted, a qualifier indicating likelihood of becoming a tender/winning bid (in 5) is required (0, 25, 50, 75, 00). 6.2 If job was cancelled or lost, specify reason 7 Change time, time constraints. (Use case 5) 8 Save private schedule. 9 Export booking changes to global schedule ( use-case 6) 9. Confirm export of changes in local schedule 9.2 Confirm overwrite if someone has updated global schedule since last synchronization. 0 Ask for confirmation (Use case 3) Notify interested parties (Use case 9) Alternative scenario A Use case 2 Update booking status Priority Goal Move unsuccessful tenders to competitor schedule, keep lead/tender status up-to-date and confirm successful tenders. Actors Sales Pre-conditions Successful online login must have been performed to generate local authorization data. Post-conditions Local booking created. Export to global schedule not yet performed. Façade - Quality - requirements Scenario Update existing booking using full-featured tool in offline modus. Description Step Action Login & authorize on offline version. Use local authorization. 2 Step 2-8 of primary scenario. Page 39 of 93

140 2.4.3 Use case 5: Reschedule jobs Primary scenario Use case 5 Reschedule jobs Priority Goal Reschedule jobs and tenders, which are already listed in the booking tool Actors Sales Pre-conditions Booking exists in private schedule Post-conditions Global booking changes OK and information about who changed the booking status logged in database. Façade - Quality - requirements Scenario Reschedule existing booking using full-featured tool. Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Open existing private schedule. 3 If needed, synchronize with global schedule. 4 Select actual booking 5 Update booking 5. 'Drag and Drop' booking to new vessel and new time or open editor and select new vessel and/or time. 5.2 Delete job, Specify reason. 6 Save private schedule. 7 Export booking changes to global schedule 7. Confirm export of changes in local schedule 7.2 Confirm overwrite if someone has updated global schedule since last synchronization. 8 Ask for confirmation (Use case 3) 9 Notify interested parties (Use case 9) Alternative scenario A Use case 5 Reschedule jobs Priority Goal Reschedule jobs and tenders, which are already listed in the booking tool Actors Sales Pre-conditions Successful online login must have been performed to generate local authorization data. Post-conditions Local booking created. Export to global schedule not yet performed. Façade - Quality - requirements Scenario Reschedule existing booking using full-featured tool in offline modus. Description Step Action Login & authorize on offline version. Use local authorization. 2 Step 2-6 of primary scenario Use case 7a: View local schedule Primary scenario Use case 7a View local schedule Priority, 2 (step 4) Goal View, print the schedule Actors Sales Pre-conditions None. Page 40 of 93

141 Post-conditions - Façade - Quality - requirements Scenario View local schedule Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Create a new private schedule. A local setup is used to identify which regions, vessels, competitors should be included in the private schedule. 3 Synchronize with global schedule. 4 Print schedule 4. Standard view of current schedule 4.2 Standard print of history schedules (per year) 4.3 Free Selection of start and end time and vessels Use case 5: Import from global schedule Primary scenario Use case 5 Import from global schedule Priority Goal Create a local schedule by importing from global schedule. Actors Sales Pre-conditions None. Post-conditions Local schedule created with selected global data. Façade - Quality - requirements Scenario Create a fresh local schedule by importing from global schedule Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Create an empty local schedule. 3 Select data to import Use case 6: Export to global schedule Primary scenario Use case 6 Export to global schedule Priority Goal Export local bookings to global schedule. Actors Sales Pre-conditions None. Post-conditions Exported booking stored in global schedule. Façade - Quality - requirements Scenario Export local bookings to global schedule. Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Open local schedule to export. 3 Select bookings to export. 4 If conflicts, choose: 4.a Override and export. 4.b Reschedule jobs. 5 Notify interested parties (Use case 9) Page 4 of 93

142 2.5 The Booking-Viewer Use Case descriptions Sales BookingViewer 7b. View global schedule Operations GlobalScheduleService Marine Management 2.5. Use case 7b: View global schedule Figure 85: Booking Viewer use cases Primary scenario Use case 7b View global schedule Priority Goal View, print the schedule Actors Marine management, Operations, Sales Pre-conditions None. Post-conditions - Façade - Quality - requirements Scenario View global schedule using lightweight tool. Description Step Action Login & authorize on online version. Use LDAP to authorize. 2 Specify which regions, vessels, competitors should be included. 3 Print schedule 3. Standard view of current schedule 3.2 Standard print of history schedules (per year) 3.3 Free Selection of start and end time and vessels. Page 42 of 93

143 2.6 The Subscription-Editor Use Case descriptions Sales SubscriptionEditor 2. Subscribe to notification Marine Management SubscriptionService Operations Figure 86: Subscription Editor use cases 2.6. Use case 2: Subscribe to notification Primary scenario Use case 2 Subscribe to notification Priority Goal User shall be able to view and modify list of subscriptions, and submit a updated list of selected subscriptions to the system. This list shall be stored in the systems subscription database. The updated list of subscriptions shall take effect immediately after the submission has been confirmed to the user. Actors User (Sales people, Marine Management) Pre-conditions The subscription system must be up running and the user must have access to this service. The administrator must have created the list with available subscriptions. Post-conditions The updated list of subscriptions must be stored in the DB and the user must receive an acknowledgement in the client tool. Façade - Quality requirements Only authorized persons must be allowed to use this service Client tool must be cross-platform compliant. Scenario - Description Step Action Login & authenticate 2 Retrieve all available subscriptions 3 Retrieve user's subscriptions and displays them. 4 View subscriptions 4.a Remove subscriptions 4.a2 Submit updated subscription list 4.b Add subscriptions, selected from available subscriptions 4.b2 Submit updated subscription list Page 43 of 93

144 2.7 The Global-Schedule-Service Use Case descriptions GlobalScheduleService. Add/remove vessels 0. Add/remove users & rights Administrator BookingEditor 7. Synchronize and save schedule SubscriptionService 8. Assemble and deliver schedule BookingViewer ActivityInfo Figure 87: Global Schedule Service use cases 2.7. Use case 0: Add/remove users & rights Primary scenario Use case 0 Add/remove users & rights Priority Goal To administer users and user privileges Actors Administrator Pre-conditions None. Post-conditions - Façade - Quality - requirements Scenario - Description Step Action Login & authorize (LDAP) 2 Create/remove users and assign roles 3 Assign/remove rights to user Use case : Add/remove vessels Primary scenario Use case Add/remove vessels Priority Goal To administer available vessels (incl. competitor vessels) Actors Administrator Pre-conditions None. Post-conditions - Façade - Quality - requirements Scenario - Description Step Action Page 44 of 93

145 Login & authorize (LDAP) 2 Create/remove Seismic companies 3 Create/remove Vessels or move vessel between different seismic companies Use case 7: Synchronize and save schedule Primary scenario Use case 7 Synchronize and save schedule Priority Goal Check Store schedule in global database Actors Booking Editor Pre-conditions Post-conditions Schedule will be stored in database Façade - Quality - requirements Scenario - Description Step Action Save schedule in database if no modification conflicts 2 If modification conflicts, ask BookingEditor for forced saving or cancel 2. If forced save, owner of original data Use case 8: Assemble and deliver schedule Primary scenario Use case 8 Assemble and deliver schedule Priority Goal Deliver the schedule Actors BookingEditor & BookingViewer Pre-conditions Post-conditions Façade - Quality - requirements Scenario - Description Step Action Assemble the schedule based on regions,vessels and time-interval specified 2 Deliver to BookingEditor & Viewer Page 45 of 93

146 2.8 The Subscription-Service Use Case descriptions SubscriptionService Administrator 20. Update list of available subscriptions 2. Save/remove subscriptions SubscriptionEditor SubscriptionInfo 9. Check for subscriptions & notify GlobalScheduleService Server Figure 88: Subscription Service use cases 2.8. Use case 9: Check for subscriptions & notify Primary scenario Use case 9 Check for subscriptions & notify Priority Goal When certain topics are changed different user groups need to be notified based on what they have "subscribed to". Notifications should be ranked according to severity. Changes in the Survey booking database shall be reported to the notification service. This service shall send a mail notification to all users who has subscriptions, which matches the reported database change. After the submission has been confirmed to the user. Actors Notifier (GlobalScheduleService), SubscriptionInfo, Server Pre-conditions changes in the booking schedule to interested parties according to notification policies set up by the individual or group. The subscription system must be up running and mail service must be available. Post-conditions - Façade - Quality requirements If the update is done when the system is up running the changes must take effect at the next incoming request after the file is saved. Scenario - Description Step Action GlobalScheduleService reports database change. 2 Retrieve all subscriptions from subscription database. 3 Search through all subscriptions too see if they match the reported data change. 4 Subscription does not match, continue search 4. Subscription matches data change. 4.2 Send mail to user about the change. Page 46 of 93

147 2.8.2 Use case 20: Update list of available subscriptions Primary scenario Use case 20 Update list of available subscriptions Priority Goal When demands for new subscription types come in the Administrator must be able to add these new subscriptions types in an easy way. Actors Administrator Pre-conditions - Post-conditions - Façade - Quality requirements If the update is done when the system is up running the changes must take effect at the next incoming request after the file is saved. Scenario - Description Step Action A new subscription type must be added. 2 The Administrator uses a text-editor to update a text-file which contains the configuration Use case 2: Save/remove subscriptions Primary scenario Use case 2 Save/remove subscriptions Priority Goal Save or remove subscription from database Actors SubscriptionEditor Pre-conditions Post-conditions Façade Quality requirements Scenario Description Step Action Save or remove subscription data in the database for a specific user Page 47 of 93

148 3 Appendix G: WesternGeco Architecture Model Example 3. Reference Architecture Analysis 3.. Survey Booking Subsystem Grouping Use Case Model BookingEditor. Book tender/lead Introspection GlobalScheduleService 7a. View local schedule 5. Reschedule job 8. Assemble and deliver schedule 2. Update booking status <<include>> 7. Synchronize and save schedule ActivityInfo Sales 5. Import from global schedule <<include>> 0. Add/remove users & rights 6. Export to global schedule <<include>>. Add/remove vessels BookingViewer <<include>> Administrator SubscriptionService 7b. View global schedule Marine Management 9. Check for subscriptions & notify SubscriptionEditor 2. Subscribe to notification <<include>> 20. Update list of available subscriptions SubscriptionInfo Operations 2. Save/remove subscriptions Figure 89: Survey Booking subsystem grouping use cases Figure 89 is a use case diagram that shows the subsystems of the Survey Booking Application. Each subsystem has a set of use cases that must be realized and offered as required to its users. Human users interact with the system using tool components that provide graphical user interfaces. Each of these tools collaborates with business service components. Business services are network visible and can be shared between multiple tools. Persistent storage for the business services is provided by resource services. Page 48 of 93

149 3..2 Component Identification BookingEditor BookingViewer S ubscriptioneditor Component Infrastructure BookingService S ubscriptions ervice ActivityInfo S ubscriptioninfo Figure 90: Survey Booking reference architecture analysis Figure 90 is a class diagram that shows the mapping of the subsystems to corresponding Tool, BusinessService and ResourceService components. The subsystems BookingEditor, BookingViewer and SubscriptionEditor are used by human users. They map to Tool components according to the reference architecture. The BookingEditor is to be installed locally on a client machine, while the BookingViewer and the SubscriptionEditor will be available through a web server. The subsystems GlobalScheduleService and SubscriptionService offers services to the tools and maps to BusinessService components. The tools communicate with these business services over a network. The GlobalScheduleService corresponds to the component BookingService in the figure above. The subsystems ActivityInfo and SubscriptionInfo map to ResourceService components that provide persistent data storage to the BookingService and SubscriptionService respectively. The structure of the Survey Booking Application component is shown in the diagram below. Components are modelled as UML classes. Each component class is modelled within a UML package that holds the full specification of the component. Page 49 of 93

150 3..3 Component Interfaces BookingEditor BookingViewer S ubscriptioneditor Browser IBookingService ISubscription POP BookingService INotify SubscriptionService SMTP S erver ISubscriptionInfo IActivityInfo SubscriptionInfo ActivityInfo Figure 9: Survey Booking component structure Components collaborate with each other through well-defined interfaces. Figure 9 is a class diagram that shows the components and interfaces of the Survey Booking Application. Two additional components are shown in this diagram. The Browser and Server. The Browser represents a standard reader tool that is used in the Survey Booking context for retrieving and reading booking notifications. The Server represents the standard server business service that is deployed within the company. As can be seen, the SubscriptionService requires the Server in order to send notifications. All of the components presented here will be handled in separate chapter. For each tool, the use cases involved will be broken down to define user services. For each business service, the use cases involved will be broken down to define and interfaces offered to the tools. 3.2 The Booking Editor Tool description A tool consists of a User Interface component and a User Service component. The Booking Editor must also be able to operate in an offline modus. This means that local persistent storage must be provided. Page 50 of 93

151 BookingEditorUI IUserService BookingEditorUS IActivityInfo LocalActivityInfo IBookingService Figure 92: Booking Editor component structure Figure 92 is a class diagram that shows the internal components of the Booking Editor Tool. BookingEditorUS is a User Service that provides a façade to the Tool. The BookingEditorUS uses LocalActivityInfo, which is a User Resource Service that provides the local data persistent storage used in offline modus. The LocalActivityInfo component is provided by a lightweight implementation of the ActivityInfo component described in appendix C. The User Service is described in details below. The User Interface component will be described in the forthcoming design document User Service In order to specify the User Service for the Booking Editor we need to do a use case analysis. The use case analysis takes the Business Resource Model as input and analyses the information and operations that must be provided through the user service. Page 5 of 93

152 3.2.. Business Resource Analysis LocalS chedule GlobalS chedule Configuration Client <<shall use>> Schedule corp_code : undefined Crew SWO Booking start : undefined end : undefined summary : undefined <<located in>> <<located in>> Vessel <<owns>> Capacity Company Job Country Area/region Tender/Lead WesternGeco Competitor Survey Phase Figure 93: Booking Editor business resource analysis Figure 93 shows the business information that must be presented to the user through the User Interface component. This information must be accessible to the User Interface component from the User Service. The information provided by the User Service is based on the generic ActivityInfo model, mapping the business information to appropriate activity elements. This information is provided to the User Interface, which is to be implemented as a rich client. Page 52 of 93

153 OrgUnit Project Vessel Company Area/Region Survey Phase ParameterS et Report Activity Configuration SWO Capacity Figure 94: Business Resource Model mapping to Activity Info Model Figure 94 shows the mappings from the Business Resource Model to the Activity Info Model. Page 53 of 93

154 Interface Operations IUserService +OPERATION_A : integer= +startbrowser(in scheduledata:project) +login(in username:string,in password:string,in url:url):loginstatus +exit() +hasaccessrights(in operation:integer):boolean +createschedule(in subregionslist [] string,in vessellist [] string,in starttime:date,in endtime:date):project +getusername(in loginstatus:loginstatus):string +isnew(in scheduledata:project):boolean +ismodified(in scheduledata:project) +checkdirectory(in dir:string):string +getschedulebuffernames(): [] string +getschedulefilenames(): [] string +getschedulefilenames(in directory:string): [] string +getschedule(in name:string):project +closeschedule(in scheduledata:project) +getscheduledirectory(in scheduledata:project):string +getschedulefilename(in scheduledata:project):string +openschedule(in directory:string):project +saveschedule(in directory:string,in filename:string,in steallock:boolean):boolean +importschedule(in schedule:project,in subregionlist [] string,in vessellist [] string,in includeownactivities:boolean,in includecompetitoractivities:boolean):exportresult +mergeschedule(in schedule:project,in data:exportresult,in localids [] string):project +exportschedule(in schedule:project,in localid [] string,in force:boolean):exportresult +createorgunit(in scheduledata:project,in type:string,in name:string):orgunit +createproject(in scheduledata:project,in type:string,in name:string):project +getcountrylist(): [] OrgUnit +getregions(): [] OrgUnit +getcorporationcodes(): [] OrgUnit +getcompanies(in onlycompetitors:boolean): [] OrgUnit +getowncompany():orgunit +getallvessels(): [] OrgUnit +getvessels(in companyname:string): [] OrgUnit +getvessels(in companynames [] string): [] OrgUnit +createpreferences():parameterset +getpreferences():parameterset +savepreferences(in data:parameterset):boolean Figure 95: User Service interface operations Figure 95 shows the interface operations provided by the IUserService interface. Page 54 of 93

155 Interface Information <<CompositeData>> ExportResult GLOBAL_ID : string LOCAL_ID : string <<Entity>> ActivityObject modified : boolean starttime : Date parameters subparametersets LAST_UPDATED : string scheduleproperties : Vector conflictproperties : Vector endtime : Date name : string equals() <<Entity>> ParameterS et parent activity <<Entity>> Activity category : string orgunits group : string <<Entity>> OrgUnit type : string orgunits <<Entity>> Project reports <<Entity>> Report activities reports comment : string description : string duration : real production : string getproject() parent suborgunits parent subprojects subactivities parent Figure 96: User Service interface information Figure 96 shows the information that is available through the IUserService interface. The entities correspond to the ActivityInfo information model described in section 3.7. The composite data corresponds to the exported data type provided by the BookingService component. 3.3 The Booking Viewer Tool description This tool resembles the BookingEditor tool. However, it is a viewer only, so it should not support editing and should only access the global schedule. Page 55 of 93

156 BookingViewerUI IUserService BookingViewerUS IBookingService Figure 97: Booking Viewer component structure Figure 97 shows the component structure for the BookingViewer component. Since no offline modus is required, a LocalActivityInfo component is not needed as in the BookingEditor case User Service The business resource analysis and the interface information are the same as for the Booking Editor tool. However, the interface operations for the Booking Viewer are more lightweight, as can be seen in the diagram below. IUserService +OPERATION_A : integer= +login(in username:string,in password:string,in url:url):loginstatus +exit() +hasaccessrights(in operation:integer):boolean +createschedule(in subregionslist [] string,in vessellist [] string,in starttime:date,in endtime:date):project +getusername(in loginstatus:loginstatus):string +createorgunit(in scheduledata:project,in type:string,in name:string):orgunit +createproject(in scheduledata:project,in type:string,in name:string):project +importschedule(in schedule:project,in subregionlist [] string,in vessellist [] string,in includeownactivities:boolean,in includecompetitoractivities:boolean):exportresult +getcountrylist(): [] OrgUnit +getregions(): [] OrgUnit +getcorporationcodes(): [] OrgUnit +getcompanies(in onlycompetitors:boolean): [] OrgUnit +getowncompany():orgunit +getallvessels(): [] OrgUnit +getvessels(in companynames [] string): [] OrgUnit Figure 98: User Service interface operations Page 56 of 93

157 3.4 The Subscription Editor Tool description SubscriptionEditorUI IUserService SubscriptionEditorUS Figure 99: Subscription Editor component structure Figure 99 shows the component structure for the Subscription Editor tool User Service The Subscription Editor is a generic notification framework that can be used in many different business contexts. An analysis of the use case gives the following user service specification Interface Operations IUserService +getsubscriptioncombinations(): [] Subscription +getsubscriptions(in user:string): [] Subscription +updatesubscriptions(in user:string,in subs [] Subscription):string Figure 00: User Service interface operations Figure 00 shows the operations provided by the IUserService interface Interface Information <<CompositeData>> Subscription +user : string + string +category : string +event : string +target : string +constraint : string Figure 0: User Service interface information Figure 0 shows the information available throught the IUserService interface. Page 57 of 93

158 3.5 The Booking Service Business Service description The BookingService component is used by the BookingEditor and the BookingViewer tools. The communication between the tools and BookingService occurs over a network, so it is important to specify an interface and protocol that minimises the communication overhead. This is done by providing composite data, which are structured by-value data objects that are sent over the network. BookingEditorUS BookingViewerUS IBookingService BookingService ISubscription IActivityInfo INotify Figure 02: Booking Service component structure Figure 02 shows the provided and required interfaces of the BookingService component. The IBookingService interface provides composite data to the tools. The composite data provided by the IBookingService encapsulates an activity graph instance according to the Activity Info model Interface Specification Interface Operations IBookingService +username : string +user address : string +importschedule(in subregionlist [] List(string),In vessellist:list(string),in starttime:date,in endtime:date,in existingglobalids:vector,in companyfilter:companyenum):exportresult +exportschedule(in _scheduleproperties:vector,in _force:boolean):exportresult Figure 03: Booking Service interface operations Figure 03 shows the operations provided by the IBookingService interface. This interface supports the use cases ) synchronize and save schedule, and 2) assemble and deliver schedule of the Global Schedule Service. The vessel and user management use cases will be provided by an administration tool. Page 58 of 93

159 Interface Information <<CompositeData>> ExportResult GLOBAL_ID : string LOCAL_ID : string LAST_UPDATED : string scheduleproperties : Vector conflictproperties : Vector Figure 04: Booking Service interface information Figure 04 shows the information available through the IBookingService interface. As discussed above, ExportResult is the composite data representation of an activity graph instance of an Activity Info model. 3.6 The Subscription Service Business Service description The SubscriptionService component is used by the SubscriptionEditor and BookingService. Figure 05 shows the required and provided interfaces of the SubscriptionService component. SubscriptionEditor ISubscription SubscriptionService SMTP BookingService INotify ISubscriptionInfo Figure 05: Subscription Service component structure An analysis of the use cases gives the interface specification detailed below. Page 59 of 93

160 3.6. Interface Specification Interface Operations <<interface>> INotify +notify(in context:properties,in newproperties:properties,in oldproperties:properties) <<interface>> ISubscription +getsubscriptioncombinations(): [] Subscription +getsubscriptions(in user:string): [] Subscription +updatesubscriptions(in user:string,in subs [] Subscription):string Figure 06: Interface operations for INotify and ISubscription Figure 06 shows the operations provided by the INotify and ISubscription interfaces Interface Information <<CompositeData>> Subscription +user : string + string +category : string +event : string +target : string +constraint : string Figure 07: Subscription Service interface information Figure 07 shows the information available through the interfaces provided by the SubscriptionService component. 3.7 The Activity Info Resource Service description This section describes the Activity Info Model and the ActivityInfo component that implements it. Page 60 of 93

161 3.7. Activity Info Model ActivityObject modified : boolean starttime : Date endtime : Date name : string equals() parameters <<Entity>> ParameterSet subparametersets parent <<Entity>> OrgUnit type : string orgunits orgunits <<Entity>> Project parent parent suborgunits subprojects reports <<Entity>> Report activity activities reports <<Entity>> Activity category : string group : string comment : string description : string duration : real production : string getproject() subactivities parent Figure 08: Activity Info Model The Activity Info Model defines five different activity types that can be used to implement system representation of business resources: OrgUnit can be used to represent an organisational unit. Project can be used to represent a project in business domain. Activity can be used to represent an activity in the business domain. Report can be used to represent a document which can be generated and printed. ParameterSet can be used to represent various attribute information The Activity Info Resource Service description The ActivityInfo component is a resource service that implements the Activity Info Model and provides access to other business service components through a well-defined interface. The ActivityInfo component is also available in a lightweight implementation, called LocalActivityInfo, which can be used by tool components to provide offline storage capabilities. Page 6 of 93

162 IActivityInfo ActivityInfo Figure 09: Activity Info component structure Figure 09 shows the component structure for the ActivityInfo component Interface Specification The interface information model exposed by the IActivityInfo interface is the Activity Info Model presented above. The interface operations of the interface are shown in the diagram below. IActivityInfo +SUBPROJECT : string=subproject +WRITE : integer= +READ : integer=2 +NAME : string=name +TYPE : string=type +PARENT : string=parent +CLASSNAME : string=classname +DAILYREPORT : string=dailyreport +RELATION : string=relation +REPORT : string=report +PARAMETER_SET : string=parameterset +ACTIVITY : string=activity +PROJECT : string=project +ORGUNIT : string=orgunit +ROOT : string=root +addorgunit(in anorgunit:orgunit):boolean +removeorgunit(in atype:string,in aname:string):boolean +addreportactivity(in anorgunit:orgunit,in anactivity:activity):boolean +removereportactivity(in anorgunit:orgunit,in anactivity:activity):boolean +createorgunit(in atype:string,in aname:string):orgunit +createreport(in atype:string,in aname:string):report +createactivity(in atype:string,in aname:string):activity +createproject(in atype:string,in aname:string):project +createparameterset(in atype:string,in aname:string):orgunit +begintransaction(in transtype:integer):boolean +committransaction():boolean +aborttransaction() +activetransaction():boolean Figure 0: ActivityInfo interface operations Page 62 of 93

163 4 Appendix H: WesternGeco Platform Specific Model Example 4. Technology Discussion This section discusses technology implementation choices for the various components identified. Component Interface name Technology description Booking Editor Will be implemented as a Java application using Java. technology. The application will be downloadable through a web server, and is to be installed locally to support offline usage. Booking Viewer Will be implemented as a Java applet using Java. technology. This applet will contain minimum functionality to support viewing of the master schedule. No modification, offline mode, import/export and save functionality will be supported. Booking Reports Will be implemented as plain HTML pages. The pages will be Booking Service dynamically served by a servlet. Will be implemted as a Java server using Java 2 Servlet technology. IBookingService Will be implemented using the Servlet tunnelling framework. Subscription Editor Will be implemented as plain HTML pages. The pages will be dynamically served by a servlet. Subscription Service Will be implemented as a Java server using Java 2 Servlet technology. ISubscription Will be implemented using the Servlet tunnelling framework. INotify Will be implemented using the Servlet tunnelling framework. Browser Will be provided by standard reader, e.g. Eudora or Netscape. Server Will be provided by the company s server. 4.2 Detailed Design 4.3 The Booking Editor Tool Design 4.3. Graphical User Interface The client shall support a graphical user interface with 2 different views as depicted (simplified) in Figure. This drawing along with the discussion in section 4.3.2, which presents a BCE analysis of the use cases, gives the background for the transformation between the classes in the analysis model and the implementation classes in the design model. This transformation is shown in Figure 8. Page 63 of 93

164 Drop down menus (Action Lists) Time Line File Edit View Setup Window Help Schedule Booking Org Units M/V GECO Eagle WesternGeco M/V GECO Triton WesternGeco M/V Western Trident WesternGeco M/V OBC- WesternGeco American Explorer PGS Drop down menus (Action Lists) Time Line File Edit View Setup Window Help Schedule Booking Org Units Gulf of Mexico (NSA) Phases (w/ vessel asigned) 9466 (NEPS) (BP) EAG EAG EAG PGS MRL 952 (Texaco) BLF ATL Australasia (ASA) Figure : GUI Schedule Page 64 of 93

165 4.3.2 BCE Analysis BookingEditor. Book tender/lead 2. Update booking status Sales 5. Reschedule job Introspection 5. Import from global schedule 6. Export to global schedule GlobalScheduleService 7a. View local schedule Figure 2: Booking Editor use cases The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the combined analysis of use-case, 2, 5, 7a, 5 and 6 shown in Figure 2. The result of the BCE analysis is shown in the diagram below. Page 65 of 93

166 Login LoginController Access New AvailabilityController VesselAvailability Open Preferences Save Notify Bookings Schedule BookingController Confirm JobForm VesselSelect SWO Print SynchronizeController Report GlobalSynchronizer Figure 3: Booking Editor BCE analysis diagram A description of the BCE classes in given in the table below: BCE class BookingController LoginController AvailabilityController SynchronizeController Description The Booking Controller is the main controller for performing these use-cases. In the process it uses a few other controllers. The Login Controller controls the entire login process. The user will enter username and password through the class Login and the class Access represents the access authorization. The Availability Controller controls the process of obtaining a list of the vessels best suited for a job. The class Vessel Availability represents the data needed for this process. The Synchronize Controller controls the process of importing data from and exporting data to the global master schedule. Page 66 of 93

167 New Open Save Print Report VesselSelect Schedule JobForm SWO Bookings Preferences To create a new schedule, save a schedule and open a previously made schedule the classes New, Open and Save are used. These are simple dialog box type classes. Other simple dialog box classes are Print, Report and Vessel Select. Print will allow the user to specify the parameters used for creating a printed version of the schedule. 'Report' will allow the user to select among the different forecast and marketshare reports available. Vessel Select will allow the user to select among the vessels the Availability Controller has found to be good candidates for the job. The Schedule is the main user interface. Figure shows how this component will look. The other main user interface are the JobForm and the SWO which are the editors for the bookings and Seismic Work Order. The entity Bookings represents both the locally stored schedules and the global master schedule. The entity Preferences represents the users default parameters. Such parameters are which vessels he/she normally includes in the schedules and the time frame used. These BCE classes can be used in a further analysis of the use cases, in which sequence diagrams are used to describe the fulfilment of the use case scenarios. Examples of such diagrams are given below. Figure 4 and Figure 5 show sequence diagrams for use case, Figure 6 shows a sequence diagram for use case 2, and Figure 7 shows a sequence diagram for use case 7a. Page 67 of 93

168 4.3.3 Use case : Book tender/lead Primary scenario i0:sales i:bookingcontroller i2:logincontroller i3:login i4:access i5:schedule i6:preferences i7:new i8:synchronizecontroller i9:globalsynchronizer i0:bookings i:jobform i2:vesselavailability i3:vesselselect i4:save i5:notify {. Login and authorize} Start system Validate user Get login parameters Identify Authenticate Initialize {2. Create new schedule} Create new schedule Create new schedule Get preferences Get schedule parameters (default = preferences) Specify Create {3. Synchronize with global schedule} Import from global master schedule Import Get global data Get import parameters Select vessels Get data Update {4. Fill in job form} Create new booking Create new booking Create new booking Enter values in required fields {5. Select vessel} Select vessel Select vessel Get prioritized list Show list Select {6. Create booking in private schedule} {7. Save} Save Update Save Get filename Specify Save {8. Export to global schedule} Export to global master schedule Export Export Get export parameters Select vessels and bookings Export data {9. Notify interested parties} Notify Figure 4: Book tender/lead sequence diagram for primary scenario Page 68 of 93

169 Alternative scenario C i0:sales i:bookingcontroller i2:logincontroller i3:login i4:access i5:bookings i6:jobform i7:vesselavailability i8:vesselselect i9:notify {. Login and authorize} Start system Validate user Get login parameters Identify Authenticate Initialize {2. Fill in job form} {3. Select vessel} Enter values in required fields Select vessel Select vessel Get prioritized list Show list {4. Print schedule} Update Select {5. Create global booking in global schedule} Create global booking Create global booking Create global booking {6. Notify interested parties} Notify Figure 5: Book tender/lead sequence diagram for alternative scenario C Page 69 of 93

170 4.3.4 Use case 2: Update booking status Primary scenario i0:sales i:bookingcontroller i2:logincontroller i3:login i4:access i5:schedule i6:open i7:confirm i8:synchronizecontroller i9:globalsynchronizer i0:bookings i:jobform i2:vesselavailability i3:vesselselect i4:save i5:notify {. Login and authorize} Start system Validate user Get login parameters Identify Authenticate Initialize {2. Open schedule} Open schedule Open schedule Get filename and location Specify Get data Create Update {3. Synchronize with global schedule} Import from global master schedule Import Get global data Select vessels Get data Update {4. Select booking} Select booking for modification Edit Edit {5. Update info} {6. Change status} {7. Change time} Update Select vessel Select vessel Get prioritized list Show list Select Update {8. Save} Save Save Get filename Specify Save {9. Export to global schedule} Export to global master schedule Export Export Get export parameters Select vessels and bookings Export data {0. Ask for confirmation} {. Notify interested parties} Confirm Notify Figure 6: Update booking status sequence diagram for primary scenario Page 70 of 93

171 4.3.5 Use case 7a: View schedule Alternative scenario A i0:sales i:viewschedulecontroller i2:logincontroller i3:login i4:access i5:schedule i6:open i7:synchronizecontroller i8:bookings i9:print {. Login and authorize} Start system Validate user Get login parameters Identify Authenticate {2. Select vessels and period} Specify vessels and timeframe Specify Get global data Get data {3. Show schedule} {4. Print schedule} Print schedule Create Update Print Get print parameters Specify Print schedule Figure 7: View schedule sequence diagram for alternative scenario A BCE to Class Mappings «Panel» GanttDiagram «Scrollbar» Hscroll & Vscroll «Panel» TimeLine «Frame» ExportAndOverwriteDialog «Frame» Schedule «Frame» ExportDialog «Frame» ImportDialog Design Model Login New Open Save Schedule JobForm VesselSelect Print SWO GlobalSynchronizer Analysis Model Design Model Editor Manager «Frame» PrintDialog «Frame» LoginDialog «Frame» OpenDialog «Frame» PropertyEditor «Frame» VesselSelectDialog «Frame» NewDialog «Frame» SaveDialog «Frame» ModHistory Figure 8: Booking Editor client class diagram from analysis Page 7 of 93

172 The diagram shows the mapping from the BCE analysis model to class design model Internal Class Design UI UserService <<frame>> LoginDialog <<frame>> OpenDialog <<panel>> <<scrollbar>> GanttDiagram HS croll_vs croll <<frame>> Schedule <<frame>> <<frame>> SaveDialog PrintDialog <<panel>> TimeLine <<Entity>> IActivity <<Entity>> IProject <<Entity>> IOrgUnit <<Auxiliary>> ScheduleData <<Auxiliary>> UserPreference <<frame>> NewDialog <<Focus>> EditorManager IUserService <<Focus>> UserS ervice <<frame>> VesselSelectDialog <<frame>> ExportAndOverwriteDialog <<frame>> PropertyEditor ConfigurationService <<frame>> ExportDialog <<frame>> ImportDialog <<frame>> ModHistory IConfigurationService <<Focus>> ConfigurationService Figure 9: Booking Editor internal design The diagram shows the static relationship between the various implementation classes in the design model. The classes are the same as identified in Figure 8. The relationship to the User Service is also shown. This will be handled through an interface IUserService. The User service will manage a set of user preferences. The service will handle a set of local schedules. The system will be able to simultaneously open a set of schedules and switch between them. The generic model for the schedules is based on the Activity Info model. The ConfigurationService provides layout information and data type information used by the PropertyEditor. The PropertyEditor is a general editor used to edit any dataset of type PropertyList. The types IActivity, IProject and IOrgUnit will all inherit from this type. 4.4 The Booking Viewer Tool Design 4.4. Graphical User Interface The client shall support a graphical user interface similar to that of the Booking Editor tool and shown in Figure. As many components and structures as possible should be reused from that tool. However, the Booking Viewer tool should be as lightweight as possible so dependencies to unused code are undesirable. The tool shall use the other lightweight tools (Booking Creator, Booking Modifier) to achieve the functionality of viewing, modifying the bookings in the global schedule. Page 72 of 93

173 4.4.2 BCE Analysis Sales BookingViewer 7b. View global schedule Operations GlobalScheduleService Marine Management Figure 20: Booking Viewer use cases The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 7b, shown in Figure 20. The result of the BCE analysis is shown in the diagram below. Login LoginController Access Open Schedule ViewS chedulecontroller Bookings Print SynchronizeController Figure 2: Booking Viewer BCE analysis diagram Page 73 of 93

174 A description of the BCE classes in given in the table below: BCE class BookingController ViewScheduleController LoginController SynchronizeController Open Print Bookings BCE to Class Mappings Description The Booking Controller is the main controller for performing these use-cases. In the process it uses a few other controllers. The View Schedule Controller is the main controller for performing these usecases. In the process it uses a few other controllers. The Login Controller controls the entire login process. The user will enter username and password through the class Login and the class Access represents the access authorization. The Synchronize Controller controls the process of importing data from the global master schedule. To open a schedule containing the desired vessels and the correct time frame, a simple dialog box type class Open is used. The Print class is also a dialog box type, which will allow the user to specify the parameters, used for creating a printed version of the schedule. The entity Bookings represents in this case the global master schedule. This section will discuss details regarding the Booking Viewer client tool. «Panel» GanttDiagram «Scrollbar» Hscroll & Vscroll «Panel» TimeLine Design Model «Frame» Schedule Login Open Schedule Print Analysis Model Design Model «Frame» LoginDialog «Frame» NewDialog View Manager «Frame» PrintDialog Figure 22: Booking Viewer client class diagram from analysis The 'Open' class in the analysis model is transformed into the 'New Dialog' class in the design model. The objective of the 'Open' class is to specify a set of vessels and a time frame, which is the same as the 'New' class in the analysis model of the Booking Editor. Page 74 of 93

175 4.4.4 Internal Class Design UserService UI <<panel>> GanttDiagram <<scrollbar>> Hscroll_Vscroll <<frame>> ScheduleLite <<panel>> TimeLine <<Entity>> IActivity <<Entity>> IProject <<Entity>> IOrgUnit <<frame>> PrintDialog <<Auxiliary>> ScheduleData <<frame>> LoginDialog <<frame>> NewDialog <<Focus>> ViewManager IUserService <<Focus>> UserS ervice <<Auxiliary>> UserPreferences Figure 23: Booking Viewer internal design The diagram shows the static relationship between the various implementation classes in the design model. The classes are the same as identified in Figure 22. The relationship to the User Service is also shown. This will be handled through an interface IUserService. 4.5 The Subscription Editor Tool Design 4.5. BCE Analysis Sales SubscriptionEditor 2. Subscribe to notification Marine Management SubscriptionService Operations Figure 24: Subscription Editor use cases The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 2, shown in Figure 24. The result of the BCE analysis is shown in the diagram below. Page 75 of 93

176 Login LoginManager LDAP S ubscription NotificationManager MailService DatabaseManager Notification S ubscriptionmanager SubscriptionDatabase Figure 25: Subscription Editor BCE analysis diagram Figure 25 shows the result of the BCE analysis for the Subscription Editor Internal Class Design UI <<panel>> SimpleGridPanel UserService <<Focus>> <<Focus>> <<panel>> SubscriptionClient IUserService UserS ervice SimpleBorder Figure 26: Subscription Editor internal design Figure 26 shows the internal design for the Subscription Editor. The relationship to the User Service is also shown. This will be handled through an interface IUserService. Page 76 of 93

177 4.6 The Booking Service Business Service Design 4.6. BCE Analysis GlobalScheduleService. Add/remove vessels 0. Add/remove users & rights Administrator BookingEditor 7. Synchronize and save schedule SubscriptionService 8. Assemble and deliver schedule BookingViewer ActivityInfo Figure 27: Booking Service use cases The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 7 and 8 shown in Figure 27. The result of the BCE analysis is shown in the diagram below. Notify NotificationController S ubscriptions Import GlobalScheduleController ActivityInfo BookingController Bookings Export Figure 28: Booking Service BCE analysis diagram Page 77 of 93

178 4.6.2 Internal Class Design BookService SubscriptionService <<Focus>> <<Focus>> IBookingService BookingService INotify NotifyManager BookingData <<Entity>> <<Entity>> Phase Survey <<Entity>> <<Entity>> <<Entity>> Vessel Company SubRegion <<Focus>> <<Entity>> IActivityInfo BookingData BusinessRegion Figure 29: Booking Service internal design The diagram shows the static relationship between the various implementation classes in the design model. The diagram also shows that all layers will be accessed through an interface to provide for separation of concern. The BookingData is accessible through the IActivityInfo interface, which will be provided by the ActivityInfo resource service. The booking data consists of vessels, companies, surveys, phases, business regions and subregions as described in the Business Model. The mapping of these business resources to the Activity Info model is shown in the diagram below. OrgUnit Vessel Company BusinessRegion SubRegion Project Survey Phase Figure 30: Business Resource mapping to Activity Info Model for booking data Page 78 of 93

179 4.7 The Subscription Service Business Service Design 4.7. BCE Analysis SubscriptionService Administrator 20. Update list of available subscriptions 2. Save/remove subscriptions SubscriptionEditor SubscriptionInfo 9. Check for subscriptions & notify GlobalScheduleService Server Figure 3: Subscription Service use case diagram The analysis model uses a stereotype diagram and shows the static relationship between boundary classes (in our cases GUI classes), controller classes and entity classes (data). The model reflects the analysis of use-case 9 and 2 shown in Figure 3. The result of the BCE analysis is shown in the diagram below. S ubscription NotificationManager MailS ervice DatabaseManager Notification SubscriptionManager SubscriptionDatabase Figure 32: Subscription Service BCE analysis diagram Page 79 of 93

180 4.7.2 Internal Class Design SubscriptionService INotify <<Focus>> NotifyManager <<Auxiliary>> SendMail ISubscription <<Auxiliary>> DBAccess SMTP SubscriptionInfo ISubscriptionInfo <<Focus>> S ubscriptionmanager <<Entity>> S ubscription Figure 33: Subscription Service component design The diagram shows the static relationship between the various implementation classes in the design model. The diagram also shows that all layers will be accessed through an interface to provide for separation of concern. The SubscriptionInfo is accessible through the ISubscriptionInfo interface, which provides the subscription data. 4.8 EJB Implementation This section describes the experiences gained with EJB technology as a result of implementing selected parts of the Survey Booking Application in EJB. This implementation phase has tested both ) EJB. on IONA s iportal Application Server, and 2) EJB 2.0 on Sun s J2EE.3 Reference Implementation Servlet Implementation In order to extend the Survey Booking Application with EJB, it is important to have a clear understanding of the original implementation so that extension points where EJB fits in nicely can be identified. One important requirement with regards to this was to keep the original reference implementation unaffected, and to be able to run both the Servlet and the EJB implementation simultaneously. Page 80 of 93

181 BookingEditor UI IUserService UserService Web ILogin IBookingService BookingService LDAP IActivityInfo SLB directory ActivityInfo Archive Booking data Figure 34: Survey Booking Application component architecture The deployment diagram above shows the scope chosen for the EJB implementation. Two target components, namely the BookingService and the ActivityInfo components, were identified as suitable EJB components. The implementation of these two components was done in two iterations: Implementation of an EJB version of the BookingService Implementation of an EJB version of the ActivityInfo In addition to these two iterations, two other iterations were introduced, targeting both the EJB. and EJB 2.0 platform for the implementation of the ActivityInfo component Servlet communication The communication details between the UserService component and the BookingService component is further elaborated in this section. ::gp::servletgen::tunnel::tunnelclient ::gp::servletgen::tunnel::tunnelserver surveybooking::com::bookingserviceproxy surveybooking::com::bookingserviceservletstub getusername() getuser address() importschedule() exportschedule() _getnewinstance() _invokemethod() surveybooking::server::bookingservice::bookingservice Figure 35: Design of servlet communication The class diagram above shows the design for the servlet communication. The design makes use of the proxy and the delegation patterns. The WesternGeco servlet generation tools creates a Proxy class that is used by the UserService component, and a Stub class that is Page 8 of 93

182 configured on the server that delegates method invocations to the actual BookingService component. ClientHost: :UserService: BookingServiceProxy: TCP/IP HTTP-tunneling ServerHost: :ServletEngine: BookingServiceServletStub: Java :BookingService: Figure 36: Deployment of servlet communication The deployment instance diagram above shows the actual instances involved during the servlet communication. Two hosts, the client and the server, communicate using the TCP/IP protocol. The BookingServiceProxy and the BookingServiceServletStub communicates through HTTP-tunneling. The BookingServiceServletStub and the BookingService component communicate using plain Java method invocations BookingServiceEJB implementation The first iteration consisted of developing an EJB version of the BookingService component. BookingEditor UI IUserService UserService Web ILogin LDAP IBookingServiceRemote BookingServiceEJB IBookingService BookingService IActivityInfo Archive SLB directory ActivityInfo Booking data Figure 37: BookingServiceEJB component architecture Page 82 of 93

183 The deployment diagram above shows the introduction of the new BookingServiceEJB component in the application architecture of the Survey Booking. As can be seen from the diagram, the original BookingService component is unaffected Servlet communication In addition to the BookingServiceEJB component, we also needed to introduce a new servlet configuration for the EJB component. ::gp::servletgen::tunnel::tunnelserver ::gp::servletgen::tunnel::tunnelclient <<comment>> URL surveybooking::com::bookingserviceproxy getusername() getuser address() importschedule() exportschedule() surveybooking::com::bookingserviceservletstub _getnewinstance() _invokemethod() surveybooking::server::bookingservice::bookingservice <<comment>> URL2 surveybooking::com::bookingserviceejbservletstub _getnewinstance() _invokemethod() surveybooking::server::bookingservice::bookingserviceejb Figure 38: Revised design of servlet communication The class diagram above shows the revised design for the servlet communication. No changes were made to the Proxy class, so the client-side is unaware of any EJB server-side modifications. In order to run both BookingService versions simultaneously a new Stub class, BookingServiceEJBServletStub, was created for the EJB component. The Proxy class takes a URL parameter input in its constructor that decides which Stub class is being used. The BookingServiceEJBServletStub only differs in respect to the original Stub class in how it instantiates the actual server object. public Object _getnewinstance(string remoteuser) throws ServletException {... IBookingServiceRemote remote = null; try { Context initial = new InitialContext(); Object obj = initial.lookup("bookingserviceejb"); IBookingServiceHome home = (IBookingServiceHome)PortableRemoteObject.narrow(obj, IBookingServiceHome.class); remote = home.create(props); } catch (Exception ex) { System.err.println("BookingServiceEJBServletStub: " + ex.getmessage()); ex.printstacktrace();; } } return remote; The code listing above illustrates how JNDI is used to create a reference to a remote EJB session bean that implements the BookingService business logic. Page 83 of 93

184 ClientHost: :UserService: BookingServiceProxy: TCP/IP HTTP-tunneling ServerHost: :ServletEngine: BookingServiceServletStub: BookingServiceEJBServletStub: Java :BookingService: RMI :EJBContainer: :BookingServiceEJB: Figure 39: Revised deployment of servlet communication The deployment instance diagram above shows the revised deployment instances. The BookingServiceEJBServlet stub communicates using RMI with the BookingServiceEJB contained in an EJBContainer (within an EJB Application Server) BookingServiceEJB design In order to make use of the current business logic implementation, the EJB bean was designed using the delegation pattern wrapping the original BookingService component. <<interface>> Java-BusinessInterface <<interface>> BusinessObject EJB-RemoteInterface <<interface>> EJB-HomeInterface EJB-Bean Java-BusinessImplementation <<comment>> Delegates to actual business implementation Figure 40: Design pattern for wrapping EJBs The class diagram above shows the design pattern used when developing the EJB wrapper component. The EJB bean implements the Java business interface. This approach allows for compile-time checking, since the EJB remote interfaces are only checked with naming conventions during deployment time. Furthermore, the EJB bean has an association to a business interface that it uses to forward method invocations to an instantiated business implementation object. Page 84 of 93

185 surveybooking::server::bookingservice::bookingserviceabstract #database 0.. ::activityinfo::iactivityinfo <<interface>> surveybooking::com::ibookingservice surveybooking::server::bookingservice::bookingservice -_serviceimpl0.. surveybooking::server::bookingservice::bookingserviceejb ::javax::ejb::ejbhome ::javax::ejb::sessionbean surveybooking::com::ibookingservicehome ::javax::ejb::ejbobject +create(inout props:properties):ibookingserviceremote surveybooking::com::ibookingserviceremote getusername() getuser address() importschedule() exportschedule() Figure 4: Detailed design of BookingServiceEJB The class diagram above shows the detailed design of the BookingServiceEJB session bean class. The bean class has dependencies to its two EJB interfaces, and a relationship to the BookingService implementation class Deployment on IONA iportal 3.0 Application Server The BookingServiceEJB was configured as an EAR application and deployed on the IONA iportal 3.0 Application Server, which has been chosen as the technical EJB platform in the COMBINE project. The iportal Application Server ships with server tools for deployment. Two of the tools used are: Application Administrator: This tool supports building EJB JAR files and EAR application files. Graphical Application Builder: This tool supports configuration of EJBs and EARs. Page 85 of 93

186 Figure 42: Application Administrator The figure above shows two views of the Application Administrator tool. View one shows how one can create or add EJB JAR files, and the second view shows an editor for the deployment descriptor for the EJB container. <?xml version=".0" encoding="cp252"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans. //EN' ' <ejb-jar> <display-name>bookingservicejar</display-name> <enterprise-beans> <session> <description>the initial values for this EJB have been deduced automatically.</description> <display-name>bookingserviceejb</display-name> <ejb-name>bookingserviceejb</ejb-name> <home>marine.surveybooking.com.ibookingservicehome</home> <remote>marine.surveybooking.com.ibookingserviceremote</remote> <ejb-class>marine.surveybooking.server.bookingservice.bookingserviceejb</ejb-class> <session-type>stateful</session-type> <transaction-type>bean</transaction-type> </session> </enterprise-beans> <assembly-descriptor /> </ejb-jar> The XML listing above shows the deployment descriptor for the BookingServiceEJB session bean. Page 86 of 93

187 Figure 43: Graphical Application Builder The figure above shows a view of the Graphical Application Builder in which one can administrate references between and configure the various bean s deployment settings ActivityInfoEJB implementation The second iteration consisted of developing an EJB version of the ActivityInfo component. BookingEditor UI IUserService UserService Web ILogin LDAP IBookingServiceRemote BookingServiceEJB IBookingService BookingService IActivtyInfoLocal/Remote IActivityInfo Archive SLB directory ActivtyInfoEJB ActivityInfo Booking data Figure 44: ActivityInfoEJB component architecture Page 87 of 93

188 The deployment diagram above shows the introduction of the new ActivityInfoEJB component in the application architecture of the Survey Booking. The BookingServiceEJB component was modified so that a property decided whether it communicated with the ActivityInfo component or the new ActivityInfoEJB component. This allowed us to test the three different configurations of the implementation at run-time Servlet communication We introduced a new servlet configuration for the ActitivyInfoEJB component. ::gp::servletgen::tunnel::tunnelserver ::gp::servletgen::tunnel::tunnelclient <<comment>> URL surveybooking::com::bookingserviceproxy getusername() getuser address() importschedule() exportschedule() surveybooking::com::bookingserviceservletstub _getnewinstance() _invokemethod() surveybooking::server::bookingservice::bookingservice <<comment>> URL2 URL3 surveybooking::com::bookingserviceejbservletstub _getnewinstance() _invokemethod() surveybooking::server::bookingservice::bookingserviceejb <<comment>> PROP=TRUE <<comment>> PROP=FALSE ::activityinfo::ascii::activityinfoasciifile ::activityinfo::ascii::activityinfoasciifileejbwrapper Figure 45: Revised design of servlet communication The class diagram above shows the new revised design for the servlet communication. Another legal URL parameter was configured for the BookingServiceEJBServletStub class. A boolean servlet property is associated with the two servlet configurations, so that the chosen URL decides which version of the ActivityInfo component implementation to use. Page 88 of 93

189 ClientHost: :UserService: BookingServiceProxy: TCP/IP HTTP-tunneling ServerHost: :ServletEngine: BookingServiceServletStub: BookingServiceEJBServletStub: Java :BookingService: Java :ActivityInfo: RMI :EJBContainer: :BookingServiceEJB: Java / RMI :ActivityInfoEJB: Figure 46: Revised deployment of servlet communication The deployment instance diagram above shows the revised deployment instances for the ActivityInfo components. The BookingServiceEJB and the ActivityInfoEJB is located in the same EJBContainer ActivityInfoEJB design In order to make use of the current business logic implementation, the EJB bean was designed using the delegation pattern wrapping the original ActivityInfo component. However, since the ActivityInfo component is passed as a reference to other components, a simple wrapper was not enough to integrate the new component transparently in the existing codebase. We also needed to wrap the EJB interfaces, so that only pure Java interfaces were exposed. <<interface>> EJB-RemoteInterface <<comment>> Delegates to EJB bean implementation BeanObject EJB-BeanWrapper <<interface>> Java-BusinessInterface BusinessObject <<interface>> EJB-HomeInterface EJB-Bean Java-BusinessImplementation <<comment>> Delegates to actual business implementation Figure 47: Design pattern for double-wrapping EJBs Page 89 of 93

190 The class diagram above shows the design pattern used when developing the EJB doublewrapper component. The EJB wrapper implements the Java business interface and has an association to a bean interface, which it uses to delegate method calls to the bean implementation. The bean itself, delegates the calls to the actual business implementation object, following the simple wrapping pattern described in the BookingServiceEJB section above ActivityInfoEJB with remote interfaces The first implementation iteration for the ActivityInfoEJB component was targeted on EJB. technology using remote interfaces. However, this attempt proved unsuccessful. The following sums up our experiences with regards to this attempt: The ActivityInfo component represents a persistent activity graph with elements of type OrgUnits, Projects, Report and Activities: o A simple EJB-wrapper implementation for EJB. failed with numerous CORBA exceptions. Debugging efforts gave the following explanation: o EJB. uses RMI on local objects within the same JVM. The consequence of this is that RMI marshalling/demarshalling must be done when we pass the reference to the ActivityInfo activity graph. Since the activity graph contains recursive references, the RMI marshalling/demarshalling failed. The solution to this problem was to:. Completely rewrite the ActivityInfo implementation so that it conforms to the EJB. standard. 2. Attempt to use local interfaces supported in EJB 2.0 on Sun s J2EE.3 reference implementation. Because of the poor performance results of the BookingServiceEJB implementation, alternative was discarded. We felt that it was much better to gain experience with the EJB 2.0 standard, which adds support for local interfaces and relationship fields ActivityInfoEJB with local interfaces The second implementation iteration was targeted on EJB 2.0 technology using local interfaces. The ActivityInfoEJB component was implemented using an ASCII file mapping for the persistent storage. Page 90 of 93

191 IActivityInfoLocal ::javax::ejb::ejblocalobject <<interface>> IActivityInfo committransaction() createorgunit() createproject() createproject() createactivity() createreport() createreport() createpropertylist() addreportactivity() removereportactivity() createparameterset() createparameterset() createreport() loginok() begintransaction() activetransaction() aborttransaction() addorgunit() removeorgunit() getorgunits() getorgunits() getorgunit() getorgunittypes() getorgunitnames() ::javax::ejb::ejblocalhome ascii::activityinfoasciifileejbwrapper IActivityInfoLocalHome create() 0.. create() -_serviceimpl ascii::activityinfoasciifileejb 0.. -_serviceimpl ::javax::ejb::sessionbean ascii::activityinfoasciifile Figure 48: Detailed design of ActivityInfoEJB The class diagram above shows the detailed design of the ActivityInfoAsciiFileEJB session bean class. The bean class has dependencies to its two EJB interfaces, and a relationship to the ActivityInfoAsciiFile implementation class. An ActivityInfoAsciiFileEJBWrapper class wraps the bean implementation and exposes only the IActivityInfo business interface Deployment on Sun J2EE.3 Reference Implementation Since the IONA iportal 3.0 Application Server does not support the EJB 2.0 standard, we were forced to try another product. Sun provides a free reference implementation of the J2EE.3 standard which incorporates EJB 2.0. The BookingServiceEJB and ActivityInfoEJB were configured into one EAR application and deployed on Sun J2EE SDK.3. The J2EE SDK.3 ships with a server deployment tool: Application Deployment Tool: This tool supports building and configuring EJB JAR files and EAR application files. Page 9 of 93

192 Figure 49: Application Deployment Tool Building an EAR The figure above shows a view of the tool in which one can create EJB jar files and add them to an EAR application. A SurveyBookingEAR application was created consisting of the two BookingServiceEJB and ActivityInfoEJB components. Figure 50: Application Deployment Tool Configuring an EJB Page 92 of 93

193 The figure above shows a view of the tool in which one can configure an EJB. As can be seen, the tool supports both remote and local interfaces. Figure 5: Application Deployment Tool Remote deployment The figure above shows a view of the tool in which one can remotely deploy EAR applications on a target server. Page 93 of 93