• Like
The slides for this lecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

The slides for this lecture

  • 122 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
122
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 3SFE514 Object-oriented Design Lecture 7: Business Modelling
  • 2. Modelling eBay
    • An initial use case model for eBay might be:
  • 3. Users vs. Actors
    • It's a property of the real-life user whether or not they are a member
      • Actors are defined by the functionality available when using the system
    • All users initially have the same abilities:
      • Register, search, browse
    • When you log in, you can do more
    • This suggests that being logged in is the important difference between actors
  • 4. Better actors
  • 5. Even better actors
    • You can only sign in once:
  • 6. Buying and selling
    • These are probably not use cases
      • They're not single transactions performed by users
      • Buying involves bidding and paying
      • Selling involves listing an item for sale
      • The system manages and closes auctions
    • Which actors can bid?
      • Signed-in users
  • 7. Use case model including buying
  • 8. Use Case Extension
    • Actually, eBay doesn't work this way
      • Any user can bid
      • But you may have to sign in before you can actually make a bid
    • 'Sign in' is an optional extension of the 'Bid' use case
  • 9. Notation for extension
    • This doesn't show the effect of signing in
  • 10. Selling
    • To sell you must create a selling account
      • Anyone who's signed in can create this
    • Anyone can list an item for sale
      • Possible extension: create selling account
    • There are no extra use cases that 'sellers' can perform
      • So no need for a 'Seller' actor
  • 11. Use cases for selling
  • 12. Ebay business entities
    • What are the key business entities?
      • Members
      • Items
    • What are the relationships between them?
      • Members sell items
      • Members bid for items
      • And so on
  • 13. Entities and relationships
    • Relationships can be shown as associations
  • 14. Adding attributes
    • Data that the system must store can be modelled as attributes
      • Auction closing date
      • Bid value
      • Bid date
      • Etc
    • Strategy: create additional classes as necessary to hold these attributes
  • 15. Including attributes
  • 16. Modelling members
    • Entities are different from actors
  • 17. Domain Modelling
    • Using UML to construct a model of the real-world system
      • similar to entity-relationship modelling
    • Model recorded as a class diagram
    • ‘ Seamless development’
      • same notation used for analysis and design
      • design can evolve from initial domain model
  • 18. Domain Model Notation
    • Subset of class diagram notation
      • classes represent real-world entities
      • associations represent relationships between the entities
      • attributes represent the data held about entities
      • generalization can be used to simplify the structure of the model
    • Similar to extended entity-relationship modelling
  • 19. Customers and Reservations
    • Basic business fact: customers make reservations
  • 20. 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
      • the expected number of diners can be modelled as an attribute of the reservation
  • 21. Tables
    • 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, eg size, can be stored
  • 22. Constraints
    • Not all domain properties can be shown graphically
      • eg 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
  • 23. Use of Generalization
    • A superclass can be used to show the properties shared by different types of booking
  • 24. 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
  • 25. Glossaries
    • Domain models capture important system concepts
    • Useful to record these terms and their definitions for use throughout a project
    • Do this in the form of a glossary
  • 26. Partial Restaurant 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