systems analysis & design of dbay, an online market space ......systems analysis & design of...
TRANSCRIPT
Systems Analysis & Design of DBay, an Online Market Space for
Drexel University
Final Project
INFO 620
Spring 2015
Team Members:Sarah Caramanico, Justin Martin, Marie Martino
Final Report Table of Contents
Introduction ………………………………………………………………………………………pg. 3
CHAPTER 1: System Analysis………………………………………………………….………pg. 4
1. The Problem Statement
1.1 Context, Vision & Importance
1.2 Goal
1.3 Scope (IN/OUT)
2. Requirements ……………………………………………………………………....…pg. 5
2.1 Functional Requirements ……………………….…………………………pg. 5
2.2 Data Requirements ………………………………………………...………pg. 5
2.3 Business Rules and Logic ……………………………...…………………pg. 6
2.4 Non-Functional Requirements …………………….………………………pg. 6
2.5 Other Important Assumptions ……………………..………………………pg. 7
2.6 Investigation of Similar Systems ……………………...…………………...pg. 7
2.7 Requirements in Narrative Form
3. Use Case Model ………………………………………………………………....……pg. 11
3.1 Actors and Their Goals ……………………………………….……....……pg. 11
3.2 Use Case Diagram ………………………………………………........……pg.12
3.3 Use Cases Overview ………………………………………….……..........pg. 13
3.4 Use Case Descriptions by Group Members ………...……………....…..pg. 15
3.5 Discussion ……………………………………………………………...…..pg. 27
4. Class Model …………………....…………………………………………………...…pg.
4.1 TCM Table for Modeling Decisions ………………….………………....……pg.
4.2 Domain Model .…………………………………………………...……....……pg.
4.3 Selected Class definitions ………………………………………....…....……pg.
4.4 Selected Association definitions ………………………..……………....……pg.
4.5 Discussion …………………………………………………………..…....……pg.
CHAPTER 2: System Design ………………………………………………..…………….......…pg.
5. Sequence Diagrams …………………....…………………………………………...pg. 32
5.1 System Sequence Diagram by Group Member .……………...……......pg. 32
5.2 Sequence Diagrams by Group Member ………………….…………......pg. 36
5.3 Validation and Discussion of Sequence Diagrams …………………......pg. 39
6. Design Class Diagram …………………................................................................pg. 39
6.1 Design Class Diagram ………………………………...……………......pg. 40
6.2 Validation and Discussion …………………………….…………….......pg.
CHAPTER 3: Physical Design ………………………………………………………….…....……pg.
7. Data Model …………………....……………………………………………………….…pg.
7.1 Relational Database Schema .…………………………...…………….......pg.
CHAPTER 4: Evaluation of Analysis & Design …………………………..……………….......pg. 42
8. Evaluation …………………....………………………………………………………..pg. 42
8.1 Evaluation of Project ….……………………………………….……….......pg. 42
8.2 Evaluation of UML and Tool ………………………..………………….......pg. 44
References ………………………………………………………………………………….....…pg. 47
Appendix ……………………………………………………………………………………........pg. 48
9.1 Lessons Learned by Group Member ……………..………………......pg. 48
9.2 Team Work & Division of Labor ………………………...………….......pg. 50
9.3 Unsolved Problems ………………………………………………....…..pg. 50
Introduction
The following report contains information related to the construction and implementation of
DBay, a Drexel-specific online marketplace in which registered users can place classified ads
for goods and services. The pages that follow will make evident our conceptualization and
investigation of the proposed system, based first on the analysis of anticipated user needs,
system functionality, business rules, data logic, and other non-functional requirements. We
strove, throughout the composition and development of this project, to utilize and display the
majority of concepts and methods that we were exposed to during the course of INFO 620,
including but not limited to Larman’s theories of UML development and Song’s use case
template, as well as various methods of determining functionality in the context of system
development. We established parameters for system scope; outlined system and data
requirements; constructed business rules and logic; conducted a heuristic evaluation of a similar
site, ULoop; established a use case diagram and developed three primary use case scenarios,
as well as class and domain models; constructed sequence and system sequence diagrams for
our base use cases; built a data model outlining the specifics of each of our data; and
summarized and evaluated both the project as a whole and the UML specifically. Subsequently,
this document also shows how we interpreted the problem domain and strategically tried to
create software objects that work together to meet the goals of the system, using UML as our
tool, as well as considering any unmet problems within the system and how they might be
effectively handled.
Chapter 1: System Analysis
1. Problem Statement 1.1 Context, Vision, and Importance of the System Members of the DU community have expressed interest an online marketplace service for the Drexel community, namely students, who need an alternative way to locate affordable academic resources, services, and other items. By providing a way to connect Drexel buyers and sellers, this system can fulfill the demand for a trusted and local Drexel-sponsored classifieds service that supports vetted forms of electronic payment. 1.2 Goal The main goal is to provide a user-friendly and easily accessible online system where only members of the Drexel community--students, faculty, and staff-- can buy and sell items and services within the Drexel Community. The university will fully support the system and outside commercial vendors are prohibited from using the system and/or placing product advertisements on the DBay website. 1.3 Scope In-scope: This system will focus on DU members, item advertisements, digital payment information, communication between members, transaction ratings, provide images
Out-scope: This system will not handle conflict resolution, the handling of payment transactions, shipping of goods transactions, and liability for misrepresentation or criminal activity.
2. Requirements
2.1 Basic System Functional Requirements
● Allow users to create and manage an account/profile ● Authenticate user by Drexel email account and personal password ● Provide a platform to buy and sell items and services
○ Users can be both buyer and seller at any given moment, but can occupy only one role of a buyer or seller within a transaction
○ Offers a space to advertise items or services for sale by way of easy-to-use web forms
○ Link item advertisements to seller’s profile and other items for sale by seller
● Facilitate communication between DBay members by providing contact information sellers
○ Contact will come via anonymized or masked email address ● Offer a search function to find specific item and/or service ● Provide platform for transactions through use of Paypal, Venmo, and “Cash on
Delivery” ● System will backup data and archive old data (up to 6 months) ● Show order/selling (aka transaction) history of individual users in user account ● Allow users to provide rating of transaction (using star rating) ● Allows users to flag inappropriate advertisements
2.2 Data Requirements
Users: System will keep track of: user ID, name, email address, related ads, related transactions, verification status
Transactions: System will keep track of: transaction ID, users involved in the transaction by role, related ad, related payment information
Ads: System will keep track of: ad ID, sellerID, item title, category, description, expiration date, price, flag
Photos: System will keep track of: photo ID, related ad ID, title, size
Ratings: System will keep track of: rating ID, rating, related transID, related
memberProfileID 2.3 Business Rules and Logic
● The system will be a free service provided for users within the Drexel community (students, faculty, staff)
● DBay member must provide a Drexel University email address and pass a confirmation test (reply-to email) to participate
● DBay members must fill out the minimum required form fields to sign up for an account and/or post items/service advertisements
● DBay members can occupy the role of buyer, seller or both in any given time period
● DBay members can list up to 8 photos per advertisement ● Photos for advertisements may not exceed the size limit ● DBay members can have up to 25 advertisements running simultaneously ● Advertisements expire after 2 weeks from the date/time it was created; a DBay
member has the option to reactivate the advertisement within 30 days ● Advertisements have a minimum bid amount posted by the seller. Confirmed bids
must meet this minimum. ● DBay members ● Transaction ratings range from 1-5 stars ● DBay member can rate a transaction only once; they cannot rate their own
behavior in the transaction ● If a flagged DBay member posts inappropriate material or comments, the
member’s account will be reviewed according to DBay policies and, if warranted, blocked
2.4 Non-Functional Requirements ● System will be screen-based (Usability) ● Ads will have the option of being sorted according to price, location and type via
drop-down menus (Usability) ● User accounts are password-protected (Security) ● System is password-protected (Security) ● System will be backed up remotely on a daily basis (Security/Preservation) ● Performance should be stable and commensurate with Drexel’s resource usage
priority ● System will be operational 24/7, with exceptions for daily back-up and weekly
system maintenance (Operation) ● System operators have no legal liability regarding transactions. (Legal) ● System will be Web-based and accessible across all standard platforms. ● (Implementation/Usability) ● System will offer downloadable mobile app for iPhone and Android (Usability) ● Mobile option will be touch-screen (Usability)
2.5 Other Important Assumptions
● We assume DBay will be used by the Drexel community, primarily students ● DBay is web-based and accessible to users by common web browsers and/or
through mobile app, which will developed after non-mobile web service ● DBay will be coded in PHP and use mySQL as its underlying database ● Hardware requirements and storage space will need to be further researched ● DBay server will run in a secure virtual environment ● Server OS depends on Drexel preferred options and but will need to
accommodate common web application solution stacks (LAMP/WAMP or comparable)
● DBay server will use automated backups, scheduled to run daily ● DBay necessitates a small staff to develop and maintain it ● Development of product will be iterative, focusing first on application for
traditional display and then move into mobile display and, perhaps, a separate app
● Implementation time is currently estimated at 6-8 months from inception to first release
2.6 Investigations of Similar Systems
ULoop: Heuristic Evaluation
Problem
ID Heuristic
Violated Problem Location Problem Description Severity
1 Aesthetic and
minimalist
design
Entire interface There is an overload of information
on the main home page. Font size
and color varies across the page,
confusing the eyes. The login tab
is conveniently placed on the top
right corner. The university/college
search bar is also conveniently
located in top center of page.
Below this search bar, there is a
number of sections for various
types of articles. Sections include
campus life, sports, entertainment,
fashion, etc. All of these categories
seem to reach out to the target
audience. However, this display of
articles creates clutter and
confusion to the main purpose of
the site, which is to find
university/college specific
information.
1
2 Visibility of
system status
Main page There is a scrolling bar at the top of
the page that displays headlines of
articles, which directs user to
appropriate article. However, there
are no dates that are displayed for
any of the articles before clicking on
them, so user is unaware if
information is timely.
1
3 Help and
documentation
Main page/
contact us page
There is a FAQ link buried at the
bottom of the page. This provides
answers to a limited amount of
issues that may arise. There is no
specific “help” section. If there is
an issue, they advise the user to
email them a question form. There
3
is no indication when they typically
respond to issues.
4 Match
between
system and
the real world
Main page The interface has duplicated
information on the main page. This
does not provide a natural and
logical set up for the user.
2
5 Match
between
system and
the real world
Main page There is not a description of the
purpose of the company. The user
must dig through the “Frequently
Asked Questions” page to discover
the company goal. When looking at
the main page, the user may find it
difficult to determine if this is a site
that provides articles related to
college aged people, or provides a
service for college aged people.
2
6 User control
and freedom
For Sale tab In the “For Sale” section, the user
has to perform an item search.
They select what category they
would like to search and it brings
them to the results page. However,
on that same results page, there is
a link on the right of the page that
says “Continue Search.” It is not
clear to the user which section they
would need to use to continue their
item search.
3
7 Flexibility and
efficiency of
use
Housing/Jobs/For
Sale/Services
selection pages
Other buy/sell websites provide a
clearly indicated search function,
buy function, and sell function. This
site provides no clarity to support
these functions.
2
8 Consistency
and standards
Main page Information overload to the point of
complete confusion on this page.
The top selection bar has links to
categories: news, campus life,
sport, fashion, entertainment.
These links are a repeat of the
3
categories shown below this tool
bar.
9 Consistency
and standards
/ Visibility of
system status
Classifieds
Section
Again, in Classifieds, the user has
to perform an item search. They
select what category they would
like to search and it brings them to
the results page. However, on that
same results page, there is a link
on the right of the page that says
“Continue Search.” It is not clear to
the user which section they would
need to use to continue their item
search.
3
10 Recognition
rather than
recall
Entire interface The site is simple enough where it
provides clearly labeled functions
for each selection. The user does
not have to guess about what that
function does. However, it does
provide confusion when these
functions are duplicated.
2
11 Help users
recognize,
diagnose, and
recover from
errors
Entire listing
process
I went through a fake creation of a
listing. The directions were simple
to follow and provides clear
direction to navigate through the
post. I did not encounter any error
messages.
0
Presently, the public has many options that offer the service of buying and selling items through
an online marketplace. When the members of the Drexel community expressed an interest in
an online marketplace solely for Drexel University students, faculty, and staff, it was important to
research and reveal any existing systems with the same purpose.
Through our research, we discovered a website called ULoop.com. This website is a student
powered News and Classifieds marketplace for over 1500 colleges and universities. The site
allows college students with an “.edu” email address to buy, sell, promote and trade textbooks,
housing, roommates, jobs, tickets, apartments, and more (Uloop.com). We used this website
to perform a heuristic evaluation to compare it against accepted usability principles. Our results
helped us with the design and requirements that we wanted to include, and exclude, in our
system.
One of the biggest results of our ULoop evaluation was the overload of information on the main
homepage. Information was repeated in multiple sections of the page, which cluttered the
screen, affecting the aesthetic design, consistency and standards. This allowed us to imagine
our proposed system depicting a more simplistic design as opposed to ULoop. This would aid
in our goal of being user friendly.
Another result from our evaluation involved the task functions within each of the selection
pages. This site provided no clearly indicated search function, buy function, or sell function.
This created an issue within user control and freedom, as well as flexibility and efficiency of use.
It is important for DBay to display a search function for ease of use within the system,
regardless if the user is buying or selling an item.
Our group did appreciate the clearly labeled functions for each selection, such as housing, jobs,
for sale, services. This is an element we would include in the design of DBay. The listing
process within ULoop is also very simple and straightforward. If DBay were to replicate this
design, the program would satisfy the need to be user-friendly.
The heuristic evaluation allowed our team to see an existing system and compare it to our
visions of DBay. It helped us see aspects of design that worked for a system that dealt with
buying and selling items within a college or university market. The evaluation also uncovered
design issues within the ULoop system, and encouraged us to think creatively to achieve our
goals, business rules and requirements of DBay.
2.7 Requirements in Narrative Format
Drexel University would like to create a platform to offer a self-service, online market space for
its students, staff and faculty. Drexel provides, DBay, a self-service web platform for the
buying/selling of goods and services. DBay membership is restricted to Drexel University
students, faculty, and staff. In addition to some basic contact information, a Drexel U email
account is required to create a DBay account pass a confirmation test (reply-to email) to
participate.
DBay members can occupy the role of buyer, seller or both in any given time period. They can
use DBay to create item or service advertisements by filling out the minimum-required form
fields. They can also cancel any of their listings whenever they wish. DBay members provide
information to description of any given item (or service) and can upload up to 8 photos per
advertisement, but are not required to post any photos. Photos for advertisements may not
exceed the size limit of 500kb. DBay members can have up to 25 advertisements running
simultaneously. Advertisements expire after 2 weeks from the date/time it was created. DBay
members will receive an email notification that the ad is due to expire and have the option to
reactivate the advertisement within 30 days.
DBay members who are acting as buyers can search and browse ads. They can ask a seller a
question by using the masked email provided in the item ad. DBay facilitates, but does not
directly handle payment, purchases can be made using PayPal or Venmo. DBay will, however,
provide a confirmation of transaction.
DBay members can rate these transactions. Transaction ratings range from 1-5 stars. They can
rate a transaction only once; they cannot rate their own behavior in the transaction. Members
have profiles and can view others’ profiles to see the transaction ratings associated with the
DBay member.
Additionally, DBay members can flag ads they believe are inappropriate, according to a DBay
“code of conduct.” If a DBay member has posted inappropriate material or comments, the
member’s account will be reviewed according to DBay policies and, if warranted, blocked by a
system administrator.
3. Use Case Model
3.1 Actors and Their Goals
1. Registered DBay user (primary actor): A current Drexel student or faculty member who has
logged into the DBay web site and filled out the sign-up form – name, email address, password,
major and graduation year. The goal is to become a member of a trusted online marketplace
where Drexel students and faculty can conduct business with each other.
2. Secondary Payment Options (Venmo, PayPal, etc.) (secondary actor): An external agent that
handles and processes payments between buyer and seller.
3. DBay system (secondary actor): The system itself, which functions autonomously to verify
valid emails by way of detecting the presence of “drexel.edu” in the address and to notify users
of expiring ads according to date posted.
3.2 Use Case Diagram
3.3 Use Cases Overview
1. CreateProfile: A current Drexel student would like to join the closed, campus-wide online
auction/bartering site DBay. He or she visits the web site and clicks “Sign Up.” He or she is then
prompted for name, password, Drexel email address, major and graduation year. Upon filling
these in and clicking “Submit,” the system returns a confirmation screen and sends a
confirmation email to the Drexel email address that the user has entered.
2. AskSellerQuestion: A DBay user is browsing listings and sees one that is appealing, but he
or she requires further information from the seller. He or she clicks seller’s live link user name
(his or her Drexel prefix, e.g. jnm73). System returns anonymous form in which user can
question or otherwise contact seller.
3. CreateAd: A DBay user has a product or service that he or she wants to sell or provide. The
user logs into the DBay site and chooses the option for placing an ad. The system returns a
blank ad form, with space for a title, a description, and optional minimum bid and photos. The
user fills out the form to his or her specifications and submits the ad. The system returns visual
confirmation and also sends a confirmation email to the seller’s Drexel address.
4. SearchAds: A DBay user is in the market for a product or service. He or she logs onto the
DBay website and selects the Ads active breadcrumb. The system returns the main listings
page, which contains options for searching by category and a search box for manual input of the
desired item or service. The user can then search by category or term.
5. SubmitBid: A DBay user browses the site and finds an ad that is appealing. He or she either
clicks on the heading, if he or she is in the search screen, to bring up the full ad, or finds the bid
box on the ad and enters an amount that he or she is willing to pay for the product or service
advertised. He or she then clicks “Submit Bid” button, and the system prompts for confirmation.
He or she clicks the “Yes” or “No” button, depending on whether or not he or she wishes to
submit the bid. If “No” is clicked, the system returns to the ad. If “Yes” is clicked, the system
displays a bid confirmation screen and simultaneously sends the bidder an email confirming the
bid.
6. NotifyExpiringAd: Ads placed on DBay have a fourteen-day time limit before expiration, to
ease the server crunch and keep the site running at top speed. The system administrator has
access to the full log of ads at all times, and when the system indicates that an ad is two days
from expiration, an alert is posted. The DBay user can see this alert when he or she is logged
in, but the system administrator also sends a brief e-mail alert to the user notifying him or her
that the ad has two days left to run. The process is repeated for one day left and day of
expiration.
7. FlagAd: A DBay user is browsing listings and sees one that seems either too good to be true
(a scam), some sort of outright scam/phishing attempt, or, conceivably, one advertising illegal
services (drugs or prostitution.) He or she opens the ad link to view the full ad and clicks the
“Flag This Ad” button. The system flags the ad and sends an alert to the system administrator,
who reviews the ad and either removes the flag or deletes the ad.
8. ViewMemberProfile: A DBay user sees an ad that looks interesting and opens it. The system
returns the full ad listing, including the handle of the person that posted it. The user can click on
this handle, which is a live link that causes the system to display a Javascript popup window
displaying the seller’s basic profile, including previous listings and transaction ratings.
9. RateTransaction: A DBay member completes a transaction with a fellow user. The system,
after a period of a week to ensure completion of the transaction, prompts the users upon log-in
to rate each the transaction via a five-star system. The system also dispatches a reminder email
to both users. The system displays a Javascript pop-up window that contains the transaction
overview and five empty stars. The user clicks the appropriate number of stars and clicks
“Submit.” The system returns a thank-you message and stores the rating on the appropriate
user’s profile.
10. StoreDrexUMemberInfo: A Drexel student logs onto the DBay website and establishes an
account by filling out the sign-up form. The system retains this information on its servers,
allowing the user to log in upon returning to the site and have access to the full suite of features.
11. CancelAd: A DBay user has placed an ad, but has reconsidered his or her offer. He or she
logs into the DBay website and clicks on his or her profile. The system displays the user’s full
profile page, including any active ads. Alongside each active ad is a small “Cancel Ad” button.
The user clicks on the button, which returns a pop-up requesting confirmation of cancellation.
The user clicks the “Yes” button, and the system returns a confirmation of the cancellation and
removes the ad. (If the user clicks “No”, the pop-up disappears and the ad remains live.)
12. ReactivateAd: A DBay user’s posted ads are stored for a period of two weeks in the system,
in the event that the user wishes to reactivate the old ad. The user logs in and clicks on “Profile”.
The system returns the user’s profile page, including all current ads and recently expired ads.
The user clicks on an expired ad, and the system returns the full ad as posted, with a button at
the top reading “Reactivate This Ad?” The user clicks the button, and the system confirms that
the ad has been reactivated for the standard two-week term.
3.4 Use Case Descriptions by Group Members
3.4a JUSTIN MARTIN
USE CASE # BASE 1 – Justin Martin
USE CASE Name CreateProfile
ACTOR DBay User
Goal (1 phrase) To create a user profile for the DBay system.
Overview and scope System prompts user for information, including name,
Drexel email address, graduation year, major and
password. System completes profile if Drexel email
address is entered; otherwise, user is denied access.
Level Primary
Preconditions User logs onto DBay webpage.
Postconditions in
words (write in
passive and past
tense)
Profile object userProfile was created.
Attributes userProfile.firstname, userProfile.lastname,
userProfile.password, userProfile.emailAddress,
userProfile.gradYear, userProfile.major were updated.
Trigger Event is triggered when user selects “Sign Up” on DBay
webpage.
Included Use Cases EmailConfirmation
Extending Use
Cases
MAIN SUCCESSFUL
SCENARIO for this
Use Case in
numbered
sequence
Reference “included
use cases” in this
section using
INCLUDE ius_name
Actor Action System Action
1. User logs onto
DBay website
2. System displays main
page.
3. User clicks on
“Sign Up”
breadcrumb.
4. System prompts for
personal information.
5. User enters
personal information
and clicks “Sign Up”
button.
6. System displays e-mail
confirmation prompt.
OTHER
SUCCESSFUL
SCENARIOS
(Specify any
successful
variations of the
normal execution
path, including any
extension points
using
EXTEND eus_name)
1. User logs onto
DBay webpage.
2. System displays main
webpage.
3. User clicks on
“Sign Up”
breadcrumb.
4. System prompts for
personal information.
5. User enters
personal information
and clicks “Submit.”
5b. System detects that one
or more pieces of
information were not
entered.
6b. System returns “Please
enter Drexel email
address/graduation
year/major/password”
depending on information
omitted.
7b. User reenters
information and
clicks “Submit”.
8b. System returns
confirmation if information
is entered correctly.
OTHER
SUCCESSFUL
SCENARIOS
(Specify any
successful
variations of the
normal execution
path, including any
extension points
using
EXTEND eus_name)
UNSUCCESSFUL
SCENARIOS
(erroneous situations)
1. User logs onto DBay
webpage.
2. System displays main page.
3. User clicks
“Sign Up”
breadcrumb.
4. System prompts for personal
information.
5. User enters personal
information and clicks
“Submit.”
6b. System detects that user has
entered a non-Drexel email
address.
7b. System returns request for
Drexel email address.
Priority in
scheduling
Primary
Frequency Once per iteration
Business rules and
data logic
1. System does not take part in transactions; transactions
are conducted between users either via third-party
application (PayPal, Venmo, etc.) or other means.
2. System permits one profile per verified email address.
3. User information is password-protected.
Other non-
functional
requirements
Standard Windows web interface.
Database backed up daily.
Superordinates
Developer Sarah Caramanico, Justin Martin, Marie Martino
Creation date and
last modified date
5/26/15, 6/3/15
Other Comments
This use case is the one upon which, essentially, the whole system rides, since it is imperative
that one officially join DBay before being permitted to access virtually any of the system’s
functionality. The main goal of this use case is to establish a member profile.
In order to register as a DBay member, the user must be in possession of an active Drexel
email account, which indicates that he or she is a current member of the Drexel community.
The prospective user visits the DBay homepage and clicks the Sign Up breadcrumb at the top
of the page. This results in the system returning the sign up page, which contains boxes for the
user to enter name, password, Drexel email address, major and graduation date. This
represents all that the system requires to establish a profile and a means of communication with
the user, since all messages are sent via the Drexel portal. After the user has entered all of the
required information, he or she submits it to the system. The system, having parsed the basic
parameters - current student, active Drexel email address - then returns a page indicating that
the user’s membership has been accepted and his or profile has been created, along with an
alert stating that a confirmation email has been sent to the user’s Drexel email address.
3.4b SARAH CARAMANICO
Use Case # 3- Sarah Caramanico
Use Case Name SubmitBid
Actor Registered DBay User
Goal (1 phrase) To submit a bid on an Ad posted in the DBay
system
Overview and Scope After a user clicks on a listing to open and
view the full Ad screen, the system gives the
option to submit a bid. The user will enter
and submit an amount. Note, the bid is
based on a minimum amount, so the user
may not submit a bid lower than that set
amount. Once the user selects confirm, the
system will return a bid confirmation screen.
Level Primary
Frequency Once per iteration
Preconditions User logs onto DBay webpage
Postconditions Object newBid is created. Attributes
newBid.id, newBid.userName,
newBid.amount, newBid.bidId are updated.
Trigger Event is triggered when the user selects an
individual Ad.
Included Use Cases ConfirmBid, MakePayment
Extended Use Cases
Main Successful Scenario for this Use
Case in numbered sequence
Reference “included use cases” in
this section using INCLUDE ius_name
Actor Action System Action
Step 1. User logs
onto DBay website
Step 2. System
displays homepage
Step 3. User signs
into profile on DBay
website
Step 4. System
returns sign-in
homepage
Step 5. User clicks
“View Ad”
Step 6. The system
returns the Ad catalog
Step 7. User selects
individual Ad
Step 8. System
displays individual Ad
with bid information.
Step 9. User enters
an amount for a bid
and selects Submit
Step 10. System
prompts for a
confirmation
Step 11. User
confirms bid
Step 12. System
returns bid
confirmation screen
and redirects user to
payment source
UNSUCCESSFUL SCENARIOS
Actor Action
System Action
Step 1. User logs
onto DBay website
Step 2. System
displays homepage
Step 3. User signs
into profile on DBay
website
Step 4. System
returns sign-in
homepage
Step 5. User clicks
“View Ad”
Step 6. The system
returns the Ad catalog
Step 7. User selects
individual Ad
Step 8. System
displays individual Ad
with bid information.
Step 9. User enters
an amount for a bid
lower than the bid
minimum and
selects Submit
Step 10. System
prompts an error
message “Bid does
not meet minimum
requirements”
Priority in scheduling Primary
Frequency Once per request
Business rules and data logic 1. System does not
take part in
transactions;
transactions are
conducted between
users either via
third-party
application (PayPal,
Venmo, etc.)
3. System is password-protected 5. Performance should be stable and follow Drexel’s resource usage priority
2. Each ad has a
minimum bid amount
and user bid must
meet that minimum.
4. DBay members can
occupy the role of
buyer, seller or both in
any given time period.
Other non-functional requirements Standard Windows
web interface.
Database backed up
remotely daily.
Developer Sarah Caramanico,
Justin Martin, Marie
Martino
Creation date and last modified
date
May 28, 2015
This use case involves an important function within the DBay system: submitting a bid for a
posted Ad. As each DBay member can act as both a buyer and/or a seller at any given
moment, but may occupy only one role of a buyer or seller within a transaction. When a
member is a buyer role, they will purchase items via a bid.
A registered DBay user has the capability to place a bid on any active Ad of their choice. Once
a user opens the DBay website, they are first required to sign into their account. After the
system displays the user’s sign-in homepage, the user can select “View Ad.” This function will
result in the system displaying the Ad catalog. As the user looks through this catalog and
decides on an item they would like to bid on, the user selects that individual Ad. The system will
display the individual Ad with the bid information, including the minimum bid amount. The user
will enter and submit a bid amount. The system will then return a confirmation page prompt to
the user. When a user is satisfied with their bid, they will confirm the bid and the system will
return a confirmation page.
Because there is a minimum bid amount, there is the possibility of an unsuccessful scenario. In
this scenario, the user will go through the same steps of signing into their account and selecting
“View Ad.” The system will display the Ad catalog and the user will select an individual Ad.
When the user submits a bid that is less than the minimum bid amount, the system will prompt
an error message stating the bid did not meet the minimum requirements.
3.4c MARIE MARTINO
Group Member Marie Martino
USE CASE # BASE 3--verify after diagram is posted
USE CASE Name CreateAd
ACTOR Registered DBay User (DBay Member)
Goal (1 phrase) To Create an Advertisement for a Product or Service on DBay
Overview and scope The ad is an essential piece of the DBay system. A DBay Member creates ads to sell their wares. To do so, they must log-in, choose to create an ad, and supply the system with information about about what they are selling, including a ad title, system pre-determined category, and a description. These are required data fields. They have the option to create an ad with photos if they wish. The system must also be able to respond to user errors when entering information, such as not filling out all the required fields.
Level Primary
Preconditions DBay Member logs into DBay website
Postconditions in words (write in passive and past tense)
Object activeAd was created. Object activeAd was associated with object activeUser
Attributes activeAd.id, activeAd.sellerId, activeAd.title, activeAd.category, activeAd.description and activeAd.expDate were inserted/updated Ad data is saved Object activeAd was destroyed
Trigger Event is triggered when user clicks “Create DBay Ad” button.
Included Use Cases
Extending Use Cases UploadPhoto
MAIN SUCCESSFUL SCENARIO for this Use Case in numbered sequence Reference “included use cases” in this section using INCLUDE ius_name
Actor Action System Action
1. User logs onto DBay website.
2. System displays homepage.
3. User signs into DBay website.
4. System returns signed-in homepage.
5. User clicks “Create Ad.” 6. System returns blank ad form.
7. User enters all required information and clicks “Submit.”
8. System returns preliminary view of prepublication ad for review.
9. User reviews ad and, if acceptable, clicks “Submit.”
10. System displays ad confirmation screen, including approximate time of publication and makes ad available to viewing by other users.
OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name)
1. User logs onto DBay website.
2. System displays homepage
3. User signs into DBay website.
4. System returns signed-in homepage.
5b. EXTEND UploadPhotos: User clicks “Create Ad with Photos”
6b. System returns blank ad form.
7b. User enters required information.
8b. User clicks “Upload Photos.”
9b. System returns blank photo upload form.
10b. User selects photos and clicks “Add My Photos.”
11b. System returns preliminary view of prepublication ad with photos for review.
12b. User reviews ad and, if acceptable, clicks “Submit.”
13b. System displays confirmation screen, including approximate time of publication and makes ad available to viewing by other users.
OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name)
1. User logs onto DBay website.
2. System displays homepage.
3. User signs into DBay website.
4. System returns signed-in homepage.
5. User clicks “Create Ad.” 6. System returns blank ad form.
7c. User forgets to enter all required information and clicks “Submit.”
8c. System messages message “Please fill out all required fields.”
9c. User enters all required information and clicks “Submit.”
10c. System returns preliminary view of prepublication ad for review.
11c. User reviews ad and, if acceptable, clicks “Submit.”
12c. System displays confirmation screen, including approximate time of publication and makes ad available to viewing by other users.
OTHER SUCCESSFUL SCENARIOS (Specify any successful variations of the normal execution path, including any extension points using EXTEND eus_name)
1. User logs onto DBay website.
2. System displays homepage.
3. User signs into DBay website.
4. System returns signed-in homepage.
5. User clicks “Create Ad.” 6. System returns blank ad form.
7. User enters all required information and clicks “Submit.”
8. System returns preliminary view of prepublication ad for review.
9d. User reviews ad and finds a data field she wishes to edit and clicks “Edit.”
10d. System displays ad form screen and allows user to update data fields.
11d. User makes appropriate changes and clicks “Submit.”
12d. System displays confirmation screen, including approximate time of publication.
13d. User reviews ad and, if acceptable, clicks “Submit.”
14d. System displays confirmation screen, including approximate time of publication and makes ad available to viewing by other users.
UNSUCCESSFUL SCENARIOS (erroneous situations)
1. User logs onto DBay website.
2. System displays homepage.
3. User signs into DBay website.
4. System returns signed-in homepage.
5. User clicks “Create Ad.” 6. System returns blank ad form.
7. User forgets to enter all required information and clicks “Submit.”
8. System messages message “Please fill out all required fields.”
9. User does not enter any further information
10. System aborts the process after 10 minutes of inactivity.
Priority in scheduling High
Frequency Once per request
Business rules and data logic
1. DBay members can occupy the role of buyer, seller or both in any given time period. 2. They can use DBay to create item or service advertisements by filling out the minimum-required form fields. 3. They can also cancel any of their listings whenever they wish. 4. DBay members provide information to description of any given item (or service) and can upload up to 8 photos per advertisement, but are not required to post any photos. 5. Photos for advertisements may not exceed the size limit of 500kb. 6. DBay members can have up to 25 advertisements running simultaneously. 7. Advertisements expire after 2 weeks from the date/time it was created.
8. DBay members will receive an email notification that the ad is due to expire and have the option to reactivate the advertisement within 30 days. 9. Users are responsible for validity of listing claims. 10. Users are responsible for securing payment from buyers; system has no role in payment process. 11. User must be logged in to create an ad.
Other non-functional requirements
Listings will have the option of being sorted according to price, location and type via drop-down menus System is password-protected System will be backed up remotely on a daily basis Performance should be stable and commensurate with Drexel’s resource usage priority System will be Web-based and accessible across all standard platforms
Superordinates
Developer Sarah Caramanico, Justin Martin, Marie Martino
Creation date and last modified date
5/29/15
Other Comments
This use case focuses on one of the primary functions of the system for the user--creating an ad
for the item or service the user wishes to sell. This function is based on the requirements and
business rules as established early on in our process. In this use case, the main actor is the
DBay Member who interacts with the system. The main goal here is to create an ad. “Behind
the scenes,” the systems stores the necessary information about the ad so that other Members
can search for them via the Catalog, or place you can search ad listings. There are pre-
conditions and limitations related to this use case. The user must be logged in and must
choose to create an ad via the interface to start the process. There is a limit of 25 ads per user
at any given moment in time.
As one can see from the diagram and full use case description above, the CreateAd use case is
a base case with one extension--UploadPhotos, that is, to create an ad with photos attached. It
does not have any includes. The system allows for the main success scenario as well other
success scenarios. Because there is only 1 extension--to upload photos-- the other successful
scenarios show the user recovering from a data entry error.
Use cases play a key role in iterative development models because they can essentially
motivate the design of a system (Larman, p. 95). Part of the reason we initially thought a
heauristic evaluation of ULoop seemed like a good idea, was because it helped us get into the
mind of the user. Use cases are really about exploring the needs and goals of the user. That
all said, one should acknowledge that it has limitations, as all use cases do. As Larman stated,”
. . .models lie (unintentionally). Only code and tests reveal the truth of what’s really wanted and
works (p.78).” The use case for CreateAd clearly represents a main user goal and a means to
ensure its functionality is carried into further phases of development.
3.5 Discussion
To form our use cases, we relied on the the information we sussed out from the system goals
and system investigation. Once we established all of the system requirements, namely, the
functional requirements and business rules, we were able to focus on how users would use the
system. Understanding who is using the system as well as how they would be using it, become
the driving force for developing the use cases, the steps involved in those functions or
processes we previously identified. We asked ourselves questions like: “What functionality do
we wish to represent?” “How does the user interact with the system?” “How do uses cases
interact with each other?” We considered a few different models, but in each diagram and each
iteration, we identified CreatProfile, CreateAd, and SubmitBid as representative of the most
important requirements of the system. The remaining use cases were arranged in the model in
such a way that attempts to be the most strategically-placed, based on the relationships with
actors, the relationships among the other use cases and the functionality each use case
represents.
One alternative version included the SysAdmin as an actor, but we realized the functionality we
had linked to the SysAdmin could be replaced by the system itself with regard to automated
email verifications and expiration notices. Nevertheless, that model is still plausible, but we
deemed the presence of that actor superfluous for our purposes here.
4. Class Model
4.1 TCM Table for Modeling Decisions
Noun Elimination Note
Applicable
Modeling Rule
Possible
Atrribues
Drexel U irrelevant - -
DBay plaform/self-servie
marketplace (sys) irrelevant - -
goods/servivces redundant - -
item attrbiute contained in ads - -
students faculty staff (use
DBayMember) needs unique id, has
attributes
name, email,
phone, pw,
verified?, id
memebership redundant - -
contact info
can be broken into
attributes of
DBayMember - -
email confirmation test
(verification)
is this same as other
email confirmation?
no, more extended
functionality--email is
only only part of
larger process
role - -
buyer (transofrm to activity or
subclass?)
think this is more of an
association than a role,
coule be an attribute in a
transaction
seller (transofrm to activity or
subclass?)
think this is more of an
association than a role,
coule be an attribute in a
transaction
ads needs unique id, has
attributes
id, item,
description,
category, type,
photos?
expdate
advertisements redundant - -
listings
redundant (plural of ads)
or refers to "catalog" list--
browsable and
searchable?
description attribute of ads - -
photos attribute of ads?
needs unique id, has
attributes
size limit, id#,
ad #
size limit how to treat? constraint? - -
expiration notice needs unique id, has
attributes exp date, ad id,
reactivated ad (transformed
from reacvtivated)
subclass? or just a
data update of exp
date? does syetm
keep multiple values
of exp
date?(probably not
needed)
id, item,
description,
category, type,
photos?
expdate
buyer questions( essentially an
emailed question)
payment unique id, has
attributes
amount, cc#,
sec code,
ccExpdate
transactions (defines the record
of the full exchange inlcuding
items and buyer/seller, not just
a payment) unique id, has
attributes
id, buyer id,
seller id,
amount, item
(ad id)
(payment)confirmation--email
confirmation
transaction recipt
redundant as part of
confirmation or output
side the scope - -
PayPal external system - -
Venmo external system - -
ratings unique id, has
attributes
number of stars,
transaction id
member profile (public)
member id,
tranaction id,
rating, about me
(optional)
account
redundant (DBay
Member)/ system term
sys admin unique id, has
attributes
login pw
privileges
4.2 Domain Model
4.3 Selected Class Definitions
● Ads: another way to say “classified ad” or listing
● EmailConfirmation: this confirmation is sent via email to confirm that a Transaction
occurred.
● EmailedQsToSeller: represents the questions that a buyer may send to seller via a
masked seller email address
● ExternalPayments: payments made outside of the DBay system through Venmo or
PayPal. Payment must be verified and sent back to DBay.
● Flags: users can flag ads they find inappropriate and that violate DBay policies.
● MemberProfiles: represents the public profile of the DBayMember; shows an “About Me”
section and transaction ratings. This is recognized as a separate class of DBayMember,
which pertains more to the user and their private account information rather than a
visible, public profile.
● Ratings: users can rate transactions with other members to establish trust within a
somewhat anonymous system, so users can make a more “informed” judgement about
whether they would make a purchase from the seller. These transaction ratings appear
on the public, member profile.
● Transactions: used interchangeably with “bid” in our process, it defines the exchange of
an item/service for money. It’s a record of the buyer, seller, ad ID, and amount that was
paid.
● Verification: refers to the verification of DBayMember based on a Drexel U email
address, supporting that all members must be part of DBay community
4.4 Selected Association Definitions
4.4a Association meanings that are not intuitive: The associations within the Domain Model are
pretty straightforward and intuitive.
4.4b When there are two associations between the same two classes: Ads and DBayMember
have 3 associations. First, there is Created-by which shows that Ads are created by
DBayMembers. The second associations is Is-canceled-by, which simply indicates the
members can terminate their ads. Finally, expired Ads (ads where the expiration date is equal
to less than the current date) can be Reactivated-by DBayMembers within a 30-day period.
These multiple associations each show how one class can interact with the other based on
different needs of functionality and business rules.
4.4c.Recursive associations: None.
4.5 Discussion
The goal of the domain model is to provide a visual representation of conceptual classes, ideas,
things, or objects, in a real-world perspective within a set domain (Larman, 2005, p. 134). This
is opposed to a logical view of the domain that shows software classes and will be explored
later in this document in the Design Class Diagram. The classes in a domain model diagram
represent domain objects, which have attributes, or properties. In a domain model diagram, the
lines connecting these classes represent associations or relationships between the classes.
Both attributes and associations are important when one needs to store a value related to the
class or the relationship between two classes (p.150). Additionally, the numbers that
correspond to the ends of each relationship line represent multiplicity which is best defined as, “
. . .how many instances of class A can be associated with one instance of class B (p. 153).”
To determine the conceptual classes to be used in our Domain Model Diagram below, our team
used both the category lists provided in the Larman text (p.140-141) and Dr. Song’s A
Taxonomic Class Modeling Methodology for Object-Oriented Analysis (2008). Dr. Song’s
guidelines were especially helpful, and we conducted a noun phrase appraisal and taxonomic
class analysis creating a spreadsheet with the following headings: Noun, Elimination Note,
Applicable Modeling Rule, Possible Attributes, and Possible Associations. Utilizing the methods
outlined by Dr. Song, we analysed and re-analysed our problem statement as well as our use
cases to identify conceptual classes that made sense for our DBay system.
Some classes, such as DBayMember and Ad, were obvious, as were some of their attributes
and associations, but others, like Catalog, had to be flushed out as we thought about system
functionality, making it possible for users to search ads for the goods and services for which
they may be looking. As we considered attributes for the classes that required them, we begin
thinking about (if not fully enveloping ourselves in it just yet) the system’s data model. But not
yet ready to embark on our relational schema, we made some notes for later. Additionally,
giving some thought to relationships between classes helped us determine the
operations/methods we would need to illustrate later in our Design Class Diagrams. Similarly,
we made notes for to be used further along in our process.
Overall, our domain model is a very important step in the iterative process because it shows
how classes relate to one another and the important data (attributes) the system needs to store
about each class. It also allows for us to move on to the more logical elements of the process
which focus on the software processes that build functionality.
Chapter 2: System Design
5. Sequence Diagrams
5.1 System Sequence Diagram by Group Member
Marie Martino: Creating an Ad
Justin Martin: Creating a Profile
Sarah Caramanico: Submit Bid
5.2 Sequence Diagrams by Group Member
Marie Martino: Creating an Ad
Creating an Ad
Justin Martin: Creating a Profile
Sarah Caramanico: Submit Bid
5.3 Validation and Discussion of Sequence Diagrams
Another artifact included in the elaboration phase includes system sequence diagrams. These
diagrams illustrate input and output events related to a system (Larman, 147). SSDs are created
with use case text and its implied system events and shows the external actors that interact
directly with the system (Larman, 147).
The use case descriptions also play an important role in the development of sequence
diagrams. A sequence diagram illustrates the interaction of objects with each other in a single
use case. The purpose of a sequence diagram is to place the order of messages into a time
sequence. These diagrams feature an object’s lifeline and the focus of control. They can be
used in context of the whole system, a sub-system or they can be attached to a use case (Song,
371).
The individual diagrams drawn by each group member illustrate the three main use cases within
the DBay system. The system sequence diagrams exhibit the input and output events of the
Drexel University as an actor and its interaction with the system. These are events within the
create profile use case, the create ad use case, and the submit bid use case. Furthermore, the
sequence diagrams focus on the time sequences of sent messages between the actor and the
system within these three use cases. There is also a representation of additional sequence
diagrams that illustrate a number of important use cases.
6. Design Class Diagram
6.1 Design Class Diagram
6.2 Validation and Discussion
The Design Class Diagram (DCD) offers a different perspective than the Domain Model
Diagram, which is another form of class diagram in UML. DCD focuses more on the logic and
software design of the system. What is being modeled is less about expressing the
requirements themselves, but more about the solutions to meet those requirements (Larman,
2008, p. 249-251). That is, the DCD shows both structure and behavior. Like the domain
model, it does reveal classes, attributes, associations, and multiplicity, but it works to make
visual the the messages/operations happening between objects.
Our system is fairly simple. In its most basic form, it stores and displays information provided by
users to maintain profiles and sell items/services. It also provides a bridge of sorts to external
systems that handle the steps revolving around payment. Our system does not make need very
many complex calculations to solve the problems surrounding the online market platform it
provides. In our DCD, we attempted to employ a simple, “elegant” architecture and identify
classes that could be distributed and re-used to solve various system matters.
DBayMember has processes related to the creation, deletion verification, etc of DBay members.
It was included in this diagram because the creation of a DBayMember substantiates a
Verification object that verifies of the member’s Drexel email, which is a requirement of being a
DBay member.
Unsurprisingly, since ads are central to the services of the system, many operations are related
to this class. They can be created, updated, canceled, flagged, and have photos added to
them. Additionally, they substantiate both expiration notices based on the calculated expiration
date and transactions when a buyer choosing to “purchase (aka “bid on”) the item the ad
represents.
Transactions, in turn allow for the creation of ratings, which are evaluations of the transactions
by both buyers and sellers. So when the rateTrans() method is called, a rating instance is born.
Transactions also make it possible for payment to take place, taking the user to an external
system for the actual transaction to take place and then, once the message is received that the
transaction is complete via the verifyPayment operation, the system records the payment
information.
Undoubtedly, there are other possible models, but we choose this model because we thought it
solved the domain problems most simply and efficiently, reusing and redistributing main classes
as needed.
Chapter 3: Physical Design
7. Data Model
7.1 Relational Schema
DBayMember (memberID, name, email, password, verified, status)
MemberProfile(profileID, memberID, aboutMe, associatedTransactionID, associatedRatingID)
Foreign Key memberID references DBayMember (memberID)
Foreign Key associatedTransactionID references Transaction (transID)
Foreign Key associatedRatingID references Rating (ratingID)
Verification (verificationID, memberID)
Foreign Key memberID references DBayMember (memberID)
Ad (adID, sellerID, itemTitle, category, description, expirationDate, price, flag)
Foreign Key sellerID references DBayMember (memberID)
Photo (photoID, adID, title, size)
Foreign Key adID references Ad (adID)
Transaction (transID, buyerID, sellerID, adID, paymentID)
Foreign Key sellerID references DBayMember (memberID)
Foreign Key buyerID references DBayMember (memberID)
Foreign Key adID references Ad (adID)
Foreign Key paymentID references Payment (paymentID)
Payment (paymentId, amount, type, paymentVerificationNum)
Rating (ratingID, rating, transID, memberProfileID)
Foreign Key memberProfileID references MemberProfile (profileID)
Foreign Key transID references Transaction (transID)
SysAdmin (sysAdminID, name, email, pw)
Confirmation (transID, memberID)
Foreign Key memberID references DBayMember (memberID)
Foreign Key transID references Transaction (transID)
ExpirationNotice (adID, memberID, finalExpDate)
Foreign Key memberID references DBayMember (memberID)
Foreign Key adID references Ad (adID)
EmailedQSeller (emailMaskID, memberID)
Foreign Key memberID references DBayMember (memberID)
Chapter 4: System Evaluation
8. Evaluation
8.1 Evaluation of Project
Our choice of the DBay commerce system for the final project was influenced by several factors.
Initially, it seems as though all three of us, individually, decided that, not only was the healthcare
informatics option not quite the sort of project we saw ourselves wholly embracing, but the
trends on the board seemed to indicate that a majority of our classmates were moving in that
direction, and beyond that, there seemed to be a sense among us that a DBay system, loosely
modeled on such extant systems as Craigslist and ULoop, would be a great – even if
hypothetical – benefit to the Drexel community, since it would be a completely closed system in
which Drexel students and faculty could feel free to barter and sell amongst themselves without
any fear of scams or phishing intruding, since no one would be allowed inside the system
without a valid, current Drexel email address. And, quite frankly, we felt it would be a fun
challenge to build this type of commerce engine, since so many extant commerce engines are,
essentially, devoted entirely to commerce, with no checks on who is permitted to join and no
real method of arresting potential scammers beyond word-of-mouth. As it happened, we found
this to be an issue in our system, as well, but we believe that can be chalked to the nefarious
nature of certain people, and the benefit of the DBay system is that, at the very least, we can be
assured that anyone who attempts such measures can be certain to be a member of the Drexel
community, and so thus is much easier to block or eradicate.
As is generally the case with systems of this nature, what seemed on the surface to be a fairly
simple and intuitive undertaking turned out to be far more complex than we had initially
suspected; the DBay system has a single primary actor and only a handful of base use cases,
and yet, upon drilling down into the system, we continually ran into contingencies that needed to
be assimilated or neglected, depending on weight and importance. Much debate was devoted to
such seemingly trivial issues as “Do we allow BrowseAds, or is SearchAds sufficient?” and
“Should ads with photos count as an extend case, or should that be its own base case? Or
should we just add the ability to upload pictures onto CreateAd?” and “How many different
confirmations do we need to represent, and are any of them driven by the system itself?”
In light of this, we believe the quality of our specification to be entirely sufficient, albeit likely
lacking some nuance and detail due largely to our own unfamiliarity with the material at the
outset. That said, we continued to refine our processes and scope throughout the course of the
project by virtue of regular communication and collaboration via GChat and Google Drive. It is
fair to speculate that, were we given more time, we would have uncovered more usability
requirements and further ways to refine what remains a fairly simple, albeit functional, system;
at the very least, we would have, with time, gained more facility with UML and all of its attendant
accoutrements, and, ideally, have begun prototyping and testing the system.
It’s difficult to say now what we might have done differently, considering the fluid and adaptive
nature of our knowledge base throughout the course of this project. Obviously, it’s fairly easy to
speculate that we’d have come to our conclusions a bit more rapidly were we more familiar with
the structure and tenets of UML – and so, thus, might have had the opportunity to build a bit
more functionality and flexibility into the system – but on the whole it’s fair to say that the
methodology that we established at the outset of this project would have been readily
sustainable had this project stretched on ad infinitum. We may have initially delegated
responsibility differently, depending on inherent and emergent strengths, but for the most part
our group adapted easily in accordance with the requirements and parameters of the
assignment, and there was no strife or calculation, just a firm resolve to learn what had to be
learned and do what needed to be done.
8.2 Evaluation of UML and Tool
Throughout class lecture, readings, and activities, we have become familiar with the Unified
Modeling Language (UML) and how it applies in system design and analysis. The focus of this
visual language has become apparent throughout the course. We have not only seen through
lessons, but now through first hand design how UML deconstructs the artifacts of a system to
specify, reconstruct, and document the elements within.
Our Dbay system, though seemingly simple in design, is best described by the creator, and
explained to the user, through the use of various modeling tools. The modeling tools in which
we used to dissect our system created the ability to outline its functions through textual
description and visualization. In addition, modeling also provided the benefit of validating the
DBay system actions and actors, and clearly communicating iterations.
When selecting a modeling tool within UML, it is critical to plan ahead as to why this tool is
necessary and how it will be used. Our first modeling tool used in the design of DBay was the
Use Case Model which allowed us to model the system’s functionality and environment within
the requirements of the system. Though use cases are text documents, a model may also
include a UML use case diagram to show the names of use cases, actors, and relationships,
which provides a clear context diagram of a system (Larman, 50). Both our case text
descriptions and our diagram, which was created in Rational Rose, depicted DBay and each
iteration within the system.
The use case scenarios and descriptions are connected to the creation of a domain model,
which will show related and important concepts (Larman, 111). The goal of a domain model is
to act as a visual guide of conceptual classes, ideas, things, or objects, in a real-world
perspective within a set domain (Larman, 134). As a part of each class, there are objects that
have attributes and connecting lines that represent associations between the classes (Larman,
150).
It was especially helpful in the design of our domain model to use Dr. Song’s guidelines. These
guidelines emphasized the importance of analyzing our problem statement and use cases to
identify the conceptual classes for our DBay system. Our team had multiple conversations
related to classes to discuss the functionality of the system and uncover any hidden. After the
development of the domain model, it was very enlightening to see just how important of a step it
is within system design. It allowed us to continue to take logical steps of the development
process that contributes to the overall functionality of DBay.
After creating the domain class model, we gathered the system events and use case text and
created system sequence diagrams. These diagrams, created on LucidChart, illustrate input
and output events related to a system and show the external actors interacting directly with the
system. As a group, we illustrated three important use cases: createProfile, createAd, and
submitBid.
We then reconfigured these diagrams to create sequence diagrams for each of the three use
cases. A sequence diagram illustrates the interaction of objects with each other in a single use
case. The purpose of a sequence diagram is to place the order of messages into a time
sequence. These diagrams feature an object’s lifeline and the focus of control. They can be
used in context of the whole system, a sub-system or they can be attached to a use case (Song,
371). Our system design’s functionality became more established with these models,
continuing to exhibit functionality with step by step actions conducted between the actor and the
DBay system.
Offering a different perspective of the DBay system is the design class diagram (DCD). DCD
emphasizes the logic and software design of the system, as well as solutions to meet
requirements within the system (Larman, 213). The DBay system stores and displays
information related to user profiles, and selling/buying items and services. Because of the
simplistic nature of our system, the design does not require complex requirements to solve
problems. In our DCD, we created a simple architecture to identify classes that could be
distributed and re-used to solve presented system matters.
It is fair to say that had our group were given more time, we would have developed additional
modeling tools to continue to depict the functionality of the DBay system. The modeling tools we
used throughout the design of DBay proved to be critical to the overall analysis and
development of system. They enabled us to see that design does not lie solely in illustration
models, nor independently through text. The marriage of these two elements encompass a
critical element in the creation of software, enabling clarity amongst not only the creators of the
system, but its potential users.
References
Craigslist. (2015). Retrieved from http://www.craigslist.org Ebay. (2015). Retrieved from http://www.ebay.com Larman, C. (2005). Applying UML and Patterns, Third Edition. Upper Saddle River: Prentice Hall.
Rumbaugh, J., Jacobson, I., & Booch, G. The Universal Modeling Language Reference Manual, 2nd Ed.
Boston: Addison Wesley, 2004. Shelley, G.B. and H.J. Rosenblatt. (2010). Systems Analysis and Design. Boston: Cengage Learning. Song, I.Y. (2008). A Taxonomic Class Modeling Methodology for Object-Oriented Analysis. [PowerPoint Slides]. Retrieved from http://learn.dcollege.net ULoop. (2015). Retrieved from http://www.uloop.com
Appendix
9.1 Lessons Learned by Group Member
Justin Martin:
I learned that UML, with all of its extended processes and methodologies, is a tricky beast and
one not to be taken lightly. I learned – or, rather, had it confirmed to me – just how important it is
to be a part of a strong, reliable team, populated by endlessly capable people of great fidelity
and vigor.
I learned that the assimilation process is lengthy in UML, but that, if you give it enough time and
effort, things eventually begin to clarify. I learned that it’s worth it to restate, and restate again,
the seemingly obvious. I learned that there is great enjoyment to be had in constructing
diagrams, even if you don’t necessarily do them accurately the first time. I learned that a task
can become simpler and more complex at the exact same moment. I learned that an email
confirmation screen can drive you to the brink.
I learned that even the simplest tasks can begin to seem infinite, once you begin to break them
down into their component parts. I learned we should never take for granted the grace of
clicking a button on a website and having it function as it should.
I learned what an “emoji” is, and why I should never use one.
Marie Martino
This was, hands-down, one of the most challenging projects in my experience at Drexel to date,
so I am especially grateful to have had a great teammates, the first key to a successful project!
With our analysis and design process, it was more difficult to work remotely, and I wish I could
have been the same physical space (replete with whiteboard) with my teammates, where we
could have imagined and refined our collection vision on the spot, drawing diagrams and solving
problems on-the-fly. That said, it goes without question that communication plays a significant
role to the realization of most endeavors, but especially one like this, where a seemingly minor
detail can actually make the project change direction if missed or miscommunicated. Overall, I
think our team did a fine job communicating despite the challenges of we faced interacting
online, but it actually increased our workload in some ways, having to communicate, perhaps,
more frequently and being more thoughtful and explicit about the ideas for which we were trying
to create understanding.
Another related “lesson learned” is the importance of language in the A & D process. If we had
to do it again, developing a formal data dictionary would have been a very useful tool right from
the beginning, rather than assuming our teammates all shared the same definitions and
understandings of words that might represent a concept or class or other abstract notion.
Sometimes, we found ourselves doing the opposite, using different terms to describe similar
things as well. I think we might have spent a good less deal of time defining/re-defining terms
farther into the process.
Additionally, I cannot help but want to compare this experience, a mock scenario school project,
with a real-life systems analysis and design project. Interpersonal roles and relationships and
dynamics would be quite different in the real world. For example, in order to keep things fair, we
tried to keep the amounts of work even between teammates. We also divided leadership in
coordinating the the various aspects of the project. In some ways this compensated for not
having a formal project manager that a systems A & D team would have in the real world. The
professional serving in that role plans, schedules, monitors, and reports out regularly on project
progress. This person manages the budget, schedule and quality of the end product (Shelley &
Roseblatt, 2001, p.102). Systems development without project management is utterly
impossible. So in some ways, while our team did not have to manage costs, we did have to
balance time spent with the quality of the end-product. In some sense, each team member was
a project manager, coordinating some micro-facet of the project.
Finally, using UML was both extremely rewarding, albeit equally as challenging. I understand
the value of this powerful modeling language, even if I still struggle to understand the more
advanced aspects of it. Being a visual thinker of sorts, I am amazed at how well UML provides
professionals with a way to document the organization and implementation a system throughout
the whole system analysis and design process, in such an economical and organic way. On the
other hand, I wonder if it is common to get bogged down with maintaining the documentation,
which in some ways goes against an agile design method. As we moved through various steps
in the process, we had to keep track and go back to update previously generated documents to
match the later ones. That said, I wonder, again, drawing a distinction between this learning
exercise and the use of UML in the real world, how widespread and frequently UML might be
used in the software industry and why or why not.
As with most group projects, the fear of dividing and conquering with unfamiliar classmates is a
scary idea, so I am lucky to have worked with such driven individuals. Though working together
virtually presented a few challenges, it encouraged constant communication, which gave us
momentum to work through this project.
The analysis and design project brought the lectures and readings alive, integrating a firsthand
experience to UML and modeling. Throughout the book, Larman expresses his dislike for
waterfall methodology, and after completing this project, I can see why. It was so critical to
break design up into sections, because our descriptions and requirements would change as we
continued to move on in the process. Had we been able to perform code and testing, this would
have been given even more light for the progression of our design, but for now, I will just
recognize its importance.
The process of UML is lengthy, but offers a way to incorporate both textual descriptions and
visual representation. I think it is important to combine both of these processes of modeling so
it can provide gradual movement in design and analysis. This project was very challenging, but
did paint a detailed picture of software development.
9.2 Team Work & Division of Labor
Our division of labor emerged fairly organically, through discussion, as did much of this project.
Initially, we divided the labor according to tasks, but upon further examination of the
requirements document we realized that that was erroneous, and so thus we altered our
methodology to reflect the specific necessities of the project. We had regular virtual meetings
via Google Hangouts, during which we discussed in depth the then-current status of the
individual elements of the project on which we were each working. Each one of us completed
the requirements as directed, and remained in regular contact via email and Hangouts in order
to lend support and insight. Additionally, because of how we divided the work, each member
took leadership within different areas of the project. We all shared tools and resources, learning
from each other and relying on each other’s feedback to sort out various questions and
challenges about the tasks at hand.
9.3 Unsolved Problems
We wondered, late in the process, about the real-world application of these methods: in other
words, were one or all of us to be hired by a company or organization tasked with building these
sorts of engines, would we be faced with the same methodology and format that we used on
this project.
