Grading Rubrics Petries Electronics Use Case Diagram Points Create a Use-Case Diagram for the CRM System following the UML guidelines in Appendix A of the textbook. Doc sharing Project Workbook – Week 7 folder, has instructions on how to create a Use Case using Visio (but you can use any MS Office application). Need to include processes for Record Customer Activities, Send Promotions, Generate Point Redemption Coupons, and Generate Customer Reports processes. The hint is to look at the external entities, processes, and data stores from the Level 0 DFD on page 187. Actors: The Customer is a source and a sink – and should be shown as one Actor on our Use Case. The three data stores will be the other actors: Customer Activity Records. Marketing Database. Product Database. Process: Each of the sub process on page 187 will become a Process reflected in the Use Case. So we have a total of four processes. Send Promotions. Generate Point Redemption Coupons. Record Customer Activity. Generate Customer Reports. Actors will interact with the processes on the Use Case based on the data flow arrows on the Level 0 diagram. For Example: Product Database Actor will connect to the Generate Customer Reports process as shown on the bottom right of the Level 0 diagram on page 187. The Unified Modeling Language (UML) allows the modeler to specify, visualize, and construct the artifacts of software systems, as well as business models. It builds upon and unifies the semantics and notations of leading object-oriented methods and has been adopted as an industry standard. The UML notation is useful for graphically depicting object-oriented analysis and design models. It not only allows you to specify the requirements of a system and capture the design decisions, but it also promotes communication among key persons involved in the development effort. A developer can use an analysis or design model expressed in the UML notation to communicate with domain experts, users, and other stakeholders. To represent a complex system effectively, the model developed needs to have a small set of independent views of the system. UML allows you to represent multiple views of a system using a variety of graphical diagrams, such as the use-case diagram, class diagram, state diagram, sequence diagram, and collaboration diagram. The underlying model integrates those views so that the system can be analyzed, designed, and implemented in a complete and consistent fashion. We first show how to develop a use-case model during the requirements analysis phase. Next, we show how to model the static structure of the system using class and object diagrams. You then learn how to capture the dynamic aspects using state and sequence diagrams. Finally, we provide a brief description of component diagrams, which are generated during the design and implementation phases. Use-Case Modeling Use-case modeling is applied to analyze the functional requirements of a system. Use-case modeling is done in the early stages of system development (during the analysis phase) to help developers understand the functional requirements of the system without worrying about how those requirements will be implemented. The process is inherently iterative; developers need to involve the users in discussions throughout the model development process and finally come to an agreement on the requirements specification. A use-case model consists of actors and use cases. An actor is an external entity that interacts with the system (similar to an external entity in data-flow diagramming). It is someone or something that exchanges information with the system. A use case represents a sequence of related actions initiated by an actor; it is a specific way of using the system. An actor represents a role that a user can play. The actors name should indicate that role. Actors help you to identify the use cases they carry out. Actor An external entity that interacts with the system (similar to an external entity in data-flow diagramming). Use case A sequence of related actions initiated by an actor; it represents a specific way to use the system. During the requirements analysis stage, the analyst sits down with the intended users of the system and makes a thorough analysis of what functions they desire from the system. These functions are represented as use cases. For example, a university registration system has a use case for class registration and another for student billing. These use cases, then, represent the typical interactions the system has with its users. In UML, a use-case model is depicted diagrammatically, as in Figure A-1. This use-case diagram is for a university registration system, which is shown as a box. Outside the box are four actorsStudent, Registration clerk, Instructor, and Bursars officethat interact with the system (shown by the lines touching the actors). An actor is shown using a stick figure with its name below. Inside the box are four use casesClass registration, Registration for special class, Prereq courses not completed, and Student billingwhich are shown as ellipses with their names inside. These use cases are performed by the actors outside the system. Use-case diagram A diagram that depicts the use cases and actors for a system. A use case is always initiated by an actor. For example, Student billing is initiated by the Bursars office. A use case can interact with actors other than the one that initiated it. The Student billing use case, although initiated by the Bursars office, interacts with the Students by mailing them tuition invoices. Another use case, Class registration, is carried out by two actors, Student and Registration clerk. This use case performs a series of related actions aimed at registering a student for a class. The numbers on each end of the interaction lines indicate the number of instances of the use case with which the actor is associated. For example, the Bursars office causes many (*) Student billing use-case instances to occur, each one for exactly one student. FIGURE A-1 Use-case diagram for a university registration system drawn using Microsoft Visio. A use case represents a complete functionality. You should not represent an individual action that is part of an overall function as a use case. For example, although submitting a registration form and paying tuition are two actions performed by users (students) in the university registration system, we do not show them as use cases, because they do not specify a complete course of events; each of these actions is executed only as part of an overall function or use case. You can think of Submit registration form as one of the actions of the Class registration use case, and Pay tuition as one of the actions of the Student billing use case. A use case may participate in relationships with other use cases. An extends relationship, shown in Microsoft Visio as a line with a hollow triangle pointing toward the extended use case and labeled with the <