IMAT1906 Systems Development

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


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


There are several modelling tools we can use Use case model Data flow diagrams Data model Structured English Decision tables

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

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

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

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



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



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



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


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


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




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

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

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

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

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

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


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

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

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

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



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



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


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


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

Further information


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




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

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

Date post:	11-Jan-2016
Category:	Documents
Upload:	leoma
View:	29 times
Download:	0 times

IMAT1906 Systems Development

Documents