Package Diagrams

Lab Overview

Scenario/Summary

Your analysis phase of the SRS project went well and your team feels good about their Functional, Structural, and Behavioral models. You also discussed the result of your analysis with the School of Prosperity (SoP) administration and they seem to be in line with your analysis models.

Now is the time to start the design phase where you generate specific directions for the implementation of the system by the software development group. The first step in the design phase is to examine the SRS class diagram and to try to simplify its organization using a package diagram. The package diagram ensures that classes that belong together are grouped into a single package and thus simplify the development of these classes and their maintenance.

Your deliverable this week is to generate a package diagram for the SRS system.

Deliverables

SRS package diagram.
Verification and validation of your work.
Explanation of your work.
Name of each member of your team and how they participated.

STEP 2: Generate the Detailed Package Diagram

Dowload the LabWeeklySubmissionTemplate. You are going to use this template for all of your Lab submissions throughout this course. This template is available in week1 Lab.
Create a diagram for the SRS system using the Rational Software Architect software on the Citrix Lab environment based on your structural and behavioral models.

STEP 4: Verify, Validate, & Explain Your Work

Using the LabWeeklySubmissionTemplate, verify and validate your work
Using the LabWeeklySubmissionTemplate, explain your work, the decisions you made to arrive at your proposed solution, and lessons learned.

STEP 4: Generate an Object State Diagram

Create a state machine diagram for an object of the RegistrationRecord class (the class that maintains the registration of a student in a class) using the Rational Software Architect software in the Citrix Lab environment based on your functional and structural models.
Using the LabWeeklySubmissionTemplate, copy and paste your object state diagram into the template.

STEP 5: Upload your LabWeeklySubmissionTemplate Document

Save the LabWeeklySubmissionTemplate MS Word document with the file name LabWeeklySubmissionTemplate_YourName and upload it to the the Files section of the Course Menu.

Student Name:

Course:

CIS339

Session (month, year):

03/2019

Object-Oriented System Analysis and Design

The School of Prosperity Student Records System (SRS)

Week 1 — System Request 3

Week 2 — Use Case Diagram AND Use Cases Descriptions 5

Week 3 — Class Diagram AND CRC Cards 9

Week 4 — Sequence, Communication, and State Machine Diagrams 15

Week 5 — Package Diagram 19

Week 6 — Method Contract AND Method Specification 21

Week 7 — Object-Oriented Application Coding 24

Week 1—System Request

Use this system request template and complete the SRS system request.

System Request—

Project sponsor:

School of Prosperity (SoP)

Business Need:

The existing desktop system will be upgraded to web-based application and this system will be used to maintain records of students, courses, classes, and student registration and grades.

Business Requirements:

The system is capable of having the following functonalities:

· Accessibility over the Internet

· Maintains records of school students

· Maintains records of courses offered by school

· Maintain records of classes offered of the above courses (both online and face-to-face classes)

· Students registration system is included as well

Business Value:

Conservative estimates of tangible value to the company include:

· The SRS will enable the school to continue the expansion of its student population and to effectively manage the expansion

· Eliminate many school staff hours re-entering paper form student registrations by allowing the students to self-register

· Make the system easy to access from anywhere there is an Internet connection and a web browser

Special Issues or Constraints:

· The SRS must be able to handle both online and face-to-face class offerings

· The system must be accessible over the Internet to both school staff and students each with appropriate permissions

· The SRS must try to integrate with and re-use existing desktop application code and database as much as possible to reduce development cost

Validate and verify that your system request addresses the SRS Preliminary Planning Overview.

The business need area explains what the SoP is requiring the system to operate. The business requirements consist of what the system must be able to handle and the expectations of the system (once it’s completed). The business value breaks down the details of information that the new system will save on both staff hours and finances for the school. The issues area give problems that could exist once the system is implemented.

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

I, carefully, read the SRS Preliminary Planning Overview and highlighted the important business needs that the SRS system is to meet. I then started to complete the various sections of the System Request Form and while doing so, I referred back to the SRS overview document to confirm my conclusions and understanding. The result of this iterative process is the current System Request Form.

Week 2—Use Case Diagram and Use Cases Descriptions

Generate a use case diagram for all of your use cases, including their actors. The diagram must be generated by a UML drawing tool. Copy and paste your diagram here:

SRS Use Case Diagram

Use this use case description template and complete the two SRS use cases of (1) Maintain Class Records and (2) Register a Student for Classes.

Maintain Class Records

Use Case Name: Maintain Class Records	ID: 1	Importance Level: 1
Primary Actor: Staff Member	Use Case Type: Fully Dressed
Stakeholders and Interests: Staff Members, Student, Teacher
Brief Description: This use case covers the maintenance of student records. It covers adding, updating and deleting student records.
Trigger: Maintain Student Record Button Type: Fully Dressed
Relationships: Association: Include: Enter courseID Extend: Add Record, Update Record, Delete Record Generalization:
Normal Flow of Events: 1. Staff Members log ins to the system. 2. Enter Course ID 3. A list of all classes for that course are then displayed. 4. If the class is to be maintained, select update or delete 5. If the user selected to add the class. 6. Enter Class type(Online / Face to Face), then 6.1 7. Enter CourseID 8. Enter Class begin Date 9. Enter Class end Date 10. Save the record
SubFlows: 4.1. If the user selected update 4.2. If the user selected delete 6.1. If the class is Online 6.2. If the class is face-to-face
Alternate/Exceptional Flows: 4.2.1. User can see all records in editable form. User will update any record and click save. 4.2.2. A respective record with entered courseID will be deleted. 6.1.1. Enter Class URL 6.1.2. Enter Class Browser 6.2.1. Enter Class Building. 6.2.2. Enter Class Room.

Register a Student for Classes

Use Case Name: Register a student	ID: 2	Importance Level: 1
Primary Actor: Staff Member	Use Case Type: Fully Dressed
Stakeholders and Interests: Staff Member/ Student
Brief Description: This use case covers the registration process of a student using SRS.
Trigger: Register Student Button Type: Fully Dressed
Relationships: Association: Include: Extend: Generalization:
Normal Flow of Events: 1. A staff member or student logs into the system. 2. A list of available courses offered are displayed. 3. User selects a course from the list and all the offered classes for the course are displayed. 4. User can select class from the class list. 5. The selected class to registration for is then validated against the registration rules 6. When the registration is valid against the rules, a registration record is created and a message is then displayed to confirm registration. 7. If registration is successful, one is added to the number of students that have enrolled in the class. 8. After the student completes the class, his registration record is updated with a grade. But the student has the option of dropping the class while taking it.
SubFlows: 5.1. No duplicate registration for the same class 5.2. Online classes registration requires students acknowledgement that they have the required hardware and software to access online classes 5.3. No more than three class registration for open classes unless student GPA is greater than 3.0. Then the student can take four classes. 5.4. The student has taken any required pre-requisite course.
Alternate/Exceptional Flows: 6.1. A message explaining the violation of the associated rule is displayed.

Validate and verify your use case diagram and use case descriptions against the SRS Requirement Definition and the SRS System Request.

SRS has 4 major functionalities which are covered in the 4 use cases, which are as follows:

Functionality	Covered in Usecase
Maintain Student Records	Maintain Student Records
Maintain Course Records	Maintain Course Records
Maintain Class Records	Maintain Class Records
Register a Student for Classes	Register a Student for Classes

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

I first read the case thoroughly and then listed all the functional and non-functional requirements on the page. Then I extracted the major use-cases from them. After that I generated the flows for those use cases. After extraction of the major use-cases and their actors I build a use-case diagram and after getting the flows I end up getting the fully dressed use cases.

Week 3—Class Diagram and CRC Cards

Generate a class diagram for the SRS system. The diagram must be generated by a UML drawing tool. Copy and paste your diagram here:

SRS Class Diagram

Use this CRC template and complete a CRC card for each class you designed in your SRS class diagram.

Class1 CRC Card

Front:CRC01

Class Name: Student

ID: 01

Type:

Description: This class will keep track of students

Associated Use Cases:

Maintain student records

Responsibilities

Add Student

Remove Student

Search Student

Collaborators

Back:CRC01

Attributes:

studentID, FirstName, MiddleInit, LastName, Department, DOB, GPA

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations:

Class2 CRC Card

Front:CRC02

Class Name: Course

ID:

Type:

Description: This class will keep track of all courses

Associated Use Cases:

Maintain course records

Responsibilities

Add course

Update Course

Remove Course

Collaborators

Back:CRC02

Attributes:

CourseID

CourseName

CreditHours

Description

Prerequisite

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Class, Register

Other Associations:

Class3 CRC Card

Front:CRC03
Class Name: Class	ID: 3	Type:
Description: This class will keep track of all classes	Associated Use Cases:
Responsibilities Add class Remove Class	Collaborators
Back:CRC03
Attributes: CourseID BeginDate EndDate ClassURL ClassBuilding ClassRoom
Relationships: Generalization (a-kind-of): Aggregation (has-parts): Course Other Associations:

Class4 Register

Front: CRC04

Class Name: Register

ID: CRC04

Type:

Description: This will register students in classes

Associated Use Cases:

Responsibilities

Assign student in classes

Collaborators

Back:

Attributes:

CourseID

StudentId

Relationships:

Generalization (a-kind-of):

Aggregation (has-parts):

Other Associations:

Validate and verify your class diagram and CRC cards against the SRS use case diagram and use case descriptions.

There are 4 major use cases, so for each case there can only be one class, because each use case is about updating the entries for one entity.

There is one CRC card for each class and every detail about that class is written there.

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

The decisions I made are quite simple. Because I created all the necessary classes and made the association relations in between them. Then I made CRC cards for those classes.

Week 4—Sequence, Communication, and State Machine Diagrams

Generate a sequence diagram for the SRS system Register a Student for Classes use case. The diagram must be generated by a UML drawing tool. Copy and paste your diagram here:

Sequence Diagram for the Register a Student for Classes Use Case

$C:\Users\Inam Baig\Desktop\sequence.jpg$

Generate a communication diagram for the SRS system Register a Student for Classes use case. The diagram must be generated by a UML drawing tool. Copy and paste your diagram here:

Communication Diagram for the Register a Student for Classes Use Case

$C:\Users\Inam Baig\Desktop\communication.jpg$

Generate a state machine diagram for the SRS system RegistrationRecord object/class (the class that maintains the registration of a student in a class). The diagram must be generated by a UML drawing tool. Copy and paste your diagram here:

State Machine Diagram for the RegistrationRecord Object

Validate and verify your behavioral diagrams against the SRS Register a Student for Classes use case description and the SRS class diagram.

All the diagrams match with the specifications in SRS. As in the communication diagram all the communication path of register a student use case is shown. Moreover in the sequence diagram the path of use case Register a student is shown according to the classes in class diagram. In state diagram all the states are shown in a sequential way.

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

I just understood the use case register a student and its path, after that I mapped that path in the form of classes in the class diagram. After that according to the paths and classes I mapped these in the form of diagrams.

Week 5—Package Diagram

Generate a package diagram for the SRS system. The diagram must be generated by a UML drawing tool. Copy and paste your diagram here:

SRS Package Diagram

Validate and verify your package diagrams against the SRS class diagram and the SRS Register a Student for Classes use case sequence and communication diagrams.

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

Week 6—Method Contract and Method Specification

Use this method contract template and complete a method contract for the GetCourseByCourseID() method of the CourseList class.

CourseList.GetCourseByCourseID() Method Contract

Method Name:	Class Name:	ID:
Clients (Consumers):
Associated Use Cases:
Description of Responsibilities:
Arguments Received:
Type of Value Returned:
Pre-Conditions::
Post-Conditions:

Use this method specification template and complete a method specification for the GetCourseByCourseID() method of the CourseList class.

CourseList.GetCourseByCourseID() Method Specification

Method Name:	Class Name:	ID:
Contract ID:	Programmer:	Date Due:
Programming Language: Visual Basic Smalltalk C# Java
Triggers/Events:
Arguments Received: Data Type:	Notes:




Messages Sent & Arguments Passed: ClassName.MethodName:	Data Type:	Notes:








Argument Returned: Data Type:	Notes:

Algorithm Specification:
Misc.Notes:

Validate and verify your method contract and method specification against the CRC card for the CourseList class and the CRC card for the Course class.

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

Week 7—Object-Oriented Application Coding

Copy your code text of the CourseList.GetCourseByCourseID() method and paste it here:

Code Text of Your CourseList.GetCourseByCourseID() Method

Copy a screenshot of running the unit test of the CourseList.GetCourseByCourseID() method and paste it here:

Screenshot of running the Unit Test of CourseList.GetCourseByCourseID() Method

Zip all the files you used in this coding project; copy and paste the *.zip file here so that it can be unzipped and loaded into the IDE and run on another computer:

A *.zip File of all of the Coding Project Files

Validate and verify your code and screenshot of the CourseList.GetCourseByCourseID() method against the method contract and the method specification of the same method.

Explain how you completed your work, the decisions you made to arrive at your conclusions, and the lessons you learned.

Page 26 of 27

Package Diagrams

Lab Overview

Scenario/Summary

Deliverables

STEP 2: Generate the Detailed Package Diagram

STEP 4: Verify, Validate, & Explain Your Work

STEP 4: Generate an Object State Diagram

STEP 5: Upload your LabWeeklySubmissionTemplate Document

Week 1—System Request

Week 2—Use Case Diagram and Use Cases Descriptions

Week 3—Class Diagram and CRC Cards

Week 4—Sequence, Communication, and State Machine Diagrams

Week 5—Package Diagram

Week 6—Method Contract and Method Specification

Week 7—Object-Oriented Application Coding

No matter what kind of paper writing service you need, we’ll get it written. Place Your Order Now!

Ready to Make Your First Order?

About Us