Also need this by sunday
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.
- So we have a total of four processes.
- 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 actor’s 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 actors—Student, Registration clerk, Instructor, and Bursar’s office—that 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 cases—Class registration, Registration for special class, Prereq courses not completed, and Student billing—which 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 Bursar’s office. A use case can interact with actors other than the one that initiated it. The Student billing use case, although initiated by the Bursar’s 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 Bursar’s 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 <<extends>> symbol, extends a use case by adding new behaviors or actions. In Figure A-1, for example, the Registration for special class use case extends the Class registration use case by capturing the additional actions that need to be performed in registering a student for a special class. Registering for a special class requires prior permission of the instructor, in addition to the other steps carried out for a regular registration. You may think of Class registration as the basic course, which is always performed—independent of whether the extension is performed or not—and Registration for special class as an alternative course, which is performed only under special circumstances.
Another example of an extends relationship is that between the Prereq courses not completed and Class registration use cases. The former extends the latter in situations where a student registering for a class has not taken the prerequisite courses.
Figure A-2 shows a use-case diagram for Hoosier Burger. The Customer actor initiates the Order food use case; the other actor involved is the Service Person. A specific scenario would represent a customer placing an order with a service person.
FIGURE A-2 Use-case diagram for a Hoosier Burger system.
So far you have seen one kind of relationship, extends, between use cases. Another kind of relationship is included, which arises when one use case references another use case. An include relationship is also shown diagrammatically as a dashed line with a hollow arrowhead pointing toward the use case that is being used; the line is labeled with the <<include>> symbol. In Figure A-2, for example, the include relationship between the Reorder supplies and Track sales and inventory data use cases implies that the former uses the latter while executing. Simply put, when a manager reorders supplies, the sales and inventory data are tracked. The same data are also tracked when management reports are produced, so there is another include relationship between the Produce management reports and Track sales and inventory data use cases.
The Track sales and inventory data is a generalized use case, representing the common behavior among the specialized use cases, Reorder supplies and Produce management reports. When Reorder supplies or Produce management reports is performed, the entire Track sales and inventory data is used.
Object Modeling: Class Diagrams
In the object-oriented approach, we model the world in objects. An object is an entity that has a well-defined role in the application domain and has state, behavior, and identity. An object is a concept, abstraction, or thing that makes sense in an application context. An object could be a tangible or visible entity (e.g., a person, place, or thing); it could be a concept or event (e.g., Department, Performance, Marriage, Registration, etc.); or it could be an artifact of the design process (e.g., User Interface, Controller, Scheduler, etc.).
Object
An entity that has a well-defined role in the application domain and has state, behavior, and identity.
An object has a state and exhibits behavior through operations that can examine or affect its state. The state of an object encompasses its properties(attributes and relationships) and the values those properties have, its behavior represents how an object acts and reacts. An object’s state is determined by its attribute values and links to other objects. An object’s behavior depends on its state and the operation being performed. An operation is simply an action that one object performs upon another in order to get a response.
State
A condition that encompasses an object’s properties (attributes and relationships) and the values those properties have.
Behavior
Represents how an object acts and reacts.
Consider the example of a student, Mary Jones, represented as an object. The state of this object is characterized by its attributes, say, name, date of birth, year, address, and phone, and the values these attributes currently have. For example, name is “Mary Jones,” year is “junior,” and so on. Its behavior is expressed through operations such as calc-gpa, which is used to calculate a student’s current grade point average. The Mary Jones object, therefore, packages both its state and its behavior together.
