Scenario To Calculate Due Date Fine Of A Library System

Overview of software development • The problems – Are we building the right system? – How to manage a large team of people? – How to guarantee the quality of the software? – How to prepare for changes in future? – How to make the software easy to maintain? – How to document the software? – What happen if people in the team quit? • How to deal with these problems? – Any guidance? Department of Information Engineering

1

Methodology • Ask the guru – provides guidance by naming a set of best practices in the industry – This set of best practices is known as methodology • Examples of methodologies – Waterfall process • Traditional approach – Rational Unified Process (RUP) • Proprietary product by Rational – Agile Process • Extreme Programming (XP) Department of Information Engineering

2

Common approach • Divide the work in 5 stages 1. Requirement model • To capture the users requirements 2. Analysis model • Initial rough model of the system 3. Design model • Detailed model, one-to-one mapping between the classes diagram and the implementation model 4. Implementation model • The code 5. Test model Department of Information Engineering

3

Requirement model • Traditional way of capturing requirements – Developer interviews the users – Jog down users requirements – Write the requirement spec – Deliver the system two years later • What is wrong? What is the biggest risk?

Department of Information Engineering

4

The biggest risk • We build a system that is not the users want !! • How is this possible? – Users have no idea of what they want – Users do not understand the technical specification – Requirements change, system must change too

Department of Information Engineering

5

Best practice in capturing requirements • Use-case approach – Use cases describe how the system is used from a user view point, written in the language of users • Advantages – Users understand the spec, so that they can participate in the process more effectively • In comparison – Traditional methods write the spec from the developer’s viewpoint, using developer’s language – Too technical, users can’t understand it Department of Information Engineering

6

Traditional software development approach • Waterfall model Requirement definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

Department of Information Engineering

7

Waterfall model • The traditional approach, still widely used • Main problem – A complete cycle can take a year to complete, slow to respond to changes – Modern approaches favor shorter cycle (from a day to a few weeks) that build the work incrementally, so that • Risks can be discovered earlier • Changes can be made more rapidly • Short iteration provides continuous feedback to the users Department of Information Engineering

8

Risks • From development point of view, risk is the most critical issue – Technical risks • risks related to new technologies, new language • risks related to architecture – whether the architecture is robust

• risks related to building the right system • risks related to performance – Non-technical risks • do we have the people with the right experience • too tight a schedule • needs timely input from subcontractors Department of Information Engineering

9

Use-case driven approach Use Cases Model Find core classes from use cases Analysis Model Refine the analysis model Design Model Turn class diagram into code Implementation Model Do the testing based on use cases Test Model Department of Information Engineering

10

The process is iterative • Start from the most important use case – produce analysis model – produce design model – produce implementation model (the code) – a little testing • Add a second use case – repeat the process, – modify the model if necessary

Department of Information Engineering

11

Case study – a library system •

The university library is using a 1960s program written in an obsolete language for some simple bookkeeping tasks, and a card index for user browsing.

• Your task is to build an interactive system which handles both of these aspects online

Department of Information Engineering

12

How to start? • The problem statement is vague, but typical • The difficulty in formulating the requirements – Users are not sure of what they want – Users have little idea of what computers can do – Developers are not familiar with the users’ problem domain – Hard for the users to visualize a non-existing system

Department of Information Engineering

13

USER

PROGRAMMER

Business Knowledge

Programming Knowledge Project Manager

Department of Information Engineering

14

How to start? • Do you homework – collect materials about the library system • A meeting between domain experts (the librarian), the users, and the developers • Purpose of the meeting – identify the actors and the use cases • actors – users of the system (borrower, administrator) • use cases – how the system will be used by the actors Department of Information Engineering

15

Preliminary system requirements • This application will support the operations of library for university. This includes the searching for and lending of library materials, including books, videos, and journals. Borrowers will enter their ID numbers in order to use the system; and they will enter material ID numbers when checking out and returning items • Member can can lend books, journals, and videos for up to ten items. Each type of library item can be lent for a different period of time. If returned after their due date, a fine will be charged, based on the type of item (books $1/day, journals $3/day, videos $5/day). • Materials will be lent to users with no overdue lendables, fewer than ten items out, and total fines less than $100. Department of Information Engineering

16

Use case model • Who is an actor? – entities external to the system that interacts with the system – represent a role that a user can play • Who is a user? – An instance of the actor – the actual person who uses the system – e.g John is an instance of the actor Borrower

Department of Information Engineering

17

Use case model • What is use-case? – A use case is a sequence of actions that an actor performs within a system to achieve a certain goal – use cases are written using the language of the users and from the user point of view – A complete set of use-case descriptions specifies the complete functionality of the system

Department of Information Engineering

18

Use case and scenario • Scenario – Scenario is also a sequence of steps describing an interaction between a user and a system • Borrower borrows 3 books successfully • Borrower borrows 3 books but failed because the number of borrowed items exceed the limit • ... – Different scenarios, same goal - borrowing • A use case is a set of scenarios tied together by a common goal Department of Information Engineering

19

Describe the system in the language of the users • Traditional approach – requirements are typically in the form • “the system shall do this and that . . . ” • Use cases approach – requirements from users’ point of view • “actor shall do this and that . . . ” – Written in the language of the users, users can understand and can provide feedback

Department of Information Engineering

20

Writing use cases • Identify the Actors – actor is external to the system – identify actors first can help us to find the use cases • Actors – Borrower – Librarian – System administrator

Department of Information Engineering

21

Actor • Primary actor - borrower – The actor that the system is built for – Use the primary actor to find the primary use cases – Each complete course of events initiated by an actor is potentially a use case • Secondary actor – librarian, system administrator – Not a primary actor because we would not need a librarian if there is no borrowers • Iterative process – Deal with the primary use cases first Department of Information Engineering

22

Writing use cases • Actor - Borrower • Use case: borrowing books – This use case includes everything until all books are checked out – Keep use case simple, factor out alternatives • Alternative use case – What if the borrowing limit is exceeded? • Focus on the basic course first – Deal with the alternative later Department of Information Engineering

23

Use case model • A use case model contains – Use case diagram – Use case description • Use cases discovered in our first iteration – User borrow copy of book – User return copy of book

Department of Information Engineering

24

Use case diagram • Record the information pictorially, in a use case

Borrow copy of a book User

Department of Information Engineering

Return copy of a book

25

Use case description • Describe in active-voice English, pick the main success scenario •

Use case: Borrow copy of book – A Borrower presents a book. – The system checks whether the borrower can borrow (borrower must be a member in the library, does not already have the maximum permitted number of books on loan, does not have overdue book, and does not have fine exceeded $100). – If the checks succeed, the system records that this library member has this copy of the book on loan Extensions: 3a: The checks failed. Refuses the loan.

Department of Information Engineering

26

Writing use cases • Use cases are strongly correlated with the user manual of the system – Advice - write the user manual before the code ! • Prototyping – Produce a rough user manual – Discover all the basic courses of action – Ignoring alternative courses (exceptions)

Department of Information Engineering

27

Writing use cases • Screen mockups – Make a draft screen design (GUI) and test it using the use cases • windows navigation diagram • showing how user can move from one window to next • Mining legacy user manuals – reengineer a legacy system, work from the user manual backward

Department of Information Engineering

28

Structure the use cases • Structure use cases using UML stereotype <<. . .>> – stereotype is a notation that allows developers to define non-standard relation – <<use>> or <> • sequences that are common to several use cases • Analogous to delegation – <<extend>>

• To describe alternate (or exceptional) scenario based on certain condition • Analogous to inheritance (specialization)

Department of Information Engineering

29

<<uses>>

• The source use case makes use of the target use case

Extend loan Borrower

<<use>>

Borrow copy  of a book

Department of Information Engineering

Check for reservation <<use>>

30

<<extend>>

• New use case: Refuse loan – Main scenario: borrows books – The alternative scenario: borrows books, but exceeds the limit; the loan is refused

Refuse loan Borrower

Borrowing books

Department of Information Engineering

<<extend>>

31

Notes • Use cases represent an external view of the system, it is not correlate with classes inside the system (although use cases can be used to discover classes) • Keep the use case diagram simple; the benefit of a complex structured diagram (<>, <<extend>> is not great in practice • The use case text is more powerful • Structuring Use Cases with Goals by Alistair Cockburn – http://members.aol.com/acockburn/papers/usecases.htm • The Use Case Zone – http://www.pols.co.uk/usecasezone/index.htm Department of Information Engineering

32

Analysis model – the what • A first-cut (draft) of the system – Identify the core classes of the system • what are the objects? • what are the object functions? • what are the interaction between objects? – Not worry about implementation issues (e.g. what database to use, which platform, etc) • How to model the system?

Department of Information Engineering

33

Procedural solution • Structural programming – Decomposed an application based on functionality – Procedure usually has global knowledge check­out

check borrow­ID

check­in

search

check fine

.  .  .

Data base Department of Information Engineering

34

Why OO modeling is difficult • The most difficult problem in teaching OO programming is getting the learner to give up the global knowledge of control that is possible with procedural programs, and rely on the local knowledge of objects to accomplish their tasks. Beck and Cunningham (A Laboratory for Teaching Object-Oriented Thinking)

• Local knowledge – Object has limited knowledge, the knowledge is encapsulated Department of Information Engineering

35

Object modeling • Decompose an application based on objects

Department of Information Engineering

36

The main problem

• How are the objects? • What are the objects’ responsibility? • Your system is only as good as the objects you find

Department of Information Engineering

37

CRC (Class-Responsibility-Collaboration) cards • A popular technique [Beck and Cunningham] for finding objects in a system • The role of an object is identified by – Class name • A good name makes it easier to understand the model – Responsibilities • The problems to be solved by the class – Collaboration • Its relationship with other classes Department of Information Engineering

38

CRC Cards • Purpose – A widely used technique in discovering the classes, their responsibility and collaborations • Tool - the index card class name subclasses: superclasses: responsibilities      collaborators

Department of Information Engineering

39

A key feature of CRC • Each card represents a class of objects • Each participant has a number of cards • Participants play a simulation game – participants act as objects passing around messages • Ref – OOPSLA`89 in http://c2.com/doc/index.html • A Laboratory for Teaching Object-Oriented Thinking by Beck and Cunningham

Department of Information Engineering

40

A meeting with the participants • Clients (Betty and Dewey) – those who are familiar with the user requirements – Betty - who wrote the system requirements – Dewey - the librarian, whose work will be offloaded by the system • Developers (Cecilia and Jim) – who will design and implement the system • Facilitator (Nancy) – object oriented expert Department of Information Engineering

41

Goal To discover classes in the application, form a glossary, use the glossary to produce scenarios

Department of Information Engineering

42

How to find the classes • Collect material – From high-level problem statement – Lower-level requirements – Expert knowledge of the problem domain – Everything, including marketing literature • Highlight the nouns and verbs – Nouns and nouns phrases become objects and attributes – Verbs and verb phrases become operations and associations Department of Information Engineering

43

How to find the classes • Brainstorming – Write down all names of classes suggested – no criticism, filtering of the names will be done later – people who know their application can usually come up with a fairly complete list of classes

Department of Information Engineering

44

How to find the classes • Result – Library, Librarian, User, Borrower, Student Member, Staff Member, Article, Material, Item, Due Date, Fine, Lendable, Book, Video, Journal • Filtering classes – eliminate redundancies – identify missing abstraction – recognize related classes

Department of Information Engineering

45

Filtering classes • Give a short, precise meaning for each abstraction – e.g. Book: the set of objects that represent books to be borrowed from a library • Informal discussion on the glossary – Should User be included in the cards? • User may be outside the scope of the model – Difference between Library and Librarian? • Librarian be the class that has overall responsibility for checking in and out library materials. Library will be reserved for the entire application Department of Information Engineering

46

Recognize related classes • Article, item, material and lendable – refer to the same thing – Use Lendable to describe item lent at a library • Due Date and Fine - class or attribute? – Due Date is probably an attribute of Lendable and Fine is an attribute of Borrower – Perhaps need a Date class for due date • If not sure about the answer, leave the class there – Later on after executing scenarios, classes that have no responsibility will be discarded eventually Department of Information Engineering

47

Classes remained after filtering • After filtering – Librarian, Lendable, Book, Video, Journal, Date, Borrower, and User • Classes eliminated – Library, Article, Material, Item, Due Date, Fine • New class added – Date • 8 cards altogether – analysis stage : use 3” x 5” index cards – design stage : use 4” x 6” index cards Department of Information Engineering

48

How to play the CRC card game • Assigning cards to – the person who suggested them – those who knows the most about the abstraction • e.g – Betty: Librarian – Dewey: Lendable – Cecilia: Borrower, User, – Jim: Book, Video, Journal, Date • Write a short description of the class at the back of each card Department of Information Engineering

49

Responsibilities (written at the back of the card) • Librarian – The object in the system that fulfills User requests to check out, check in, and search for library material • User: – The human being that comes to use the library • Borrower – The set of objects that represent Users who borrow items from the library • Date – The set of objects that represent dates in the system Department of Information Engineering

50

Responsibilities (back of the card) • Lendable – The set of objects that represent items to be borrowed from the library • Book – The set of objects that represent books to be borrowed from the library • Video – The set of objects that represent videotapes to be borrowed from the library • Journal – The set of objects that represent technical journals to be borrowed from the library Department of Information Engineering

51

Example of a CRC card (back of card) Librarian:  The object in the system that fulfills User requests to check out, check in, and search for library material

Librarian                            (class name) subclasses: superclasses: responsibilities            collaborators

Department of Information Engineering

52

Attributes • Where are the attributes of the classes? – not concern at this early stage – more concern about the behavior of the objects – only need to record down attributes if it is obvious – write the attributes at the back of the cards • Scenario walkthrough – Scenarios are concrete instances of use cases – Use case • A Borrower presents a book. The system checks . . . – Scenario • Ricky presents the C# Primer to the system, . . . Department of Information Engineering

53

Ask the “What happens when . . .” question • What happens when – Ricky returns a video, C# Primer, to the Library • Scenarios should be very specific – related scenarios should be modeled separately – avoids branching questions, e.g. • “What if the video is overdue?”

Department of Information Engineering

54

The simulation • People who own particular CRC card should hold the card in the air and become the active object in the scenario • When someone holds a card saying “I need to do this” (responsibility) and points at someone (collaborator) else saying “I need you to do that”, control is passed to the collaborating object • Live prototype and simulation

Department of Information Engineering

55

Check-out scenario • What happens when . . . – Ricky, who has no accrued fines and one outstanding book, not overdue, checks out a book entitled C# Primer? • Who should have the overall responsibility for checking out Ricky’s book? – Betty: the librarian – Group: agree • Betty wrote CheckOutBook in the responsibility column on her card (Librarian) Department of Information Engineering

56

Check-out scenario • Librarian – How to handle this CheckOutBook responsibility? – Who (collaborator) can help me? • The Book ? – Ask the Book to change its status to ‘OUT’ • But wait a minute, the Librarian should make sure that the borrower can borrow (i.e. doesn’t have overdue books, too large a fine, or too many borrowed items) • Who has the responsibility to know whether the person can borrow? Department of Information Engineering

57

Check-out scenario • The Librarian? – Don’t overload the Librarian. Avoid using a mega object knowing too much and doing too much – Large object is hard to change; its role is also not clear – OO is about distributing the responsibilities to objects of suitable size • The Borrower ! – Ricky should know how many books he has borrowed Department of Information Engineering

58

So Betty (Librarian), starts the scenario as follows • Librarian – I am the Librarian and CheckOutBook is my responsibility. I need to verify whether this user can borrow. I will collaborate with Borrower to do this. Borrower, lift your card up. • Borrower – I am adding CanBorrow on my card as the responsibility. I can use KnowFine responsibility to see that my fine is less than $100. I will use KnowSetOfBooks responsibility to see if I am over my lendable limit. Knowing that I have only one book out, I need to find out whether this book is overdue. Will you know that, Book? Department of Information Engineering

59

Check-out scenario • Book – I’ll add KnowDueDate as a responsibility. I will also add KnowIfOverdue. To do this, I need to collaborate with Date to compare today’s date and due date • Date – I’ll add CompareDates responsibility to my list. To compare, I need to collaborate with another instance of Date (today’s date), so I’ll add Date as my collaborator. In this case, today’s date is less than due date, Book. • Book – Great. Borrower, I can tell you that I am not overdue • Borrower – OK. Librarian, the Borrower can borrow. Department of Information Engineering

60

Check-out scenario • Librarian – OK. I now need to change the Book’s state to indicate that it is OUT – I’ll ask Book to • set due date • set out status • record name of borrower • Wait a minute . . . – Need to collaborate with Book three times

Department of Information Engineering

61

Check-out scenario • Jim – Can the Book object just checks itself out instead of collaborate with the Librarian three times • Librarian – Book, if I tell you who the Borrower is, can you please check yourself out? • Book

– Sure. I’ll add CheckOut as my responsibility. I must know how to CalculateMyDueDate, and I need to KnowMyBorrower, KnowDueDate, and KnowInOrOut. I will add these as responsibilities. Done. Back Librarian . Department of Information Engineering

62

Check-out scenario • The difference between – Librarian collaborates with Book 3 times – Book checks itself out • First approach has a higher degree of coupling – Know too much about the internal state of Book – Bad, against the principle of encapsulation • Second approach has less coupling – Changing Book’s internal state in future will not affect the way Librarian carries out her responsibilities Department of Information Engineering

63

Check-out scenario • Librarian finishes her CheckOutBook responsibility telling Borrower to add the Book to her list • Librarian – Borrower,

by

please add this book to your list

• Borrower

– I will add a responsibility to AddBook • End of check out scenario

Department of Information Engineering

64

Librarian check out book for User

Borrower, Book

Date compare dates

Date

Borrow can borrow

Book

know set of books Book know if overdue

Date

check out calculate due date know due date know borrower know in or out Department of Information Engineering

65

What we have achieved • Identify objects (classes) in the system • Identify their responsibilities – the behavior of the objects later becomes the functions of the objects • Identify their collaboration • Related scenarios – repeat the check-out scenario with different variations – e.g. what happens if Frank has a non-overdue book at home and what to check out a video “Casablanca”? Department of Information Engineering

66

Frank checks out a video • Librarian

– I have my card up. I have added the responsibility CheckOutVideo. I will verify that the Borrower doesn’t have any overdue Lendables and is not at his lending limit. To do this, I collaborate with Borrower. • Borrower

– I already have this responsibility CanBorrow on my card, so I don’t have to add any new responsibility. The Borrower is OK. • Librarian

– Now Video, like what I have done with Book before, if I tell you who the Borrower is, can you check yourself out? Department of Information Engineering

67

Related scenarios • Video

– Yes. I’ll add check out to my card. I know how to CalculateDueDate (only 7 days) and I KnowDueDate, KnowBorrower, and KnowInOrOut, and I will collaborate with Date. OK, back to you, Librarian. • Librarian – Borrower,

the sequence is same as CheckOutBook ! I think it is better to change my responsibility to CheckOutLendable for all the landable items • Borrower – A good idea. I shall replace my KnowSetOfBooks to KnowSetOfLendables to make my responsibility more general Department of Information Engineering

68

Related scenarios • Group discussion – Note the similarity in the two scenarios (check out book and check out video) • check out • know borrower • know if overdue • know due date • know in or out – except • calculate due date

Department of Information Engineering

69

What it will be looked like in C# class Lendable { public virtual bool Checkout() {...} public virtual Date KnowDueDate() {...} public virtual bool KnowBorrower() {...} public virtual bool KnowInOrOut() {...} public virtual bool KnowIfOverdue() {...} public abstract double CalculateDueDate(); } class Book : Lendable { public override double CalculateDueDate() {...} }

Department of Information Engineering

70

Collaboration drawings • Repeat the scenario walkthrough for other use cases • Discover more classes and responsibility until you have a stable model • Visualize the object relations – Put the cards on the white board – Link the pattern to see how the objects participated in the application – Spot any spaghetti code – The drawing becomes the analysis class diagram

Department of Information Engineering

71

Collaboration drawings UI

Library

DB

Collection

Lendable Borrower

Department of Information Engineering

Date

72

Class diagram

UI

checkout checkin search Library

Borrower

collection Lendable

Book

Video

Department of Information Engineering

Date

Journal 73

Advantages of CRC cards • Live prototyping – Identifying holes in requirements • Common project vocabulary – Group effort in identifying the classes and responsibilities • Spreading domain knowledge – Domain experts participate directly • Making the paradigm shift – Internalization of participants through role playing Department of Information Engineering

74

CRC cards after analysis session Librarian

Responsibility

Collaborators

check out Lendable                                         Lendable, Borrower check in Lendable                                           Lendable, Borrower search for Lendable                                        Collection get info from user                                            UI Subsystem display message                                             UI Subsystem Collection know set of Lendables                                     DB Subsystem, Lendables Borrower can borrow                                                        Lendable know set of Lendables know fine amount Department of Information Engineering

75

CRC cards after analysis session Date compare dates                                                          Date add days to date Lendable subclasses:  Book, Video, Journal calculate due date                                                    Date calculate fine check out                                                                  Date check in  know due date know borrower know in or out know if overdue                                                        Date Department of Information Engineering

76

CRC cards after analysis session Book superclass: Lendable calculate due date                                                     Date calculate fine Video superclass: Lendable calculate due date                                                     Date calculate fine Journal superclass: Lendable calculate due date                                                     Date calculate fine Department of Information Engineering

77

• Borrower can be a staff or a student – Staff can borrow more books, has more privilege, and pays heavier overdue fine • How to model this relationship? – Inheritance or composition? Borrower

Teacher

Student

Department of Information Engineering

Borrower

Status

Teacher

Student 78

• When to use inheritance – To model is-a relation – A staff is-a kind of borrower • Problems with inheritance – Superclass is fragile – Subclass is rigid • Ask “what if” question – What if a student working part-time for the library, and has the status of a staff? – Perhaps different class of borrowing right? Department of Information Engineering

79

From analysis to design • OO Analysis (OOA) – Pay no attention to hardware/software platform, the database used, and the GUI required • OO Design (OOD) – Include real-world constraints, such as • Target environment (UNIX/PC?) • Language • User interface (X-window/Windows ?) • Database management (Oracle/MySQL?) • Class libraries, software components • Performance requirements Department of Information Engineering

80

Design model • Continuous refinement of classes – Add and refine classes, responsibilities, and collaborations up to implementation level • UI

– Keep the GUI subsystem as separate as possible – Add new class UI to serve as a layer that separate the application and the GUI • DB

– like UI, to separate the application from DBMSspecific calls Department of Information Engineering

81

Design model • Object creation scenarios – Who is responsible in creating/destroying the object? – What is the lifetime of the object? • e.g. Librarian and DB classes – A single object that lasted for the whole duration of the application process • e.g. objects like Borrowers and Lendable – created and destroyed more dynamically

Department of Information Engineering

82

Start-up scenario • Create a DB object – Only need one object for the system – Created by the Library application at system start up – Lifetime of the object lasted for the entire process – DB established a connection to the DBMS as it is created, and closed it when it is destroyed – Add CreateConnection responsibility in the DB card and write DBMS as the collaborator

Department of Information Engineering

83

Start-up scenario • Librarian

– Wait for user request – Add WaitForUser responsibility, collaborate with UI, because the UI has the responsibility to get the borrower’s Id • UI

– Add GetBorrowerId as a responsibility

Department of Information Engineering

84

main static DB db;

//static object

void main() { Librarian betty = new Librarian(); betty.WaitForUser(); //pass control to UI, wait }

Department of Information Engineering

85

Check-out scenario at design level • Design level scenario – Frank has no fine and one non-overdue book at home, want to check out a book called C# Primer • Librarian

– Wait for user to log in – Collaborate with UI to get the User’s Id – UI’s GetBorrowerId responsibility will handle user’s input, get the Id, and pass to Librarian • UI

– Collaborate with the C# Form classes to capture user input Department of Information Engineering

86

Check-out scenario • Librarian

– Frank enters his Id, I will collaborate with DB to create the Borrower object for Frank, who becomes my current Borrower • Cecilia (the developer) – Wait! The Librarian should verify whether Frank’s Id is correct first, before he can be the current borrower • Nancy (the OO expert) – Don’t overload the Librarian. It is becoming like a monolithic block of code. Better use a separate class called IdVerifier – The goal of OO design is to spread the knowledge and responsibility Department of Information Engineering

87

• Librarian

– OK, before I get a Borrower object, I collaborate with IdVerifier to verify the Id • IdVerifier

– I must have a Verify responsibility. I probably look in the current employee database table. Cecilia, you should add an Employee table to the database. Anyway, I found Frank • Librarian

– Good. Now I can collaborate with DB to get a Borrower Object using the employee Id • DB – I use my GetBorrower responsibility, in which I get data from the DBMS and then use it to Create Borrower Department of Information Engineering

88

Check-out scenario • Borrower

– As I create myself, I need to create my set of previously borrowed Lendable objects. Perhaps I will just create an empty set and DB will pass me the actual Lendable to put on it. • DB

– The Borrower table in the database will have the Id of the Lendable . So I use these Id and my Get Lendable responsibility to get data from the DBMS and to create Lendable. Actually, I create a Book object in this case (the book borrowed by Frank), which I can give to Borrower to add to her set using AddLendable responsibility Department of Information Engineering

89

Check-out scenario • Borrower

– I have an AddLendable responsibility, which I will add the Lendable to a container called Collection. I shall also have a DeleteLendable, a GetLendable, and a NumberOfLendables responsibilities • DB

– I will use Borrower’s AddLendable for each of the Lendable I found from database, then I can return the Borrower object to Librarian • Librarian

– I now have the Borrower object. I’ll ask Borrower to check whether it can borrow from the library. If it is OK, then I must use UI to get user’s choice, . . . Department of Information Engineering

90

Check-out scenario • Repeat the scenarios, refine the class diagram and the interaction diagram, try to develop a small prototype in C# code, see how the system works, shows the prototype to users, . . . • Iterative and incremental process • Each CRC design class maps to a C# class

Department of Information Engineering

91

Design model vs analysis model • Analysis model

• Design model

• conceptual model • generic, applicable to many designs • less expensive to develop • outlines the design • may not be maintained throughout the software life cycle

• physical model • not generic, specific to an implementation • more expensive to develop • manifests the design • should be maintained throughout the software life cycle

Department of Information Engineering

92

Implementation model • one-to-one mapping from design classes to code • Traceability - dependency between the models can easily be traced Design Model

Implementation Model

<>

<>

interface Department of Information Engineering

93

Artifacts from each stage Requirement model

Analysis model

Design model

Use case model

Refined Use case model

Refined Use case model

sequence diagram Glossary

class diagram

Refined interaction diagram refined class diagram

source code Department of Information Engineering

94

Case tools • Code generation – Generate C++/Java/C# code from UML class diagrams • Reverse engineering – Turn C++/Java/C# code into UML class diagrams • Round-trip engineering – Generate C# code from UML class diagrams – Edit the C# source code, compile and run – Update the UML class diagrams by reverse engineering – Repeat the iterations Department of Information Engineering

95

Reading list • • • • • • • •

A Laboratory for Teaching Object-Oriented Thinking by Beck and Cunningham (on CRC cards) – c2.com/doc/index.html UML resources (contains references to tutorials on UML) – www.omg.org Using the IBM RUP for small project – Gary Pollice – www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2 003/tp183.pdf A simplified approach to RUP – Gary Evans – www-106.ibm.com/developerworks/rational/library/354.html dX: A minimal RUP process – Martin, Booch, Newkirk – www.objectmentor.com/publications/RUPvsXP.pdf Extreme Programming (XP) – www.serverworldmagazine.com/webpapers/2002/01_kanbay.shtml A good introduction to XP – www.extremeprogramming.org A Comparison of the IBM RUP and XP – John Smith – www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2 003/TP167.pdf Department of Information Engineering

96