Upload
delphina-malas
View
30
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Decision Support & Executive Information Systems:. LECTURE 9 Amare Michael Desta. 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 - PowerPoint PPT Presentation
Citation preview
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
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
RelationshipsGuests reserve roomsRooms have occupantsRooms have reservations
16
Object-Oriented Modelling – Modelling - 4
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
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 problemPresentation of the problemCommunication of the analysisDesign of a solutionCommunication of a solutionBeing part of a solution
24
Object-Oriented Modelling –
Strengths
Reduces ‘semantic gap’ User language forms basis of model
Good support for reusabilityGood support of extendibility
25
Object-Oriented Modelling –
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
Actors Task Model/Use case with scripts
Business model + interface objects
Structures Event traces
Technology constrained model
Goals Objectives
Actors Task Model/Use case with scripts
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?