Presentation is loading. Please wait.

Presentation is loading. Please wait.

Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing.

Similar presentations


Presentation on theme: "Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing."— Presentation transcript:

1 Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing

2 Objectives By the end of session you will be able to: Understand some of the guiding principles behind business systems analysis Appreciate the value of modelling Identify a range of modelling tools and techniques Describe how these modelling tools and techniques can be combined to conduct business systems analysis. Develop information systems requirements for the Zeitgeist Club OO Analysis and Design

3 5. Create Prototype Evaluate against real-world Candidate Design Solution 1 Candidate Design Solution 3 Candidate Design Solution 2 3. Technical Design Generate candidate design solutions 4. Choose A business benefits vs. cost/ risk trade-off Candidate Design Solution 2 Modelling and Systems Design Real-world problem domain Logical Model 1. Analysis Study and understand the current solution to develop a logical model New Logical Model 2. Process Re-Design Radical rethink or best practice

4 Outline Some Theory and Principles Modelling Zeitgeist Conclusions

5 Some Theory and Principles

6 General Systems Theory Systems have Inputs, perform Processes and produce Outputs. They include some element of Control which uses Feedback. Anything with these elements can be regarded as a system. Systems can be very simple (e.g. a thermostat controlling heating) or highly complex (e.g. human systems of government). Some key features of General Systems Theory: 1. The components of a system work together towards a collective goal 2. Systems do not operate in complete isolation They are contained within an environment The scope of the system is defined by its boundary The boundary marks the interface between a system and its environment 3. Systems can be complex and made up of sub-systems 4. Systems have emergent properties – more than the sum of their parts 5. Subsystems can be treated as systems Their environment includes the other sub-systems that they interface with Sub-systems have emergent properties

7 Sub-Systems and Emergence Sub-system A1 Sub-system A2 Emergent Properties of A Key is a part of System A is more than the sum of Subsystems A1 and A2 System A BodyMind Life, decision making, interaction Human Example – a complex system

8 Sub-Systems and Emergence Key is a part of Sub-system A1 Sub-system A2 Emergent Properties of A System A Sub-system A2a Sub-system A2b Emergent Properties of A2 Emergent Properties of A2b

9 Sub-Systems and Emergence Key is a part of Competitor: Venue Zeitgeist: Venue Growth Sophisticated customer base Information sensitive Entertainment: Industry Catering: Department Zeitgeist IS: Information System Loyal customers Falling attendance Warring department managers Security Performance Usability

10 Modelling Perspectives The System to be Studied OUTSIDE view INSIDE view HIGH-LEVEL view LOW-LEVEL view REQUIREMENTS viewDYNAMIC viewLOGICAL viewPHYSICAL view

11 Modelling Z-Club

12 Z-Club Business Context OUTSIDE… REQUIREMENTS view HIGH-LEVEL… Key Actor – independent, autonomous, a person, organisation or other system that is outside the system boundary but that interacts with it.

13 Z-Club Business Use Case OUTSIDE… REQUIREMENTS view HIGH-LEVEL… Key Actor Use Case – a case of using the system. A class of (set of) interactions between actor and the system that results in a positive outcome (measurable value) when complete. Typically represents a business process or system requirement.

14 Z-Club Business Process HIGH-LEVEL… DYNAMIC view Key An activity. An action, or set of actions that are performed as part of a process. It may represent a process in its own right. Transition. A line to indicate the next activity in the sequence.

15 Z-Club Business Process (Swimlanes) HIGH-LEVEL… DYNAMIC view Key An activity. Transition. Swimlane. A boundary between two areas responsible for different activities. OUTSIDE view INSIDE view

16 Z-Club Business Object Model HIGH-LEVEL… Key A business worker. A role performed by people within the business A business entity. An important object that plays a key role in understanding and modelling the business. INSIDE… LOGICAL view

17 Z-Club Business Service Use Cases OUTSIDE, REQUIREMENTS view Key Actor Use Case – a case of using the system. Each use case must independently have value to the actor.

18 Z-Club Service Delivery Process INSIDE … DYNAMIC view Key An activity. Transition. Swimlane.

19 Z-Club Radical Process Redesign DYNAMIC view Example: Problem 5. Customers must book and pay in person at reception. This entails a visit to the venue which is in a seedy part of town renown for car crime and poor parking. Q. How can technology change the entire process? Key An activity. Transition. Swimlane.

20 Z-Club Best Practice Process Redesign 1. There is little information on what events are taking place or when. Process: (Customer) Learn about Events Best Practice: Self-service information via Web Best Practice: Send targeted information based on customer profile 2. The receptionists are surly and unhelpful. Process: (Customer) > Best Practice: Self-service information via Web … 8. Tickets do not specify a seat number; therefore customers scramble to gain the best seats. Process: (Customer) Make a booking Best Practice: Booking by seat number 12. Popular drinks often sell out early on. Process: (Customer) Buy drinks Best Practice: Stock management based on demand forecasting REQUIREMENTS view

21 Z-Club System Concept Class Model Key A class of objects. The class diagram represents the model that the system maintains to store what it needs to know about the real-world problem domain. A relationship between objects of different classes, e.g. one (1) to many (*) A part of A type of (a class can inherit some properties from another class, e.g. a disco is a type of event. All events have date, time, duration, room etc.) INSIDE… LOGICAL view

22 Z-Club System Use Case Diagram REQUIREMENTS view Key Actor Use Case – a case of using the system a system requirement.

23 Z-Club Use Case Realisations DYNAMIC view INSIDE … LOW-LEVEL … Key Boundary Object – controls the user interface Control Object – controls the logic of the use case A message sent between objects in the system

24 Z-Club Software Components INSIDE … HIGH-LEVEL … PHYSICAL view Software Component Package Dependency Key

25 Conclusions

26 The Nine UML Diagrams Use Case Class Activity StateSequence Communication Object Composite Deployment UML was developed as a set of complementary diagrams to support multiple views Now a de facto standard in software engineering. The current standard is UML 2.0.

27 Once you have the big picture you can then zoom in to examine the detail. Modelling Levels Choosing Levels of Abstraction

28 Visual Modelling Levels OUTSIDE View Business Business Context Business Use Case diagram System System Context Use Case diagram System Use Case diagram Sub-Systems More use cases INSIDE View Business Business Objects – workers/ objects Business Activity Diagrams System Concept Class Diagram Activity diagram for a use case Sub Systems Design Level Class diagrams Sequence diagrams for a use case realisation State diagrams for a Class + physical design – software components and packages

29 Current Research Modelling Variety and Best Practice MIT Process Compass VBP Modelling GeneralisationSpecialisation Subactivities Uses Citizen Access Information and Services Access Other Information and Services Get Help with Pupil Admission Get Information on School Make an Application Other Processes Make Application to Local Authority Make Application direct to School Best Practice: Citizen Portal Best Practice: Local Authority managed application Get Information from Local Authority Get Information from School Best Practice: School Web site

30 Objectives By the end of session you will be able to: Understand some of the guiding principles behind business systems analysis Appreciate the value of modelling Identify a range of modelling tools and techniques Describe how these modelling tools and techniques can be combined to conduct business systems analysis. Develop information systems requirements for the Zeitgeist Club OO Analysis and Design

31 What next? Online School of Computing, Software Engineering The Object Management Group (OMG's) UML Style guidelines from Scott Ambler Reading Ambler S, Agile Modeling, Wiley, 2002 Ambler S, The Elements of UML 2.0 Style, Cambridge University Press, 2005 Bennett S, Skelton J & Lunn K, Schaum's Outline of UML (2nd edition), McGraw-Hill, 2005 References King S.F. and Johnson O.A. VBP: An Approach to Modelling Process Variety and Best Practice, Information and Software Technology, forthcoming. Malone, T.W, Crowston, K, Lee, J, Pentland, B, Dellarocas, C, Wyner, G, Quimby, J, Osborn, C.S, Bernstein, A, Herman, G & Klein, M (1999). Tools for inventing organizations: toward a handbook of organizational processes. Management Science, 45(3), OO Analysis and Design

32 Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing


Download ppt "Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing."

Similar presentations


Ads by Google