IMAT1906 Systems Development Lecture week 8: systems analysis (3) : logical system
Jan 11, 2016
IMAT1906 Systems Development
Lecture week 8: systems analysis (3) : logical system
Today’s Agenda
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-112
Modelling logical system to meet requirements
Use case model Data flow diagrams Blackboard survey
Purpose
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-113
By now we have found the requirements, from our fact-finding activities
Now we need to model the logical system to meet the requirements
Modelling tools
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-114
There are several modelling tools we can use Use case model Data flow diagrams Data model Structured English Decision tables
Use case model
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-115
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
Use case diagram (1)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-116
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
Use case diagram (2)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-117
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
Use case description (1)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-118
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
Use case description (2)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-119
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
Use case description (3)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1110
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
Use case description (4)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1111
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
Use case model examples
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1112
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
Use case model summary
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1113
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
Where we are on agenda
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1114
Modelling logical system to meet requirements
Use case model Data flow diagrams Blackboard survey
Data flow diagrams (DFDs)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1115
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
Levels of complexity
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1116
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
Elements of DFD
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1117
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
Duplicate elements
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1118
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
Context diagram - purpose
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1119
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
Context diagram - contents
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1120
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-1121
Level 1 diagram - overview
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1122
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
Level 1 diagram - contents
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1123
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
Level 1 diagram – notation
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1124
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
Level 1 diagram – how to do (1)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1125
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
Level 1 diagram – how to do (2)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1126
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
Level 1 diagram – how to do (3)
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1127
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-1128
Level 2 diagram
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1129
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-1130
Data flow diagram summary
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1131
Shows what happens in system How processing transforms inputs into
outputs What data stores are needed Levels of complexity describe processes
within processes
Further information
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1132
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
Where we are on agenda
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1133
Modelling logical system to meet requirements
Use case model Data flow diagrams Blackboard survey
Survey background
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1134
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
Survey method
IMAT 1906 Lecture Week 8 (c) De Montfort University 2010-1135
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