Information Technology Reference
In-Depth Information
DataTypes
RepairAction
Id
Person
Delivery
+by : Staff
+when : date
+detail : String
+id : UserId
+name : String
+email : String
+phone : String
+username : String
+password : String
+id : DeliveryId
+part : PartId
+from : Address
+to : Address
+comment : String
CompanyId
ContractId
User
0..*
0..*
UserId
PartId
DeliveryId
RepairId
+worksFor
0..1
0..*
Customer
Company
Part
Staff
Courier
RepairOrder
+id : PartId
+serialNo : String
+status : PartStatus
+manufacturer : CompanyId
+contractStart : date
+contractEnd : date
+salary : Money
+id : RepairId
+user : UserId
+handset : PartId
+open : date
+estimatedClose : date
+status : OrderStatus
+closed : date
+loanHandset : PartId
+delivery : DeliveryId
Company
0..*
+id : CompanyId
+name : String
+addr : Address
+phone : String
+contact : UserId
+contract : ContractId
+worksFor
0..1
0..*
RepairCentre
0..*
PerformanceFigures
0..*
Address
Money
Memory
Handset
SIM
Manufacturer
+capacity : int
+isLoan : Boolean
+number : String
0..1
«enumeration»
PartStatus
0..1
Contract
0..*
«enumeration»
OrderStatus
Contact
0..*
+id : ContractId
+startDate : date
+expiryDate : date
+feePerPhone : Money
+MonthlyFlatRate : Money
+company : CompanyId
+billingInfo : BillingInfo
+name : String
+number : String
Broken
BillingInfo
Operational
Open
Unfixable
HandsetWithManufacturer
HandsetReturnedToUser
Closed
Unknown
+sla
SLA
...
0..*
0..*
FIGURE 4.8: Data types used by the computational objects.
a computational specification to be created either top-down or bottom-up, or
even from both sides using an iterative process (sometimes called middle-out ).
So far, we have concentrated on a static structure to keep things simple,
but a computational design typically involves a dynamically evolving struc-
ture. This involves the computational objects in instantiating further com-
putational objects or computational interfaces, performing binding actions,
using the control functions of binding objects, dissolving bindings, deleting
computational interfaces or discarding computational objects. These mech-
anisms are modelled in ODP using the factory concept, which introduces
an object that, when given an object type and any necessary qualifying pa-
rameters, creates a new object and returns a reference to it. This pattern
is commonplace in systems nowadays, and found, for instance, in component
factories in platforms such as .NET or JEE.
For example, the login process for a staff member typically involves an
initial exchange with a generic presentation object, followed by the creation
of a specific proxy object in the presentation tier to manage the interactions
with that particular staff member. When the staff member logs out, the proxy
object is discarded. Similarly, an object managing some volatile grouping may
create a new interface instance for each new group member, thus enforcing
