Question Details

(Solved) WERS - Code Tour ITEC 6660 - Code Tour The Walden Emergency Response System (WERS) is a Java program accessible through the NetBeans IDE. It provides...


UML presents a useful abstraction of code. When designing a system, the UML diagrams allow you to define objects, details such as their states and activities, and the way they interact with each other. In addition, you have seen how reverse engineering existing source code to UML can give you quick and useful insight into the same details of a system without having to read the source code line by line.


In this unit’s Discussion, you performed an overall comparison of source code with the UML diagrams generated from it. It is also very useful to develop a deeper understanding of the system by focusing on missing details of the dependencies between class objects. These dependencies include the important ways that classes and packages rely on one another. While creating a system with no dependencies is impossible, a very useful goal is to work to minimize the dependencies that exist within a system. In this Assignment, you learn how IDE plug-ins, such as jDepend, can help you find these dependencies.


For this Assignment, you analyze the Walden Emergency Response System (WERS) code for dependencies. To do this, you download the jDepend plug-in and install it into the NetBeans IDE. Follow the instructions in Installing jDepend in the NetBeans IDE document. You should already have the NetBeans IDE installed on your system. If not, or if you need to reinstall NetBeans, download and install the most recent version of NetBeans from the website.


With jDepend installed, set up the WERS source code as a NetBeans project. To do this, select the Open Project option from the File menu in NetBeans and navigate to the directory where you unzipped the WERS source code. WERS displays with a Java coffee cup icon to indicate that it can be opened as a NetBeans Project.


Select WERS, and then click the Open Project button. Run jDepend over WERS. In addition, look at the UML diagrams you generated for this unit’s Discussion.


By Day 7, submit a 3- to 5-page analysis that includes the following:


  • The number of package-to-package dependencies in WERS (Determine whether they preserve strict layering, i.e., they depend on the level immediately below.)
  • A list of classes from outside the planning package that depend on (use) the Planner class
  • A list of classes in packages other than planning that the Planner class depends on (uses)
  • The addition to your UML diagrams from the Discussion of any missing dependency information found by jDepend
  • An analysis of the code complexity (Keep in mind that code complexity is based largely on the number of dependencies in the code.)


Make sure that your submission follows the APA style.

WERS – Code Tour ITEC 6660 – Code Tour
The Walden Emergency Response System (WERS) is a Java program accessible through the
NetBeans IDE. It provides basic emergency information in response to chemical spills on the Walden campus. You will be updating this program based on what you learn about software
design and construction during each unit of the course.
This document provides the basic navigation through the Java packages and classes in
NetBeans so you can see how the WERS Java code works, the overall structure of the code, and
where in the code you will be working for each unit’s assignments. Contents
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Unit 1
1
2
3
4
5
6
7
8 – Starting up WERS .................................................................................................. 2
– The WERS Code Overview ...................................................................................... 4
– Reducing Client Coupling – The Facade Pattern .......................................................13
– Observers ............................................................................................................14
– Refactoring to Patterns .........................................................................................17
– Design Patterns for Complex Data Structures ..........................................................19
– Threads for Concurrency .......................................................................................23
– Implementing Concurrency Safely ..........................................................................24
– Exception Handling ...............................................................................................26 WERS – Code Tour Page 1 WERS – Code Tour Unit 1 – Starting up WERS
In this part of the Code Tour, you will see how to start up WERS once you have imported it as a
project in NetBeans. The WERS system you will be working on is called StudentWers. To run it,
select StudentWers in NetBeans. Figure 1 – StudentWers opened in the NetBeans IDE. Then click the Run button
. It is circled in red in the toolbar in Figure 1 above.
In NetBeans, you will notice that the Output pane at the bottom right of the window indicates
that WERS has started. WERS – Code Tour Page 2 WERS – Code Tour Figure 2 – The Output pane in NetBeans. The WERS runner window will appear. It is shown in Figure 3 below. This window allows you to
start up the various options for WERS. You can refer to the WERS User Guide for more about
the information that responders input into each view and information WERS displays based on
the input. Figure 3 – The WERS runner window You will run one view to verify that your updated code works for most of your assignments. In
unit 3, you will run two views and admin view, and you will run two views for the Unit 6
and 7 assignments on Threads and Safe Concurrency. WERS – Code Tour Page 3 WERS – Code Tour Unit 1 – The WERS Code Overview
This section will give you an overview of what happens when you invoke WERS and input
information on an emergency spill. This will give you a sense of the overall WERS Java code
structure.
When you click the Run button in NetBeans, an instance of the WERS class is constructed. This
class is defined in WERS.java of the wers package, shown in Figure 4 below. Figure 4 – The WERS.java file in the wers package Notice that WERS extends the Swing GUI’s JFrame class. WERS – Code Tour Page 4 WERS – Code Tour This extension of the JFrame graphical user interface allows for the creation of the buttons
(JButtons from the Swing GUI library) in the WERS runner window. These buttons are created
in the initGUI method, shown in Figure 5 below. Figure 5 – The initGUI method You have seen how this gets displayed in the WERS runner window, shown again in Figure 6
below: Figure 6 – The WERS runner window
WERS – Code Tour Page 5 WERS – Code Tour Clicking these buttons call the various classes in the scenarios package, shown in Figure 7
below. Figure 7 – OneView.java, TwoView.java and TwoViewAdmin.java in the scenarios package For instance, clicking the Run one view button invokes the OneView class from the scenarios
package. You can see from the code above that this begins the process of implementing the
Model/View/Controller pattern within WERS.
A new ResponderView is created, along with the overall WERSController. This view and the
controller are defined in the mvc package, shown in Figure 8 below. WERS – Code Tour Page 6 WERS – Code Tour Figure 8 – AdminView.java, ResponderView.java and WERSController.java in the mvc package Notice that only Views and the Controller are defined in the mvc package. The Planner and
Plans make up the model portion of MVC in WERS. Planners, and the plans they create, are
complex enough to warrant their own planning package.
In the mvc package, you will notice two different types of views. AdminView is a shell that
you will update in Unit 3.
The ResponderView class, shown in Figure 9 below, provides the main interface for
responders to input emergency information about a spill into WERS, and for WERS to display
information about handling the spill back to responders. WERS – Code Tour Page 7 WERS – Code Tour Figure 9 – The ResponderView class ResponderView implements the Java Observer class. This implementation allows the Plan
model to push information to the ResponderView observer as changes to the plan are made.
You will learn more about the Observer class and the Observable interface in Unit 3.
When a ResponderView is created, it generates a Get Plan button. Once a responder has
input information about the emergency into ResponderView, he or she will press the Get
Plan button. When this button is pressed ResponderView invokes the controller’s
requestPlan method. The requestPlan call is shown in the middle of the red box in Figure
10 below. Figure 10 – The ResponderView constructor invoking the controller’s requestPlan method
WERS – Code Tour Page 8 WERS – Code Tour Recall from the OneView scenario that first the ResponderView is created, and then the
WERSController is created. This is displayed in Figure 11 below. Figure 11 – The OneView constructor creating an instance of WERSController WERSController is also defined in the mvc package, shown in Figure 12 below. Figure 12 – WERSController.java in the mvc package
WERS – Code Tour Page 9 WERS – Code Tour WERSController is responsible for mapping each view as an observer of its Plan. The Plans
are parts of the Planner, the “Model” portion of this Model/View/Controller implementation.
WERSController performs this mapping in its requestPlan method, where it gets Plans
from the Planner and maps them to their corresponding ResponderView. This is shown in
Figure 13 below. Figure 13 – The requestPlan method WERSController gets the Plan by calling the getPlan method of the Planner class.
Planner is defined in the planning package, shown in Figure 14 below. WERS – Code Tour Page 10 WERS – Code Tour Figure 14 – The Planner class defined in the planning package The getPlan method of Planner creates an instance of Plan from responder, using spill and
size information provided by the responder. Figure 15 – Planner’s getPlan method Back in WERSController is the last piece, where the display takes place. WERSController
assigns the Plan returned by Planner.getPlan() to its plan instance variable. Then it calls
the addObserver method of the plan with the view as input. WERS – Code Tour Page 11 WERS – Code Tour Figure 16 – getPlan called from WERSController’s requestPlan method This makes sure that view is an Observer of this plan. Any time the plan changes, it will notify
this view and it will update and display the changes.
This overview of the WERS code should provide you with a foundation for understanding how
the MVC code is structured and where everything is. The specific logic for accessing database
information and putting together responses to emergency spills is located in other packages
within WERS.
Each of the following units includes an assignment that will require you to update the WERS
code to implement a design pattern or update the code based on software design and
construction best practices. This document provides additional information to help you approach
each of these subsequent assignments. Simply click on the correspond Unit to access this
additional information. WERS – Code Tour Page 12 WERS – Code Tour Unit 2 – Reducing Client Coupling – The Facade Pattern
This assignment revolves around using design patterns to help clarify your code and increase
the potential for reuse. Tight coupling occurs when one class accesses implementation-specific
information of another class. One way to loosen, or ‘reduce’, the coupling is to introduce the
Façade design pattern.
Keep in mind that while you are working to reduce coupling in this assignment, you won’t
eliminate it. This is because there has to be some coupling, or some relationship, between the
objects in the system, in order for the system to function.
By implementing the Façade pattern, you will be able to funnel the dependencies/coupling of
other packages through a single public class via method calls to that pattern.
Your analysis of coupling in WERS should lead you to focus on more than one package that may
benefit from reducing the number of dependencies. Choose one of these packages and
implement the Façade pattern within that package.
Your implementation of the Facade pattern will be a class that will go in a separate .java file in
the package you select. You can come up with the name; make sure the name of your new
class includes the word “facade”. Collect as much of the functioning of the selected package
into this new facade as you can.
Keep in mind that other class definitions in other packages will need to be updated to reference
your new facade class. And you will remove references to the databases themselves.
There may need to be changes in other classes. You can find most of the changes you will need
to make when you instantiate the facade class and eliminate the old references. As you make
test runs of WERS, NetBeans will let you know that you have broken references, and you can
work to patch these up. WERS – Code Tour Page 13 WERS – Code Tour Unit 3 – Observers
This unit’s task requires you to add another view to WERS. This new view is an administrative
overview of all emergencies and proposed responses. Everything you will need to work with
resides in the mvc package. You will find that the basics for this new view have already been
created in the AdminView.java, displayed in Figure 17 below. Figure 17 – AdminView.java in the mvc package You can see how AdminView implements the Java Observer class in Figure 18. WERS – Code Tour Page 14 WERS – Code Tour Figure 18 – AdminView implements the Java Observer class Farther down in this file is a shell for the update method shown in Figure 19. Figure 19 – Shell for the update method You will create the code for this method. This method will receive the callbacks that are pushed
to this Observer implementation. Any plan may call this update method, and this will trigger
renewing/updating information in this Administrator view from all of the Responder views.
You will also need to create an addController method in AdminView. This method is
passed a reference to a controller, and it will assign the reference to a variable in AdminView
that you will create.
This AdminView will also need to be “registered” with the controller. You will do this either by
overloading the addView method for the existing controller, or by creating a new controller
which references the same model for this new AdminView. Whichever way you decide to go,
keep in mind that you will need to explain and justify your decision for this unit’s assignment.
Finally, once you have created the addController method for AdminView, you will need to
go back to the scenarios package, where you will find the TwoViewAdmin.java class file,
shown in Figure 20 below. WERS – Code Tour Page 15 WERS – Code Tour Figure 20 – The TwoViewAdmin.java file in the scenarios package TwoViewAdmin is the scenario that runs the Two ResponderViews with the new
AdminView. Uncomment the last two lines so that the code will use the methods you just
created to wire the AdminView into your MVC implementation.
The real trick in this assignment will be finding the logical points in the Planner where the
AdminView must be attached as an observer to existing and/or new plans made for
responders. Finally, note that the very best answer will even know about responder views that
exist but do not yet have a plan. WERS – Code Tour Page 16 WERS – Code Tour Unit 4 – Refactoring to Patterns
For this unit’s assignment, you will take an existing, tightly coupled factory and replace it with
an Abstract Factory.
This tightly coupled factory is the Plan class. It is defined in the Plan.java class file within the
planning package, shown below in Figure 21. Figure 21 – The Plan.java file in the planning package The part of the constructor that chooses absorbents and special cautions based on spill type
can be modified to use the Abstract Factory pattern to get the correct absorbent and cautions
once the spill type is known, without any further logic. This decreases coupling by removing the
knowledge of absorbent and caution details and moving it into subclasses specifically design for
that information.
The Plan constructor method creates the correct plan for a situation based on input from a
responder about an emergency chemical spill. Elements of this constructed plan include the
information about the proper absorbents, along with cautions specific to certain problematic
materials. WERS – Code Tour Page 17 WERS – Code Tour Figure 22 – This if/then/else determines how to set values for absorbents and cautions You can see the coupling in the code fragment from the constructor method in Figure 22,
where an if/then/else conditional determines what to set for the absorbents and cautions.
Instead of having the Plan make decisions and update state variables in both the
absorbents and the cautions objects, you will encapsulate this logic as an abstract Factory.
The old conditional can then be refactored into a compact choice of which concrete factory to
use, based on the spill material. You may also have to refactor additional application code so
that it makes use of the new abstract Factory. WERS – Code Tour Page 18 WERS – Code Tour Unit 5 – Design Patterns for Complex Data Structures
For this unit’s assignment, you will be updating WERS to upgrade the Emergency Materials list
to a tree structure so that it shows the campus as the root, all of the buildings within the
campus as branches, all the rooms as branches off each building, and all materials as leaves
within each room. WERS must also include a function to display a string that shows the entire
tree structure of the material on campus.
To do this, you will create classes implementing the Composite design pattern as a logical tree
structure from campus, to building, to room, to materials in the room. In essence, there must
be classes created to hold each of the different elements of this tree.
You will create these new classes as part of the composite package. Figure 23 – MaterialTreeTestScenario.java in the composite package A scenario for exercising your code called MaterialTreeTestScenario already exists in the
MaterialTreeTestScenario.java file of the composite package, shown in Figure 23. WERS – Code Tour Page 19 WERS – Code Tour Figure 24 – The main method in MaterialTreeTestScenario.java You will test your implementation of the Composite pattern via the main method shown in
Figure 24. Once you have created the tree classes for the campus, building, room and material,
you can remove the comments around this method, and possibly add or update the existing
code. Keep in mind that the material class you create will be a terminal or leaf node to this
tree structure. WERS – Code Tour Page 20 WERS Code Tour Figure 25 – When comments are removed, the main method creates a tree from the materials
database. You can see in Figure 25 above that this method first creates the tree from materials database,
and each of the classes you create will need to include an override of the
insertMaterialRecord method.
Once the MaterialTree has been generated from the database information, this main test
method just iterates each branch or node of the tree. Each iteration will print out the
information via the class’s toString() method. This will require campus, and perhaps other
tree nodes, to include a toString() method that returns a string representation of the total
tree.
You will have to work to make the output look good, so that each branch is indented to show
clearly the tree structure and how each leaf node is related to its branch, and each branch to
the overall tree.
In addition, you will need to provide an Iterator that can produce all the types of materials on
campus in alphabetical order. You will have to decide whether the Iterator is defined as a
method in an existing class or as a separate class. WERS – Code Tour Page 21 WERS – Code Tour Keep in mind that your Iterator must step through all the materials on Campus. You will have to
provide the Iterator required methods; minimally you will need to implement next() and
hasNext(). The Iterator sequence will be used in the loop that prints the alphabetic list of
materials by printing the items as they are encountered by the next() method. WERS – Code Tour Page 22 WERS – Code Tour Unit 6 – Threads for Concurrency
In this unit’s assignment, you will be developing a scenario to demonstrate the existence of the
race condition that seems to exist when spill kit assignment in WERS. When the Planner
generates two response plans intended to run at the same time (concurrently) they may be
assigned the same spill kit! This is hard to see, but your simple scenario will let you exercise the
lanner and find this random failure.
To test your implementation, you will also need to create a driver scenario that creates two
Responder Threads that run concurrently. The code you write will be all new; you will not be
updating any existing code. Create your new .java files in the currently empty threads
package shown in Figure 26. You get to choose whether to implement them as subclasses of
the Thread class, or by using Java’s Runnable interface. Either will work. Figure 26 – The threads package If you go with a Thread implementation, your new classes will be subclasses of Thread. If you
use the Runnable interface, you will have to define the run method.
Your driver should output the rooms and spill kits used for each responder. You should add
enough “debug” output to clearly show what your threads are running concurrently. WERS – Code Tour Page 23 WERS – Code Tour Unit 7 – Implementing Concurrency Safely
This unit’s assignment is about making the concurrent code you developed for the previous unit
run “safely”. In this case, “safely” means so that Plans running simultaneously do not violate
any of the WERS requirements.
One requirement in WERS is that spill kits get assigned to one and only one emergency spill
plan. Spill kits are considered expendable resources, and each spill must get its own spill kit.
When you created the concurrent code during the previous unit, you did not incorporate any
mechanism to make sure that the plan (and accompanying spill kit) you assigned to a spill was
not already in use by another emergency spill.
If your concurrency scenario from the previous unit really runs concurrent threads AND you run
it over and over you should notice that for some of your runs, WERS assigns the same spill kit
to both spills. If not, try the following to convince yourself of the lack of thread safety: for each
attempt, make both spills happen in the same room. Try this a number of times and you should
see one of the runs showing the same plan spill kit for both spills.
You must fix this race condition problem by synchronizing (via Java’s synchronized keyword)
some parts of the current code. This will either be in the Planner class shown in Figure 27
below… Figure 27 – The Planner class, in Planner.java of the planning package
WERS – Code Tour Page 24 WERS – Code Tour …or the Plan class displayed in Figure 28 below. Figure 28 – The Plan class in Plan.java of the planning package Both of these classes reside in the planning package.
Find the smallest code fragment that you can synchronize so that two spill kits are never
assigned to the same spill. Since synchronization restricts concurrency and may pose other
problems, you want to minimize the scope of the synchronized code.
One hint; which class is most narrowly responsible for assigning spill kits? WERS – Code Tour Page 25 WERS – Code Tour Unit 8 – Exception Handling
This unit’s assignment is about exception handling using Java’s catch-throw mechanism.
Currently, WERS handles exceptional cases like missing information by using conventional
programming logic such as if-then-else statements. You will go through the existing logic
of WERS exception handling and update it to use catch-throw.
Specifically, WERS handles the exceptional case of an unqualified responder requesting
emergency help from WERS by providing this responder with a default plan. You will find the
logic for this in the Plan class of the planning package shown below in Figure 29. Figure 29 – The Plan class in the planning package This class generates a Plan based on the responder and the information the responder provides
to start the process of dealing with the emergency spill. The method buildActionPlan,
shown in Figure 30 below, performs most of this. WERS – Code Tour Page 26 WERS – Code Tour Figure 30 – The buildActionPlan method of the Plan class The initial if-then statement in buildActionPlan decides whether to create a specific plan
or clone the default plan, based on whether the responder is recognized. WERS – Code Tour Page 27 WERS – Code Tour If the responder is recognized, buildActionPlan uses another if-then statement to either
generate the appropriate plan for a qualified responder or else generate a default plan. Figure 31 – buildActionPlan employs a series of if-then statements to determine how to build
the plan buildActionPlan also uses if-then for determining whether the area is recognized so that
distance calculations for the spill can be made. This is shown in Figure 32 below. Figure 32 – An if-then is also used to determine whether the area is recognized Your assignment is to re-work this code to replace the if-then statements with Java’s
exception handling features. For this assignment, you will not have the occasion to use the java
throw mechanism. You will implement exception handling using try, catch and finally. WERS – Code Tour Page 28

 


Solution details:
STATUS
Answered
QUALITY
Approved
ANSWER RATING

This question was answered on: Sep 05, 2019

PRICE: $18

Solution~000200197656.zip (25.37 KB)

Buy this answer for only: $18

This attachment is locked

We have a ready expert answer for this paper which you can use for in-depth understanding, research editing or paraphrasing. You can buy it or order for a fresh, original and plagiarism-free solution (Deadline assured. Flexible pricing. TurnItIn Report provided)

Pay using PayPal (No PayPal account Required) or your credit card . All your purchases are securely protected by .
SiteLock

About this Question

STATUS

Answered

QUALITY

Approved

DATE ANSWERED

Sep 05, 2019

EXPERT

Tutor

ANSWER RATING

GET INSTANT HELP/h4>

We have top-notch tutors who can do your essay/homework for you at a reasonable cost and then you can simply use that essay as a template to build your own arguments.

You can also use these solutions:

  • As a reference for in-depth understanding of the subject.
  • As a source of ideas / reasoning for your own research (if properly referenced)
  • For editing and paraphrasing (check your institution's definition of plagiarism and recommended paraphrase).
This we believe is a better way of understanding a problem and makes use of the efficiency of time of the student.

NEW ASSIGNMENT HELP?

Order New Solution. Quick Turnaround

Click on the button below in order to Order for a New, Original and High-Quality Essay Solutions. New orders are original solutions and precise to your writing instruction requirements. Place a New Order using the button below.

WE GUARANTEE, THAT YOUR PAPER WILL BE WRITTEN FROM SCRATCH AND WITHIN YOUR SET DEADLINE.

Order Now