Business Systems Analysis with UML Modelling the Zeitgeist Club

1. Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing owenj@comp.leeds.ac.uk

2. OO Analysis and Design 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

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

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. Example – a complex system Life, decision making, interaction Human Body Mind Sub-Systems and Emergence Emergent Properties of A System A Sub-system A1 Sub-system A2 System A is more than the sum of Subsystems A1 and A2 Key is a part of

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

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

10. HIGH-LEVEL view LOW-LEVEL view INSIDE view OUTSIDE view REQUIREMENTS view DYNAMIC view LOGICAL view PHYSICAL view Modelling Perspectives The System to be Studied

11. Modelling Z-Club

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

13. HIGH-LEVEL… OUTSIDE… REQUIREMENTS view Z-ClubBusiness Use Case 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. DYNAMIC view HIGH-LEVEL… Z-ClubBusiness Process Key An activity. An action, or set of actions that are performed as part of a process. It may represent a process in it’s own right. Transition. A line to indicate the next activity in the sequence.

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

16. HIGH-LEVEL… INSIDE… LOGICAL view Z-ClubBusiness Object Model 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.

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

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

19. DYNAMIC view Z-ClubRadical Process Redesign 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. REQUIREMENTS view Z-ClubBest 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) <<Get Information>> 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

21. INSIDE… LOGICAL view Z-ClubSystem 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.)

22. REQUIREMENTS view Z-ClubSystem Use Case Diagram Key Actor Use Case – a “case of using” the system a system requirement.

23. DYNAMIC view Z-ClubUse Case Realisations LOW-LEVEL … INSIDE … 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-ClubSoftware Components HIGH-LEVEL … INSIDE … PHYSICAL view Key Software Component Package Dependency

25. Conclusions

26. Requirements Views Use Case Deployment Class Logical Views Physical Views Composite Object Communication Activity State Sequence Dynamic Views The Nine UML Diagrams 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. Modelling LevelsChoosing Levels of Abstraction Once you have the big picture you can then zoom in to examine the detail.

28. Visual Modelling Levels • 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 • OUTSIDE View • Business • Business Context • Business Use Case diagram • System • System Context Use Case diagram • System Use Case diagram • Sub-Systems • More use cases + physical design – software components and packages

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

30. OO Analysis and Design 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

31. OO Analysis and Design What next? Online • School of Computing, Software Engineering www.comp.leeds.ac.uk/se20 • The Object Management Group (OMG's) www.uml.org • UML Style guidelines from Scott Ambler www.agilemodeling.com/style 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), 425-443.

32. Business Systems Analysis with UML Modelling the Zeitgeist Club Owen Johnson Information Systems Programme Manager Leeds University, School of Computing owenj@comp.leeds.ac.uk