1COMP5028
Object Oriented Analysis & Design
Week 11: Implementing Diagrams
Today’s Topics
• Leftover statecharts from last week
• Implementing models in Java
• a little bit of XML
• Lab 7 sample solutions
Communication within Composites
• Use forks and joins as you normally would in
activity diagrams
• Use sync states to queue entries
– the number inside the queue is the number of entries
in that queue
Initialising
InitialiseSensors
InitialiseAlarm
*
History State
• Allows you to “pick up where you left off”
• “H” inside sync state circle
BrowseCatalogue
ViewCategory
ViewItem
H
Pay
Checkout
2Turning Models into Code
• Many tools will auto-generate code skeletons for you
• Some IDEs allow you to go back and forth between
code and UML models, e.g. JBuilder Enterprise
• Code templates are just that; you have to understand
the code that is created
• You have to fill in the implementation details
• You have to debug it!
Writing Code
• You can write your own code from scratch almost as
easily for all but the biggest systems
• You can find improvements to the design as you’re
coding
• You should be integrating unit testing as you develop
code anyway
• Refactor code, refine design, iterate
• You will have to make more design decisions as you
implement, but these should not be business decisions
Produce a Class Skeleton First…
BankAccount
-owner: Customer
-balance: int = 0
-acctNumber: int
+BankAccount(owner: Customer)
+deposit(amount: int)
+withdraw(amount: int): boolean
-hasFunds(amount: int): boolean
#close()
class BankAccount {
private Customer owner;
private int balance = 0;
private int acctNumber =
getNextAcctNumber();
public BankAccount(Customer owner){}
public void deposit(int amount){}
public boolean withdraw(int amount){}
private boolean hasFunds(int amount){}
protected void close(){}
}
Then Flesh Out the Code…
• Now we’re back into
traditional coding
• In OOA&D we stop
at this point
class BankAccount {
private Customer owner;
private int balance = 0;
private int acctNumber =
getNextAcctNumber()
public BankAccount(Customer owner)
{
this.owner = owner;
}
// more code...
private static int nextAcctNumber = 1;
private static int getNextAcctNumber()
{
return nextAcctNumber++;
}
}
3Attribute adornments (1)
• Get those multiplicities right
– Through appropriate structures
List employees = new LinkedList();
Employee[] employees =
new Employee[MAX_EMPLOYEES_ALLOWED];
– Through constraints in methods
private static int numEmployees
public void addEmployee(Employee gopher) {
if (numEmployees == MAX_EMPLOYEES_ALLOWED)
throw new TooManyEmployeeException();
employees.add(gopher);
}
Attribute adornments (2)
• Get those visibilities right
– Use packages to isolate subsystems
– Watch for differences between languages & UML in scope
• Turn roles and relationships into attributes
– Explicitly follow navigability
class BankAccount {
private Customer owner;
...
}
BankAccount Customer
1 1
account owner
Not used
Packages, Interfaces, Abstract Classes
EmployeeDatabase
package database
...
interface Employee {}
class Person implements Employee {} Person
Employee
abstract class Employee {}
class Person extends Employee {}
Person
XML
• eXtensible Markup Language
• Generalisation of HTML
• Isolates structure in a collection of objects
• Principally a hierarchical structure
• Defacto universal interchange format
• Quite verbose
• Basic syntax
content
4XML Example
BankAccount
-owner: Customer
-balance: int = 0
-acctNumber: int
class BankAccount {
private Customer owner;
private int balance = 0;
private int acctNumber;
}
...
0
100
•Attribute objects are often shown as content
•Don’t worry about DTDs, constraints, etc.