Questions and Answers
1)
Suppose that you finish your game app, it’s in the Google Play store, and you
are making a small but steady income. Then the money suddenly stops and the
negative reviews pile up. Before long, you understand it is because the new
release of Android 6.0 is out on the street, and your app crashes all the time
even during simple operations that always worked before! In what ways might you
have suffered from Programming by Coincidence? What is your plan for solving
the problem?
Programming by Coincidence is the dependent on luck and
accidental success. To a programmer, this is a dangerous approach and should
always be discarded in favor of a reliable approach such as deliberate
programming. Coincidental programming is more dependent on luck and there are
several instances that this may appear such as due to minimal testing
(Pragprog.com, 2015). Coincidences should not be adopted in favor of
well-stipulated plans. In this scenario, the coincidental challenge arose due
to lack of proper evaluation and consideration of technological changes. Before
the release of any new or upgraded operating system, news are released to
prepare the stakeholders in the industry of any prevalent changes. Therefore, the
release of Android 6 must have been preceded by some educative news of the
imminent changes and what to expect and plan. However, to the programmer, this
variable was not taken into account. It is for this reason that the lack of
information positions the programmer in a programming by coincidence position.
Through an implicit assumption that the application will work in the same
manner in the new version as it did in the old version leads the developer to
suffer from programming by coincidence.
In such a scenario, the damage has already occurred. Simple
tasks no longer work in the new version. The foremost action is not to be a
slave to history (Pragprog.com, 2015). Code refactoring should be done and is
inevitable. The developer needs to be flexible and learn the changes present in
the new version, new rules, and concepts and program implementation principles
that have changed. After this, effort prioritization follows followed by a well
augmented plan that aims at deciphering the cause of the problem and providing
a plan for the challenge (Pragprog.com, 2015). The problems in this scenario
are better understood by evaluating how the program worked in the previous
version and projecting the reasons why it does not work in the new version. It
is paramount to determine the operating principles of the new version and
compare them with a conceptualization approach with those of the former
version. Doing this will ensure that the program is re-coded to adopt to the
new changes inculcated in the new version. Lastly being away of what one is
doing will enable the creation of a comprehensive application that is well
documented to handle operational errors.
2)
Earlier in the course, we discussed coupling and cohesion, and we tried to
factor out the rules of the Memory Game from the Android interface. In what way
does this change improve coupling and cohesion? How could we further improve
the coupling and cohesion of the classes that make up our game app?
Coupling is a matter of degree while cohesion is a matter of
relation. In the latter, when two variables or class are related, a change in
one causes a change in the other class that contributes to both adding new
value. Proper code structuring makes it adaptive, easier to change and maintain
in the future in the event that other externalities such as the operating
system change or get upgraded. Coupling and cohesion are two vectors that
address a number of design problems (Jha, Bali, Narula & Kalra, 2014).
Coupling as indicated in terms of degree invariably shows the extent to which
classes are interconnected. There are two types of coupling, loose coupling,
and tight coupling. Tight coupling implies that the levels are closely related
that they know the functions of each other. In this scenario, the rules of the
memory game dictate that the classes should be closely intertwined to save on
operational costs. The implication here is that the game parameters must
explicitly know the functionality of each other to save time and memory. In a
game, the users are more dependent on the response time of the game and the
design of the interface. It is inherently important for the developer to adopt
a tightly coupled approach that addresses this challenge. A change to the new
operating platform improves on the coupling but due to the compression, some
functions and methods of the game fail to work and coordinate.
Some of the ways that can be applied in the game app classes
to enhance coupling and cohesion include the elimination of inappropriate
intimacy. The removal ensures that harmful and tight coupling does not occur.
Increased cohesion will further ensure that the methods, data and functions of
classes are closely related in terms of functionality (Jha, Bali, Narula &
Kalra, 2014). When the levels are closely related, they will have well-outlined
roles in the game application. Cohesiveness and coupling can be achieved by
make divergent changes, feature envy, and shotgun surgery. The latter implies
that a logical function or idea id spread across multiple classes.
3) Testing;
Would you need to refactor your code? Use particular new tools?
Unit testing
Modules and individual units of the source code are tested in
this approach. In the Android game app, different groups that are independent
may be tested together prior to linking them with other modules, classes or
functions. Procedure, principles and use of data control are carried out in
this module to ensure that they cooperate to provide the desired output.
Different interfaces, procedures, functions and classes may be tested
individually in the app to ensure they work correctly. The testing should be done
prior to integrating the application. Such an approach reduces any future
errors once the units are combined together. For the application, the
programming interface will be used to test this outcome.
Integration testing
Units and modules are combined and tested as a group in this
approach. It is an intermediate level of testing that occurs after unit
testing, but before validation testing (Utting, Pretschner & Legeard,
2011). Code may be refactored to comply with the set standards. Either a
top-down or a bottom-up approach may be used to guarantee the satisfactory
performance of the application. The testing will be run both on the programming
environment and on the operating environment.
System testing
A test carried out on a completed system to ensure that it is
compliant with the set goals and objective of programming (Utting, Pretschner
& Legeard, 2011). For the Android project, this process would be tested
using different devices to ensure that it provides the expected result.
Different models of smartphones and tablets running the new Android version
will be used to enhance this testing model.
Interface testing
Testing the graphical user interface is essential to ensure
that the expected results are displayed. The front-end interface and the
backend interface are to be tested to ensure that the outcome of communicates
the system requirements. Security, documentation, hardware and software are
tested to guarantee a successful outcome (Ehmer Khan, 2011).
References
Ehmer
Khan, M. (2011). Different Approaches To Black Box Testing Technique For
Finding Errors.IJSEA, 2(4),
31-40. doi:10.5121/ijsea.2011.2404
Jha,
P., Bali, V., Narula, S., & Kalra, M. (2014). Optimal component selection
based on cohesion & coupling for component-based
software system under build-or-buy scheme. Journal Of Computational Science, 5(2), 233-242.
doi:10.1016/j.jocs.2013.07.003
Pragprog.com,
(2015). The Pragmatic Bookshelf | Programming by Coincidence. Retrieved 8 May 2015, from https://pragprog.com/the-pragmatic-programmer/extracts/coincidence
Utting,
M., Pretschner, A., & Legeard, B. (2011). A taxonomy of model-based testing
approaches.Softw. Test. Verify.
Reliab., 22(5), 297-312. doi:10.1002/stvr.456
EmoticonEmoticon