CS377 UML Diagrams
thoson
damontholsoncs3771503a01ip4.docxDesign Implementation Proposal
Design Implementation Proposal
***Some of the Material in this paper has been repurposed from IT with Professor Stewart and CS455 with Professor Lemaster, and IT251 with Professor Noffsinger ***
CS377-1503-A-01 Software Design
Phase 1 Individual Project
Design Implementation Proposal
Damon Tholson
July 18th, 2015
Design Implementation Proposal
For
<Legacy Equipment Corporation>
Version 1.2 approved
Prepared by <Damon Tholson>
<Ethical Company Finder>
<July 21st, 2015,>
Revision History
|
Name |
Date |
Reason For Change(s) |
Version |
|
Damon Tholson |
July 18, 2015 |
Original Document |
1.0 |
|
Damon Tholson |
July 21, 2015 |
Phase Two Class Diagram Implementation |
1.1 |
|
|
|
|
1.2 |
|
|
|
|
1.3 |
|
|
|
|
1.4 |
Table of Contents Revision History 3 1.0 Project description 4 1.1 Use Case Diagram 6 Introduction 6 Use Case Model Actor Description and intended interactive role 6 Relationships between the actors and the use case 7 1.2 Use Cases 9 2.0 Class Diagram 13 3.0 Sequence and Collaboration Diagram 15 4.0 State Transition and Activity Diagram 16 5.0 Follow-Up Discussion on Use of Object-Oriented and Recap of Design Changes 19 References: 20
1.0 Project description
The Ethical Company Finder application will allow the US government to sell otherwise wasted byproducts of the chemical munitions process to companies which operate ethically and set a standard for honest business practices. Thiodiglycol is most commonly used as a common solvent in the paint and coatings industry however, it can also be used for more devious purposes (i.e., the reproduction of mustard gas) and a system is needed to identify industrial companies who will purchase and use the chemical in a safe and ethical manner. Therefore, in order to sell this chemical for a profit, a software service must be developed which will create a “whitelist” (list of allowed, rather than prohibited) companies which meet a given set of conditions set forth by the US government. Companies which meet the minimum criteria, to include such things as good credit, a reputation of honest business practices, and no lawsuits regarding company behavior within the past ten years, will be considered for the whitelist service. Once companies are whitelisted they will be allowed to bid on the chemical with the software service calculating factors such as quantity of selected product, cost and distance of shipping, location of the product destination, the required route for the product to reach the customers destination, and the price the customer is willing to pay to determine which company to sell the product to and how much to sell them.
1.1 Use Case Diagram
1.2 Introduction
Within every individual use case there are specified actors and roles which those actors play. In the following paper the names of those actors will be specified and a description of how they interact with the software service will be provided. It should be noted that only current customers are within scope with current customers being defined as those who already reside in a database of companies identified as ethical companies. It should also be noted that orders are not updateable meaning that once an order is created no further changes to that order are permitted Additionally, we will define the system and boundary box and define the use of the packages in requirements engineering.
1.3 Use Case Model Actor Description and intended interactive role
A use case is a description of specified interactions between a product and an actor that will result in an outcome desired by the actor (Weigers & Beatty, 2013). An actor is a representative of an individual or object from the outside of a product, who will interact with that product in a specified way to perform a use case. The human actors known as Corporate Customer, System Administrator, and Government Auditor will be interacting with the Ethical Company Finder product (ECF) by completing desired tasks utilizing the on screen user interface along with the provided peripherals of a keyboard and mouse. The following is a description of the roles these actors will play
· The Corporate Customer will use the ECF application in an attempt to purchase the product from the government.
· The Government Auditor will use the ECF application to ensure the Corporate Customer meets all of the criteria required to purchase the product from the government.
· The system manager will oversee the operation and will be ensure that all objectives of the project are met.
1.4 Relationships between the actors and the use case
The relationships between actors in a use case help to identify the functionality of the system and how the user will interact with the system. In a use case the actor has identified a desired result and to achieve that desired result the actor must perform the tasks outlined in the use case. Relationships between actors occurs when an actor is reliant upon another actor complete a given task before they can continue on with the completion of their assigned tasks or achieved their desired results. For example, a Corporate Customer may wish to purchase a government product and has completed all of the tasks necessary to do so however the Corporate Customer cannot achieve their desired result until the Government Auditor has approved the purchase. Additionally, when a System Administrator is performing updates or audits the system may be offline which would prevent all other actors from achieving their desired results.
1.5 Use Cases
Use Case ID: #: [UC001]
· Use Case: Login to create an order and payment entry
· User Story: Customer creates an order and then decides upon the payment method for that order. The manager then approves or denies the order based upon the availability of the product and the customers’ ability to pay
· Primary Actor(s): Customer, Manager
· Preconditions: Customer is logged in and verified as an approved vendor. Vendor is able to pay at the time of purchase and product is available for
· Post-conditions: Product is removed from system inventory and shipped to customer.
|
Flow of Events |
Actor |
System
|
|
|
1. Customer logs onto system 2. Customer verifies personal info 3. Customer places order 4. Customer updates order/adds item if necessary 6. Customer ends order 7. Customer pays with CC payment 8. Manager views order |
1.1 Create order 2.1 Display order 3.1 Add item 4.1 End order 6.1 Verify payment 7.1 End order 8.1 Log/view order |
Use Case ID: #: [UC002]
· Use Case: Application Access to view an order and payment entry
· User Story: The system shall allow vendors current and prior transactions
· Primary Actor(s): Customer
· Preconditions: User is logged onto system and granted privileges to access current and past transactions
· Post Conditions: User has verified current and past transactions
|
Flow of Events |
Actor |
System
|
|
|
1. Customer logs onto system 2. Customer verifies personal info 3. Customer views order
|
1.1 Creates an order 2.1 Verifies Customer input 3.1 Order is displayed
|
Use Case ID: #: [UC003]
· Use Case: User Communications to update an order and payment entry
· Primary Actor(s): Customer/Manager
· User Story: Company employee accesses applications across the network.
· Preconditions: User is logged on and has required credentials
· Post Conditions: Order is updated
|
Flow of Events |
Actor |
System
|
|
|
1. Manager logs onto system 2. Manager views Account 3. Manger updates payment entry type 4. Manager Exits account
|
1.1 Verify Credentials 1.2 Display Account 1.3 Update payment type
|
Use Case ID: #: [UC004]
· Use Case: User Communications to delete an order and payment entry
· Primary Actor(s): Customer/Manager
· User Story: Company employee accesses applications across the network.
· Preconditions: User is logged on and has required credentials.
|
Flow of Events |
Actor |
System
|
|
|
1. Manger logs onto system 2. Manager views Account 3. Manger deletes order or payment entry type 4. Manager Exits account
|
1.4 Verify Credentials 1.5 Display Account 1.6 Delete order or payment type
|
·
2.0 Class Diagram
The goals and objectives of the Accounts application will be achieved through the use of the Inheritance hierarchy principle of project design. Inheritance hierarchy is a concept in object oriented programming in which a new class is created by acquiring a parent class’s existing capabilities. For inheritance hierarchy to be effectively used the subclasses must all share at least one common attribute or method with their specified superclass.
The superclass for the inheritance hierarchy will be Accounts and the two subclasses will be PaymentAccount, SalesAccount, and SuppliesAccount each of which share an “is a” type of relation with the Accounts superclass because each is a type of account. Accounts superclass will also extend the functionality of the computeSales method functionality to each of the subclasses through the use of inheritance hierarchy. The subclasses will share a “has a” type of relationship with the superclass computeSales method because each subclass which is an object of the Accounts superclass with have a computeSales method but that method will be specialized according to the needs of the specific account. This methodology increases the robustness of the code because Common instance variables or attributes which are assigned or defined in a superclass are not affected by changes in a subclass.
A test class known as SalesApplication will be created to test the subclasses by instantiating the already created objects of the Accounts superclass (subclasses which extend the functionality of a superclass are considered objects of that superclass). The information contained within the methods will then be displayed using the viewAcccounts and modifyAccounts methods.
Class Diagram 1
3.0 Sequence and Collaboration Diagram
In addition to the use cases we have been asked to put together some sequence diagrams to give the customer a graphical representation of the logical processes throughout the new system. In the following sequence diagrams we will depict the actions of a user logging onto the system, accessing the applications residing on the host server, and communicating on the system through the use of email or instant message.
Figure 1 User Logon Use Case Sequence
Figure 2 Application Access Use Case Sequence
3.1. Collaboration Diagrams
Application Access Collaboration Diagram 1
Login Collaboration Diagram 1
4.0 State Transition and Activity Diagram
The following Activity diagram shows the activities involved when a user attempts to logon to the network. It also shows the activities that occur when a user who is unauthorized or has forgotten their username/password attempts to access the network.
User Login Activity Diagram 1
The following Application Access activity diagram assumes the user is logged in with valid credentials. It shows the activities that occur when a user attempt to access programs within the application which they are authorized to access. Additionally it shows the system response when a user attempts to access parts of the system which are beyond their level of access.
Application Access Activity Diagram 1
4.1 State Transition Diagrams
The following state transition diagram shows User Communications to update an order and payment entry
State Transition Diagram 1
The following state transition diagram shows user communications to delete an order and payment entry.
5.0 Follow-Up Discussion on Use of Object-Oriented and Recap of Design Changes
TBD
References:
Ambler, S. W. (2014). UML 2 Use Case Diagrams: An Agile Introduction. Retrieved from http://agilemodeling.com/artifacts/useCaseDiagram.htm
Wiegers K. and Beatty J. (2013). Software requirements 3 (3rd ed.). (chapter 1 – 4, pp. 3 – 73, chapter 7, pp. 119 – 142). Redmond, Washington: Microsoft Press.
-End1
Application access to view and order and payment entry
User Communications to update a payment entry
Customer
Government Auditor
*
-End2
*
Login to create an order and payment entry
-End3
*
-End4
*
User communications to delete an order and payment entry
-End5
*
-End6
*
-End7
*
-End8
*
-End9
*
-End10
*
-End11
*
-End12
*
Manager
-AccountID() : void
-get Account int AccountID() : void
-get creationDate Date() : int
-toString():() : string
+computeSales():() : void
-viewAccounts():() : Accounts
-modifyAccounts():() : Accounts
-AccountNumber : int
-creationDate : Date
Accounts
-paymentVerified()
+setpaymentType int () : long
+getpaymentType() : double
+computeSales():() : long
-paymentType : String
PaymentAccount
+Unit() : long
+setunitSold () : long
+getunitSold() : long
+setpricePerUnit() : long
+getpricePerUnit()
+computeSales():() : long
-unitSold : long
-pricePerUnit : long
SalesAccount
+computeSales() : long
+viewAccounts() : Accounts
+modifyAccounts() : Accounts
«interface»
Sales
+public static void main (String [] args)()
+totalSales() : string
SalesApplication
-AccountID() : void -get Account int AccountID() : void -get creationDate Date() : int -toString():() : string +computeSales():() : void -viewAccounts():() : Accounts -modifyAccounts():() : Accounts
-AccountNumber : int -creationDate : Date
Accounts
-paymentVerified() +setpaymentType int () : long +getpaymentType() : double +computeSales():() : long
-paymentType : String
PaymentAccount
+Unit() : long +setunitSold () : long +getunitSold() : long +setpricePerUnit() : long +getpricePerUnit() +computeSales():() : long
-unitSold : long -pricePerUnit : long
SalesAccount
+computeSales() : long +viewAccounts() : Accounts +modifyAccounts() : Accounts
«interface» Sales
+public static void main (String [] args)() +totalSales() : string
SalesApplication
User Interface
Application Server
User Logon Use Case
Sequence
User Logon
Access requested
SD User Authentication
Invalid User
Valid User
[guard]
PERM1
[User Has Access
�
�
�
�
�
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
ref
Access requested
Invalid User
User Logon Use Case Sequence
Valid User
[User Has Access
User Interface
Application Server
User Logon
SD User Authentication
PERM1
Application Server
Email Application
Application Access Use
Case Sequence
User Logon
Message is created
SD Application Access
Conf Message Sent
Comms Error
[guard]
PERM1
[User is Logged on
Message recipient
Message is Sent
Message Recieved
Comms Error
�
�
�
�
�
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
ref
Message is created
Conf Message Sent
Application Access Use Case Sequence
Comms Error
[User is Logged on
Application Server
Email Application
User Logon
SD Application Access
PERM1
Message recipient
Message is Sent
Message Recieved
Comms Error
User Input Feedback
Application access to view an
order and payment entry
collaboration diagram
User login Prompt
/SelectAccount
/ViewOrder
�
�
�
�
�
Text
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
ref
Text
User Input Feedback
Application access to view an order and payment entry collaboration diagram
/ViewOrder
User login Prompt
/SelectAccount
User Input Feedback
Login to create an order and
payment entry collaboration
diagram
User login Prompt
/Login
/User
Text
User Input Feedback
Login to create an order and payment entry collaboration diagram
/User
User login Prompt
/Login
User Login
Login is Valid
Login is Invalid
User enters system
Access is Denied
User attempts application access
Authentication is Valid
Login is Invalid
Results are Displayed
User Login
Statechart
Login is Valid
Login is Invalid
User enters system
Access is Denied
User attempts application access
Authentication is Valid
Login is Invalid
Results are Displayed
User attempts application access
Credentials are valid
User has insufficient privilege
User enters system
Access is Denied
User attempts application access
Dispatch the order
Confirm the order
Results are Displayed
[check if item is in
stock]
[No]
[Yes]
User attempts application access
Statechart
Credentials are valid
User has insufficient privilege
User enters system
Access is Denied
User attempts application access
Dispatch the order
Confirm the order
[Yes]
Results are Displayed
[check if item is in stock]
[No]
Checking
Do/check inventory
Dispatching
Do/package items
Items Delivered
Waiting
/Receive Order
A
l
l
i
t
e
m
s
i
n
S
t
o
c
k
Order Cancelled
i
t
e
m
s
N
o
t
i
n
S
t
o
c
k
Checking Do/check inventory
Dispatching Do/package items
Order Cancelled
items Not in Stock
Items Delivered
All items in Stock
Waiting
/Receive Order
User Login
Send Deletion Request
Order cancelled
Waiting
/Initialization
I
t
e
m
s
s
t
i
l
l
i
n
i
n
v
e
n
t
o
r
y
Cancellation Request Denied
i
t
e
m
s
D
e
l
i
v
e
r
y
i
n
p
r
o
g
r
e
s
s
User Login
Send Deletion Request
Cancellation Request Denied
items Delivery in progress
Order cancelled
Items still in inventory
Waiting
/Initialization
Application access to
view and order and payment
entry
User Communications to
update a payment entry
Customer
Government Auditor
Manager
Login to create an
order and payment entry
-End1
*
-End2
*
-End3
*
-End4
*
User communications to
delete an order and payment
entry
-End5
*
-End6
*
-End7
*
-End8
*
-End9
*
-End10
*
-End11
*
-End12
*
