7
SOFTWARE—PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2002; 32:837–843 (DOI: 10.1002/spe.462) Developing object-oriented enterprise quality frameworks using proto-frameworks Marcelo Campo 1, ,† , Andr´ es D´ ıaz Pace 1,2 and Mario Zito 3 1 ISISTAN Research Institute, UNICEN University, Campus Universitario, B7001BBO Tandil, Argentina 2 CONICET, Buenos Aires, Argentina 3 ANALYTE - Lab Technology Solutions , Buenos Aires, Argentina SUMMARY In this article, we present an approach to architecture-driven design of object-oriented frameworks based on the notion of object-oriented materialization of architectural styles. This approach leads us to the development of the proto-framework concept, which is a new denomination for an object- oriented framework that provides the essential basis to build other frameworks that adopt an underlying architectural design derived from non-object-oriented styles. In this context, we describe the approach to framework design, the design of a particular proto-framework called Bubble, and a real example of its application to the design of an enterprise framework. Copyright 2002 John Wiley & Sons, Ltd. KEY WORDS: architecture-driven design; architectural styles; object-oriented frameworks; framework development; adaptability INTRODUCTION After the relatively recent advances in the field of software architecture and design patterns, architecture-driven design methods have become one of the most active and challenging research areas of software engineering [1,2]. These developments highlight the importance of models for software organization and, essentially, quality requirements, as the principal drivers for the design of quality software. Yet more importantly, they focus on the provision of methods for producing highly reusable software artifacts called product-line architectures [1] or object-oriented application frameworks [3,4]. For the last three years, the authors have been involved in the development of a design method for frameworks based on the combination of architectural styles [1] with object-oriented concepts. This design method is based on the notion of object-oriented materialization of a software architecture Correspondence to: Marcelo Campo, ISISTAN Research Institute, UNICEN University, Campus Universitario, B7001BBO Tandil, Argentina. E-mail: [email protected] Copyright 2002 John Wiley & Sons, Ltd.

Developing object-oriented enterprise quality frameworks using proto-frameworks

Embed Size (px)

Citation preview

SOFTWARE—PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2002; 32:837–843 (DOI: 10.1002/spe.462)

Developing object-orientedenterprise quality frameworksusing proto-frameworks

Marcelo Campo1,∗,†, Andres Dıaz Pace1,2 and Mario Zito3

1ISISTAN Research Institute, UNICEN University, Campus Universitario, B7001BBO Tandil, Argentina2CONICET, Buenos Aires, Argentina3ANALYTE - Lab Technology Solutions , Buenos Aires, Argentina

SUMMARY

In this article, we present an approach to architecture-driven design of object-oriented frameworksbased on the notion of object-oriented materialization of architectural styles. This approach leads usto the development of the proto-framework concept, which is a new denomination for an object-oriented framework that provides the essential basis to build other frameworks that adopt an underlyingarchitectural design derived from non-object-oriented styles. In this context, we describe the approach toframework design, the design of a particular proto-framework called Bubble, and a real example of itsapplication to the design of an enterprise framework. Copyright 2002 John Wiley & Sons, Ltd.

KEY WORDS: architecture-driven design; architectural styles; object-oriented frameworks; frameworkdevelopment; adaptability

INTRODUCTION

After the relatively recent advances in the field of software architecture and design patterns,architecture-driven design methods have become one of the most active and challenging research areasof software engineering [1,2]. These developments highlight the importance of models for softwareorganization and, essentially, quality requirements, as the principal drivers for the design of qualitysoftware. Yet more importantly, they focus on the provision of methods for producing highly reusablesoftware artifacts called product-line architectures [1] or object-oriented application frameworks [3,4].

For the last three years, the authors have been involved in the development of a design methodfor frameworks based on the combination of architectural styles [1] with object-oriented concepts.This design method is based on the notion of object-oriented materialization of a software architecture

∗Correspondence to: Marcelo Campo, ISISTAN Research Institute, UNICEN University, Campus Universitario, B7001BBOTandil, Argentina.†E-mail: [email protected]

Copyright 2002 John Wiley & Sons, Ltd.

838 M. CAMPO, A. D. PACE AND M. ZITO

derived from architectural styles. Our experience began with the development of a simple academicframework called Bubble, designed to support simulation of bubbly flow systems [5]. The frameworkwas then used to support the implementation of several simulation applications for different domains.The most relevant aspect of this work was that Bubble became the basis for the development of otherframeworks. In particular, Bubble supported the development of an industrial framework for EnterpriseQuality Management Systems (EQMSs).

On analyzing this versatility, we realized that the framework actually provided a set ofdomain-independent architectural abstractions, which made the mapping of domain concepts intocomputational components much easier. Additionally, the object-oriented representation enabled thereuse of the essential mechanisms prescribed by the architecture in the same way a normal frameworkdoes. However, the mechanisms provided by Bubble are more oriented towards a generic architecturalbehavior than a generic behavior of a domain. This aspect makes it difficult to classify Bubble into thedifferent framework classification schemes proposed in the literature [4]. Essentially, Bubble is a white-box framework; that is, it is reused by inheritance. However, from a functional point of view it cannotbe considered as a horizontal or service framework because it is not used by different frameworks, ascould be the case of a framework for building graphical user interfaces. Instead, different frameworkscan be derived from Bubble by inheritance, through the mapping of domain components into Bubblecomponents. For this reason, we refer to Bubble as a proto-framework; that is, an object-orientedframework that provides the essential basis to building new frameworks that adopt the underlyingarchitecture of Bubble.

PROTO-FRAMEWORKS AND FRAMEWORK DESIGN

Architectural styles and ABAS [1,6] aim at providing sound formalisms to describe essential structuresof software systems, whereas object-oriented frameworks represent the best technology presentlyavailable to achieve both design and code reuse. Nonetheless, to take advantage of both approaches it isnecessary to balance the tradeoffs imposed by a purely functional decomposition versus a purely object-oriented decomposition of a problem. In our view, the notion of architectural materialization is a key.By materialization, we mean the process of producing a concrete computational representation from anabstract description using a given technology. In this context, a proto-framework represents an object-oriented materialization of a software architecture derived from non-object-oriented architecturalstyles.

A proto-framework makes explicit essential architectural choices by means of object-oriented constructs, providing a domain-independent infrastructure implementing cooperation andcommunication of each component type. In other words, it gives very abstract hooks to mapspecific domain components into a class hierarchy in a white-box fashion. This mapping can lead tospecific applications and yet it can produce new domain-specific frameworks adopting the underlyingarchitectural model.

The proto-framework Bubble

Bubble is a proto-framework implemented in Java [5], originally conceived and designed to buildmulti-agent systems for the simulation domain. The current design of Bubble is the result of several

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:837–843

PROTO-FRAMEWORKS 839

Bubbles

ContainerBubble eventsRegistry

Sensors

Event

1. Bubble D sends an event E, as a result of

executing some task

4. Event E is

also received by

the container (it

is a bubble itself)

2. The container catches event

E, and dispatches it tothesensors interested in that event

5. Bubble A does not

receive event E, because

its sensor is not registered

to listen to those events

A

B

C

D

6. Sensors corresponding to bubbles B

and C perceive event E, and pass it to

their associated bubbles

3. Sensors hear events in

a certain neighborhood

within the container

Figure 1. Conceptual model of Bubble’s architecture.

design iterations, due to strong limitations of flexibility imposed for the initial object-oriented design.After realizing the problem, an implicit invocation style was chosen as the main design driver for thearchitecture and domain entities were modeled separating state from actions using the notion of tasks.The interaction among these entities, which we call bubbles, is performed through events that theyproduce and receive. Bubbles are also equipped with associated sensors (like filters) that are registeredto listen to certain kinds of events with a defined criterion of relevance (local, by group, by eventstrength, regional, etc.).

The behavior of any bubble is defined through independent tasks. This tasks use a condition–actionstyle, i.e. a task is a module composed by a series of actions to be executed by the bubble (action part)when certain conditions are fulfilled (condition part). Conditions can be related either to the internalstate of the bubble or the incoming events. The framework also admits bubbles containing groups ofother bubbles and tasks composed by groups of predefined tasks. In this way, complex interactions,structures and behaviors can be modeled combining primary blocks. Figure 1 shows a diagram ofthe underlying framework architectural model, illustrating a typical event flow between bubbles ina container and the role that sensors play in this process. Note that the outgoing events producedby bubble D are propagated only if the bubble is attached to a container, but this relationship is notmandatory. When a bubble receives an incoming event (the bubbles B, D, C and container, in theexample), the processing depends on the current tasks associated with the bubble.

The process of materializing the architecture of Bubble on an object structure was incrementallyaccomplished. Firstly, we produced a preliminary design for the architecture and then we refined itincluding several design patterns in order to provide more flexibility to the framework. The initial

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:837–843

840 M. CAMPO, A. D. PACE AND M. ZITO

design comprised the classes mapping the main components of Bubble, namely: bubble entities, tasks,sensors and events. Following our design approach, once we outlined a first abstraction of the Bubbleframework, we proceeded to improve it with a more detailed design. This step involved, for instance,the splitting of behavior in some classes, class refactorizations, and the application of design patterns.Essentially, the purpose of all these activities was to offer more possibilities of reuse and flexibility atthe framework level.

InQuality: THE REALIZATION OF THE CONCEPT

InQuality is a framework for EQMSs derived from Bubble, developed by Analyte Lab InformationTechnology. Essentially, InQuality is a framework for constructing structured document-basedapplications, which intends to support different types of control quality applications from, for example,ISO9000 compliance document management systems up to Laboratory Information ManagementSystems (LIMSs). The development started with consulting work for the design of an object-orientedframework, primary intended to support LIMSs, using standard object-oriented methods for frameworkdevelopment. After a few design iterations, the complexity of the design became unmanageable insize. This fact was due to two main reasons. The first one was the relatively little experience of thedevelopment team that tended to produce very complex designs. However, the most important was dueto the dynamic configurability and flexibility requirements that drove the design decisions.

In this situation, after analyzing the different variants of the domain, we concluded that the Bubblearchitecture could fit these flexibility requirements well. In addition, it could serve as a guide for thedevelopment team to map the required functionality into computational components. Following thisidea, the first version of the framework was designed in a short period. For the sake of communicationalsimplicity with the development team, the abstract notion of bubble was firstly refined into theconcept of agent. This way they could think about concrete autonomous entities using an establishedterminology. The design process had two phases as follows.

• Mapping the functional specification to Bubble components. This phase involved the decision ofwhat components should be mapped to bubbles, associated tasks and event types.

• Materialization of functional components through the design of subclasses that implement thespecific functionality of the EQM domain.

After the first iteration, the design was evaluated, trying to identify potential bottlenecks andarchitectural tradeoffs regarding security and efficiency. During a two-day workshop, a groupcomposed by the development team and the consulting staff carried out the evaluation following anadaptation of the ATAM method [6] for architecture evaluation. In this phase, several flaws wereidentified, and as a result, for example, a blackboard component was added. This aspect shows how thebase architecture of Bubble can be complemented with another architectural style, without loosing theadvantages of having an architectural guide for the rest of the framework design.

The final architecture is depicted in Figure 2. Shaded components correspond to Bubbleinstantiations, whereas non-shaded ones, except the blackboard, correspond to normal object modelsthat mainly provide static specifications for the rest of the components.

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:837–843

PROTO-FRAMEWORKS 841

Message Server(persistent and non persistent messages)

Web ServerServlet

User Interface Agent

(browser)

Role Manager

Page Builder

Security Model Application Interface Model

Specific Domain Model(LIMS, EQM...)

RDBMS Doc DB (XDB) File store ...

Document Model

WorkflowManager

Message flow

Object method invocation

Network

Figure 2. Architectural scheme of InQuality.

The workflow and role manager components

In this section, we describe in more detail the design of the workflow component of InQuality (seeFigure 3). This component is an example of how the mapping to the Bubble architecture simplifiedthe implementation of a complex component for workflow management and how it relates to the rolemanager.

A workflow usually represents a graph constituted by a set of activities (nodes) and paths (arcs)connecting these activities, related to the specific tasks to be developed in a work process of a product.In many cases, workflow activities are modeled using some variants of Petri-nets [7], and they areenacted by a workflow engine. In the InQuality case, however, each document type has an associatedworkflow. Each workflow is produced through a Petri-net-based graphical notation using a graphicaleditor. The editor produces a specification of the net that will be used to configure the specific workflowinstance. However, instead of having a centralized workflow engine, every particular workflow instance(or workflow process) associated with a document is represented as a container agent. Each activitywithin the workflow instance is represented as a single agent.

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:837–843

842 M. CAMPO, A. D. PACE AND M. ZITO

Document

Workflow Instance

(Container Agent)

WorkFlow Activities

(Activity Agents)

Changes

Manager

User

Technician

User

Pending Activities

Figure 3. Relationship among workflow activities, roles and participants and documents.

The workflow instance agent encapsulates the knowledge related to the structure of the particularworkflow and the one related to create the corresponding agents and associated tasks that willimplement the workflow. Activity agents listen to events generated by the execution of previousactivities and react when these events arrive. Tasks associated with activity nodes of the workflowwill produce messages directed, through the blackboard component, to the specific role or participantin charge of executing such activity.

When the ‘end of activity’ event arrives, the corresponding activity agent evaluates each of the rulesassociated with each path originating from it and generates the corresponding events that enable thenext activities in the workflow. This scheme greatly simplifies the implementation of the workflowmanagement component by mapping it into the simple conceptual model of bubbles and tasks.The dynamic nature of the task scheme makes it easy to configure a Participant agent with the tasksthat implement the activities it must execute. The Application Interface component is in charge ofcustomizing the user interface of each specific participant in order to show the activities it is expectedto accomplish, by simply asking the Participant Agent about its current tasks.

This organization is also used to control the access to system functions for each user according to hisrole. In this way, a given user can only see authorized functions, which are mapped from the interface tothe task that implements the selected function. For example, some users are allowed to edit documentswhile other users can only consult documents.

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:837–843

PROTO-FRAMEWORKS 843

CONCLUSIONS

From the development of InQuality we extracted several experiences that are currently driving thedevelopment of new versions of the framework. The first relevant conclusion was the importanceof the communicational aspects cited above. The development team felt more comfortable once aconcrete terminology, i.e. agents, was used to refer to the proto-framework components. Very abstractdenominations usually caused less-experienced members of the team to get confused about the role ofeach abstraction.

Another relevant lesson learned was that, besides the fact that framework design is a difficult task,the design of a complex enterprise framework needs more than domain expertise [9]. This kind offramework can be so complex that it requires the capacity of combining many computational factorsthat transcend the domain itself. Having a clear architectural guidance, such as the one provided by theBubble architecture, became a stronger advantage to having an elegant but complex framework fromwhich to start the development.

As several renowned authors have highlighted, the transition to object-oriented developmentrequires more than just knowledge about object-oriented programming and design concepts [8].The provision of technology-independent architectural guidance for organizing the development isalmost indispensable. This factor impacts positively in providing a smooth technology transitionfor a relatively inexperienced development team. Although the proto-framework concept still needsfurther research, we believe it represents a valuable aid for the reuse of object-oriented architecturalmaterializations.

REFERENCES

1. Bass L, Clement P, Kazman R. Software Architecture in Practice. Addison-Wesley: Reading, MA, 1998.2. Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-

Wesley: Reading, MA, 1994.3. Fayad M, Schmidt D. Object-Oriented Application Frameworks. Communications of ACM 1997; 40(10):32–38.4. Fayad M, Schmidt D, Johnson R. Building Application Frameworks: Object-Oriented Foundations of Framework Design.

Wiley and Sons: New York, 1999.5. Diaz Pace A, Trilnik F, Campo M, Fayad M. Accomplish adaptability in simulation frameworks: the Bubble approach.

25th Annual IEEE International Computer Software and Applications Conference (COMPSAC 2001), Chicago, IL, October2001.

6. Kazman R, Klein M. Attribute-based architectural styles. Report CMU/SEI-99-TR-022. Software Engineering Institute,Carnegie-Mellon University, Pittsburgh, PA, November 1999.

7. Workflow Management Coalition. Workflow Reference Model. http://www.wfmc.org [1995].8. Goldberg A, Rubin K. Succeeding With Objects: Decision Frameworks for Project Management. Addison-Wesley. 1995.9. Fayad M, Hamu D, Brugali D. Enterprise Frameworks Characteristics, Criteria and Challenges. Communications of the

ACM 2000; 43(10).

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:837–843