Can Design Pattern Detection be Useful for Legacy ... - CiteSeerX

Can Design Pattern Detection be Useful for Legacy System Migration towards SOA? Francesca Arcelli

Università degli Studi di Milano-Bicocca Via Bicocca degli Arcimboldi, 8, I-20126, Milan, Italy

[email protected]

Christian Tosi

Università degli Studi di Milano-Bicocca Via Bicocca degli Arcimboldi, 8, I-20126, Milan, Italy

christian.tosi @essere.disco.unimib.it

ABSTRACT

marco.zanoni @essere.disco.unimib.it

without making important changes to the legacy systems, but it is not so obvious. One of the most famous methodologies towards SOA migration is SMART (Service-Oriented Migration and Reuse Technique) described in [16] which analyzes the viability of reusing legacy components as the basis for services by answering several questions, such as: What services make sense to develop? Which service granularity should be used? What components can be mined to derive these services? What changes are needed to accomplish the migration? What migration strategies are most appropriate? Another interesting approach toward migration is described in [1] through a workbench framework called COMPASS (COde Migration Planning and ASSessment), which helps to understand VB applications, to assist in isolating business components in the code towards SOA and to identify possible migration obstacles. In the context of modernization an Architecture Driven Modernization (ADM) standard has been proposed by OMG [17], which aims to capture architectural aspects of existing applications. Here modernization is considered from an analysis and design based perspective to prevent propagation of obsolete concepts and designs in modern languages and platforms. Independently from the approach or methodology adopted during the migration process, to understand a system it is crucial to know its software architecture and to recover high level representations of the source code. A lot of tools for software architecture reconstruction (SAR) and program comprehension have been proposed for different languages which provide different views on the systems. For example, a SAR tool taxonomy has been introduced in [19], practice patterns for SAR are proposed in [22] and a very good description of the research challenges in this field and their practice solution are discussed in [20]. We have experimented different tools for SAR and program comprehension, such as SA4J [4], Doxygen [3], ARMIN [18], Swagkit [7], Codelogic [2] and Codecrawler [15] on systems of different sizes. We observed how some tools provide views that complement the information retrieved through other system views, and we are currently analyzing how these tools can be exploited during a migration process and which tools provide the most useful views. In this paper we explore if design pattern detection (DPD) could be useful in this context too.

Legacy systems maintenance involves different decisions, often very complex and sometimes requiring high costs and time. Hence studying and applying the right system modernization technique becomes very important for systems evolution. One of the solutions often adopted to modernize a system is the possibility to migrate it towards a SOA architecture. A lot of works in the literature have been done in this direction, which propose methodologies that provide some kind of migration strategy. In the migration process one of the main tasks is related to system comprehension. We often have to analyze not well documented systems, where it is difficult to identify the components which could become services or to recognize the possible problems we could face during the migration process. Software architecture reconstruction is certainly a relevant key activity, which is used for these purposes. In this paper we explore if design pattern detection could be also useful in the migration process: knowing that some design patterns have been applied in the system could give relevant hints to take decisions during migration.

Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures

General Terms Design, Experimentation

1.

Marco Zanoni

Università degli Studi di Milano-Bicocca Via Bicocca degli Arcimboldi, 8, I-20126, Milan, Italy

INTRODUCTION

In the context of legacy systems maintenance and modernization, several approaches focused their attention on systems migration towards SOA, even if it is well known that “service orientation is not the solution to all problems” [14]. The characteristics of SOA enable the exposure of legacy systems functionalities as services. This could be applied

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SDSOA’08, May 11, 2008, Leipzig, Germany. Copyright 2008 ACM 978-1-60558-029-6/08/05 ...$5.00.

63

2.1.1

DPD has been largely studied and applied in the context of reverse engineering [9] and a lot of tools have been developed for this purpose. These tools can be particularly useful for the comprehension of software systems. They provide helpful information about the organization and design of a system, indicating the logical fundamentals of its implementation. Moreover, detecting design patterns is important during the re-documentation process, in particular when documentation is very poor, incomplete or not up-todate. It is obvious that the DPD can be applied only in object oriented systems, but it is also well known that already a lot of object oriented systems exist, which need to be modernized, and in several cases this is done through migration strategies. In this paper we describe some design patterns which give, according to our analysis, relevant hints towards the SOA migration process: patterns whose presence could be useful and enhance the migration process and patterns which may create problems or obstruct the migration. Regarding the research perspective and challenges for maintenance and reengineering of service oriented systems described in [14], this work is placed in the context of the reengineering processes towards the migration of legacy components to SOA environments and of the tools, techniques useful to support maintenance activity. As observed before, reengineering tools, as the ones available for DPD, are very important to support comprehension and maintenance of legacy applications and, according to the considerations given in this paper, to support migration too. We are particularly interested in DPD since we are working towards the development of a tool, called Marple (Metrics and Architecture Reconstruction PLugin for Eclipse), whose main modules are devoted to DPD and SAR ( [10], [8]). Moreover, in our laboratory [6] we are very interested in experimenting and applying Smart methodology for the migration of both Cobol and Java systems and we are currently proving COMPASS on VB systems of medium complexity.

2.

• Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. [12, p185] • Wrap a complicated subsystem with a simpler interface.

2.1.2

Relevance

If you find this design pattern in your application you may have found a good service candidate. This means that there are a number of subsystems controlled by a component that exposes a common interface to the overall functionalities. You can identify a service with the fa¸cade component if you think that it directly exposes a service. On the other hand, if you think the granularity of its interface is too low, then you can think about it as a service composer and about each subsystem as a service candidate.

2.2

Mediator Mediator

Colleague

ConcreteMediator

ConcreteColleague1

ConcreteColleague2

Figure 2: Mediator UML diagram

2.2.1

Intent

• Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objs from referring to each other explicitly, and it lets you vary their interaction independently. [12, p273] • Design an intermediary to decouple many peers. • Promote the many-to-many relationships between interacting peers to “full object status”.

PATTERNS INVOLVED IN MIGRATION TO SOA

2.2.2

Relevance

This design pattern for our goal is similar to the fa¸cade pattern because the Mediator composes the behavior of its subsystems (where the fa¸cade composes the interfaces of its subsystems). Thus, you can identify a mediator as a high level service or as a service composer and each colleague as a service candidate.

In this section we describe some design patterns, as defined in [12], which we think are particular relevant in a SOA migration process when identified in a system, as they give additional information on the underlying architecture and behavior. The Intent section of each DP analysed is taken from [13], while in the Relevance section we describe the relevant or critical aspects of the pattern respect to the migration purpose.

2.1

Intent

2.3

Singleton Singleton

Façade

-instance: Singleton -Singleton() +Instance(): Singleton

Façade

Figure 3: Singleton UML diagram

Subsystems

2.3.1

Figure 1: Fa¸ cade UML diagram

Intent

• Ensure a class has only one instance, and provide a global point of access to it. [12, p127] • Encapsulated “just-in-time initialization” or “initialization on first use”.

64

2.3.2

Relevance

Client

A singleton is an object that exists in a unique instance, and it can be used by any other component dependent on it having the necessary access rights. It may have a state that depends from the overall system state (because of its unicity). Thus, it can be considered as a service without any other change. There is at least one other aspect to consider: the granularity, because a good service needs a medium/low granularity level, so if the singleton is too little it can be a good idea to keep it as a subsystem used by one or more services.

2.4

implementor

Abstraction

RefinedAbstraction ConcreteImplementatorA +OperationImpl()

AbstractProductA

AbstractFactory +CreateProductA() +CreateProductB()

ProductA2

Relevance

The Bridge DP expresses a high level of abstraction about the implementation of an interface. The Abstraction can be considered a good service candidate, as it wraps many possible APIs and is implicitly at low level of granularity and quite independent from other subsystems.

Client

ProductB1

ConcreteImplementatorB +OperationImpl()

Figure 5: Bridge UML diagram

2.5.2

ProductB2

+OperationImpl() implementor.OperationImpl()

Abstract Factory

AbstractProductB

Implementator

+Operation()

2.6

ProductA1

Decorator Component

ConcreteFactory1 +CreateProductA() +CreateProductB()

ConcreteFactory2

+Operation()

+CreateProductA() +CreateProductB()

ConcreteComponent +Operation()

2.4.1

-addedState +Operation()

Intent 2.6.1

• The new operator considered harmful.

super.Operation()

Intent

• Client-specified embellishment of a core object by recursively wrapping it.

Relevance

Even if a creational pattern such as the Abstract Factory does not directly have much to do with services, it could be a good idea to localize its instances, because they often realize the entry point in the use of a subsystem/library/component. Identifying abstract factories can help localizing high level components and entry points of the system that can be directly converted to services or wrapped by new services, if their behavior needs to be adapted to the paradigm.

2.5.1

ConcreteDecoratorB +Operation() +AddedBehavior()

• Attach additional responsibilities to an object dynamically. Decorator provides a flexible alternative to subclassing for extending functionality. [12, p175]

• A hierarchy encapsulating many possible platforms, and the construction of a suite of products.

2.5

component.Operation()

Figure 6: Decorator UML diagram

• Provide an interface for creating families of related objects without specifying their real classes. [12, p87]

2.4.2

+Operation()

ConcreteDecoratorA

Figure 4: Abstract Factory UML diagram

component

Decorator

• Wrapping a gift, putting it in a box, and wrapping it.

2.6.2

Relevance

In the Decorator pattern there is an incremental refinement of interfaces and functionalities through the stack of wrapped objects, and it can be done at runtime. It would be interesting to find out if the interfaces and objects can be treated as services and if any of them are used in other places of the system, in order to identify useful components. The most probable service is the highest level interface that wraps all the others.

Bridge Intent

2.7

• Decouple an abstraction from its implementation so that the two can vary independently. [12, p151]

2.7.1

Adapter Intent

• Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. [12, p139]

• Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy. • Beyond encapsulation, to insulation.

65

Target

Client

Client

Command

Invoker

+Execute()

+Request()

adaptee.SpecificRequest()

Adapter

Adaptee adaptee

+Request()

Receiver

+SpecificRequest()

receiver

receiver.Action()

ConcreteCommand -state +Execute()

+Action()

Figure 7: Adapter UML diagram Figure 9: Command UML diagram

• Wrap an existing class with a new interface. • Impedance match an old component to a new system.

2.7.2

2.9.2

Relevance

An Adapter can be nearly a service itself (maybe it adapts an older technology); if its interface is relevant as a service it can be possible to substitute it with a service (in order to simplify the object stack) or to adapt it to a service interface, or a combination of both. The presence of an adapter is a signal that the previous developers identified a legacy subsystem, so they delimited and adapted it. Hence, considering the previous effort involved in applying an Adapter DP, it is very useful in a migration task.

2.8

2.10

Chain of Responsibility Handler

Classe

+HandleRequest()

Proxy

ConcreteHandler1 +HandleRequest()

ConcreteHandler2

successor

+HandleRequest()

Subject

Client

+Request()

RealSubject +Request()

Figure 10: Chain of Responsibility UML diagram

realSubject.Request()

2.10.1

Proxy realSubject

+Request()

Intent

• Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. [12, p223]

Figure 8: Proxy UML diagram

2.8.1

Relevance

Commands are well encapsulated actions you can reuse. In this context they act as perfect bricks for a bigger service, maybe using the Command Facade pattern [21], that addresses the use of commands managed by a fa¸cade service.

Intent

• Provide a surrogate or placeholder for another object to control access to it. [12, p207]

• Launch-and-leave requests with a single processing pipeline that contains many possible handlers.

• Use an extra level of indirection to support distributed, controlled, or intelligent access.

• An object-oriented linked list with recursive traversal.

2.10.2

• Add a wrapper and delegation to protect the real component from undue complexity.

2.8.2

This pattern is similar to the service orchestration design paradigm found in the major SOA IDEs/tools. The possibility to compose procedures by dynamically using small objects with a common interface can be very useful. Thus, this pattern could represent a starting point to create services reflecting the chain elements. The other possibility can be to maintain the chain and wrap it with a service for each instance of the chain we need. This can be the right choice if single elements of the chain are too low level components.

Relevance

This is a pure stack of objects sharing a common interface. One possibility is that the Proxy can be substituted with a service that wraps the RealSubject object, as in the adapter hypothesis.

2.9 2.9.1

Relevance

Command

2.11

Intent

Context

• Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. [12, p233]

State state

State

+Request()

+Handle()

state.Handle()

ConcreteStateA +Handle()

• Promote “invocation of a method on an object” to full object status.

ConcreteStateB +Handle()

Figure 11: State UML diagram

• An object-oriented callback.

66

2.11.1

Intent

For example, the orchestration process done in a SOA environment is similar to the behaviour of the Mediator pattern, where there are a number of colleagues (the services) whose behavior is composed by a Mediator, that in a SOA is often implemented using a BPEL processor. Hence, we can easily observe that the two approaches are similar. This similarity is also shared by the Fa¸cade and Chain Of Responsibility Patterns, when they are applied to implement business processes. Since the first composes services from the structural point of view (but the pattern also allows the composition of subsystems functionalities), and the second naturally models processes by splitting steps into freely composable homogeneous tasks. This approach is not far from the perception of services as small bricks which are useful for composing business processes. A note in this context could be about the Observer pattern. If it is used to model business processes, it can be considered like a SOA anti-pattern, because its design is opposite, for example, from the Mediator pattern. Observer creates implicit dependencies between services at runtime. We can consider, for instance, a component that inserts a new item into a system and fires an item inserted event and another component that catches the event and sends a message to interested users. Using SOA we would transform this Observer instance into two services: an inserting service and a messenger, combined by a business process implemented at a different level. Another possible point of view is the migration one. Consider structural patterns based on object composition, and especially wrapping, like Bridge, Adapter, Decorator and Proxy: instances of these patterns show us stacks of functionalities that are interesting because they delimit subsystem areas. Even if these patterns have different intents, they all give us hints on the type of component composition, so we may discover that all or parts of these stacks can be recognized as entire or partial services. The State pattern also gives us other types of information during the migration process: we know services must be stateless, so its detection may be a warning to make a deeper analysis in order to understand whether that component can be maintained or must be changed.

• Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. [12, p305] • An object-oriented state machine. • Wrapper + polymorphic wrappee + collaboration.

2.11.2

Relevance

The concept of state in SOA is very important. Services should be stateless, as they can be invocated from any sources. This means that the service state is limited to the state of the domain model (stored in the persistence level) or passed through service parameters. Finding a State pattern can be a useful indication that a component’s behavior depends on its internal state. If this component is involved in a service, we should be sure that all the state transitions are always delimited by a single service invocation. Otherwise we must refactor the components to respect this design constraint.

2.12

Observer Subject

+Attach(in Observer)() +Detach(in Observer)() +Notify()

observer

Observer

foreach o in observers o.Update subject

ConcreteSubject -subjectState +GetState()

+Update()

observerState = subject.GetState()

ConcreteObserver -observerState +Update()

return subjectState

Figure 12: Observer UML diagram

2.12.1

Intent

• Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. [12, p293] • Encapsulate the core (or common or engine) components in a Subject abstraction, and the variable (or optional or user interface) components in an Observer hierarchy.

4.

• The “View” part of Model-View-Controller (MVC).

2.12.2

Relevance

Observer defines dependencies between a number of objects/components. We know that services must be independent of each other. Thus, if we detect an observer pattern modeling business processes, we must know that interaction has to be modified in a more procedural way, in order to show up at design time the dependencies that are implicit and defined at runtime. This does not represent a problem if only the “View” part of MVC is used.

3.

CONCLUSIONS

In this paper we explored if design patterns instances detection in a system could support the system migration toward SOA, always under the hypothesis that the system has some features, as those described in [14], where service orientation can be of benefit. For all the considerations given in the paper for each design pattern analyzed and the previous discussion, we think that DPD, or basically the knowledge of existing DP instances in a system, can be useful for a SOA migration task of an object oriented system. Obviously, migration to SOA is not just identifying the structures in the code, and there are many organizational issues that have to be addressed before deciding to start a migration process. However, when we have a legacy system and we decide to start a migration process, we hope that a pattern based detection approach as the one we described in the paper could give some useful hints to locate some components to be exposed as services. We are currently applying and experimenting our approach on two Java systems of medium complexity, by exploiting

DISCUSSIONS

The SOA paradigm differs from the OO paradigm from many points of view (e.g. Table 1, taken from [5]). Despite this, we can take advantage of some similarities between the different aspects of both paradigms.

67

Compare What is it? Exposes Granularity Interaction Interaction Model

Service Oriented Modeling, Design, Architecture Services Business-Level (Very Coarse) Service-Level, Inter-Service via service requests Document-based exchanges with services

Object Oriented Modeling, Design, Architecture, Progamming (Languages) Methods Object/Component-Level (Fine to Coarse) Object/Component-Level, Inter-objects/components via method calls RPC parameters exchanges with objects/components

Table 1: Comparison of Service Oriented and Object Oriented approach our Marple([10]) prototype and other known tools for DPD, hoping to validate the usefulness of the approach. In this case it would be interesting to include design pattern detection techniques in other methodologies proposed in the literature (e.g. [16]). Moreover, we are working on the integration of the results obtained through DPD tools in the direction described in this paper, with the views gained through SAR tools, trying to verify if the merging of the obtained information could enhance the migration process. We are also interested to explore if the detection of certain DPs could be useful to better understand when architectural mismatch in SOA occurs in practice [11].

5.

[12]

[13] [14]

ACKNOWLEDGMENTS [15]

The authors would like to thank Reply S.p.A Italy for their financial support in this research.

6.

[16]

REFERENCES

[1] Code migration planning and assessment workbench for visual basic. Web site. http://www.alphaworks.ibm.com/tech/compass. [2] Codelogic. Web site. http://www.logicexplorers.com/index.html. [3] Doxygen. Web site. http://www.stack.nl/~dimitri/doxygen/. [4] Sa4j: Structural analysis for java. Web site. http://www.alphaworks.ibm.com/tech/sa4j. [5] Soa: Oo and so - how you gonna get there? Web site. http://blogs.sun.com/alur/entry/soa_oo_or_so. [6] Software evolution and reverse engineering lab at university of milano bicocca. Web site. http://essere.disco.unimib.it. [7] Swag kit. Web site. http://www.swag.uwaterloo.ca/swagkit/. [8] F. Arcelli and C. Raibulet. Program comprehension and design pattern recognition: An experience report. In ECOOP 2006 International Workshop on Object-Oriented Reengineering (WOOR 2006), Nantes, France, 2006. [9] F. Arcelli, C. Raibulet, Y.-G. Gu´eh´eneuc, and J. Smith. Design pattern detection for reverse engineering. In Proceedings, of the DPD4RE Workshop, co-located event with IEEE WCRE 2006 Conference, Benevento, Italy, 2006. [10] F. Arcelli, C. Tosi, M. Zanoni, S. Maggioni, L. Cristina, and L. Ubezio. Metrics and architecture recognition plug-in for eclipse. Technical report, Universita’ degli Studi Milano Bicocca, 2006. [11] K. Bierhoff, M. Grechanik, and E. S. Liongosari. Architectural mismatch in service-oriented

[17]

[18]

[19]

[20]

[21]

[22]

68

architectures. In SDSOA ’07: IEEE Proceedings of the International Workshop on Systems Development in SOA Environments, Washington, DC, USA, 2007. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional, 1995. V. Huston. Design patterns. Web site. http://www.vincehuston.org/dp/. K. Kontogiannis, G. A. Lewis, D. B. Smith, M. Litoiu, H. Muller, S. Schuster, and E. Stroulia. The landscape of service-oriented systems: A research perspective. In SDSOA ’07: IEEE Proceedings of the International Workshop on Systems Development in SOA Environments, page 1, Washington, DC, USA, 2007. M. Lanza. Object oriented Reverse Engineering. PhD thesis, University of Berna, 2003. G. Lewis, E. Morris, D. Smith, and L. O’Brien. Service-oriented migration and reuse technique (smart). In STEP ’05: Proceedings of the 13th IEEE International Workshop on Software Technology and Engineering Practice, pages 222–229, Washington, DC, USA, 2005. P. Newcomb. Architecture-driven modernization (adm). In WCRE ’05: IEEE Proceedings of the 12th Working Conference on Reverse Engineering, page 237, Washington, DC, USA, 2005. L. O’Brien, D. Smith, and G. Lewis. Supporting migration to services using software architecture reconstruction. Software Technology and Engineering Practice, 2005. 13th IEEE International Workshop on, pages 81–91, 24-25 Sept. 2005. D. Pollet, S. Ducasse, L. Poyet, I. Alloui, S. Cimpan, and H. Verjus. Towards a process-oriented software architecture reconstruction taxonomy. In CSMR ’07: IEEE Proceedings of the 11th European Conference on Software Maintenance and Reengineering, pages 137–148, Washington, DC, USA, 2007. K. Sartipi and K. Kontogiannis. Managing Corporate Information Systems Evolution and Maintenance, chapter Software architecture analysis and reconstruction. Idea Group Publishing, 2005. J. Snell. Web services programming tips and tricks: Learn simple, practical web services design patterns, part 2. Web site, October 2004. http://www.ibm.com/ developerworks/library/ws-tip-altdesign2/. C. Stoermer, L. O’Brien, and C. Verhoef. Practice patterns for architecture reconstruction. In WCRE ’02: IEEE Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE’02), page 151, Washington, DC, USA, 2002.