2008 Exam answers

Revision as of 04:52, 17 July 2009

Question 1

Possible improvements to the design:

• Replace the Pair class with a Transaction class and two subclasses CreditTransaction and DebitTransaction. These classes will contain the information that was contained in Pair, and any other behavior related to transactions which is likely to have leaked out into the rest of the system.
  • Currently, the Pair class is used to keep track of the Stock a Stockholder owns (price and date of purchase or sale) and to record transactions (the stock that was traded and the date of the trade).
  • Violations:
    • Behavioral completeness - The Pair class currently only acts as a data container but does not contain the behaviour related to that data.
    • One key abstraction - Pair currently does not capture one particular domain concept but tries to do several things at once. This is also related to Single responsibility principle.
    • Separation of concerns - Pair should only have one particular responsibility but at the moment fulfills several. These should be separated.
• Replace Stock class with CompanyStock and OwnedStock. These classes will not share a common super class as they differ greatly in what they represent.
  • The Stock class currently tries to represent both a single share (OwnedStock) and the master share with information about the stock for a particular company (CompanyStock).
  • Violations:
    • Single responsibility principle - The Stock class tries to represent two very different concepts at the same time.
    • One key abstraction
• Broker and StockHolder should both hold a reference to an Account object. This would replace the brokersAccount property of Broker. The Account class would manage Transactions and include a reference to the account holder (Broker or StockHolder).
  • Violations: Single responsibility principle
• Broker and StockHolder should both hold a reference to ContactDetails object. Alternatively they could both inherit from a Person class, but if we favor composition over inheritance this would seem the less preferred solution. This also wouldn't be a good solution if a Broker can be a company as well as a person. This would allow personal details of Brokers and StockHolders to be stored. In the current design the notion of a Person is mixed with that of an Account. The improved design separates these two and would allow someone to have multiple accounts.
  • Violations: Single responsibility principle
• Once the notion of a person (Stockholder) and an account has been separated, all the accounts for one particular person can be stored as a Set by the object representing the person.
  • At the moment, accounts are chained together through the next link in the StockHolder class. This further shows that two different concepts have been muddled up. This also means that redundant data will be stored since for each account the data for the person is stored separately, rather than that data being stored only once.
  • Violations:
    • Single responsibility principle
    • Separation of concerns
    • One key abstraction
• The trades field should be moved out of the GUI class. The GUI should concentrate on the visual display of information rather than recording trades and transactions.
  • The trades field could potentially be moved to the Broker class to record the trades made by one particular Broker.
  • Violations:
    • Separation of concerns
    • [[Single responsibility principle]
    • The GUI is part of the presentation layer of the program while the trades field belongs in the Business layer. The two should not be mixed.
• The Price class should not be a subclass of Stock. This inheritance relationship makes no sense in the given domain as the two concepts are totally different. The Price class has very different behaviour and data and should therefore not inherit from Stock.
  • We can easily see that the inheritance relationship makes no sense in this case because the behaviour of the Stock class (which is inherited by Price) makes little sense for a Price object.
  • Violations:
    • Liskov substitution principle - A Price object cannot be used where a Stock object is expected.
• Decouple the Broker from the GUI. This could be done using an observer design pattern.
  • At the moment, the Broker calls on the GUI to display itself. Broker contains a display method which knows about different ways of displaying a Broker. This behaviour does not belong in the Broker class but in the GUI. The GUI is the only part of the system which should be concerned with displaying information.
  • Violations:
    • Separation of concerns

Question 2

a) A maxim that contrasts with the culture of software reuse

• I think that You ain't gonna need it potentially conflicts with the culture of software reuse. YAGNI basically says not to worry about functionality or a fancy design that you don't really need yet. On the other hand, in order to achieve software reuse you need to develop modules in a very general way, keeping in mind possible future needs. -- Janina

b) A maxim that might be measured automatically by software tools

• There are a lot of maxims like this that can be measured automatically. I think essentially any maxim which can be evaluated by simply looking at the syntax of a program or the relationships between parts of a program can be easily measured. Examples include:
  • Acyclic dependencies principle - This is easy to measure by looking at which parts of the program depend on each other.
  • Avoid downcasting - This can be easily measured by looking for casts that go down the inheritance hierarchy.
  • Law of Demeter - This can be measured by looking at method calls to check that they all comply with the law
  • ...

c) A maxim that can never be measured automatically be software tools

• Again, there are a number of principles that we will probably never be able to measure properly. Especially maxims which require an understanding of the domain semantics will be very hard to measure directly, though it is possible that we may be able to measure them indirectly through some metric. Examples include:
  • Model the real world - Evaluating whether this maxim has been followed requires domain knowledge.
  • Single responsibility rule - Again, domain knowledge is required to measure this one though we may be able to indirectly measure the effects that not following this rule has on our program.
  • Premature optimization - This would require knowledge about when a system is fully working, what constitutes optimization etc which is likely to be hard to automate.
  • ...