Please see attachment for Assignment. and supporting files.

Also please see link for supporting information 

https://www.uml-diagrams.org/examples/online-shopping-domain-uml-diagram-example.html   

SampleITOT Case Study Class Diagram Page 1

Sample UML Class Diagram for Instructor,
Course, and Expertise Areas Classes

The diagram below was created with a CASE tool and shows a
portion of the class diagram for the ITOT Case Study.

This class diagram
includes the classes Instructor, Course, and ExpertiseArea with their
attributes, operations, and relationships with multiplicity constraints. There
are notes for the Class Diagram and the CASE tool.

1. Sample Class Diagram

Sample ITOT Case Study Class Diagram Page 2

2. Class Diagram Notes

This diagram represents the classes Instructor, Course, and Expertise Areas and their
relationships (associations) to each other. Attributes, operations, as well as relationships with
multiplicity constraints are represented. The details are deduced from the ITOT Requirement
Specification.

Classes and Relationships

1. Instructor and Course Relationship

An Instructor teaches 0..* Course(s).

Each Course is taught by exactly 1 Instructor

(Business rules may be applied to the relationships. Instructors may or may not be
teaching at a given time. Courses are taught by only one Instructor.)

2. Course and Course (reflexive) Relationship

Each Course may have 0..* prerequisite Course(s)

Each Course may be a prerequisite for 0..* Course(s)

(This is an example of a recursive relationship of a class to itself.)

3. Instructor and ExpertiseArea Relationship

An Instructor is qualified in 1..* ExpertiseArea(s).

Each ExpertiseArea is a qualification for 0..* Instructor(s).

(Since all Instructors have teaching areas of expertise and there are many areas, it was
decided to make ExpertiseArea into a class rather than an attribute of Instructor. Then we
can use a relationship to connect Instructor to ExpertiseArea. )

Sample ITOT Case Study Class Diagram Page 3

3. CASE Tool Notes

Much of this diagram is automatically generated by the CASE tool. For example when you start
to add attributes, you can right click on the class and select the option to Add attributes with
Getter and Setter methods. All of the getter/setter method entries will be automatically generated.
The getter methods make the values of the attributes available to other classes. The setter
methods allow the values of attributes to be changed.

The first method listed is called a Constructor which will create a new instance of the class. This
is also automatically generated by right clicking on the class and selecting the option to add
constructor. You can also add parameters (attributes) to the Constructor so that a complete
Constructor is created and it will include all attributes.

Changes to each class can be made directly through the Specification dialog box. Just right click
on the class or relationship and choose the Open Specification option. You can also change the
listing order of the attributes or operations by selecting the item and using the arrows to move it
up or down, then click apply, and OK in the Specification dialog box.

1. Sample Class Diagram
2. Class Diagram Notes
3. CASE Tool Notes

Lesson2 How to Create a State Diagram

OnlineOrder Class
An online Order might be in the states Order
Placed, Processing, Shipped, Ready for pickup, Picked up

PizzaOrder Class
A pizza order might be in the states of Building, Assembling,
Baking, Quality Checking, Delivering, Delivered

Bank Class
A bank might be “solvent” or “insolvent”

StudentApplication Class
A student application might be “pending”, “approved”,
“rejected”

A CheckingAccount is an account
offered as a service at a bank
Preliminary attributes are listed as
private (-) to the class and this
means that only the methods of the
class can access them
Preliminary data types (character,
float) listed for the class may be
changed later
Preliminary methods listed are
public (+) and can be accessed by
other classes
Standard getter/setter
(accessor/mutator) methods are not
shown. These methods get or
change attributes and are assumed
at this point

class CheckingAccount Draft Class

CheckingAccount

– accountNumber: char
– accountT ype: char
– accountStatus: char
– balance: float
– date

Opened

– dateClosed

+ Create()
+ deposit(amount: float)
+ withdraw(amount: float)
+ close(): refund
+

delete()

1. Select the classes that will require a state diagram. These classes should be ones that
have complex behavior. Not all classes will require a state diagram.

Start with CheckingAccount

2. Identify the status conditions for each state. You can review other project documents,
search for related class states, brainstorm, or use other techniques. Consider how the
object is created and how it ceases to exist. Is it in an active or passive state, open or
closed, pending, in preparation, scheduled, delivered, or other states.

For our CheckingAccount class, we identify the possible states as New, Open, Closed,
Overdrawn

3. Identify the transitions that will cause the object to go to another state. Build the
state diagram by starting with one of the states and identifying the transitions that will
cause the object to go to another state.

See the state analysis table

4. Start building the state diagram and filling in the transitions and states. Make certain
that they are in the correct order.

5. Look for independent, concurrent paths. An object may be in two states
concurrently and it may be that the paths are independent and can change
without affecting each other. Also look for states that are a composite state with
one state inside another.

6. Identify any additional transitions. It may take several iterations to complete
a state diagram.

7. Fully specify the transition to include message events, guard condition, or
action expressions.

8. Review and test.

Use desk checking to test
Are these really states for CheckingAccount?
Is there a life cycle from Start to Final state?
Are exceptions handled?
Is there concurrent behavior or nested paths?

State Event Causing a Transition Out Resulting New State/Comment

Start Create() New

New deposit(amount) [amount >= 1]/increaseBalance Opened (The bank business rules require
that a new account needs to have a
minimum balance of $1 in order to be
opened.)

Opened deposit(amount/increaseBalance Opened (Any deposits result in staying in
the Opened state)

Opened withdraw(amount) [amount <= balance] decreaseBalance Opened (Withdrawals can be made only if the balance exceeds the withdrawal)

Opened withdraw(amount) )[amount >= balance] decreaseBalance

Overdrawn (Withdrawals exceeding the
balance result in the account changing to
Overdrawn)

Overdrawn deposit(amount) [amount < balance]/increaseBalance

Overdrawn (Account remains in the
Overdrawn state while the amount
deposited is less than the balance)

Overdrawn

deposit(amount) [amount > balance]/increaseBalance

Opened (Account changes to opened
when a positive balance is achieved)

Opened close/refund Closed (request is to close account)

Closed delete Final (account is deleted)

stm CheckingAccount Draft State Diagram

Initial

New

Opened

Ov erdraw n

closed

Final

withdraw(amount) [amount>balance]
/decreaseBalance

deposit(amount)
/increaseBalance

deposit(amount) [amount>=balance]
/increaseBalance

close /refund

create()

withdraw(amount) [amount <= blanace] /decreaseBalance

deposit(amount) [amount >= 1]
/increaseBalance

delete()

State diagrams are created for classes with important
or complex behavior
Follow steps for creating a state diagram including:
selecting classes, identifying states, identifying
transitions that will cause object to advance to the
next state, start building the state diagram while
checking the order, look for independent concurrent
paths, identify additional transitions, add details to
include message events, guard condition, or action
expressions, review and test.

• ENTD321 Object Oriented Programming and UML
• Example States of Classes
• CheckingAccount Class Draft Diagram
• Step 1 for Creating State Diagrams�
• Steps for Creating State Diagrams cont’d
• CheckingAccount State Analysis
• Draft CheckingAccount State Diagram
• Summary

Running head: A REVIEW OF THE IT ONLINE TRAINING 1

A REVIEW OF THE IT ONLINE TRAINING 14

A Review of the IT Online Training Project Requirements

Name

Institutional Affiliation

A Review of the IT Online Training Project Requirements

1. Introduction

IT Online Training, which is here-in abbreviated as ITOT is an online service offering IT training via the internet. The training is web based; however, the online application will have different user interfaces and designs for web services and applets. The rationale of establishing the online application is to train clients through the internet because of enhanced connectivity and increased time confidence in internet services. Furthermore, clients in the current society have tight schedules that affect attendance in centralized training sites. Therefore, the web-based application enables a decentralized training in IT courses in the comfort of the client’s house or office. Among the IT courses that will be offered include customer management, course management, learning management system access, scheduling, purchasing through an online shopping cart; user account management, and payment management.

1.1 Problem Description

Learning is a continuous process in individual’s life due to technical, procedural, and societal changes that individuals have to cope with. As such, some previously learnt knowledge may be obsolete hence the need for new knowledge. Due to this, the young and the aged enroll in learning institution’s that suit their lifestyle. For example, the employed proffer evening classes in order to maintain their source of income while the unemployed prefer day classes. Despite these arrangements, there are challenges that face learners after enrolling among them include inconvenience due to the long distance from the learning institutions to their homes, unsuitable time schedules particularly if they have job of family commitments and high indirect expenses such as transport cost.

Due to these challenges engaging in online training offers solutions because of the convenience of the training. Among the conveniences, include training at learner’s own time schedule, choosing a suitable training module among the available options and reduced expenses. In cognizance of the advantages of online training, ITOT project will offer online training services in information technology to various clients. The clients will choose between the different training modules that include self-paced courses, scheduled courses, and using different training products such as books and videos. Due to the importance of the application, it is important that stakeholders are familiar with it. Among the stakeholders are customers, instructors, course administrators, schedule administrators, and other administrators, who must have knowledge and access to the functions of the application.

1.2 Sponsor Project Description

The project is online based; the training will include educating clients on the various functions of the application and engage in the real IT training. However, prior to full enrolment in the online service, the clients must be familiar on how to use the system. Therefore, the project has two main functions at this stage, the first function in educating stakeholders on the functional requirements such as how to purchase the ITOT products online, how to create and maintain customer account and how to maintain course schedules among others. The second role of the project is meeting the non-functional requirements, which means the application must be scalable such that it can maintain the increasing number of user accounts, it should be secure in terms of reducing security threats such as cross site scripting and injection among others.

1.3 Sponsor Requirements

The sponsors of the project have identified some preliminary requirements of the system as documented below. The following are some initial requirements of the application.

Functional Requirements

1. Purchase ITOT Products

REQF1.1

Customer

s must be able to purchase ITOT Products via an online shopping cart.

REQF1.2 The Customer must be able to add and remove products from an online shopping cart.

REQF1.3 Customers must be able to cancel orders.

REQF1.4 Customers must be able to purchase by credit card.

REQF1.5 System must provide certificates of completion for customers.

2. Maintain Customer information

REQF2.1

Customers must be able to create and change customer account , which holds information about the Customer including customer id, first and last name, address, phone numbers for work and cell phone. Customer id is issued by the system and cannot be changed by the customer.

REQF2.2 The system must be able to store and maintain customer credit card information for each credit card including account number, account name, expiration date, and security code.

REQF2.3 The system must maintain a list of accounts in its central database.

REQF2.4 The system must be able to search and display customer information by instructors, course administrators, schedule administrators, and other administrators.

3. Maintain Products

REQF3.1

The system must be able to create, modify, and delete ITOT Products including scheduled courses, self-paced courses, videos, and books.

REQF3.2 The system must be able to maintain course information including course number, course title, course description, course type, course duration, course start date, course end date, course prerequisites, CEU credits, and course fee.

REQF3.3 The system must be able to maintain video information including video id, video name, and video fee.

REQF3.4 The system must be able to maintain book information including title, authors, date, edition, and ISBN.

REQF3.5 The system must maintain course history including offering dates (beginning and ending), number of students enrolled, and instructor.

REQF3.6 The system must provide search capability for courses based on title, category, popular course, recent releases, planned courses.

REQF3.7 The system must provide access to all course maintenance features to the Course Administrator.

4. Maintain Instructor Information

REQF4.1 The system must maintain Instructor information including instructor id, instructor first and last name, address, cell and home phone, areas of teaching expertise, bio, and stipend.

REQF4.2 The system must be able to provide reports of instructor schedules and courses taught

5. Maintain Course Schedules

REQF5.1 The system must be able to create, modify, and delete course schedule information in its central database including course title, course number, course description, course prerequisites, course type, length of course, course outline, schedule dates, and instructor information.

REQF5.2 The system must be able to query course schedules and display results for all users based on keyword, title, and schedule.

REQF5.3 The system must provide all course schedule maintenance features to the Course Schedule Administrator.

6. Manage Shopping Cart

REQF6.1 The system must be able to provide a shopping cart feature for customers to select and pay for courses.

REQF6.2 The system must provide a Shopping Cart Item, which lists each item in the Shopping Cart including quantity, item number, item name, cost, shipping, coupons, discount, and total.

REQF6.3 The system must be able to provide customers with the ability to update the shopping cart including increasing the number of items, removing items, calculating shipping costs, and applying coupons and discounts.

REQF6.4 The system must be able to provide payment options for the customer including credit cards.

7. Access Credit Card Service

REQF7.1 The system must be able to link to an external Credit Card Service.

8. Access the Accounting System

REQF8.1 The system must provide a link to the Accounting System for the transfer of customer payment information.

9. Provide

User

Management

REQF9.1

The system must provide management of User with user name and password for all users of the system including customers and employees. Users can login and logout of the system.

REQF9.2 The system must implement a password policy that includes strong passwords including 8-15 symbols including letters (at least one upper case), digits, and special symbols like “!”.

REQF9.3 The system must maintain password history and not allow the reuse of the last three passwords

REQF9.4 The system must encrypt passwords.

Non-Functional Requirements

1. Design a Scalable Architecture

REQNF1.1 The training application must be capable of maintaining customer accounts for up to 100,000 customer accounts during the first six months and 1,000,000 after six months.

REQNF1.2 The training application must be capable of servicing up to 1,000 simultaneous customers initially and up to 10,000 after six months.

REQNF1.3 The training application must be capable of handling 100 search requests per minute and up to 1,000 search requests after six months.

REQNF1.4 The training application must be capable of handling up to 100 purchases per hour and 1,000 after six months.

2. Implement Security

REQNF2.1 The system shall implement the industry standard security features, including PCI compliance, for using secure web pages for all sensitive transactions including account, password, and payment management.

REQNF2.2 The system shall provide protection from the common web security threats including Injection, Weak Authentication and session management; cross site scripting (XSS); Insecure Direct Object References; Security Misconfiguration; Sensitive Data Exposure; Missing Function Level Access control; Cross Site Request Forgery; Using Components with Known Vulnerabilities. Invalidated Redirects and Forwards; price manipulation through hidden fields or cookies; buffer overflow and other security risks detailed in OWASP Top Ten at https://www.owasp.org/index.php/Main_Page

4.3. List of Classes with Definitions, Attributes, and Operations

The following are the list of classes that would be included in the project.

Class

Name

Class Definition

Attributes

Operations

Requirement

Number

Customer

A Customer is a person or organization where an Account exists for the purpose of accessing ITOT products.

customerID: string

firstName: string

lastName: string

address: string

workPhone:string

cellPhone: string

createCustomer()

getCustomerID()

setCustomerID(customerID)

getFirstName()

setFirstName(firstName)

getAddress()

setAddress(address)

getWorkPhone()

setWorkPhone(workPhone)

getCellPhone()

setCellPhone(cellPhone)

removeCustomer(customerI

REQF2.1

Book

A book is a product providing

written instruction on a topic and is available in printed or digital format.

BookNumber: string

title: string

description: string

type: string

prerequisites: string

fee: number

createbook()

getbooktNumber()

setbookNumber(courseNumber)

getTitle()

setTitle(title)

getDescription()

setDescription(description)

getType()

setType(type)

getPrerequisites()

setPrerequisites(prrequisites)

getFee()

setFee(fee)

Removebook(bookNumber)

REQF3.1

Product

A product is an offering that ITOT makes available for Customers to purchase.

productNumber: string

title: string
description: string
type: string
prerequisites: string
fee: number

createproduct()

getproductNumber()

setproductNumber(courseNumber)

getTitle()
setTitle(title)
getDescription()
setDescription(description)
getType()
setType(type)
getPrerequisites()
setPrerequisites(prrequisites)
getFee()
setFee(fee)

Removeproduct(productNumber)

REQF3.1

Scheduled Course

A Scheduled Course is a course offered by ITOT at a specific date and time.

courseNumber: string

title: string
description: string
type: string

duration: number

startDate: string

endDate: string

prerequisites: string

ceuCredits: number

fee: number

createScheduledCourse()

getCourseNumber()

setCourseNumber(courseNumber)

getTitle()
setTitle(title)
getDescription()
setDescription(description)
getType()
setType(type)

getDuration()

setDuration(duration)

getStartDate()

setStartDate(startDate)

getEndDate()

setEndDate(endDate)

getPrerequisites()
setPrerequisites(prrequisites)

getCeuCredits()
setCeuCredits(ceuCredits)

getFee()
setFee(fee)

RemoveScheduledCourse(courseNumber)

REQF3.1

Self-paced Course

A self-pacedCourse is

course that a customer can take at their own pace but has a time limit on the number of weeks the customer can take it

courseNumber: string
title: string
description: string
type: string
duration: number
startDate: string
endDate: string
prerequisites: string
ceuCredits: number
fee: number

create self-pacedCourse()

getCourseNumber()
setCourseNumber(courseNumber)
getTitle()
setTitle(title)
getDescription()
setDescription(description)
getType()
setType(type)
getDuration()
setDuration(duration)
getStartDate()
setStartDate(startDate)
getEndDate()
setEndDate(endDate)
getPrerequisites()

setPrerequisites(prequisites)

getCeuCredits()
setCeuCredits(ceuCredits)
getFee()
setFee(fee)

Removeself-pacedCourse(courseNumber)

REQF3.1

User

A User is a person who has credentials to access the ITOT system

username:string

password: string

login(username, password)

logout()

getUsername()

setUsername(username)

REQF9.1

…

…

…

…

…

4.3.1 List of Classes, Attributes, Operations and Requirement Number Discussion

Book

Book is one of the classes; it is a product providing written instruction on a topic and is available in printed or digital format. Clients should be able to access the books for purposes of reference during the training. As one of the products, the system must be able to create, modify, and delete ITOT products. The system must also be able to maintain book information including title, authors, date, edition, and ISBN. As such, the operations enable the system to get the title, the description of the book in terms author, publisher, and ISBN.

Product

A product is an offering that ITOT makes available for customers to purchase. Clients should be able to access the available products and decide on which ones suit them. The system must be able to create, modify, and delete ITOT products including scheduled courses, self-paced courses, videos, and books. Therefore, the identified operations helps the user to access the products, it also helps the administrator to make changes to the products in case there is need.

Scheduled Course

A scheduled course is a course offered by ITOT at a specific date and time. It is one of the products of ITOT. The system must be able to maintain course information including course number, course title, course description, course type, course duration, course start date, course end date, course prerequisites, CEU credits, and course fee. The operations aim at achieving the objectives of the system in relation to maintaining course information.

Self-paced Course

A self-paced course is course that a customer can take at his or her own pace but has a time limit on the number of weeks the customer can take it. The operations;

create self-pacedCourse()
getCourseNumber()
setCourseNumber(courseNumber)
getTitle()
setTitle(title)
getDescription()
setDescription(description)
getType()
setType(type)
getDuration()
setDuration(duration)
getStartDate()
setStartDate(startDate)
getEndDate()
setEndDate(endDate)
getPrerequisites()
setPrerequisites(prequisites)
getCeuCredits()
setCeuCredits(ceuCredits)
getFee()
setFee(fee)
Removeself-pacedCourse(courseNumber)

The above operations enable the system to maintain course information including course number, course title, course description, course type, course duration, course start date, course end date, course prerequisites, CEU credits, and course fee.

IT Online Training (ITOT) Analysis Specification

with the word “Insert” or “Provide” are explanatory and should be removed from your document after you follow the directions. Other symbols <> require you to insert names.

This document is intended to provide a partial analysis specification for the project case study, IT Online Training. This document includes an introduction, use case diagrams, detailed use cases, activity diagrams, domain class diagrams, and domain state diagram. Parts of this specification will come from the IT Online Training Specification and from your assignments. This document integrates some of the analysis diagrams and project specification details to provide a single reference. Headings are used to provide easier navigation. To see the heading navigation, in Word click on the View tab and check the Navigation Pane box.

You will submit this document for each assignment with new sections completed and added to it. You can revise any previous sections as needed. Remember to insert you name and class information at the top of this document.>

1. Introduction

1.1 Problem Description

1.2 Sponsor Project Description

1.3 Sponsor Requirements

2.

System Use Case Diagram

2.1 System Use Case Diagram

Customer

”.>

2.2 Use Case Diagram Description

2.3 List of Actors and Definitions

“An actorName is a

…

”.

Then add additional details as necessary. Use the following table format.>

Actor Name	Definition
	Customer	A Customer is a person who purchases ITOT products.
	…

2.4 List of Use Cases and Description

…

Use Case Name	Description
Create Customer	This use case creates a new Customer including customer id, first and last name, address, phone numbers for work and cell phone.

3. Detailed Use Case and Activity Diagram

3.1. Use Case

above with the actual name of your use case Manage Shopping Cart Use Case. For example it might read Manage Shopping Cart Use Case.>

3.1.1. Use Case Description/Scenario

above with the actual name of your use case, for example, Manage Shopping Cart Use Case Description/Scenario. In this section insert a description/scenario for this use case.>

3.1.2 Use Case Detailed Steps

.

Use Case and History

Use Case ID:	Use Case Name: Manage Shopping Cart
Created By:	Date Created:	Last Updated By:	Date Last Updated:

Actors, Description, Preconditions, Postconditions

Actors:

Description:

Preconditions:

Postconditions:

Normal Path

	User Action		System Action
1. This use case begins when….(you need to complete the sentence)	2.

Alternative Path

User Action

System Action

Use Case Related System Issues

Exceptions:

I

ncludes:

Priority:

Frequency of Use:

Business Rules:

Special Requirements:

Assumptions:

Notes and Issues:

3.1.3 Form/Screen Mockup and Dialog

above with the actual name of your use case like Manage Shopping Cart so that it reads Manage Shopping Cart Form/Screen Mockup.

Provide a mockup (image) of whatever forms/screens that are used to illustrate the activities in your use case. Include a description of your forms/screens. These should support and illustrate your use case. For example for a Create Customer use case, a Create Customer screen with customer id, first and last name, address, phone numbers for work and cell phone boxes and a Submit Button would be an example of a form or web screen.

Include a discussion of the form including its content (data elements) and how they will be used. Identify the classes has these attributes. Include a dialog (step by step instructions on what happens when this form is used. While these forms/screens will be used in the application, they are also used as a storyboard to explain the user interface to the sponsors of the project. These can be used to create and verify the steps of your detailed use case. >

3.1.4 Activity Diagram Name for Use Case and Discussion

”

above with the actual name of your use case like Manage Shopping Cart. For example, Activity Diagram for Use Case Manage Shopping Cart. Insert the following:

1. An activity diagram for your use case

2. A discussion of the activity diagram.

Remember that the detailed use case steps should be reflected in your activity diagram.>

4. Domain Class Diagram

4.1 Domain Class Diagram(s)

< Insert your Domain Class Diagram here. Remember that classes are named with nouns or noun phrases. A domain class diagram includes classes with attributes and operations for each class and named relationships with multiplicity constraints. Associations need names. You do not need a name for generalization, aggregation, and composition relationships. You must have names for associations .

4.2 Class and Relationship Analysis

Class and Relationship Analysis
Class Name 1	Relationship with Multiplicity	Class Name 2
Instructor	An   Instructor teaches zero or more (0..*) Course A Course is taught by  a single (1) Instructor	Course

Then on the class diagram association between Instructor and Course you can name the association “teaches” and add the multiplicity constraints (1) near Instructor and (0..1) near Course.

4.3 List of Classes with Definitions, Attributes, and Operations

T Online Training

 Project Requirements 

2018

document. Remember that class names are nouns or noun phrases. To define a class, complete the phrase “A className is a …”. Additional information can then be added. Attributes are properties of a class like “customerID” and begin with a lowercase letter. Operations are actions that a class can perform and begin with a lower case letter followed by parentheses (). We can create a new instance of a class (Create), delete an instance of a class (remove), get ( read) values of the attribute, or set (change) values of the attribute. See the examples in the table below.

The examples below include all of the getter/setter methods for the attributes. You do not need to include them in this assignment, but for Assignment 2 when you create your class diagram, you can use the features of our CASE to so that the getter/setter methods will automatically be added

.

For now you can use a high level modify() and read() to represent the getter/setter methods.

Later In design these will be modified depending on the technology used. During analysis we want to be independent of technology as much as possible.>

Classes, Attributes, Operations, Requirement

Customer

…

…

…

…

Class Name	Class Definition	Attributes	Operations	Requirement Number
A Customer is a person or organization where an Account exists for the purpose of accessing ITOT products.	customerID: string firstName: string lastName: string address: string workPhone:string cellPhone: string	createCustomer() getCustomerID() setCustomerID(customerID) getFirstName() setFirstName(firstName) getAddress() setAddress(address) getWorkPhone() setWorkPhone(workPhone) getCellPhone() setCellPhone(cellPhone) removeCustomer(customerID)	REQF2.1
ScheduledCourse	A ScheduledCourse is a course offered by ITOT at a specific date and time.	courseNumber: string title: string description: string type: string duration: number startDate: string endDate: string prerequisites: string ceuCredits: number fee: number	createScheduledCourse() getCourseNumber() setCourseNumber(courseNumber) getTitle() setTitle(title) getDescription() setDescription(description) getType() setType(type) getDuration() setDuration(duration) getStartDate() setStartDate(startDate) getEndDate() setEndDate(endDate) getPrerequisites() setPrerequisites(prrequisites) getCeuCredits() setCeuCredits(ceuCredits) getFee() setFee(fee) RemoveScheduledCourse(courseNumber)	REQF3.1
User	A User is a person who has credentials to access the ITOT system	username:string password: string	login(username, password) logout() getUsername() setUsername(username)	REQF9.1
				…

4.3.1 List of Classes, Attributes, Operations, and Requirement Number Discussion

4.4 Domain Class Diagram Discussion

5. Domain State Diagram

5.1 State Diagram and Discussion

above with the name of the required class ShoppingCart State Diagram so that it reads like ShoppingCart State Diagram and Discussion. See the examples of state diagrams in the assignment. Complete the following:

1. Insert a state diagram for the class from your class diagram as indicated in the assignment.

2. Provide a brief discussion of your State Diagram.>

6. Sequence Diagrams

6.1 System Sequence Diagram (SSD) for Use Case and Description

above with the name of your detailed Use Case like Manage Shopping Cart so that it reads like System Sequence Diagram (SSD) for Manage Shopping Cart Use Case.

1. Insert a description of your SSD.

2. Insert a UML System Sequence Diagram (SSD) for your use case from Section 3 above. An SSD shows the actor and the System and the messages (including message name and parameters) required to implement the detailed use case description from Section 3. The SSD shows the inputs and outputs to/from the system for the use case.>

6.2 Detailed Sequence Diagram for Use Case and Discussion

above with the name of your use case like Manage Shopping Cart so that it reads like
Detailed Sequence Diagram for Manage Shopping Cart Use Case and Description
.

1. Insert a UML Detailed Sequence Diagram for your use case. A Detailed Sequence diagram shows the actor and instead of the System like in the SSD, it will show all of the objects (instances of classes) that are required to implement the use case. Your Class Diagram will be helpful here. The net messages should be the same as in your SSD above but you will have more detailed messages including message name and parameters among the different objects that are actually required to implement the use case. So now you will add objects across the top of your diagram and omit System. Include a discussion of your Detailed Sequence Diagram.>

2. Insert a discussion of your Detailed Sequence Diagram.

Appendix.

Analysis Specification 2018R2 Page 7