IN-MMO Forelesning 20.02.2003 Brian Elvesæter briane@ifi.uio.no 1 Agenda Oblig 1b Presentation (Group 3 & 5) More UML Modelling Usability and UML Business Modelling Discussion COMET Business Model WesternGeco Survey Booking Reference Example More Objecteering/UML Questions and discussion 2 1
More UML Modelling Structural modelling Building blocks of UML Classes Attributes/Operations Associations Packages Extension mechanisms Behavioral modelling Use Cases Interactions Sequence diagrams Collaboration diagrams Statecharts Activity Diagrams 3 Packages in UML Geometry Package (from Logical View) + Accuracy + TopologicalGeometry + RepresentationalGeometry + TemporalGeometry + Geometry + Vector{dimension} + SpatialVector A mechanism to group related classes of a model. Packages dependencies summarize dependencies between classes of different Packages. Packages can contain other Packages. Can show the Class/Entities found in a given Package. 4 2
Packages, containment and dependency 5 Import X Y A B +C «import» +E -D X Y A B Y::C +C «import» Y::E +E -D The associations are owned by package X 6 3
Common Mechanisms Adornments: - Notes Extensibility mechanisms: (stereotypes, tagged value, constraint) Notes: Comments and constraints <<requirement>> Shall conform to. 7 Common Mechanisms: Stereotype, tagged values and constraints Stereotype <<interface>> Constraint and Comment {Person.employer = Person.boss.employer} << stereotype >> Subclass of existing modeling element - may have additional constraints and code generators will treat stereotyped element specially. Element properties, tagged value {author = Joe Smith, status = analysis} 8 4
Stereotypes Used to define derivative modeling concepts based on existing generic modeling concepts Defined by: base (meta-)class = UML meta-class or stereotype constraints required tags (0..) icon A model element can have at most one stereotype 9 Tagged values - properties Name (tag) separator (=) value (of the tag) properties on an element - relevant for code generation or configuration management (Can be applied to all UML elements) Server {processors = 3} Billing {version=3.2 status=checkedout by=ajb} 10 5
OCL - Object Constraint Language First order predicate logic, for boolean expressions - included in UML 1.1 Can be used for: invariants, value restrictions, pre and post conditions Person self.age > 0 Expressions with: and, or, not, implies, exists, forall, Collections (select, reject, collect, iterate) Married people are of age >= 18 self.wife->notempty implies self.wife.age >= 18 and self.husband->notempty implies self.husband.age >= 18 and 11 State Models: Simple Some objects have simple interesting states We can draw a state diagram of these states Each state is like a boolean attribute The structure of the states represents an mutually exclusive invariant Transitions between states visually show partial operation specs attributes + op specs GasPump idle Gas Pump idle, pumping ready: Boolean inv xor (idle, pumping, ready) hang up ready pick up pickup squeeze release hang up pre idle post ready pre ready post pumping pre pumping post ready pre ready post idle release pumping squeeze 12 6
Outputs and Actions As the automaton changes state it can generate outputs: off Lamp On Lamp Off on on/print( on ) off Lamp On print( on ) off Lamp Off on on off Mealy automaton Moore automaton 13 Activity Diagram Applications Intended for applications that need control flow or object/data flow models... rather than event-driven models like state machines. For example: business process modeling and workflow. The difference in the three models is how step in a process is initiated, especially with respect to how the step gets its inputs. 14 7
Activity Diagram 15 Activity Diagram Swim Lanes 16 8
Actions and Object Flows 17 Usability and UML 18 9
Definition of Usability A concept comprising the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in a particular environment (ISO 9241 v 2.5) The extent to which a product can be used effectively, efficiently and with satisfaction by specified users, for specified tasks in specified environments (ESPRIT 5429: MUSIC project) a measure of ease with which a system can be learned or used, its safety, effectiveness and efficiency, and attitude of its users towards it (Preece, 1994, pp 722) 19 Why usability? shortening the time to accomplish tasks reducing the number of mistakes made reducing learning time improving peoples satisfaction with a system reduce development time 20 10
Rational for introducing usability IBM gained a 400% increase in online sales (and an 84% decrease in help button usage) after redesigning their web site according to usability principles (Tedeschi, 1999). Productivity within the service sector would rise 4% - 9% annually if every software program were designed for usability. (Landauer, 1995) According to a 1995 study by The Standish Group the three main factors in a successful software project are; user involvement, support from executive management and clearly formulated requirements (http://www.standishgroup.com/chaos.html). The implementation of usability engineering techniques has demonstrated a reduction in the product development cycle by 33% - 50%. (Bosert, 1991) Every $1 invested in user-centred design returns between $2 and $100. (Pressman, 1992) 21 User-centred design implies early focus on users, tasks and environment; the active involvement of users; an appropriate allocation of function between user and system; the incorporation of user-derived feedback into system design; iterative design whereby a prototype is designed, tested and modified; 22 11
Development process Phases - organisation along time Process activities Inception Elaboration Construction Transition Activity organization by work type Business analysis Requirements capture Analysis & design Implementation Test Supporting activities Project management Work product management Iterations: preliminary iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 Evaluation of the product with real users to see if it meets user requirements User-centered techniques which give input to the design prosess Review milestones: Inception Review Prototype Iteration Launch Technical Audit Product Commit Demonstrator Iteration Launch Demonstrator Iteration Launch Demo / Delivery Beta Test Launch Acceptance Meeting 23 Why modeling? Communication with developers Users have mental models of their world ( user model ) 24 12
Target audience and description format users The description of the results should foster communication with the target audience Software developers Visual designers 25 The user and the designer Designers' world inform Users' world Designers guide Users Goals Tasks Prototype Implementation specify specify produce and use Referents Implementation Referents Descriptions 26 13
Models of the users world User' World describes Referent 1 1.. uses 1.. used in task performance 1.. describes User performs Task 1.. 1.. describes 1 describes 1 1.. describes 0..1 0..1 Referent Descriptions involves User Profile involves Task description 0..1 correspondence 0..1 0..1 Use Case illustrated by Scenario illustrated by 27 Handbooks http://www.informatics.sintef.no/projects/hci/doc/index.html 28 14
Pen-case used for paper prototyping and requirement sessions 29 Viktige ting å tenke på når en skal planlegge bruk av brukersentrerte teknikker Brukere få med alle viktige brukergrupper: Ledelse, sluttbrukere, support,. Kritiske oppgaver finnes det noen oppgaver som MÅ støttes Hvor mye ressurser og tid er tilgjengelig? Lokal organisering og eksisterende metodikk 30 15
Hva er oppgaveanalyse? Teknikker som har til hensikt å beskrive forutsetninger for og konsekvenser av å utføre en gitt oppgave. Særlig vekt på faktorer i arbeidsomgivelser, organisasjon og egenskaper ved brukere. Arbeidsoperasjoner brytes gjerne ned i deloppgaver for videre analyse. 31 Hierarkisk Oppgaveanalyse 0 Ta ut penger fra minibank Plan 0 1-2 -3 Hvis penger på konto 4-5 -6 1 Sett inn kortet 2 Tast inn pinkode 3 Velg beløp 4 Ta kortet 5 Ta pengene 6 Avslutt transaksjon 1 Sjekk saldo på konto Trykk avslutt 2 Sjekk saldo i kortet 3 Bestem beløp 4 Tast inn beløp Plan 3 1 hvis saldo > 0 gå videre ellers gå til 06 2 hvis saldo > 0 gå videre ellers gå til 06 3-4 Velg skjerm/utskrift Les ny kontostatus på skjerm Motta kvittering 32 16
Avgjøre sak i høyesterett 1. Forberede for kjæremålsutvalg 2. Behandle sak i kjæremålsutvalg 3. Forberede for avdelingsbehandling 4. Forhandle sak i avdeling 5. Etterarbeid med avgjort sak 6. Postbehandling 7. Svare på direkte henvendelser 8. Utarbeide HRs sammensetning og tablå 9. Utarbeide statistikk PLAN 1 Sivile saker 1: Når posten er fordelt (2 g/dag + bud fra adv. / statsadvokaten) (2: Ikke aktuelt) 3: Når saken er mottatt 4: Når saken er registrert 5: Når saken er tildelt fra utredingsleder 6: Når saken er ferdig utredet PLAN 1 Straffesaker 1: Når posten blir fordelt eller saken kommer med bud til straffesaksfunksjonær 2: Når saken er mottatt - Fengslingskjæremål først, andre saker når fengslinger er ferdig fordelt til kjæremålsutvalget (3: Ikke aktuelt) 4: Når saken er fordelt til kjæremålsutvalg 5: Når saken er tildelt fra utredingsleder 6: Når saken er registrert 1.1 Motta sak fra underrett eller riksadvokat 1.2 Registrere ny straffesaksak 1.3 Registrere ny sivil sak 1.4 Planlegge utredning 1.5 Utrede sak 1.6 Fordele til kjæremålsutvalg Se detaljering Se detaljering Se detaljering Samme som 1.2.2 NB! Begjæring om omgjøring av beslutning 1.4.1 Definere hva saken gjelder 1.4.2 Fordele til utreder 33 Spørreteknikk Hierarkisk oppgaveanalyse Hvorfor? Hva går forut? Hva er oppgaven? Hva følger etter? Hvordan? 34 17
Tabularisk oppgaveanalyse 0 Ta ut penger fra minibank 1 Stikke inn kortet 2 Taste inn pinkode Oppgavens mål Hva er hovedmålet ved å utføre denne oppgaven? Få mere kontanter Starte transaksjon, identifisere seg. Valg Kan brukeren velge om de vil bruke produktet til å oppnå det de ønsker? Ja, i bankens åpningstid. Nei Resultat av oppgaven Hva er resultatet av oppgaven? Brukeren får mere kontanter og lavere saldo på konto. Adgang til neste deloppgave. Identifisering Nei Adgang til neste deloppgave. Bivirkninger Kan det at oppgaven blir utført resultere i uheldige bivirkninger? Noen brukere vil bruke mere penger enn ved uttak i bank. Brukeren kan være usikker på om automaten "sluker" kortet. Mulighet for at andre ser pin-koden? Oppgave frekvens Hvor ofte er det vanlig å utføre oppgaven? 1 til 5 ganger per mnd. Oppgaven s varighet Hvor lang tid vil brukeren vanligvis bruke på oppgaven? Oppgavens fleksibilitet Må brukeren følge en bestemt handlingsrekke for å utføre oppgaven? Fysiske og mentale krav Faktorer som gjør oppgaven krevende. 5 min Ikke fleksibel Forstyrrelser fra andre i køen. Huske pin-kode. Lesbarhet av skjermen. Skinn i skjermen. Hver gang 10 sek. (?) Ikke fleksibel Vanskelig å sette kortet riktig inn. Noen vil ha problemer med å rekke opp. Hver gang 20 sek. (?) Ikke fleksibel Man må huske pinkoden. Sikkerhet Er oppgaven skadelig eller farlig for brukeren eller andre? Sjansen for å bli ranet er større enn ved uttak i bank. (?) Nei (Se bivirkning er) 35 Fra brukersentrert teknikk til UML diagram En oppgave i oppgaveanalysen kan brukes for å identifisere ett use case (systemnivå). COMET kravmodellering. Use casene kan videre analyseres med tanke på brukeropplevelse og grafisk brukergrensesnitt. En oppgave i oppgaveanalysen kan brukes for å identifisere en aktivitet i en prosess (virksomhetsnivå) COMET virksomhetsmodellering. Aktivitetsgrafene analyseres videre for å identifisere krav til systemet. 36 18
Activity: Model the User-Experience Artifact: User-Experience Model (Use-Case Storyboards) 37 Activity: Model the User-Experience Artifact: User-Experience Model (Use-Case Storyboards) 38 19
Activity: Model the User- Experience Artifact: User-Experience Model 39 Business Modelling Discussion 40 20
Diskusjon Virksomhetsmodellering Sett dere sammen i grupper a 2-3 og diskuter begrepene: Virksomhet og virksomhetsmodellering Spørsmål i diskusjonen Hva er en virksomhet? Hvordan skal vi beskrive/modellere virksomheten? Hva er hensikten med virksomhetsmodellering? Hvordan kan vi bruke virksomhetsmodeller i systemutviklingen? 41 COMET Business Model with WesternGeco Survey Booking Reference Example 42 21
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. 43 High-Level System Boundary <<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. <<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. <<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. Marine Management Op erations Sales SurveyBooking Support Introsp ection Administrator <<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. <<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. <<description>> A person with administrator rights is needed to keep the system updated with regards to user names and rights and vessel names. 44 22
Subsystem Grouping BookingEditor 1. Book tender/lead Introspection GlobalScheduleService 7a. View local schedule 5. Reschedule job 18. Assemble and deliver schedule 2. Update booking status <<include>> 17. Synchronize and save schedule ActivityInfo Sales 15. Import from global schedule <<include>> 10. Add/remove users & rights 16. Export to global schedule <<include>> 11. Add/remove vessels BookingViewer <<include>> Administrator 7b. View global schedule SubscriptionService M arine Management SubscriptionEditor 19. Check for subscriptions & notify 20. Update list of available subscriptions SubscriptionInfo 12. Subscribe to notification <<include>> Operat ions 21. Save/remove subscriptions 45 Component Structure Bus Pattern BookingEditor BookingViewer SubscriptionEditor Component Infrastructure BookingService S ubscriptions ervice ActivityInfo SubscriptionInfo 46 23
47 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. 48 24
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. 49 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. 50 25
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 M onitor vesel availability M onitor competitor activity <<summary>> Marketing <<summary>> Review work specifications Propose technical solutions Oil Company Corporat e Manager AccountManager Marketing Technical Support Marine acquisition <<summary>> Produce a timeliy, quality image service to help clients find, produce and manage oil assets. Operation M anagement <<summary>> Review operational risks Data Processing <<summary>> Monitor marine activity OBP proposals Legal <<summary>> Review contract Assess risk Insurance Maritime Manager <<summary>> Optimize revenue Position vessels Upgrade vessels Report 51 Tender Bid Context Diagram [no bid] :Sales & Marine Management PreSales [qualified bid] <<ResourceAsArtefact>> :ITT :Operations Tender Bid [won] [lost] <<ResourceAsArtefact>> :SWO Survey Preparation Survey Execution Survey Close 52 26
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. 53 Vision for change (1/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 10 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. 54 27
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 55 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. 56 28
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 57 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. 58 29
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. 59 Tender Bid Process Overview Receive ITT & Prepare for bidding [continue] Make Tender [continue] [stop] [stop] Submit Tender 60 30
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 {Othe tool} {Surve Bookin Create business review form brf:businessreviewform Bid approval Make Tender {End of survey booking} [Cancel bid] 61 Make Tender :AccountManager {Surve Costing Survey Costing {Othe 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 Costing [cost ok] tender:tender Approve Tender Submit Tender [decide to send] [decide not to send] {End of survey booking} 62 31
Submit Tender :Oil Company :AccountManager :Operations tender:tender Review Tender Update booking status to tender sent response:bidresponse Update booking status to bid won or lost Survey Preparation 63 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. 64 32
Business Resources LocalSchedule GlobalSchedule Configuration 1 Client <<shall use>> 1 Schedule 1 1 1 corp_code : undefined Crew SWO 1 1 1 Booking 1 start : undefined end : undefined 1 summary : undefined <<located in>> <<located in>> 1 1 Vessel <<owns>> 1 1 Capacity 1 Company Job Country Area/region Tender/Lead Survey Phase WesternGeco Competitor 65 More Objecteering/UML Questions and discussions 66 33