Software Engineering

Unit 1: Questions

Team 2

February, 2021

1
 1 QUESTION AND ANSWERS

1 Question and Answers

1. Does pair programming reduce the need for refactoring? Support your argument with appro-
priate evidence.

Pair Programming:
Pair programming is a method of software development, where two developers work using a
single machine. Both developers can control the machine via their personal keyboard and
mouse. There are two roles: Driver and Observer. The developer who is the “driver”
writes the code whereas the “observer” proofreads and checks the code being written by the
driver and plans what to do next. These roles are not fixed and can be changed throughout
the course of the development process.

Refactoring:
Refactoring means improving the internal structure of a source code without changing its ex-
ternal structure or behavior. Making the code more modular, easily readable, having required
abstractions, removing code duplication and bugs are few of the code refactoring methods.

How does Pair Programming reduce the need for refactoring?

• Since there are two developers working on a single code base simultaneously, it is highly
likely for gross code bugs and mistakes to be caught in real time rather than later while
executing the code.
• Since there are two people involved, it leads to a better code design and structure which
reduces the load of post code refactoring.
• Since it is common for coders to make simple syntax or logical errors while coding fast,
having another person constantly observing and checking the code reduces the occurrence
of such mistakes.
• Since the roles of developers are changeable in pair programming, it will reduce the
burden and monotony of having to code continuously coding and hence also reduces the
mistakes and need for refactoring.

2. In “No Silver Bullet – Essence and Accidents of Software Engineering” by Fred Brooks, the
author claims “there is no single development, in either technology or management technique,
which by itself promises even one order of magnitude improvement within a decade in pro-
ductivity, in reliability, in simplicity”. List arguments to support/contradict his claim.

No Silver Bullet:
• According to Brooks, there are mainly two types of complexities in software development
and software engineering:
– Accidental Complexity: This category of complexities consists of complexities
created by engineers and hence are also solved by the engineers only. The complexity
caused by choosing an outdated tool or framework are in this category and can be
solved by making the right choices at the engineering end.

2
 1 QUESTION AND ANSWERS

– Essential Complexity: This category of complexities consists of complexities

which are inherited by the problem itself. If the problem is inherently hard to solve,
no amount of expertise in the can make it easy and hence cannot reduce the essen-
tial complexity. An example would be that writing a new Facebook is inherently (or
essentially) more complex than writing a “hello world” program.
• What Brooks argues is that with the advancement of hardware and speed we have
certainly been able to reduce the accidental complexity by a huge margin. The computers
in last couple of decades have become much smarter, faster and efficient.
• However, we haven’t been able to reduce the essential complexity by that margin so
far. What he meant by this is, introduction Ada programming language or C++, java
like object-oriented programming languages did reduce essential complexity, but since
the introduction of these languages and technologies few decades ago, we haven’t seen a
huge improvement in them as much as we have seen in terms of hardware.
• Brooks argues that we have focused so much on solving the accidental complexity that
what we are left is mainly the essential complexity and hence we can’t see ten folds
improvements in future decades in software development because essential complexity
cannot be reduced effectively.
• And hence, Brooks says that we can’t expect to have a “Silver Bullet” which will solve
all the problems and need to think systematically about solving the essential complexity
along with the accidental complexity.
3. The C++ implementation of class Adapter specifies the use of multiple inheritance. Using a
diagram show how this could be implemented in Java? Be specific about the Java features
that you are using.

Adapter design pattern

Design for Adapter Implementation in Java

3
 1 QUESTION AND ANSWERS

Since multiple inheritance is not supported in Java, the following features are used for the
implementation of Adapter:
• Abstraction: By using interfaces.
• Inheritance: The adapter class inherits from the interface that the existing codebase
conforms to.
• Composition: The adapter class composes of the existing service class that it tries to
adapt to the expected interface.
4. One method of classifying iterators does so along two dimensions. The first indicates the
location of control of the iteration (internal to the iterator or external client control), and
the second which indicates the location of the definition of the iteration logic (embedded as
part of the collection objects or in objects separate from the collections). Considering each
dimension separately, what are the positive and/or negative aspects of iterators of each type?

Iterator is a behavioral pattern or an interface in collection framework used to traverse el-

ements one by one. Using iterator, underlying collection object representation will not be
exposed. Collection object can be tree, hash, graph, complex data structures, array list etc.,

There are three types of iterators in java collections which are Enumerations, Iterator and
List Iterator.
Enumeration – It is an interface, the first iterator introduced in java and can only support
collections like vectors or hash tables and these two collections are inheritance collections.
Used only for forward navigation and elements cannot be deleted using enumerator.
Iterator – This type is an advanced variant of enumeration and this is designed to support
all types of collections, but this type also only supports forward navigation.
List Iterator – This type is applicable for list type collections such as array list, double
linked list, linked list and so on. It has capability to process elements in bidirectional manner.
Iterators are classified in two dimensions, location of iteration control and location of iteration.
• Location of Iteration control
– Control is external to iterator – Iteration client has control.
∗ Client should drive iterator and process each object. So, operations like list
comparisons have more flexibility than internal iterator.
– Control is internal to iterator – Iterator has control.
∗ An operation is provided to iterator to apply each element. It is easy to use
because logic is defined by internal iterator only.
• Location of Iterator
– Iterator is embedded in collection object.
∗ Advantage – Its intact encapsulation of collection object.
– Iterator is separate class from collection class.
∗ Advantages:
(a) Without any worry it is possible to separate collection structure and traversal.

4
 1 QUESTION AND ANSWERS

(b) From the traversals such as forward, backward, and bidirectional only neces-
sary one can be used.
(c) We may also perform multiple traversals at a time.

5. What language constructs would you use to give iterators privileged access in Java and in
C++? How will your answer depend on the classifications for iterators given above?
Any programming language comprises of tokens and structures. Tokens(words) are used to
construct as per rules or structures of programming language. The examples of language
constructs are data types, keywords, operators, methods, literals, class libraries etc.,

An iterator may need privileged access to the aggregate structure for traversal.

Language construct operations such as First (), Next (), IsDone(), Current Item (), Previous
() and Skip To () in java or in C++ have it in iterator class which is an extension of aggregate
class. Each required operation in iterator class must be protected while accessing them. To
gain privileged access to aggregate class the iterator sub classes may use protected operations.
In C++ Polymorphic iterators rely on factory methods to instantiate the appropriate Iterator
subclass.
6. Draw sequence diagrams for the registration and update cycles of an Observer pattern imple-
mented using appropriate Java classes. Be sure to label the object with the Java class and its
role in the Observer pattern using Stereotypes.
Sequence diagram for Observer Pattern with reference to Java classes:

5
 1 QUESTION AND ANSWERS

Sequence diagram for registration and update cycle of an Observer Pattern

Observer is a behavioral design pattern. It specifies communication between objects: observ-

able (the subject) and observers. An observable is an object which notifies observers about
the changes in its state.

• The observer pattern requires that a subject notify all its observers about its change in
state. In return, the observers get the updated state from the subject.
• observers can be attached to an existing subject while they can also detach themselves
from the subject.

Implementing Observer pattern in Java:

(I) Observable:
The java.util.Observable class is used along with Observer instance to implement the
Observer pattern. A class whose changes are to be tracked by the observers, extends the
java.util.Observable class. This class has implemented methods for updating/notifying
the Observers about the changes made to the Observable. It also provides method to
the Observer instances to hook on with itself, or unhook. Following are methods in the
java.util.Observable class are:
• public void addObserver(Observer o): Add an Observer.

6
 1 QUESTION AND ANSWERS

• public void deleteObserver(Observer o): Delete an Observer.

• public void notifyObservers(): notify observers of changes.
(II) Observer:
The java.util.Observer class is used to create an instance of an Observer. Its update()
method is required to be overridden by the class inheriting the Observer class.

The sequence diagram:

The UML sequence diagram shows the run-time interactions of the objects involved. The
Observer1 and Observer2 objects call attach on Subject to register themselves. If the state
of Subject1 changes, Subject1 calls notifyObserver() on itself. notify Observer () calls up-
date() on the registered Observer1 and Observer2 objects, which request the changed data
(getState()) from Subject1 to update (synchronize) their state.
7. You have seen that it is very common to use the Observer pattern within GUI frameworks,
such as Java’s Swing framework. Why do you need to be concerned about how long it takes
to process a notification by a GUI element? Should this be the application designer’s concern
or be dealt with by the framework itself? How can the concern be eliminated?
Importance of time taken by GUI to process a notification:
When a change is made to the GUI element, the entities which are referring to the GUI element
must also reflect the changes accordingly, since it is important to maintain consistency between
these related elements.
Responsibility of designer or the framework:
The time it takes to process a GUI notification should be the concern of the framework as
the changes made through GUI needs to be processed by the Observable entity and notified
to all the Observer entities. This is the responsibility of the framework.
How to eliminate this concern: The Observer pattern
It would be time consuming for an element to send individual updates to the elements which
are related to it. The Observer pattern provides support for broadcast communication. Unlike
an ordinary request, the notification that a subject send, need not specify its receiver. The
notification is broadcast automatically to all interested objects that subscribed to it. The
subject does not care how many interested objects exist; its only responsibility is to notify its
observers. With such an implementation, the time taken to update the related entities when
change in “state” of some element occurs, is handled efficiently without having to send the
changes individually.
The Java Swing model:
Swing models use the JavaBeans Event model for the implementation of the notification
processing. The Model sends a lightweight notification that the state has ”changed” and
require the listener to respond by sending a query back to the model to find out what has
changed.
The Models are based on the ChangeListener/ChangeEvent APIs. The ChangeListener in-
terface has a single generic method:
• public void stateChanged(ChangeEvent e)

7
 1 QUESTION AND ANSWERS

Models use following methods to add and remove ChangeListeners:

• public void addChangeListener(ChangeListener l)
• public void stateChanged(ChangeEvent e)
The above clearly describes use of Observer pattern by the Swing model to process notifica-
tions of change in states of GUI elements.
8. Argue both for and against including the functions to handle the Composite’s children in the
Component interface. What are the implications for implementation of the pattern and on
the intention of the pattern?

Let us call the functions of interest ‘execute’(eg. traverse) and functions for handling children
as ‘handlers’(eg. Add, remove, getChildren).

• Alternative 1: Including the ‘handlers’ in the Component interface.

– Pro: This allows us to generalize the common interface of Leaf and Composite to
‘handler’ functionalities too other than ‘execute’.
– Con: This will lead to the need for including error checking and logging in case of
’handlers’ being called on leaves.
– Intention-wise: This does a pretty good job of providing a common interface for
‘execute’ as well as ’handler’ functions without the need for any information of the
structure of the object being operated upon.
– Implementation-wise: This will require additional implementation of error handling
in leaves for ‘handler’ functions and will also lead to the need for logging these errors.
• Alternative 2: Including the ’handlers’ in the Composite class.
– Pro: This will eliminate the need for error checking and logging in ‘handlers’ as they
can only be called on composites and not leaves.
– Con: If a need arises, for the client to use the ‘handlers’ (rarely) then they would
need to look into the structure of the Composite class.
– Intention-wise: It still does a pretty good job at living up to its promise but in the
rare cases mentioned in the con, they might fail.
– Implementation-wise: Eliminates the need for error checking and logging in ‘han-
dlers’.

Therefore, if it is expected that there will be a considerable number of leaf elements, then
Alternative 2 can be opted as it will eliminate unnecessary logging of errors. On the other
hand, if ‘handlers’ are expected to be accessed by the client, then Alternative 1 can be opted.