1 / 50

LECTURE 9 Amare Michael Desta

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

delphina-malas
Download Presentation

LECTURE 9 Amare Michael Desta

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Decision Support & Executive Information Systems: LECTURE 9Amare Michael Desta

  2. Object-Oriented Modelling –what is it? A type of Modelling in which programmersdefine not only the data type of a datastructure, butalso the types of operations(functions) that can beapplied to the datastructure. In this way, the data structure becomes anobject that includes both data and functions. Inaddition, programmers can create relationshipsbetween one object and another. E.g. objects can inherit characteristics fromother objects

  3. Object-Oriented Modelling –what is it?(Contd…) One of the principal advantages of OO oriented Modelling techniques overproceduralModelling techniques is that theyenableprogrammers to create modules that donotneed to be changed when a new type ofobjectis added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes OO programseasier tomodify

  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 telephoneor mail, although telephone reservations must subsequently be confirmed in writing within 7 days or the reservation is cancelled. The reception staffreserve 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'sreserving 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. Candidate Object Classes Room Guest Hotel Reservation Telephone Mail Reservation chart Pencil Candidate Actions reserve confirm cancel write change receive Object-Oriented Modelling –Modelling - 1

  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. . Whatdefines 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. . Whereshould 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. . Whydefines the motivation for undertaking the activity.

  40. 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 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 Customerenquires about the availability of a Vehicle (enquires are received as: e-mails, telephone calls or visits in-person). The Transport Manageropens the Schedule and selects the Vehicle type the Enquirer (Customer) is interested in. The Transport Managerenters the times the Enquirer is interested in and requests the Schedule to show the availability. The Scheduledisplays a Timetable showing the availability of each Vehicle during the requested times. The use case ends when the Transport Managerinforms 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 Customerenquires about the availability of a Vehicle (enquires are received as: e-mails, telephone calls or visits in-person). The Request Handleropens the Schedule and enters the vehicle ID or type the Enquirer (Customer) is interested in. The Request Handlerenters the times the Enquirer is interested in and requests the Schedule to show the availability of the Vehicle for the times. The Scheduledisplays a Timetable showing the availability of each Vehicle during the requested times. The use case ends when the Request Handlerinforms 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 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 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?

More Related