Manuel Pichler

This new release of PHP_Depend took some time to be finished. This is because the initial idea of a simple adaption of JDepend evolved (supported thru this blog-post by Sebastian), and so PHP_Depend has become a complete software metric application. Many new features and enhancements have found their way into this version. One of the key features is the pluggable architecture for custom Loggers and Metric-Analyzers. This opens the possibility to hook own Logger- and Analyzer-implementations into the execution chain of PHP_Depend. Beside these architectural changes this PHP_Depend version is shipped with a large set of implemented software metrics.

ClassLevel (Class)

• dit: Depth of Inheritance Tree
• impl: Number of implemented interfaces
• cis: Class Interface Size
• csz: Class SiZe
• vars: Number of defined class properties
• varsi: Number of own and inherited class properties
• varsnp: Number of public class properties
• wmc: Weighted Method per Class(Sum of method Cyclomatic Complexity)
• wmci: Weighted Method per Class + inherited WMC
• wmcnp: Weighted Method per Class for all public class methods

CodeRank (Class, Package)

An adaption of google's PageRank algorithm for classes and packages.

• cr: Forward CodeRank (based on incoming edges)
• rcr: Reverse CodeRank (based on outgoing edges)

Coupling (Project)

• calls: Number of called methods and functions
• fanout: Number of referenced types

Cyclomatic Complexity (Project, Method, Function)

• ccn: Cyclomatic Complexity
• ccn2: Extended Cyclomatic Complexity

Dependency (Package)

For details see the following entry.

• ca: Afferent coupling
• ce: Efferent coupling
• a: Abstraction
• i: Instability
• d: Distance

Hierarchy (Project)

• clsa: Number of abstract classes.
• clsc: Number of concrete classes.
• roots: Number of root classes within the analyzed system.
• leafs: Number of leaf classes.
• maxDIT: Max Depth of Inheritance Tree value

Inheritance (Project)

• andc: Average Number of Derived Classes.
• ahh: Average Hierarchy Height

NodeCount (Project, Package, Class, Interface)

• nop: Number Of Packages
• noc: Number Of Classes
• noi: Number Of Interfaces
• nom: Number Of Methods
• nof: Number Of Functions

NodeLOC (Project, Package, Class, Interface, Method, Function)

• loc: Lines Of Code
• cloc: Comment Lines Of Code
• ncloc: Non Comment Lines Of Code

Due to the fact that PHP is a loosely typed programming language, PHP_Depend can only approximate some values. But the measured results can be improved with a good and complete source code documentation, because PHP_Depend takes advantage of different doc comment annotations (@throws, @var, @return). So I suggest the use of a tool like PHP_CodeSniffer, to achieve better results.

Beside all these metrics, PHP_Depend also provides a new chart type, the "Overview Pyramid". The Overview Pyramid can be a handy tool to analyze legacy code. If you have read the book Object-Oriented Metrics in Practice you should know howto interpret the Overview Pyramid, all others have to wait for a detailed description.

PHP_Depend Overview Pyramid for PHP_Depend

This new version can be installed with the PEAR-Installer. Just discover the pear.xplib.de channel and install the latest PHP_Depend release. After PHP_Depend has been installed successfully, the new command line tool pdepend should exist.

 mapi@arwen ~ $ pear channel-discover pear.xplib.de
 mapi@arwen ~ $ pear install xplib/PHP_Depend-beta
 mapi@arwen ~ $ pdepend --help
 PHP_Depend 0.8.0beta1 by Manuel Pichler

 Usage: pdepend [options] [logger] <dir[,dir[,...]]>

   --jdepend-chart=<file>    Generates a diagram of the analyzed packages.
   --jdepend-xml=<file>      Generates the package dependency log.

   --overview-pyramid=<file> Generates a chart with an Overview Pyramid for the
                             analyzed project.

   --summary-xml=<file>      Generates a xml log with all metrics.

   --coderank-mode=<*[,...]> Used CodeRank strategies. Comma separated list of
                             'inheritance'(default), 'property' and 'method'.

   --suffix=<ext[,...]>      List of valid PHP file extensions.
   --ignore=<dir[,...]>      List of exclude directories.
   --exclude=<pkg[,...]>     List of exclude packages.

   --without-annotations     Do not parse doc comment annotations.

   --help                    Print this help text.
   --version                 Print the current PHP_Depend version.

There is also a Subversion repository at http://svn.pdepend.org/, where the latest development version can be found.

Please test this beta release and file bug-reports and feature-requests in the PHP_Depend bug tracker.

To provide a flexible and extendable software, it is a good OO practice to reduce the dependencies between implementing classes. This could be achieved by developing against abstractions which means both, abstract classes and interfaces. By using abstractions instead of real implementation in the application you provide some sort of contract, that could be used by others to hook into the application with their own classes that fulfill the contract. Except the extensibility of an application a good abstraction reduces the risk of breaks in multiple subsystems when something was changed in a single package. But how to get rid of all these dependencies, doing this by hand will become an impossible job, at least for larger projects. At this point a tool should be used to assist the development process.

PHP_Depend is an adaption of the established Java development tool JDepend. This tool shows you the quality of your design in the terms of extensibility, reusability and maintainability. All these facts are influenced by the inter-package dependencies and the package abstraction that PHP_Depend visualizes in form of an abstract/instability chart and as a detailed XML report of all detected dependencies.

PHP_Depend calculates the following metrics by counting classes, interfaces and dependencies.

Ca - Afferent Couplings:

The number of other packages that depend upon classes within this package. This value is good indicator how changes to classes in this package would influence other parts of the software.

Ce - Efferent Couplings:

The number of other packages that classes from this package depend upon. This value indicates how sensitive this package is for changes to other packages.

I - Instability:

The ratio between efferent coupling (Ce) and the total package coupling (Ce + Ca) which is based on the following formula (Ce / (Ce + Ca)) and produces results in the range [0,1]. A value I=0 indicates a maximally stable package that depends upon nothing and I=1 indicates a total instable package that has no incoming dependencies but depends upon other packages.

A - Abstractness:

The ratio between abstract classes (ac) and the total of all classes (ac + cc) that is calculated by this formula (ac / (ac + cc)) that results in a value in the range [0,1]. A=0 means that all classes in this package are non-abstract while A=1 shows a package that only consists of abstract classes and interfaces.

With these values we can create a chart that visualizes the relationship between the instability (I) on the y-axis and the abstraction (A) on the x-axis.

Graphical view of PHP_Depend metrics

Because in a project not each package can achieve the optimal values of A = 1, I = 0 or A = 0, I = 1, we draw a diagonal between the two corners. This line is called the Main sequence and represents an average between abstraction (A) and instability (I). This means that packages near this line have a good mix between abstraction and instability. You can call these packages balanced. Because it is desirable for packages to be close to the Main sequence we have a fifth metric, the package distance (D) from this ideal.

D - Distance

The normalized distance has a value in the range [0,1] and is calculated by the formula ((A + I) - 1)

If you are interested in this subject and PHP_Depend you can check out the latest version, including the unit tests, from the subversion repository or simply install the PHP_Depend PEAR package. But be aware this software is at a very early stage.

mapi@arwen $ pear channel-discover pear.xplib.de
mapi@arwen $ pear install xplib/PHP_Depend-alpha

Now you can run PHP_Depend with the following command.

pdepend <source-dir> [<output-dir>]

If you are interested in the code coverage follow this link .

I will close this post with a cite of Robert Martin:

However, a metric is not a god; it is merely a measurement against an arbitrary standard.

The following sources were used for this post.

• OO Design Quality Metrics - An Analysis of Dependencies
• Managing Your Dependencies with JDepend
• JDepend

During the last weeks while I have read some documents about the model view controller pattern (MVC), which seem to be wrong in my eyes or better expressed, which mix and merge different application layers in a wrong way, I decided to write this blog post. Everybody who reads this text should know for what the shortcut MVC stands. It describes the responsibilities and dependencies between model, view and logic in the top level layer of an application. As I understand it, this means all parts in the presentation layer and nothing else. But most documents wrote about business logic, when the topic controller is treated, and this assertion is wrong in my opinion. Business logic and business models aren't part of the presentation layer, they build a further layer in an application. Keeping each layer independent, means that the presentation should know as few as possible about the underlying business logic.

Because practice is more understandable than all written text, I would like to explain my thoughts with a little example. The following diagram shows a simple business modell for a product catalog which implements a transaction based product storing. Beside the business classes you can find all possible exceptions in this diagram.

The class mpProduct provides the context model in this example, a simple object which only consist of the product name. mpProductCatalog is some sort of list object that is wrapped around the underlying storage as it occurs in most applications. The mpProductTransaction class can be used to encapsulate a product modification until it is persistent stored in the mpProductCatalog-instance. Finally you see some exception classes that could be thrown during a normal product process. The complete source code can be found here.

To insert a new mpProduct-object into the mpProductCatalog we have to create MVC infrastructure, which means a controller and a view.

At this point I will ignore the details and the whole environment around these two components and I will concentrate onto the method doAddProduct() which tries to add a new product to the mpProductCatalog-instance. The source code for the view and the controller from the following diagram can be found here and here.

Now let's take a look at the required logic for an insert operation. What must be done? First we have to get an instance of mpProductCatalog, then we have to create a new mpProduct object and we have to open a new transaction for this object. Then we can try to insert the new product whereby we have to take care about thrown business model exceptions. The listing below shows the required code for the doAddProduct() method.

One weak point this example shows very well is that the controller has at least six dependencies to the business model. Since I assume that dependencies between a business model and the controller will occur more than one time in an application, which makes the maintenance of the business model source code very difficult. Another point that can happen is the need of another presentation layer for your complex business model. For web applications this requirement should be resolvable by the choice of a suitable frameworks, but in some situations it's conceivable that is not possible without larger expenditure. So I created a second GTK based presentation layer for the business model. The source code for this gtk frontend can be found here controller, view.

If we compare both doAddProduct() implementations we see that they are nearly identical except some minor differences due to the used technology. This produces further complexity for the application maintenance, which no one wants.

So! What can be done to solve this problem?

The simple answer to this question is, we have to decouple both layers. So we have to implement a simplified model controller(MC) that encapsulates the business model from the MVC. This technology is also well known under the terms Facade or Command. A very good description can be found in the Java J2EE Blueprints. The following listing shows the new domain/business facade.

As you can see this new subsystem encapsulates the whole insert operation. Everything a client has to do is to pass the new product name into the component and the client must care about thrown mpDomainException objects. And here is the new doAddProduct() implementation from the web controller.

The produced overhead is really limited, because the new facade uses same method calls as the original implementation. Even if the introduction of own Value-Objects for communication between Controller and Facade, which weren't used in the shown example, would result in an additional overhead, I have the opinion that the presented technology is important for all large and long running application.

The modified source code for the controllers and the facade can be found here: facade, web controller, gtk controller.

Since there are a many great applications that aren't working with the presented separation and that are very successful, I assume, that some of my readers will not agree with me. It is also possible that the shown technology is more java and not the php way of doing things. But when I was young, I smoked to much java

And now I invite you to discuss with me and I close this post with a citation from Arne Nordmann:

separate your concerns