Given a set of program specifications for a simple business

Question

A.    Lab #CIS CIS170A-A1

B.    Lab 5s of 7: Modularization

C.    Lab Overview - Scenario / Summary:

TCOs:

TCO: 7 Given a set of program specifications for a simple business problem utilizing a modular design, code and test a program that meets the specifications and employs best programming practices.

TCO: 8 Given a set of program specifications for a simple business problem, code and test a program that implements methods with parameter lists that are passed as supported by the chosen programming language

This lab will familiarize the student with the process of modularizing his or her code.

D.    Deliverables:

Step	Deliverable	Points
5	Program Listing, Output, and Project Files	45

The Dropbox deliverables include the following.

1.     Include a zipped file with all the files from your Visual Basic project (see directions in Doc Sharing on how to collect and zip files.)

2.     Create a single MS Word document and include the following.

• For each lab, copy and paste your code directly into the MS Word file.
• Include screenshot(s) of your test data with test results. Enter enough data to demonstrate that all your code has been tested.
• Include another screenshot of the Visual Basic build output messages. Check your build output to make sure you have a successful build with (0) errors and (0) warnings. NOTE: The build output messages appear at the bottom of your window after you click the Build menu and before you click the Start Without Debugging option. Your build output messages provide a list of compiler warnings or errors and let you know whether your program compiled successfully.
• Include the Word document as part of the zipped project file.

3.     Upload each part of the lab into its corresponding weekly Dropbox.

E.    Lab Steps:

Preparation:

If you are using the Citrix remote lab, follow the login instructions located in the iLab tab in Course Home. Locate the Visual Studio 2010 Icon on the desktop. Click to open.

Lab:

Step 1: Create a New Project
Create a new project in VB.NET. Name your project CIS170A_Lab05. Practically every real-world professional program in existence today uses some type of modular design-this is just the way programs are designed and built. As a result, the primary objective of this lab is for you to understand how modular programs are designed and how data are passed between modules as the program is executing. This may be one of the most important lessons of this course, so it is critical that you focus on the modular design of the program; if you have any questions, post them to the Lab Forum threaded discussion. In this project, we are going to use the Week 4 Hockey Player Statistics program that you created last week as a starting point and make a few minor changes in the program requirements. What you will do is take the existing project and with only slight modifications to the form design you will modularize the design of the code and then add a few new requirements. As you will see when you complete the modular program design you will be able to add the new requirements to the design algorithm much more easily. One very important point is that the logic used in the modules is virtually identical to the logic used in the Week 4 assignment, with the only major difference being that the code has been moved into sub procedures and functions. However, this comes at a price because the communication of the modules becomes more complex; however, the gains in efficiency in creating the original program and then modifying the program when requirements change (as they always will) outweigh the negative effects of communication complexity.
Step 2: Program Description
As a reminder here are the requirements of the Week 4 program. Create a program that will calculate and display the career statistics for a hockey player. The program will begin by allowing the user to enter the following information. Name of the hockey player - The name must be a nonempty string. Number of seasons played - The number must be at least one season and no more than 20 seasons. Only after a valid season value is provided, processing of goals and assists can begin. The next step is to allow the user to provide additional information as follows. Number of goals - A valid number of goals is between 0 and 60. Number of assists - A valid number of assists is between 0 and 60. The program will keep a running total of the following statistics. Number of goals Number of assists Total points A list of the each season's data will be display after the season data are provided. Additionally, once all the season data are collected, the program shall list the summary information for the player and all the seasons. NEW REQUIREMENTS The following are the new requirements that the customer wants to make. 1.     The customer has decided that he or she wants to change the upper limits for goals, assists, and seasons. He or she wants the upper limit of the seasons to be 25, the upper limit for the goals is 70, and the upper limit for assists will be 75. 2.     As with most programs that collect names of individuals, the full name shall be broken into two parts: the first name and the last name. Both the first and last name must contain nonempty-string values. 3.     The customer wants to keep track of how old the player was when he or she started playing hockey, so the program shall provide a field to collect and validate the age of the player when he or she was a rookie. The starting age shall be at least 18 years old and no more than 30 years old, and the age shall be displayed as part of the summary output. 4.     The user cannot begin to collect season data until after the first name, last name, seasons, and age are all provided and validated. The updated hierarchy chart, which shows the structure and flow chart of the program, is given below. Notice that most of the processing details have been encapsulated into separate modules. As a result, this makes the high-level processing flow easier to understand and the lower level details of the processing are isolated into smaller modules. The modules can be reused as necessary when new requirements are added. The hierarchy chart shows the events (which are just "specialized" modules), which illustrates how the higher level modules control the execution of the lower level modules. The hierarchy chart also shows the isolation of modules, which is another key characteristic of modular designs. Also notice from the hierarchy chart that there are multiple levels of modules in each tree branch. For example, the Gets Status Button Event handler branch has three sub-levels of modules. It is not uncommon for real world, professional programs to have several levels of modules in each tree branch. The flow chart for the overall program and each of the modules listed in the hierarchy chart are provided below. Before you begin constructing your program, ensure that you review these diagrams carefully and pay attention to the comments in the call-out boxes. Also, it is highly recommended that you refer to these diagrams often while you are building your program.
Step 3: Build the Form
The following is the Object, Property, Setting, Event chart for the form controls, and each input field will have a label/input field pair. Also, group the related information in the associated group box The form and form controls will be logically placed on the form, the controls aligned and sized, and a logical tab order assigned to each of the form controls. Object Property Setting frmHockeyStats Text Hockey Player Statistics lblHeading Text Name, Course Title, Week Number, Lab Title grpPlayer Text Player Information  lblFirstName Text First Name:  txtFirstName Text (empty)  lblLastName Text Last Name:  txtFirstName Text (empty)  lblSeasons Text Number of Seasons:  txtSeasons Text (empty)  lblAge Text Rookie Age  txtAge Text (empty) grpStatistics Text Statistic Operations  btnGetStats Text Get Player Statistics grpResults Text Season Results  lstSeasons Items (empty)  lblTotal Text (empty) grpOperations Text Operations  btnClear Text Clear  btnExit Text Exit You are free to experiment with colors and form design as you see fit. However, your application must meet the listed requirements. Hint: Use constants for the lower and upper limits for the goals and assists. This will allow you to easily change the range limits in one place (see below). For example:  Private Const GOAL_LOWER_LIMIT As Integer = 0  Private Const GOAL_UPPER_LIMIT As Integer = 70  Private Const ASSIST_LOWER_LIMIT As Integer = 0  Private Const ASSIST_UPPER_LIMIT As Integer = 75  Private Const SEASONS_LOWER_LIMIT As Integer = 1  Private Const SEASONS_UPPER_LIMIT As Integer = 25  Private Const PLAYER_MIN_AGE As Integer = 18  Private Const PLAYER_MAX_AGE As Integer = 30 Hint: Declare the seasons, age, total goals, total assists, and total points variables as "form-level" variables at the top of the form and outside any module body. This will make these variables form-level variables and they can be accessed by any of the modules without having to pass them into the module through the argument list. Private totalGoals As Integer = 0 Private totalAssists As Integer = 0 Private totalPoints As Integer = 0 Hint: An event handler can handle events from multiple controls, which allows you to modularize and reuse event handler code. For example: Private Sub txtName_Validating(ByVal sender As Object, ByVal e AsSystem.ComponentModel.CancelEventArgs) Handles _ txtFirstName.Validating, _ txtLastName.Validating   Dim txtbox As TextBox = CType(sender, TextBox)   e.Cancel = ValidateStringInput("Name", txtbox.Text) End Sub Hint: Use the "sender" argument of each event handler to inspect the control that fired the event, but you need to convert the "object" to a textbox first, such as: Dim txtbox As TextBox = CType(sender, TextBox) e.Cancel = ValidateStringInput(datadescription, txtbox.Text) Hint: Use the "IS" operator to see which control fires an event; for example: If sender Is txtNumSeasons Then process the number of seasons ElseIf sender Is txtAge Then 'process the age End If Step 4: Implement the Event Handlers Use the following as the design for your event handlers, referring to the flow chart for rules on input validation and processing. The final calculation SHOULD NOT be completed until all the input fields are validated. Control Name Event Task txtFirstName Validating Get player first name Validate player name txtLastName Validating Get player first name Validate player name txtSeasons Validating Get number of seasons Validate number of seasons txtAge Validating Get age Validate age Enable/disable get statistics command button btnGetStats Click For each season  Get goals  Validate goals  Get assists  Validate assists  Calculate total goals  Calculate total assists  Calculate total points  Output season statistics in list Next Output season summary btnClear Click Clear all textboxes and output labels btnExit Click Close program (hint: use "Me.close") frmHockeyStats Load Clear all textboxes and output label (hint: call the ClearFields module)
Step 5: Executing the Program
To execute your code, click Start and then start debugging. Check your output to ensure that you have space(s) where appropriate. If you need to fix anything, close your execution window, modify your code as necessary, and rebuild.
Step 6: Deliverables
1.     Capture a screen print of your output (do a PRINT SCREEN and paste into an MS Word document). 2.     Copy your code and paste it into the same MS Word document that contains the screen print of your output. 3.     Save the Word document as CIS170A_Lab05_LastName_FirstInitial. 4.     Zip up the Word document along with a complete set of project files into a single document. 5.     Place deliverables in the Dropbox.
END OF