Entries tagged as software design
design quality checkstyle cyclomatic complexity npath complexity overview pyramid php php_depend quality assurance release announcement software architecture software metrics ant book bug fix changes company conference consulting continuous integration crazy cruisecontrol css dortmund elephpant ext/filter ezcomponents fabien potencier fun hamburg lint logger php5 phpbbq phpmd phpt phpug phpugdo phpundercontrol phpunit php_codesniffer pirum pmd quality static code analysis static_reflection support talks testing thinkpad tools training unconference unit test xml xpath zce zend certified engineer cbo class interface size coupling between objects dbus derick optimization performance tokenizer annotations cli customization dashboard phpdoc rule set usability arbit article cologne ipc karlsruhe kore php-magazin xsl Wednesday, June 25. 2008Using the Overview PyramidThe Overview Pyramid is used to visualize a complete software system in a really compact manner. Therefor it collects a set of metrics from the categories Inheritance, Coupling and Size & Complexity, and puts them into relation. The following figure shows the base structure of the Overview Pyramid[ML06]. 
Base structure of the Overview Pyramid.
Metrics used by the Overview PyramidThe following three lists contain all the metrics, which the Overview Pyramid uses. Size and ComplexityThe category Size & Complexity contributes the greatest and mostly used set of software metrics.
CouplingThis group of metrics informs about the coupling between different program parts in the analyzed application.
InheritanceBoth metrics in this group deal with the use of Inheritance and give a general overview of the use of Inheritance within the analyzed system.
Structure of the Overview PyramidNow that we know all metrics used for the Overview Pyramid, it is time to replace the placeholders with the measured informations. The figure below shows the filled Overview Pyramid. 
The filled Overview Pyramid
In a second step, the previously independent metrics are set into relation. Therefor we calculate the average values of individual value pairs, these computed values provide us with new informations about the distributions within the application. The following example figure of the Overview Pyramid contains a computed value for the measured LOC and NOM metric which shows us, that in the average each operation has 25 lines of code. This value can be described as very high, especially when you consider that most systems contain a variety of simple operation, like Getter and Setter, in addition to the main application logic. 
Computed average values in the Overview Pyramid
To take reasonable conclusions from the computed values one important part is still missing, an adequate set of reference values. Without reference values, that say what values are low, average or high, it is not possible to classify these results. The current version of PHP_Depend supports a single set of reference values, this set was taken from [ML96]. Reference values
With these reference values PHP_Depend can classify the computed results. PHP_Depend uses this information for the generation of colored backgrounds, so that the color already supports the categorization. 
The complete Overview Pyramid
The benefit of the Overview PyramidOf course, the final question is, which advantages offers the Overview Pyramid? The Overview Pyramid provides a simple and size indipendent way to get a first impression of a software system, and this without an expensive source code analysis. Thus the Overview Pyramid is an effective tool for a first cost estimate for an unknown system. With the help of this tool and know-how, an experienced developer will quickly get a first impression and will know what can be expected from the analyzed application. And this knowledge could be a good help during the planning phase of a new project. Bibliography
Wednesday, February 6. 2008How reusable, extensible and maintainable is your software?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.
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.
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:
The following sources were used for this post.
Saturday, August 4. 2007Exploring the MVCDuring 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 To insert a new At this point I will ignore the details and the whole environment around these two components and I will concentrate onto the method
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 <?php
public function doAddProduct() { $name = $this->view->getText(); // Create a new product $product = new mpProduct( $name ); // Get the product catalog $catalog = mpProductCatalog::getInstance(); // Create a new transaction $transaction = $catalog->createTransaction( $product ); try { // Start transaction $transaction->begin(); // Add new product to catalog $catalog->addProduct( $product ); // Commit product transaction $transaction->commit(); // Reset input $this->view->setText( "" ); } catch ( mpProductInTransactionException $e ) { // Show error message $this->showDialog( "Transaction Error", $e->getMessage() ); } catch ( mpProductExistsException $e ) { try { // Rollback product transaction $transaction->rollback(); // Show error message $this->showDialog( "Name Error", $e->getMessage() ); } catch ( mpProductTransactionNotOpenException $e ) { // Show error message $this->showDialog( "Transaction Error", $e->getMessage() ); } } } ?> 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 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. <?php class mpDomainFacade { public function addProduct( $productName ) { // Create a new product $product = new mpProduct( $productName ); // Get the product catalog $catalog = mpProductCatalog::getInstance(); // Create a new transaction $transaction = $catalog->createTransaction( $product ); try { // Start transaction $transaction->begin(); // Add new product to catalog $catalog->addProduct( $product ); // Commit product transaction $transaction->commit(); } catch ( mpProductInTransactionException $e ) { throw new mpDomainException( "Transaction Error", $e->getMessage() ); } catch ( mpProductExistsException $e ) { try { // Rollback product transaction $transaction->rollback(); // Show error message throw new mpDomainException( "Name Error", $e->getMessage() ); } catch ( mpProductTransactionNotOpenException $e ) { // Show error message throw new mpDomainException( "Transaction Error", $e->getMessage() ); } } } } class mpDomainException extends RuntimeException { private $title = ""; public function __construct( $title, $message ) { parent::__construct( $message ); $this->title = $title; } public function getTitle() { return $this->title; } } ?> 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 <?php public function doAddProduct() { $name = $this->view->getText(); // Create a domain Facade $facade = new mpDomainFacade(); try { // Try to add product $facade->addProduct( $name ); // Reset input $this->view->setText( "" ); } catch ( mpDomainException $e ) { $this->showDialog( $e->getTitle(), $e->getMessage() ); } } ?> 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:
|
ProjectsFurther stuffSee also
Categories |
.
