1. From Class Diagrams to Databases

2. So far we have considered “objects” Objects have attributes Objects have operations Attributes are the things you record about an object Operations are things you “do” to objects Databases

3. Databases are used to store attributes name address telephone number customer order() pay for goods() name address telephone number We “remember” attributes by storing them on a computer’s hard disk The most common way to keep a record of the attributes is to use a database

4. Ways of remembering attributes Relational Databases Easy to get things in and out Can do clever things Files Hard work Cheaper and less to learn Forget the clever things Object Oriented Databases Every computer scientist’s dream But they don’t work too well yet

5. A database is a collection of tables Parts Customers Orders

6. Linking tables together One record refers to another by recording its key So the order record holds the key of the customer record Foreign key Primary key

7. Entity-relationship diagrams These are like class diagrams They show tables instead of objects

8. So what do we store from an object-oriented analysis Later we will talk about: Boundary objects that define interfaces such as screens Control objects that define where complex processing is done Entity objects that are the primary objects We store the entity objects in the database because boundary objects such as screens don’t need their states recording for long times – they are transient control objects do their work and you forget about them entity objects need to be used again and again – need to be persistent

9. Get stored in database Don’t get stored in database

10. A Class diagram

11. Customer order

12. Add multiplicity

13. Add attributes Customer Surname Forename Address TelNo Order Date Payment method 0..n places OrderItem Quantity 1..n made up of Product Description Price Size Colour 1..n of 0..n 1..n

14. Add Primary Keys Customer Customer No Surname Forename Address TelNo Order Order No Date Payment method 0..n places OrderItem Item No Quantity 1..n made up of Product Product ID Description Price Size Colour 1..n of 0..n 1..n

15. Add Foreign Keys Customer Customer No Surname Forename Address TelNo Order Order No Customer No Date Payment method 0..n OrderItem Item No OrderNo Product ID Quantity 1..n Product Product ID Description Price Size Colour 1..n 0..n 1..n

16. These are the tables of your database Customer Customer No Surname Forename Address TelNo Order Order No Customer No Date Payment method OrderItem Item No OrderNo Product ID Quantity Product Product ID Description Price Size Colour

17. More on Implementing Relationships The attributes of the object map to columns in a table. An object is stored as a row in a database table

18. Storing Objects loan loanNumber customerNumber amountBorrowed LoanNumberCustomerNumberAmountBorrowed 15221£122.00 16331£62.50 16421£19.25 Objects stored as rows Attributes stored as fields

19. One-to-many relationships A customer places many orders An order is for many products A loan can have many payments A course has many students Record relationship by storing key of one side in the table on the many side

20. loan loanNumber customerNumber amountBorrowed payment date amount 0..n Attributes into a table Record relationship by storing key of one side in the table on the many side One-to-many relationships

21. Many-to-many relationships Many Customers order many items. Many clients book many holidays Many students select many modules Whilst many to many relationships are perfectly acceptable in class diagrams, they cannot be implemented directly into relational databases. A customer will not link directly to a product item A product item will not link directly to a customer It is usual to produce a linking table to connect the two lots of information.

22. Attributes into a table Create a table to store the relationship with keys from each of the other tables Many-to-many relationships

23. More objects So far, we have looked at the idea of objects. When you build an "object oriented" system, everything is an object. We have not really considered all the different types of object. We have looked at entity objects and seen how they can be made into relational database tables Now we will look at: boundary objects and control objects.

24. Design Objects Add structure to the implementation Separate out interface, control and entity behaviour Make systems more maintainable Clarify design issues

25. Transferring Money Primary Path: 1. Withdraw cash from account 1 2. Deposit cash in account 2 Our initial model Documentation

26. First sequence diagram

27. Problems This model assumes that once the clerk has requested that account1 transfers funds, it will know to withdraw money from itself and credit account2 Accounts in the real world do not know about each other, so this would be unnatural You need to log or record transactions, so the account would have to have a transaction logging ability, so again not natural If you wire up your objects this way, the wiring can get very messy

28. Better model:

29. Why is it better? There is a new notion of a “control” object called “Transfer” The control object knows how to execute a transfer Accounts know how to be accounts The control object can be responsible for other related transaction items (e.g. journaling)

30. Interfaces The previous model didn’t consider any interface behaviour

31. Even better

32. Why? Actors always interact with boundary objects (e.g. screens) Screens often do lots of things, such as collect data, before causing some internal action to take place Screens instruct control objects to do things when they have all the information they need

33. Object types Control Entity Boundary

34. Control Objects Group inter-object communication Stop entity objects from having to “know” more than is necessary to behave as entities Can do meaningful housekeeping Are easier to rewire than if interaction is spread through the network

35. Entity objects Are the basic “domain” objects Find these first They are the things that tend to need to persist They usually become database tables Should know about their own behaviour

36. Boundary objects Define interfaces Includes things like screens, web pages, sub-windows Separate interface from control and entity

37. A standard design pattern for interactive systems There is an actor involved in the interaction There is a boundary object (e.g. screen) to which all actor interactions are directed The boundary object passes on some requests to a control object The control object deals with the entity objects The entity objects are stored as database tables

38. A standard design pattern

39. A simpler design pattern Merge the boundary and control class Normal for simple interactions Common way of working with simple packages like Microsoft Access

40. A simpler design pattern

41. Summary We have considered the three basic types of system object: Control Entity Boundary We have seen how to use each type properly to improve the design of a system. We can see how the objects would contribute to: –a relational database system –an object based system.