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
  not
• only the data type of a data structure, but also
  the
• types of operations (functions) that can be
  applied to
• the data structure.
• In this way, the data structure becomes an object
• that includes both data and functions. In
  addition,
• 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
• Modelling techniques over procedural Modelling
• techniques is that they enable programmers to
• create modules that do not need to be changed
• when a new type of object is added.
• A programmer can simply create a new object
• that inherits many of its features from existing
• 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 ModellingOO Concepts 1

• Encapsulation
• data hiding
• Interfaces
• Composition
• Parts and wholes
• Aggregation
• Classification
• Generalisation and specialisation

8
Object-Oriented ModellingOO Concepts 2

• Inheritance
• Attributes
• Methods
• Polymorphism
• Many formed
• Overloading
• Methods
• Operators

9
Object-Oriented ModellingOO 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.
13
Object-Oriented Modelling Modelling - 1

• Candidate Object Classes
• Room
• Guest
• Hotel
• Reservation
• Telephone
• Mail
• Reservation chart
• Pencil

• Candidate Actions
• reserve
• confirm
• cancel
• write
• change
• receive

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

19
Object-Oriented Modelling UML 2
(Class)
20
Object-Oriented Modelling
UML 3 (Sequence)
21
Object-Oriented Modelling UML 4
(Collaboration)
22
Object-Oriented Modelling UML 5 (Use
Case)
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
Identifying the role of the six Men
. 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.
39
Identifying the role of the six Men (Contd)
. 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.
40
Serving Men and CATWOE
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
Adapted by Graham from original Zachman
Framework. Sowa and Zachman
47
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?