LECTURE 9 Amare Michael Desta

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 notonly the data type of a data structure, but also thetypes of operations (functions) that can be applied tothe data structure.

In this way, the data structure becomes an objectthat includes both data and functions. In addition,programmers can create relationships between oneobject and another. E.g. objects can inherit characteristics from otherobjects

3

Object-Oriented Modelling – what is it?

(Contd…)One of the principal advantages of OO orientedModelling techniques over procedural Modellingtechniques is that they enable programmers tocreate modules that do not need to be changedwhen a new type of object is added.

A programmer can simply create a new objectthat inherits many of its features from existingobjects. This makes OO programs easier to modify

4

Object-Oriented Modelling – Why OO?

Specifying designs for OO ProgrammingDeveloping in client/server environmentsCapturing domain semanticsReducing the semantic gapDevelop 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 semanticsSubjectObjectVerb

The cat sat on the mat

Similarities and DifferencesAttributesBehaviour

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 hidingInterfaces

CompositionParts and wholesAggregation

ClassificationGeneralisation and specialisation

8

Object-Oriented Modelling–OO

Concepts 2 Inheritance

AttributesMethods

PolymorphismMany formed

OverloadingMethodsOperators

9

Object-Oriented Modelling–OO

Concepts 3 Abstractions

Top downBottom upMiddle up down

HierarchiesUse casesTask Scripts

10

Object-Oriented Modelling – OO

Concepts 4 Class

An abstract definitionA cookie cutterAn object factory

ObjectAn instance of (member of) a classInstantiationState, 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

ClientServerAgentMiddleware

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.

13

Object-Oriented Modelling – Modelling - 1

Candidate Object Classes

RoomGuestHotelReservationTelephoneMailReservation chartPencil

Candidate Actionsreserveconfirmcancelwritechangereceive

14


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


RelationshipsGuests reserve roomsRooms have occupantsRooms have reservations

16


Constraints (Rules)Rooms are single or double or twin bedOnly 1 guest can occupy a single room at any one time.New guests cannot enter a room before current guests has leftRooms must be prepared for guestsReservations must be confirmed in writing

17

Object-Oriented Modelling –

Representation

UML, (Unified Modelling Language)Standard Graphical representationThings

Objects and Relations

18

Object-Oriented Modelling – UML 1

Range of diagramsClass

InheritanceComposition

SequenceOrder of execution of methods

CollaborationWhich objects use/are used by other objects

Use caseTypical user interactions

ActivityWorkflows – sequential and parallel behaviour

19


(Class)

20

Object-Oriented Modelling – UML 3 (Sequence)

21


(Collaboration)

22

Object-Oriented Modelling – UML 5 (Use

Case)

23


Roles of the Model

Analysis of the problemPresentation of the problemCommunication of the analysisDesign of a solutionCommunication of a solutionBeing part of a solution

24


Strengths

Reduces ‘semantic gap’ User language forms basis of model

Good support for reusabilityGood support of extendibility

25


Weaknesses

Poor support for process and workflow modellingComplicated

To learnTo 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 organisationNot a new idea

Database approachInformation Engineering

But a new twistProvides a management business modelReusable, extendible and maintainable

28

Enterprise Modelling, EM) - Purpose

Identifies what is of value in an organisationIdentifies means of realising value in an organisationRelates

Contracts – what should be done and by whomSchedules – when things should be doneMeasurements – what and how well things have been done

29

Enterprise Modelling, EM) - Process

The actions that an organisation uses in order to achieve its purposeDetails

The flow of workThe flow of information

Relates work and information to specific purposes

30

Enterprise Modelling, EM) – Entity

The things that make up the businessBoth

PeopleArtefacts

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 purposesA kind of social system

32

Enterprise Modelling, EM) – Structure

Social StructureFormal

Power, influence, authority, responsibility

Communication StructureInformal

Interpersonal relationships

33

Enterprise Modelling, EM) – Social System

A set of interrelated units that are engaged in joint problem solving to accomplish a common goalUnits

Individual, group, organisation or sub-system

34

Enterprise Modelling, EM) – Memory

Enterprise models act as a form of organisational memoryOf what the organisation is about

PurposeOrganisation

And how it seeks to achieve its purpose

Process – temporal orderEntities - roles

35

Enterprise Modelling, EM) – Value of Memory

EM models can provide value (have purpose) in a variety of waysReduce ‘semantic’ or ‘culture gap’ between business analysts and IS analystsHighlight 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 managementPlanning 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. vehiclescheduler. Typically an initial draft will contain peoplesnames or job titles, these are the people that thedescription must be discussed with to ensure itscorrectness. As is explained below it is useful, after theactivity is well understood to decompose each activity sothat it defines single operation and to give it anoperational 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 theprocedures employed in the activity.

. Where should include details of location and or thephysical environment and conditions under which theactivity occurs.

. When defines the pre-conditions of the activity and itstemporal 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 Who What How Where When Why

Activity Actor The outcome of the transformation

Transform-ation

Environ-ment

The pre-conditions of the transformation 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 - CustomerA - Transport ManagerT - Customer needing availability information -

those needs metW - Speedy accurate replies keep customers happyO - Senior ManagementE - Varying Customer demand for vehicles. The

condition, reliability and service requirements of the vehicles. Demands on the transport Manager’s 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 software’s viewpoint while the Root Definition is the Human viewpoint.

46

What How Where Who When Why

Scope/ Objectives

List of Entities

List of processes

List of Locations

List of organisations

List of Events

Strategy Goals, etc.

Business/ enterprise model

ERD Process flow diagram

Logistic network

Organogram Business schedule

Business plan

Information systems model

Data model DFD Distributed systems architecture

HCI architecture

Process structure

Knowledge architecture

Technology constrained model

Data Design Structure chart

Systems architecture

HCI design Control Structure

Knowledge design

Detailed representation

Database description

Program source

Network architecture

Security, etc.

Interrupts etc.

Knowledge base

Working system

Data Function Comms. Organisation

Schedule Use

Adapted by Graham from original Zachman Framework. Sowa and Zachman

47

Motivation People Tasks Objects Network Motivation

Scope/ Objectives

Goals Objectives

Actors Task Model/Use case with goals

Key terms Messages Constraints

Business/ enterprise model

Goals Objectives

Actors Task Model/Use case with scripts

Business model

Structures Event traces

Information systems model

Goals Objectives


Business model + interface objects

Structures Event traces

Technology constrained model

Goals Objectives


OOD Model Structures Event traces,STDs

Detailed representation

Goals Objectives

Actors Test Scripts Types/classes

Pointer structures, class specs

STDs, Event traces

Working system

Goals Objectives

Users Test runs Code Code Benchmarks

Graham's OO version of the Zachman framework.

48

Conclusions 1OO modelling can be extended to business modelling, providing:

ReuseExtendibility

OO can be integrated with SSM through use-case

49

Conclusions 2Enterprise models can be useful KM tools helping us to

Know what we knowCommunicate what we knowProvide a medium for trainingReduce time to effectiveness of new employeesProvide a knowledge map and decision support

50

Conclusions 3However 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 adoptedAdoption must be enterprise wide?

LECTURE 9 Amare Michael Desta

Documents

Transcript of LECTURE 9 Amare Michael Desta