Design 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 ProposalFor<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 Diagram1.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 bei.

1. Design 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 ProposalFor<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

2. 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

3. 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 Diagram1.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

4. 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

5. be offline which would prevent all other actors from achieving
their desired results.
USE CASE DIAGRAM 1
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. 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.

7. · 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

8. 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

9. 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

10. 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.

11. 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

12. *
-End4
*
User communications to
delete an order and payment
entry
-End5
*
-End6
*
-End7
*
-End8
*
-End9
*
-End10
*
-End11

13. *
-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

14. «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

15. +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]

16. [guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]
[guard]

17. [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]

18. 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]

19. [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

20. 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]

21. [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

22. /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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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
*

29. -End10
*
-End11
*
-End12
*