1 / 18

Systems grenser mot omverdenen Forelesning IN 265 18.3-2003

Systems grenser mot omverdenen Forelesning IN 265 18.3-2003. Are Use Cases necessarily the best start of an OO System Development Process? Basert på artikkel og lysark av Gerhard Skagestein, Universitetet i Oslo. The Unified Modeling Language - UML. Use-Case diagram.

ashby
Télécharger la présentation

Systems grenser mot omverdenen Forelesning IN 265 18.3-2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Systems grenser mot omverdenenForelesning IN 265 18.3-2003 Are Use Cases necessarily the best start of an OO System Development Process? Basert på artikkel og lysark av Gerhard Skagestein, Universitetet i Oslo

  2. The Unified Modeling Language - UML Use-Case diagram Class/object diagram Sequence diagram Collaboration diagram State diagram Activity diagram Component diagram Deployment diagram A set of 8 diagram techniques, established by groups setting the tone within the OO community Use- Case view Logi- cal view Compo- nent view Concur- rency view Deploy- ment view

  3. Recommended sequence by most methods Use-Case diagram Class/object diagram Sequence diagram Collaboration diagram State diagram Activity diagram Component diagram Deployment diagram Start here Use- Case view Logi- cal view Compo- nent view Concur- rency view Deploy- ment view

  4. A Use Case for an Automatic Teller Machine (see IN 102, ch. 9) Automatic Teller Machine • Insert card • Give PIN • Select amount • Remove card • Take money Withdrawcash Show recent transactions Customer Show currency exchange rates

  5. Whats nice with Use Cases • Describe the expected functionality of the system on an appropriate abstraction level • Nice form of requirement specifications • Excellent basis for test-programs • Understandable by the users

  6. What is bad with Use Cases • Use Cases are build on assumptions about the boundary of the system to be used • Responsibilities of users and system are more or less taken for granted • Does not assist in getting new ideas on how to organise things better – on the contrary, they prevent you from getting such ideas

  7. An alternative approach –illustrated by a small example The object-oriented loan loan

  8. The object-oriented loan A loan-object may • Know its own balance, interest rate, installment dates etc. • Calculate its own interests • Ask for instalments • Accept instalments Hello, you should pay the instalment loan

  9. The Person and the Loan –a simple collaboration diagram :Person :Loan askforInstalment Person Loan classes

  10. Allocation of responsibilities :Person :Loan askforInstalment Person Loan classes calculateInterest( ) calculateBalance( ) calculateInstalment( ) askforPayment(amount,date) acceptPayment(amount) askHimforPayment(amount,date) remindHim(amount,date) acceptHisPayment(amount)

  11. The communication between the real and the computerized part Example: remindHim(amount, date) • Send him a typed letter • Send him an e-mail • Ask a clerk to call him • Send a SMS-message to his Mobile Phone the Protocol Person askHimforPayment(amount,date) remindHim(amount,date) acceptHisPayment(amount) 4 different Use Cases!

  12. The harmful boundary Computerized system :object1 :object3 :object2 :object5 :object4 :object6 :object8 :object7 :objectn :object9 Computerized system

  13. The better boundary Computerized system A user interface, may be describedby Use Cases :object1 :object3 :object2 :object5 :object4 :object6 :object8 :object7 :objectn :object9

  14. My message – first part • The boundary between the computerized system and the environment does neither go through messages between objects, nor does it coincide with the interfaces of some objects On the contrary: • The boundary runs right through some objects, splitting them in a real world and a computerized part • The communication between those two parts is governed by a protocol, which may be documented by Use Cases • This protocol may involve communication between objects, but the on a lower abstraction level

  15. My message – second part • A Use Case is a way to document the protocol between a human being (or another system) and a computerized system • It is obviously wrong to lay down this protocol before we have • Decided upon the distribution of responsibilities between the human being and the computerized system • Decided upon the means of communication between the two • Conclusion: Sequence/collaboration diagrams first!

  16. Alternative sequence Use- Case view Logi- cal view Compo- nent view Concur- rency view Deploy- ment view Use-Case diagram Class/object diagram Sequence diagram Collaboration diagram State diagram Activity diagram Component diagram Deployment diagram Start here

  17. Is the alternative method really ”better”? • Difficult to prove empirically –good designers make good systems even with bad methods But: • A method should not be obviously counterproductive in getting new ideas • The basic models should be invariant with regard to organizational and technical solutions

  18. Punchline… • ”A system is an inter-related set of components, with an identifiable boundary, working together for some purpose, and which we choose to regard as a whole” • In other words: We select our systems to fit the purpose. • Before doing so, we should know as much as possible about the purpose!

More Related