Release date: Monday, 29.06.15 - Due date: Sunday, 05.07.15, 23:59

The lecture has now made its way from the “Requirements Engineering” to the “Implementation”.

So, let's compare the Analysis Model

• Use Case Diagram
• Analysis Object Model
• Sequence Diagram

with our actual implementation:

• CloudBakery2100Customer
  • Remark 1: To keep the task feasible we concentrate our effort on the customer application.
  • Remark 2: You might want to check out the project into your workspace.

a) List for the three use cases that are to a larger part implemented on the client the following information:

• Use Case Name
• Analysis Objects in the Analysis Object Model that realize this Use Case
• Implementation classes that correspond to this Analysis Objects.

b) Look out for differences and similarities and list them as well:

• Are there classes in the implementation that have no counterpart in the model?
• Are there classes in the model that have no counterpart in the implementation?
• Are there other differences, e.g. in the naming?
• Compare as well the dependencies in the model to the dependencies in the implementation!
  • Tip: Check out the imports of the Java files.

c) Review as well the sequence diagram:

• What are the differences and the similarities between the flow in the implementation and the model:
  • Remark: You can restrict your discussion to the part of the sequence diagram that takes place in the customer application.
  • Tip: You might want to start from the controller object. Which methods are called by the controller? Which methods of the controller are called by whom?

d) Let us assume that this software and the models would now be handed over to another team. Of course the next team would be happy to get understandable software and models from you. So let us assume you had a few days to make some corrections. Add to each of the differences you found a remark, whether you

• would keep the difference, or
• would change or correct the model, or
• would change or correct the implementation.

We'd like to get one short sentence per difference. You don't need to do the changes. We just want to learn from you, whether the differences are there for systematic reasons or whether they could be removed in a more perfect system.

We have an implementation of a class Rectangle that stores its coordinates in two instances of the class Interval, one for the horizontal and one for the vertical extension of the Rectangle.

1. Review the code below. Give us six ideas how to improve it. If you can name a bad smell somewhere, do it. Which refactorings would you apply? We won't count the suggestion to introduce getter-methods. (Maybe you understand later why (see 3)).
2. Give us for four cases the code that we would get after your refactoring.
3. (Optional) Reviewing your code after executing the refactorings, could you imagine why we suggest being reluctant concerning the introduction of getter-methods?

You can find the source code for this task (with a JUnit-test) as well in your repository in the project A12T47_Refactoring.

View.java

package gui;
import model.Rectangle;

public class View {
  public Rectangle rectangle;
  public void redraw() {
    System.out.println(rectangle);
  }
}

Rectangle.java

package model;
import static java.lang.Math.*;
import gui.View;

public class Rectangle {

  private Interval horizontal;
  private Interval vertical;
  private View view;

  public Rectangle(View view, int startX, int startY, int endX, int endY) {
    if ((startX > endX) || (startY > endY))
      throw new IllegalArgumentException("Parameters in wrong order.");
    this.horizontal = new Interval(startX, endX);
    this.vertical = new Interval(startY, endY);
    this.view = view; view.rectangle = this;
  }

  /**
   * Create an empty Rectangle with no location.
   */
  public Rectangle(View view) {
    this.horizontal = null;
    this.vertical = null;
    this.view = view; view.rectangle = this;
  }
 
  public Vertex getCenter() {
    if (horizontal == null)
      return null;
    return new Vertex((horizontal.start + horizontal.end) / 2,
        (vertical.start + vertical.end) / 2);
  }

  public boolean contains(Rectangle parameter) {
    if (parameter.horizontal == null)
      return false;
    if (horizontal == null)
      return false;
    // check whether the horizontal interval
    // contains the horizontal interval
    // in the other rectangle
    // AND
    // check whether the vertical interval
    // contains the vertical interval
    // in the other rectangle
    return ((horizontal.start <= parameter.horizontal.start) 
      && (parameter.horizontal.end <= horizontal.end))
      && ((vertical.start <= parameter.vertical.start) 
      && (parameter.vertical.end <= vertical.end));
  }

  /**
   * Enlarge the Rectangle just enough so that it contains the other
   * Rectangle. If the Rectangle was empty it gets the same extension
   * as the other Rectangle.
   */
  public void accommodate(Rectangle other) {
    if ((other == null) || (other.horizontal == null))
      return;
    if (horizontal == null) {
      horizontal = new Interval(other.horizontal);
      vertical = new Interval(other.vertical);
      return;
    }
    horizontal.start = min(other.horizontal.start, horizontal.start);
    horizontal.end = max(other.horizontal.end, horizontal.end);
    vertical.start = min(other.vertical.start, vertical.start);
    vertical.end = max(other.vertical.end, vertical.end);
    view.redraw();	
  }

  public boolean equals(Object obj) {
    if (!(obj instanceof Rectangle))
      return false;
    Rectangle other = (Rectangle) obj;
    if (horizontal == null)
      return (other.horizontal == null);
    return (horizontal.equals(other.horizontal))
        && (vertical.equals(other.vertical));
  }

  public String toString() {
    return "Rectangle(" + horizontal + " x " + vertical + ")";
  }
}

Tip: The automated refactorings in Eclipse are more effective if you use some tricks:

• Before extracting a method extract those expression you want to become parameters into local variables.
• Before moving a part of a method to another class, you should extract this part into an own method in the current class.
• If you need more tips: Ask on the mailing list!

Do you still remember your software vision? Fly over the (slides of the) lecture and describe in one or two sentences ideas from the lecture that you would use in your implementation (idea?/why?/how?). You get 0,5 points for each reasonable idea. We will count not more than three ideas per slide set and not more than 24 ideas (12 points) in total.

You may as well list up to three questions that the lecture did not answer for you.

Tell us in the following table how many test cases it needs to cover all statements, all branches, all paths or all basic paths:

	Control Flow 1	Control Flow 2	Control Flow 3	Control Flow 4
Statements
Branches
Paths
Basis Paths
	Control Flow 5		Control Flow 6
Statements
Branches
Paths
Basis Paths

Evaluation: 1 point for each control flow for which you gave all numbers correct.

• Prepare questions for the final lectures and tutorials, so that we may clarify what had not become clear till now.
• In the future, make best use of what you learned in the lecture. Challenge the ideas. Develop them further. Change them, if necessary. Reconsider them, if you are missing an answer to a problem, the lecture might have touched.
• No more advice here. Others have advice, like wearing sunscreen. Could be a useful tip these days.