SEEING THE WOOD FROM THE TREES

1
SEEING THE WOOD FROM THE TREES

• Issue with two lectures a week great detail but
  how does it all fit ?
• In this lecture we will review
• A high-level example of a complete system
  analysis design
• The practical project that will from a major part
  of the work of this module

2
Introductory Case Study

• The Problem
•    You have been contracted to develop a
  computer system for a university library. Current
  system does some simple bookkeeping, and allows
  browsing. Library wants interactive online
  system covering these aspects.

3
Requirements more detail needed !

• The library contains books and journals. It may
  have several copies of a given book. Some of the
  books are for short term loans only. All other
  books may be borrowed by any library member for
  three weeks. Members of the library can normally
  borrow up to six items at a time, but members of
  staff may borrow up to 12 items at one time. Only
  members of staff may borrow journals
•   Books Journals
• Some items are short-loans
• All members borrow for 3 weeks
• Journals only borrowed by
• Library members borrow 6 items, Staff 12
• New items arrive and old items disposed
• Borrowing
• Track borrowings and returns
• Produce reminders for overdue books
• May be need for extension facility
• Browsing
• Users should search for book, check
  availability, reserve

4
Requirements - Use Case Model

• Use Case Model user-oriented approach to systems
  analysis.
• An actor is a user of the system in a particular
  role. Can be an external system or many different
  job descriptions. e.g. BookBorrower
• A use case is a task that an actor needs to
  perform with the help of the system, e.g. Borrow
  copy of book.
• Name use case after what happens in the generic
  case.
• Record this information in a use case diagram.
• For each use case, document a use case
  description

5
Requirements - Use Case Model
Borrow copy of book A BookBorrower presents a
book. The system checks that the potential
borrower is a member of the library...........
    If a diagram is too complex to be drawn by
hand, should be drawn at a higher level of
abstraction. For example, we have condensed all
the Librarian's tasks into Update catalog. Do not
invent requirements to demonstrate one's
intelligence. Make a list of ambiguities and
questions with each use case description, discuss
with stakeholders. User interface assume that
job is to build underlying system, providing
functionality that will be invoked through the UI
which will be designed and developed by UI
engineers. Separation of system and UI
important.

•   

6
Software Development Process Scope and
Iterations

• Single release approach to systems development
  has long history of failures.
• Instead, several iterations through development
  process.
• First iteration delivery of system with very
  basic functionality.
• An iteration can deliver enough of the system to
  allow certain use case to be followed out, but
  not others.
• First iteration develop following use cases -
• Borrow a copy of book
• Return copy of book
• Borrow a journal
• Return journal.
• In a real project, might have to diagram and
  describe all use cases in first iteration, serves
  as a contractual basis. Then apply scope. Hence
  first iteration use case model

7
Analysis Identifying Classes

• Identify the key domain abstractions.
  Abstractions equal classes.
• Use noun identification technique applied to
  requirements.
• Underline nouns and noun phrases to derive a list
  of candidate classes.
• Data driven design (DDD) versus responsibility
  driven design (RDD).
• Books and journals The library contains books
  and journals. It may have several copies of a
  given book. Some of the books are for short term
  loans only. All other books may be borrowed by
  any library member for three weeks. Members of
  the library can normally borrow up to six items
  at a time, but members of staff may borrow up to
  12 items at one time. Only members of staff may
  borrow journals.
•  
• Borrowing The system must keep track of when
  books and journals are borrowed and returned,
  enforcing the rules described above.

8
Analysis Identifying Classes

• Identify the key domain abstractions.
  Abstractions equal classes.
• Use noun identification technique applied to
  requirements.
• Underline nouns and noun phrases to derive a list
  of candidate classes.
• Data driven design (DDD) versus responsibility
  driven design (RDD).
• Books and journals The library contains books
  and journals. It may have several copies of a
  given book. Some of the books are for short term
  loans only. All other books may be borrowed by
  any library member for three weeks. Members of
  the library can normally borrow up to six items
  at a time, but members of staff may borrow up to
  12 items at one time. Only members of staff may
  borrow journals.
•  
• Borrowing The system must keep track of when
  books and journals are borrowed and returned,
  enforcing the rules described above.
• Discard those that are not good candidates.
• library because it is outside the scope of our
  system.
• short term loan an event, not a useful object.
• member of the library same as library member.
• week measure of time, not a thing.
• item vague.
• time outside scope of system
• system part of meta-language of requirements
  description, not part of domain.
• rules same reason.
• The following classes are left

9
Analysis Identifying Classes

• System's users do not have to be represented
  inside the system unless the system is required
  to keep data about each user. In that case, model
  the users as classes.
• Make system objects representing actors
  responsible for carrying out actions on behalf of
  those actors.
• E.g., when Ann borrows a book, the message
  borrow(theCopy) will be sent to the LibraryMember
  object which represents Ann.
• Data dictionary - overkill at this stage.

10
Relations (Associations) between Classes
11
Revise Model
12
System in Action borrow a book !

• Not yet described dynamic behaviour e.g. record
  how objects in the system interact to allow a
  user to borrow a copy of a book.
• Employ interaction diagrams.
• Diagram that illustrates how messages are passed
  between objects.
• Need not do this for every use case.
• In this example, fixed order, only one thread of
  activity, and activities cannot execute in
  parallel.
• Can by attaching times to activities, can deal
  with real-time problems.
• Could also use a collaboration diagram.

13
Important objects may change state e.g. book
14
Reading
Using UML Stevens Pooley Chapter
3.
15
Project

• Produce a Systems Analysis and Design
• Team-based
• Details can be found on web www.csis.ul.ie
• Current Students
• Module Materials
• Autumn Semester
• CS4125

16
Project - Teams

• Labs will be key to successful project
• By end of Lab3 (week 5) all teams must be formed
• 3 people per team
• Must be identifed on lab3 worksheet.
• Placements for LabA and LabB will be modified to
  reflect teams from Lab4 (week 6)

17
Project

• Identify a system to be modelled
• Examples
• Airline reservation system.
• Hotel reservation system.
• Car hire system.
• Online banking.
• Online stock trading.
• Student record system

18
Project - Output

• Design Document
• Front cover
• Blank Marking Scheme
• Table of contents
• System Narrative
• System Architecture
• Discussion on Software Lifecycle Model
• Requirements (Functional, non-functional, GUI,
  reports)
• Analysis (Class diagram, sequence collaboration
  diagrams, state chart, entity-relationship
  diagram)
• Design (Refine analysis artefacts)
• Description of style/pattern used
• Data Dictionary
• Team activities description

19
Project Marking Scheme

• Details of marking scheme may be found on web
• Vital you understand marking scheme do not
  place too much focus on incorrect artefact
• Slightly false scenario academic exercise
• May put more emphasis on requirements in
  real-world
• Exercise to expose student to entire ooad
  experience
• Including practical usage of CASE tool !!