1 / 35

IMAT1906 Systems Development

IMAT1906 Systems Development. Lecture week 8: systems analysis (3) : logical system. Today’s Agenda. Modelling logical system to meet requirements Use case model Data flow diagrams Blackboard survey. Purpose. By now we have found the requirements, from our fact-finding activities

leoma
Download Presentation

IMAT1906 Systems Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IMAT1906 Systems Development Lecture week 8: systems analysis (3) : logical system

  2. Today’s Agenda • Modelling logical system to meet requirements • Use case model • Data flow diagrams • Blackboard survey IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  3. Purpose • By now we have found the requirements, from our fact-finding activities • Now we need to model the logical system to meet the requirements IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  4. Modelling tools • There are several modelling tools we can use • Use case model • Data flow diagrams • Data model • Structured English • Decision tables IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  5. Use case model • Use case model consists of • Use case diagrams + use case descriptions • Use case diagram • Simple model that shows who requires which function in the system • Functions and requirements identified in overall fact finding • Use case description • Clear concise explanation of what the function does • Entries come from detailed fact finding • We have seen these for documentation • Can also be used for analysis and design of a new system IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  6. Use case diagram (1) • Actors • Users and other systems that interact with this system • Shown as matchstick figures • Use cases • Things the system does • Things the users need the system to do for them • Functions or processes • Shown as ovals • Connections • Link actors with use cases • Shown as lines IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  7. Use case diagram (2) • System boundary • Depicts system scope • Actors are outside the system • Use cases are inside the system • Shown as a box • Dependencies • Use cases may relate to each other without being the same • One may always include the same steps: use <<include>> • One may sometimes lead to another: use <<extends>> • Can be drawn by hand or on a CASE tool • We saw examples of bookshop and Monte Cerino IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  8. Use case description (1) • Gives the details behind a use case • One description per use case • Several entries • More than one possible title for some entries • Doesn't matter which you choose • Be consistent across the use case model • Use same entries on all descriptions, even if blank or not applicable • Needs to be clear but not over-wordy • Name • The name of the use case on the diagram • Reflects the function or process being described • Use whatever term the business people talked about IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  9. Use case description (2) • Actor(s) • Anyone or anything that will interact directly with the system • Can have more than one actor • Goal or description • What process is being described • Brief summary of what the use case does • If business people have used more than one phrase to describe a function’s purpose, include their phrases so they can relate to the use case • Scope • Which system the use case is part of eg bookshop • What unit of work the use case covers eg single book IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  10. Use case description (3) • Primary actor • Sometimes there is one particular actor who instigates a use case or starts it running • Stakeholder(s) • Anyone with a work-related interest in the function • Preconditions • What needs to have been done or what needs to be true before the use case can start • Successful completion • Steps taken by both actor and system to carry out the process • Process flow when nothing goes wrong • Reads like a conversation between actor and system IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  11. Use case description (4) • Alternatives • Steps taken by both actor and system to deal with error situations • Can also describe non-standard or unusual situations • Sometimes called Extensions • Postconditions • What has been done or what is true after the use case has completed • What has changed as a result of the process IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  12. Use case model examples • We have seen use case diagrams and descriptions for • Restaurant – Monte Cerino model, in the first Qsee trainer • Bookshop - Student 2 Student, in the lab sessions • Bookshop is a simple system • And it has a simple use case model • Restaurant is a little more complex • And it has more use cases in its diagram • Also more connections between use cases IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  13. Use case model summary • Use case model shows what happens in the system • Can be used to depict overall or outline requirements • Can be used to design processes needed in a new system • Can be used to indicate which processes link together IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  14. Where we are on agenda • Modelling logical system to meet requirements • Use case model • Data flow diagrams • Blackboard survey IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  15. Data flow diagrams (DFDs) • Show what happens in a system and the logic of how it happens, along with the data needed • Can be used at several stages in system development process depending on needs: • If replacing existing system, DFDs can show current physical system ie what is done and how • this DFD gives the current physical model • DFD can show the logic behind the current physical system, concentrating on what is done without reference to how • this DFD gives the current logical model • DFD can show the logic and data needed in the new system • this DFD gives the required logical model IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  16. Levels of complexity • Levels of diagram and complexity • Context diagram – sometimes called Level 0 diagram • Level 1 diagram – shows main processes • Level 2 diagram – breaks a complex process down into smaller processes • Levels are in a hierarchy • Lower-level diagrams are said to further explain or decompose higher-level diagram it came from IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  17. Elements of DFD • Elements of DFD are the same at all levels of complexity • Process • shown as box • External entity • shown as oval • Data store • shown as open-ended box • Flow of information or data • shown as arrow • Every element is named to indicate what it does • We have seen these in the lab sessions weeks 7 and 8 IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  18. Duplicate elements • Duplicate elements • Included to make DFD more readable • Use diagonal line at top left corner to show duplicates • But note that QSee does not put the diagonal line on the diagram • Often used for external entities • Sometimes used for data stores IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  19. Context diagram - purpose • Shows where the system will fit in its surrounding context • Flow of information / data / requests / results between actors and system • Also shows scope of system • What is in the system • What is outside the system • Can be used to discuss the requirements with the business people • Good idea to confirm the scope of the system at the design stage before much development effort has been spent IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  20. Context diagram - contents • Whole system shown as an empty box • Each actor or external entity shown as an oval • Each way in which actors interact with system is shown as a data flow • Arrow from actor to system for inputs or requests for information • Arrow from system to actor for outputs, results of requests, and reminders IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  21. IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  22. Level 1 diagram - overview • Shows what goes on inside the system • Links to context diagram for the system • Level 1 diagram decomposes the context diagram • CASE tool often uses the context diagram as a skeleton to start off the level 1 diagram • Tool knows from the context diagram what is outside the system and what interactions are planned • Puts those things on the level 1 diagram ready for connection to processes IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  23. Level 1 diagram - contents • Shows more detail about what’s in the system • Processes • Data stores • Data flows • External entities from the context diagram • Usually starts at the beginning of major processing • Works through main flow of data in system eg one order • Follows it through the system • Describes various processes that happen to the data (eg the order) along the way IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  24. Level 1 diagram – notation • Elements • Same as for context diagram • Processes in boxes • Data stores in open boxes • Data flows are arrows • External entities in ovals outside the system • All with names IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  25. Level 1 diagram – how to do (1) • Data flows • Show information passed between components of the system • Flow pointing into a data store means some form of update - could be add, amend, delete • Flow pointing out of a data store means read without update IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  26. Level 1 diagram – how to do (2) 26 IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11 • Data flow rules • Every process must have at least one input data flow and at least one output data flow • Data doesn’t come from nowhere • Process cannot swallow data • All data output from a process must be related to inputs • No data flow between external entity and data store • Some process needs to transfer the data • No data flow from data store to data store • Some processing needs to happen to get the data from place to place

  27. Level 1 diagram – how to do (3) • Method • Start with first step in major flow through system • Add processes for the steps • Attach known data flows from context diagram to processes • Add data stores the processes work with • Attach data flows between processes and data stores • Check for unconnected data flows from external entities • Put in processes needed to connect them • Check for exception processes or minor processes that are missing • Put them in • Check the model – QSee can do a lot of the checking IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  28. IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  29. Level 2 diagram • If any process on the level 1 diagram is quite large then split or decompose the complex process by creating a level 2 diagram for it • The level 2 diagram is not usually so big as a level 1 diagram • Notation and method are the same as for the level 1 diagram • Processes as boxes • Data stores as open boxes • Data flows as arrows • Same rules for data flows IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  30. IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  31. Data flow diagram summary • Shows what happens in system • How processing transforms inputs into outputs • What data stores are needed • Levels of complexity describe processes within processes IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  32. Further information 32 IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11 • Use case models • Skidmore & Eva pp 100-107 • Cadle et al pp 205-211 • Shelly & Rosenblatt pp 147-148, 257-260 • Schneider & Winters chapters 1-4 • Data flow diagrams • Skidmore & Eva pp 111-119 • Shelly & Rosenblatt pp 198-205

  33. Where we are on agenda • Modelling logical system to meet requirements • Use case model • Data flow diagrams • Blackboard survey IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  34. Survey background • One thing I am doing, with other tutors, is research into student feedback and making it more meaningful to you • Tutors give you feedback: • In labs and tutorials • In comments on assignments • In answers to your questions • Students give us feedback: • At end of module • At end of year • But I want to know what you think now in the middle of the year so I can solve any problems IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

  35. Survey method • Short questionnaire on Blackboard • In the Student Feedback area – this is a new option on the left hand side menu of the module home page • There are about 12 questions • One module mark is available to those who take part • There is likely to be a similar survey at the end of next term IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-11

More Related