Representation of Prototype Diagram

As mentioned earlier, class diagram is useful to describe the structure of a system by showing the system’s classes, operations, attributes, and the relationships among them. However, on one hand the static model cannot depict the behaviours of objects. Dynamic models, on the other hand, cannot adequately represent considerations of structure and dependency relationships. Therefore, when it comes to representing the system’s design artefacts, it is a good choice to take advantages of various kinds of diagrams, such as using class diagram to describe the system’s structure while sequence diagram as a complement to illustrate how these objects interact.

Interactions between the objects are performed by messages transferring in object oriented technology. In UML models, the graphical representation of the message is a line segment with an arrow with which the message sender and receiver are connected. The type of message is represented by the arrow type. Both sequence diagram and communication diagram represent the interactions between objects, however, they emphasise the different aspects. Sequence diagram clearly depicts the time sequence among object interaction, but does not indicate the relationship among them. While communication diagram expresses the relationships among objects, but time sequence must be obtained from sequence number.

Thus, in this thesis, the class diagram dependency is analysed with the help of sequence diagram. Since sequence diagram describes execution scenarios of the system, the scenario path will be taken into account in the proposed method.

For the purpose of consistency, the definition of UML class diagram is given below.

Definition 4.1 UML class diagram Dcl is a tuple Dcl = {CLASS, ATTRIBUTE,

OPERATION, RELATION}, where

C LASS = {c1, c2,…, cn} is the finite set of classes in Dcl;

ATTRIBUTE is the finite set of attributes in Dcl;

ATTRIBUTE = {∀ci.attr_a | a ∈ ATTRIBUTE, ci ∈ CLASS};

OPERATION is the finite set of operations in Dcl;

RELATION is the finite set of relationships in Dcl;

REALTION = {∀ r | r ∈ REALTION, r = (ci, cj), ci, cj ∈ CLASS}.

UML class diagram depicts a variety of relationships among classes. In UML class diagram, relations are represented by association line and navigation arrow. Dependency, is a form of association that specifies a dependency relationships between two classes,a dependency is displayed as a dashed line with an open arrow that points from the client model element to the supplier model element. Different from other relations, dependency relation is very useful when describing class relationships with no attributes visible. For example, dependency relation shows whether one packet is aware of the existence of the other packet. The component of one packet does not reference any class, component, interface, method or service of the other packet if there is no dependency relation between them.

As mentioned in the previous section, sequence diagram in nature is a flow chart depicting an execution process. It is obvious that sequence diagram includes control dependency information. Scenarios describe the flow of events when executing a use case and each event flow is called a scenario. Scenario path represents the complete trace of threads execution in sequence diagram and it is the trace of participated objects interaction as well.

As described in [157], “a scenario is a formal description of the flow of events that occur during the execution of a use case instance, and it defines the specific sequence of events between the system and the external actors”. For the reasons above, scenario is used from sequence diagram to compensate the limitation of class diagram by reflecting the control dependency in sequence diagram to class diagram.

Definition 4.2 For a given class diagram Dcl = {CLASS, ATTRIBUTE, OPERATION,

RELATION}, a sequence diagram Dsq is a trituple = {OBJECT, LINK, MESSAGE},

where

OBJECT is the set of instance of CLASS in Dcl;

OBJECT = {∀obj| obj is the instance of ci, ci ∈CLASS}

instance of association relationship in RELATION in Dcl;

LINK = {∀ l | l = (obji, objj), obji, objj ∈OBJECT}

MESSAGE is a finite set of element representing the interaction between objects

which can be either synchronous or asynchronous;

MESSAGE = {m₁, m_2, …, m_n }

Message is the only way to communicate between objects in UML interaction diagram which conveys information with the expectation that action will occur. Links are thought as the instances of associations. It is against the rule to create a link in a sequence diagram if there is no relationship (i.e. association, aggregation, or composition) among the objects in the corresponding class diagram. As shows in Figure 4-5, there exists a link between the objects of POST and SALE. Message flows along with the link. A total() operation needs to be defined in SALE class if a total() message is sent to an instance of SALE class. In sequence diagram, messages are represented as arrows around the Links and are labelled with sequence number, names and arguments. The name of the message is the same to the name of object’s operation which must exist in the class where the receiving object is instantiated from. The numbers in the sequence diagram show the order of message occurrence. The sequence numbers are nested so that you can differentiate which messages are sent from within other messages.

:POST :SALE

1.1 tot:=total():integer 1.sysop()

Figure 4-5 Sequence Diagram Example

A message is shown as an arrow line from the sender message end to the receiver message end. A label is used to identify the number, guard condition, iteration or return value of message. Designer can find out the collaborations among objects, trace the

execution path and the variation of messages by identifying the syntax. The objects in the communication can be instantiated from the classes. There exists a corresponding relation in the class diagram for each link between the objects in the sequence diagram. It is exactly based on which can be used to aid the dependency analysis in the proposed method.