1. Class diagram for the BITS system
achops27
week_3.zipWeek 3/~$ek3.iLab.Directions-1.docx
Week 3/BITS.BusinessProcess.ActivityDiagram.docx
Open Staffing Request Use Case
SEARCH FOR CANDIDATES USE CASE
CLOSE STAFFING REQUEST USE CASE
1
oleObject2.bin
text
Staffing Request
Candidate
Reserve Candidate
[Qualified Candidate]
Unable to Fill memo
[No Qualified Candidate]
Staffing Request Fill Pending
Add Candidate to Qualified List
Create Unable to Fill Memo
Notify Arrangement Department
Unable To Fill
Staffing Request
Notify Client
Staffing Agent Searches For Qualified Candidate
Candidate
Client
Arrangement Specialist
image3.emf
oleObject3.bin
text
Staffing Request
Arrangement Specialist Contacts Candidate
Candidate
Create Bill
[Candidate Accepts]
Invoice
Mark Candidate Placed
Notify Staffing Agent
Notify Staffing Agent
Status Request Reopen
[Candidate Rejects]
Request Filled
Staffing Agent
Offer Rejected in Qualified List
Staffing Request
Delete Qualified List
Unreserve Candidate
Candidate
image4.emf
oleObject4.bin
text
Notify Client
Unable To Fill Memo
Notify Client
[Successful Search]
Invoice
Staffing Request
[Unsuccessful Search]
Client
Client
Close Staffing Request
image1.emf
oleObject1.bin
text
Get Client Information
[New Client]
[Old Client]
Create New Client
Enter Staffing Request and Mark as Open
Staffing Request
Client
image2.emf
Week 3/BITS.Requirements Definition.docx
BITS System Requirements Definition
BITS wants to automate their staff placement system. Each staffing agent will have to log into it. That login software already exists for other computer applications that the employees must log into at BITS. Here is how the current staff placement system works:
When a BITS client company determines that it will need a temporary professional employee, it issues a staffing request to a staffing agent through email, fax, or the phone. The staffing agent then writes down the staffing request information on a BITS staffing request form and marks its status as “opened.” Once in a while, a new client calls in search of a temporary employee. Then the new client information must be added to the client file by the staffing agent.
The staffing agent checks the type of position and experience requested on the staffing request against the files of available professional staff in the candidate file cabinet to find the most qualified candidate. If a qualified individual is not found, the staffing agent creates an “unable to fill memo” that explains the reason why the staffing request could not be satisfied. The staffing request status is changed to “unable to fill.” The agent then notifies the client. If a qualified candidate is found, the candidate is marked “reserved” in the candidate’s file, his name, email address, phone number, and status indicator are written to a blank “Qualified List” that is attached to the staffing request and the staffing request form status is changed to “fill pending.” The staffing agent then sends the staffing request to the arrangements department.
The arrangement specialist in the arrangement department contacts the qualified candidate in the staffing request to see if he or she will accept the position. If the answer is yes, the arrangement specialist completes the arrangements by marking the candidate “placed” in the candidate’s file. The status of the staffing request is then changed to “filled.” The arrangement specialist also creates a bill and then notifies the staffing agent. If the candidate rejects the offer, then the candidate is taken off “reserved” status in the candidate’s file. The member’s entry status indicator in the “Qualified List” that is attached to the staffing request is also marked “Offer Rejected,” and the staffing request status is changed to “opened.” The staffing agent is then notified to search again for another qualified candidate. The staffing agent will not pick the same candidates that have already rejected the offer because of the candidates’ “Offer Rejected” status in the “Qualified List” attached to the staffing request.
As part of the arrangement policy, BITS has an agreement with all clients that the commission paid to BITS by the client will not be paid until two weeks after the candidate begins work. This policy is to ensure that the candidate is a good fit for the client. If the candidate does not work out well, then the search process begins again.
If an arrangement was successful, a bill and the staffing request are given to the client by the staffing agent. If the search was unsuccessful, then the client is given the “unable to fill memo” by the staffing agent. In both situations, the staffing request status is changed to “closed” and filed away.
Week 3/CRC_Card_Template.docx
|
Class Name: |
ID: |
Type: |
|
Description:
|
Associated Use Cases: |
|
|
Responsibilities
|
Collaborators
|
Back:
|
Attributes:
|
|
Relationships: Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations:
|
Week 3/Week3.iLab.Directions-1.docx
Scenario:
As the software architect for the BITS system, you are making good progress in your work. After finishing the Functional Modeling (activity diagram, use case diagram, and use case descriptions) of the BITS system, you are now ready to move on to its Structural Modeling.
In this week, you will use the models of your Functional Modeling to determine and design your class diagram and complete a CRC card for each class. The Structural Modeling is very critical for the success of your project since it is the backbone upon which the entire project is built, so take the time to design and refine your class diagram and its corresponding CRC cards.
Deliverables:
1. Class diagram for the BITS system
2. CRC cards for each class in your class diagram
Step 1: Watch how to create a Class Diagram in RSA using Citrix in MY iConnect Live Lecture. You can instead do this in Visio.
Step 2:
1. Create the class diagram for the BITS system using the Rational Software Architect software in the Citrix iLab environment based on your functional models. Pay attention to different kinds of relationships in the class diagram.
2. Copy and paste your BITS class diagram into a Word document.
Step 3:
1. Complete CRC cards for each class that you designed in your class diagrams, ensuring that you identify all appropriate attributes, operations, relationships (including types), responsibilities, and collaborations. Be sure that you complete the front and back of each card. Be sure that your CRC cards exactly reflect what you created in your class diagrams.
2. Copy and paste your CRCs into the document that contains your class diagram.
Step 4:
Save the Word document with the file name LastName.CIS339.Week1.Lab and upload to your Dropbox. Only submit one document.
Remember that I need for you to put your last name first in the file name so that the files are saved on my hard drive in alphabetical order. Thank you.
Week 3/Week3.Library.Class_Diagram.CRC-1.docx
How to Create a Class Diagram and a CRC
When you begin to create a class diagram, you can start by thinking about relational database modeling because a class really is an enhancement of a database table (entity). A class is a template for the same data in a table but then you add operations and then make the data and the operations private or public.
So let’s start off by creating the tables for the library system. We can look at the activity diagram and find those tables by looking at the object symbols in the diagram. In the activity diagram we have the Library Card, Loaned Resource, and Resource. We will not use the screen object or the printer object because they are not part of the Problem Domain. Let’s begin by focusing on the first three of these objects: Library Card, Loaned Resource, and Resource.
In this system, a patron can borrow one or more resource and one resource can be borrowed by more than one patron. So it is a many-to-many relationship. In a many-to-many relationship we need an associative table to store the data about each item that is borrowed. So there are three tables in this system.
So here is what the Entity Relationship diagram would look like:
Now, all we have to do is add operations and make them public or private and we will be done! But we must make sure that each class is cohesive. That is extremely important. If you don’t make your classes cohesive, then all other UML object oriented diagrams you build from your class diagram will be worthless.
So we now know that we need three classes. The next step is to determine what operations we would define in each class. Operations are the same things as methods. We refer to them as operations in a class diagram and as methods in subsequent diagrams as we begin to get more technical.
Library Card:
This class is a template for holding personal information about the patron. The operations are public which means that other class instances can directly send messages to those operations. We need to be able to create cards, update cards, delete cards, validate cards and so on.
Resource:
The Resource class keeps track of the different types of resources at the library. If you look at the attributes, you will see standard information for perhaps a book or CD. The operations will allow someone to borrow one of the copies of the resource. The class must keep track of how many copies of the resource are still available at the library. It will start the process of checking out and checking in of any resource. We should also be able to add resources, delete resources, and update resources as well.
The Library System Class Diagram
One patron (library card) “borrows” one or more item resources. One resource “is loaned” as one or more borrowed item resources. In other words, one patron can borrow many resources and one resource be loaned out to many patrons.
You will notice that each class is cohesive. That means that each class will contain operations that will directly impact the data in the class they are in. That is a very important “rule of thumb” when determining where to put an operation. Take a moment and examine the operations in each of the classes in the above diagram.
For instance, in the Library Card class, the CreateCard operation will create a new card for someone and the name, address, phone and status in the object instance for that class will be affected or referred to. It would be wrong to put the CheckOutResource operation in the Library Card class because the data in a Library Card class instance would not be affected or referred to by that operation. If you keep this rule of thumb in mind, then you will enjoy creating your class diagram.
The biggest mistake students make is that they think that the operation should go in the class that is executing (CALLING) the operation. Classes send messages to other classes all the time. Classes are reused and operations are reused all the time. So it is important that an operation only be defined once and be defined in the class that has the data template the operation uses.
You want other applications to send “messages” to your class object instance public operation. But that operation must be created in the class it is related to just like you would only put related data in a relational table. Each table in a relational database only contains information about the name of that table or in other words the entity name. For instance, you would not put customer information in a sales representative table and you wouldn’t put sales rep information in a customer table.
So in order to test the cohesiveness of your class, ask yourself: “Does the operation directly use a substantial number of attributes in the class?” If it doesn’t then mostly likely that operation does not belong in that class.
Class Responsibility and Collaboration Card
|
Class Name: Patron Card |
ID: 1 |
Type: Concrete, Domain |
|
Description: This class contains information about the library patron as well as some library status information |
Associated Use Cases: Check-In Resources, Check-Out Resources |
|
|
Responsibilities CreateCard DeleteCard UpdateCard ValidateCard RetrieveCard DisplayCard |
Collaborators
|
Back:
|
Attributes: CardID PatronName Address Phone Status
|
|
Relationships: Generalization (a-kind-of): Aggregation (has-parts): Other Associations: Loaned Resource
|
|
Class Name: Resource |
ID: 2 |
Type: Concrete, Domain |
|
Description: Contains information about the resources that can be borrowed. |
Associated Use Cases: Check-In Resources, Check-Out Resources |
|
|
Responsibilities OrderResource UpdateResourceStatistics AddResource DeleteResource CheckOutResource CreateLoanedResourceItem (Client object)
|
Collaborators
LoanedResource (server object) |
Back:
|
Attributes: ISBN CopyNumber Resource Type Title Author Publisher NumberOfCopiesAvailable
|
|
Relationships: Generalization (a-kind-of): Aggregation (has-parts): Other Associations: LoanedResource
|
image1.emf
oleObject1.bin
Table
image2.emf
oleObject2.bin
+CreateCard() +DeleteCard() +UpdateCard() +ValidateCard() +RetrieveCard() +DisplayCard()
-CardID : String -PatronName : String -Address : String -Phone : String -Status : String
Patron Card
+CheckInResource() +CreateLoanedResourceItem() +RetrieveLoanedResourceInfo() +UpdateLoanedResourceItem() +CalculateResourceFine() +GenerateReceipt() +CloseResourceItem()
-PatronCardID : String -ISBN : String -CopyNumber : Integer -DateBorrowed : Date -DateDue : Date -LateCharge : Single -Status
Loaned Resource
+CheckOutResource() +AddResource() +DeleteResource() +OrderResource() +UpdateResourceStatistics()
-ISBN : String -CopyNumber : Integer -ResourceType : String -Title : String -Author : String -Publisher : String -NumberCopiesAvailable : Integer
Resource
1
0..*
0..1
-
1
Week 3/Week3.Visio.Tutorial.ClassDiagram.docx
This week you will be creating a class diagram in Visio. This tutorial will show you the mechanics of creating a class diagram.
This tutorial will reflect the Appointment system class diagram in your text book. In order to keep this tutorial short and instructional, the class diagram has been modified. But please complete this tutorial because next week, your sequence diagram tutorial will need everything you do in this tutorial.
So, let’s begin to create a class diagram!
1. Launch Visio 2010, click on the UML icon.
2. Right-click on “ Tutorial Package” in the model explorer, click on “ new” then click on “ Static Structure Diagram.”
3. Drag the class shape to the drawing.
4. Double-click on the class shape.
5. Give the class the name “ Patient.”
6. Click on Attributes. Add Attributes. “ Type” refers to the datatype. For small numbers you can use Integer, for numbers with decimals use Single. Use the VB or C# data types. Make the visibility “ Private.” Add these attributes:
Name String, Address String, Phone String, Age Integer, Insurance Carrier String.
7. You will notice that the Patient class has been added to the model explorer at the bottom of the screen.
8. Click on Operations. Add the operation NewCancelChangeAppt. Make the operation public. Leave “ return type” alone. Make the operation visibility public. Public means that other classes can send a message to that operation. If it is private, then only the class can execute the operation. Add the operation ApptTimes and make it public as well. Then click OK.
9. Look at the model explorer. You will notice the new class and its attributes and operations. Also below, you will notice that the class has three sections: Name, Attributes, and Operations.
10. Create a class named ” Appointment.” Add these attributes: Time Date, Date Date, Reason String. Add this operation: Cancel Without Notice. Make it public with no return value.
11. Notice the new class in the model explorer along with its attributes and operation.
12. Drag a binary association line to the drawing. It is the first symbol in the second row.
13. Click on the line to activate it. Right-click with your mouse and click on “Display Shapes Option.” Then uncheck all the boxes except for “ First End Name,” “ End Multiplicities” and the two last boxes at the bottom.
14. Double-click on the line. You will be associating one class with another class. A class may have a one-to-many, one-to-one, or many-to-many relationship with another class. You can designate those relationships by using the “ Multiplicity” column in that dialogue box. In this example, we have a one-to-many relationship between Patient and Appointment. One patient can have zero or more appointments and one appointment can have only one patient. Click on the first row under Multiplicity and select 1 in the dropdown list. Click on the second row under Multiplicity and select 0..* in the dropdown list. Click Ok.
15. In the first “ end name,” type in “ Schedules.” Only the first end name can be seen because you unchecked the “ second end name” previously. Click OK.
16. Drag the line between the two classes making sure that the 0.** is closest to the appointment class. It now reads that one patient schedules one or more appointments and one appointment can only have one patient.
17. Create a class called PatientsList and add to it the operation LookUpPatients, a class named BillsList and add to it the operation LookUpBills, and an ApptsList class and add to it the operation MatchAppts. They are now added to the model explorer. It is very important that you do this portion because you will need these classes for your sequence diagram tutorial next week.
