Formalization of Functional Requirements and Their Traceability in UML Diagrams A Z Notation Based Approach Sabnam Sengupta 1,Swapan Bhattacharya 2 Department of Computer Science & Engineering, Jadavpur University, Kolkata 700032, India. 1 sabnam_sg@yahoo.com, 2 bswapan2000@yahoo.co.in Abstract- In this paper, we propose an approach for formalizing the Functional Requirements section of a SRS document and establish traceability of these requirements among different UML diagrams that are used in requirement analysis and design phases after formally representing them, using Z notation, which is a nonexecutable, but, a strongly typed specification language. We represent the formalized functional requirements with their traceability among different UML diagrams visually using E-R Diagram. Development of a tool based on this approach will produce a visual representation of formalized functional requirements and their traceability among different formalized UML diagrams, from which automated traceability of requirement in different phases of software development can be achieved. This tool will enable us with a solution that will be formal and hence automatically verifiable, at the same time understandable by both the developers and users. Index Terms: Traceability, Functional Requirement, UML, Use case diagram, Class Diagram, Sequence Diagram, Z notation, Formalization, ER Diagram, Automated verification. INTRODUCTION In order for the vision of the OMG s model driven architectures to become a reality and software or system development automation to become a success, it is essential, at least to constrict the huge semantic gap between nonformal requirements and semi-formal or formal design specifications in subsequent development phases, and that goes down to the code level. This would enable engineers to employ tools to automatically map requirements into designs and eventually into code within one development project. According to Gotel and Finkelstein [7], Requirement Traceability is The ability to describe and follow the life of a requirement, in both a forward and a backward direction, i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases Requirements are the agreement between the customer and the developer regarding the artifacts to be produced. Functional requirements are the requirements to support the various aspects around operation of and interaction with one or more semantic services. The next step in a standard development process will be the derivation of a design of the system based on these requirements. This activity results in design documents. Nowadays, the main reason for failures of largescale systems development is that the requirement analysis stage fails to produce complete, understandable, unambiguous, traceable and testable system requirements documents. The main reason behind this is that, Requirements documents are primarily written in natural language and it is not possible to establish automated traceability of requirements in the subsequent phases of software development. Due to its informal nature, there is no way of making sure that each and every requirement in the Software Requirement Specification (SRS) document has been addressed in the design phase. UML use case diagrams are applied to capture the intended behavior of the system being developed without specifying how the behavior is implemented.
Unified Modeling Language (UML) [1, 2] UML is a set of Object Oriented modeling notations that has been standardized by the Object Management Group (OMG) [2]. But, due to semiformal nature of UML, it is not possible to apply rigorous automated analysis or to execute a UML model in order to test its behavior. This has given rise to the need for development of some formal or semi-formal language, which would augment UML and would be able to describe the entire system in totality. Due to these reasons, formalization of UML diagrams is now a dominant area of research. Formal specifications use mathematical notation to describe in a precise way the properties, which an information system must have, without unduly constraining the way in which these properties are achieved. This abstraction makes formal specifications useful in the process of developing a computer system. A formal specification can serve as a single, reliable reference point for all associated with the entire software life cycle. The Z notation [3, 4] is a strongly typed, mathematical, specification language. It is a model-based notation. It is not an executable notation; it cannot be interpreted or compiled into a running program. There are some tools like ZTC [5] for checking Z texts for syntax and type errors in much the same way that a compiler checks code in an executable programming language. We here propose an approach to establish traceability of functional requirements among some of the widely used UML diagrams, used in analysis and design phases of software development, after formally representing requirement and UML diagrams using Z notation. Finally we propose to represent formalized functional requirement along with their traceability within formalized UML diagrams visually using Entity Relationship (ER) diagram. REVIEW OF RELATED WORKS Lots of research work is going on in the direction of requirement traceability. Formalization of UML diagrams using Z notation is another dominant area of research these days. There are a very few works in the direction of visualizing Z notation, [6] is an example of the works in that domain. In this section, we will discuss some of the relevant works in the field of Requirements Traceability. Different approaches have been developed to automate the acquisition of trace information. Typically these approaches support the creation or recovery of traces between two types of engineering artifacts (e.g., design/code, code/documentation, requirements/architectures). For example, Antoniol et al. discuss a technique for automatically recovering traceability links between object-oriented design models and code based on determining the similarity of paired elements from design and code [9]. Murphy et al [16] suggest software reflexion model showing where the engineer's high-level model agrees with and where it differs from a model of the source. Antoniol et al describe an approach to automatically recovering trace information between code and documentation [8]. Other approaches discuss specific traceability issues without focusing on automation: Arlow et al emphasize the need to establish and maintain traceability between requirements and UML design and present Literate Modeling as an approach to ease this task [10]. Gotel and Finkelstein extend the view of artifact based RT and focus on understanding the social network of people that contributed in the development of requirements [25]. Pohl et al describe an approach based on scenarios and meta-models to bridge requirements and architectures [12]. Grünbacher et al. discuss the CBSP approach that improves traceability between informal requirements and architectural models by developing an intermediate model based on architectural dimensions [15]. Gruber et al. discuss the problems of design rationale capture and demand the need for automatically inferring rationale information [14]. Further work will concentrate on developing automated support assisting engineers in exploring and using the automatically derived trace dependencies. For example, by highlighting artifacts and situations that requires special attention [17]. As said earlier, most of these approaches propose to establish the creation or recovery of traces between two types of engineering artifacts
(e.g., design/code, code/documentation, and requirements/architectures). In this paper, we, too, propose to establish traceability of functional requirement in UML diagrams used in analysis and design phases of software development. Additionally, we propose to formalize a functional requirement and the UML diagrams, within which we propose to establish traceability of requirements, using Z notation. Finally, we represent the formalized requirement along with its traceability among UML Diagrams visually using an ER diagram. As this requirement traceability is followed by formalization, a tool based on this approach would empower us in achieving automated traceability of requirement and automated checking of consistency among UML diagrams used in analysis and design phases of software development. SCOPE OF WORK In this paper we propose to establish functional requirement traceability in UML diagrams used in analysis and design phases and check consistency among the same UML diagrams based on the traceability parameters and consistency rules proposed in section IV. In order to do so, we have used Z notation as a standard for expressing the functional requirement section of a SRS and some of the UML diagrams (use case, class and sequence diagrams along with a few of their elements) in a formal manner. In Section IV we propose some basic traceability parameters of functional requirements and consistency rules among different UML diagrams. After we formalize requirement and these diagrams in Section V, these parameters are met and the rules get satisfied. In section VI, we demonstrate verification of traceability parameters and consistency rules after formalization. Finally we represent the formalized functional requirements along with their traceability among UML diagrams visually using an ER diagram in Section VII. We demonstrate our approach with the help of a simple case study in section VIII. Our approach would bridge the semantic gap between functional requirements of a SRS document and UML diagrams that has become a de-facto industry standard for analyzing and designing object oriented systems. This approach would also bridge the gap between a visual modeling language, that is easy to understand, and Z notation, that is formal, i.e., mathematical and difficult to understand by the users and the developers. A tool based on our approach would generate a visual representation of a formalized functional requirement and UML diagrams from which automated verification of functional requirement traceability and consistency among diagrams used in different phases of software development can be achieved. REQUIREMENT TRACEABILITY PARAMETERS AND CONSISTENCY RULES Based on the relationships among functional requirements of a SRS document and different UML diagrams, a number of traceability parameters and consistency rules can be developed. These parameters and rules verify some of the basic existence parameters between the requirement and different diagrams, which are necessary conditions for ensuring requirement traceability among UML diagrams used in different phases of software development. A. Requirement Traceability Parameters A functional requirement has an ID and a description. A functional requirement has to be captured by at least one use case. More than one use case can capture a functional requirement. B. Consistency Rules Rule 1: Rules for Use Case Diagram: A use case can capture one and only one functional requirement. A use case should contain at least one event. An event has to be of type either basic or alternate. An event has to be handled by at least one method Rule 2: Rules for Sequence Diagram: Any method that handles an event has to be present in a message of a sequence diagram. A message can be between two objects or between an actor and an object. Each message can either be a string or a method.
Rule 3: Rules for Class Diagram: All the methods that handle events of a use case and present in a sequence diagram has to be present as a method of a class of a class diagram. FORMALIZATION OF FUNCTIONAL REQUIREMENT AND UML USING Z NOTATION SCHEMA In this section, we propose to formalize the functional requirement section of a SRS document along with a few UML diagrams using Z notation in order to establish requirement traceability among different UML diagrams used in different phases of software lifecycle. We first propose to formalize a functional requirement followed by use case diagram that is widely used to capture requirements in the requirements specification and analysis phase. In order to do so, we represent an event and a use case as a Z notation schema. We suggest a one-tomany relationship among a use case and an event, i.e., a use case consists of at least one event and an event is a part of one and only one use case. So, we are formally making sure that a functional requirement is getting captured by at least one use case that consists of events. We propose to map an event with a method. This approach checks that an event is handled by at least one method in the design phase. So, a functional requirement is getting handled by at least one method at the design phase. We formalize a method using Z notation schema as well. This method has to be a part of a class in the class diagram. We propose to formalize the class diagram using Z notation, also. The same method has to be the part of a message of a sequence diagram. We also propose to formalize a sequence diagram using Z notation. Our approach of traceability establishment can be diagrammatically represented as: Functional Requirement Class Diagram Sequence Diagram Class Use Case Message Fig 1: Roadmap to Traceability of Functional Requirement Method A. Formalization of Functional Requirement A formal specification of a SRS document in IEEE format [18] would include the declaration: [Introduction, OverallDescription, SpecificRequirements, Appendixes, Index] Similarly, Specific Requirement can be formally specified as: [ExternaIinterfaceRequirements, FunctionalRrequirements, PerformanceRequirements, DesignConstraints, SoftwareSystemAttributes, OtherRequirements] The Z nation schema for a Functional Requirement is: FunctionalRequirement desc: seq char capturedbyusecaseid: capturedbyusecaseid = dom UseCase # capturedbyusecaseid limit Here limit is a global variable can be axiomatically defined as limit : N limit = 1 A. Formalization of Use Case Diagram In this section, we propose to map events of a use case with the use case itself. Then we formalize the use case and its events using Z notation schema. While formalizing the, we introduce an attribute handledbymethodid to ensure that each and every event gets handled by at least one method in the design phase. This will help us tracking the requirements in the design phase and also verifying that all the requirements have been addressed in the design automatically. A formal specification of a use case diagram would include the declaration: [UseCase, Actor, UseCaseRelationship, ActorRelationship] The Z notation schema for a use case is: UseCase name: seq char eventid: capturesfuncreqid: eventid = dom #eventid limit #capturesfuncreqid = limit
We represent each event of the Flow of events or Alternative flow of events using a Z notation schema: ucid: desc: seq char type:seq char handledbymethodid: type Є {basic, alternate} ucid = dom UseCase #ucid = limit handledbymethodid = dom Method #handledbymethod limit We next define a method as a Z notation schema B. Formalization of a method Using Z Notation Schema In this section, we formally represent a method using Z notation schema. A method is an element of a class diagram and a sequence diagram and some other diagram. In this paper, we propose to establish consistency among different diagrams used in different phases of software development through a method. This is why, we propose to formalize a method, as a method acts as a bridge among different UML diagrams. The Z notation schema for a method is: Method name: seq char returntype: seq char parameters: data memberofclass: seq char returntype Є datatype memberofclass = dom ClassDiagram Where datatype is a set of data types declared in a programming language. For example, if we consider Java as a programming language, datatype = {byte, short, int, long, float, double, char, boolean, Object} variable = datatype identifiername data = variable,., variable If the method is declared to throw any Exceptions in its signature is not within the scope of this paper. C. Formalization of a sequence Diagram Using Z Notation Schema A sequence diagram realizes a use case in design phase. It is composed of messages between two objects or an object and an actor. These objects are the instances of the classes declared in the class diagram. In this section, we formalize a sequence diagram using Z notation. A formal specification of a UML Sequence diagram would include the declaration [Message] We here propose a Z Notation schema for the Message of a sequence diagram. Message fromobjectofclass: seq char toobjectofclass: seq char methodid: methodid = dom Method methodid == 0 ((fromobjectofclass = dom Class) ^toobjectofclass = dom Class)) (fromobjectofclass == Actor toobjectofclass == Actor) D. Formalization of a class Diagram Using Z Notation Schema A Class diagram consists of classes and relationships among the classes. A formal specification of a UML Class diagram would include the declaration [Class, Relationship] We here propose two Z notation schemas, one representing a class and the other one representing Class realatinships. Class name: seq char attributes: variable methodids: methodids= dom Method VERIFICATION OF TRACEABILITY PARAMETERS AND CONSISTENCY RULES In this section we verify requirement traceability parameters and consistency rules proposed in section IV, after formalizing functional requirement and relevant UML diagrams.
A. Verification of Requirement Traceability Parameters A functional requirement has an ID and a description. From the Z notation schema for Functional Requirement: desc: seq char A functional requirement has to be captured by at least one use case. capturedbyusecaseid: capturedbyusecaseid = dom UseCase More than one use case can capture a functional requirement. # capturedbyusecaseid limit B. Verification of Consistency Rules Rule 1: Rules for Use Case Diagram: A use case can capture one and only one functional requirement. From the Z notation schema for a use case, capturesfuncreqid: #capturesfuncreqid = limit A use case should contain at least one event. eventid: eventid = dom #eventid limit An event has to be of type either basic or alternate. type Є {basic, alternate} An event has to be handled by at least one method handledbymethodid: handledbymethodid = dom Method #handledbymethod limit Rule 2: Rules for Sequence Diagram: Any method that handles an event has to be present in a message of a sequence diagram. From the Z notation schema of a message, methodid: methodid = dom Method methodid == 0 A message can be between two objects or between an actor and an object. fromobjectofclass: seq char toobjectofclass: seq char ((fromobjectofclass = dom Class) ^toobjectofclass = dom Class)) (fromobjectofclass == Actor toobjectofclass == Actor) Each message can either be a string or a method. methodid = dom Method methodid == 0 Rule 3: Rules for Class Diagram: All the methods that handle events of a use case and present in a sequence diagram has to be present as a method of a class of a class diagram. From the Z notation schema of a class: methodids: methodids= dom Method DERIVATION OF E-R DIAGRAM FROM Z NOTATION SCHEMA We can represent the Z notation schemas representing a Elements of Use Case Diagram, Class Diagram and sequence diagrams in an ER diagram as shown in Fig 5 of Appendix: This ER diagram is implemented in the tabular formats as below: Functional Requirement ID Use Case ID Message ID Use Case Name Functional Requirement Description ID From Object of Class Name type Desc To Object of Class Name Use Case ID handled by method ID Method Id Class Name Attribute Method ID We now explain our approach with the help of a simple case study of a library system. I. CASE STUDY The Functional requirement section of a SRS of a simple library system would look like: 3.2.1 A person can get membership of the library. 3.2.2 The librarian can issue a book for a member of the library, provided, 3.2.2.1 the member is valid, 3.2.2.2 the maximum issue limit of the member has not yet reached, 3.2.2.3 the book is valid,
3.2.2.4 If the book is available for issue 3.2.2.5 the member status gets updated 3.2.2.6 book status gets updated 3.2.2.7 the transaction record gets updated. 3.2.3 A member returns a book, provided, 3.2.3.1.. 3.2.3.2. For the sake of brevity, we have only expanded the functional requirements related to book issue only. The use case diagram of a Library system is given in fig 2. For simplicity we here consider only one use case Issue Book in a library. We also do not consider the use case relationship and class relationships for the sake of brevity. The realization of the use case is modeled using Sequence diagram of UML as shown in Fig 3. The class diagram depicting Member class only is shown in Fig 4. 10. Book status updated. 11. Use case ends. Alternate flow of events for the use case Issue Book : 1. The use case Validate Member returns invalid member ID. 2. After three consecutive tries the use case ends. Another Alternate flow of events: 1. The member ID is valid, but the member has exceeded his quota. 2. A message appears on the GUI and the use case ends. Another Alternate flow of events: 1. The use case Validate Book returns invalid book ID. 2. After three consecutive tries the use case ends. Another Alternate flow of events: 1. The book id is valid, but the book is not available. 2. A message appears on the GUI and the use case ends. Our approach ensures that each and every event of the use case description gets handled by at least one method. A method is a part of a sequence diagram and a class diagram, also. The sequence diagram for the use case Issue book is: Fig 2: Use Case Diagram of a Library System The basic flow of events of the use case Issue Book is: 1. The librarian enters the member ID. 2. The use case Validate Member is included. 3. Checking is made if issue limit for the member has exceeded. 4. The librarian enters book id. 5. The use case Validate Book is included. 6. Checking is made to see if the book is available. 7. The use case Update Transaction is included. 8. Book is issued. 9. Member status updated. Fig 3: Sequence Diagram for the use case Issue Book
The Class diagram for the library system is: Fig 4: Class Diagram of a Library System The Table structure of this system corresponding to the ER diagram is given in Table I, Table II, Table III, Table IV and Table V of Appendix. For brevity, only parts of the table structures are shown. In Table 3, i.e., the Method table, we have excluded return type and attributes for the sake of simplicity. In Table 4, we have not considered the attributes of the classes for the same reason. With the help of this case study, we have tried to demonstrate how a functional requirement of a SRS document can be made traceable among different UML diagrams used in analysis and design phases of software development. Consistency among these UML diagrams is also established after these diagrams are formalized. A tool developed based on our approach will enable us automated requirement traceability in different phases making sure each and every requirement has been addressed in subsequent phases. It will also empower us with production of a visual representation of formalized functional requirement along with its traceability among different formalized UML diagrams along with their relationships, where, consistency will be automatically checked. CONCLUSION Software development is a human intensive activity and the need for better and higher quality software has led to the evolving field of software engineering. In the recent decades, we have witnessed a phenomenal increase in the functional and structural complexity of software systems being produced. Object oriented methodology has emerged as one of the most common paradigms for design and development of information systems today. Timely production of such products and verification of their functional correctness has been major challenges. In particular, it has been observed that incorrect or incomplete specification of the software is often a major hindrance in the development process. A Formal Specification, on the other hand, is made in a formal language, and hence is unambiguous, and can be tested for correctness. It is costeffective to formalize characteristics at initial stages of software development. So, it makes much more sense from the perspective of cost effectiveness as well as software evolution if we can formalize the behavior of the system right at the functional requirement specification level. The adoption of UML as a standard for modeling functional requirement specifications of object-oriented systems has made modeling simpler and easy to understand with lots of tools supporting it. However, UML being a visual language is semi-formal in nature and hence formalizing functional requirement specification using UML has triggered challenging opportunities of research in this domain. There are mainly two directions of research Requirement Traceability and Formalization of one or more UML diagrams. Our work falls in both the categories. In this paper, we propose to formalize functional specification part of a SRS document using Z notation and establish traceability of requirements using UML diagrams used in different phases of software development. We also formalize UML Use Case diagram, which has become a de-facto industry standard for capturing requirements, Sequence diagram and Class diagram, which are used widely in analysis and design phases, with Z notation, establish consistency among them. Finally, we represent the
formalized functional requirement along with its traceability among formalized UML diagrams visually using ER diagram. A tool based on our approach would empower us achieving automated requirement traceability that would help software engineers to produce formal, traceable and modifiable functional requirements. Our work is a step forward in that direction. Reference: [1] Grady Booch, James Rumbaugh, Ivar Jacobson; The Unified Modeling Language User Guide (1999) [2] OMG: Unified Modeling Language Specification, version 2.0. Available at http://www.omg.org/uml [3] J.M. Spivey, The Z Notation, A Reference Manual, 2nd edition. Prentice Hall International, 1992. [4] Jim Woodcock, Jim Davis; Using Z Specification, Refinement and Proof, Prentice Hall, 1996 [5] Xiaoping Jia, ZTC: A Type Checker for Z Notation User s Guide Version 2.2, October 2002 [6] Thomas Tilley, Towards an FCA based tool for visualizing formal specifications, ICCS 2003, The 11 th International Conference on Conceptual Structures, July 2003, Dresden [7] Gotel, O., Finkelstein, A., An Analysis of the Requirements Traceability Problem, Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101 [8] Antoniol, G., Canfora, G., De Lucia, A., Casazza, G. Information Retrieval Models for Recovering Traceability Links between Code and Documentation Proceedings of the International Conference on Software Maintenance, 2000. [9] Antoniol, G., Caprile, B., Potrich, A., Tonella, P.,Design-Code Traceability Recovery: Selecting the Basic Linkage Properties, Science of Computer Programming, vol. 40, issue 2-3, pp. 213-234, July 2001. [10] Arlow, J., Emmerich, W., Quinn, J., Literate Modelling - Capturing Business Knowledge with the UML, UML'98: Beyond the Notation 1998. [11] Dohyung, K., "Java MPEG Player," Online at http://mirage.snu.ac.kr/dhkim/java/mpeg/. [12] Gotel O.C.Z., Finkelstein A.C.W., An Analysis of the Requirements Traceability Problem. 1st International Conference on Rqts. Eng., pp. 94-101, 1994. [13] Gotel, O. & Finkelstein, A. "Extended Requirements Traceability: results of an industrial case study" in Proc. 3rd International Symposium on Requirements Engineering RE97, (IEEE CS Press), 1997, 169-178. [14] Gruber, T. R. & Russell, D. M. Generative design rationale, Lawrence Erlbaum Associates, 1994. [15] Grünbacher P., Egyed A., Medvidovic N., Reconciling Software Requirements and Architectures: The CBSP Approach, In: Proceedings 5th IEEE International Symposium on Requirements Engineering (RE01), Toronto, Canada, 2001. [16] Murphy, G. C., Notkin, D. and Sullivan, K., Software Reflexion Models: Bridging the Gap Between Source and High-Level Models, In the Proceedings of the Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, October 1995, ACM, New York, NY, p. 18-28. [17] Pohl et al., Integrating Requirement and Architecture Information: A Scenario and Meta- Model Based Approach, REFSQ workshop 2001. [18] IEEE Recommended Practice for Software Requirements Specifications; IEEE Std 830-1998 (Revision of IEEE Std 830-1993)
Appendix Fig 5: ER diagram demonstrating Traceability of Functional Requirements in UML Diagrams used in Analysis and Design phase TABLE I Functional requirement traceability Functional Requirement ID Functional Requirement Description Use Case ID 3.2.4 A person can get membership of the library. 01 3.2.5 A member can get membership of the library, provided 02 3.2.5.1 the member is valid 05 3.2.5.2 the maximum issue limit of the member has not yet reached, 02 3.2.5.3 the book is valid, 06 3.2.5.4 The book is available for issue 02 3.2.5.4 the member status gets updated 02 3.2.5.5 book status gets updated 02 3.2.5.6 the transaction record gets updated. 07 3.2.6 A member can return a book, provided 08 3.2.6.1..
TABLE II Use Cases and their events of a library system Use Case ID Use Case Name ID Type Description Handled By Method ID 03 Issue Book 01 Basic The librarian enters the member ID. 01 03 Issue Book 02 Basic Member validation 01 03 Issue Book 03 Basic Checking is made if issue limit for the member has 03 exceeded. 03 Issue Book 04 Basic The librarian enters book id. 04 03 Issue Book 05 Basic Validation of the book takes place. 04 03 Issue Book 06 Basic Checking is made to see if the book is available. 05 03 Issue Book 07 Basic New transaction added to Library Transaction. 06 03 Issue Book 08 Basic Book is issued. 02 03 Issue Book 09 Basic Member status updated. 11 03 Issue Book 10 Basic Book status updated. 09 03 Issue Book 11 Alternate Member ID is not valid, system prompts to reenter 01 03 Issue Book 12 Alternate After three consecutive tries the use case ends. 01 03 Issue Book 13 Alternate The member ID is valid, but the member has exceeded his 03 quota. 03 Issue Book 14 Alternate A message appears on the GUI and the use case ends. 03 03 Issue Book 15 Alternate The book id is invalid, system prompts to reenter. 04 03 Issue Book 16 Alternate After three consecutive tries the use case ends. 04 03 Issue Book 17 Alternate The book id is valid, but the book is not available. 05 03 Issue Book 18 Alternate A message appears on the GUI and the use case ends. 05 TABLE III methods OF LIBRARY SYSTEM Method ID Method name Member of Class 01 getmemberdetails Member 02 bookissue Member 03 getmaxissuelimit Member 04 getbookdetails Book 05 getstockbalance Book 06 addtrans LibTrans 07 getmembertrans LibTrans 08 getstatus Book_details 09 setstatus Book_details 10 issue Book_details 11 reissue Book_details 12 setstatus Member TABLE IV classes of class diagrama library system Class Name Method ID Member 01 Member 02 Member 03 Member 12 Book 04 Book 05 Book_details 08 Book_details 09 Book_details 10 Book_details 11 LibTrans 06 LibTrans 07 TABLE V Messages of a sequence diagram of a library system Message ID From object of class To Object of class Method Id 01 Actor InterfaceClass 0 02 InterfaceClass Member 01 03 InterfaceClass InterfaceClass 01 04 InterfaceClass Actor 0 05 InterfaceClass InterfaceClass 02 06 InterfaceClass Actor 0 07 Actor InterfaceClass 0 08 InterFaceClass Book 04 09 InterfaceClass InterfaceClass 05 10 InterfaceClass LibTrans 06 11 InterfaceClass Book 10 12 InterfaceClass Member 02 13 InterfaceClass Actor 0 14 InterfaceClass Book 09