1 / 50

Lecture 6

Module P00801 E-Business Information Systems. Lecture 6. E-Business Modelling with UML. Prof. Hong Zhu Department of Computing and Electronics. Outline. Principles of Software Modelling Roles of models in e-business software development Principles of object-oriented modelling

latif
Download Presentation

Lecture 6

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. Module P00801 E-Business Information Systems Lecture 6 E-Business Modelling with UML Prof. Hong Zhu Department of Computing and Electronics P00801: E-Business Information Systems

  2. Outline • Principles of Software Modelling • Roles of models in e-business software development • Principles of object-oriented modelling • Types of models • United Modelling Language UML • Functional models • Use case diagram • Activity diagram • Structural models • Class diagram • Object diagram • Behaviour models • Sequence diagrams • Collaboration diagrams • State machine P00801: E-Business Information Systems

  3. What is a Model Irrelevant details are omitted. • Model is an abstract description of a system under study • In scientific disciplines, we often use a set of statements • For example, Newtonian physics models objects by three laws • In engineering disciplines, we often use small scale objects (also in different material, etc.) • For example, in architecture design, architectures use structural models of buildings • For software modelling, we often use a set of diagrams • For example: SSADM uses dataflow diagrams, control flow diagrams, entity relationship diagrams P00801: E-Business Information Systems

  4. Relationship between system and model • A system is an instance of model, if the description is correct • the statements are true • the structure and operation of the system is as the meaning of the diagrams • Model as the specification, system as the implementation • One model, many instances • different ways of implementations • One system, many models • different ways of abstraction P00801: E-Business Information Systems

  5. Modelling in E-Business Software Development P00801: E-Business Information Systems

  6. Model-Driven Software Development General ideas: • Develop a model is the main goal of the development at early stage; • Use the model as the baseline for later development activities; • Use automated tool to construct analyse and process models. Platform Independent Model (PIM) Use automated modelling tool Platform Specific Model (PSM) Automated code generation tool Executable code P00801: E-Business Information Systems

  7. Types of Models P00801: E-Business Information Systems

  8. Behavioural model Sequence diagram Communication diagram Behavioural state machine Functional model Use case diagram Activity diagram Structural model Class Diagram Object Diagram Relationships Between Types of Models External view Internal view Dynamic view Static view Interaction view Individual view P00801: E-Business Information Systems

  9. Underlying Principles of OO Modelling (1) • An information system should be structured in such a way that it reflects the structure of the real world system • Easier to understand the information system • Metaphor: using the same vocabulary to describe the entities in the information system as the users describes the things, ideas and concepts in the real world • Easier to modify the information system • Users’ requirements tend to change much more frequently than the structure of their organisation and the domain • Changes in organisation system can be relatively easily reflected in the modification of the information system P00801: E-Business Information Systems

  10. Underlying Principles of OO Modelling (2) • ‘Everything in the world is object’. Hence, • The real world can be modelled by objects • Everything in an information system should be an object in order to satisfy principle 1 • All information systems can be modelled in OO approach Semantic gap Real world World of software Design phase Analysis phase Model of the real world Model of the SW world P00801: E-Business Information Systems

  11. The Meta-Model of Object-Orientation • Object • A set of attributes: • The states of real world objects are reflected by the values of the attributes • A set of methods: • The changes of states are reflected in the collection of methods that changes the states of objects • The set of attributes and the set of methods are encapsulated into one computational entity P00801: E-Business Information Systems

  12. Class is called the classifier of objects, similar to data type is the classifier of data In mainstream OO methodology, objects does not change their membership to the classes. Class is an abstract thing that does not actually exist in the system at runtime. • Class • The similarity between objects is reflected by classifying them into the same class. • Objects are instances of classes • Class is the template for a collection of objects that have the same structure, i.e. • the same set of attributes, and • the same set of methods. P00801: E-Business Information Systems

  13. Relationships Between Objects • Generalisation • Definition: Class A is a generalisation of class B, if every instance of class A is also an instance of class B. • Class A is called a super-class of B; class B is called a subclass of A. • We also say that class B is a specialisation of A. • A relationship between classes: the super-class /subclass relationship is also called inheritance relation. • Class B inherits the attributes and methods of A. • Example: • Undergraduate Student is a subclass of Student; • Postgraduate Student is a subclass of Student; • Student is a subclass of Person; • Lecturer is also a subclass of Person It also allows B to specialise the attributes and methods by giving a new definition while maintain the same semantics P00801: E-Business Information Systems

  14. Whole-part relationships • Whole-part: Object A is a part of object B • A wheel is a part of a car • Aggregation: an object consists of several other objects • A car consists of 4 wheels, 1 engine, 1 steering wheel, … • Key features of whole-part relationship • Life-dependence: • Whether a part object can exist without being a part of a whole object • Shareability: • Whether a part object can be a part of more than 1 object • Cardinality: (also called multiplicity): • How many part objects can be contained in 1 whole object • Types of whole-part relations in UML: • Aggregate: shareable, but no life-dependence • Composite: life-dependent and not shareable E.g. Heart is a part of human body. E.g. Your money is also mine. E.g. A bike has 2 wheels. P00801: E-Business Information Systems

  15. Association • An object A affects another object B’s state, e.g. object A can directly cause object B to change its state (by invocation of object B’s method). • A doctor operates on a patient • Engine drives wheels • Steer wheel change the direction of wheels • An object A monitors another object B’s state, e.g. object A accesses B’s attributes. P00801: E-Business Information Systems

  16. Functional Models • Describes the functionality of the SW • its roles in the business process • its interaction with the user and environment • What are the functions • How the system works from the external point of view • UML’s support of functional modelling • Use case diagram • Activity diagram P00801: E-Business Information Systems

  17. Use Case Diagrams • A use case diagram is a collection of actors, use cases, and theircommunication • Used during requirements elicitation to represent the functions of a system from external point of view P00801: E-Business Information Systems

  18. Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality <<Extend>> or <<Include>> relations between use cases Passenger PurchaseTicket FindRoute The Notation of UML’s Use Case Diagrams <<Extend>> P00801: E-Business Information Systems

  19. An actor models an external entity which communicates with the system: User External system Another computer system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A traveller on the train GPS satellite: Provides the system with GPS coordinates Passenger Actors P00801: E-Business Information Systems

  20. A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements Purchase Ticket PurchaseTicket Use Case P00801: E-Business Information Systems

  21. Example of Use Case Diagram • Flow of Events: • The seller selects an agent. • The system responds by assigning an agent and notifying the seller’s agent. • The seller lists the property to sell. • The system responds by displaying this property in the property listing and linking it for searches. • The buyer selects an agent. • The buyer reviews the property listings by entering search criteria. • The system responds by displaying properties that match the buyer’s search criteria. • The buyer finds a property and makes an offer on it. • The system responds by notifying the seller and the seller’s agent. • The seller responds to the offer with a counteroffer. • The system responds by notifying the buyer and the buyer’s agent. • The buyer and the seller agree to terms. • The system responds by recording the agreement. • The buyer indicates that a loan is required. • The system responds by locating an appropriate loan provider. • The buyer and the loan provider agree to loan terms. • The system responds by recording the terms of the loan. • The buyer and the seller close on the property. • The system responds by recording the details of the close. Use case name: Sell Property Participant: Buyer, Seller, Loan Adviser Entry conditions: … Exit conditions: … Kulak, D and Guiney, E., Use Cases: Requirements in Context, Addison Wesley, 2000 (page 190-191) P00801: E-Business Information Systems

  22. Revised use case diagram How to decompose long transactions into use cases? P00801: E-Business Information Systems

  23. Control flow Object flow Notation of UML’s Activity Diagrams Action Action/activity node: an action or an activity Class name Object node: represent an object Initial node: beginning of a sequence of actions/activities Final activity node: stop all control flows and object flows in an activity Final flow node: stop a specific control flow or object flow Swim lane: break up an activity diagram into parts to assign the activities or actions to the actors Decision node Fork node Join node Merge node P00801: E-Business Information Systems

  24. Activity Diagram: the Underlying Concepts • Action/Activity • Performed for some specific business reason • Can be manual or computerised behaviour • Named by a verb with a noun, e.g. • Make payment arrangement • Book an air ticket • Enter delivery address • Action: simple, not decomposable • Activity: can be further decomposed into a set of actions or activities P00801: E-Business Information Systems

  25. Control Flow and Object Flow • Control flow • Model the path of execution through a business process • Can only be attached to action/activity nodes • Object flow • Model flow of object through a business process • Show the objects that flow into and out of the actions or activities (i.e. passed between activities) • Similar to dataflow in dataflow diagrams • Attached to one action/activity node and an object node P00801: E-Business Information Systems

  26. Decision node Object node Decision condition Object flow Example: Appointment Get patient info [old patient] [New patient] Appt request form Create new patient record Appt request form Make an appointment Appt P00801: E-Business Information Systems

  27. Swim Lanes • Breaking up an activity diagram into parts by placing activities/actions into the swim lane box • Assigning responsibility to objects or individuals that performs the activities/actions by assign a name of object/individual to each swim lane • Representing parallel and concurrency of executions • Modelling a business workflow, • Describing ‘who is doing what’ using swim lanes • Describing ‘how they coordinate’ using synchronisation bar P00801: E-Business Information Systems

  28. Example: Make a School Lunch Box Mother Father Get bread Get drink Get dessert Get jelly Get peanut butter Create sandwich Get lunch box Put lunch in box P00801: E-Business Information Systems

  29. Structural Models • General concept: • A structural model describes a system in terms of its constituent elements and their interrelationship. • For information systems: • A structural model of an information system describes the structure of the data and their processing code by dividing them into computational entities. P00801: E-Business Information Systems

  30. Structural Modelling at Different Phases • At analysis phase: • Shows the logical organisation of the entities without indicating how they are stored, created, or manipulated • Free from any implementation or technical details • At design phase: • Reflects how the objects will be organised in databases and files • Address implementation and technical issues, such as • redundancy in the storing of information, • ease of retrieval of stored information, etc. P00801: E-Business Information Systems

  31. UML Class Diagram Notation Class name Attributes Methods Class name Aggregate Class node without compartments Composite Class node with 3 compartments Inheritance Association P00801: E-Business Information Systems

  32. Vehicle Buffalo cart Truck Aircraft Jumbo-jet Helicopter Example: Inheritance Relation P00801: E-Business Information Systems

  33. Car Car 1 4 Wheel Wheel Examples: Multiplicity Car 0..1 4..5 Wheel A wheel is a part of car A car has 4 wheels. A wheel can be on 1 car at any time. A car may have 4 or 5 wheels. A wheel may be fixed on 1 car, but it may also be not used by any car. P00801: E-Business Information Systems

  34. Person Symptom Illness 0..* 0..* Schedules Treatment Employee Patient 1 0..* Appointment 0..* 1 1..* Nurse Doctor Leads to Has scheduled 0..* 0..* 1..* Bill Administrative staff 0..1 Health Team Example: Hospital * P00801: E-Business Information Systems

  35. Person -surname -first name -address -telephone -date of birth -/age Patient -amount … +make appointment … Derived attribute: Its value is calculated from other attributes rather than stored. Example: Class Diagram with Attributes & Methods P00801: E-Business Information Systems

  36. Has scheduled schedules Patient -amount +make appointment Doctor Symptom -name 1 0..* 0..* 1..* Appointment -time -date -reason +Cancel 0..* 1..* suffer Example: Class Diagram P00801: E-Business Information Systems

  37. Behavioural Models • Behavioural models describe the internal dynamic aspects of an information system that supports the business processes in an organisation • At requirements analysis stage • Internal logic of the business processes • Without specifying how the system is implemented • At design and implementation stage • Details of the designs of the system, such as • the data types of the attributes • the operations of the objects Behaviour model describes the ‘journey between the towns’, i.e. the interactions between the objects to achieve the functions of use cases. P00801: E-Business Information Systems

  38. Two Types of Behaviour Models • Interaction models • Describe the collaboration between objects and actors in the business process by describing how objects and actors in the system communicate, cooperate and coordinates with each other • In UML, they are described by sequence diagrams and communication diagrams • Individual models • Describe the behaviour of individual objects and actors by describing how they change their states and the actions to be taken in each state and the outside condition. • In UML, they are described by behavioural state machines associated to classes P00801: E-Business Information Systems

  39. Interaction Diagrams OO Behaviour rule: When an object receives a message, it executes its corresponding method with the parameters given in the message. Basic concepts • Object • Instances of classes • Consists of attributes and methods • Operations • Attributes describe the information about the object • Operations (i.e. methods) are the actions that an object can perform, which are essentially procedure/function declarations that has attributes as global variables • Messages • Messages are information sent to objects to tell an object to execute one of its operations • Messages are essentially procedure/function calls from one object to another P00801: E-Business Information Systems

  40. :Customer Manager :Bookshop :ClientGUI :Buyer keywords keywords List of titles objects List of titles title Two dimensions title title available title available place order time request customer details customer details customer details request credit details credit details credit details purchase confirmed Sequence Diagrams: Buying Book Online P00801: E-Business Information Systems

  41. <<actor>> Actor/Role Actor: A person or system that derives benefit from and is external to the system anObj: Class Object: Participants in an interaction depicted in the sequence diagram by sending and/or receiving messages aMessage() Return value Elements of Sequence Diagrams Lifeline: denotes the life of an object during the interaction depicted in the sequence diagram Message: conveys information from one object to another one Execution occurrence: denotes when an object is sending and/or receiving messages Object destruction: shows an object is going out of existence P00801: E-Business Information Systems

  42. There is only ONE thread of execution, and activity passes from one object to another. More than one object can be active at any one time. This would be the case in a multi-threaded system. Message Flows Message flow annotation: Procedural or synchronous - a message is sent by one object to another, and the first object WAITS until the resulting action has completed. Asynchronous - a message is sent by one object to another but the first object does NOT wait until the resulting action has completed, it carries on with the next step in its own sequence of actions. Flat - each arrow shows a progression from one step to the next in a sequence. Normally the message is asynchronous, but can be used for both (sync. and async. modes) Return - represents the explicit return of control from the object to which the message was sent (optional). P00801: E-Business Information Systems

  43. notation using an object constraint language UML notation for a note Example: Telephone Connection • The objects are: • sender (person) • receiver (person) • telecoms switch • conversation P00801: E-Business Information Systems

  44. Loops and conditionals: UML 1.x procedure dispatch foreach (lineitem) if (product.value > $10K) careful.dispatch else regular.dispatch end if end for if (needsConfirmation) messenger.confirm end procedure P00801: E-Business Information Systems

  45. Loops and conditionals: UML 2.0 P00801: E-Business Information Systems

  46. Common Operators for Interaction Frames P00801: E-Business Information Systems

  47. Enters Hospital > 2 weeks [Diagnosis = healthy] Checks in Released Admitted Waiting [Diagnosis =Unhealthy] [Diagnosis = healthy] Under observation Behavioural State Machines • A dynamic model that shows • the different states that a single object passes through during its life • its response to events with changes on its state and the actions. • Used for further definition of the behaviour of objects P00801: E-Business Information Systems

  48. Basic Concepts of State Machines • State: • The state of an object is defined by the values of its attributes and its relationships with other objects at a particular point in time. • E.g. a patient can be new, current, or former. • Event: • Something that takes place at a certain point in time and changes a value of an attribute. • For example: • A designated condition becoming true • The receipt of a call for a method by an object • Passage of a designated period of time • Transition: • A relationship that represents the movement of an object from one state to another state. • A transition is trigger by an event; • A transition may be associated with an action/activity. The action/activity takes place when the state transition happens • A transition may have a guard condition, which is a Boolean expression. The transition happens only when the guard condition is true P00801: E-Business Information Systems

  49. [guard condition] Event/Action UML’s Notation of State Machines state State node Initial state Final state State transition P00801: E-Business Information Systems

  50. Further reading • Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modelling language, Third Edition, Addison-Wesley, 2003. • Michael P. Papazoglou and Pieter M. A. Ribbers, E-Business: Organizational and Technical Foundations, (Chapter 12: E-Business Modelling, pp305-347) P00801: E-Business Information Systems

More Related