Software Implementation: From UML Class Diagrams to Java Code

1. Software Engineering Chapter 8 Software Implementation from UML • Learning Outcomes • Know how to translate the components of a class diagram into Java Ref: This chapter leans heavily on Priestley – Practical Object Oriented Design with UML Ch 5

2. From Class Diagram to Implementation • Class diagram shows classes, attributes, methods and associations in the application • Generally, it will NOT contain low-level detail • E.g. how to display a window or listen for a mouseclick • Application Frameworks contain the generic code for this • E.g. Diagram editor application will require code • To manage the interaction of the application with the environment e.g the applet starting in a browser • To detect user input/output • To provide graphics functions • Frameworks can be developed for different target environments • E.g an applet framework

3. Hotspot Classes • Frameworks can be implemented using ‘Hotspot’ classes Framework code Application code • Hotspot classes define a number of operations which are needed by the application • These are standard but for special cases can be overridden

4. Applet Framework • Refer to Diagram Editor class diagram • Need applet class

5. Java API code Java - Widgets would also be in here

6. User input/output • Sequence diagrams good for representing this • Mouse is moved, message sent to DiagramEditor object, then to selected tool • Implication: DiagramEditor class needs to override the Canvas mpuseMove()

7. Selected scenarios • E.g Draw a diagram

8. Implementing Classes • UML Classes are implemented as Java classes (or C++…) • Attributes defined (normally) as private data • Methods/Operations defined (normally) as public methods Tool publicabstractclass Tool { private Point current; public void delete(){} publicabstractvoid move(Point p); publicabstract void press(); publicabstract void release(); } current : Point delete()move(Point)press()release()

9. Inheritance • Generalisation/ Specialialisation implemented using inheritance publicabstractclass Tool { private Point current; publicvoid delete(){} public abstract void move(Point p); public abstract void press(); public abstract void release(); } public abstract class CreationTool extends Tool{ Point start; public void move(Point p){ ...etc } }

10. Associations • Associations define links between objects I.e. that one object knows about another • references i.e. the address of an object/ pointer to it • An association might imply that one object sends a message (I.e. calls one of its methods) or receives a message from another object of a different class. • These messages may involve sending the object as a parameter I.e its reference • Also – some associations imply that one object is made up of another (even if an aggregation symbol has not been used!)

11. Mandatory (immutable) Associations publicclass Account { //data private Guarantor theGuarantor; //constructor public Account(Guarantor g){ if (g == null) { // ... throw NullLinkError } theGuarantor = g; } public Guarantor getGuarantor(){ return theGuarantor; } } reference

12. Optional Associations publicclass Account { private CashCard theCard; public CashCard getCard() { return theCard; } publicvoid setCard(CashCard card) theCard = card; publicvoid removeCard() { theCard=null; } } reference Set to null I.e can be optional

13. Associations with ‘many’ multiplicity • Need a data structure to hold multiple references (pointers) E.g. vector, array, linked list… import java.util.*; publicclass Manager { private LinkedList theAccounts; public Manager() { theAccounts = new LinkedList(); } publicvoid addAccount(Account acc){ theAccounts.add(acc); } publicvoid removeAccount(int accIndex){ theAccounts.remove(accIndex); }//...etc }

14. Bi-directional Associations • i.e where the association is valid in both directions • Need a reference in each class • Problem – referential integrity = making sure they are consistent! i.e. publicclass Account { private Guarantor theGuarantor; public Account(Guarantor g){ if (g == null) { // ... throw NullLinkError } theGuarantor = g; //code in here to check g has //correct reference to this //instance of Account } }

15. Bi-directional 1:1 • Suppose we need to reference Account from CashCard • When we create a CashCard we need to assign a reference to it for the Account it belongs to See earlier for Account code publicclass CashCard { private Account acc; public CashCard() { public CashCard(Account a){ //code in here to create a CashCard linked to // this instance of Account } public Account getAccount(){ //code in here to return the linked account } } } A GOOD SOLUTION??? See over

16. publicclass CashCard { private Account acc; CashCard() { CashCard(Account a){ acc = a; } public Account getAccount(){ return acc; } } } Bi-directional 1:1 cont. ‘public left out’ – why? • NO! • Both classes have to maintain the correct reference. • Very easy for a programmer to omit one • Better solution = allow one class only to maintain the refernce • Which one? • In this case Account seems logical since it will be created before CashCard public class Account{… public void addCard(){ theCard=new CashCard(this); }

17. Bi-directional 1:* • Same problems/solutions as 1:1 • Except – it is logical that the 1 side should be the one to maintain responsibility for creating the link • I.e. Customer has the relevant code

18. Aggregation publicclass InvoiceItem { //data private int itemNo; private String partNo; private String partDescription; private String partQuantity; //constructors public InvoiceItem(){ } public InvoiceItem(String p, String d, String pQ) { partNo = p; partDescription = d; partQuantity = pQ; } //rest of methods here // etc... }

19. Aggregation continued publicclass Invoice { //data private int invoiceNo; private String deliverTo; private InvoiceItem itemDetails; //constructor public Invoice(int newInvoiceNo, String deliveryDetails) { invoiceNo =newInvoiceNo; deliverTo=deliveryDetails; itemDetails = new InvoiceItem(); } }

20. Qualifiers public class Bank { private HashTable theAccounts; publicvoid addAccount(account a){ theAccounts.put(new Integer(a.getNumber()),a); } public void removeAccount(int accno){ theAccounts.remove(new Integer(accno)); } public Account lookup(int accno){ return(Account) theAccounts.get(new Integer(accno)); } } Used to pick out the correct account instance

21. Association Classes • Often done like this

22. Software Engineering Chapter 8 Software Implementation from UML • Learning Outcomes • Know how to translate the components of a class diagram into Java Ref: This chapter leans heavily on Priestley – Practical Object Oriented Design with UML Ch 5