Information Technology Reference
In-Depth Information
<<CV_OperationInterfaceSignature>>
ILogin
<<CV_OperationInterfaceSignature>>
IManufacturerOps
+login( name : String, pwd : String ) : UserId
+getPwd( eMail : String ) : String
+setPwd( name : String, newPwd : String ) : boolean
+getPendingRepairs( c : CompanyId ) : Part [0..*]
+setNewRepairDate( p : PartId, newDate : date )
+closeRepairOK( p : PartId, when : date, comment : String )
+closeRepairWithProblems( p : PartId, when : date, comment : String )
<<CV_OperationInterfaceSignature>>
IRepairOrderMgmt
<<CV_OperationInterfaceSignature>>
IUserOps
+addOrder( order : RepairOrder ) : boolean
+addAction( r : RepairId, action : RepairAction ) : boolean
+updateOrder( order : RepairOrder ) : boolean
+getOrderDetails( r : RepairId ) : RepairOrder
+removeOrder( r : RepairId ) : boolean
+getOrders( searchCriteria : StringExpression ) : RepairId [0..*]
+getRepairActions( r : RepairId ) : RepairAction [0..*]
+pendingOrders( u : UserId ) : RepairId [0..*]
+changeReturnAddress( r : RepairId, newAddress : Address ) : boolean
+closeRepairRequest( r : RepairId, result : boolean, comment : String )
+getDetails( u : UserId ) : User
+getEstimatedClose( r : RepairId ) : date
+repairOrderInfo( r : RepairId ) : RepairOrder
<<CV_OperationInterfaceSignature>>
IUserMgmt
<<CV_OperationInterfaceSignature>>
ICorporationAdmin
<<CV_OperationInterfaceSignature>>
IHRMgmt
+addUser( user : User ) : UserId
+removeUser( u : UserId ) : boolean
+updateUser( user : User ) : boolean
+getUser( u : UserId ) : User
+addCompany( company : Company ) : CompanyId
+removeCompany( c : CompanyId ) : boolean
+updateCompany( company : Company ) : boolean
+getCompany( c : CompanyId ) : Company
+addStaff( staff : Staff ) : UserId
+addRepairCentre( centre : RepairCentre ) : CompanyId
+removeStaff( s : UserId ) : boolean
+removeRepairCentre( rc : CompanyId ) : boolean
FIGURE 4.6: Detailed specification of operation interface signatures.
bindings that we showed in figure 4.1 or that we use later in figure 4.7, where
the signatures of the interfaces are explicitly specified.
4.6.2 Object Interfaces and Action Signatures
Once the software architecture is defined, the next step is to refine the
specific services that each object will provide to, or require from, other objects
by specifying the interfaces of the computational objects. This involves both
declaring the signature of their operations (see figure 4.6) and defining their
behaviour (which will be discussed in the next section).
Computational interfaces are represented in UML4ODP by means of UML
ports (see figures 4.5 and 4.7). The signatures for the services provided and
required by each port are specified in UML4ODP by using UML interfaces.
Thus, figure 4.6 shows the UML interfaces that specify the ODP interface
signatures characterizing some of the system interactions. The use of these
interface signatures is illustrated in figure 4.7, where the UML ball-and-socket
notation is used to express primitive bindings between the corresponding com-
putational objects.
Figure 4.7 includes further information about the components, such as
some of their internal realizing classifiers. For example, component Corpora-
tionDataMgmt manages the information about corporations that are clients of
the PhoneMob company. It represents a database that stores and manages
the relevant information about them and thus contains a realizing classifier
(the CorpMgmt
«
focus
»
class), which specifies its behaviour. This classifier
owns the information about the set of companies and customers known by the
system.
Note the use here of standard UML concepts and stereotypes for expressing
some of the model details, in addition to the UML4ODP stereotypes. For
example, UML classes stereotyped
«
focus
»
and
«
dataType
»
are used to make
