Physical design vs. logical design (part II)


In the first instalment of this post, I introduced the notions of physical and logical designs. Then, I introduced three new stereotyped UML dependencies needed to express the relations between classes in terms of both interfaces and implementations. In this post I discuss how to transform a logical design  into a physical architecture that can be exploited in order to analyze the overall system testability.

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).

The shape editor

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).

Logical design of the shape editor

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.

shape-editor-logical-physical

Figure 3 - From logical to physical design

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

Physical design of the shape editor

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.

About these ads

About Andrea Baruzzo

Andrea Baruzzo is an author, a research fellow of the University of Udine, and an independent consultant. He has a strong experience in UML modeling and object-oriented technology, applying OOA/OOD in a wide variety of business applications. As a technical author he is a columnist on the magazine “Computer Programming” since 1999 and since 2003 he writes regularly for the column "Object-Oriented Design". As a research fellow, he is actively involved in the following two main areas: - software engineering, concerning in particular the automatic validation and verification of models; - knowledge representation, information filtering and retrieval; - [semantic] digital libraries, semantic Web, and service-oriented architectures (SOA). Andrea Baruzzo’s Specialties: Helping development teams to bridge the gap between analysis and design using models. Getting all team members to speak the same language, distilling the core of a complex domain and distilling out implicit knowledge in the models.

No comments yet... Be the first to leave a reply!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 72 other followers

%d bloggers like this: