Transcript Data Requirements for the Amanda Model System

ADMS-BIS
Bouwkundige Informatiesystemen
ADMS 2006
UML part 1
Jan Dijkstra - 25 september 2006
ADMS-BIS
Subjects
• Software Engineering
• Software Requirements
– Introduction
– A use case approach
•
•
•
•
•
•
•
UML : Use Case Modelling
Exercise UCD
Discussion exercise UCD
UML Introduction
UML : Activity Diagram
Microsoft Visio
Task UML-part 1
ADMS-BIS
Software Engineering
ADMS-BIS
What is software engineering?
SE is an engineering discipline which is concerned
with all aspects of software production –
implied a systematic and organised approach to the
development operation, and maintenance of software
ADMS-BIS
Software Engineering – Why ?
Software problems
– Bugs: low quality
– High cost: budget overrun
– Late delivery: schedule overrun
ADMS-BIS
Software Engineering – Goal
Make quality software, on time, within budget
–
–
–
–
–
Large and complex systems
Exist in may versions and variants
Last for many years in a changing environment
Undergo frequent changes
Built by project teams
ADMS-BIS
Software Engineering vs. System Engineering
• System engineering is concerned with all aspects of
computer-based systems development including
hardware, software and process engineering
• Software engineering is part of this process
ADMS-BIS
What is software
Computer programs and associated documentation
ADMS-BIS
Nature of software
•
•
•
•
Intangible
Easy to modify
Trivial replication
Labor-intensive
ADMS-BIS
Types of software
Software products may be developed for a particular
customer or may be developed for a general market
– Custom
– Generic
– Embedded
ADMS-BIS
Another categorization of software
• Real time software
– It has to react immediately to stimuli from the environment
• Data processing software
– Is used to run business
ADMS-BIS
Stakeholders in software engineering
• Users
• Customers (clients)
• Software developers
• Development managers
ADMS-BIS
Quality Software
Customer:
User:
solves problems at an
acceptable cost in
terms of money paid
and resources used
easy to learn; efficient
to use; and helps get
work done
Quality Software
Developer:
Development manager:
easy to design; easy
to maintain; and easy
to reuse parts
sells more and pleases
customers while costing less
to develop and maintain
ADMS-BIS
Software Quality
• Usability
• Efficiency
• Reliability
• Maintainability
• Reusability
ADMS-BIS
Software process
• A structured set of activities required to develop a software
system
• Generic activities in all software processes are
– Specification
– Design
– Validation
– Evolution
ADMS-BIS
Compare SE with building a house
•
•
•
•
•
•
•
Search for a location
What type of house
Make a design (architect)
Design  drawings
Realise house
Completion of the house
Use of the house
ADMS-BIS
Software Requirements
Introduction
ADMS-BIS
Requirements engineering
• Get a complete description of the problem
– feasibility study
• Process of establishing the services that the customer
requires from a system
– elicitation
– specification
– validation
ADMS-BIS
Domain analysis
• The process by which you learn about the domain to
better understand the problem
– The domain is the general field of business or technology in which
the clients will use the software
• Benefits of performing domain analysis
– Faster development
– Better system
– Anticipation of extensions
ADMS-BIS
Starting point for software projects
ADMS-BIS
Defining the problem
A problem can be expressed as
– A difficulty the users or customers are facing
– Or as an opportunity that will result in some benefit
ADMS-BIS
Defining the scope
Narrow the scope by defining a more precise problem
• List all the things you might imagine the system doing
– Exclude some of these things if too broad
– Determine high-level goals if too narrow
ADMS-BIS
Defining the scope
Narrow the scope by defining a more precise problem
• List all the things you might imagine the system doing
– Exclude some of these things if too broad
– Determine high-level goals if too narrow
ADMS-BIS
Question ?
Narrow the scope of a university registration system
browsing courses
room allocation
registering
fee payment
exam scheduling
ADMS-BIS
What is a requirement?
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
–
–
–
–
Short and precise piece of information
Says something about the system
All the stakeholders have agreed that it is valid
It helps solve the customer’s problem
ADMS-BIS
Types of requirements 1
• User requirements
– Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers
• System requirements
– A structured document setting out detailed descriptions of the
system services. Written as a contract between client and
contractor
• Software specification
– A detailed software description which can serve as a basis for a
design or implementation. Written for developers
ADMS-BIS
Types of requirements 2
• Functional requirements
Describe what the system should do
• Non-functional requirements
Constraints that must be adhered to during development
ADMS-BIS
Gathering and analyzing requirements
• Observation
– Read documents and discuss with users
– Shadowing important users doing their work
– Session videotaping
• Interviewing
–
–
–
–
Specific details
Alternative ideas
Other sources of information
Draw diagrams
ADMS-BIS
Requirements and design
• In principle, requirements should state what the system
should do and the design should describe how it does this
• In practice, requirements and design are inseparable
ADMS-BIS
Software Requirements
A Use Case Approach
ADMS-BIS
Software Requirements
The Rock Problem ?! [Ed Yourdon]
ADMS-BIS
Software systems nature
• Software systems by their nature are
–
–
–
–
intangible
abstract
complex
infinitely changeable
ADMS-BIS
Software development
• Goal
– to develop quality software that meets customers’ needs
• What is this software supposed to do?
• How will we know when the software does exactly that and
nothing else?
ADMS-BIS
Software requirement
• A software requirement
– is a capability needed by the user to solve a problem to achieve an
objective
– is imposed on the system
ADMS-BIS
Problem domain
• The problem domain
– is the home of those people (real users, other stakeholders)
– whose needs must be addressed
– in order to build the perfect system.
ADMS-BIS
Needs
problem
domain
Features
solution
domain
Software requirements
ADMS-BIS
Stage
Requirements time
.1-.2
Design
.5
Coding
1
Unit test
2
Acceptance test
Maintenance
5
20
Relative cost to repair a defect
Derived from: Alan Davis, Software Requirements: objects,functions and states; Prentice-Hall, 1993
ADMS-BIS
Functional requirements
• Find the solution for the user needs by proposing
objectives for the system that involves
–
–
–
–
problem definition
identifying the users
defining the solution system boundary
identifying the constraints
ADMS-BIS
Defining solutions system boundary
Inputs
System
Outputs
inputs / system / outputs relationship
Of concern:
1. Our system
2. Things that interact with our system
actor
ADMS-BIS
System boundary
System Boundary
I/O
Our Solution
I/O
Users
Other Systems
ADMS-BIS
System perspective
New Solution
System Boundary
Library system
Users
Catalog
system
ADMS-BIS
Use Case approach
library system
Lending services
Library user
User
administration
Library staff
Books
database
ADMS-BIS
Example Use Cases
Videotheek
Huur videoband
Lever nieuwe
banden
KLant
Filmimporteur
Retourneer videoband
ADMS-BIS
NS Ticket machine – a use case approach
Destination
Purchase Ticket
Traveler
Maintenance
basic data
Take ticket
NS
ADMS-BIS
Use Case Modelling
ADMS-BIS
Use Cases
Use Case
• A use case is a set of
sequences of actions a system
performs that yield an
observable result of value to an
actor.
ADMS-BIS
Actors
• An actor represent a coherent
set of roles that users of use
cases play when interacting
with these use cases.
Actor
ADMS-BIS
Organizing Use Cases
•
Use cases can be organized by specifying generalization, include, and
extend relationships.
ADMS-BIS
Generalization
• It means that the child use case
inherits the behaviour and
meaning of the parent use case;
the child may add behaviour of
its parent.
ADMS-BIS
Include (Uses) relationship
• This relationship is used when
there is a common chunk of
behaviour across more than
one use case.
ADMS-BIS
Extend relationship
• It is used to add behaviour to
the base use case at certain
extension points
{ pushing
behaviour into other use cases that
extend it}
ADMS-BIS
Model the Context of a System
• Identify the boundaries
• Identify the actors
• Organize actors
ADMS-BIS
Exercise: Use Cases
& the context of the system
Word Processor
•
•
A simple word processor is
required to create new and
edit existing documents.
Also the ability to print is
required.
Create
New
Editor user
Edit
existing
Print
Printer
ADMS-BIS
Use Cases and Scenarios
•
- Description
- Flow of events
- Variations
- Exceptions
---------------------------------
Use Case
----------------------------------------------------------------Actor
•
Scenarios
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
•
The behaviour of a use case
can be described by a flow of
events;
Separate main (base) versus
alternative flows;
A scenario is an instance of a
use-case.
ADMS-BIS
Example of a Use Case Text
ADMS-BIS
Template of a Use Case Text
ADMS-BIS
Use Case Diagram
•
•
•
•
Subject
Use cases
Actors
Dependency,
generalization, and
association relationships
ADMS-BIS
Model the Requirements of a System
•
•
Establish the context of the
system
Factor common behaviour and
variant behaviour into new use
cases
AND
– Model the use cases, actors
and their relationships
– Describe each use case and
define the scenarios
ADMS-BIS
Exercise: NS Ticket Service machine Use Case Diagram
Destination
•
Describe the Use Case
Diagram of the NS ticket
machine
•
Describe one use case
Single / Retour
No Reduction /
40% reduction
2e class / 1e class
Take ticket
ADMS-BIS
Use Case diagram ‘NS Ticket Service’
NS Ticket Service
Buy OV ticket
«extends»
«uses»
Buy NS ticket
Traveller
Pay ticket
ADMS-BIS
Use Case
Buy OV Ticket
Actors
Traveller
Description
Traveller decides to take a ticket for train or bus and pay for it
Pre-conditions
Traveller has a valid pass
Basic flow
1.
2.
3.
4.
5.
6.
7.
Ticket device expects destination code
Traveller enters destination code
Extension point: NS ticket
Ticket device checks code and calculates the charge.
Shows destination code & fare. Activates ticket machine
for paying
Traveller pays (use case: Pay ticket)
Ticket device print and supplies ticket
Traveller takes ticket
Extension
Destination code = NS station.
3a. Ticket device expects ticket type
3b. Traveller enters Single/Return, Discount Y/N, Class
Exceptions
Traveller interrupt the interaction or walk away
Traveller enters an incorrect destination code
Payment is not finished off successful
Postconditions
Traveller has ticket.
(NS can look forward to the payment)
ADMS-BIS
Short Summary
ADMS-BIS
Core Elements
Construct Description
use case
actor
A sequence of actions, including variants, that a system
(subject) can perform,
interacting with actors of the
system.
Syntax
UseCaseName
A coherent set of roles that
users of use cases play when
interacting with these use
cases.
ActorName
system
boundary
Represents the boundary
between the system and the
actors who interact with the
system.
ADMS-BIS
Core Relationships
Construct
Description
association
The participation of an actor in a
use case. I.e., instance of an actor
and instances of a use case
communicate with each other.
Syntax
extend
A relationship from an extension
use case to a base use case,
specifying how the behaviour for
the extension use case can be
inserted into the behavior defined
for the base use case.
generalization A taxonomic relationship between
a more general use case and a
more specific use case.
<<extend>>
ADMS-BIS
Core Relationships
Construct
Description
Include
(uses)
A relationship from a base use
case to an inclusion use case,
specifying how the behaviour for
the inclusion use case is inserted
into the behaviour defined for the
base use case.
Syntax
<<include>>
(<<uses>>)
ADMS-BIS
Study Matter
•
Ian Sommerville
•
Dean Leffingwell & Don Widrig
Software Engineering , 6th edition – Ch.6
Addison Wesley
Managing Software Requirements, 2nd edition
Addison Wesley
•
Grady Booch, James RumBaugh & Ivar Jacobson
•
Martin Fowler
The Unified Modeling Lnaguage – Covers UML 2.0, 2nd edition
Addison Wesley
UML Distilled, 3nd edition
Addison Wesley
•
Fowler & Scott
UML beknopt, 2nd edition
Addison Wesley
•
Sander Hoogendoorn
Pragmatisch modelleren met UML 2.0
Addison Wesley
ADMS-BIS
Exercise
A library lends books to borrowers, who are registered in a
membership file. A borrower can reserve a book that is not
currently available in the library. In a file of books the loaning
or reservation of a book will be kept up to date. The librarian is
an employee of the library who interacts with the customers
(borrowers).
o
Design a simple library system for borrowing and
returning books. The file of books and the membership file
may be considered as actors.
o
text.
Describe one or more use cases by means of a use case
ADMS-BIS
Exercise Solution : UCD
Library System
Borrow a book
Books Database
Desk clerk
Retrurn a book
Member/Borrower
Memebers database
ADMS-BIS
Exercise Solution : Use Case Text
Use case
Borrow a book
Description
A member borrows a book from the library
Actors
Borrower, Desk clerk, Members database, Books database
Pre-conditions
Borrower has a valid pass and has given this to the desk
clerk with the book(s)
Basic flow
o Pass is scanned
o Borrower wants to reserve a book  Book
Reserve a book
o System verifies book data and member data
o Members database and Books database will be
updated
Exceptions
Borrower is not authorized to borrow a book.Book is missing
Post-conditions
Borrower has books or there is made a reservation of books.
ADMS-BIS
Exercise UCD
Starting point is the MKW case
• Make a Use Case Diagram of the MKW system and
describe the use cases with a use case text.
ADMS-BIS
Date2date
Date2date is een commerciële online dating service, waarmee singles in
betrekkelijke anonimiteit contact kunnen leggen met andere
alleenstaanden.
 De slides m.b.t. Date2date zijn ontleend aan het boek van Sander
Hoogendoorn, zie “Study Matter”.
ADMS-BIS
Date2date : the context
Date2date
ADMS-BIS
Date2date : UCD van een Use Case (element)
ADMS-BIS
Date2date : UCD van een Use Case (element)
ADMS-BIS
Date2date : UCD van een Use Case (element)
ADMS-BIS
Date2date : use case text van “versturen bericht”
ADMS-BIS
Date2date : use case text with scenario’s
ADMS-BIS
Next
9 Oktober 2006
• Study of UML exercises and examples
• Each group works on Exercise UCD (slide 70)