Presentation on theme: "March 2011 P00801: E-Business Information Systems 1 Lecture 6 E-Business Modelling with UML Prof. Hong Zhu Department of Computing and Electronics Module."— Presentation transcript:
March 2011 P00801: E-Business Information Systems 1 Lecture 6 E-Business Modelling with UML Prof. Hong Zhu Department of Computing and Electronics Module P00801 E-Business Information Systems
March 2011 2 P00801: E-Business Information Systems 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
March 2011 3 P00801: E-Business Information Systems What is a Model 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 Irrelevant details are omitted.
March 2011 4 P00801: E-Business Information Systems 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
March 2011 5 P00801: E-Business Information Systems Modelling in E-Business Software Development ActivityRoles of Modelling Requirements Elicitation Guide the analyst to obtain the information in the process of model construction Requirements Clarification Force the analyst to explicitly express obtained information clearly in well-defined notations in model construction Req. & Design Documentation Represent information in the form of models in well-defined notation without ambiguity Validation, Verification and Testing Support VV&T by readable representations of models at a suitable level of abstraction that are easy to understand by users and developers Analysis and transformation Support automated and semi-automated analysis and transformation by representing systems in machine readable models
March 2011 6 P00801: E-Business Information Systems 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) Platform Specific Model (PSM) Use automated modelling tool Executable code Automated code generation tool
March 2011 7 P00801: E-Business Information Systems Types of Models TypeWhat are modelledFocusUML Functional models The functionality of the SW as its roles in the business process and its interaction with the user and environment How the system works from the external point of view Use case diagram, activity diagram Structural models The structure of the data that supports the business process in an organisation and their representation and process in the SW The logic organisation of data at RE and technical details such as how the data are stored, created or manipulated in design and implementation Objects and class diagrams Packages, deployment and component diagrams Behaviour models The internal dynamic aspects of an IS that supports the business processes in an organisation The internal logic of processes and how the processes are implemented Sequence, communication, behavioural state machine
March 2011 8 P00801: E-Business Information Systems Relationships Between Types of Models External view Functional model Use case diagram Activity diagram Structural model Class Diagram Object Diagram Behavioural model Sequence diagram Communication diagram Behavioural state machine Internal view Static view Dynamic view Interaction view Individual view
March 2011 9 P00801: E-Business Information Systems 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
March 2011 10 P00801: E-Business Information Systems 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 Real world World of software Semantic gap Model of the real world Model of the SW world Analysis phase Design phase
March 2011 11 P00801: E-Business Information Systems 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
March 2011 12 P00801: E-Business Information Systems 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. 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.
March 2011 13 P00801: E-Business Information Systems 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
March 2011 14 P00801: E-Business Information Systems 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. A bike has 2 wheels. E.g. Your money is also mine.
March 2011 15 P00801: E-Business Information Systems Association An object A affects another object Bs state, e.g. object A can directly cause object B to change its state (by invocation of object Bs method). A doctor operates on a patient Engine drives wheels Steer wheel change the direction of wheels An object A monitors another object Bs state, e.g. object A accesses Bs attributes.
March 2011 16 P00801: E-Business Information Systems 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 UMLs support of functional modelling Use case diagram Activity diagram
March 2011 17 P00801: E-Business Information Systems Use Case Diagrams A use case diagram is a collection of actors, use cases, and their communication Used during requirements elicitation to represent the functions of a system from external point of view
March 2011 18 P00801: E-Business Information Systems The Notation of UMLs Use Case Diagrams Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality > or > relations between use cases Passenger PurchaseTicket FindRoute >
March 2011 19 P00801: E-Business Information Systems Actors 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
March 2011 20 P00801: E-Business Information Systems Use Case 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 PurchaseTicket
March 2011 21 P00801: E-Business Information Systems Example of Use Case Diagram Flow of Events: 1.The seller selects an agent. 2.The system responds by assigning an agent and notifying the sellers agent. 3.The seller lists the property to sell. 4.The system responds by displaying this property in the property listing and linking it for searches. 5.The buyer selects an agent. 6.The buyer reviews the property listings by entering search criteria. 7.The system responds by displaying properties that match the buyers search criteria. 8.The buyer finds a property and makes an offer on it. 9.The system responds by notifying the seller and the sellers agent. 10.The seller responds to the offer with a counteroffer. 11.The system responds by notifying the buyer and the buyers agent. 12.The buyer and the seller agree to terms. 13.The system responds by recording the agreement. 14.The buyer indicates that a loan is required. 15.The system responds by locating an appropriate loan provider. 16.The buyer and the loan provider agree to loan terms. 17.The system responds by recording the terms of the loan. 18.The buyer and the seller close on the property. 19.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)
March 2011 22 P00801: E-Business Information Systems Revised use case diagram How to decompose long transactions into use cases?
March 2011 23 P00801: E-Business Information Systems Notation of UMLs Activity Diagrams Action Class name Action/activity node: an action or an activity 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 Decision node Merge node Join node Fork node Swim lane: break up an activity diagram into parts to assign the activities or actions to the actors Control flow Object flow
March 2011 24 P00801: E-Business Information Systems 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
March 2011 25 P00801: E-Business Information Systems 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
March 2011 26 P00801: E-Business Information Systems Example: Appointment Get patient info Create new patient record Appt request form Make an appointment [New patient] [old patient] Appt Decision node Decision condition Object node Object flow
March 2011 27 P00801: E-Business Information Systems 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
March 2011 28 P00801: E-Business Information Systems Example: Make a School Lunch Box Get jelly Get bread Get peanut butter Create sandwich Get drinkGet dessert Get lunch box Put lunch in box Father Mother
March 2011 29 P00801: E-Business Information Systems 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.
March 2011 30 P00801: E-Business Information Systems 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.
March 2011 31 P00801: E-Business Information Systems UML Class Diagram Notation Class name Attributes Methods Class name Class node without compartments Class node with 3 compartments Aggregate Composite Inheritance Association
March 2011 32 P00801: E-Business Information Systems Example: Inheritance Relation Vehicle Buffalo cartTruckAircraft Jumbo-jetHelicopter
March 2011 33 P00801: E-Business Information Systems Examples: Multiplicity Car Wheel A car has 4 wheels. A wheel can be on 1 car at any time. Car Wheel 4 1 A wheel is a part of car Car Wheel 4..5 0..1 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.
March 2011 34 P00801: E-Business Information Systems Example: Hospital Person EmployeePatient Treatment Nurse Administrative staff Doctor Health Team 0..* 1..* 0..1 * Appointment Schedules Has scheduled 1 0..* 1..* 0..* Bill Leads to 1 0..* Symptom Illness 0..*
March 2011 35 P00801: E-Business Information Systems Example: Class Diagram with Attributes & Methods 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.
March 2011 36 P00801: E-Business Information Systems Example: Class Diagram Patient -amount +make appointment Appointment -time -date -reason +Cancel Doctor Symptom -name schedules Has scheduled suffer 0..* 1..* 0..* 1..*1
March 2011 37 P00801: E-Business Information Systems 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.
March 2011 38 P00801: E-Business Information Systems 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
March 2011 39 P00801: E-Business Information Systems Interaction Diagrams 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 OO Behaviour rule: When an object receives a message, it executes its corresponding method with the parameters given in the message.
March 2011 40 P00801: E-Business Information Systems Sequence Diagrams: Buying Book Online :Buyer :ClientGUI :Bookshop :Customer Manager keywords List of titles title title available place order request customer details customer details request credit details credit details purchase confirmed Two dimensions time objects
March 2011 41 P00801: E-Business Information Systems Elements of Sequence Diagrams > 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 Lifeline: denotes the life of an object during the interaction depicted in the sequence diagram Execution occurrence: denotes when an object is sending and/or receiving messages aMessage() Return value Message: conveys information from one object to another one Object destruction: shows an object is going out of existence
March 2011 42 P00801: E-Business Information Systems 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. 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) 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. Message Flows Return - represents the explicit return of control from the object to which the message was sent (optional). 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.
March 2011 43 P00801: E-Business Information Systems UML notation for a note notation using an object constraint language The objects are: sender (person) receiver (person) telecoms switch conversation Example: Telephone Connection
March 2011 44 P00801: E-Business Information Systems 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
March 2011 45 P00801: E-Business Information Systems Loops and conditionals: UML 2.0
March 2011 46 P00801: E-Business Information Systems Common Operators for Interaction Frames OperatorMeaning altAlternative multiple fragments; only the one whose condition is true will execute optOptional; the fragment executes only if the supplied condition is true. Equivalent to an alt with only one trace. parParallel; each fragment is run in parallel. loopLoop; the fragment may execute multiple times, and the guard indicates the basis of iteration regionCritical region; the fragment can have only one thread executing it at once. negNegative; the fragment shows an invalid interaction. refReference; refers to an interaction defined on another diagram. The frame is drawn to cover the lifelines involved in the interaction. You can define parameters and a return value. sdSequence diagram; used to surround an entire sequence diagram, if you wish.
March 2011 47 P00801: E-Business Information Systems 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 Waiting Enters Hospital Checks in Admitted [Diagnosis =Unhealthy] Released [Diagnosis = healthy] Under observation [Diagnosis = healthy] > 2 weeks
March 2011 48 P00801: E-Business Information Systems 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
March 2011 49 P00801: E-Business Information Systems UMLs Notation of State Machines state Initial state Final state [guard condition] Event/Action State transition State node
March 2011 50 P00801: E-Business Information Systems 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)