Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
C
car_rental
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
CSCE 361
starter code
car_rental
Commits
457045ec
Commit
457045ec
authored
5 years ago
by
Christopher Bohn
Browse files
Options
Downloads
Patches
Plain Diff
Prepared class diagram assignment.
parent
6d135868
Branches
Branches containing commit
Tags
Tags containing commit
No related merge requests found
Changes
2
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
.gitignore
+88
-0
88 additions, 0 deletions
.gitignore
assignment/class_diagram.md
+175
-0
175 additions, 0 deletions
assignment/class_diagram.md
with
263 additions
and
0 deletions
.gitignore
0 → 100644
+
88
−
0
View file @
457045ec
# Project-specific
# none (for now)
# Mac file finder metadata
.DS_Store
# MS Office temporary file
~*
# Emacs backup file
*~
# Java files
*.class
javadoc/
# JetBrains (IntelliJ IDEA, PyCharm, etc) files
.idea/
cmake-build-*/
out/
bin/
*.iml
*.iws
*.ipr
# Eclipse files
bin/
.settings/
.classpath
.project
# Visual Studio / VS Code files
.vs*/
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates
*_i.c
*_p.c
*_h.h
*.ilk
*.meta
*.obj
*.iobj
*.pch
*.pdb
*.ipdb
*.pgc
*.pgd
*.rsp
*.sbr
*.tlb
*.tli
*.tlh
*.tmp
*.tmp_proj
*_wpftmp.csproj
*.log
*.vspscc
*.vssscc
.builds
*.pidb
*.svclog
*.scc
# Netbeans files
nbproject/private/
build/
nbbuild/
dist/
nbdist/
nbactions.xml
nb-configuration.xml
# Xcode files
*.xcodeproj/
xcuserdata/
.build/
# Maven
target/
# Miscellaneous
tmp/
*.tmp
*.bak
*.bk
*.swp
*.gcno
This diff is collapsed.
Click to expand it.
assignment/class_diagram.md
0 → 100644
+
175
−
0
View file @
457045ec
# Class Diagram
Due: January 24, 2020 at 9:30am
## Overview
In this assignment you will prepare a simple class diagram.
You will:
-
Prepare a simple class diagram
-
Practice domain modeling under guidance
-
Demonstrate UML notation to show relationships between classes.
## Instructions
This assignment is to be completed individually;
**
no collaboration is
permitted
**
.
You may draw the diagram using a tool, or you may hand-draw it.
*
You may
**not**
use a tool that generates UML diagrams from programming language code.
*
If we see hallmarks of auto-generated UML, we will ask you to show us the tool
you used to prepare the diagrams. If you used a tool that auto-generates UML,
you will receive a score of 0 for this assignment.
### Setup
1.
You will use your
`csce361-homework`
repository for this assignment.
1.
You will need one of:
-
A tool with which to draw UML diagrams, such as
<https://draw.io>
, that
will let you save your diagram as a pdf file.
-
A way to scan a hand-drawn diagram and save it as a pdf file.
### Assignment
Imagine, if you will, that you're working for Husker Klunker Car Rental Company.
The company previously used notecards to keep track of its inventory and a
pocket calculator to prepare customers' bills. After a particularly unfortunate
incident involving the notecards, a table fan, a jar of peanut butter, and the
owner's cat, you've been tasked with automating the car rental process.
Prepare a domain-level UML
*class diagram*
for the relationship between
vehicles, customers, and similarly-related domain concepts. Because this is
domain-level, you don't need to include details such as visibility modifiers or
datatypes. Because this is domain-level, you shouldn't include anything not
present in the problem domain; in particular, you shouldn't include
implementation details such as GUI frames and textboxes.
1.
There are two types of
`Customer`
s,
`IndividualCustomer`
s and
`CorporateCustomer`
s. All customers have a name and an address. Place
`name`
and
`address`
attributes in the
`Customer`
base class. Show that the
`Customer`
class is an abstract class. If you are hand-drawing your
diagram, leave room to later add operations to the class.
-
A
`CorporateCustomer`
also has a
`billingAccountNumber`
attribute and a
`negotiatedRate`
attribute. If you are hand-drawing your diagram, leave
room to later add operations to the class.
-
An
`IndividualCustomer`
has a payment card. Create a
`PaymentCard`
class. Use aggregation to show that an
`IndividualCustomer`
has-a
`PaymentCard`
. You do not need to show any of
`PaymentCard`
's
attributes or operations. You do not need to show multiplicity on the
aggregation relationship.
1.
Husker Klunker charges the customer based on the
*class*
of the vehicle.
For example, it costs more to rent an SUV than a mid-sized car, and an
economy car costs less to rent than a compact car.
-
Create an abstract
`VehicleClass`
that has a
`dailyPrice`
attribute.
-
Create subclasses of
`VehicleClass`
for SUVs, mid-sized cars, compact
cars, and economy cars.
1.
Husker Klunker organizes its inventory based on the
*model*
of the vehicle.
For example, employees can check to see how many Canyoneros are available
to be rented.
-
Create a
`VehicleModel`
class, and show that it can be described by its
name, manufacturer, style, number of doors, and transmission type.
-
Use a simple association to show that each
`VehicleModel`
is associated
with exactly one
`VehicleClass`
.
1.
The inventory keeps track of
*vehicles*
.
-
Create a
`Vehicle`
class, ad show that a
`Vehicle`
knows its VIN
(Vehicle Identification Number), its license plate, and its color. If
you are hand-drawing your diagram, leave room to later add operations
to the class.
-
Add an association between
`Vehicle`
and
`VehicleModel`
.
-
Use directionality to show that a
`Vehicle`
"knows" about its
`VehicleModel`
, but a
`VehicleModel`
doesn't "know" about its
`Vehicle`
s.
-
Add a label to show that a
`Vehicle`
can refer to its associated
`VehicleModel`
as its
`model`
.
-
Add an operation to
`Vehicle`
to query the status of the
`Vehicle`
.
1.
A customer rents a vehicle.
-
Use associations to show that an
`IndividualCustomer`
rents at most one
`Vehicle`
, and that a
`CorporateCustomer`
rents arbitrarily many
`Vehicle`
s.
-
Add reasonably-named operations to
`Customer`
for selecting a
`Vehicle`
, checking out a
`Vehicle`
, and returning a
`Vehicle`
.
-
Because each subclass handles checking out a
`Vehicle`
differently,
show that the check out operation is abstract in
`Vehicle`
, and add the
check out operation to the subclasses to show that they override the
operation.
-
Add an operation to
`Vehicle`
to query its price.
1.
After you have completed your diagram, save it as a pdf file called
`07-class_diagram.pdf`
in your local copy of your
`csce361-homework`
repository. Then upload (add/commit/push) to the server.
### Deliverables
For grading, we will pull updates to your
`csce361-homework`
repository after
the assignment is due, and we will look for:
-
`03-class_diagram.pdf`
containing your class diagram.
*
It is your responsibility to ensure that your work is in the master branch of
the
**correct repository**
and that we have the correct level of access to the
repository at the
**time the assignment is due**
. We will grade what we can
retrieve from the repository at the time it is due. Any work that is not in
the correct repository, or that we cannot access, will not be graded.
*
## Rubric
The assignment is worth
**13 points**
:
-
**5.5 points**
for including the eleven classes (0.5 per class).
-
**3.0 points**
for including the class members as described (0.5 for each
of:
`Customer`
,
`IndividualCustomer`
,
`CorporateCustomer`
,
`Vehicle`
,
`VehicleModel`
, and
`VehicleClass`
.)
-
Deduct for missing members
-
Deduct for members in the wrong box
-
Comment upon attributes named with verbs or operations named with nouns
-
Comment upon providing type-signatures for operations without parameter
names
-
**0.5 points**
for showing that
`Customer`
and
`VehicleClass`
are abstract
classes, and that
`Vehicle`
's checkout method is abstract (either with
*italics*
or with {abstact}).
-
**0.5 points**
for showing inheritance between
`Customer`
and its
subclasses,
`IndividualCustomer`
&
`CorporateCustomer`
.
-
Correct notation at correct end
-
**0.5 points**
for showing inheritance between
`VehicleClass`
and its
subclasses.
-
**0.5 points**
for showing association between
`Vehicle`
and
`VehicleModel`
.
-
Correct directionality arrow
-
Correct label
-
**0.5 points**
for showing association between
`VehicleClass`
and
`VehicleModel`
.
-
No directionality
-
Correct multiplicity
-
**0.5 points**
for showing associations between
`Vehicle`
and the
subclasses of
`Customer`
.
-
Correct multiplicity for the
`IndividualCustomer`
-
`Vehicle`
association
-
Correct multiplicity for the
`CorporateCustomer`
-
`Vehicle`
association
-
**0.5 points**
for showing aggregation between
`IndividualCustomer`
and
`PaymentCard`
-
Correct notation at correct end
-
**0.5 points**
for not including anything else wrong (TA discretion).
-
**0.5 points**
for using a meaningful commit message when committing your
file.
*If **at any time*
*
your repository is public or has internal visibility then
you will receive a 10% penalty. Further, if another student accesses your
non-private repository and copies your solution then I will assume that you are
complicit in their academic dishonesty.
*
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment