These critiques can be relevant or not, depending on the way and for which purpose the UML is used. UML adopters should understand in the first place why they are building models (in particular, design models). Are they interested mainly to raise the level of abstraction, moving their development environments from textual programming languages to graphical programming environments (with an obvious shift in notation)? Otherwise, are they approaching modeling in an attempt to give dignity to design artifacts like architecture, subsystems, protocols, and so on, that are usually implicit (hidden) in the code? Are they focusing on generating code, or they consider the goal of improving communication as a mandatory requirement?

Design models are artifacts to be maintained and updated. There is a lot of emphasis about automatic synchronization in the market, but (considering the state-of-the-art tools that are available nowadays) I do not believe that this is the right direction, in most cases. Simply, this type of automation it is not about design. It provides a mechanistic view of code. After some rounds, people continue to do all the shortcuts in the code (perhaps because they are programmer and code is their natural place to work…), and the only fact that an integrated environment is able to automatically re-align with a single click both models and code does not mean that you are doing design! Neither that you are doing GOOD design. It is exactly the opposite. It is the shortest path to bypass design!
Who claims that automatic generation of UML models is the right tool to avoid the burden of synchronize code and models has in mind the main goal of speeding productivity. But it seems they are focusing only to the most easy (and useless) way of measure productivity: the percentage of LOCs automatically generated. Without taking too much into account the quality of the design, this attempt to improve will fail because the most important improvements in productivity come from design, not from code. In the long term, this choice is usually counter-productive. In my opinion, you have to pay a price for keeping a high level of (design) quality in a complex project. Building models and maintaining them as the backbone of the system is an important investment in communication, IP sharing inside the company, and in development.

If the development team really embrace a model-driven approach, modeling should not be viewed as “a way of building programs”, but as a way of designing solutions, a way of thinking to problem domains without the bias of a programming language, a way of communicating with people rather than with machines. Not one of these in particular, but all of these at the same time. Of course, we have to remember that the sole use of UML is not a guarantee of success. The value is not in the notation, but in the way the notation is exploited to guide the development process, to forge and inspire good solutions, and to better communicate with people (eventually even with ourself).

The reality is that without a significative background on software testing techniques, even utilizing an automation tool results in a sterile activity. No tool is able to tell you what to test (first) or how to design test cases. Unfortunately, as happens for other stages in a project lifecycle which are mainly (and in my opinion erroneously) driven only by CASE tools, the idea to perform “appropriate” testing coincides with the ability to run “some” tests in NUnit until a green light reassures people that all is fine. Of course, this is not enough. Too many fundamental questions about testing remain unanswered using this approach. One of these questions is “how many test cases I need to properly test a particular functionality?” Proper white-box testing requires at least some minimum coverage criteria. Any attempt to introduce a serious testing activity in a software project without a coverage criteria is a clear sign of an hobbist approach. Of course, a bunch of tests can provide value by itself, but this level of software quality assurance is simply insufficient and inadequate for industrial systems.

What I mean using the term coverage is to identify a set of tests (with respect to a module/subsystem/system) that has the potential for executing every instruction and taking all branches in all directions (paths) in the code. According to Boris Biezer, complete coverage is the first minimum mandatory requirement for serious testing [1]. Moreover, he also stresses the need to perform such level of testing without  taking refuge in pretexts such as the non-economical cost of testing:

Any testing based on less than complete coverage requires decisions regarding what code should be left untested (which is by itself a cost). Such decisions are inevitably biased, rarely rational, and always grievous. Realistically, the practice of putting untested code into systems is common, and so are system failures. The excuse I’ve most often heard for putting in untested code is that there wasn’t enough time left or enough money left to do the testing. If there wasn’t enough time and money to test the routine, then there wasn’t enough time and money to create it in first place. For what you think is code, before it has been properly tested, is not code, but the mere promise of code. [...]  It is better to leave out untested code altogether than to put it in. Code that does not exist cannot corrupt good code. An untested function may or may not work itself (probably not), but it can make other functions fail that would otherwise work. [...] Leaving untested code in a system is stupid, shortsighted, and irresponsible. (The italics are mine.)

Many years has been passed since the time Beizer wrote his book, but the situation is not changed a lot. I believe his message is very actual even nowadays. The problem is that many software developers continue to think that developing software systems is a mere act of writing code, compile it, debug it, and deploy it. This development cycle hides testing. This was probably a little concern when software systems were written by only one person and consisted of no more than a few hundred lines of code. This is a huge problem now, because more sophisticated techniques are required for testing a complex system, developed by many people, often distributed in different organizations or teams. The sole programming culture is not sufficient. Anf the role of models comes to light.

Considering the definition of coverage criteria provided by Beizer, which is a simple, sound metric for a (model-driven) testing activity? I believe that McCabe’s complexity metric can be useful [2]. Whereas the CCD family of metrics [3] helps to catch an overall indicator of the testing/maintenance burden, the McCabe’s metric provides a first hypotesis on the numer of test cases needed to test a module/subsystem/system fulfilling a coverage criteria. Indeed, McCabe’s metric is closely related to the number of circuits required to cover a graph. Due to the fact that any flowchart-like representation of the control flow structure is similar to a graph, it is straightforward to conclude that this metric has the potential to provide an indicator of the number of test case needed to test e.g. a piece of model dynamics expressed by an UML activity diagram. There are three ways to calculate such metric. The first one is a simple formula:

M= L – N + 2P,

where L= the number of links in th graph, N= the number of nodes in the graph, and P= the number of disconnected parts of the graph (e.g. a calling program and a subroutine).

The second method  is to calculate the number of binary decisions in a program plus one. A three-way decision must be converted in a two binary decisions, and a N-way case statement in a N-1 binary decisions. Similarly for the guard condition of a loop.

Finally, the third way, which is associated to the notion of a circuit in a graph, is to count the number of connected regions present in the graph’s topology. An interesting property of the McCabe’s metric is that the complexity of several graphs (modules/subsystems/systems) considered as a group is equal to the sum of the individual graphs’ complexity. (Of course, we focus here in the structural complexity concerning the algorithmic/dynamic representation of such modules/subsystems/systems.) Hence, as a simple test plan action, we start to build a representation of the control flow structure of a module code (using either flowcharts or UML activity diagrams). Then we transform such a representation in a graph, and finally we calculate the McCabe’s metric on it. If the number of test cases does not equal the final M value of the metric, then we have not yet satisfied the coverage criteria. In that case, there isn’t necessarily an error, but there is anyway a reason for caution, as Beizer claims:

1. You haven’t calculated the complexity correctly. Did you miss a decision?
2. The cover is not really complete. There is a link that has not been covered.
3. The cover is complete, but it can be done with a few more but simpler paths.
4. It might be possible to simplify the routine.

I like the McCabe’s metric because it is quite as simple as the count of LOCs (Lines Of Code) but provides a better measure of the structural complexity of a routine (method). It’s intuitively better because it takes into account the increase of complexity due to subdividing a routine (method), something that a LOC-based metric does not do. To be precise, as suggested by Beizer, the McCabe’s metric takes into account but underestimate the real impact of subdividing code because in such cases the structural complexity increases nonlinearly with respect to the number of parts in which the routine (method) is splitted into. However, it is better than nothing.

It is time to show how things work in practice. Consider the situation in which we want to test the main method of a simple data recorder for a hot-water healing system. We first create a flowchart (e.g. an activity diagram in UML) illustrating the control-flow logic of our recorder system. The result should be similar to that illustrated in Figure 1.

Flowchart for a simple data recorder system

(It is not the best design for such application, but this is not the point). Then we translate this flowchart into a graph representing all possible paths. We label each node with a number and each link with a letter. (In order to facilitate the mapping with the two diagrams, I have annotated the activity diagram accordingly.) A link in the graph corresponds to either an activity (process) or a connection between nodes (e.g. a loop) in the flowchart, whereas a node represents a decision point, a junction (a point in the flowchart where two or more paths join), or a combination of both. For example, the f link describes the jump backward to the the process b (Read data from environmental sensors) that can arise at the decision point 5 (Any error during validation?) immediately after the execution of process c (Validate data).

Paths for the workflow model of the data recorder system

Applying the McCabe’s formula, we have that: L=7; N=6, thus M= L – N + 2= 7-6+2= 3

The minimum number of test cases needed to test the flowchart of our data recorder system is 3. I have made an important hypotesys here: all the paths through the routine are achievable because all the predicates (statements) in the routine are uncorrelated (independent). If we have correlated data or statements, the actual possible paths are less than those provided by the McCabe’s metric.

Our next problem is to find these test cases. In our pretty simple example, it is quite forward to find them simply by manually inspecting the graph. The simplest path is probably abcde, which covers all the links except f and g. Now we need two other different paths to complete the coverage criteria: one satisfying f (the simplest one is abcfbcde), and the other satisfying g (again, the simplest path is abcdgcde). In conclusion, the set of test cases needed are:

1. abcde
2. abcfbcde
   
3. abcdgcde
   

Finding a set of input values that will cause the execution of each desired path (path sensitizing) gives us a reasonable level of confidance that our testing effort was sufficient (according to our basic coverage criteria) to check the recorder funtionality illustrated here.

Bibliography

[1] B. Beizer, “Software Testing Techniques”, Van Nostrand Reinhold, 1983 [2] T.J. McCabe, “A Complexity Measure”, IEEE Transaction on Software Engineering SE-2: 308-320 (1976) [3] J. Lakos, “Large-Scale C++ Software Design”, Addison Wesley, 1993

The Blog-Health-o-Meter™ reads Minty-Fresh™.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 2,200 times in 2010. That’s about 5 full 747s.

In 2010, there were 3 new posts, growing the total archive of this blog to 9 posts. There were 3 pictures uploaded, taking up a total of 93kb.

The busiest day of the year was November 23rd with 32 views. The most popular post that day was Physical design vs. logical design (part I).

Where did they come from?

The top referring sites in 2010 were:

• users.dimi.uniud.it,
• sole.dimi.uniud.it,
• lmodules.com,
• facebook.com, and
• linkedin.com.

Some visitors came searching, mostly for logical design diagram, logical design vs physical design, andrea baruzzo, logical design and physical design, and difference between logical and physical design.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1. Physical design vs. logical design (part I) July 2009
2. Physical design vs. logical design (part II) July 2009
3. How testable is a software architecture? August 2009
4. About cardinalities and multiplicities in UML associations November 2008
5. On the difference between data and object models August 2010

Figure 1 - The first option to model a portion of a domain in UML

The model illustrates two aggregates, G and M, a hierarchy H and some infrastructure classes all around the aggregates (repositories, factories, and proxies). Looking at this design, the designer experimented a little bit in order to improve it. Pheraps the hierarchy merges two different dimensions, an abstraction and an implementation (Hj and Hjk, where j stands for the abstraction concern and k for the implementation concern, respectively). Thus, one possible refactoring strategy is to separate such dimensions, applying the Bridge pattern (the original hierarchy rooted at H now has been divided into two structures rooted at H1 and H2, respectively). Another improvement can be to merge the classes X and Y in order to provide a single, convenient access point to the hierarchy for the aggregates M and G (another Proxy interface?). Finally, some small modifications affecting the dependencies between the infrastructure classes and their aggregates, and we obtain the design described in model Figure 2.

Figure 2 - An alternative design for the original model

In his refactoring, the designer applied two well-known design patterns. This sounds good, but does he really improve the design? Looking at the structures of the two models, which one is better is not so evident. In general, there is no single answer. We need to understand which non-functional requirement is more important, in order to choose a suitable metric to measure it. Considering maintainability and testability, better means “simpler” in terms of complexity and coupling. We can calculate the CCD/NCCD metrics for both design alternatives in order to evaluate the dependecy structure of the two models. Despite of the fact that the second model applies some design patterns, the overall maintainability is not improved. The crude numbers are showed in Table 1:

Table 1 - Comparison between the two designs

The second design shows an increase in complexity of 9,334% according to NCCD metric despite of a reduction of the system size (-13,793%). This example illustrates several points:

• The simple application of design patterns does not always guarantee an improvement in quality. A pattern represents a well documented solution to a recurring problem, but it comes with costs and consequences. If we choose a pattern which do not represents a good trade-off with respect to the specific non-functional requirement we want to optimize, the result will not be optimal.
• Changing the non-functional requirement to prioritize, the numbers may tell a completely different story. In our example, if we take into account scalability, probably the alternative model of Figure 2 is better, at least considering the maintainance of the evolving hierarchy structure. After all, this is exactly the reason why the Bridge pattern was introduced.
• Supported by a mathematical model such as that provided by the CCD/NCCD metric, we can measure one dimension of software quality objectively and systematically.
• Without an objective evaluation, making strategic decisions (e.g. optimizations, design speculations, architectural choices, and so on) on the basis of the sole designer’s intuition can produce unexpected (unpleasant) results.

Obviously the space in a blog is not sufficient to provide a complete treatment. The interested reader can deepen the arguments discussed here in the books suggested at the end of this post.

Relationships and navigability

Of course, the most evident difference between the two paradigms concerns how they handle the relationships between entities. The relational model is based on the set theory whereas the object model is quite close to the graph theory. This fact has several implications which affect how relationships are dealt with. As described by Jimmi Nilsson [1], in the relational model, relationships are formed by duplicated values. Consider, for example, the ORDER entity which has the primary key ORDER.Id: such key is duplicated as a foreign key in any children entity, letting the child rows “point” to the parents. Thus, everything in a relational model is data, even the relationships. In an object-oriented model, relationships are implemented using the built-in object identifiers, letting the parent have references to object identifiers of its children.

Navigability is also affected by the different nature of these two models. A graph can be oriented, so in an object model the navigation between two objects is one way. Bidirectional navigation is achieved by two separate links (relations). Conversely, in the relational model the navigation is always bidirectional. Moreover, the relational model is set-based, hence almost every operation on the database deals with sets. When we want to navigate in the relational model, we execute a query to retrieve all children that have a foreign key with the same value of the primary key of the parent. What we have in return is a set of data. Another way of navigating the relational model is to perform a joint between both the parent set and the children set. In an object model the typical way to navigate through the instances is to traverse the relationships between the objects (as in a graph). With objects, we deal always with only an object (instance) at a time.

Data encapsulation

This different way to implement relationships affects also the “privacy” of the data. Every data in the relational model is “global”, while in an object model we usually keep data encapsulated and protected in agglomerates called aggregates. Every aggregate should keep secret its internal state, exposing only the public services used to manipulate it.

Static vs. dynamic nature

Relational models concern only data, whereas object models take into account also the dynamic nature of object (objects, differently than entities, expose a behavior implemented by methods).

Type system

Using both a relational database and an object model, we deal with two different type systems. This is evident when we look at the physical models. Often the two types systems are located in different machines and even it is not so, they live in different address spaces. Moreover, not even the primitive types are the same. A string in .NET can have a variable length whereas in Microsoft SQL Server is typically a varchar or a text or a char. Again according to [1], a DateTime in .NET has the precision of 100 ns, whereas in SQL Server the precision is only of 3/1000 s. Yet another example: in the object type system it is not possible to assign a primitive type to an object instance, and viceversa. Thus it is not possible to set an int to null; however, it is perfectly legal to store a null value in an int in SQL Server.

Clearly, these differences show us that when we are developing a complete software system we are dealing with two distinct development environments: the application programming environment and the database programming environment. In the latter the typical programming language is a declarative query language, whereas in the former the languages are usually imperative (often either procedural or object-oriented). Declarative query languages have no control constructs, nor variables, thus they are not well suited for complete application development. Hence, programmers write applications in a programming language with its own data structures, and use a query language to transfer data back and forth between the application programming environment and the database programming environment. Because these two environments adopt different paradigms (with the differences highlighted above), we deal with the impedance mismatch problem.

Due to their intrinsic characteristics, the object model is usually the best place for coding the business logic. The translation between the object model and the data model can be done manually (e.g. with design patterns such as Repository or Query Object) or automatically, with an Object-Relational Mapping (ORM) tool such as Hibernate or Cayenne. Moving the business layer in the data model is typically an anti-pattern. We are forced to work in the database programming environment where the programming languages are not expressive enough to provide the support needed to code business rules and complex business logic. Moreover, we lack also the support of testing tools and techniques which is commonly available in the application programming environment (assertions, unit testing, integration testing, and system testing frameworks).

Bibliography

[1] Jimmy Nilsson, “Applying Domain-Driven Design and Patterns”, Addison Wesley, 2007

[2] Roderic Geoffrey Galton Cattell, “Object Data Management: Object-Oriented and Extended Relational Database Systems”, Addison Wesley, 1991

[3] François Bancilhon and David Maier, “Multilanguage Object-Oriented Systems: New Answers to Old Database Problems?”, in Future Generation Computer, K. Fuchi and L. Kott Eds, North-Holland, 1988

• Communication is based on hypertext protocols. COM and CORBA failed mainly because of the transport mechanism they use to communicate between remote servers  (i.e. the low-level TCP-IP protocol). The problem with this mechanism concerned the need to cross firewall boundaries or pass between proxy servers. SOA uses a different protocol for communication (i.e. HTTP) which works better as a transport layer and is capable of traversing firewalls and proxy servers.
• Through Web services, SOA has a common (and standard) lexicon. SOA uses both the Web Services Description Language (WSDL) and a publishing mechanism (UDDI, Universal Description Discovery and Integration) for discovering Web services, which are standard formats. CORBA is based on a standard specification, but implementors failed to provide standard implementations. DCOM achieves portability at the binary level, but it is “standard” only in the realm of the Microsoft platform. Porting DCOM outside Windows resulted in several difficulties.
• SOA emphasize orchestration, not just communication. The typical code we write with either DCOM or CORBA exploits local and remote function call. With marshaling and unmarshaling, this programming style enables a uniform invocation style, which makes local and remote calls look similar. However, that code remains at the functional level. SOA concentrates on the more abstract task of integrating at the service level. Furthermore, using the Business Process Execution Language (BPEL), this task can be reasonably achieved by a business analyst rather than by a programmer.

Of course, any technology succeeds (or fails) for a variety of reasons concerning not only the technical aspects. Nonetheless, I think that the aspects discussed so far are quite interesting as key factors in the comparison between SOA and its predecessors.

Finally, I conclude this post with what I consider a challenge in the actual software modeling scenario. The development of SOA applications promotes the use of a declarative programming style on the top of an object layer. To this regard, it is interesting to see how modeling notations such as UML are/will-be capable of expressing these two different paradigms in a coherent, unified style.

The initial question (how testable is a software architecture?) is thus a question concerning the quality of the design. Objectively, it is a complex question which can be tackled from several different perspectives. There is no single “good answer”, no magical tool. I try to address it considering the quality aspect from the physical design perspective, which I have discussed in previous posts. This is also a good occasion to talk about two types of testing strategies:

• Isolation testing;
• Hierarchical testing.

One technique useful to analyze the testability of a system is to check either if it is layered or how far it is from a layered structure. In the case it is layered, we want to analyze also both the complexity of each layer (how many components, how many dependencies, etc.) and the cumulative complexity of the entire system.  Layering is a technique to produce levelizable system. The idea is to identify a method for partitioning all the components constituting the system under testing into equivalence classes called levels. This partition is based on the physical dependencies existing between the components. Each level is then referred by a non-negative integer number, called level number. An example will clarify the idea.

Several years ago I developed a geometrical engine to solve some research problems in the field of computational geometry. This engine was intended to provide not only the geometrical algorithms, but also a predefined library of shapes upon which the programmers could build their applications. I was asked also to develop a simple shape editor implementing the most common operations concerning the shapes manipulation. Inspired by the work of Lakos, I designed the shape editor subsystem as illustrated in Figure 1 (actually, this is a simplified version of that system, but it suffices to illustrate the point). It was composed by several components which do not form any cycle in the physical dependency graph. I strove to not introducing cyclic dependencies because only a configuration of components that has a directed acyclic physical dependency graph (DAG) forms a levelizable system. In a DAG, we can always assign a unique level number to each component using the following rule. At level 0 we place all the components external to the system under test (e.g. a third-party library component, assuming that such components have already been tested). At level 1 we place components internal to the system under test with no local physical dependencies (e.g. Shape and Utils::Node components in the figure). Finally, at level N we place those components internal to the system under test which depend physically on components at level N-1, but not higher. In this way, a component has a level number one more the maximum level of the components upon which it depends.

The rationale in this level number assignment is that a level number counts the length of the longest path from that component through the (local) component dependency graph to the (possibly empty) set of external or compiler-supplied library components. In general, we will say that any software system is levelizable if its physical dependency graph can be assigned unique level numbers. A cycle is not levelizable, so we cannot assign to its components unique level numbers. In that case, the cycle must be considered as a unique component in order to assign a unique level number to it.

Figure 1 - A UML component diagram annotated with level numbers in the upper-right corner of each component

It is very simple to rearrange the components in the diagram in order to enphasize each level. The diagram in Figure 2 reflects this new disposition, appearing now as a typical layered architecture.

Figure 2 - The same component diagram rearranged according to a typical layered design

Why layering is a desirable property of a design? Why I were so carefully with cycles in the dependency graph? If we have a levelizable system and we want to test it, we can immediately identify which components are testable in isolation: it is sufficient to look at those components belonging to level 1. In a cycle there is no level 1! In the case of my shape editor illustrated in Figure 1, there are only two components that can be tested without linking any other component: Utils::Node and  Shape. Moreover, by starting to test at the lowest level (level 1)  and testing all the components belonging to that level before moving to the next level, we guarantee that all the components on which the current component depends have already been tested.  This criteria is referred by Lakos as hierarchical testing, because level numbers define a partition that can be considered as an hierarchy of component dependencies in the physical graph.

Layering let us quickly identify the most reusable components in the system and, if we arrange the UML diagrams as in figure 2, we will find such components looking at the top of the diagrams. However layeing alone does not reveal a direct measure of the internal complexity of each level, nor it provide a measure of the cumulative complexity of the overall architecture. To do this, we need a metric based on the physical properties of a system: the Cumulative Component Dependency (CCD). CCD is not new: it has been discussed extensively by John Lakos in his book “Large-Scale C++ Software Design”, published in 1993. Despite this metric is available long before the rise of UML, no modeling CASE tool supports it nowadays (at least to the best of my knowledge). CCD is useful because represents a good indication of the long-term maintenance cost associated to that component/system [1]. CCD is defined as follows:

CCD = sum over all components C in a subsystem of the number of components needed in order to test each C incrementally.

Calculate the CCD is straightforward: for each component C in the subsystem under test we count how many other components are reachable inspecting the dependency graph rooted at C. To test C incrementally we have to write a test driver for it and a single independent test driver for each component reachable from C. If there are n components reachable from C, we have to link k+1 components to test C incrementally. This k+1 is the linkg cost associated to C. Now we add the link cost of all the components in the subsystem under test. The total sum is the CCD value for the specific subsystem. In our example, the CCD of the EditorShape subsystem is 50, as shown in Figure 3. For each component in the upper-right corner I have shown now the link cost. To test incrementally the Edge componet, we have to link to its test driver the test drivers of Point and Shape, so the link cost is 3. If we want to test Triangle, we have to link also Vertex, Utils::Node, Point, and Shape, so the link costs is 5. The CCD is the sum of all link costs.

Figure 3 - CCD of the Shape editor

CCD is useful because provides a numerical measure of the overall link cost associated with the incremental testing of a given system. Obviously a low CCD value identifies a design which is simpler to test, to maintain, and to understand. A low CCD combined with a levelizable design allows to study pieces of the subsystem in isoltation, to test, tune, and even replace them whithout having to involve the entire subsystem either mentally or physically [1].

If our subsystem is very tightly coupled, e.g. forming a cyclical graph of the same size (11 components) as illustrated in Figure 4, the CCD will be 121. Comparing the 49 CCD value of the system in Figure 3 with the CCD value of this second configuration, we have a numerical evidence that the former design is better (from the testing perspective). Indeed, in Figure 4 none of the components can be tested in isolation or reused independently of the others. There is no partition that let us to test the subsystem hierarchically. Each independent test driver will be forced to link the entire subsystem in order to test a single component, causing a quadratic link time.

Figure 2 - A cyclic subsystem of size 11

The conclusion of this long post is summarized by the following principle:

Principle: Large software architectures must be levelizable if they are to be tested effectively.

As Lakos remarks:

CCD provides a raw measure to grasp the structural complexity of a software architecture in order to test it. Level numbers characterize the relative complexity of a component, providing also an objective strategy for testing (hierarchical testing). Cyclic physical dependencies among components inhibit understanding, reuse, and testing, hence they should be avoided or at least confined in a single package. If we design our software systems with an eye toward minimizing CCD, most cyclic dependencies would be eliminated, producing more testable architectures. Moreover, reducing the interdependencies between components as quantified by the CCD helps to keep the overall system simpler, improving both maintenability and understandability.

Bibliography

[1] Lakos, J. – “Large-Scale C++ Software Design”, Addison Wesley, 1996

To show how this transformation is obtained, consider the simple UML class diagram in Figure 1: it illustrates the Shape hierarchy, one of its clients (the ShapeEditor class), and a utility class (ShapeUtil). The first step to translate this diagram into a logical design diagram (according to the Lakos method) is to characterize each relation between classes in terms of generalization and the three new stereotyped dependencies «Uses-In-The-Interface», «Uses-In-The-Implementation», and «Uses-In-Name-Only» (the latter is not supported by all programming languages, as noted in the aforementioned instalment).

Figure 1 - The shape editor

To select the proper type of dependency, we have to check the source code, if available. Otherwise, at design-time, we can set a specific dependency type between two classes in order to force a particular property: for example, we specify that a class X «Uses-In-The-Implementation» a class Y when we want to treat Y as an encapsulated implementation detail of X, avoiding to propagate this logical dependency to any external client which uses X.

I suppose here that at design-time ShapeUtils will be coupled with every concrete shape, using them substantially in its implementation. Thus, from a logical point of view, ShapeUtils «Uses-In-The-Implementation» Triangle, Square, and Circle.

The same reasoning is applied for the class ShapeEditor, with one important difference: whereas ShapeUtils needs to delve directly with each concrete class, the ShapeEditor can (should) treat every shape trasparently, without knowing directly its concrete type. Hence, ShapeEditor will depend only from the (abstract) base class Shape, and the communication with concrete shapes will be realized by means of polymorphism. The resulting logical design is depicted in Figure 2. Note that, in order to show the transition between logical and physical design, I have specified in the diagram also the component to which every class belongs to (showing components is not mandatory in a logical design, as it is in physical design).

Figure 2 - Logical design of the shape editor

The last step that we have to do to complete the transformation is to map any arrow (relation) between classes in the logical design into a dependency between components in the physical design. The transformation of both generalization and dependency relations between the classes ShapeUtil, Triangle, and Shape is depicted in Figure 3.

Figure 3 - From logical to physical design

The final physical design corresponding to the class diagram of Figure 1 is illustrated in Figure 4.

Figure 4 - Physical design of the shape editor

This diagram has an important property of good software design: it is layered. In other words, it is levelizable: it is possible to partition all the components in a system based on their physical dependencies into equivalence classes called levels. I will discuss levels and their implication to testability in the next instalment.

The physical architecture is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms. The quality of the physical design of a large system will dictate the cost of its maintenance and the potential it has for the independent reuse of its subsystems.

This claim touches several important points. First, it emphasizes the need of up-front design in developing complex and large software architectures. In other words, don’t believe that your architecture will “emerge” simply as a side-effect of continuous refactoring steps. Refactoring simply do not scale well to be a serious “large-scale” architectural design tool. Second, Physical design provides some interesting metrics which can be very effective in order to evaluate the maintenance cost of an architecture. Furthermore, the same metrics can also be used to compare alternative designs. Finally, working with physical design lets the architect to address many testability issues (such as testing in isolation, testing hierarchically, ensuring high-quality software as it is being developed). I will discuss separately each of these aspects in future posts, especially in the context of modern, model-driven development environments.

Before to delve into technical details, however, I briefly recap here the difference between logical and physical design. The dichotomy between these two concepts is similar to that of classes and components. Logical design addresses issues such as the interaction of classes and functions, the (public) interface of a class, the signature of a method, and so on. In an object-oriented system, the class is the smallest fundamental unit of logical design. Physical design, on the other hand, takes into account physical entities (e.g. components, files, and libraries), compile-time coupling, link-time dependencies. The component is the smallest fundamental unit of physical design. Using both physical and logical design aspects, it is possible to automatically analyze a software architecture in order to evaluate several characteristics closely tied to software quality such as understandability, maintainability, testability, and reusability.

In order to do this, it would be desirable to have a unique notation to talk about both logical and physical design. Furthermore, it is desirable that such notation would be supported by modern CASE tools in order to be really applicable. At the time of his writing, Lakos proposed a visual language to talk about logical and physical architectures which were based upon the Booch Notation. Unfortunately, no tool never supported this endeavour. What I propose here is an adaptation of the Lakos notation to current UML. In this way, we can approach to the same type of analysis proposed by Lakos, but applying it to UML diagrams using current state-of-the-art CASE tools, where Lakos performed his automatic analysis of (only) C++ source code using a custom analyzer, in spite of his more general, langugage-independent method).

To set the stage, I choose a simple example consisting of three concrete classes forming a hierarchy of shapes. If we would like to describe the logical design of this small system in UML, we would probably draw a class diagram similar to the following:

Logical dependencies between classes

Three types of shapes, Circle, Square, and Triangle, derive from the abstract class Shape. Logically, the interface of Circle, Square, and Triangle depend from the interface of Shape (this dependency is expressed by the generalization relation). This diagram represents a logical architecture because it describes logical entities (classes) and their relations. Suppose now that each class will be implemented as a single component (for example, in C++ this component consists of both a header file and an implementation file; in Java we will have a single physical .java file, and so on). In UML we can use a component diagram to describe each shape component. A dependency between classes in the logical design is then propagated to a dependency between components in the physical design, as illustrated by the figure below:

Physical dependencies between components

I will use extensively these types of diagrams to discuss design for testability issues. What the diagrams have in common here is the notion of dependency. After all, designing object-oriented system is mainly a question of managing dependencies. Not surprisingly, thus, we can rely on a very simple notation in order to reason about many aspects related to the complexity of a software architecture. More specifically, concerning the physical design, I will use classes, components, and dependencies. With these few elements, we are able to understand a lot of the overall architectural quality, especially for analysing the maintenance cost or the degree of testability (I will examine opportune metrics in a successive post). Concerning the logical design, again I adhere to the minimal notation used by Lakos for designing a logical system, based on classes and relations. More specifically, in UML I will use generalization (for hierarchies) and three types of (stereotyped) dependencies: the «Uses-In-The-Interface», the «Uses-In-The-Implementation», and the «Uses-In-Name-Only». Such dependencies replace to some extent the more specific association, aggregation, and composition relations in UML.  The semantics of these relations is quite strightforward:

• «Uses-In-The-Interface»: a type T is used-in-the-interface of a component C if the type is used in the public interface of any class defined for that component. In this case, we will say that C depends in its interfaces from the type T. If T is used in the interface of C, it can also be used in any C implementation. Therefore, the  «Uses-In-The-Interface» dependency subsumes the «Uses-In-The-Implementation» one, which will not be drawn in order to keep the diagrams simple.

• «Uses-In-The-Implementation»: a type T is used-in-the-implementation of a component C if that type is referred to by name anywhere in the definition of the component. In this case, the component C depends in its implementation from the type T. This dependency is not propagated to the interface of C. (In other words, the dependency is logically encapsulated in the implementation of C, thus T is not visible/accessible from the outside of C.)

• «Uses-In-Name-Only»: a component C uses a type T in name only if compiling C and any of the components on which C may depend does not require having first seen the definition of T. It is, for example, the case of a C++ type T which appear in a component C always only in the form of T* (i.e. a pointer). In that case, the compiler do not need to see the layout of T in order to compile C (it will always reserve the space for a memory address – the T* pointer – to represent any reference of T in C).

In the second part of this post, I will provide further examples which clarify the use of such dependencies. Before to conclude, I have to address a question that can arise: why we have to “re-invent” new relations by means of stereotyped dependencies when they are similar to the association-aggregation-composition relations already present in UML? The answer is simple: the traditional UML relations used in class diagrams do not differentiate between the interface and the implementation of a class. This is natural, because class diagrams are typically concerned with logical issues. From a logical point of view, what is and what is not used in the implementation of a component is unimportant because it is an encapsulated detail. Vice-versa, from a physical point of view, such usage can imply physical dependencies on other components. It is these physical dependencies that will affect maintainability, reusability, and testability in large systems.  Good design requires that the developer understands the issues involved in both logical and physical design. Thus, we need more expressive dependencies.