Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 3 - PowerPoint PPT Presentation

1 / 62
About This Presentation
Title:

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 3

Description:

... system uses manual booking sheets. 3/23/09. CPSC-4360 ... Head waiter (assigns tables etc). Individual user may play one or more roles at different times. ... – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 63
Provided by: NUS171
Category:

less

Transcript and Presenter's Notes

Title: Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 3


1
Software Engineering, CPSC-4360-01,
CPSC-5360-01,Lecture 3 
2
Overview of the Last Lecture
  • Software Development Models
  • Waterfall Model
  • Evolutionary Models
  • Incremental Model
  • Spiral Model
  • Unified Process
  • Overview of UML
  • History
  • 4 1 View models
  • Using UML in UP

3
Overview of This Lecture
  • Introduction to Case Studies
  • Requirement Gathering
  • Use Case Modeling
  • Domain Modeling / Business Modeling
  • Activity Diagram

4
Case Study 1 The Restaurant
  • Example developed in the Practical
    Object-Oriented Design With UML by Mark
    Priestley, chapter 4.
  • Support the day-to-day operations of restaurant
    by improving the processes of
  • Making Reservations
  • Allocating Tables
  • Current System is based on manual booking system
  • Hand-written forms in large folder.

5
Case Study 1 The Restaurant
  • Current system uses manual booking sheets.

6
Case Study 1 The Restaurant
  • Three sittings (slots) in an evening
  • Booking can span more than one slot
  • Each Booking records
  • Contact Name and Phone Number
  • Annotation made for various events
  • Arrival of customer (Cross out record)
  • Table switch (Arrow to new table)
  • Cancellation
  • Time to vacate
  • Walk-In Customer

7
Case Study 1 Restaurant
  • Problems with the manual systems
  • Slow
  • Confusing and difficult to read
  • No backup copies
  • Hard to get useful management data
  • Develop an automated computerized version.

8
Case Study 2 The Monopoly Game
  • Chosen because of its familiarity.
  • A game played almost in every country.
  • Developed in the Applying UML and Patterns by
    Craig Larman, Chapter 3.
  • The software version will run as simulation
  • User starts the simulation by indicating the
    number of simulated players.
  • All turns are simulated with result (trace)
    printed.

9
Case Study 3 The Bicycle Renting
  • Adopts a use-case driven object-oriented approach
    to develop a system to support the process of
    bicycle renting in a kiosk at East Coast Park,
    Singapore.
  • Developed in the Software Engineering An
    object-oriented approach by Bimlesh Wadhwa,
    Stefan Andrei, Soo Yuen Jien, 2007, McGraw Hill.

10
Where are we now?
  • Requirement Gathering
  • Understanding the requirements.
  • Business Modeling
  • Understanding the problem domain.

11
Requirement Overview
  • Early phase of the development.
  • Inputs
  • informal specification.
  • Activities
  • create use case model.
  • define use cases.
  • create domain model.
  • create glossary.
  • create activity diagram.

12
Use Case View
  • Intended to provide a structured view of the
    system's functionality.
  • Description of how users interact with the
    system.
  • Supported by UML use case diagrams.
  • Serves as the starting point for all subsequent
    development.
  • Three important definitions
  • Use Case
  • Scenario
  • Actor

13
Use Case and Scenarios
  • Use Case
  • The different tasks that users can perform while
    interacting with the system.
  • Scenarios
  • Are particular instances of the use case
  • Basic Course of Events normal flow.
  • Alternative Course of Events optional flow.
  • Exceptional Course of Events erroneous flow.

14
Actor
  • Roles played by users when interacting with a
    system, e.g.
  • Receptionist (makes bookings)
  • Head waiter (assigns tables etc).
  • Individual user may play one or more roles at
    different times.
  • Often corresponds to certain level of access,
    e.g., logging into Lamar website as Staff or
    Student.

15
Use Case Diagram
  • UML diagram to summarize the relationship between
    actors and use cases.
  • Diagram Element

16
Case Study 1 Use Cases
  • A preliminary list of use cases
  • Record new booking.
  • Cancel a booking.
  • Record customer arrival.
  • Transfer a customer from one table to another.

17
Case Study 1 Use Case Diagram
  • Show use cases, actors and who does what.

18
Use Cases Description
  • A use case comprises all the possible
    interactions that a user can have when performing
    a given task.
  • Often a dialogue between system and user.
  • These are described as courses of events, or
    scenarios.
  • A full description of a use case includes
  • a basic course of events
  • a number of alternative and exceptional courses.

19
Basic Course of Events
  • Describes what happens in the normal case.
  • For example, for Record Booking
  • Record Booking Basic Course of Events
  • Receptionist enters date of requested
    reservation
  • System displays bookings for that date
  • There is a suitable table available Receptionist
    enters details (customers name, phone number,
    time of booking, number of covers, table number)
  • System records and displays new booking.

20
Use Case Templates
  • UML does not define a standard format for use
    case descriptions.
  • Various templates have been defined to structure
    descriptions.
  • Essentially a list of subheadings such as
  • Name
  • Actors
  • Courses of events

21
Other Use Case Description Template
  • This version emphasizes the exchange between user
    and system, e.g.

Actor
System
  • Receptionist enters date of requested
    reservation
  • there is a suitable table available Receptionist
    enters details (customers name, phone number,
    time of booking, number of covers, table number)
  • System displays bookings for that date.
  • System records and displays new booking.

22
User Interface Prototype
  • During the use case modeling activity, it is
    usually useful to have a rough idea of the user
    interface, e.g.

23
Alternative Courses of Events
  • Describe predicted alternative flows.
  • For example, if no table is available
  • Record Booking No Table Available Alternative
    Course of Event
  • Receptionist enters date
  • System displays bookings
  • no table available end of use case.

24
Exceptional Courses of Events
  • Situations where a mistake has been made.
  • E.g., allocate a booking to a small table
  • Record Booking table too small Exceptional
    course of events
  • receptionist enters date
  • system displays bookings
  • receptionist enters details
  • system asks for confirmation of oversize booking
  • if no, use case terminates with no booking
    made
  • if yes, booking recorded with warning flag.

25
Shared Functionality
  • Different use cases can overlap.
  • E.g., Record Arrival
  • Record Arrival Basic Course of Events
  • head waiter enters date
  • system displays bookings
  • head waiter confirms arrival for booking
  • system records this and updates display.
  • First two steps shared with Record Booking
    (even though different actor).

26
Use Case Inclusion
  • Move shared functionality to a separate use case
  • Display Bookings Basic Course of Events
  • user enters a date
  • system displays bookings for that date.
  • Include this in other use cases, e.g.
  • Record Booking Basic Course of Events (revised)
  • receptionist performs Display Bookings
  • receptionist enters details
  • system records and displays new booking.

27
The ltltincludegtgt Dependency
  • UML shows inclusion as a dependency between use
    cases, labelled with the stereotype ltltincludegtgt
    on the dashed arrow

System
28
Case Study 1 Use Case Diagram (Revised)
Display booking
System
29
Actor Generalization
  • The last diagram shows that the Receptionist can
    performs the Display bookings use case
    independently from the Record Booking use case.
  • Head Waiters can also performs Display bookings
    use case.
  • Introduce a more general actor Staff to show what
    the other two actors have in common.
  • The initial actors are specializations of the
    general actor.

30
Actor Generalization Notation
System
31
Use Case Extension
  • Recording a walk-in can be described as an
    exceptional course of events
  • someone arrives but theres no booking recorded.
  • It could also be a separate use case
  • a customer arrives and asks if there's a free
    table.
  • Then, it can extend Record Arrival
  • even without a booking, the customer stays to eat.

32
Use Case Extension
  • Record Walk-in Basic Course of Events
  • Head waiter performs Display Bookings use case
  • Head waiter enters details (time, number of
    covers and the table allocated to the customer)
  • System records and displays new booking.
  • Very similar to Record Arrival use case. Can we
    simplify?
  • ltltIncludegtgt dependency is inappropriate. (why?)
  • Record Walk-in is performed in some cases of
    Record Arrival, when there is no booking for the
    customer.

33
The ltltextendgtgt Dependency
  • Use case extension is shown with a ltltextendgtgt
    dependency.
  • Record walk-in optionally extends the
    functionality of Record arrival.
  • States the constraint (condition) which causes
    the branch off.

No Prior Booking
System
34
Case Study 1 Complete Use Case Diagram
System
35
Guidelines
  • Use case
  • Should cover full sequence of steps from the
    beginning of a task until the end.
  • Should describe users interaction with the
    system.
  • Should not describe actual computations.
  • Should be as independent as possible from any
    particular user interface design.
  • Should only include actions in which the actor
    interacts with the computer.
  • Use case diagram should be used to supplement
    the use case description, not as the main
    artifact.

36
Use Cases Strengths
  • Simple and Familiar
  • Can be understood easily by untrained personnel,
    e.g., the customer.
  • Involve the customer early in the development.
  • Emphasize the user goals and perspective.
  • Scale in term of sophistication and formality.

37
Use Cases Problems
  • Care must be taken to ensure the use cases are
    complete and unambiguous.
  • Only actor initiated activities are recorded.
  • Software requirement derived from use cases often
    mimics the manual system too closely.
  • Preventing any innovative or more efficient way
    to be developed.

38
Domain Modelling
  • Using UML diagram to construct a model of the
    real-world system
  • Understand the problem domain.
  • Model recorded as a simplified class diagram.
  • Seamless development
  • The same notation is used for analysis and
    design.
  • The design can evolve from the initial domain
    model.

39
Domain Model Notation
  • A subset of class diagram model elements are
    used.

Name
Multiplicity
Multiplicity
Association
Class
40
Domain Model Notation
  • Classes represent real-world entities.
  • Attributes represent the data held about
    entities.
  • Associations represent relationships between the
    entities.
  • Generalization can be used to simplify the
    structure of the model.
  • Constraints can be used to indicate conditions.

41
Case Study 1 Customers and Reservations
  • Basic business fact customers make reservations.

42
Defining a Relationship
  • Give a name to the relationship
  • use a verb so that the relationship can be read
    as a sentence
  • A customer can make many reservations.
  • How many people make a reservation?
  • one principal contact whose details are held
  • that principal contact can make more than one
    reservation (e.g., by postponing the time)
  • the expected number of diners can be modelled as
    an attribute of the reservation.

43
Case Study 1 Tables and Reservation
  • Is table number an attribute of Reservation?
  • Better modelled as a separate class
  • tables exist even if there are no reservations
  • other attributes of tables, e.g., size, can be
    stored.

44
Use of Constraints
  • Not all domain properties can be shown
    graphically
  • e.g., it should be impossible to double-book a
    table.
  • Constraints add information to models
  • written in a note connected to the model element
    being constrained.

45
Use of Generalization
  • A superclass can be used to show the properties
    shared by different types of booking.

46
Correctness
  • How do we know when a domain model is complete?
  • we don't there are lots of plausible models in
    most cases.
  • Domain modelling is not an end in itself, but a
    guide to further development.
  • Realizing use cases tests the domain model, and
    will usually lead to refinements.

47
Supplementary Documents
  • Common Supplementary Documentation
  • Glossary.
  • Activity Diagram.
  • Glossary
  • A mini dictionary that captures concepts and
    vocabulary relevant in the problem domain.
  • Avoids misunderstanding and facilitate
    communication.
  • Activity Diagram
  • UML diagram that describes activities.

48
Case Study 1 Partial Glossary
  • Booking an assignment of diners to a table.
  • Covers the number of diners for a booking.
  • Customer a person who makes a reservation.
  • Reservation a booking made in advance.
  • Walk-in a booking that is not made in advance.

49
Activity Diagram
  • Similar to flow chart that describes sequence of
    activities.
  • Useful in
  • Business Modelling (business workflow).
  • Use Cases (interrelation and interaction).
  • Design (algorithm, complex sequence etc).
  • Often associated with several classes.
  • One of the strengths of activity diagrams is the
    representation of concurrent activities.

50
Activity Diagram
  • Diagram Elements

Activity Initial Node
Activity End Node
51
Activity Diagram
  • Action
  • Fundamental block in an activity diagram.
  • Represents a unit of work (something is done).
  • Automatic transition upon completion.
  • Transition
  • Represents the control flow it is simply a
    movement between actions.
  • Initial and End Node
  • Show the beginning and ending points in an
    activity diagram.

52
Case Study 1 Activity Diagram
  • Documenting the sequence when customer arrives.
  • Note the interrelation of Record Arrival and
    Record Walk-In.

53
Concurrent Actions
  • Independent actions which can be carried out at
    the same time (in parallel).
  • Shown using forks, joins and rendezvous
  • Fork
  • One incoming transition and multiple outgoing
    transitions.
  • Execution splits into multiple concurrent
    threads.
  • Rendezvous
  • Multiple incoming and multiple outgoing
    transitions.
  • All incoming transitions must occur before the
    outgoing transitions.

54
Representing Concurrency
  • Join
  • Multiple incoming transitions and one outgoing
    transition.
  • The outgoing transition will be taken when all
    incoming transitions have occurred.

55
Activity Diagram Another Example
  • Use Cases
  • Submit registration request.
  • Register student
  • Verify prerequisites.
  • Verify course enrolment.
  • Verify special cases.

56
Swimlanes
  • Activity diagrams are most often associated with
    several classes.
  • The partition of activities among the existing
    classes can be explicitly shown using swimlanes.
  • Further clarify where an action takes place.

57
Swimlanes Example
Course
Student
Receive course
registration request
Verify
Check
course not
prerequisites
full
Action taken by Student
Action taken by Course
ok
not ok
ok
not ok
Check
special
ok
permission
not ok
Complete
registration
58
Where are we now?
  • Typical Artifacts
  • Requirement Specification.
  • Use Cases
  • Use Case Description.
  • Use Case Diagrams.
  • Activity Diagrams.
  • Glossary.
  • Domain Model.

59
Summary
  • Introduction to Case Studies
  • Requirement Gathering
  • Use Case Modeling
  • Domain Modeling / Business Modeling
  • Activity Diagram

60
Reading suggestions
  • From Wadhwa, Andrei, Soo 2007
  • Chapter 3
  • From Priestley 2004
  • Chapter 4, sections 4.2 to 4.5
  • Exercises 4.1-4.7
  • From Larman 2005
  • Chapters 1, 6
  • From Stevens, Pooley 1999
  • Chapter 11

61
Coming up next
  • Analysis
  • Priestley 2004, Chapter 5
  • Wadhwa, Andrei, Soo 2007, Chapter 3
  • UML Class and Object Diagrams
  • Priestley 2004, Chapter 8
  • Wadhwa, Andrei, Soo 2007, Chapter 4

62
Thank you for your attention!Questions?
Write a Comment
User Comments (0)
About PowerShow.com