Electronic Business: Concepts, Methodologies, Tools, and Applications (4-Volumes) P122 pdf

1144 Case Study In SODI, while a software project is being developed through the inception, elaboration, construction, and transition phases, the activi- ties for analysis, design, implementation, and deployment are done iteratively, incrementally, and concurrently. The activities are modeled based upon Kruchten’s (1995) 4+1 view using UML diagrams. These visual models are used for model- ing, that is, visualizing, specifying, constructing, and documenting the service-oriented software development and integration. Table 1 shows SODI using the RUP framework and 4+1 views. At the inception phase, SODI practitioners bring the idea of using three architectural patterns WRDOOZRUNÀRZV'XULQJWKHLQFHSWLRQSKDVHWKH use-case view is mainly modeled based upon the given or collected case scenarios. The use-case view model consists of use-case diagrams along with activity diagrams for more detailed coverage RI XVHFDVH VSHFL¿FDWLRQV 8VHFDVH GLDJUDPV are generally used to describe the requirements present throughout the design of the system while activity diagrams help describe the basic ÀRZEHWZHHQDSSOLFDWLRQFRPSRQHQWV7KHXVHU requirements are viewed in terms of the three- layered architecture, and each layer is represented as a subsystem in the use-case diagrams. If a use case or a set of use cases needs more explanations, activity diagrams are drawn for them. During the elaboration phase, the design and process views are modeled based upon the use-case or activity diagrams. The design view model consists of class diagrams for a business logic layer and entity-relationship (ER) diagrams for databases (Connolly & Begg, 2005). Class diagrams are used to model classes and their relationships. When Kruchten’s (1995) 4+1 view model was proposed, the object-orientation concept was dominant at that time. Also, the concept of software development within an organization was the main concern instead of the integration of heterogeneous software applications across organizations. Additionally, the concept of pro- cess could not be clearly represented with the conceptual building block object. Therefore, the process view was limited to methods in a class, the states of an object, and interactions among objects. If a method of a class needs more ex- planation, an activity diagram can be used to explain the method. Also, the state change of an object can be explained in a state-chart diagram. The interactions among several objects can be described in an interaction diagram that may be a collaboration or sequence diagram. Since a Web service can represent a business process, and a special class called an interface can represent the service, a class diagram can be used to show the relationship between the Web service and a set of classes to implement the service. Class diagrams mainly focus on the structure hidden behind the Web service interfaces. Using an activ- ity diagram, we can represent the collaboration among services. During the construction phase, the implemen- tation view model is built by using component diagrams. These diagrams are closely linked to class diagrams but are a bit more physical in their existence. Component diagrams primarily focus RQGH¿QLQJGHSHQGHQFLHVEHWZHHQFRPSRQHQWV of any type for a layer on a tier. During the transition phase, the deployment view is modeled using deployment diagrams. Deployment diagrams clearly illustrate how your system components should be deployed, and exactly on what system they should be deployed to. These deployment diagrams are used to out- line the deployment of executable components onto a platform equipped with various software engines. CASE STUDY: SODI AND RETAIL BISS OF EAS, 3S, AND POS Each of the individual applications has its own set of unique diagrams that describe the requirements of the system, the structure of the system, and how 1145 Case Study the system should be deployed. While some of the Web services and classes are shared, for the most part, each application is fairly different from one another in terms of implementation. The diagrams that appear in this chapter are just a handful of the many different diagrams developed to describe the three applications: EAS, 3S, and POS. Use-Case Scenarios 7KH¿UVWWDVNLVWRFROOHFWWKHXVHFDVHVFHQDULRV Although there are many other functions offered E\($6WKHHPSOR\PHQWHQUROOPHQWZLWKD¿Q- gerprint is discussed in this chapter. The image in Figure 2 depicts a manager enrolling an employee’s personal information in EAS. The upper half of the form contains personal details while the bot- tom half contains job-related details. Once the employee’s personal information is entered, his RUKHU ¿QJHUSULQWPXVW WKHQ EHHQUROOHG 2QFH WKH¿QJHUSULQWLVHQUROOHGPDQDJHUVFDQEHJLQ creating schedules. There are various problems associated with the existing surveillance solutions, namely, the systems can react to streamed video and perform some action. However, they are not proactive in nature. The 3S implementation provides a better control layer for managers to use when interacting with their security camera. 3S allows managers to schedule images to be taken at any interval from DQ\SHULRGRIWLPHWKURXJKRXWWKHGD\7KLV¿QH grained control allows managers to see only what they want at any time. Providing faster access to security recordings improves productivity and allows for more accurate archiving of footage. 7KHVHIHDWXUHVFRXOGEHXVHGIRUEHLQJQRWL¿HG with various images from around your store when the store is supposed to open or close. This would Figure 2. Employee enrollment in EAS 1146 Case Study be a very handy feature for small business own- ers who want to make sure that their employees open their shop in the mall on time and do not skip out early at closing time. Figure 3 is of the start-up screen for 3S. The screenshots have been selected as images a manager would see if he or she wanted to schedule a set of snapshots to be taken and then view them remotely. The new POS system takes advantage of the features of an SOA to decouple the application interface from its implementation. To enhance the robustness of the system, its database back end has been built to be fully compliant with the VSHFL¿FDWLRQVRXWOLQHGLQWKHSURYHQ$VVRFLDWLRQ for Retail Technology Standards (ARTS, 2003) model standard. The ARTS model is an industry standard database schema that can be used for enterprise-level retail database applications. By using this standardized database back end, a pluggable interface, and a Web service middle tier, the POS is constructed in such a way that it is capable of being upgraded, extended, and integrated as new technologies and new business demands emerge. The main focus in designing this POS system was to create a basic interface and a set of Web services that the interface can use to handle most of its functionality. The screenshots in Figure 4 show one example interface that could be used in conjunction with the Web services being developed. These are the screens that a cashier would see after logging onto the system using a ¿QJHUSULQWZKHQZDQWLQJWRULQJXSDSXUFKDVH This screen shows the main interface that cashiers use. Cashiers enter the product ID and the quantity, and then click the Add Item button. The item is then added to the sales grid. Use-Case View The core requirements for each application have been described in use-case diagrams. Actors and V\VWHPFRPSRQHQWVDUH¿UVWPRGHOHGXVLQJWKH Figure 3. 3S start-up screen 1147 Case Study use-case diagrams. Next, the primary functional- ity of each system is described in the three logic layers in the diagrams. Figures 5 and 6 show the use-case diagrams for EAS and 3S. Figure 5a illustrates the main functionality of the EAS system, as well as the various sub- V\VWHPVWKDWKDYHEHHQLGHQWL¿HGDQGPRGHOHG :LWKLQ($6WKHUHDUH¿YHPDLQVXEV\VWHPVIRXU that contain system functionality, and a database system. The recognition system is responsible for PDWFKLQJHPSOR\HH¿QJHUSULQWV7KHHQ UROOPHQW V\VWHPLVUHVSRQVLEOHIRUHQUROOLQJHPSOR\HH¿Q- gerprints. The management system is designed to add, update, and delete employee information as well as employee schedules. The report system is responsible for generating the various reports that can be created once schedules have been entered. 7KH¿QDOV\VWHPLVWKHGDWDEDVH The use-case diagram in Figure 5b illustrates a store manager controlling employee schedules. There are certain options that are presented to the manager in the presentation layer. These op- tions such as updating schedules use the schedule management service in the business logic layer to accomplish its task. The schedule management service in turn uses the main EAS database and ac- cesses the appropriate scheduling information. The use-case diagram in Figure 6a illustrates a security person and a manager wanting to re- trieve a snapshot recording by using 3S. Security personnel can both delete and view snapshots from the snapshot management service. The ac- tivity diagram in Figure 6b depicts the process for viewing and deleting snapshots. First, the snapshot service ensures that the snapshot actu- ally exists, and then the service either retrieves the snapshot or deletes the snapshot depending on the input received. If the snapshot does not exist, the service method returns. Design View The class diagram in Figure 7 shows a design view by showing the class hierarchy of the main form, which contains all the interfaces for the POS. The main form uses two local classes, ReceiptInfo and Figure 4. POS start-up screen 1148 Case Study Figure 5. Use-case view of EAS (a) Use-case view with a use-case diagram for EAS (b) Use-case diagram with three-layered architecture for EAS 1149 Case Study Figure 6. Use-case view of 3S (a) Use-case view with a use-case diagram for 3S (b) Use-case view with an activity diagram for 3S 1150 Case Study Receipt, for managing receipts and receipt lines. Also, there is a payment form that allows cashiers to enter the designated payment and calculate the change required. Process View A collaboration diagram can represent the process view by showing the interactions among objects and atomic Web services. An activity diagram can represent the process view of a composite service by showing the interactions among Web services. In Figure 8, the recognition subsystem of EAS is not responsible for anything other than UHFRJQL]LQJ¿QJHUSULQWVDQGFRQWDFWLQJWKHDS- propriate Web service FingerprintProcess with the results. As such, it is much simpler than the other EAS components. The top class is a form; this class uses various other classes on the client side within the same application. The collaboration diagram in Figure 9 depicts the relationship between a Web service object Ser- viceManager and other objects. ServiceManager is a central class that is a Web service, and there are various other classes and data sets that the Web service class uses. There are data transport classes such as ScheduleData and UserData as well as normal data type classes such as Snap- shotPack, which are generally found in the class library called ThreeSObjects. Figure 7. Design view of the POS 1151 Case Study Figure 8. Process view of the recognition subsystem of EAS Figure 9. Process views of 3S 1152 Case Study Implementation View A component diagram can represent an imple- mentation view of a system by showing what physical components are used and how they are interrelated. Figure 10 contains a fairly simple overview of the components of the Employee- Hours subsystem required to generate a simple report containing information about how long an employee worked for a given day. There is one Web form EmployeeHours.aspx, its corresponding code in C# behind page EmployeeHours.aspx.cs, two Web services used by the code behind pages UserValidation.asmx and EmployeeHours.asmx, and the employee database used by both Web services EAS_DataBase.mdf. Figure 11 depicts the dependencies that ex- ist in the 3S client application. The executable client depends on the Active X control called AxisMediaControl.dll used to interface with the camera. The MainForm that launches other forms depends upon the 3S class library Three- 3Objects.dll as well as a few other forms such as UserManagementFrm, ScheduleViewerFrm, SnapshotSelecterFrm, and so forth. Deployment View A deployment diagram can show which executable components are deployed at which tier. Figure 12 outlines which components are executable by end users and where they are stored within the EAS architecture. There are two types of client: two client-side Windows applications called EASRecognition.exe and EASAdministration. exe, and two server-side Web applications called Figure 10. Implementation view of the EmployeeHours subsystem of EAS 1153 Case Study EASLogin.aspx and EmployeeHours.aspa, which require network connections on both the client and server sides, as well as the physical ¿QJHUSULQW VFDQQLQJ GHYLFH RQ WKH FOLHQW VLGH Figure 12b shows the three-tier architecture for the recognition component deployed, requiring a client workstation, an application server, and a database server as well as an internal network between each workstation. The service consumer EASRecognition.exe invokes the FingerprintPro- cess.asmx Web service. Figure 13 illustrates the four-tier architecture used to deploy 3S. There is the actual camera called Axis 2100, the 3S Windows application client called 3S.exe, the 3S database ThreeS_Data. mdf, the 3S server ThreeSSever.exe, and a service ThreeS.asmx. Since the 3S sever can access the remote camera through the Web service, the legacy camera interface is hidden and any applicant can access the camera easily. ANALYSES AND DISCUSSIONS One of the main goals of this project is to see WKH EHQH¿WV RI VHUYLFHRULHQWHG DUFKLWHFWXUH by applying it in particular to the area of retail business applications. This section describes the Figure 11. Implementation view of the 3S client . Technology Standards (ARTS, 2003) model standard. The ARTS model is an industry standard database schema that can be used for enterprise-level retail database applications. By using this standardized. SODI AND RETAIL BISS OF EAS, 3S, AND POS Each of the individual applications has its own set of unique diagrams that describe the requirements of the system, the structure of the system, and. interface, and a Web service middle tier, the POS is constructed in such a way that it is capable of being upgraded, extended, and integrated as new technologies and new business demands emerge.