My thesis project is about automatic evaluation of object-oriented design by means of automated code analysis; in other words evaluate the design of a program automatically.

I found the need for a tool that would allow to me to extract the code model from a program and then query over that model in order to extract information and metrics about the program's design.

The characteristics I was looking for in a code analysis tool where:

1. The code model extractor must process source code or intermediary code Java or .Net

   Rationale: If we are able to analyze bytecode or MSIL we can use the same tool for any language of the given platform.
   Acceptance Criteria: A proof of concept must be implemented that is able to extract the code model in the form of objects of the given platform.

2. It must possible to invoke the tool from within the code as objects, without having to go through a GUI or CLI.

   Rationale: This is to easily integrate the tools as part of another project without hassle or strange behavior (i.e. opening a GUI, etc)
   Acceptance Criteria: A proof of concept must be created that invokes the tool in a programmatic manner without using the CLI.

3. It must be able to provide:

   • Number of lines of code in a method, class or namespace (package).
   • Method calls between classes
   • Location of method calls between classes
   • Method and member signatures of a class
   • Enumeration of classes, abstract classes and interfaces

   Rationale: This features are needed in order to perform the code analysis, because that will provide the data we will measure and evaluate. With those features it is possible to obtain all the Chidamber & Kemerer metric suite which are fundamental for code analysis.
   Acceptance Criteria: A proof of concept that can obtain each and one of the listed items programmatically.

4. The extracted code model must be readable in-memory, directly or indirectly.

   • It is allowed for the tool to generate a file first and then read that file to generate an in-memory model

   Rationale: The code model must be representable in-memory in order to use for automatic evaluation.
   Acceptance Criteria: A proof of concept must be created where the code model is fully representable in memory.

This post is primarily to remind me of the concepts behind Extreme Programming. This post will help me remember that Extreme Programming is not just pair programming, TDD, reduced documentation, evolutionary design and reduced planning.

XP practices are actually the smallest piece in the puzzle, the guiding values and principles are what made Kent Beck come up with those practices.

(Human) Values => (Domain Specific) Principles => (Software Specific) Practices

Values of Extreme Programming

Values are intended to balance and support each other. Improving communication helps achieve simplicity by eliminating unneeded or deferrable requirements from today's concerns.

Values do not provide concrete advice about what to do in software development. Because of the distance between values and practices, for that Principles bridge the gap between them.

• Communication
  • Communication is important for creating a sense of team and effective cooperation.
  • The objective of communication is to transfer knowledge and information between the team(s).
• Simplicity
  • Simplicity is the most intensely intellectual of the XP values.
  • The objectives are to make a system simple enough to gracefully solve only today's problem and eliminate the waste of unnecessary complexity.
  • It is also important to remember that simplicity is contextual, the design must be understandable by the team working on it, otherwise it is pointless.
• Feedback
  • Change is inevitable in software development, therefore an XP team embraces change by giving high value to feedback.
  • XP teams strive to generate as much feedback as they can handle as quickly as possible.
  • They try to shorten the feedback cycle to minutes or hours instead of weeks or months. The sooner you know, the sooner you can adapt.
• Courage
  • Courage is effective action in the face of fear.
  • Doing something without regard for the consequences is not effective teamwork.
  • Courage alone is dangerous, in concert with other values it is powerful.
  • Examples: The courage to speak truths, to discard failing solutions and to seek new ones.
• Respect
  • The other four values point to one that lies below the surface: respect.
  • The contributions of each person on the team need to be respected. I am important and so are you.
  • Every person whose life is touched by software development has equal values as a human being.
• Others
  • Your organization, your team, and you yourself may choose other values. What is most important is aligning team behavior to team values.