DOC PREVIEW
CORNELL CS 501 - Lecture 12 Object-Oriented Design II

This preview shows page 1-2-24-25 out of 25 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS 501: Software Engineering Fall 2000AdministrationRequirements: the Long TermRequirements, Design and ImplementationModeling ClassesNoun Identification: A Library ExampleSlide 7Candidate ClassesRelations between ClassesOperationsClass DiagramRough Sketch: Wholesale SystemSlide 13Slide 14Expanding a Class: Modeling Financial InformationModeling InvoiceLessons LearnedLevels of AbstractionComponent DiagramActor and Use Case DiagramUse Cases and ActorsUse Cases for Borrowing BooksRelationships Between Use Cases: <<uses>>Relationships Between Use Cases: <<extends>>Use Cases in the Development CycleCS 501: Software EngineeringFall 2000Lecture 12Object-Oriented Design II2Administration• PresentationsYour will have three presentations this semesterEverybody in the team should present at least once • A case study: a new clientClient satisfaction is the first requirement!3Requirements: the Long TermBelieve that your software will be in use 5 years from now.• What happens at end of semester?Packaging and hand-overClient's technical preferences (C++, Java)• Some system decisions based on short-term considerations • Which formats, protocols, etc. do you think will last? (IIOP, RMI, SNMP, ...)4Requirements, Design and ImplementationRemember the definitions.Example: Consistency between two players of a board game• The requirement is .....• The design is .....What is a requirements specification?5Modeling ClassesGiven a real-life system, how do you decide what classes to use?• What terms do the users and implementers use to describe the system? They are candidates for classes.• Is each candidate class crisply defined? • For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes?• What attributes and operations does each class need to carry out its responsibilities?6Noun Identification: A Library ExampleThe library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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.The system must keep track of when books and journals are borrowed and returned and enforce the rules.7Noun Identification: A Library ExampleThe library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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.The system must keep track of when books and journals are borrowed and returned and enforce the rules.8Candidate ClassesLibrary the name of the systemBookJournalCopyShortTermLoan eventLibraryMemberWeek measureMemberOfLibrary repeatItem book or journalTime abstract termMemberOfStaffSystem general termRule general term9Relations between ClassesBook is an ItemJournal is an ItemCopy is a copy of a BookLibraryMemberItemMemberOfStaff is a LibraryMemberIs Item needed?10OperationsLibraryMember borrows CopyLibraryMember returns CopyMemberOfStaff borrows JournalMemberOfStaff returns JournalItem not needed yet.11Class DiagramMemberOfStaffBookCopyJournalis a copy of1..* 1LibraryMember10..*0..121on loanon loan12Rough Sketch: Wholesale SystemA wholesale merchant supplies retail stores from stocks of goods in a warehouse.What classes would you use to model this business?13Rough Sketch: Wholesale SystemRetailStoreWarehouseOrderInvoiceProductShipmentMerchant14Rough Sketch: Wholesale SystemWarehouseOrderInvoiceProductMerchantRetailStorenameaddresscontactInfofinancialInfoShipmentResponsibilities-track status of shipped productsReversalsdamaged()return()wrongItem()responsibility (text field)15Expanding a Class: Modeling Financial Information RetailStoreTransaction1 *associationInvoicePaymentWhich class is responsible for the financial records for a store?16Modeling InvoiceShipmentInvoiceinvoiceNumber+goodsShipped()-sendInvoice()goodsShippedPartsListadornments+ public- privateRetailStore???invoiceRecord17Lessons LearnedDesign is empirical. There is no single correct design. During the design process:• Eliding: Elements are hidden to simplify the diagram• Incomplete: Elements may be missing.• Inconsistency: The model may not be consistentThe diagram is not the whole design. Diagrams must be backed up with specifications.18Levels of AbstractionThe complexity of a model depends on its level of abstraction:• High-levels of abstraction show the overall system.• Low-levels of abstraction are needed for implementation.Two approaches:• Model entire system at same level of abstraction, but present diagrams with different levels of detail.• Model parts of system at different levels of abstraction.19Component DiagramHelloWorld.classhello.javahello.hmlhello.jpgexecutable component20Actor and Use Case Diagram• An actor is a user of a system in a particular role. An actor can be human or an external system.• A use case is a a task that an actor needs to perform with the help of the system.Borrow bookBookBorrower21Use Cases and Actors• A scenario is an instance of a use case • Actor is role, not an individual(e.g., librarian can have many roles)• Actor must be a "beneficiary" of the use case(e.g., not librarian who processes book when borrowed)In UML, the system boundary is the set of use cases.22Use Cases for Borrowing BooksBorrow copy of bookBookBorrowerReturn copy of bookReserve bookExtend loan23Relationships Between Use Cases: <<uses>>BookBorrowerCheck for reservationExtend loan<<uses>><<uses>>Borrow copy of book24Relationships Between Use Cases: <<extends>>Borrow copy of bookBookBorrowerRefuse loan<<extends>>25Use Cases in the Development Cycle• Use cases are a tool in requirements analysis• Intuitive -- easy to discuss with clients• Use cases are often hard to translate into class models• Scenarios are useful to validate


View Full Document

CORNELL CS 501 - Lecture 12 Object-Oriented Design II

Documents in this Course
Quiz 2

Quiz 2

2 pages

Usability

Usability

31 pages

Quiz 1

Quiz 1

2 pages

Stulba;''

Stulba;''

33 pages

Load more
Download Lecture 12 Object-Oriented Design II
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 12 Object-Oriented Design II and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 12 Object-Oriented Design II 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?