Possible Improvements in UML Behavior Diagrams

Fahad Alhumaidan College of Computer Sciences and IT

King Faisal University Hofuf, Saudi Arabia

e-mail: falhumaidan@kfu.edu.sa

Nazir Ahmad Zafar College of Computer Sciences and IT

King Faisal University Hofuf, Saudi Arabia

e-mail: nazafar@kfu.edu.sa

Abstract—Although, Unified Modeling Language (UML) has become a de-facto standard for design and specification of object oriented systems but its structures being semi-formal in nature have various disadvantages. The UML diagrams lack with defining semantics of the functionality of a system to be developed. Automata theory and formal methods are proved powerful at requirement specification, modeling, design and test case generation. To address and realize the benefits of liking UML, automata and formal methods, our project on “formalization of UML diagrams” is in progress. This paper is continuation of the same project in which behavior diagrams namely use case, activity and state diagrams are selected for critical analysis and possible improvements. Advantages, disadvantages and limitations of the diagrams are addressed. Finally, a treatment is suggested to link UML diagrams with nondeterministic and parallel finite automata to enhance modeling power of UML for facilitating the software development procedures.

Keywords-UML, Use cases, Activity diagram, State diagram, Automata.

I. INTRODUCTION The emergence of Unified Modeling Language (UML)

has raised some interesting issues because it has incorporated a number of techniques into a single modeling language. Because of the obvious benefits of UML modeling techniques, it plays an important role in design and specification of software systems. However, some weaknesses and limitations existing in UML notations have invited software engineers to find other suitable software tools and techniques considering compatibility and integration issues with UML models for the complete and consistent, design, development and modeling of complex software systems. UML has a standard set of notations for visualizing and constructing artifacts of software systems as well as for business modeling and other non-software systems [1]. UML has become a de-facto standard for design and development of object oriented systems despite the fact that its semantics is semi-formal which allows ambiguities in design of a system [2]. Few major issues in modeling using UML, being hybrid and visual language in nature, diagrams are listed below:

• Most of the UML structures are based on graphical notations and hence are prone to causing errors.

• The hidden semantic, under the UML diagrams, allows ambiguities at design level.

• The same system can be described by multiple UML notations producing an inconsistent or ambiguous model.

• A model described by UML diagrams may have multiple interpretations and recipients of the design may not be able to understand what has been put in the diagrams.

The UML structures are based on graphical notations having informal or semi-formal definitions which are prone to cause errors [3]. Modeling power of UML can be enhanced by defining semantic rules and axioms in a formal way for the diagrams used in design of system. There is a need to link and formalize UML diagrams to other useful approaches to get full benefit at design level capturing complete functionality of a system to be developed which is one of the objectives of this research. This work is part of our ongoing project on integration of UML and formal approaches [4]. The integration of formal notations and UML diagrams will result an approach for complete, consistent and correct modeling of complex software system. It is noted that formal methods are proved to be effective at all phases of software development particularly at requirements analysis, specification, modelling and design levels [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15].

To address and realize the benefits of liking UML, automata and formal methods, our project on “formalization of UML diagrams” is in progress. Some important and most relevant work on formalizing UML is presented in the next section. It is mentioned that in the existing work mostly it is focused on syntax of the diagrams. In this paper, in continuation to our previous work [16], three important diagrams namely use cases, activity and state diagrams are considered. An introduction to each diagram is presented. Then advantages and limitations of the diagrams in software engineering are discussed. The weaknesses of the diagrams are identified. Finally, a treatment is suggested to link UML with other appropriate approaches. The major objectives of this research are:

• Identifying weakness and limitations existing in UML and hidden semantics under the diagrams

• Listing benefits of automata theory, formal approaches for software engineering, particularly, at requirements analysis and design specification

• Proposing an integration of UML, automata and formal approaches to be useful in modeling of software systems

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.113

657

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.113

173

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.113

173

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.113

173

• Providing syntactic and semantics-based relationship between most commonly used UML diagrams, automata and formal notations

• Analyzing and proving correctness of the proposed theory and models of integration

• Finally, developing an approach to provide an automated computer tool support to transform UML models to automata and formal languages

Rest of the paper is organized as follows: In section 2, most relevant work is discussed. A critical analysis of the UML is provided in section 3. Benefits, weaknesses, limitations and proposed treatment of behavioral diagrams, use cases, activity and state diagrams is provided in section 4. Proposed theory is presented in section 5. Finally, conclusion and future work are discussed in section 6.

II. RELATED WORK Only closely related work is discussed in this section.

Although there exits a lot of work [17], [18], [19], [20] on integration of approaches but there does not exists much work on linking UML diagrams with formal approaches. In [21] authors have developed Alloy Constraint Analyzer tool supporting the description of a system whose state space involves relational structures. It is described a way of creating tables and SQL code for Z specifications according to UML diagrams in [22]. A case study is discussed by a formal verification method for Cooperative Composition Modeling Language (CCML) in [23]. In [24], semantic translation from statechart diagrams to Object-Z specifications is presented. Information is captured using sequence and use case diagrams as a functional model by taking a case study. In another work, a method for translating and verifying UML sequence diagrams to Petri nets for deadlock, safety and liveness properties by model checking is presented in [25]. An integration of B and UML is presented in [26]. It is investigated the reliability issues using fuzzy logic and petri-nets in [27]. The mathematical induction technique is used to prove correctness of recursive programs in [28]. Formalization of the UML is proposed by focusing on basic constructs of class structures by taking simple case studies in [29]. A tool is developed in [30] which takes UML class diagram in the form of petal files, ASCII format files generated by Rational Rose, and evaluates it automatically and produces a list of comments. Activity model is proposed by ontology based formal method in [31]. In [32], a mathematical extension to the Object Constraint Language (OCL) language is presented to manipulate some mathematical concepts including functions and relations in predicate logic. A comparison of UML, state-charts, Z notation, petri nets and fuzzy logic is presented by taking a simple case study on commerce system in [33]. Some other related work can be found in [34], [35], [36], [37], [38], [39], [40] and [41].

III. CRITICAL ANALYSIS OF UML We start an introduction and critical analysis of Unified

Modeling Language (UML) with the statement by Liu:

“UML is a kind of modeling language which is wall-defined, easily expressed, strong function and widely used. It includes new theory, new method and new technology of software engineering fields. It doesn’t only apply to object-oriented design and analysis, but also support the whole process of software development beginning with requirement analysis”.

This shows role of UML diagrams in software engineering particularly in design and analysis of object oriented systems. However, despite the benefits of UML, it has its limitations as well. In this section, an introduction and critical analysis to UML diagrams and notations is presented. Merits and demerits of UML diagrams are listed. The reasoning of linking UML with other similar approaches is provided.

UML is a semi-formal language in which each element of the language is strongly defined showing well defined-ness of the notations [42]. For example, we are confident when modeling a particular facet of a system in a sense that it will not mislead to an incorrect or inconsistent design. UML is a concise and easy to understand designing language [43]. The entire language is made up of simple and straightforward concepts and notations. It is comprehensive language and describes all important aspect of a system. UML has enough expressive power to handle massive and complex systems although it is not a formal language [44]. It is the result of best practices in modeling of complex systems using object-oriented concepts in software engineering and systems design and has proved to be a successful modeling language. UML has become a de facto standard for modeling of systems using object oriented technology [45]. It has various other benefits for modeling of complex systems.

Despite the above benefits, UML lacks with few important concepts and currently cannot be used for the complete and consistent design and specification of a system [46]. For example, UML lacks formal semantics in which meanings are hidden under the diagrams creating ambiguities at the design and implementations levels. That is why linkage and integration of UML with other appropriate approaches is required for true software engineering.

IV. POSSIBLE IMPROVEMENTS IN BEHAVIOR DIAGRAMS A critical analysis to UML diagrams considered for the

possible improvement is given in this section. For this purpose, first of all, an introduction to every diagram is provided. Then its benefits and limitations are provided. Finally improvements are suggested to enhance modeling capability by linking it with other approaches. UML behavior diagrams considered, in this paper, for the critical analysis and treatment are: (1) Use case diagram, (2) Activity Diagram and (3) State Diagram.

A. Use Case Diagram Use Case Diagrams (UCD) can be used to describe

abstract functionality rather than giving details of individual features of a system. The use case diagrams provide interactions between actors and system to achieve a certain goal. Human or external system both are assumed as actors in the definition of UCD. More precisely, an actor represents

658174174174

whoever, for example, person or machine needs to interact with the system. The actors in use case are not assumed as part of the system. The actors represent anything or anyone that interact with the system to provide data, receive data or both provide and receive the data to/from the system. Usually, use cases are used at a higher level in systems engineering as compared to their use in software engineering. The UCD are different from sequence diagrams because order of execution is not executed. A critical analysis along with possible improvements of using use cases in systems designing is presented below.

Benefits: There are various benefits of using UML use cases in system analysis and design, some are listed here. The role of use cases has obvious benefits and is observed at the analysis phase of modeling and designing. As complexity is one of the major issues in systems analysis and design and use cases help managing complexity of systems. This is because it is emphasized on specific usage by starting from a very simple viewpoint of a system by focusing on the users. The use cases provide a basic mechanism from requirements analysis to test case generation which is another important benefit of using use cases. Finally, use cases facilitate to designers to specify achieving the final goals in the system development.

Limitations: Although use cases have various benefits but still there are some disadvantages for modeling systems using use cases. One of the most important issues in using use cases is that motivations and experience of users are not considered in case of modeling using use cases. The usability and usefulness are important variables in software engineering which are not considered in modeling using use cases. There are no well-organized and systematic criteria to address the non-functional requirements of a system in use case diagram. On the other side, the non-functional requirements are important in quality issues and play a crucial role to the success of a software system. Use cases consider requirements separately and there is no procedure to define interaction between the requirements. Time is another issue for using use cases because preparation of the whole system requires much time using such diagrams however it depends on the size of the system. Finally use cases are considered very ambiguous which do not capture fully the system. As a consequence developing automated computer tools which can transform use cases to other diagrams, for example class and sequence diagrams, is a challenge in systems and software engineering.

Improvements: To capture the syntax and semantics of use case diagrams, it is suggested to transform the diagrams by semi-automated way. In this way, the actor-actor and actor-system and system-system relationships can be described to identify the statics and dynamics of the system. B. Activity Diagram

Activity diagram of Unified Modeling Language (UML) is an important one describing behavior of systems. Activity diagram is used to describe the business workflows and operational components in a system. The diagram makes it possible to present the multiple conditions and choices within a workflow in a simple and understandable way.

Activity diagrams are much easier to interpret even for less experienced users and analysts. The most important is that the activity diagrams enable analysts to reason about functionalities as well as implementation details of workflows of a system. It is noted that activity diagrams may not be used as an alternative of state diagram or sequence diagram. This is because activity diagrams do not give much detail about behavior or interaction of objects as we can observe in state diagram or sequence diagram. The most commonly used elements of an activity diagram are listed below with little description:

• Initial Node: indicates start of the workflow represented by a blackened circle. There might be more than initial nodes in an activity diagram.

• Control Flows: represent the direction of the workflow represented by arrows.

• Activities: indicate stages in the workflows and are represented by ovals.

• Decisions: indicate choices between multiple conditions of a workflow in the diagram which are represented by diamond. The decisions are useful for presenting workflows that may have more than one possible consequence.

• Guard Conditions: indicate a condition to proceed and may follow a decision and are represented by brackets.

• Forks: indicates two or more possible conditions that may occur in the same process.

• End Nodes: indicate an end of the workflow represented by a blackened circle within a circle.

Benefits: Activity diagrams are much powerful because of its distinguished elements: guard conditions, forks, joins and decisions. Another useful aspect of activity diagrams is that it can be used to represent parallel activities and multiple conditions. The diagrams are easily understandable and interpretable for analysts and stakeholders which is another benefit for modeling of systems using activity diagrams.

Limitations: The activity diagrams are much easier and may advance the analysts to a detailed description because of their over complexity and user-friendly nature. Activity diagrams are easier to get hang of because of their simple representation. The activity diagrams have various elements to represent all possible scenarios of a system but, on the other hand, do not have much mathematical foundation to represent pre/post conditions and data constraints to be useful in validation and verification of the procedures.

Treatment: The activity diagram can be represented in terms of a graph tree. One of the good solutions is to use activity diagrams in an intelligent ways, that is, define the structure of a workflow not attempting many levels of the graph tree. In this way, the analyst may present a separate diagram for every workflow. The other possible effective way of improvement is to transform the activity diagram to finite automata. As the activity diagrams support parallelism therefore parallel finite automata is a best option to transform activity diagram into finite automata. The parallel finite automata have seven components: (N, Q, , γ, δ, q0, F). First one component N is a finite set of nodes. The second one Q

659175175175

is a finite set of states. The third one is a finite set of alphabets. The fourth one γ is a node transition function which takes a finite set of states and an alphabet as input and produces finite set of set of states. The fifth component δ is a state transition function which takes a state and an alphabet as input and produces finite set of states as an output. The sixth variable q0 represents initial state and the last one variable F represents set of final states.

C. State Diagram UML state machine is a variant of Harel statechart [16]

extended and adapted by UML. The goal of UML state machine is to overcome existing limitations of traditional finite-state machines. UML state machine introduces additional concepts, for example, nested states, orthogonal and regions. The diagram supports actions on both the state and triggering an event in the system. There are two main types of UML state machine: behavioral and protocol state machines. Behavioral state machines are used to model behavior aspects of class instances while protocol state machines are used to describe the legal scenarios.

A state in UML state diagram is used to capture various aspect of a system efficiently. The term event refers to something that occurs rather than to represent an instance of the occurrence. An event may have various associated parameters having information related to occurrence of the event. An event once generated may convey its occurrence to any number of states through a processing life cycle.

Benefits: The use of UML state machine is important in event driven programming because event handling is made possible explicitly depending both on the event-type and state of a system. Another important benefit of using state machine is that it may reduce number of possible scenarios if used intelligently and it simplifies the testing conditions between different modes of implementation supporting effective validation and verification mechanism [47].

Weaknesses: Although UML state diagrams are useful for representing behavior of systems but they have certain limitations as well. For example, the state diagram shows behavior of single object and not effective in representing behavior of several objects. Further, there do not exist computer tools for transforming state diagram to next phases of design and development. Sequence and activity diagrams might be used as alternatives of state diagrams. Nested states make the state diagram very complex due to recursion increasing complexity of the system.

Treatment: State diagram consists of set of total states, initial state, final states, set of alphabets and transition function. The transition function is used to move from one state to another by application of possible operators. The finite automate has capability to describe all of this information showing a strong relationship between UML state diagram and finite automata. We propose an integration of state diagram and finite automata because automata have various tools which will provide a solid background representing behavior of systems which can be verified by computer tools existing in automata theory. It is mentioned that the resultant automata will be nondeterministic because

it will not be possible to define transition from every state for every alphabet.

V. PROPOSED THEORY Requirement analysis and design specification have

become important issues in software engineering. For a moment, there does not exist any real approach which can be used for complete design and specification of a complex system. That is why integration of approaches has become a well-researched area. Further, it needs an integrated tool support for the complete and consistent development of software systems. UML has become a de facto standard for design and specification of object oriented systems. UML has some disadvantages and limitations, as discussed before, therefore, it needs to define a relationship between UML diagrams and other similar techniques to complement each other for the same purpose. UML behavior diagrams such as use cases, activity and state diagrams play an important role in capturing behavior of complex systems. These diagrams are selected here for the critical analysis and possible treatment.

The syntactic and semantics issues of the diagrams are identified and analyzed. An approach is proposed to link UML behavior diagrams and finite automata to be useful for correct and complete modeling of systems. The overall process of linking UML behavior diagrams embedded with finite automata is presented proposing new approach capturing syntax and hidden semantics of the diagrams as shown in Figure 1. The activity diagrams will be linked with the parallel finite automata. The relationship between parallel finite automata and activity diagrams is already presented above. The state diagrams and nondeterministic finite automata will be linked to address limitations of state diagrams. It is important to mention that the proposed theory will be developed later on. Then it will be applied to some real World problems after integration proving usefulness and effectiveness of the approach.

Figure 1. Proposed treatment of behavior diagrams.

660176176176

VI. CONCLUSION AND FUTURE WORK In this paper, a critical analysis of Unified Modeling

Language (UML) behavior diagrams is provided along with the possible improvements. Although UML is being used at initial phases of software development successfully because of having a sufficient support of diagrams and notations but has not sufficient power for the complete modeling of complex software systems. Based on our experience applying UML in various projects, some weaknesses in the diagrams are identified. It is observed that UML structures are prone to causing errors because of graphical notations. The hidden semantics under the diagrams allow ambiguities at design level and multiple notations produce inconsistent and ambiguous models. Further, the models described using UML diagrams may have multiple interpretations and the recipients of the design may not be able to understand what has been put in the diagrams.

There exist some well-established approaches, for example, automata theory, formal methods, which can capture the semantics hidden under the UML diagrams. Automata theory has proved useful in capturing static as well as dynamic behavior of systems. Formal methods are useful at all stages of software development because of having rigorous mathematical and computer tools support. In this way, UML, automata and formal methods will be useful for design and specification of software systems as suggested in the proposed theory. Therefore an integration of these approaches will facilitate the software development process. A comprehensive survey of relevant work [48], [49] was presented as starting point for this research.

REFERENCES

[1] K. E. Hamdy, M. A. Elsoud and A. M. El-Halawany, “UML-based Web Engineering Framework for Modeling Web Application,” Journal of Software Engineering, 5, pp. 49-63, 2011.

[2] X. He, “Formalizing UML Class Diagrams: A Hierarchical Predicate Transition Net Approach,” Proceedings of Twenty-Fourth Annual International Computer Software and Applications Conference, Taipei, Taiwan, pp. 217-222, 2000.

[3] A. M. Mostafa, A. I. Manal, E. B. Hatem and E. M. Saad, “Toward a Formalization of UML2.0 Meta-model using Z Specifications,” Proceedings of 8th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/ Distributed Computing, Qingdao, 3, pp. 694-701, 2007.

[4] N. A. Zafar and F. Alhumaidan, “Transformation of Class Diagrams into Formal Specification,” International Journal Computer Science and Network Security, 11, pp. 289-95, 2011.

[5] F. Sohail, F. Zubairi, N. Sabir, N. A. Zafar, “Designing Verifiable and Reusable Data Access Layer Using Formal Methods and Design Patterns, International Conference on Computer Modeling and Simulation, 2009.

[6] N. A. Zafar and F. Alhumaidan, “Scenarios Verification in Sequence Diagram,” Journal of American Science, Vol. 9, No. 11, pp. 287-93, 2013.

[7] N. A. Zafar, F. Alhumaidan, “Transformation of Class Diagrams into Formal Specification,” International Journal Computer Science and Network Security, 11, pp. 289-95, 2011.

[8] N. A. Zafar, “Model Analysis of Equivalence Classes in UML Events Relations,” Journal of Software Engineering and Applications, Vol. 6, No. 12, pp. 653-661, 2013.

[9] N. A. Zafar, “Modeling and Formal Specification of Automated Train Control System using Z Notation,” IEEE Multi-topic Conference (INMIC'06), pp. 438-43, 2006.

[10] N. A. Zafar, S. A. Khan and K. Araki, “Towards Safety Properties of Moving Block Railway Interlocking System,” Int'l Journal of Innovative Computing, Information & Control, 2012.

[11] S. A. Khan, N. A. Zafar, F. Ahmad and S. Islam, “Extending Petri Net to Reduce Control Strategies of Railway Interlocking System,” Applied Mathematical Modelling, Elsevier, Vol. 38, No. 2, pp. 413-24, 2014.

[12] N. A. Zafar and F. Alsaade, “Syntax-Tree Regular Expression Based DFA Formal Construction,” Intelligent Information Management (IIM), Vol. 4, No. 4, pp. 138-46, 2012.

[13] N. A. Zafar, “Formal Partitioning Analysis and Verification of Extended Algebraic Automata,” African Journal of Mathematics and Computer Science Research, Vol. 4, No. 12, pp. 368-74, 2011.

[14] N. A. Zafar, A. Hussain and A. Ali, “Verifying Monoid and Group Morphisms over Strongly Connected Algebraic Automata,” Journal of Software Engineering and Applications, Vol. 3, No. 8, pp. 803-12, 2010.

[15] N. A. Zafar, A. Hussain and A. Ali, “A Refinement: Integration of Algebraic Automata and Z Conforming Some Important Structures,” Proceedings of International Multi-Conference of Engineers and Computer Scientists (IMECS), Vol. 1, pp. 483-88, Hong Kong, 2009.

[16] F. Alhumaidan, “A Critical Analysis and Treatment of Important UML Diagrams Enhancing Modeling Power,” Intelligent Information Management, Vol. 4, No. 5, pp. 231-237, 2012.

[17] B. Akbarpour, S. Tahar and A. Dekdouk, “Formalization of Cadence SPW Fixed-Point Arithmetic in HOL,” Formal Methods in System Design, 27, pp. 173-200, 2005.

[18] M. Brendan and J. S. Dong, “Blending Object-Z and Timed CSP: An Introduction to TCOZ,” Proceedings of International Conference on Software Engineering, Kyoto, Japan, pp. 95-104, 1998.

[19] F. Gervais, M. Frappier and R. Laleau, “Synthesizing B Specifications from EB3 Attribute Definitions,” Proceedings of 5th International Conference on Integrated Formal Methods, Springer Berlin/Heidelberg, 3771, pp. 207-26, 2005.

[20] O. Hasan and S. Tahar, “Verification of Probabilistic Properties in the HOL Theorem Prover,” Proceedings of the Integrated Formal Methods, Oxford, UK, 4591, pp. 333-352, 2007.

[21] D. Jackson, I. Schechter and I. Shlyakhter, “Alcoa: The Alloy Constraint Analyzer,” Proceedings of International Conference on Software Engineering, Limerick, Ireland, pp. 730–733, 2000.

[22] A. Moeini and R. O. Mesbah, “Specification and Development of Database Applications based on Z and SQL,” Proceedings of 2009 International Conference on Information Management and Engineering, Kuala Lumpur, pp. 399-405, 2009.

[23] Z. Xiuguo and H. Liu, “Formal Verification for CCML Based Web Service Composition,” Information Technology Journal, 10, pp. 1692-1700, 2011.

[24] S. -K. Kim and D. Carrington, “An Integrated Framework with UML and Object-Z for Developing a Precise and Understandable Specification: The Light Control Case Study,” Proceedings 7th Asia-Pacific Software Engineering Conference (APSEC), pp. 240–248, 2000.

[25] E. Cunha, M. Custodio, H. Rocha and R. Barreto, “Formal Verification of UML Sequence Diagrams in the Embedded Systems Context,” Brazilian Symposium on Computing System Engineering (SBESC), pp. 39–45, 2011.

[26] H. Leading and J. Souquieres, “Integration of UML and B Specification Techniques: Systematic Transformation from OCL Expressions into B,” Proceedings of 9th Asia-Pacific Software Engineering Conference, Gold Coast, Australia, pp. 495, 2002.

[27] Z. Shi, “Intelligent Target Fusion Recognition Based on Fuzzy Petri Nets,” Information Technology Journal, 11, pp. 500-503, 2012.

661177177177

[28] C. Yong, “Application of Wu’s Method to Proving Total Correctness of Recursive Program,” Information Technology Journal, 9, pp. 1431-1439, 2010.

[29] Z. M. Ma, “Fuzzy Conceptual Information Modeling in UML Data Model,” International Symposium on Computer Science and Computational Technology, Shanghai, China, pp. 331-334, 2008.

[30] N. H. Ali, Z. Shukur and S. Idris, “A Design of an Assessment System for UML Class Diagram,” International Conference on Computational Science and Applications, pp. 539–46, 2007.

[31] W. Zhixue, H. He, L. Chen and Y. Zhang, Ontology Based Semantics Checking for UML Activity Model,” Information Technology Journal, 11, pp. 301-306, 2012.

[32] M. T. Bhiri, K. Mourad, M. Graiet, P. Aniorte, “UML/OCL and Refinement,” 18th IEEE International Conference and Workshops on Engineering of Computer-Based Systems, pp.14-158, 2011.

[33] S. A. Ehikioya and B. Ola, “A Comparison of Formalisms for Electronic Commerce Systems,” Proceedings of International Conference on Computational Cybernetics, Vienna, pp. 253–258, 2004.

[34] K. Araki, A. Galloway and K. Taguchi, “Using Process Algebra to Control B Operations,” Proceedings of 1st International Conference on Integrated Formal Methods, Springer Verlag London, UK, pp. 437-456, 1999.

[35] W. S. Changchien, J. J. Shen and T. Y. Lin, “A Preliminary Correctness Evaluation Model of Object-Oriented Software Based on UML,” Journal of Applied Sciences, 2, pp. 356-365, 2002.

[36] Z. Derakhshandeh, B. T. Ladani and N. Nematbakhsh, “Modeling and Combining Access Control Policies Using Constrained Policy Graph (CPG),” Journal of Applied Sciences, 8, pp. 3561-3571, 2008.

[37] A. Hall, “Correctness by Construction: Integrating Formality into a Commercial Development Process,” Proceedings of International Symposium of Formal Methods Europe, Denmark, LNCS, 2391, pp. 139–157, 2002.

[38] Liu and C. Chen, “An Improved Quasi-Static Scheduling Algorithm for Mixed Data-Control Embedded Software,” Journal of Applied Sciences, 6, pp. 1571-1575, 2006.

[39] J. M. Spivey, “The Z Notation: A Reference Manual,” Englewood Cliffs NJ, Prentice-Hall, ISBN: 013983768X, 1989.

[40] J. M. Wing, “A Specifier, Introduction to Formal Methods,” Computer Journal, 23, pp. 8-24, 1990.

[41] S. Zarina, N. Alias, M. M. Halip and B. Idrus, “Formal Specification and Validation of Selective Acknowledgement Protocol using Z/EVES Theorem Prover,” Journal of Applied Sciences, 6, pp. 1712-1719, 2006.

[42] R. Borges and A. Mota, “Integrating UML and Formal Methods,” Electronic Notes in Theoretical Computer Science, 184, pp. 97-112, 2003.

[43] H. Podeswa, “UML for IT Business Analyst,” 2nd Edn., Course Technology, ISBN: 1598638688, Pages: 372, 2009.

[44] A. Dennis, B. H. Wixom and D. Tegarden, “Systems Analysis and Design with UML,” 3rd Edn., Wiley, ISBN: 047172257X, Pages: 576, 2005.

[45] R. Miles and K. Hamilton, “Learning UML 2.0,” First Edition, O'Reilly Media, ISBN: 0596009828, Pages: 288, 2006.

[46] W. Liu and W. Dui, “The Application of UML in the Business System Modeling,” Application Research of Computers Journal, 2002.

[47] M. Bo, W. Huang and J. Qin, “Automatic Verification of Security Properties of Remote Internet Voting Protocol in Symbolic Model,” Information Technology Journal, 9, pp. 1521-1556, 2010.

[48] S. Sengupta and S. Bhattacharya, “Formalization of UML Diagrams and Consistency Verification: A Z Notation Based Approach,” Proceedings of India Software Engineering Conference, pp. 151-152, 2008.

[49] X. Than, H. Miao and L. Liu, “Formalizing Semantics of UML Statecharts with Z,” Proceedings of 4th International Conference on

Computer & Information Technology, Wuhan, China, pp. 1116-21, 2004.

662178178178