Previous article

Next article


Applying Analysis Patterns Through Analogy: Problems and Solutions

Haitham Hamza, University of Nebraska-Lincoln, U.S.A
Mohamed E.Fayad, PhD, San Josè State University, U.S.A.

 

space TOOLS USA 2003
PROCEEDINGS


PDF Icon
PDF Version

Abstract

Traceability and generality are among the main qualities that determine the effectiveness of developed analysis patterns. However, satisfying both qualities at the same time is a real challenge. Most of the analysis patterns are thought of as templates, where they can be instantiated, and hence reused through an analogy between the original pattern and the problem in hand. Developing analysis patterns as templates might maintain the appropriate level of generality; however, it scarifies patterns’ traceability once they are applied in the developed system. In this paper, we illustrate the main problems with developing analysis patterns as templates and reusing them through analogy. In addition, we demonstrate, through examples, how stable analysis patterns [Hamza, 2002a,Hamza and Fayad 2002a] can satisfy both the generality and traceability, and hence, enhance the role of analysis patterns in software development.


1 INTRODUCTION

In the last decade, patterns have emerged as a promising technique for improving the quality and reducing the cost and time of software development [Schmidt et al., 1996, Gamma et al., 1995]. A pattern can be generally defined as: “An idea that has been useful in one practical context and will probably be useful in others” [Fowler, 1997].

The obscurity of doing accurate analysis along with the fact that analysis is a tedious and time-consuming activity both makes the development of effective and reusable analysis artifacts of great interest. Analysis patterns form a promising base for facilitating and improving the quality of performing analysis. Some essential quality factors an analysis pattern should maintain in order to contribute effectively to the development process.

In this paper we focus on two of these qualities: traceability and generality. Generality means that the pattern that analyzes a specific problem can be successfully reused to analyze the same problem whenever it appears, even within different applications or across different domains. This quality factor is essential due to the fact that the analysis of a specific problem is the same if the problem remains the same. There is little sense in having different analysis models for the same exact problem. If analysis patterns fail to model the exact same problem when it appears in different applications, then the goal of developing patterns as reusable artifacts is diminished.

Traceability means that a pattern that is used in the development of a specific system can be successfully traced back to the original analysis pattern that has been used. Untraceable patterns will disappear once the developer instantiate them in their system, the fact that imposes further complications in the maintainability of the system.

Satisfying both generality and traceability is a factual challenge in current analysis patterns. This challenge is due to the fact that most current techniques for developing analysis patterns are based on viewing patterns as templates that form a general model for the problem. These templates can be reused through analogy [Fernandez and Yuan, 1999, Fernandez and Yuan, 2000, Fernandez, 2000, Vaccare et al., 1998]. As we will discuss in the following section, this approach may maintain patterns’ generality to some extent; however, it may scarify their traceability.

In this paper, we illustrate the main problems in developing analysis patterns as templates and reusing them through analogy. As a remedy to these problems, we propose the use of the concept of Stable Analysis Patterns [Hamza, 2002a, Hamza, 2002b, Hamza and Fayad 2002a, Hamza and Fayad 2002b]. Stable analysis patterns are analysis patterns that are built based on the software stability concepts [Fayad and Altman 2002].

The paper is organized as follows: Section 2 describes the use of analysis patterns through analogy; Section 3 illustrates the problems associated with this approach; Section 4 provides an overview of stable analysis patterns; and Section 5 provides examples of using stable analysis patterns. The conclusions are presented in Section 6.

2 ANALYSIS PATTERNS AS TEMEPLETES

Most of analysis patterns are thought of as templates [Fernandez and Yuan, 1999, Fernandez and Yuan, 2000, Fernandez, 2000, Vaccare et al., 1998]. In [Coad et al., 1995], Code has defined patterns in general as follows: “A pattern is a template of interacting objects, one that may be used again and again by analogy”. That is, the pattern that is extracted from a specific project can be put into an appropriate abstract level such that it can be used to model the same problem in a wide range of applications and domains. The abstracted pattern is then considered to be a template, by which it could be used through an analogy. Developing patterns as templates, while providing an appropriate level of generality, it sacrifying their traceability when they are used by the means of analogy.

As an example of this approach, Figure 1 shows the class diagram of the Resource Rental pattern taken from [Vaccare et al., 1998], which forms the abstract template of the Resource Rental problem. The objective of the pattern is to provide a model that can be reused to model the problem of renting any resource; therefore, the class diagram does not tie the renting to a specific recourse. Figure 2 shows an example of using the Resource Rental pattern in the application of the library service taken from [Vaccare et al., 1998]. Simply through an analogy, one can apply the original abstract pattern into a specific application.

Fig. 1: Resource Rental pattern

Fig. 2: Instantiation of Resource Rental pattern for a library service

3 PROBLEMS WITH USING ANALYSIS PATTERNS THROUGH ANALOGY

Though using analysis pattern through analogy might appear to be an appealing approach for maintaining a good level of pattern’s generality; however, this technique raises some problems. Some of these problems are summarized below:

  • Generate untraceable systems. Once analysis patterns templates have been instantiated in the developed system, the original patterns are no longer extractable. For example, consider the instance of the Resource pattern shown in Figure 2 and imagine it as part of a complete library service system; it would be hard to extract the original pattern after such instantiation. This complication increases as the size of the developed system increases.
  • Complicate system maintainability. Software maintenance is considered to be one of the most costly phases in the development life cycle. Therefore, complicating system maintainability is expected to further increase such cost. One can imagine a very simple situation where we need to update the developed system documentation due to some modification in system requirements. Since the developed system is using several patterns, identifying which patterns to be updated will be tedious and time consuming task.
  • Trivialize classes’ roles of the pattern. To better discuss this issue we will use an example from [Fernandez and Yuan, 2000], where a class diagram for designing a computer repair shop is used, by an analogy, to build the class diagram of a hospital registration project. Thus, instead of shop that fixes broken computers we have a hospital that fixes sick people. We can simply replace the class named computer in the first project by the new class named patient in the next project. Even though such an analogy seems doable, it is impractical. There is a big difference between the computer as a machine and the patient as a human. These two classes might looks analogous since they both need to be fixed; however, their behaviors within the system are completely different. The role of the computer class is completely different from that of the patient. Therefore, such analogy is inaccurate. There would be even more differences if we try to generate the dynamic behavior of these two system using an analogy as suggested in [Vaccare et al., 1998].

4 STABLE ANALYSIS PATTERNS

Stable analysis patterns introduced in [Hamza, 2002a, Hamza, 2002b, Hamza, and Fayad 2002a], are analysis patterns constructed based on software stability concepts [Fayad and Altman 2002]. Before we describe how stable analysis patterns can satisfy both the generality and the traceability quality factors, a brief overview of software stability concepts, and an example of stable analysis patterns are provided in this section.

Software stability paradigm

Software stability stratifies the classes of the system into three layers: the Enduring Business Themes (EBTs) layer [Cline and Girou 2000, Fayad and Altman 2002], the Business Objects (BOs) layer, and the Industrial Objects (IOs) layer [Fayad and Altman 2002]. Based on its nature, each class in the system model is classified into one of these three layers. Figure 3 depicts the layout of the Software Stability Model (SSM) layers. Figure 4 shows the relationship between the different layers of SSM. The properties that characterize EBTs, BOs, and IOs are given in [Fayad 2002a, Fayad 2002b].

EBTs are the classes that present the enduring and core knowledge of the underlying industry or business. Therefore, they are extremely stable and form the nucleus of the SSM. BOs are the classes that map the EBTs of the system into more concrete objects. BOs are semi-conceptual and externally stable, but they are internally adaptable. IOs are the classes that map the BOs of the system into physical objects. For instance, the BO “Agreement” can be mapped in real life as a physical “Contract”, which is an IO.

Fig. 3: SSM layers layout

Fig. 4: The relation between SSM layers

Stable analysis pattern example

To illustrate the concept of stable analysis patterns we use a simple example. We use the Negotiation analysis pattern. Negotiation is a general concept that has many applications. In our daily life, there are various situations where negotiation usually takes place. For instance, buying or selling properties usually involves some sort of negotiation. In software systems, negotiation also appears frequently in the development of different applications. Developing software for online auctions and shopping might involve the negotiation of the price and/or the negotiation of different product aspects.

More technically, negotiation becomes an essential part in the development of next generation Web-based devices and appliances. Devices that need to access the Web diverge greatly in their capabilities, and hence negotiation mechanisms between client agent and the server play a fundamental role in deciding which representation of information a device should be given. Therefore, having a stable pattern that can model the basic aspects of a negotiation problem would make it easier for the developer to build their system by reusing and extending this pattern. Figure 4 shows the stable object model of the Negotiation pattern.

Fig. 5: Negotiation pattern stable object model

As shown in Figure 5 above, the Negotiation pattern consists of the following participants:

  • Negotiation:. Represents the negotiation process itself. This class contains the behaviors and attributes that regulate the actual negotiation process.
  • AnyAgreement: Represents the result of the negotiation. The ultimate goal of any negotiation is to reach an agreement. Thus, this object presents a core element in any negotiation. It is important to note that in many cases negotiation ends with no agreement and thus it is considered to be failed (the seller of the car did not agree on the price proposed by the buyer and vise versa), however, in this case we expect that the agreement should provide this result by whatever mechanism. So one can view the agreement object as the result of the negotiation, which is not necessary a successful result.
  • AnyParty: Represents the negotiation handlers. It models all the parties that are involved in the negotiation process. Party can be a person, organization, or a group with specific orientation.
  • AnyMedia: Represents the media through which the negotiation will take place. For instance, one can negotiate the price of a good over the phone. Others might use an email or a mail to negotiate specific issues in their business.
  • Context: Represents the matters to be negotiated. If we are buying a home, many issues could be negotiated. For instance, the price of the home, the payment procedure, etc. Defining what is the issue to be negotiated is an essential element of any negotiation process, otherwise, negotiation will have no meaning.

The prefix ‘any’ that we used herein indicates that this is another pattern that provides an abstract model for the notion it precedes. For instance, AnyParty is a stand-alone stable pattern that models the party notation, and hence, can be used to model any party in any applications.

5 APPLYING STABLE ANALYSIS PATTERNS

In order to illustrate how stable analysis patterns can maintain both the generality and traceability quality factors, we use the Negotation pattern to model two different applications: Negotiation of buying a car, and Content Negotiation using Composite Capability/ Preference Profile (CC/PP). For simplicity, we give parts of the models in both examples that help to demonstrate the usage of the proposed pattern, and hence, these models are not complete. The full analysis (CRC- cards, use case diagrams, use case descriptions, sequence diagrams, and state transition diagrams) of these two examples is given in [Hamza, 2002a]. In the models given in Figures 6 and 8, we use the black color to denote the EBT objects, gray color to denote BO objects, and while color for IO objects.

Example 1: Negotiation to buy a car

In buying a car, a negotiation concerning the car’s price and warranty usually takes place. This example models the simple negotiation that might be involved in buying a car. Figure 6 shows the stability model of the negotiation used in buying a car.

Fig. 6: Stability model of the negotiation in buying a car example

Example 2: Content Negotiation using Composite Capability/Preference Profile (CC/PP)

Today, very heterogeneous devices are required to access the World Wide Web; yet, each device has its own set of capabilities. As a result, a negotiation between the client and the server should take place in order for the server to know the capabilities of these devices and provide the appropriate contents. One possible techniques of performing content negotiation is called Composite Capability/Preference Profile (CC/PP) [W3C 2000]. A possible scenario of CC/PP content negotiation is given in Figure 7. Figure 8 shows the stability model of this example. Again, classes that are not in the original Negotiation pattern are colored in gray.

Fig. 7: Possible scenario of content negotiation using CC/PP

Fig. 8: The stability model of the content negotiation example

As shown in the two examples, the use of the Negotiation pattern is not achieved through an analogy. The pattern can be spotted easily and thus it is possible to trace it back in the developed system. On the other hand, the developed pattern does not lose its generality, as we were able to apply it to model the same problem in two different applications. Moreover, one can realize that each object in the Negotiation pattern has a clear role independent of the application the pattern will be used in. For instance, AnyMedia as an object still exists and it has the same role independent of the application; however, the type of media might vary based on the application.

6 CONCLUSIONS

Stable analysis patterns introduce a new vision of developing and utilizing analysis patterns in building software systems. Although current approaches of developing analysis patterns as templates and utilizing them through an analogy maintain pattern generality; it scarifies its traceability. This makes the developed systems harder and more costly to maintain. Stable analysis patterns are developed and utilized so that they can preserve both the generality and traceability. In addition, stable analysis patterns guarantee the preservation of the classes’ roles within the pattern; thus, each class has the same role independent of the application that the pattern will be deployed in. Therefore, stable analysis patterns can form a more effective base for utilizing patterns in developing software systems.

 

REFERENCES

[Cline and Girou 2000] Cline, M., and Girou, M. “Enduring Business Themes”. Communications of the ACM, Vol. 43, No. 5, pp. 101-106, 2000.

[Coad, et al. 1995] Coad, P., North, D., and Mayfield, M. “Object models-strategies, patterns, and applications”. Yourdon Press, Prentice-Hall, Inc. New Jersey, 1995.

[Fayad 2002a] Fayad, M. E. “Accomplishing software stability”. Communications of the ACM, Vol. 45, No. 1, 2002.

[Fayad 2002b] Fayad, M. E. “How to deal with software stability”. Communications of the ACM, Vol. 45, No. 4, 2002.

[Fayad and Altman 2002] Fayad, M. E., and Altman, A. “Introduction to software stability”. Communications of the ACM, Vol. 44, No. 9, 2002.

[Fernandez, 2000] Fernandez, E. B. “Stock Manager: An analysis pattern for inventories”. In 7th Pattern Languages of Programs Conference (PLoP’2k), Monticello, IL, USA, 2000.

[Fernandez and Yuan, 1999] Fernandez, E. B., and Yuan, X. “An analysis pattern for reservation and use of reusable entities”. In 6th Pattern Languages of Programs Conference (PLoP’99), Monticello, IL, USA, 1999.

[Fernandez and Yuan, 2000] Fernandez, E. B., and Yuan, X. “Semantic analysis pattern”. In 19th Int. Conference on Conceptual Modeling ER2000, pp. 183-195, 2000.

[Fowler 1997] Fowler, M. Analysis patterns: reusable object models. Addison-Wesley, 1997.

[Gamma et al., 1995] Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesely, 1995.

[Hamza, 2002a] Hamza, H. “A foundation for building stable analysis patterns”. Master Thesis. University of Nebraska, Lincoln, USA, 2002.

[Hamza, 2002b] Hamza, H. “Building stable analysis patterns using software stability”. 4th European GCSE Young Researchers Workshop (GCSE/NODE), Erfurt, Germany, 2002.

[Hamza and Fayad 2002a] Hamza, H., and Fayad, M. E. “Model-based software reuse using stable analysis patterns”. In 12th Workshop on Model-based Software Reuse, 16th ECOOP 02”, Malaga, Spain, 2002.

[Hamza and Fayad 2002b] Hamza, H., and Fayad, M. E. “A pattern language for building stable analysis patterns”. In 9th Pattern Languages of Programs Conference (PLoP’02), Monticello, IL, USA, 2002.

[Hay, 1996] Hay, D. Data model pattterns-conventions of thoughts. Dorset House Publ., 1996.

[Schmidt et al., 1996] Schmidt, D. C., Fayad, M. E., and Johnson, R. “Software Patterns”. Communications of the ACM, Vol. 39, No. 10., 1996.

[Vaccare, et al. 1998] Braga, R. T. V., Germano, F. S. R., and Masiero, P. C. “A confederation of patterns for business resource management”. In 5th Pattern Languages of Programs Conference (PLoP’98), Monticello, IL, USA, 1998.

[W3C 2000] Composite Capability/Preference Profiles (CC/PP): “A user side framework for content negotiation”. W3C Note 21 July 2000. http://www.w3.org/TR/NOTE-CC

 

About the authors

Haitham Hamza is a Ph.D. student at the University of Nebraska-Lincoln. He can be reached at hhamza@cse.unl.edu

Mohamed E. Fayad is a Full Professor of Computer Engineering at Josè State University http://www.engr.sjsu.edu/fayad. He can be reached at m.fayad@sjsu.edu or fayad@activeframeworks.com


Cite this article as follows: Haitham Hamza, Mohamed E. Fayad: “Applying Analysis Patterns through Analogy: Problems and Solutions”, in Journal of Object Technology, vol. 3, no. 4, April 2004, Special issue: TOOLS USA 2003, pp. 197-208. http://www.jot.fm/issues/issue_2004_04/article11


Previous article

Next article