78
Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

  • View
    225

  • Download
    3

Embed Size (px)

Citation preview

Page 1: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

Bouwkundige InformatiesystemenADMS 2006

UML part 1

Bouwkundige InformatiesystemenADMS 2006

UML part 1

Jan Dijkstra - 25 september 2006

AD

MS

-BIS

Page 2: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

SubjectsSubjects

• Software Engineering• Software Requirements

– Introduction– A use case approach

• UML : Use Case Modelling• Exercise UCD• Discussion exercise UCDDiscussion exercise UCD• UML IntroductionUML Introduction• UML : Activity DiagramUML : Activity Diagram• Microsoft VisioMicrosoft Visio• Task UML-part 1Task UML-part 1

Page 3: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software EngineeringSoftware Engineering

Page 4: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

What is software engineering?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

Page 5: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software Engineering – Why ?Software Engineering – Why ?

Software problems– Bugs: low quality– High cost: budget overrun– Late delivery: schedule overrun

Page 6: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software Engineering – GoalSoftware 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

Page 7: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software Engineering vs. System EngineeringSoftware 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

Page 8: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

What is softwareWhat is software

Computer programs and associated documentation

Page 9: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Nature of softwareNature of software

• Intangible• Easy to modify• Trivial replication• Labor-intensive

Page 10: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Types of softwareTypes of software

Software products may be developed for a particular customer or may be developed for a general market

– Custom

– Generic

– Embedded

Page 11: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Another categorization of softwareAnother categorization of software

• Real time software– It has to react immediately to stimuli from the environment

• Data processing software– Is used to run business

Page 12: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Stakeholders in software engineeringStakeholders in software engineering

• Users

• Customers (clients)

• Software developers

• Development managers

Page 13: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Quality Software Quality Software

Quality Software

Customer:solves problems at an acceptable cost in terms of money paid and resources used

User:easy to learn; efficient to use; and helps get work done

Developer:easy to design; easy to maintain; and easy to reuse parts

Development manager:sells more and pleases customers while costing less to develop and maintain

Page 14: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software QualitySoftware Quality

• Usability

• Efficiency

• Reliability

• Maintainability

• Reusability

Page 15: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software processSoftware process

• A structured set of activities required to develop a software system

• Generic activities in all software processes are

– Specification

– Design

– Validation

– Evolution

Page 16: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Compare SE with building a houseCompare 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

Page 17: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software RequirementsIntroduction

Software RequirementsIntroduction

Page 18: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Requirements engineeringRequirements 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

Page 19: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Domain analysisDomain 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

Page 20: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Starting point for software projectsStarting point for software projects

Page 21: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Defining the problemDefining 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

Page 22: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Defining the scopeDefining 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

Page 23: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Defining the scopeDefining 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

Page 24: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Question ?Question ?

Narrow the scope of a university registration system

browsing courses

registering

fee payment

room allocation

exam scheduling

Page 25: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

What is a requirement?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

Page 26: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Types of requirements 1Types 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

Page 27: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Types of requirements 2Types of requirements 2

• Functional requirementsDescribe what the system should do

• Non-functional requirementsConstraints that must be adhered to during development

Page 28: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Gathering and analyzing requirementsGathering 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

Page 29: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Requirements and designRequirements 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

Page 30: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software RequirementsSoftware Requirements

A Use Case Approach

Page 31: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software RequirementsSoftware Requirements

The Rock Problem ?! [Ed Yourdon]

Page 32: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software systems natureSoftware systems nature

• Software systems by their nature are– intangible– abstract– complex– infinitely changeable

Page 33: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software developmentSoftware 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?

Page 34: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Software requirementSoftware requirement

• A software requirement – is a capability needed by the user to solve a problem to achieve an

objective– is imposed on the system

Page 35: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Problem domainProblem 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.

Page 36: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Needs

Features

Software requirements

problemdomain

solutiondomain

Page 37: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Stage

Relative cost to repair a defect

Derived from: Alan Davis, Software Requirements: objects,functions and states; Prentice-Hall, 1993

Requirements time

Design

Coding

Unit test

Acceptance test

Maintenance

.1-.2

.5

1

2

5

20

Page 38: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Functional requirementsFunctional 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

Page 39: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Defining solutions system boundaryDefining solutions system boundary

SystemInputs Outputs

inputs / system / outputs relationship

Of concern:

1. Our system

2. Things that interact with our system

actor

Page 40: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

System boundarySystem boundary

Our Solution

Users

Other Systems

System Boundary

I/O

I/O

Page 41: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

System perspectiveSystem perspective

New Solution

Users

Catalog system

System Boundary

Library system

Page 42: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Use Case approachUse Case approach

Lending services

User administration

Books database

Library user

Library staff

library system

Page 43: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Example Use CasesExample Use CasesVideotheek

Huur videoband

Lever nieuwebanden

Retourneer video-band

KLant

Filmimporteur

Page 44: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

NS Ticket machine – a use case approachNS Ticket machine – a use case approach

Traveler

Purchase Ticket

Maintenance basic data

NSTake ticket

Destination

Page 45: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Use Case ModellingUse Case Modelling

Page 46: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Use CasesUse Cases

• A use case is a set of sequences of actions a system performs that yield an observable result of value to an actor.Use Case

Page 47: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

ActorsActors

• An actor represent a coherent set of roles that users of use cases play when interacting with these use cases.

Actor

Page 48: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Organizing Use CasesOrganizing Use Cases

• Use cases can be organized by specifying generalization, include, and extend relationships.

Page 49: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

GeneralizationGeneralization

• 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.

Page 50: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Include (Uses) relationshipInclude (Uses) relationship

• This relationship is used when there is a common chunk of behaviour across more than one use case.

Page 51: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Extend relationshipExtend 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}

Page 52: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Model the Context of a SystemModel the Context of a System

• Identify the boundaries• Identify the actors• Organize actors

Page 53: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Exercise: Use Cases & the context of the system

Exercise: Use Cases & the context of the system

• A simple word processor is required to create new and edit existing documents.

• Also the ability to print is required. Editor user

Create New

Edit existing

Print

Printer

Word Processor

Page 54: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Use Cases and ScenariosUse Cases and Scenarios

- Description- Flow of events- Variations- Exceptions

Actor

----------------------------------

--------------------------------------------------------------------

----------------------------------

--------------------------------------------------------------------

----------------------------------

--------------------------------------------------------------------

----------------------------------

--------------------------------------------------------------------

Use Case

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.

Page 55: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Example of a Use Case TextExample of a Use Case Text

Page 56: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Template of a Use Case TextTemplate of a Use Case Text

Page 57: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Use Case DiagramUse Case Diagram

• Subject• Use cases• Actors• Dependency,

generalization, and association relationships

Page 58: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Model the Requirements of a SystemModel 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

Page 59: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Exercise: NS Ticket Service machine Use Case DiagramExercise: NS Ticket Service machine Use Case Diagram

• Describe the Use Case Diagram of the NS ticket machine

• Describe one use case

Take ticket

Destination

Single / Retour

No Reduction / 40% reduction

2e class / 1e class

Page 60: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Use Case diagram ‘NS Ticket Service’Use Case diagram ‘NS Ticket Service’

NS Ticket Service

Traveller

Buy OV ticket

Buy NS ticket

Pay ticket

«extends»

«uses»

Page 61: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Traveller has ticket.

(NS can look forward to the payment)Post-conditions

Traveller interrupt the interaction or walk away

Traveller enters an incorrect destination code

Payment is not finished off successful

Exceptions

Destination code = NS station.

3a. Ticket device expects ticket type

3b. Traveller enters Single/Return, Discount Y/N, Class

Extension

1. Ticket device expects destination code

2. Traveller enters destination code

3. Extension point: NS ticket

4. Ticket device checks code and calculates the charge. Shows destination code & fare. Activates ticket machine for paying

5. Traveller pays (use case: Pay ticket)

6. Ticket device print and supplies ticket

7. Traveller takes ticket

Basic flow

Traveller decides to take a ticket for train or bus and pay for it

Traveller has a valid pass

Description

Pre-conditions

TravellerActors

Buy OV TicketUse Case

Traveller has ticket.

(NS can look forward to the payment)Post-conditions

Traveller interrupt the interaction or walk away

Traveller enters an incorrect destination code

Payment is not finished off successful

Exceptions

Destination code = NS station.

3a. Ticket device expects ticket type

3b. Traveller enters Single/Return, Discount Y/N, Class

Extension

1. Ticket device expects destination code

2. Traveller enters destination code

3. Extension point: NS ticket

4. Ticket device checks code and calculates the charge. Shows destination code & fare. Activates ticket machine for paying

5. Traveller pays (use case: Pay ticket)

6. Ticket device print and supplies ticket

7. Traveller takes ticket

Basic flow

Traveller decides to take a ticket for train or bus and pay for it

Traveller has a valid pass

Description

Pre-conditions

TravellerActors

Buy OV TicketUse Case

Page 62: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Short SummaryShort Summary

Page 63: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Core ElementsCore Elements

Construct Description Syntax

use case A sequence of actions, inclu-ding variants, that a system (subject) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the system and the actors who interact with the system.

UseCaseName

ActorName

Page 64: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Core RelationshipsCore Relationships

Construct Description Syntax

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.

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>>

Page 65: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Core RelationshipsCore Relationships

Construct Description Syntax

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.

<<include>> (<<uses>>)

Page 66: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Study MatterStudy Matter• Ian Sommerville

Software Engineering , 6th edition – Ch.6Addison Wesley

• Dean Leffingwell & Don WidrigManaging Software Requirements, 2nd editionAddison Wesley

• Grady Booch, James RumBaugh & Ivar JacobsonThe Unified Modeling Lnaguage – Covers UML 2.0, 2nd editionAddison Wesley

• Martin FowlerUML Distilled, 3nd editionAddison Wesley

• Fowler & ScottUML beknopt, 2nd editionAddison Wesley

• Sander HoogendoornPragmatisch modelleren met UML 2.0Addison Wesley

Page 67: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

ExerciseExercise

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 Describe one or more use cases by means of a use case text.

Page 68: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Exercise Solution : UCDExercise Solution : UCD

Library System

Borrow a book

Retrurn a book

Books Database

Memebers database

Desk clerk

Member/Borrower

Page 69: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Exercise Solution : Use Case TextExercise Solution : Use Case Text

Borrower has books or there is made a reservation of books.Post-conditions

Borrower is not authorized to borrow a book.Book is missingExceptions

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

Basic flow

Borrower has a valid pass and has given this to the desk clerk with the book(s)

Pre-conditions

Borrower, Desk clerk, Members database, Books databaseActors

A member borrows a book from the libraryDescription

Borrow a bookUse case

Borrower has books or there is made a reservation of books.Post-conditions

Borrower is not authorized to borrow a book.Book is missingExceptions

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

Basic flow

Borrower has a valid pass and has given this to the desk clerk with the book(s)

Pre-conditions

Borrower, Desk clerk, Members database, Books databaseActors

A member borrows a book from the libraryDescription

Borrow a bookUse case

Page 70: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Exercise UCDExercise 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.

Page 71: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2dateDate2date

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”.

Page 72: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2date : the contextDate2date : the context

Date2date

Page 73: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2date : UCD van een Use Case (element)Date2date : UCD van een Use Case (element)

Page 74: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2date : UCD van een Use Case (element)Date2date : UCD van een Use Case (element)

Page 75: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2date : UCD van een Use Case (element)Date2date : UCD van een Use Case (element)

Page 76: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2date : use case text van “versturen bericht”Date2date : use case text van “versturen bericht”

Page 77: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

Date2date : use case text with scenario’sDate2date : use case text with scenario’s

Page 78: Bouwkundige Informatiesystemen ADMS 2006 UML part 1 Jan Dijkstra - 25 september 2006 ADMS-BIS

AD

MS

-BIS

NextNext

9 Oktober 2006

• Study of UML exercises and examples

• Each group works on Exercise UCD (slide 70)