1 LECTURE 9 Amare Michael Desta Decision Support & Executive Information Systems:
2 Object-Oriented Modelling – what is it? A type of Modelling in which programmers define notModelling programmers only the data type of a data structure, but also thedata typedata structure types of operations (functions) that can be applied tofunctions the data structure. In this way, the data structure becomes an objectobject that includes both data and functions. In addition,data programmers can create relationships between one object and another. E.g. objects can inherit characteristics from other objects
3 Object-Oriented Modelling – what is it? (Contd … ) One of the principal advantages of OO oriented ModellingModelling techniques over procedural ModellingModelling techniques is that they enable programmers to create modules that do not need to be changedmodules when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existingfeatures objects. This makes OO programs easier to modify
4 Object-Oriented Modelling – Why OO? Specifying designs for OO Programming Developing in client/server environments Capturing domain semantics Reducing the semantic gap Develop organisational memory Increase reusability (knowing what we know) Assembly from standard parts (Codification) Avoid reinventing the wheel
5 Object-Oriented Modelling – the bases Based on semantics Subject Object Verb The cat sat on the mat Similarities and Differences Attributes Behaviour
6 Object-Oriented Modelling – Why OO? OO – An object is an abstraction of attributes and operations that is meaningful to the system Consider a manual system that consists of a pen, an order form and a product After developing an OO system – the pen disappears, the form becomes a software object. The product is still a physical object but now has various associated software objects
7 Object-Oriented Modelling – OO Concepts 1 Encapsulation data hiding Interfaces Composition Parts and wholes Aggregation Classification Generalisation and specialisation
8 Object-Oriented Modelling – OO Concepts 2 Inheritance Attributes Methods Polymorphism Many formed Overloading Methods Operators
9 Object-Oriented Modelling – OO Concepts 3 Abstractions Top down Bottom up Middle up down Hierarchies Use cases Task Scripts
10 Object-Oriented Modelling – OO Concepts 4 Class An abstract definition A cookie cutter An object factory Object An instance of (member of) a class Instantiation State, behaviour and identity
11 Object-Oriented Modelling – - Client Server Computing OO is ideally suited to modelling client server systems due to the message passing metaphor used to describe object interactions Client Server Agent Middleware
12 Look at this scenario: Intending guests may contact the hotel to reserve a room (or rooms) by telephone or mail, although telephone reservations must subsequently be confirmed in writing within 7 days or the reservation is cancelled. The reception staff reserve the room(s) on a Room Reservation Chart by marking the room(s) "R" in pencil between the start and finish dates for the guest's reserving by mail and with a "T" for those reserving by telephone. The "T" is changed to an "R" when mail confirmation is received. All reservations are confirmed in writing by the hotel.
14 Object-Oriented Modelling – Modelling - 2 Reservation (booking) Attributes Type: name Guest: guest, Room: room, Date: received, from, to, status (T, R), confirmed (Y/N) Actions Type (of output) name (inputs) setGuest(Guest g), setRoom(Room r), fromDate(Date f), toDate(Date t), confirm(), cancel()
15 Object-Oriented Modelling – Modelling - 3 Relationships Guests reserve rooms Rooms have occupants Rooms have reservations
16 Object-Oriented Modelling – Modelling - 4 Constraints (Rules) Rooms are single or double or twin bed Only 1 guest can occupy a single room at any one time. New guests cannot enter a room before current guests has left Rooms must be prepared for guests Reservations must be confirmed in writing
17 Object-Oriented Modelling – Representation UML, (Unified Modelling Language) Standard Graphical representation Things Objects and Relations
18 Object-Oriented Modelling – UML 1 Range of diagrams Class Inheritance Composition Sequence Order of execution of methods Collaboration Which objects use/are used by other objects Use case Typical user interactions Activity Workflows – sequential and parallel behaviour
23 Object-Oriented Modelling – Roles of the Model Analysis of the problem Presentation of the problem Communication of the analysis Design of a solution Communication of a solution Being part of a solution
24 Object-Oriented Modelling – Strengths Reduces semantic gap User language forms basis of model Good support for reusability Good support of extendibility
25 Object-Oriented Modelling – Weaknesses Poor support for process and workflow modelling Complicated To learn To apply Does not provide a management view of the organisation Now let us see: Enterprise Modelling, (EM).
26 What is Enterprise Modelling, EM)? ….. is a capability for externalising, making and sharing enterprise knowledge.
27 What is EM? (Contd … ) It is: An OO approach to modelling the whole organisation Not a new idea Database approach Information Engineering But a new twist Provides a management business model Reusable, extendible and maintainable
28 Enterprise Modelling, EM) - Purpose Identifies what is of value in an organisation Identifies means of realising value in an organisation Relates Contracts – what should be done and by whom Schedules – when things should be done Measurements – what and how well things have been done
29 Enterprise Modelling, EM) - Process The actions that an organisation uses in order to achieve its purpose Details The flow of work The flow of information Relates work and information to specific purposes
30 Enterprise Modelling, EM) – Entity The things that make up the business Both People Artefacts Entities perform different roles in different processes and at different points with a process
31 Enterprise Modelling, EM) – Orgnisation A network, or set of networks of small groups that cooperate to achieve a set of common purposes A kind of social system
32 Enterprise Modelling, EM) – Structure Social Structure Formal Power, influence, authority, responsibility Communication Structure Informal Interpersonal relationships
33 Enterprise Modelling, EM) – Social System A set of interrelated units that are engaged in joint problem solving to accomplish a common goal Units Individual, group, organisation or sub- system
34 Enterprise Modelling, EM) – Memory Enterprise models act as a form of organisational memory Of what the organisation is about Purpose Organisation And how it seeks to achieve its purpose Process – temporal order Entities - roles
35 Enterprise Modelling, EM) – Value of Memory EM models can provide value (have purpose) in a variety of ways Reduce semantic or culture gap between business analysts and IS analysts Highlight the gap between what is done – informal communication structure and what is intended – formal social structure
36 Enterprise Modelling, EM) – Updating Memory To maintain its value an EM must be up to date. Model building needs to be part of normal management practice Line management Planning and review Requires management commitment and tool support
37 Serving Men I have six little serving men, they taught me all I know, Their names are: - What - and where - and when - and how - why and - who. Just So Stories, Rudyard Kippling.
38. Who might be a persons name e.g. Chris, a job title e.g. Transport manager or an operational label e.g. vehicle scheduler. Typically an initial draft will contain peoples names or job titles, these are the people that the description must be discussed with to ensure its correctness. As is explained below it is useful, after the activity is well understood to decompose each activity so that it defines single operation and to give it an operational label.. What defines the goals/desired outcomes of the activity. Identifying the role of the six Men
39. How should identify the systems, objects and the procedures employed in the activity.. Where should include details of location and or the physical environment and conditions under which the activity occurs.. When defines the pre-conditions of the activity and its temporal relations to other activities and the environment.. Why defines the motivation for undertaking the activity. Identifying the role of the six Men (Contd … )
40 Serving Men and CATWOE WhoWhatHowWhereWhenWhy ActivityActorThe outcome of the transforma tion Transform -ation Environ- ment The pre- conditions of the transforma tion and temporal semantics Weltan- schauung. Owners
41 Muller, defines a use case as a text description that contains the following elements: - The beginning of the use case - the event that triggers the use case. The end of the use case - the event that stops the use case. The interaction between the use case and the actors. The exchanges of information. The chronology and the origin of the information. Repetitions of behaviour. Optional situations.
42 Use Case Example 1 - Customer Request For Availability Information The use case begins when a Customer enquires about the availability of a Vehicle (enquires are received as: e-mails, telephone calls or visits in-person). The Transport Manager opens the Schedule and selects the Vehicle type the Enquirer (Customer) is interested in. The Transport Manager enters the times the Enquirer is interested in and requests the Schedule to show the availability. The Schedule displays a Timetable showing the availability of each Vehicle during the requested times. The use case ends when the Transport Manager informs the Enquirer of the availability of the requested Vehicle at the requested times. It is import in use case that an Actor label identifies the role being fulfilled and not the user fulfilling it. Customers have many roles but will only play one part in a particular use case. Similarly we might know that it is the Transport Manager who responds to the request but the role they are playing is Request handler.
43 Use Case Example 2 - Customer Request For Availability Information The use case begins when a Customer enquires about the availability of a Vehicle (enquires are received as: e-mails, telephone calls or visits in-person). The Request Handler opens the Schedule and enters the vehicle ID or type the Enquirer (Customer) is interested in. The Request Handler enters the times the Enquirer is interested in and requests the Schedule to show the availability of the Vehicle for the times. The Schedule displays a Timetable showing the availability of each Vehicle during the requested times. The use case ends when the Request Handler informs the Enquirer of the availability of the requested Vehicle at the requested times.
44 Comparing Use Case with the Soft Systems Methodology approach. C - Customer A - Transport Manager T - Customer needing availability information - those needs met W -Speedy accurate replies keep customers happy O -Senior Management E - Varying Customer demand for vehicles. The condition, reliability and service requirements of the vehicles. Demands on the transport Managers time.
45 A system owned by senior management and operated by the manager to give customers speedy and accurate information about the availability of a vehicle under conditions of varying vehicle usage, servicing requirements and Customer requests. NOTE: - An Actor in a Use Case is quite different to an Actor in SSM. One way of understanding this difference is that Use Case is the softwares viewpoint while the Root Definition is the Human viewpoint.
46 WhatHowWhereWhoWhenWhy Scope/ Objectives List of Entities List of processes List of Locations List of organisation s List of Events Strategy Goals, etc. Business/ enterprise model ERDProcess flow diagram Logistic network OrganogramBusiness schedule Business plan Information systems model Data modelDFDDistributed systems architecture HCI architecture Process structure Knowledge architecture Technology constrained model Data DesignStructure chart Systems architecture HCI designControl Structure Knowledge design Detailed representation Database description Program source Network architecture Security, etc.Interrupts etc. Knowledge base Working system DataFunctionComms.OrganisationScheduleUse Adapted by Graham from original Zachman Framework. Sowa and Zachman
47 MotivationPeopleTasksObjectsNetworkMotivation Scope/ Objectives Goals Objectives ActorsTask Model/Use case with goals Key termsMessagesConstraints Business/ enterprise model Goals Objectives ActorsTask Model/Use case with scripts Business model StructuresEvent traces Information systems model Goals Objectives ActorsTask Model/Use case with scripts Business model + interface objects StructuresEvent traces Technology constrained model Goals Objectives ActorsTask Model/Use case with scripts OOD ModelStructuresEvent traces, STDs Detailed representation Goals Objectives ActorsTest ScriptsTypes/classe s Pointer structures, class specs STDs, Event traces Working system Goals Objectives UsersTest runsCode Benchmarks Graham's OO version of the Zachman framework.
48 Conclusions 1 OO modelling can be extended to business modelling, providing: Reuse Extendibility OO can be integrated with SSM through use-case
49 Conclusions 2 Enterprise models can be useful KM tools helping us to Know what we know Communicate what we know Provide a medium for training Reduce time to effectiveness of new employees Provide a knowledge map and decision support
50 Conclusions 3 However these benefits do not come for free Must be maintained and kept up to date to be useful Maybe through line management reviews Require training to be used and understood effectively Maybe specialised tools Must enhance general practice if they are to be widely adopted Adoption must be enterprise wide?