Docstoc

u08a3

Document Sample
u08a3 Powered By Docstoc
					U08a3 1 Jeannine Tyler

Jeannine Tyler Ken Orgill - TS4720 U08a3 – Object Oriented Design and Modeling User Networking Subsystem

U08a3 2 Jeannine Tyler

Table of Contents

I. Extended Use Case Scenario ……………………………………3 II. Use Case …………………………………………………..……5 III. Interface, Control, and Entity Classes ……………………….…6 IV. Summary of Invite Potential Member Use Case Behavior……....7 V. Entities with Assigned Behaviors and Responsibilities …………8 VI. Sequence Diagram………………………………………….……9 VII. State Machine Diagram ……………………………………..…10 Diagram……………………………………………..…….…11 VIII. Class Diagram ……………………………………………...…12 References ………………………………………………………..…14

U08a3 3 Jeannine Tyler

I.

Extended Use Case Scenario:

The Use Case I chose to implement for the User Networking System is the Invite Potential Member Use Case. This scenario describes the use case and the various steps needed to complete the task. The required actor actions are included. The first step is the actor has to click the “Invite Friend” button. This button will be located either on the Profile Page of the User, or as a link in a promotional email from Fantasy Games that was sent to the User to their account email. The second step is for the system to return the Invite Friend Form, which consists of four text boxes, two of which are optional. The actor then fills out the required data and hits send. If the fields are filled out incorrectly then an error message will result. Once the actor has successfully sent the data, the system sends out an email. The system also saves the Potential Member‟s email and name. If the email should be returned as invalid, the system will delete the Potential Member Name and Email.

Use Case Name: User Case ID Priority Source Primary Business Actor Other Actors Other Stakeholders Description

Invite Potential Member 12182207 High UN Subsystem Req 12 User Member System (database) Marketing – interested in the rate of referrals and the data stored from the transactions. Potential Member – the one who gets the email with the invite. The Member chooses to send a form letter to an external Potential Member that invites them to join the site. The information gathered is then stored in the database, and if the email comes back as invalid, the information is deleted from the database. The Member must be logged in. The Member must fill in all the proper fields. The email must be valid. The Member must navigate to the proper webpage. The Member clicks on a link that invites a friend, either in a promotional email or on a page on the website itself. Actor Action System Response 1. Member clicks “invite friend” button. 2. Returns the “invite friend” email form in a new browser window. The form will have editable text boxes for the name, email, email subject, and email body. The name will have “Type your friend‟s name here…” in the box, email will have “Type your

Precondition

Trigger Typical Course of Events

U08a3 4 Jeannine Tyler friend‟s email here…” in the box, the subject and body can be optionally edited and is complete as is. 4. Sends form email to the email listed. Sends the information (email, potential user name, Member user) to the database. Gives screen confirmation of the email sent to the Member. 5. If the email gets returned to the system and is not valid, the system deletes the database entry

3. Member fills out email and name and clicks the “send” button.

U08a3 5 Jeannine Tyler

II.

Use Case:

This Use Case shows the actor: Member, who interacts with the interface. The Use Case shows the required actions: Clicks “Invite Friend” link, enters the name and email of the Potential Member, optionally edits the body and/or subject line of the email form, and then clicks the send button. The system, another actor in this case, returns the “Invite Friend” Form Interface, entry errors, confirmation of completion, saves the data entered by the Member, and deletes this data is it proves to be invalid.

U08a3 6 Jeannine Tyler

III.

Interface, Control, and Entity Classes

This table shows the Interface, Controller, and Entity classes. Not all the interfaces will be in the diagrams, as they are not dependent on the controller, but are still relative to the task of the Invite Friend Use Case. The Potential Member Information Handler (or Data Handler) routes the data and processes it for other departments, such as the Marketing Department. The entities, Member, Potential Member Name, and Potential Member Email, are used to create the classes.

Interface Member Profile Display

Controller Potential Member Information Handler

Entity Member

Promotional Email Display Invite Friend Display Invite Friend Form Error Display Invite Email Confirmation Display

Potential Member Name

Potential Member Email

U08a3 7 Jeannine Tyler

IV.

Summary of Invite Potential Member Use Case Behaviors

This table shows the behaviors of the Invite Friends part of the subsystem. The behaviors are listed as either Manual or Automated, and the Automated behaviors are given a class type, either Interface, Entity, or Control. The behaviors are used to create the attributes of the class diagram.

Behaviors Navigates to Profile or promotional email Clicks „Invite Friend‟ link Enters Potential Member email Enters Potential Member name Clicks „Send‟ button to send email Optionally edits the subject or body of the email Returns Invite Friend Form Interface Returns invalid field message Returns screen confirmation of email sent Saves Potential Member email in Database Saves Potential Member name in Database Deletes Potential Member Information Receives returned bad email Sends email to Potential Member Records date email sent Records that the Member sent an Invite Compiles Invite Statistics for Marketing analysis Provides information to Member ID class for analysis Processes received Potential Member Information

Auto/Manual Manual Manual Manual Manual Manual Manual Automated Automated Automated Automated Automated Automated Automated Automated Automated Automated Automated Automated

Class Type

Interface Interface Interface Entity Entity Entity Entity Entity Entity Entity Entity Entity

Automated

Control

U08a3 8 Jeannine Tyler

V.

Entities with Assigned Behaviors and Responsibilities

This table shows the entities and their behaviors and responsibilities. These behaviors and responsibilities are used to create the attributes of the classes in the class diagram.

Entity

Member

Behaviors and Responsibilities Records that the Member sent an Invite Compiles Invite Statistics for Marketing analysis Saves Potential Member name in Database Deletes Potential Member name in Database Provides information to Member ID class for analysis Saves Potential Member email in Database

Potential Member Name

Potential Member Email Deletes Potential Member email in Database Receives returned bad email Sends email to Potential Member Records date email sent Provides information to Member ID class for analysis

U08a3 9 Jeannine Tyler

VI.

Sequence Diagram:

The Sequence Diagram shows the actions of the Member throughout the Use Case. Two interfaces are shown here, the Profile or Email interface, from which the link is clicked, and the Invite Potential Member (or Invite Friend) interface. The Controller, Process Potential Member Info (or Process PotMem Data) holds the business logic to carry out the task of moving the data to be compiled and reported. The Entities, PotMembEmail, PotMemName, and MemberID are also represented and the diagram shows the sequence in which their responsibilities are handled. The items “Edit email body/subject” and “invalid email, delete email, delete name” are not required actions.

U08a3 10 Jeannine Tyler

VII. State Machine Diagram:
The state machine diagram shows the state of the data collected as it moves from acquisition to compellation. The state diagram outlines the CRUD functionality. Create: Data is created when the email and name of the potential member is input by the Member,<actor>>. Data is also created when the information given proves to be valid and is saved to the system. Read: The Data is read by the system when the Member, <<actor>>, inputs information. The system reads the data and determines that there are no null fields. The system also determines if the email is in proper email format: char@domain.com(net, etc). The data is also read again by the system when the Member entity requests data from the Potential Member Email and the Potential Member Name entities. This information is requested by the controller. Update: Once the data goes to the Member entity, the existing compiled data is updated so that the data may be used in reports for various other departments, such as the Marketing department. Delete: Once data is accepted as valid by not being null and following proper email format, the information is stored as data. If at a later time the data proves to be invalid, specifically if the email is returned as an invalid or unreachable email address, then the data collected by the input of the Member, <<actor>>, is deleted as it is unusable.

U08a3 11 Jeannine Tyler

U08a3 12 Jeannine Tyler

VIII. Class Diagram:
The class diagram shows the entities Member, Premium Member, Potential Member Email, and Potential Member Name with their attributes and method with their visibility shown to indicate public or private access. Information from Member to Potential Member Email is shown to only go one direction and this navigability is indicated by the arrow in the box connected to the Potential Member Email class box. The controller, the Potential Member Data Handler processes the data collected by the Member entity. Three interfaces are shown to depend upon the Data Handler: Invite Friend Interface, Promotional Email Interface, and the Member Profile Interface. The Premium Member class is a subclass of the Member superclass. In the majority of the diagrams, the Premium Member does not specifically do anything different from the Member class, and in fact „Member‟ and „Premium Member‟ is interchangeable in most cases, as there is no difference in how they invite potential members.

U08a3 13 Jeannine Tyler

U08a3 14 Jeannine Tyler References: Deitel, H.M, P.J. (2005). Visual Basic 2005 How to Program. Pearson Prentice Hall. Upper Saddle River, New Jersey. http://livejournal.com (2008). Retrieved on February 10, 2008.


				
DOCUMENT INFO
Description: College document, essay, form, or assignment from an Information Technology class.