Object-Oriented Software Development with UML - UNU-IIST ...

120 Creating Collaboration DiagramsObject Store-XUPCQuantityPriceDescTotalBalancepress buttonTenderedEnter Item End Sale Make PaymentCashierInterface LayeronEnterItem():POSTApplet3:t=total():Float1:enterItem(upc,qty)2:[no sale] sale:=getSale():SaleDomain Layerp:POST1.1: create():sale:SaleFigure 7.38: Connecting interface and domain objectsThe interface layer should not have any domain logic responsibilities. It should only be responsiblefor interface (presentation) tasks, such as updating widgets.The interface layer should forward requests for all domain-oriented tasks on to the domainlayer, which is responsible for handling them.Interface layer has visibility to the domain layer and can directly send messages to the domainlayer. However, the domain objects usually do not have visibility to the interface layer, andcannot send messages to the interface layer.This principle supports the separation between the design of the domain layer (application layer) and thedesign of the interface.7.3.7 Design Class DiagramsDuring the creation of a collaboration diagram, we record the methods corresponding to the responsibilitiesassigned to a class in the third section of the class box. For example, see Figure 7.39.These classes with methods are software classes representing the conceptual classes in the conceptual models.Then based on these identified software classes, the collaboration diagrams and the original conceptualmodel, we can create a design class diagram which illustrate the following information:classes, associations and attributes¾methods,¾¾types of attributesReport No. 259, July 2002UNU/IIST, P.O. Box 3058, Macau