INF520 Modellbasert systemutvikling COMET Business Modelling COMET Requirements Modelling Forelesning 2.03.2007 Brian Elvesæter brian.elvesater@sintef.no COMET Business Modelling with WesternGeco Survey Booking Reference Example
Sales & Planning Vessel Schedule W ork Order Exec. Monitoring Seismic Acquisition Vessel Op eratio n Prod. stat istics Do wntim e stat. Op. Mgr NCR Reporting & Monitoring Support Engineering Registrator Secretariat application ClubRegister ObtainClubInfoand deliver to registeringprocessor ExistingClubInfo Edit and accept existingclubinfo Club registration Information AskClubRegisterto check if Club already exists Existi ngclubinfo Ask to edit and confirm existing ClubInfo Ask to register Club [Club Exists] Check if Club exists [Club do not Exists] Add Club Registrator Secretariat application ClubRegister ObtainClubInfoand deliver to registeringprocessor ExistingClubInfo Edit and accept existingclubinfo Club registration Information AskClubRegisterto check if Club already exists Existi ngclubinfo Ask to edit and confirm existing ClubInfo Ask to register Club [Club Exists] Check if Club exists [Club do not Exists] Add Club : Registrator registerclub : Secretariat Application clubexists registerclub : ClubRegister : Registrator registerclub : Secretariat Application : ClubRegister clubexists registerclub Arnor er en kul type Dette er et forsøk på å fylle denne kommenten med text Model world Real world Context Business 0, model Goal Model Business model Goal Model Context statement Business Resource Model 0, Context statement Business Resource Model Vision for change Risk analysis Business Process & Role Model Vision for change Risk analysis Requirements model Prototype Other requirements Business Process & Role Model WARM Work Element Analysis Model System Boundary Use case Scenario Model Concepts& Artifacts Processes Actors Business Domain Busines domain to system domain mapping Subsystem grouping and BCE (Combine Ref Arch) BM analysis BCE Model Architecture model Workflow Service Domain Component structure and internal design Interface and interaction specification Platform specific model UMT Config model Component implementation model PIM Data Types 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 System Domain Deployment Business Model (What and why) Requirements Model (What) Prototypes Context statement Goal Model Business process model Business Resource model System Boundary Model Use case scenario Model Other requirements Arnor er en kul type Dette er et forsøk på å fylle denne kommenten med text Vision for change Risk analysis Work Analysis Refinement Architecture Model (How) Subsystem Subsystem 2 BCE Model Iterative & Incremental Subsystem4 Subsystem3 Component structure model Component interaction model Interface & Information Model Problem domain Solution domain Platform Specific model (HowSolution) Platform profile model Applications Business components General components OS HW Component Implementation Model 2
Business Model 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. 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. Business Metamodel Structuring Concepts Basic Business modelling concepts Profiling model Work Analysis Refinement Concepts 3
Structuring concepts 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 Model structure for the Business model 4
Modelling concepts Enabled by.. Goal met by to meet Enabling behaviour objective of...... subgoals.. has.. executes behaviour of.... constrains Community constrained by constrained by Behavioural Policy represents Business Process 0.. constrains has resources model of constrains Business Rule.. constrained by resource in modelled as 0.. constrains.. modelled as 0.. Resource Resource in Role.... Step affected by actor for performed by is generated by affects generates.. constrained by identifier for Event Artifact Resource Actor Resource fulfils fulfilled by Role...... identified by results in resource subject for recipient.... sender.. concerns.. issued to received by artifact Resource as Artefact represented information flow artifact in Business Message result of UML profile for business modelling 5
Survey Booking Reference Example 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 surveybooking 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. High-Level System Boundary 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. 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. 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 Operations Sales SurveyBooking Support Introspection Administrator 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. 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. A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. 6
Subsystem Grouping BookingEditor. Book tender/lead Introspection GlobalScheduleService 7a. View local schedule 5. Reschedule job 8. Assemble and deliver schedule 2. Update booking status 7. Synchronize and save schedule ActivityInfo Sales 5. Import from global schedule 0. Add/remove users & rights 6. Export to global schedule. Add/remove vessels BookingViewer Administrator 7b. View global schedule SubscriptionService Marine Management SubscriptionEditor 9. Check for subscriptions & notify 20. Update list of available subscriptions SubscriptionInfo 2. Subscribe to notification Operations 2. Save/remove subscriptions Component Structure Bus Pattern BookingEditor BookingViewer SubscriptionEditor Component Infrastructure BookingService SubscriptionService ActivityInfo S ubscriptioninfo 7
Scoping statements The context statement, which defines the scope and positions this business model in its context. 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. Risk analysis, which identifies the business and technical risks related to a development project for the proposed Product. Context statement 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. 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. 8
Roles Organisation and Process roles Sales Support Introspection Operations Maritime Manager Administrator Client Technical Manager System Operator Reviewer QC-Rep Technical Support Operation Management Data Processing Legal Marketing Corporate Manager Oil Company Operation Manager Secretary Sales Manager Scope and stakeholders <<summary>> Liase with sales Issues tender Issue award/loss <<summary>> Client contacts Marketing Global fleet plan <<summary>> Liase with client Coordinate review review Compile tender Monitor vesel availability M onitor competitor activity <<summary>> Marketing <<summary>> Review work specifications Propose technical solutions Oil Company Corporate M anager AccountM anager Marketing Technical Support Operation Management <<summary>> Review operational risks Data Processing <<summary>> Monitor marine activity OBP proposals Marine acquisition Legal <<summary>> Review contract Assess risk Insurance Maritime Manager <<summary>> Produce a timeliy, quality image service to help clients find, produce and manage oil assets. <<summary>> Optimize revenue Position vessels Upgrade vessels Report 9
Tender Bid Context Diagram :Sales & Marine Management PreSales [qualified bid] [no bid] <<ResourceAsArtefact>> :ITT :Operations Tender Bid [won] [lost] <<ResourceAsArtefact>> :SWO Survey Preparation Survey Execution Survey Close Vision for change 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. 0
Vision for change (/2) 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 potential survey. Vision for change (2/2) 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
Goal Model 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. The Goal Model is discovered by a process of workshops and interviews involving all stakeholders (as identified in development of the Context Statement). Goals must be achievable, preferably measurable, and not selfevident, 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. Goal Model 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 2
Business Resource Model 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. 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. Object flows in the activity diagrams are candidates for business resources. Business Resources LocalS chedule GlobalSchedule 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 3
Business Process & Role Model Purpose 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). Methods and Techniques The Business Process Model is derived through a set of activities that encompass brain-storming sessions, structured workshops, interviews and feed-back sessions, and detailed modelling using a UML tool. Work Element Analysis (WARM) 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. 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. 4
Tender Bid Process Overview Receive ITT & Prepare for bidding [continue] Make Tender [continue] [stop] [stop] Submit Tender 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 [Cancel bid] {End of survey booking} 5
Make Tender :AccountManager {Surve Costin Survey Costing {Oth tool} Distribute ITT for review :Manager :Reviewer 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} 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 6
Process and goal structure Sound cost estimates Win profitable bids <<achieves>> <<achieves>> Sales Oil Company Tender ITT Tender Bid Plan Survey costing Tender compilation COMET Requirements Modelling with WesternGeco Survey Booking Reference Example 7
Model world Real world Context Business 0, model Goal Model Business model Goal Model Context statement Business Resource Model 0, Context statement Business Resource Model Vision for change Risk analysis Business Process & Role Model Vision for change Risk analysis Requirements model Prototype Other requirements Business Process & Role Model WARM Work Element Analysis Model System Boundary Use case Scenario Model Concepts& Artifacts Processes Actors Business Domain Busines domain to system domain mapping Subsystem grouping and BCE (Combine Ref Arch) BM analysis BCE Model Architecture model Workflow Service Domain Component structure and internal design Interface and interaction specification Platform specific model UMT Config model Component implementation model PIM Data Types 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 System Domain Deployment Use Case Model The Use Case Model describes the system in terms of Actors use cases scenario descriptions It is defined a use case template to be used as a vehicle for developing the use case model. Non functional requirements are 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 applies for the whole system are associated with the system boundary which is also included in the use case model. 8
Purpose of Use Case Model Capture system requirements Specify system behavior as Use Cases Set the system boundary Specify system environment as Actors Describe interactions between System and Actors Drive system development process A Use Case specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to a particular actor. A Use Case is User visible User-meaningful Easy for a user to confirm (or change) Precise enough as specification 9
System Boundary Goals 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. Deliverables A high-level UML Use case diagram showing the system, the actors and the actors responsibilities. A detailed UML Use case diagram showing the system boundary, the actors and their main use cases. Each use case should be numbered for later reference. General extra requirements that applies for the complete system are associated with the System Boundary Survey Booking Example (/2) 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. 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. 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 Operations Sales SurveyBooking Support Introspection Administrator 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. 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. A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. 20
Survey Booking Example (2/2). Book tender/lead SurveyBooking 8. Automated schedule updates Introspection 2. Update booking status 2. Subscribe to notification 9. Notify Sales 3. Ask for confirmation 4. Confirm job Operations 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 4. View competitor input report(s). Add/remove vessels Support System Boundary: Methods and techniques (/2) Information gathering Sources Domain model Users and domain experts Users playing the roles denoted by identified actors Existing system/competing system 2
System Boundary: Methods and techniques (2/2) Identify the system boundary What is Inside the system: Use case(s) (this is what to create) What is outside the system: Actors (this is what to interface with) Identify actors Answer the following questions: Who uses the system? 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 preset times? Who starts and shut down the system? Examples: persons/roles, software systems, things/objects (hardware) networks, etc. Describe the actors responsibilities (short) 22
Identify use cases Go through the list of actors and identify what services they need to fulfil their obligations Answer the following Questions What services will the actor want to get from the system? Which events will the actor initiate and which events will the actor be interested in? Which events/notifications occur? (the notifications reaching the actor independent of his interest (e.g error notifications)) Use case Scenario Model Description The Use Case Scenario Model digs into the identified use cases and describes these in detail. A use case template is used as a vehicle for this detailing. Goal Capture and understand the requirements. Deliverables Detailed UML use case diagram and descriptions in accordance to Use case template Activities Fill in Use Case template 23
Use case template Use case <number> Use case <name> Each use case is identified for later reference. Priority Priority with respect to implementation, marked 0. Goal Actors Pre-conditions Description of the goal(s) for the use case, derived from the Goal Model in the Business Model. Description of the roles involved in the use case and their responsibilities. Description of the pre-conditions for the use case. Postconditions Façade Quality requirements Description of the post-conditions for the use case. Description of methods/operations that the system should provide to realize the use case. Description of extra requirements for this use case. Issues such as uptime, availability, security, performance, etc. can be recorded here. Scenario Description of the use case scenarios. This includes the primary scenario and related secondary scenarios. Description Step Action Step description. 2 Step 2 description. n Step n description. Quality / Non-functional requirements Non functional requirements Description of non functional requirements for this use case Consider: Performance Uptime Availability Security Scalability Distribution Reliability and more... 24
RA Analysis Description The Reference architecture analysis is the first step in modeling the architecture, representing an intermediate step between Business Domain Models and the architecture design. 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. Deliverables Detailed use case diagram with subsystem grouping. Updated use case descriptions following the use case template. First version of the Component Structure using the bus architecture pattern (Object Management Architecture pattern). Survey Booking Example BookingEditor. Book tender/lead Introspection GlobalScheduleService 7a. View local schedule 5. Reschedule job 8. Assemble and deliver schedule 2. Update booking status 7. Synchronize and save schedule ActivityInfo Sales 5. Import from global schedule 0. Add/remove users & rights 6. Export to global schedule. Add/remove vessels BookingViewer Administrator 7b. View global schedule SubscriptionService Marine Management SubscriptionEditor 9. Check for subscriptions & notify 20. Update list of available subscriptions SubscriptionInfo 2. Subscribe to notification Operations 2. Save/remove subscriptions 25
RA Analysis: Methods and techniques (/2) Recall the Reference Architecture with associated tiers and component types. Analyse the System Boundary part of the Use Case Model with regards to the Reference Architecture. The System Boundary correspond to the boundaries of the component of concern for the actual project, typically an 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. Divide the System Boundary Model into a set of subsystems. Each subsystem will cover a collection of the System Boundary use cases. 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, with reiterated versions of the use cases. RA Analysis: Methods and techniques (2/2) The actors are important when it comes to obtaining the most appropriate decomposition as they group related use cases. The subsystem grouping are related to the actors 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. The subsystems identified typically reflects Tool Components; Business Service Components; and Resource Service Components 26
Prototype Goals Reduce technical risk Reduce the possibility of user dissatisfaction Deliverables Prototype Activities Identify technical uncertainties Develop UI, get feedback from users Test the risky technical solutions Start prototyping early Useful for the common understanding Best way of communicating with end user? Useful for identifying more user requirements WesternGeco Survey Booking Reference Example 27
Survey Booking Reference Example 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 surveybooking 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. High-Level System Boundary 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. 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. 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 Operations Sales SurveyBooking Support Introspection Administrator 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. 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. A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. 28
Definition of actors 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. Marine management 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. 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. Detailed System Boundary. Book tender/lead 2. Update booking status SurveyBooking 8. Automated schedule updates 2. Subscribe to notification 9. Notify Introspection Sales 3. Ask for confirmation 4. Confirm job Operations 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 29
Subsystem Grouping BookingEditor. Book tender/lead Introspection GlobalScheduleService 7a. View local schedule 5. Reschedule job 8. Assemble and deliver schedule 2. Update booking status 7. Synchronize and save schedule ActivityInfo Sales 5. Import from global schedule 0. Add/remove users & rights 6. Export to global schedule. Add/remove vessels BookingViewer Administrator 7b. View global schedule SubscriptionService Marine Management SubscriptionEditor 9. Check for subscriptions & notify 20. Update list of available subscriptions SubscriptionInfo 2. Subscribe to notification Operations 2. Save/remove subscriptions Definition of subsystems Booking Editor 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. Booking Viewer The Booking-Viewer is a tool-component used by all actors. Subscription Editor The Subscription-Editor is a tool-component used by all actors. This component is a web-based client that gives the possibility to monitor (via email) different business-events (state-changes) in the booking schedule. Global Schedule Service The Global-schedule-service is a business-service-component that serves the Booking-Editor- and the Booking-Viewer tool-components. Subscription Service The Subscription-service is a business-service component that implements the server-side functionality of the Subscription-editor. 30
Booking Editor Component 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 UC: Book tender/lead Primary scenario 3
UC: Book tender/lead Alternative scenario Global Schedule Service Component GlobalScheduleService. Add/remove vessels 0. Add/remove users & rights Administrator BookingEditor 7. Synchronize and save schedule SubscriptionService 8. Assemble and deliver schedule BookingViewer ActivityInfo 32
UC7: Synchronize and save schedule Primary scenario Component Structure Bus Pattern BookingEditor BookingViewer SubscriptionEditor Component Infrastructure BookingService SubscriptionService ActivityInfo S ubscriptioninfo 33