1. www.monash.edu.au IMS1805 Systems Analysis Topic 3: Doing analysis (cont)

2. www.monash.edu.au 2 Recap of last three lectures The importance of understanding the purpose of analysis Some important purposes: Organisational; Technological; Development team The purposes behind various types of models (FDD/DFD/ERD/O-O/Soft systems)

3. www.monash.edu.au 3 Agenda Aim: To develop further your skills in using analytical techniques To identify some of the main problem areas students have in applying these techniques

4. www.monash.edu.au 4 1. Issues in process modelling: (a) physical vs logical models Physical actions versus information transformations People/places/times vs logical information events Note: Physical models are not ‘wrong’ – unless you are asked for a logical model! Why bother with the distinction? The importance of “seeing” pure information elements, not physical objects Examples from tute exercise

5. www.monash.edu.au 5 Issues in process modelling: (b) actions and data flow elements Relating physical actions to information processes Understanding/interpreting actions as data flow elements other than processes Seeing the overall picture: recognising the problems arising from poor process selection and re-thinking the process Examples from tute exercise

6. www.monash.edu.au 6 Issues in process modelling: (c) hierarchy and abstraction in processes The concept of hierarchy of processes Low-level vs high-level processes Composite (multi-process) processes vs single processes Implications for process names Why bother with the distinction? The importance of “seeing” both top and bottom level processes Examples from tute exercise

7. www.monash.edu.au 7 Issues in process modelling: (d) naming data flow elements ‘Bad’ names vs ‘good’ names Processes = verb + name (what transformation occurs + what data is transformed) High-level process names vs low-level process names Names as a clue to how clearly you are thinking Examples from tute exercise

8. www.monash.edu.au 8 Issues in process modelling: (e) testing your process model Putting the pieces together for an FDD: Every element of the diagram is a process Every low-level (child) process is a component of its associated higher-level (parent) process Every high-level (parent) process is fully described by its associated lower-level (child) processes Putting the pieces together for a DFD: Every process must have data inputs and data(/info) outputs Every data input/output must have a process at one end and either a process, data store or external agent at the other end All inputs must be used by a process to create all its outputs Processes ‘fit together’ in the same levels as in the FDD Examples from tute exercise

9. www.monash.edu.au 9 2. Issues in data modelling: (a) choosing your entities ‘Things’ which are involved in or part of the system vs ‘things’ about which the system needs to store information The first test for any entity: what are its attributes? (ie what does this system need to store as information about it (and why)?) Seeing an entity as a table in a database Examples from tute exercise

10. www.monash.edu.au 10 Issues in data modelling: (b) distinguishing attributes and entities Features which are inherently part of something (attributes) vs features which are connected/related to it. (Perhaps a different entity or an attribute of a different entity?) The first test for any attribute: does it have attributes as well? (ie does this system need to store as information about it?) If so, should it be an entity in its own right? Seeing an attribute as a field (column) in a database record Examples from tute exercise

11. www.monash.edu.au 11 Issues in data modelling: (c) identifying relationships What connections does the system need to be able to make between entities? Seeing a relationship as the basis for setting rules for a database to enforce about its entities Seeing a relationship as the basis on which queries can be built between database tables Examples from tute exercise

12. www.monash.edu.au 12 3. Issues in soft systems modelling: (a) identifying stakeholder positions Do all people involved in a system have attitudes towards it OR are people neutral users who simply supply/extract information? Do people involved in a system have ‘rights’ which should be acknowledged and taken into account? Is it sensible to ignore people’s attitudes/rights towards a system? Examples from tute exercise

13. www.monash.edu.au 13 4. Issues in O-O modelling: (a) identifying objects How easy is it for you to identify: Actions? Processes? Entities? How easy is it for you to identify objects? How easy is it to create objects from composites of processes and entities? Examples from tute exercise

14. www.monash.edu.au 14 Administration Assignment documents New assignment deadline No lecture on Monday, August 29th