Systems Analysis and Design I

1. Systems Analysis and Design I Session 3 Modelling concepts and activity diagrams

2. Recap • IS (software) development methodology • Traditional Waterfall Lifecycle, iterative and incremental lifecycles • Methods/processes and methodology • Unified processes (phrases: inception, elaboration, construction, transition vs workflows: requirements, analysis, design, implementation, test) • Object orientation concepts • Object and Classes • Encapsulation, generalisation/specification, polymorphism

3. Today • Models and diagrams • Section 5.2 (pp. 114 – 122), Section 7.2 (pp. 181 – 184) • Activity Diagrams • Section 5.3 (pp. 122 – 128) • Requirements Capture • Section 6.2 (pp. 138 – 142), Section 12.5.3 (pp. 360), Section 21.4.2 (p. 622 – 623), Section 6.3 (pp. 142 – 150)

4. Models and Diagrams

5. What is a Model? • “A model captures a view of a physical system. • It is an abstraction of the physical system, with a certain purpose. • This purpose determines what is to be included in the model and what is irrelevant. • Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the relevant level of detail.” • (OMG, 2009) 5

6. Abstraction 6

7. Business Model Program Systems Analysis and Design Coding Conceptual world Computing world Real world Models in IS development 7

8. Why use a model [purpose]? • A model is quicker and easier to build • A model can be used in a simulation • A model can evolve as we learn • We can choose which details to include in a model • A model can represent real or imaginary things from any domain • A model allows us to talk, or reason, about the real thing without actually building it • Much of software development involves creating and refining models, rather than writing lines of code 8

9. What is a Diagram? • A diagram is a graphical representation of a set of elements in the model of the system • Models vs Diagrams • A diagram illustrates some aspect of a system • A model provides a complete view of a system at a particular stage and from a particular perspective • Most IS models today are in the form of diagrams, with supportingtextual descriptions and logical or mathematical specifications • A model usually contains many diagrams – related to one another in some way 10

10. Why use a diagram? • Natural language is often too ambiguous to be used for modelling • Communication + Ambiguity = Confusion ! A large object with one trunk and four legs. 11

11. Unified Modelling Language (UML) • Around 1997: UML 1.1 • 1.x • 2005: UML 2.0 major revision replaced version 1.5 • UML 2.1 was never released as a formal specification • 2007: versions 2.1.1 and 2.1.2 • 2009: UML 2.2. • 2010: UML 2.3 • 2011: UML 2.4.1 • 2012: UML 2.5 ("In progress" version) • 2015: UML 2.5 (official version) • December 2017: UML 2.5.1 12

12. UML Diagrams (UML 2.0 --) • UML2 defines 14 types of diagrams • Structure • Class Diagram, Object Diagram • Component Diagram, Package Diagram, Profile Diagram • Composite Structure Diagram, Deployment Diagram • Behaviour • Use Case Diagram • Activity Diagram,State Machine Diagram • Interaction • Sequence Diagram, Communication Diagram • Timing Diagram, Interaction Overview Diagram 13

13. Plan Chapter Produce First Draft Revise Draft [not satisfied] [satisfied] Add Exercises Add References to Bibliography UML diagrams notation • A UML diagram usually consists of: • icons • symbols • paths • strings NB：These terms are no longer used in UML 2.2, but are useful to explain stuff. 14

14. What models/diagrams are good? • Accurate • unambiguous, following rules or standards • Concise • showing only what needs to be shown • Complete • showing all that needs to be shown • Consistent • internally and among each other • Hierarchical • breaking the system down into different levels of details 15

15. Campaign Selection Campaign Selection Client: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Yellow Partridge Client: Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Campaign: Yellow Partridge Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 Campaign: Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 Campaign: OK Quit Spring Jewellery Campaign 2002 OK Quit OK Quit Campaign Selection Campaign Selection Client: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Yellow Partridge Client: Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Campaign: Yellow Partridge Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 Campaign: Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 Campaign: OK Quit Spring Jewellery Campaign 2002 OK Quit OK Quit Developing models • During the life of a project using an iterative lifecycle, models change along the dimensions of: • abstraction — they become more concrete • formality — they become more formally specified • level of detail — additional details are added Iteration 1 Obvious use cases Simple use case descriptions Iteration 2 Additional use cases Simple use case descriptions Prototypes Iteration 3 Structured use cases Structured use case descriptions Prototypes A useful model has just the right amount of detail and structure, and represents only what is important for the task! 16

16. Activity Diagrams

17. Purpose of Activity Diagrams • Activity Diagrams can be used to model • high-level business tasks • in the early stages of a project or • when the relevant objects or classes have not been identified • system functions (represented by use cases) or object operations • but communication/sequence diagrams are closer to the spirit of object-orientation 18

18. Notation of Activity Diagrams • Activity Diagrams are essentially Flowcharts / Petri nets in an object-oriented context • sequence, selection, iteration • Concurrence • Core notations • Action • Nodes: action node, decision node, initial node, final node, • merge node fork node, join node, • Edges: action edge, guard conditions • OO related: class name, operation name, object flow, activity partition 19

19. Notation of Activity Diagrams (1) • action node • rectangle with rounded corners and a meaningful name • action edge (control flow) • open arrow Add a New Client Action exists to carry out some task. Assign StaffContact The flow implies that as soon as the first action is complete, the next action is started. 20

20. Add a New Client Assign StaffContact [no campaign to add] [campaign to add] Add New Campaign Notation of Activity Diagrams (2) • initial node • black circle • decision node merge node • diamond • guard condition • in square brackets • final node • black circle in white circle 21

21. Add a New Client Assign StaffContact [no campaign to add] [campaign to add] Add New Campaign [no staff to assign] [staff to assign] Assign Staff to Campaign Tips on Activity Diagrams • Iteration or loop can be represented • Multiple flows from an action are implicitly AND-ed • Guard conditions do not have to be mutually exclusive, but it is advisable that they should be • If they are not, you need to specify the order of evaluation (otherwise the results will be unpredictable) • Decisions should be strictly nested, but a merge point can be combined with the following decision point 22

22. Add a New Client Add New Campaign Assign StaffContact Notation of Activity Diagrams (3) • fork node join node • thick bar • actions carried out in parallel 23

23. OO kicks in • Activity diagrams can represent three structural components of PL • Sequence, selection, iteration • Not only useful for business modelling, but also for operations in classes • Create AD that can model the implementation of operations and can compile into a PL: executable UML • Two ways to show objects • The operation name and class name can be used as the name of an action • An object to provide the input/output of an action

24. Campaign:: Campaign:: calculateCost calculateCost getFirst getFirst ( ( AdvertCollection AdvertCollection ::) ::) getCost getCost (Advert::) (Advert:) getNext getNext ( ( AdvertCollection AdvertCollection ::) ::) [more adverts] [more adverts] [no more adverts] [no more adverts] getOverheads getOverheads (Campaign::) (Campaign::) Notation of Activity Diagrams (4) • class name • can be shown followed by double colons in brackets (parentheses) beneath the action name • Operation Name • can be shown after the colons, when different with the action name 25

25. Campaign [Active] Record completion of a campaign Campaign [Completed] Notation of Activity Diagrams (5) • objects • rectangle • optionally shows the state of the object in square brackets • object flows • open arrow between an object and an action • Result in a change to the state of that object (i.e., the data) 26

26. CampaignManager Accountant Client Record Completion of a campaign Issue invoice Pay invoice Record client payment Notation of Activity Diagrams (6) • activity partitions(swimlanes) • vertical columns • labelled with theperson, organisation,department or system responsible for the activities in that column Where actions take place or who carries out the actions. 27

27. Administrator Campaign Manager Add a New Client Assign StaffContact [no campaign to add] Client [New] [campaign to add] Campaign [Commissioned] Add New Campaign [no staff to assign] [staff to assign] Assign Staff to Campaign [more staff to assign] [no more staff to assign]

28. Activity Diagram for producing a book.

29. Write Chapter Plan Chapter Produce First Draft Revise Draft [not satisfied] [satisfied] Add Exercises Add References to Bibliography More details can be shown on a lower level.

30. Self-Check • Action • Nodes • action node, decision node, initial node, final node, merge node • fork node, join node, • Edges: action edge, guard conditions • OO related: class name, operation name, object flow, activity partition 31

31. Exercise: Supermarket Self-service Checkout 32

32. Requirements Capture

33. Factors on Challenged Software Projects 37% of factors are related to requirements --- C. Larman: Applying UML and Patterns. Prentice Hall, 2004

34. Why Requirement Capture • Identify what a new IS system should be able to do • This is based on the users’ requirements • Need to gather information from users • Requirements include • What the existing system does • What the new system has to do that the existing system does not do

35. Need for New Systems • Organisations operate in a rapidly changing • business and technical environment • Governments and supra-governmental organisations (e.g., EU) may introduce legislation • Information Systems become outdated • Organisations may merge, take over and get taken over • or even simply grow and change the ways they operate 36

36. Investigating Current System • Some of the functionality will be required in the new system • Some of the data must be migrated to the new system • Technical documentation provides details of processing algorithms • Defects of existing system must be avoided • Parts of the existing system may have to be kept • We need to understand the work of the users • Baseline information about the existing system helps set performance targets for the new one 37

37. Current System vs New System • SSADM (Structured Systems Analysis and Design Method) makes the case for modelling the current system — much of its functionality will be required in the new system. • Yourdon (1989) argues against spending a lot of time analysing the existing system — it’s being replaced! Things will develop in the opposite direction when they become extreme. The Golden Mean from Confucianism 38

38. Types of User Requirements • Whether you are investigating the working of the existing system or the requirements of the new system, the information will fall into: • Functional requirements • Non-functional requirements • Usability requirements 39

39. Functional Requirements • What the system does or is expected to do (functionality) • include • descriptions of processing to be carried out • details of the inputs (forms, documents, etc.) • details of the outputs (documents, reports, screens, transfers to other systems) • details of data that must be held in the system • documented in • Use Case models • Class Diagrams, Communication or Sequence Diagrams and State Machine Diagrams 40

40. Non-functional Requirements • How well the system provides the functional requirements • include • performance: response times / volumes of data • availability (downtime), concurrent access • security considerations • … • documented in: • Requirements List • Use Case models (for requirements that can be linked to specific use cases) Support for both Microsoft IE and Mozilla Firefox? 41

41. Measurable Objectives • How can we tell whether the non-functional requirements have been achieved? • Measurable objectives set clear targets for designers • Objectives should be operational and quantified so that they can be tested • by simulation during the design phrase • in prototypes that are built for the propose • in the final system 42

42. Measurable Objectives: Examples • To reduce invoice errors by one-third within a year • How would you design for this? • checks on quantities • comparing invoices with previous ones for the same customer • better feedback to the user about the items ordered • To process 50% more orders at peak periods • How would you design for this? • design for as many fields as possible to be filled with defaults • design for rapid response from database • design system to handle larger number of simultaneous users 43

43. Usability Requirements • How good the system is matched to the way that people work • include: • characteristics of users who will use the system • tasks users undertake (including the goals that they are trying to achieve) • situational factors (that describe the situations that could arise during system use) • acceptance criteria for the working system • … • documented in: • Requirements List (may be tested by prototypes) Unbounded undo/redo? Pop-up free? 44

44. Prioritising Requirements • MoSCoW • Must have requirements are crucial -- the system will not operate without them • Should have requirements are important, but if necessary the system can still operate without them • Could have requirements are desirable, but provide less benefit to the user • Won’t have requirements should be left for a later iteration/increment Rocks, Gravel, Sand and Water 45

45. Fact-Finding Techniques • SQIRO • Document Sampling • Questionnaires • Interviewing • Background Reading • Observation This is not the order they are mostly likely to be used! 46

46. Background Reading • aim: • to understand the organisation and its business objectives • sources of information: • reports • organisation charts • policy manuals • job descriptions • documentation of existing systems • appropriate situations: • analyst is not familiar with the organisation • initial stages of fact finding 47

47. Background Reading • advantages: • helps to understand the organisation before meeting the people who work there • helps to prepare for other types of fact finding • documentation of existing system may provide formally defined requirements for the current system • disadvantages: • written documents may be out of date or not match the way the organisation really operates 48

48. Interviewing • aim: • to get an in-depth understanding of the organisation’s objectives, users’ requirements and people’s roles • includes: • managers to understand objectives • staff to understand roles and information needs • customers and the public as potential users • appropriate situations: • most projects • at the stage in fact finding when in-depth information is required Interviewing guidelines (Box 6.1) 49

49. Interviewing • advantages: • personal contact allows the interviewer to respond adaptively to what is said • it is possible to probe in greater depth • if the interviewee has little or nothing to say, the interview can be terminated • disadvantages: • can be time-consuming and costly • requires skill and sensitivity • notes must be written up or tapes transcribed after the interview • can be subject to bias • if interviewees provide conflicting information this can be difficult to resolve later 50

50. Observation • aim: • to see what really happens, not what people say happens • includes: • seeing how people carry out processes • seeing what happens to documents • obtaining quantitative data as baseline for performance improvements provided by the new system • following a process through end-to-end • appropriate situations: • when quantitative data is required • to verify information from other sources • when conflicting information from other sources needs to be resolved • when a process needs to be understood from start to finish 51