These are full directions for what I need done.
The background information for this:
Problem Description for SAS (Subscription Automation System):
A company produces a monthly magazine called HOST (Hot Software Technologies). It wants to create a web-enabled subscription automation system as described below.
HOST is sold on a subscription basis. Subscription to HOST is either paid or free. There are three categories of free subscriptions. The first category is authors of articles. The second category is members of the editorial board, who review and edit the articles. The third category is complimentary subscriptions which are sent to gurus of the field, and this complimentary subscription is determined by the editor. Authors of an article receive a one-year free subscription from the month their article appears. If they already have a subscription, then the expiration date on the existing subscription is extended for a year. The publisher also has a large list of “prospects,” as a trial basis. Many of these prospects have asked for a sample copy, but then decided not to convert to a paid subscription. All of this information is kept in the system.
For paid subscriptions to HOST, most subscriptions are for a one-year period. If subscribers subscribe for multiple-years, they receive a 10% discount for each year up to three years. Subscriptions can come by mail, phone, or the web. The web subscription requires the use of a credit card for payment, while other subscriptions could be paid for by check or credit card. When subscribing through the web, one can also check the subscription status or renew. The termination of a subscription, however, cannot be done via web. The termination must be initiated by the customer via a phone, fax, or a written request and must be processed by a staff member. For each subscription and cancellation, a confirmation notice is sent via email to the subscriber. Paid subscribers are 2 types- “corporate” or “individual” subscribers. In the case of a corporate, the primary contact person is clearly designated. Copies could be sent to either office address or home address of a subscriber. Some subscribers live in foreign countries and issues need to be mailed to the foreign countries with a proper mailing charge.
A renewal notice is sent to a subscriber several months before the expiration date. On the final month of a subscription, the publisher includes a large note with the magazine that says “THIS IS YOUR LAST ISSUE.” For several months after the subscription has expired, the publisher occasionally sends renewal notices. Therefore, it is vital to maintain the various subscription data on the database indefinitely. To simplify the problem, assume as follows:
– Each subscription is for only one copy
– The subscriber is the one who actually gets the issue.
– The billing address is the same as mailing address.
– No purchase order or invoice will be sent out;
– No ordering of back issues will be handled
Note: If you need to make any other reasonable assumptions within the above framework, you may as long as you make sure to state it on your paper. Be careful that your wrong or unreasonable assumptions, which contradict to the above statement, cause a wrong analysis.
What needs to actually be done:
Class Diagrams
a) Develop a Domain Model (Class Diagram) for the SAS use case diagram. The Domain Model must contain attributes, associations, and cardinality. Your association lines must contain appropriate association names.
b) Develop a Design Class Diagram for the SAS domain based on the problem definition given above. Identify only domain classes. Domain classes are those that are fundamental to the problem domain at the business level. Do not include design classes such as input/output classes, windows classes, or physical implementation-related classes. Your diagram must include important attributes that are mentioned or implied in the problem statement and the above use case description. Show the important attributes in the second component of a class symbol. The class diagram must show classes, important attributes, associations, methods and cardinality.
Further notes: (the book that includes the chapters referenced below will be included as a reference.
NOTE 1: Before you start this assignment, be sure to review the chapters on the Domain Model (Class Diagram) and on the Design Model (Design Class Diagram — DCD). Chapters 9 and 16 are your instructions on this assignment. Be sure that you are including all the required characteristics of each model. For the purposes of this assignment your Domain Model needs MULTIPLICITY, ATTRIBUTES, and ASSOCIATION NAMES. DCD’s need ATTRIBUTES, FUNCTIONALITY (Methods), MULTIPLICITY, and ASSOCIATION NAMES.
Finally, be sure you understand how associations change from the Domain Model to the DCD. To help keep you on track, please refer often to the Figure 16.2 from Chapter 16. I have included this figure in the assignment for your convenience. Note that in the Domain Model, “Register” “Captures” “Sale”. Since in the DCD we are modeling the software implementation, the association changes to an instance of a sale – a variable named “currentSale.” Think about when you create a class. You will declare variables that get values, and you will write subroutines (methods) that do jobs. The variables that you declare are in many cases the attributes of the object. The values that you assign to the attributes describe the object in some way. Sometimes, the variables that you declare are actually instantiation of some other object. For example, to do its job, “Register” needs access to several attributes and methods that belong to the “Sale” class. To get access to this information, “Register” instantiates a new instance of the “Sale” class. So, “Register” could have a variable that is declared this way: “currentSale = new Sale()”. Then you can access members of the “Sale” class with statements like “dateTime saleTime = currentSale.time” or “while more lineItems
Receipt = receipt + currentSale.makeLineItem() + chr(10)”
These attribute variables that instantiate another object, are the associations between objects in the computer program. So, the names of the associations in the DCD (which is a model of the computer program) would be appropriate variable names for an instantiated object.
Following the same thought process, sometimes the association between two classes is not an attribute, but a message or method call from the initiating class to the target class. Either way, the association line has a label that indicates what the initiating class is doing with the associated class. In our example 16.2, another viable association label might be “makeLineItem”. But either way, the correct label for the DCD would not be “captures.”
NOTE 2: Testing your class diagrams
Walk through your class diagram to see whether a few scenarios from the use case can be processed. Try the following scenarios that come from several different use cases:
– A person subscribes for one year with a VISA card. The system records the necessary subscription data, process payments, establish expiration date for subscription, establish expiration warning date, and send a confirmation email for subscription.
– A foreign subscriber subscribes for two years with 10% discount. HOST issues will be sent to the home address. The system records the necessary subscription data, process payments, establish expiration date for subscription, establish expiration warning date, and send a confirmation email for subscription.
– A subscriber renewed her subscription for one more year using her credit card.
– A person sent a request to cancel her subscription and requested a refund for the remaining portion of the subscription fee.
– A prospect requested a sample issue.
– A subscriber’s subscription is about to expire.
You may create your own test cases based on use cases. Keep modifying the class diagram until your diagram can handle these requirements.