- Email: [email protected]
Documenting electronic commerce systems and software using the unified modeling language
Information and Software Technology 44 (2002) 303±311
www.elsevier.com/locate/infsof
Documenting electronic commerce systems and software using the uni®ed modeling language Kassem Saleh* Department of Computer Science and Mathematics, American University of Sharjah, P.O. Box 26666 Sharjah, United Arab Emirates
Abstract Electronic commerce (EC) systems are complex systems consisting of cooperating heterogeneous software, hardware and database subsystems that are distributed among processing nodes [1]. They are reactive, real-time and concurrent distributed systems. They are ®nancially critical systems since they perform distributed business functions, the success of which is very critical for the business operation. The use of well-de®ned speci®cation and documentation techniques is very essential for the effective development and maintenance of these systems. In this paper, we propose the use of the uni®ed modeling language (UML) [2] as a technique for documenting and specifying EC systems at various levels of abstractions and from different views. We believe that the use of UML ensures a better reliability and reusability of these systems. q 2002 Elsevier Science B.V. All rights reserved. Keywords: Electronic commerce; Speci®cation and documentation; Uni®ed modeling language
1. Introduction Electronic commerce (EC) systems are complex systems consisting of cooperating heterogeneous software, hardware and database subsystems that are distributed among processing nodes [1]. They are reactive, real-time and concurrent distributed systems. They are ®nancially critical systems since they perform distributed business functions, the success of which is very critical for the business operation. EC can be de®ned as ªthe exchange of value (i.e. goods for money) between two parties (i.e. consumer and merchant) via electronic means (i.e. the internet)º. A more technical de®nition states that `EC involves the orderly exchange of secure messages between various distributed processing entities for the purpose of successfully completing a business transaction'. EC involves the execution of commerce-related activities and functions using predominantly internet-based electronic means. EC is a by-product of the technological advances in the areas of computing and communications. The speed, ef®ciency and security in processing and communicating information over the internet play important roles in the acceptance of EC by the general public. In this paper, we show the use of the uni®ed modeling language (UML) [2], an emerging de-facto software industry standard, for the documentation of various aspects and * Tel.: 1971-6-505-5555; fax: 1971-6-505-5950. E-mail address: [email protected] (K. Saleh).
views of EC systems. In addition to enhancing the quality, UML-based documentation and software development processes can be used to reduce the time to deliver and maintain communications software. Moreover, we outline how the UML can be used to describe the different behavioral, structural and architectural aspects and views of EC systems. The rest of the paper is organized as follows. Section 2 provides some preliminary background on EC systems and the UML. Section 3 discusses the use of the UML in modeling and documenting EC software and business models. In Section 4, we present part of an EC business model and its speci®cation in UML. Finally, we summarize and conclude the paper in Section 5. 2. Preliminaries In this section, we provide some preliminary background on the two main constituents of the work reported in this paper. First, we give a brief overview of EC systems, its components, and its business models. Then, we present a brief and general overview of the UML. 2.1. Overview of electronic commerce systems An EC system consists of components that are distributed and cooperating across a private or public network in order to provide a speci®ed set of business functions and services to various stakeholders. Reliability and availability of these
0950-5849/02/$ - see front matter q 2002 Elsevier Science B.V. All rights reserved. PII: S 0950-584 9(01)00213-0
304
K. Saleh / Information and Software Technology 44 (2002) 303±311
systems are essential features of such systems to ensure a greater usability. These components of EC systems include software, hardware, databases, people, procedures and standards. In this paper, we concentrate on the software components of EC systems. EC software ranges from online, web-based and distributed software to of¯ine software applications and packages that are necessary to provide the various EC services and functions. These may include software for: cataloguing and content development for informing consumers about products, pricing based on various business conditions, marketing for attracting consumers to the electronic marketplace, searching and browsing to ensure easy accessibility to products, negotiating personalized and customized deals, ordering using shopping carts, paying using secure payment protocols and servers, and product support services using expert online interaction with consumers. Furthermore, EC software systems possess several features that make them complex, such as the concurrency and non-determinism due to the unpredictability of usage and network traf®c conditions, the existence of a multitude of subsystem interfaces with hardware and databases, the existence of multi-platform, multi-vendor hardware and networking devices, and the interfacing with multi-lingual and multi-version software and database management systems. EC services are ®nancially critical since they involve ®nancial decision-making in pricing, security concerns in ordering and payment, and electronic market competition in negotiating. When providing these services, usability, scalability and availability are of utmost importance for the economic feasibility of the EC venture. Moreover, these services must deliver the promises of the electronic marketplace of being global and available: anywhere and anytime, easily searchable, virtual, highly interactive and usable, customizable and personalizable. These features can be achieved by guaranteeing some basic operational requirements, such as (a) high availability involving robustness, reliability and scalability issues, (b) high responsiveness involving performance, real-timeliness and quality of service issues, and (c) high security and data integrity involving traceability and auditability issues. In addition, EC software must be of high quality ensuring high testability, reusability and quick deployment, since time-to-market is an important factor for competing globally and succeeding. An EC business model determines the business rules for performing the various electronic business functions mentioned earlier. A complete model speci®es the rules for negotiating, ordering, paying, delivering and supporting the purchased products. Various internet-based business models can be clearly identi®ed such as the broker model, the assembly model, the factory outlet model, the store front model, the auction model and the commission model [3]. Moreover, business models may involve business-to-business and/or consumer-to-business, and/or consumer-toconsumer business interactions. A standard and formal technique for describing and
documenting EC business models is highly desirable for all stakeholders, including businesses, EC systems developers and consumers/users. A generic and uni®ed technique considering the requirements of the various viewers and stakeholders of the system would be an attractive candidate. For more information on EC from a technology point of view, the reader can refer to [4]. 2.2. Overview of the UML The UML is a de-facto software industry standard modeling language for visualizing, specifying, constructing, and documenting the elements of systems in general, and software systems in particular [2]. UML has a well-de®ned syntax and semantics. It provides a rich set of graphical artifacts to help in the elicitation and top±down re®nement of object-oriented software systems from requirements capture to the deployment of software components. In UML, systems can be understood by addressing three of their aspects, namely, the behavioral, structural and architectural aspects. Each aspect is concerned with some of the views and viewers of the system. Behavioral aspects involve the functionalities provided by the system and their associated interactions, timings and their orderings. Structural aspects involve the class structures of the object-oriented system, their interrelationships, and their packaging. Finally, architectural aspects are related to the deployment and distribution of the software across the various distributed system components. In UML, a system is described using different levels of abstraction and considering various views. Each view represents a projection onto the complete system description. A view is described using a number of diagrams containing information emphasizing a particular aspect of the system. The Use Case view considers the behavioral aspects of the system. Primarily, it re¯ects the user's concerns and requirements. The static aspects are shown using use case diagrams. However, the dynamic aspects are shown using system-level sequence, statechart, interaction and activity diagrams by considering the system as a black-box. Usually, users, testers and analysts are interested in this view. The Design and Process Views are the concern of the development team including the analysts, designers and implementers. They describe the structural aspects of the system. The software structure is described statically by class and object diagrams, and dynamically by detailed low-level sequence, statechart, interaction and activity diagrams. The Design View is concerned with objects, classes and collaborations, while the Process View is concerned with software architecture issues such as concurrency, multi-threading, synchronization, performance and scalability issues. The Implementation View describes the ®les and components needed to assemble and release the system. Component diagrams are used to provide this view. Finally, the Deployment View describes the ways to distribute, deliver
K. Saleh / Information and Software Technology 44 (2002) 303±311 Table 1 Aspects, views and supporting diagrams in UML Views Behavioral aspects Use Case
Structural aspects Design
Process
Static
Dynamic
5.
Use Case diagrams
Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams
6.
Class diagrams; Object diagrams
Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams
7.
Class diagrams; Object diagrams
Architectural aspects Implementation Component diagrams Deployment Deployment diagrams
and install the system components and ®les across the distributed nodes of the system. A diagram contains model elements such as classes, objects, nodes, components, and relationships, described by graphical symbols. Moreover, a diagram can be used to describe certain system aspects at different levels of abstraction. For example, a state diagram can describe system-level input/output interactions, and can also be used to show state changes of a particular system object across multiple use cases. The nine diagrams in the UML are described brie¯y. 1. Use Case Diagram: This diagram describes the functions of a system and its users. It shows a number of external actors and their connection to the use cases representing the services provided by the system. Uses cases can be inherited by another use case, allowing reusability of use cases. Also, a use cases can `use' another use case, allowing the modularization of use cases, and a use case `extends' another use case to deal with certain exceptional or abnormal conditions or situations. 2. Class Diagram: This diagram shows the static structure of classes and their possible relationships (i.e. association, inheritance, aggregation and dependency) in the system. 3. Object Diagram: This diagram is a variant of a class diagram and uses almost identical notation. An object diagram can be an example of a class diagram that shows possible instantiations of classes during system execution. 4. Statechart Diagram: This diagram describes the possible behavior of an object using state changes. It can also be
8.
9.
305
used as a system-level diagram showing system state changes during the operation of the system. Sequence Diagram: This diagram shows the interactions between a number of objects and their time ordering. In other words, this diagram describes a scenario involving various interacting objects. Collaboration Diagram: This diagram shows the objects and the messages they exchange. Messages are numbered to provide a time ordering of the message. Therefore, we can easily produce a sequence diagram from this diagram and vice-versa. Both sequence and collaboration diagrams are also referred to as interaction diagrams. Activity Diagram: This diagram shows a sequential or concurrent ¯ow from activity to another activity. An activity diagram consists of action states, activity states and transitions between them, and usually spans more than one use case (or functionality). This diagram uses symbols from Petri Nets, ¯owcharts and ®nite state machines. Component Diagram: This diagram shows the physical structure of the code in terms of code component. A component can be a source code, a binary, or executable component. A component contains information about the logical class or classes it implements, thus creating a mapping from the Design View to the Component View. Deployment Diagram: This diagram shows the physical architecture and distribution of the hardware and software components in the system.
Table 1 summarizes the aspects, views and their supporting diagrams in UML. For a complete tutorial on UML, the reader can refer to [2]. 3. Electronic commerce systems and the UML UML has been used for modeling various software systems. In general, any object-oriented distributed software applications can be rigorously described using the UML. In an earlier work, we have used UML to describe communications protocols and their corresponding services [5]. UML allows us to describe and understand systems at different levels of abstractions and using different views and graphical artifacts. Consequently, it is a very natural and intuitive technique for modeling EC systems. Depending on the interested viewer, the UML provides speci®c modeling tools to document and understand the system. In this section, we ®rst document the logic of the business model using UML. Then, we document its supporting software system in terms of business objects, classes, packages and components. 3.1. Documenting the business model: the use case view The EC business model describes, at a higher level of abstraction, the various interactions between the EC system and its users, i.e. actors. A use case view of the system provides the users viewpoint of the system: the functionality
306
K. Saleh / Information and Software Technology 44 (2002) 303±311
of the system in terms of input and output behaviors. This view covers the behavioral aspects of the system. Use case analysis can be used to elicit and capture the business processes from a user's perspective. As a result of this analysis, use case diagrams are obtained. These diagrams are used as a requirement capture mechanism which have a direct relationship to the quality and coverage of generated test cases to test the implementation of the system [6]. The static elements of the behavior are described by use case diagrams. These diagrams will show all the actors involved with the system, the use cases representing the functionalities provided by the system, and the relationships between actors and use cases. To deal with the complexity of a large system, we can use more than one diagram and exploits of the `uses' and generalization relationships among use cases. These two relationships provide the modularity and reusability mechanisms, respectively, when dealing with use cases. The dynamic elements of the behavior can be described using interaction diagrams, statechart diagrams and activity diagrams. Interaction diagrams can be sequence diagrams or collaboration diagrams. Business-level sequence diagrams are very useful for describing the ordering and timing aspects of the system behavior. Collaboration diagrams show the collaborations between the various distributed actors in terms of message exchanges in order to complete a business function or enforce business logic. State diagrams can also be used to describe the input/output system-level functional behavior as observed across the various distributed points of interactions with system actors. High-level activity diagrams describe the ¯ow of control from activity to activity across various use cases and model the dynamic system behavior at a high-level of abstraction. The use of the UML diagrams for business modeling helps considerably in ensuring the completeness of the functional and behavioral aspects of an EC business system requirements, and provides a useful basis for generating functional, transaction-oriented and system-level blackbox-based test cases and for obtaining use case based metrics and estimations [6]. 3.2. Structural modeling: the design and process views The structural model is considered as a re®nement of the behavioral model of the business functionalities as elicited in the use case view using the use case diagrams, and system-level state, sequence, collaboration and activity diagrams. The structural model is elaborated using the design and process views. The static elements of the structural model are described using object and class diagrams. A class diagram shows all the classes included in the model, in addition to their relationships. Visualizing the aggregation, generalization, dependency and association relationships connecting classes helps considerably in understanding the classes and their structures, in addition to their degree of coupling,
traversal and reusability. Objects diagrams show how instances of the classes interact among each other's. The dynamic elements of the structural model are described using interaction diagrams, statechart diagrams and activity diagrams. Sequence diagrams show the sequencing of exchanged messages and inter-object messages among actors and objects. Objects with a signi®cant, state-oriented dynamic behavior are also modeled using statechart diagrams. Moreover, multi-threaded and concurrent behaviors of certain objects are captured intuitively in both activity and statechart diagrams. Collaboration diagrams are used to show the various ways objects and actors collaborate to provide the required business logic and functions. Messages in collaboration diagrams become operations embedded within some classes of the static elements of the structure. Activity diagrams normally show the behavior of actors and objects across several use cases. Both the design and process views use the same diagrams to describe the static and dynamic elements of the structural model. The only difference is that the process view increments the design view with semantical information dealing with real-time issues related to concurrency, multi-threading, synchronization and scalability. 3.3. Architectural modeling: the implementation and deployment views At the architectural level, the two views related to the implementation and the deployment of EC software components are provided. The implementation view is represented using component diagrams describing the organization of the EC software implementation components and their inter-dependencies. A component diagram contains a set of software model components, the model development time relationships between components, and the model calls relationships between components. The deployment view (also referred to as the environment view) is represented using deployment diagrams. These diagrams show the various processing nodes in the EC system according to its business model, and the distribution of software implementation components among these nodes. A deployment diagram consists of EC nodes and components (from the component diagram), the communications and run-time relationships between nodes, the calls and becomes relationships between components (the latter from the component diagram), and ®nally, the supports relationships between nodes and components. Table 2 summarizes the use of UML diagrams to support the various views, aspects, and software development processes. 4. Example In this section, we illustrate the use of the UML for the
K. Saleh / Information and Software Technology 44 (2002) 303±311
307
Table 2 Use of UML diagrams for EC software development Views
Diagrams
EC system software development
Behavioral aspects: Use Case View
Use Case diagrams; Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams Class diagrams; Object diagrams; Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams Component diagrams; Deployment diagrams
Business model documentation; Requirements capture and functional speci®cations
Structural aspects: Design and Process Views Architectural aspects: Implementation and Deployment Views
visual speci®cation and documentation of a subset of an EC business model, namely, the Store Front business model. First, we will informally describe the ordering and paying parts of the model. Then, we will show the behavioral aspects using the use case view and its related diagrams. We also show the structural aspects using the design and process views and their related diagrams. Finally, we present the architectural aspects using the implementation and deployment views and their related diagrams. 4.1. Informal description of the model This model subset deals with the ordering and paying parts of the EC store front business model. In this model, an online business is selling products made by various manufacturers. The products are physically located in the business warehouses. Consumers will be ®rst able to browse through the business catalog of products and ®ll a shopping cart with products to purchase as they go along. Then the consumer will proceed to checkout for payment. At this moment, the business will channel the request to a payment server, which will securely request the payment credit information from the consumer. The payment server will then con®rm with its supporting ®nancial institution (the bank) the validity of the payment. The bank will either send a transaction authorization code or decline the approval of the transaction. Once approved, the payment server will concurrently send the approval code to the business, and a
High-level and detailed design; Object-oriented analysis and design; Test suite development Con®guration management; Installation plan; Version control; Testing and test management
con®rmation of receipt to the consumer. (Notice here in this model, the business will never be aware of any personal credit information on the consumer). Once the business receives the transaction approval code, it launches the order ful®llment process, which includes sending a message to the warehouse with customer delivery information, which in turn sends a message to the shipping company. The shipping company will then communicate delivery information to the consumer. It is clear here that the use of English to describe this part of the process model is not adequate and can lead to some ambiguities. The use of a visual modeling techniques and tools such as the UML would de®nitely eliminate any misinterpretations of the business model. The proper development of the various UML diagrams drawn mostly from the vocabulary of the system and elicited by a thorough process involving many stakeholders at various stages of the development process reduce the risks of producing low quality, incomplete, ambiguous or non-deterministic software. 4.2. Behavioral aspects of the model This part of the business model can be described using the static and dynamic elements of the behavioral aspects of the use case views. In our example, the use case diagrams in Fig. 1 show the static elements including the various actors and the functionalities involved in the ordering and paying
Fig. 1. Use case diagram for the ordering and paying parts of the model.
308
K. Saleh / Information and Software Technology 44 (2002) 303±311
Fig. 2. Collaboration diagram for the ordering and paying parts of the model.
behaviors. However, the dynamic elements of the behavior are shown using the collaboration diagram in Fig. 2, the sequence diagram in Fig. 3 and the activity diagram in Fig. 4. Moreover, a high-level statechart diagram is shown in Fig. 5 to represent the states of the system during the different ordering and paying activities, and the transitions between them. Normally, as it is in this case, additional collaboration, sequence and activity diagrams are needed to show the complete possible interaction and activity scenarios. 4.3. Structural aspects of the model The static elements of the structural aspects of the model are shown using the partial class diagram in Fig. 6. For conciseness, we are omitting the details of the classes in terms of attributes and methods. The object/class model including both attributes and operations depends on the business model, in our case, the store front model. The required classes include bound-
ary classes representing the interfaces between actors identi®ed in the use case view and the system, entity classes representing those things in the system that must be persistent, in addition to application domain or control classes, such as the Transaction and Catalogue class, and low-level utility classes, such as the Timer and Authentication classes. The collaboration and sequence diagrams illustrating the dynamic elements of the structural aspects include, in addition to the objects shown in the same diagrams for the behavioral aspects (Figs. 2 and 3), objects corresponding to the additional classes identi®ed in the class diagram, such as, Order, Transaction, Timer, Product and Catalogue. For example, both the payment server and bank objects are going to start their timers to make sure that a certain time limit is not exceeded waiting for an approval. Also, once the business validates an order, it will create a transaction object to be handled by the payment server object. Fig. 7 shows these parts of the overall collaboration and sequence
Fig. 3. The sequence diagram for the ordering and paying parts of the model.
K. Saleh / Information and Software Technology 44 (2002) 303±311
309
Fig. 4. The Activity diagram for the paying parts of the model.
Fig. 5. State diagram for the ordering and paying parts of the model.
diagrams. Moreover, at this level, statechart diagrams can be used to describe the lifecycle of some objects in the static class model. For example, an order object can go through a ®nite number of states, from `open' to `closed', and ®nally, it is saved in a persistent store, either in a Transactions/Orders database or in a log ®le. In this paper, we are not including the complete diagrams. But it is important to mention here that UML diagrams allow the inclusion of many semantical details that are very helpful to move from the modeling phase to the implementation or coding phase of the software. In fact, code generation tools already exist to generate object-oriented code in C11 or Java starting from the various diagrams obtained in the modeling phase [7].
310
K. Saleh / Information and Software Technology 44 (2002) 303±311
Fig. 6. Class diagram for the ordering and payment parts of the model.
Fig. 7. Partial collaboration and sequence diagrams for the structural aspects of the model.
Fig. 8. Deployment diagrams.
K. Saleh / Information and Software Technology 44 (2002) 303±311
4.4. Architectural aspects of the model UML provides very little semantical links between the two diagrams supporting the architectural aspects from the implementation and Deployment viewpoints and the diagrams supporting the structural aspects. However, we believe that these two diagrams, namely the component and deployment diagrams, provide the necessary information to package the software and con®gure it properly across a distributed system such as an EC system. Fig. 8 shows a deployment diagrams which include components drawn in the component diagrams.
311
we intend to develop a semantic model checking technique which can detect semantic errors in the model that are not detected by the tool.
Acknowledgements The author would like to thank Professor Robert Probert from the University of Ottawa, and Professor Rachida Dssouli from Concordia University, for their constructive comments and remarks made on an earlier version of this work.
5. Summary and conclusion In this paper, we have used the UML for the formal visual speci®cation and documentation of EC systems and their business models. The various UML diagrams are appropriately used to describe the three model aspects: the behavioral, structural and architectural aspects. The bene®ts of using UML extend beyond being a documentation technique, to reach test case design, generation and coverage and model checking and reuse. We have illustrated the use of UML using a small subset of the store front business model currently a very popular model for online internet-based businesses. This part includes the ordering and paying parts of the business model. In the future, we intend to describe the complete store front business model, and we will elaborate further on the structural and architectural aspects of the model. We also plan to include within these two aspects CORBA-based design and implementation details. Finally,
References [1] K. Saleh, R. Probert, Issues in testing e-commerce systems, in: K. Dong (Ed.), Electronic Commerce Technology Trends: Challenges and Opportunities, IBM Press, IIR Publications Inc, California, USA, 2000, pp. 273±282 Chapter 17. [2] G. Booch, J. Rumbaugh, I. Jacobson, The Uni®ed Modeling Language User Guide, Addison Wesley, Reading, MA, 1999. [3] R. Dssouli, R. Probert, K. Saleh, F. Khendek, Electronic commerce testing. Tutorial Notes, IFIP 13th International Conference on Testing of Communicating Systems (TestCom 2000), Ottawa, Canada, August 2000. [4] G.W. Treese, L. Stewart, Designing Systems for Internet Commerce, Addison Wesley, Reading, MA, 1998. [5] K. Saleh, M. Jaragh, Speci®cation of communications protocols and services using UML, TENCON 2000, Malaysia, September 2000. [6] K. Saleh, R. Probert, W. Li, W. Fong, An approach to high-yield requirements speci®cations for e-commerce and its application, International Journal on Digital Libraries (2001). [7] W. Boggs, M. Boggs, Mastering UML with Rational Rose, Sybex Publisher, Sybex Inc, California, USA, 1999.
www.elsevier.com/locate/infsof
Documenting electronic commerce systems and software using the uni®ed modeling language Kassem Saleh* Department of Computer Science and Mathematics, American University of Sharjah, P.O. Box 26666 Sharjah, United Arab Emirates
Abstract Electronic commerce (EC) systems are complex systems consisting of cooperating heterogeneous software, hardware and database subsystems that are distributed among processing nodes [1]. They are reactive, real-time and concurrent distributed systems. They are ®nancially critical systems since they perform distributed business functions, the success of which is very critical for the business operation. The use of well-de®ned speci®cation and documentation techniques is very essential for the effective development and maintenance of these systems. In this paper, we propose the use of the uni®ed modeling language (UML) [2] as a technique for documenting and specifying EC systems at various levels of abstractions and from different views. We believe that the use of UML ensures a better reliability and reusability of these systems. q 2002 Elsevier Science B.V. All rights reserved. Keywords: Electronic commerce; Speci®cation and documentation; Uni®ed modeling language
1. Introduction Electronic commerce (EC) systems are complex systems consisting of cooperating heterogeneous software, hardware and database subsystems that are distributed among processing nodes [1]. They are reactive, real-time and concurrent distributed systems. They are ®nancially critical systems since they perform distributed business functions, the success of which is very critical for the business operation. EC can be de®ned as ªthe exchange of value (i.e. goods for money) between two parties (i.e. consumer and merchant) via electronic means (i.e. the internet)º. A more technical de®nition states that `EC involves the orderly exchange of secure messages between various distributed processing entities for the purpose of successfully completing a business transaction'. EC involves the execution of commerce-related activities and functions using predominantly internet-based electronic means. EC is a by-product of the technological advances in the areas of computing and communications. The speed, ef®ciency and security in processing and communicating information over the internet play important roles in the acceptance of EC by the general public. In this paper, we show the use of the uni®ed modeling language (UML) [2], an emerging de-facto software industry standard, for the documentation of various aspects and * Tel.: 1971-6-505-5555; fax: 1971-6-505-5950. E-mail address: [email protected] (K. Saleh).
views of EC systems. In addition to enhancing the quality, UML-based documentation and software development processes can be used to reduce the time to deliver and maintain communications software. Moreover, we outline how the UML can be used to describe the different behavioral, structural and architectural aspects and views of EC systems. The rest of the paper is organized as follows. Section 2 provides some preliminary background on EC systems and the UML. Section 3 discusses the use of the UML in modeling and documenting EC software and business models. In Section 4, we present part of an EC business model and its speci®cation in UML. Finally, we summarize and conclude the paper in Section 5. 2. Preliminaries In this section, we provide some preliminary background on the two main constituents of the work reported in this paper. First, we give a brief overview of EC systems, its components, and its business models. Then, we present a brief and general overview of the UML. 2.1. Overview of electronic commerce systems An EC system consists of components that are distributed and cooperating across a private or public network in order to provide a speci®ed set of business functions and services to various stakeholders. Reliability and availability of these
0950-5849/02/$ - see front matter q 2002 Elsevier Science B.V. All rights reserved. PII: S 0950-584 9(01)00213-0
304
K. Saleh / Information and Software Technology 44 (2002) 303±311
systems are essential features of such systems to ensure a greater usability. These components of EC systems include software, hardware, databases, people, procedures and standards. In this paper, we concentrate on the software components of EC systems. EC software ranges from online, web-based and distributed software to of¯ine software applications and packages that are necessary to provide the various EC services and functions. These may include software for: cataloguing and content development for informing consumers about products, pricing based on various business conditions, marketing for attracting consumers to the electronic marketplace, searching and browsing to ensure easy accessibility to products, negotiating personalized and customized deals, ordering using shopping carts, paying using secure payment protocols and servers, and product support services using expert online interaction with consumers. Furthermore, EC software systems possess several features that make them complex, such as the concurrency and non-determinism due to the unpredictability of usage and network traf®c conditions, the existence of a multitude of subsystem interfaces with hardware and databases, the existence of multi-platform, multi-vendor hardware and networking devices, and the interfacing with multi-lingual and multi-version software and database management systems. EC services are ®nancially critical since they involve ®nancial decision-making in pricing, security concerns in ordering and payment, and electronic market competition in negotiating. When providing these services, usability, scalability and availability are of utmost importance for the economic feasibility of the EC venture. Moreover, these services must deliver the promises of the electronic marketplace of being global and available: anywhere and anytime, easily searchable, virtual, highly interactive and usable, customizable and personalizable. These features can be achieved by guaranteeing some basic operational requirements, such as (a) high availability involving robustness, reliability and scalability issues, (b) high responsiveness involving performance, real-timeliness and quality of service issues, and (c) high security and data integrity involving traceability and auditability issues. In addition, EC software must be of high quality ensuring high testability, reusability and quick deployment, since time-to-market is an important factor for competing globally and succeeding. An EC business model determines the business rules for performing the various electronic business functions mentioned earlier. A complete model speci®es the rules for negotiating, ordering, paying, delivering and supporting the purchased products. Various internet-based business models can be clearly identi®ed such as the broker model, the assembly model, the factory outlet model, the store front model, the auction model and the commission model [3]. Moreover, business models may involve business-to-business and/or consumer-to-business, and/or consumer-toconsumer business interactions. A standard and formal technique for describing and
documenting EC business models is highly desirable for all stakeholders, including businesses, EC systems developers and consumers/users. A generic and uni®ed technique considering the requirements of the various viewers and stakeholders of the system would be an attractive candidate. For more information on EC from a technology point of view, the reader can refer to [4]. 2.2. Overview of the UML The UML is a de-facto software industry standard modeling language for visualizing, specifying, constructing, and documenting the elements of systems in general, and software systems in particular [2]. UML has a well-de®ned syntax and semantics. It provides a rich set of graphical artifacts to help in the elicitation and top±down re®nement of object-oriented software systems from requirements capture to the deployment of software components. In UML, systems can be understood by addressing three of their aspects, namely, the behavioral, structural and architectural aspects. Each aspect is concerned with some of the views and viewers of the system. Behavioral aspects involve the functionalities provided by the system and their associated interactions, timings and their orderings. Structural aspects involve the class structures of the object-oriented system, their interrelationships, and their packaging. Finally, architectural aspects are related to the deployment and distribution of the software across the various distributed system components. In UML, a system is described using different levels of abstraction and considering various views. Each view represents a projection onto the complete system description. A view is described using a number of diagrams containing information emphasizing a particular aspect of the system. The Use Case view considers the behavioral aspects of the system. Primarily, it re¯ects the user's concerns and requirements. The static aspects are shown using use case diagrams. However, the dynamic aspects are shown using system-level sequence, statechart, interaction and activity diagrams by considering the system as a black-box. Usually, users, testers and analysts are interested in this view. The Design and Process Views are the concern of the development team including the analysts, designers and implementers. They describe the structural aspects of the system. The software structure is described statically by class and object diagrams, and dynamically by detailed low-level sequence, statechart, interaction and activity diagrams. The Design View is concerned with objects, classes and collaborations, while the Process View is concerned with software architecture issues such as concurrency, multi-threading, synchronization, performance and scalability issues. The Implementation View describes the ®les and components needed to assemble and release the system. Component diagrams are used to provide this view. Finally, the Deployment View describes the ways to distribute, deliver
K. Saleh / Information and Software Technology 44 (2002) 303±311 Table 1 Aspects, views and supporting diagrams in UML Views Behavioral aspects Use Case
Structural aspects Design
Process
Static
Dynamic
5.
Use Case diagrams
Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams
6.
Class diagrams; Object diagrams
Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams
7.
Class diagrams; Object diagrams
Architectural aspects Implementation Component diagrams Deployment Deployment diagrams
and install the system components and ®les across the distributed nodes of the system. A diagram contains model elements such as classes, objects, nodes, components, and relationships, described by graphical symbols. Moreover, a diagram can be used to describe certain system aspects at different levels of abstraction. For example, a state diagram can describe system-level input/output interactions, and can also be used to show state changes of a particular system object across multiple use cases. The nine diagrams in the UML are described brie¯y. 1. Use Case Diagram: This diagram describes the functions of a system and its users. It shows a number of external actors and their connection to the use cases representing the services provided by the system. Uses cases can be inherited by another use case, allowing reusability of use cases. Also, a use cases can `use' another use case, allowing the modularization of use cases, and a use case `extends' another use case to deal with certain exceptional or abnormal conditions or situations. 2. Class Diagram: This diagram shows the static structure of classes and their possible relationships (i.e. association, inheritance, aggregation and dependency) in the system. 3. Object Diagram: This diagram is a variant of a class diagram and uses almost identical notation. An object diagram can be an example of a class diagram that shows possible instantiations of classes during system execution. 4. Statechart Diagram: This diagram describes the possible behavior of an object using state changes. It can also be
8.
9.
305
used as a system-level diagram showing system state changes during the operation of the system. Sequence Diagram: This diagram shows the interactions between a number of objects and their time ordering. In other words, this diagram describes a scenario involving various interacting objects. Collaboration Diagram: This diagram shows the objects and the messages they exchange. Messages are numbered to provide a time ordering of the message. Therefore, we can easily produce a sequence diagram from this diagram and vice-versa. Both sequence and collaboration diagrams are also referred to as interaction diagrams. Activity Diagram: This diagram shows a sequential or concurrent ¯ow from activity to another activity. An activity diagram consists of action states, activity states and transitions between them, and usually spans more than one use case (or functionality). This diagram uses symbols from Petri Nets, ¯owcharts and ®nite state machines. Component Diagram: This diagram shows the physical structure of the code in terms of code component. A component can be a source code, a binary, or executable component. A component contains information about the logical class or classes it implements, thus creating a mapping from the Design View to the Component View. Deployment Diagram: This diagram shows the physical architecture and distribution of the hardware and software components in the system.
Table 1 summarizes the aspects, views and their supporting diagrams in UML. For a complete tutorial on UML, the reader can refer to [2]. 3. Electronic commerce systems and the UML UML has been used for modeling various software systems. In general, any object-oriented distributed software applications can be rigorously described using the UML. In an earlier work, we have used UML to describe communications protocols and their corresponding services [5]. UML allows us to describe and understand systems at different levels of abstractions and using different views and graphical artifacts. Consequently, it is a very natural and intuitive technique for modeling EC systems. Depending on the interested viewer, the UML provides speci®c modeling tools to document and understand the system. In this section, we ®rst document the logic of the business model using UML. Then, we document its supporting software system in terms of business objects, classes, packages and components. 3.1. Documenting the business model: the use case view The EC business model describes, at a higher level of abstraction, the various interactions between the EC system and its users, i.e. actors. A use case view of the system provides the users viewpoint of the system: the functionality
306
K. Saleh / Information and Software Technology 44 (2002) 303±311
of the system in terms of input and output behaviors. This view covers the behavioral aspects of the system. Use case analysis can be used to elicit and capture the business processes from a user's perspective. As a result of this analysis, use case diagrams are obtained. These diagrams are used as a requirement capture mechanism which have a direct relationship to the quality and coverage of generated test cases to test the implementation of the system [6]. The static elements of the behavior are described by use case diagrams. These diagrams will show all the actors involved with the system, the use cases representing the functionalities provided by the system, and the relationships between actors and use cases. To deal with the complexity of a large system, we can use more than one diagram and exploits of the `uses' and generalization relationships among use cases. These two relationships provide the modularity and reusability mechanisms, respectively, when dealing with use cases. The dynamic elements of the behavior can be described using interaction diagrams, statechart diagrams and activity diagrams. Interaction diagrams can be sequence diagrams or collaboration diagrams. Business-level sequence diagrams are very useful for describing the ordering and timing aspects of the system behavior. Collaboration diagrams show the collaborations between the various distributed actors in terms of message exchanges in order to complete a business function or enforce business logic. State diagrams can also be used to describe the input/output system-level functional behavior as observed across the various distributed points of interactions with system actors. High-level activity diagrams describe the ¯ow of control from activity to activity across various use cases and model the dynamic system behavior at a high-level of abstraction. The use of the UML diagrams for business modeling helps considerably in ensuring the completeness of the functional and behavioral aspects of an EC business system requirements, and provides a useful basis for generating functional, transaction-oriented and system-level blackbox-based test cases and for obtaining use case based metrics and estimations [6]. 3.2. Structural modeling: the design and process views The structural model is considered as a re®nement of the behavioral model of the business functionalities as elicited in the use case view using the use case diagrams, and system-level state, sequence, collaboration and activity diagrams. The structural model is elaborated using the design and process views. The static elements of the structural model are described using object and class diagrams. A class diagram shows all the classes included in the model, in addition to their relationships. Visualizing the aggregation, generalization, dependency and association relationships connecting classes helps considerably in understanding the classes and their structures, in addition to their degree of coupling,
traversal and reusability. Objects diagrams show how instances of the classes interact among each other's. The dynamic elements of the structural model are described using interaction diagrams, statechart diagrams and activity diagrams. Sequence diagrams show the sequencing of exchanged messages and inter-object messages among actors and objects. Objects with a signi®cant, state-oriented dynamic behavior are also modeled using statechart diagrams. Moreover, multi-threaded and concurrent behaviors of certain objects are captured intuitively in both activity and statechart diagrams. Collaboration diagrams are used to show the various ways objects and actors collaborate to provide the required business logic and functions. Messages in collaboration diagrams become operations embedded within some classes of the static elements of the structure. Activity diagrams normally show the behavior of actors and objects across several use cases. Both the design and process views use the same diagrams to describe the static and dynamic elements of the structural model. The only difference is that the process view increments the design view with semantical information dealing with real-time issues related to concurrency, multi-threading, synchronization and scalability. 3.3. Architectural modeling: the implementation and deployment views At the architectural level, the two views related to the implementation and the deployment of EC software components are provided. The implementation view is represented using component diagrams describing the organization of the EC software implementation components and their inter-dependencies. A component diagram contains a set of software model components, the model development time relationships between components, and the model calls relationships between components. The deployment view (also referred to as the environment view) is represented using deployment diagrams. These diagrams show the various processing nodes in the EC system according to its business model, and the distribution of software implementation components among these nodes. A deployment diagram consists of EC nodes and components (from the component diagram), the communications and run-time relationships between nodes, the calls and becomes relationships between components (the latter from the component diagram), and ®nally, the supports relationships between nodes and components. Table 2 summarizes the use of UML diagrams to support the various views, aspects, and software development processes. 4. Example In this section, we illustrate the use of the UML for the
K. Saleh / Information and Software Technology 44 (2002) 303±311
307
Table 2 Use of UML diagrams for EC software development Views
Diagrams
EC system software development
Behavioral aspects: Use Case View
Use Case diagrams; Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams Class diagrams; Object diagrams; Sequence diagrams; Collaboration diagrams; Statechart diagrams; Activity diagrams Component diagrams; Deployment diagrams
Business model documentation; Requirements capture and functional speci®cations
Structural aspects: Design and Process Views Architectural aspects: Implementation and Deployment Views
visual speci®cation and documentation of a subset of an EC business model, namely, the Store Front business model. First, we will informally describe the ordering and paying parts of the model. Then, we will show the behavioral aspects using the use case view and its related diagrams. We also show the structural aspects using the design and process views and their related diagrams. Finally, we present the architectural aspects using the implementation and deployment views and their related diagrams. 4.1. Informal description of the model This model subset deals with the ordering and paying parts of the EC store front business model. In this model, an online business is selling products made by various manufacturers. The products are physically located in the business warehouses. Consumers will be ®rst able to browse through the business catalog of products and ®ll a shopping cart with products to purchase as they go along. Then the consumer will proceed to checkout for payment. At this moment, the business will channel the request to a payment server, which will securely request the payment credit information from the consumer. The payment server will then con®rm with its supporting ®nancial institution (the bank) the validity of the payment. The bank will either send a transaction authorization code or decline the approval of the transaction. Once approved, the payment server will concurrently send the approval code to the business, and a
High-level and detailed design; Object-oriented analysis and design; Test suite development Con®guration management; Installation plan; Version control; Testing and test management
con®rmation of receipt to the consumer. (Notice here in this model, the business will never be aware of any personal credit information on the consumer). Once the business receives the transaction approval code, it launches the order ful®llment process, which includes sending a message to the warehouse with customer delivery information, which in turn sends a message to the shipping company. The shipping company will then communicate delivery information to the consumer. It is clear here that the use of English to describe this part of the process model is not adequate and can lead to some ambiguities. The use of a visual modeling techniques and tools such as the UML would de®nitely eliminate any misinterpretations of the business model. The proper development of the various UML diagrams drawn mostly from the vocabulary of the system and elicited by a thorough process involving many stakeholders at various stages of the development process reduce the risks of producing low quality, incomplete, ambiguous or non-deterministic software. 4.2. Behavioral aspects of the model This part of the business model can be described using the static and dynamic elements of the behavioral aspects of the use case views. In our example, the use case diagrams in Fig. 1 show the static elements including the various actors and the functionalities involved in the ordering and paying
Fig. 1. Use case diagram for the ordering and paying parts of the model.
308
K. Saleh / Information and Software Technology 44 (2002) 303±311
Fig. 2. Collaboration diagram for the ordering and paying parts of the model.
behaviors. However, the dynamic elements of the behavior are shown using the collaboration diagram in Fig. 2, the sequence diagram in Fig. 3 and the activity diagram in Fig. 4. Moreover, a high-level statechart diagram is shown in Fig. 5 to represent the states of the system during the different ordering and paying activities, and the transitions between them. Normally, as it is in this case, additional collaboration, sequence and activity diagrams are needed to show the complete possible interaction and activity scenarios. 4.3. Structural aspects of the model The static elements of the structural aspects of the model are shown using the partial class diagram in Fig. 6. For conciseness, we are omitting the details of the classes in terms of attributes and methods. The object/class model including both attributes and operations depends on the business model, in our case, the store front model. The required classes include bound-
ary classes representing the interfaces between actors identi®ed in the use case view and the system, entity classes representing those things in the system that must be persistent, in addition to application domain or control classes, such as the Transaction and Catalogue class, and low-level utility classes, such as the Timer and Authentication classes. The collaboration and sequence diagrams illustrating the dynamic elements of the structural aspects include, in addition to the objects shown in the same diagrams for the behavioral aspects (Figs. 2 and 3), objects corresponding to the additional classes identi®ed in the class diagram, such as, Order, Transaction, Timer, Product and Catalogue. For example, both the payment server and bank objects are going to start their timers to make sure that a certain time limit is not exceeded waiting for an approval. Also, once the business validates an order, it will create a transaction object to be handled by the payment server object. Fig. 7 shows these parts of the overall collaboration and sequence
Fig. 3. The sequence diagram for the ordering and paying parts of the model.
K. Saleh / Information and Software Technology 44 (2002) 303±311
309
Fig. 4. The Activity diagram for the paying parts of the model.
Fig. 5. State diagram for the ordering and paying parts of the model.
diagrams. Moreover, at this level, statechart diagrams can be used to describe the lifecycle of some objects in the static class model. For example, an order object can go through a ®nite number of states, from `open' to `closed', and ®nally, it is saved in a persistent store, either in a Transactions/Orders database or in a log ®le. In this paper, we are not including the complete diagrams. But it is important to mention here that UML diagrams allow the inclusion of many semantical details that are very helpful to move from the modeling phase to the implementation or coding phase of the software. In fact, code generation tools already exist to generate object-oriented code in C11 or Java starting from the various diagrams obtained in the modeling phase [7].
310
K. Saleh / Information and Software Technology 44 (2002) 303±311
Fig. 6. Class diagram for the ordering and payment parts of the model.
Fig. 7. Partial collaboration and sequence diagrams for the structural aspects of the model.
Fig. 8. Deployment diagrams.
K. Saleh / Information and Software Technology 44 (2002) 303±311
4.4. Architectural aspects of the model UML provides very little semantical links between the two diagrams supporting the architectural aspects from the implementation and Deployment viewpoints and the diagrams supporting the structural aspects. However, we believe that these two diagrams, namely the component and deployment diagrams, provide the necessary information to package the software and con®gure it properly across a distributed system such as an EC system. Fig. 8 shows a deployment diagrams which include components drawn in the component diagrams.
311
we intend to develop a semantic model checking technique which can detect semantic errors in the model that are not detected by the tool.
Acknowledgements The author would like to thank Professor Robert Probert from the University of Ottawa, and Professor Rachida Dssouli from Concordia University, for their constructive comments and remarks made on an earlier version of this work.
5. Summary and conclusion In this paper, we have used the UML for the formal visual speci®cation and documentation of EC systems and their business models. The various UML diagrams are appropriately used to describe the three model aspects: the behavioral, structural and architectural aspects. The bene®ts of using UML extend beyond being a documentation technique, to reach test case design, generation and coverage and model checking and reuse. We have illustrated the use of UML using a small subset of the store front business model currently a very popular model for online internet-based businesses. This part includes the ordering and paying parts of the business model. In the future, we intend to describe the complete store front business model, and we will elaborate further on the structural and architectural aspects of the model. We also plan to include within these two aspects CORBA-based design and implementation details. Finally,
References [1] K. Saleh, R. Probert, Issues in testing e-commerce systems, in: K. Dong (Ed.), Electronic Commerce Technology Trends: Challenges and Opportunities, IBM Press, IIR Publications Inc, California, USA, 2000, pp. 273±282 Chapter 17. [2] G. Booch, J. Rumbaugh, I. Jacobson, The Uni®ed Modeling Language User Guide, Addison Wesley, Reading, MA, 1999. [3] R. Dssouli, R. Probert, K. Saleh, F. Khendek, Electronic commerce testing. Tutorial Notes, IFIP 13th International Conference on Testing of Communicating Systems (TestCom 2000), Ottawa, Canada, August 2000. [4] G.W. Treese, L. Stewart, Designing Systems for Internet Commerce, Addison Wesley, Reading, MA, 1998. [5] K. Saleh, M. Jaragh, Speci®cation of communications protocols and services using UML, TENCON 2000, Malaysia, September 2000. [6] K. Saleh, R. Probert, W. Li, W. Fong, An approach to high-yield requirements speci®cations for e-commerce and its application, International Journal on Digital Libraries (2001). [7] W. Boggs, M. Boggs, Mastering UML with Rational Rose, Sybex Publisher, Sybex Inc, California, USA, 1999.