1 / 22

Software Engineering

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. From Class Diagram to Implementation.

reeves
Download Presentation

Software Engineering

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. 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

More Related