THE BCS PROFESSIONAL EXAMINATION Diploma April 2005 EXAMINERS REPORT Object Oriented Programming (Version 2) General
A truly disappointing outcome to this assessment. Disappointment for the examiners but, more importantly, even greater disappointment for the candidates. The pass rate (60%) and the overall average are some 5 points down from the last sitting (October 2004). The only consolation for the examiners is that 12 candidates have scores in excess of 70%, suggesting that if they are properly prepared then quality outcomes are possible. The response of the candidates suggested they were ill-prepared for the examination or did not have sufficient experience of the subject matter. In Question 1, for example, a candidate needs to be comfortable in using the various UML diagrams. They also need to be skilled at reading the knowledge contained in a UML diagram. This ability to interpret these diagrams is only achieved through regular usage. This paper gives a fair coverage of the syllabus. Therefore it is our intention that the next paper we author will have the same architecture and the same style of questions. Centres that prepare students should be advised of this and be aware of our observations here.
Question 1 1. The Unified Modelling Language (UML) class diagram in Figure 1 below models a software house that employs programmers and project leaders.
Figure 1
a)
Construct a UML object diagram showing one ProjectLeader and two Programmers working for the same SoftwareHouse. Give a short explanation of the diagram. If the two Programmers and the one ProjectLeader are present in the employees collection, then explain if the SoftwareHouse needs to distinguish between these differing types of developer.
(5 marks)
b)
(5 marks)
c)
Revise the above class diagram to introduce a Secretary class, representing an employee not involved in any software development activities. Explain the principal revisions that have been made to the diagram. Revise the above class diagram so that a ProjectLeader is given managerial responsibilities for a team of developers. In your scheme explain how a management hierarchy of ProjectLeaders would be possible. Revise the object diagram from part 1a) showing both Programmers being managed by the ProjectLeader.
(5 marks)
d)
(5 marks)
e)
(5 marks)
Answer Pointers
Question 1 (a) Mark This question examines Part 3 (Design) of the syllabus As a consequence of the specialisation hierarchy, both Programmers and ProjectLeaders are managed by the employees (role) set. 5
(b)
A distinguishing feature of specialisation used in OO systems is that the SoftwareHouse would not have to distinguish between either type. The methods describe by the class Developer can be sent to each without concern for what actual type they represent. Method overriding in the class hierarchy might result in differing behaviours, but the SoftwareHouse is not concerned with this. The first revision introduces the class Secretary as a subclass of Employee. Importantly, the SoftwareHouse class then forms a relationship with the Employee class so that Secretary, Programmer and ProjectLeader objects can be part of the employees set.
(c)
(d)
Here, a group of Developers are made team members of a ProjectLeader. Since both Programmer and ProjectLeader are subclasses of Developer, then a ProjectLeader may be a team member of another ProjectLeader.
(e)
Examiners Comments
There is strong evidence from the answers given, that the candidates are unable to interpret and infer the knowledge present in the class diagram. For example, when answering part (a) too many candidates included Developer and Employee objects! Further, the object diagram they presented mixed in class diagram elements such as specialisation! Candidates need practice of working with class, object, collaboration, sequence and use-case diagrams. They also need to demonstrate that they can interpret the information presented by such diagrams. The candidates were also poor at extending the class diagram as required in parts (c) and (d). For example, the Secretary class required in part (c) was correctly a specialisation of the class Employee but the relation between the SoftwareHouse and the Developer remained so that a Secretary could not be made and employee of the organisation. Part (b) did not seem to be understood. The question sought to identify that the SoftwareHouse did not need to distinguish between Programmers and ProjectLeaders since they would all be considered some kind of Developer and they would all engage in the same messages.
Question 2
2. a) Carefully distinguish between the terms subclass and superclass. When combined they give rise to a class hierarchy. Why is a class hierarchy important when modelling object oriented systems? What do you understand by the term abstract class? Draw a revision to the class diagram given in question 1, clearly distinguishing those classes that have been changed into abstract classes and explaining why they have changed. What do you understand by the term interface class? Offer a strong argument why object oriented software should be developed in terms of interfaces Revise the class diagram developed in part 2c) to show where interfaces would be introduced into the scheme. (6 marks) (5 marks) (2 marks)
b) c)
(6 marks) (2 marks) (4 marks)
d) e)
f)
Answer Pointers
Question 2 (a) Mark This question examines Part 2 (Concepts) of the syllabus A superclass represents a generalisation. A subclass is a specialisation of a superclass and inherits all the features of its superclass. This relationship can be repeated any number of times giving rise to a hierarchy of classes. Class hierarchies support code reuse and support object substitution whereby an object of a subclass can be used where an object of the superclass is required. An abstract class is used to establish other classes. There is no intention of making object instances of it. It is a way to guarantee that all subclasses share a common set of features. 5
(b)
(c)
Since there are no actual examples of Employee or Developer then we consider these as abstract classes.
(d)
A class in which none of the operations have a defined method and has no state information is referred to as an interface. All operations are deferred to subclasses to implement. Effectively, an interface presents only a specification of its behaviours.
(e)
Since an interface has no implementation then different subclasses can be defined with differing implementation strategies. Code written to that interface is then free to adopt any of the concrete subclasses, even where they differ in their implementation.
(f)
Introducing the interfaces EmployeeIF and DeveloperIF we can make the software more resilient to change.
Examiners Comments
Too many candidates answered part (a) by simply describing the relationship between a superclass and a subclass in a class hierarchy. Very few discussed code reuse, method redefinition, polymorphic substitution, etc. That is, few gave concrete illustrations of the consequences of this arrangement. Usually part (b) was correctly answered with deferred methods and no instantiation. Few candidates identified that an abstract class is used to establish other classes. Certainly, there seemed to be no clear idea of the purpose of abstract classes. Far too many candidates answered the final part by discussing GUIs. The question specifically asked for interface classes and far too many considered this to do with user interface issues.
Question 3
3. a) A guiding principle for object oriented development processes is that they should be: i) Use-case driven ii) Architecture centric iii) Iterative and incremental Explain what is meant by these terms. b) Discuss the impact that an iterative and incremental development process has on the testing activity. (5 marks) c) In the context of testing an object oriented system, explain what is meant by the terms: i) Unit testing ii) Regression testing (12 marks)
(8 marks)
Answer Pointers
Question 3 (a) Mark This question examines Part 4 (Practice) of the syllabus A use-case is a typical interaction between a user and the system under development. It is used to capture some functionality to be provided by the software system. For example, in a banking application a use-case may document that a requirement of the system is to support transactions on bank accounts, e.g. make a deposit. Similarly, in a word-processor application changing the font of some text might be presented as a use-case. Developing use-cases is a significant activity in the OOAD process. They can be used to communicate with clients, as statements of intent for developers and as specifications for the testing that should be applied to the system when it is under development. A process that is architecture centric makes the system's architecture the primary focus during development. A model, presented as various UML diagrams, gives different perspectives of the system. Some diagrams emphasize the static structure of the systems architecture while others capture some of its dynamic behaviours. Any software system is actually a model of a problem that exists in the real (or imagined) world. Therefore the more closely a software model corresponds to the actual problem then the more effective it will be. OOAD methods recognize this fact and use key abstractions (objects) taken from the problem domain as the fundamental building blocks for the software system. With this approach there is only one model of the system no matter what stage of development it is at. System development is a process that progressively adds more detail to the model until such time that it can be executed on a computer. Further, there can be different views (perspectives) of the model at any given point in its development. Each view has a specific purpose and uses only part of the information held in the full model. In this way multiple and easily understood views of a complex system can be presented. An iterative process aims to release a series of versions of the software. Each version augments its predecessor with some additional functionality. We need to ensure that each iteration has a clearly defined aim to avoid undisciplined development. Some iterations may not involve new designs but are concerned with refining or refactoring the model to enhance its quality or its usefulness. Within an iteration we conduct an incremental style of development in which we introduce small changes as the software is developed with the aim of minimizing any risk. More frequent testing than is normal is required. Typically, each increment and iteration gives rise to a testing activity. This puts testing at the forefront of the developers mind. Given the testing burden placed on the developer, it is likely that the testing process will be automated. Code should be written so that it is relatively easy to test. Ideally it should conform to a standard style and be easy to read and understand. The aim is to avoid introducing errors and to help a developer/tester/maintainer find them. 4 4 4
(b)
(c)
(i) The term unit testing refers to a test of individual parts of an application. In an objectoriented system a part would typically be a single method, a class or a group of classes. In any event unit testing should take place as soon as possible. There is no need to wait until the complete application has been assembled. (ii) A developer cannot assume that correcting errors does not introduce errors. Therefore he/she must re-run tests that have already been passed. This is referred to as regression testing. Its purpose is to ensure that a new iteration or increment still passes earlier tests. Typically there would be a test harness to automate this process.
Examiners Comments
Parts (a) (i) and (ii) elicited poor and very poor responses. Too many candidates seemed not to understand the role of the use-case diagram. The architecture centric question had a very poor response with few able to express its intent. Part (b) was intended to be an easy question and as a result it was answered reasonably well. However, it was clear from the responses to part (c) that few candidates were familiar with or regression testing. Many did not answer the question and described unit testing in general.
Question 4
4. a) Give definitions of the following: i) ii) iii) iv) v) b) abstract data type modular programming structured programming typed languages untyped languages
(15 marks)
Choose THREE of the above concepts and discuss how each has contributed to the development of object oriented languages.
(10 marks)
Answer Pointers
Mark Question 4 (a) This question examines Part 1 (Foundations) of the syllabus (i) A set of data values and associated operations that are precisely specified and are independent of any implementation. (ii) A style of programming in which large programs are written as several small subprograms. A subprogram is either a procedure or function. Each subprogram performs a single task and is normally short in length. A module is a grouping of related subprograms. A major benefit is the separation of concerns into modules. (iii) A technique for organizing and coding computer programs in which a hierarchy of modules is used. Normally, each has a single entry and exit point. Control is passed downward through the structure without unconditional braches to higher levels of the structure. 3 (iv) With a typed language checks that the rules pertaining to the use of a certain type (datatype) are possible. Typically checking is done statically by the compiler. The extent to which the rules are enforced are determined by whether it is strongly or weakly typed. For example, with strong typing if a parameter is specified to be of a certain type then the actual parameter must be of that type. With weak typing a subtype of the formal parameter would be acceptable. Typing brings confidence that during execution there will be no surprises. However the price to pay is flexibility. (v) With an untyped language checks made that each call can actually be executed are relaxed. Often any checks made are made at run-time i.e. dynamically. This means that the programmer has a great deal of flexibility in the code that is written. However the price to pay is one of safety. (b) The ADT leads to the class (a concrete data type) and objects (instances of the type) represented by the abstractions of the problem domain. Prior to the advent of OO, code was typically organized as a collection of modules, each consisting of a collection of subprograms. Modular programming leads the notion of a set 3
3 3
of related operations for a class. Structured programming leads to method bodies with sequence selection and repetition control structures. The ideas inherent in the use of typed languages lead to polymorphism in OOPs. Some of the constraints of typing are relaxed but some important compiler checks are still possible. For example, checks on the type (class) the actual substitutions made. The same applies to casts. This gives us the balance between type safety and flexibility. Experience with untyped languages leads to the desire to relax typing rules because they are so flexible. For example, in Smalltalk and Java there is the class Object that is the root of all classes. 4
Examiners Comments
Part (a) of this question was intended to be relatively straightforward and it proved to be so. It was in fact one of the few questions that seemed to be answered well by most of the candidates. Part (b) by contrast was disappointing with many of the students missing the point of the question.
Question 5
5. a) b) Briefly explain what is meant by the term, Design Pattern. Explain how an understanding of Design Patterns helps the following people: i) computing students ii) inexperienced software developers iii) experienced software developers iv) software maintainers Describe a Design Pattern with which you are familiar. Your answer should include the motivation for the existence of the Design Pattern, its structure, participants and consequences of its use. (3 marks)
(12 marks)
c)
(10 marks)
Answer Pointers
Question 5 (a) (b) Mark This question examines Part 3 (Design) of the syllabus A solution to a problem in a context. A design pattern captures in an elegant fashion examples of best-practice as practiced by expert software developers over many years. (i) Design patterns illustrate how certain types of problem should be approached. This shortens the learning curve and acts as an excellent source of exemplars. Typically the documentation for a Design Pattern has code samples. Again they should what can/should be done. Discussions of the forces that are taken into account are also very useful from an educational point of view. (ii) Exposure to Design Patterns builds on experience already gained. It may even give confidence that an inexperienced designer was doing it right all along. More likely it will widen the developers horizons and make it easier to start or take part in a major project. In this respect the discussion of the advantages/disadvantages/implications/related patterns are particularly useful. 3 (iii) Design Patterns provide a useful vocabulary for experienced developers. It allows them to communicate at a high level of abstraction without having to worry about unnecessary detail. They have access to a library of properly documented, tried and trusted Design Patterns. It is even possible that they may introduce new Design Patterns and pass on their experience to others.
(c)
(iv) Maintenance programmers find it easier to understand what the software does if they understand the Design Patterns on which the software is based. It also helps them make sensible modifications if they appreciate the overall intent and structure of the design. A typical Design Pattern selected would be Decorator, Iterator, Observer or Singleton. For example:
Observer
Motivation There is a need to maintain consistency among co-operating objects. However they must not be tightly coupled as they become less re-usable. Structure 2
Participants Subject knows its observers and provides an interface for attaching/detaching observers. Observer defines an updating interface for objects that should be notified of changes. ConcreteSubject stores state that is of interest and notifies observers of state changes. ConcreteObserver references a ConcreteSubject, stores its own state that should be consistent with the Subjects and implements the Observer updating interface. Consequences Subjects and observers can be varied independently. Therefore subjects can be re-used with re-using their observers and vice versa. It lets you add observers without modifying the subject or other observers.
Examiners Comments
This was a popular question and it was clear that many of the candidates had been well prepared for parts (a) and (c). It was mainly book work. However, it was refreshing to find that many candidates managed to use their knowledge of Design Patterns to answer part (b).
Question 6
6. a) A requirement of object oriented systems is to manage a collection of objects. i) Describe how collection classes are used to realise this requirement. ii) Give examples of two collection classes with which you are familiar. iii) Explain how a particular collection class might maintain its objects as an ordered collection. (12 marks) b) Using a suitable example, explain the essential differences between specialisation and delegation. You should use a programming language of your choice to illustrate your answer. Consider the following scenario: A class Vector is a collection class that holds its elements in the order in which each element is added. Each element has a unique index associated with it. Indices start at 1 and increase by 1 each time a new element is added. For example, the first element added has an index of 1, the second 2 and so on. The Vector class also has a method get that is used to retrieve a particular element from a Vector. When supplied with an integer representing an index, the method get returns the element with that index. For example, get(1) would return the first element in the Vector. You are required to use the Vector class in the construction of a Queue class. This new class should mimic a queue. As with the Vector, it holds its elements in the order in which each are added. However it has a method front to return the first element added i.e. the element at the front of the queue. It also has a similar method back to return the last element added i.e. the element at the back of the queue. Crucially, it should not be possible to access elements at intermediate positions in the queue. Discuss whether you should you use delegation or specialisation to develop the Queue class. Give a detailed explanation of the reasons for your decision. As before, you should use a programming language of your choice to illustrate your answer.
(5 marks)
c)
(8 marks)
Answer Pointers
Question 6 (a) Mark This question examines Part 2 (Concepts) of the syllabus (i) The collections classes are used to maintain a reference to a collection of objects. They are frequently required by OO applications such as the employees that work for the software house in Q1. The collection classes include the Java container library and the C++ STL containers. These classes remove the burden of maintaining the object collection. (ii) Java supports the ArrayList and the TreeSet. The former maintains the items in the order they are entered into the collection. The TreeSet collects its items in some determined sort order. (iii) A container such as the Java TreeSet maintains a sorted collection of objects. This it does, not by knowing how to sort the items. This would restrict the container to a certain sorting scheme. Rather, the container relies on the objects to conform to a Comparable interface so that the objects can be sent the compareTo message from which the ordering is determined. With specialisation, a child (subclass) inherits all of the features (methods and attributes) of its parent (superclass). Only one object exists. However, with delegation object composition is used. The delegate is held as an attribute (variable) i.e. two objects exist. Therefore a message received by an object can be delegated (relayed) to a delegate. For example using Java, we might have:
public class Parent { public Parent() { // }
(b)
public void operation_1( ) { // } public void operation_2( ) { // } public void operation_3( ) { // } // ... } public class Child extends Parent { public void operation_1( ) { // } public void operation_2( ) { // super.operation_2(); }
// replaced
// redefined
} and
public class Delegator { public Delegator(Delegate aDelegate) { theDelegate = aDelegate; } public void operation_1( ) { // } public void operation_2( ) { // theDelegate.operation_4(); } public void operation_3( ) { theDelegate.operation_5(); } private Delegate theDelegate; // ... } public class Delegate { public void operation_4( ) { // } public void operation_5( ) { // } // }
(c)
(ii) Specialisation would not be appropriate. The main reason is that it is not possible to disinherit a method. In this case the inherited method get that takes an index as a parameter does not apply to a queue. It would be possible to redefine it but this is not really acceptable. A much better solution is to have a Vector attribute in the Queue class and delegate to it when implementing the front and back methods. For example, using Java we might have:
public class Queue { public Queue() { theVector = new Vector(); } public Object front() { return theVector.get(1); } public Object back() { return theVector.get( theVector.size() ); } public void add(Object element) { theVector.add(elelment) }; // private Vector theVector; }
Examiners Comments
This question was not attempted by many candidates. A similar observation was made at the last sitting. Seems that candidates do not like questions with too many words! Part (a) invariably produced a collection of methods as the answer! Given that most OO solutions involve collections of objects it was expected that the candidates would be comfortable with the basic container classes needed to answer this question. On reflection, parts (b) and (c) might have been too challenging for the candidates. However, several did manage to give good answers.
