1. Implementation classes and developing relational databases IS Development Lecture 9

2. Implementation classes The physical side of system design Link to the entity or business classes to enable user interface development (also known as “boundary classes”) Implementation issues also surround the storage of persistent data about the business classes

3. Representation of the relationship (See Bennett, McRobb and Farmer, p. 408 for more detail)

4. Entity classes Implementation class

5. Linking implementation objects to business objects Eriksson and Penker, UML Toolkit

6. Examples of implementation classes Windows and Graphical User Interfaces Items or Controls within windows (note strong aggregation here) Web pages Standard packages: e.g. Java classes and ODBC (Open Database Connectivity)

7. Class Diagram for CheckCampaignBudgetUI 3 1 2 1 1 1 2 1 Dialog CheckCampaignBudgetUI LabelButtonTextFieldChoice

8. Creating relational databases from class diagrams Why? Most databases are relational while an increasing amount of systems analysis is object-oriented But underlying principles are different (set theory vs software engineering)

9. Differences in practice Inheritance and aggregation don’t exist in entity relationship models Multiplicity is much more varied in UML than in entity relationship models Object-oriented analysis is more relaxed about many:many relationships and the use of foreign keys

10. Strategies for coping with inheritance Make each class in the hierarchy as separate table (but proliferation of tables!) Make the superclass a single table and increase the number of fields to cover the subclasses. Only model concrete, not abstract, classes as tables.

11. Creating a single table from an inheritance hierarchy IDNameCust. Type

12. Making only concrete classes into tables Student Employee “Person” is probably an abstract class - all people here are either students or employees

13. Coping with aggregation and multiplicity Aggregation: classes become tables with cascade update/delete properties on relationships. Multiplicity: resolve M:M relationships into two 1:Ms with associative relations More subtle max and min values: use validation rules.