Extracting Domain-Specific and Domain-Neutral Patterns ... - CiteSeerX

Extracting Domain-Specific and Domain-Neutral Patterns Using Software Stability Concepts Haitham Hamza1, Ahmed Mahdy1, Mohamed E. Fayad 2, and Marshall Cline3 1

Computer Science& Engineering Dept., University of Nebraska-Lincoln, Lincoln, NE 68588, USA {hhamza, amahdy}@ cse.unl.edu 2 Computer Engineering Dept., Collage of Engineering, San José State University, One Washington Square, San José, CA 95192, USA m.fayad@ sjsu.edu 3 MT Systems Co. 5419 Bent Tree Dr., Dallas TX 75248, USA cline@ parashift.com

Abstract. Extracting domain-specific patterns and domain-neutral patterns is a challenge for both expert and novice software engineers. Currently, no mature guidelines or methodologies exist for extracting patterns. Software stability model proposed in [3] provides a base for extracting the core knowledge of the domain and identifying atomic notions that can be thought of as patterns by extracting another level of abstraction using software stability concepts. This paper proposes and demonstrates, through examples, how to extract both domainspecific and domain-neutral patterns from systems that are built using software stability concepts.

1 Introduction Extracting domain-specific patterns and domain-neutral patterns is a challenge for both expert and novice software engineers. Some developers might consider extracting patterns is easier than describing them [6]; however, extracting the patterns themselves is practically a real challenge that needs further exploration. Extracting patterns faultily, no matter how perfectly they are documented, substantially reduces their reuse value. Theoretically, patterns seem to be obvious and can be easily located within the developed system. By observing considerable numbers of systems, developers can spot and extract their patterns [6]. However, in practice this approach does not scale well, since many developers fail to extract the patterns this way. Software Stability Model (SSM), introduced in [3] and described briefly in the next section, forms a great promise in the area of software reuse. SSM applies the concepts of Enduring Business Themes (EBTs) [1], and Business Objects (BOs). The stability and reusability properties of the EBTs and BOs qualify them to serve as a base for building stable and reusable patterns.

Domain-specific patterns are defined in this paper as those patterns that capture the core knowledge of specific applications and, therefore, they can be reused to model applications that share the core knowledge. On the other hand, domain-neutral patterns are those models that capture the core knowledge of atomic notions that are not tied to specific application domains and, hence, can be reused to model the same notions whenever they appear in any domain. This paper proposes and demonstrates, through examples, how domain-specific and domain-neutral patterns can be extracted from systems that are built based on software stability concepts. The basic idea for domain-specific patterns is to combine EBTs and BOs to form a stable core pattern that can be reused to model the similar applications, and for domain-neutral patterns to model each EBT and BO independently using stability concepts again. The resulting patterns inherit the stability characteristics of the original objects they model; consequently they are stable and can be reused. Section 2 describes the architecture of the SSM and its concepts, Section 3 introduces the concept of extracting patterns from software stability models. Section 4 provides an example of extracting domain-specific patterns, and Section 5 provides an example of extracting domain-neutral patterns. Conclusions are presented in Section 6.

2 Software Stability Paradigm Figure 1 shows the layout of the SSM. Software stability stratifies the classes of the system into three layers: the Enduring Business Themes (EBTs) layer, the Business Objects (BOs) layer, and the Industrial Objects (IOs) layer [2], [3], [4], and [5]. Each class in the system model is classified into one of these three layers according to its nature. EBTs are the classes that present the enduring and basic 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 tangible 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. Even though the properties of each layer are fairly clear, identifying these layers in practice is not always obvious. The practitioner should consult [3], [4], [10] for heuristics to help identify EBTs, BOs, and IOs, and [5], [7], and [12] for complete examples of building different systems using software stability concepts.

3 Extracting Patterns Using Software Stability Concepts Software stability stratifies the classes of the system into EBTs, BOs, and IOs. The concept of extracting stable patterns from SSM is made possible due to the stable characteristic of both the EBTs and BOs.

IO

IO

IO

BOs EBTs

IO

IO

Stable Core IO

Fig. 1. Stable Model Concepts and their relationship

Systems that share the same domain have commonalities in their models. For instance, renting systems have core aspects that are common and independent of the nature of the rented item. Therefore, capturing these core aspects in a single model is beneficial for developing different renting systems without starting from scratch. As mapping to software stability concepts, the model that captures the common aspects of some systems is a model that combines both the EBTs and the BOs of these systems. This submodel forms a stable pattern for these systems. To obtain stable domain-neutral patterns from the stability model of one problem, we need to obtain a second level of abstraction for each EBT and BO in the stability model of the problem. This second level of abstraction is obtained by modeling each EBT and BO using stability concepts. Thus, we will have a stable model for each EBT and BO in the problem. Each new stable model will stand as a pattern by itself. This pattern focuses on a specific problem and can be reused to model this problem whenever it appears, therefore, it is considered to be a domain-neutral pattern. Stable domain-neutral patterns resulting from modeling each EBT and BO can be further classified into stable analysis pattern [7], [8], [9], and stable design pattern, respectively. For instance, a concept such as Satisfaction, which is an EBT, is a general concept that can be found in a wide range of applications that span different domains; whether developing a wireless telecommunication system or an interface for a bank’s ATM, Satisfaction is an essential goal. The stable model that represents the

EBT Satisfaction is a stable analysis pattern. Similar reasoning can be applied to BOs: the BO Account can be modeled and reused in the developing of different applications, so the stable model representing the Account BO is a stable design pattern. Figure 2 shows the steps of the patterns extraction concept. The paper shows a detailed example of applying the concepts of extracting patterns to the car-renting problem. Figure 3 shows a road map for the rest of the paper as four steps. The first step is to build the stable model of the problem itself. From the stability model of the problem, the combination of the EBTs and BOs is extracted as a domain-specific pattern called Renting. This pattern is then reused to model another renting problem (furniture-renting). The third step is to illustrate the concept of extracting stable domain-neutral patterns. To do so, we chose the EBT Negotiation and obtained its second level of abstraction by building the stability model for this EBT. The resultant model is a stable analysis pattern called Negotiation. To build stable design patterns, we chose two BOs: Account and Entry and generated the stability model for each of them. The resultant models are stable design patterns named AnyAccount and AnyEntry, respectively. In order to show the reusability of the extracted stable patterns, we used the AnyAccount and the AnyEntry patterns in the modeling of two different systems later in the paper.

Problem Apply SSM Concepts

Define EBTs, BOs, and IOs

Create SSM for the problem

EBTs

Second level of Abstraction “Model Each EBT Using SSM concepts”

Build Neutral Domain Stable Analysis Patterns

EBTs+ BOs

Build Domainspecific Stable Pattern

BO

Second level of Abstraction “Model Each BO Using SSM concepts”

Build Neutral Domain Stable Design Patterns

Fig. 2. The concept of extracting patterns using software stability model

1

2

EBTs + BOs

Stable Model for the Problem

Renting Pattern (Domain-Specific Pattern) EBTs

0

BOs

IOs

Renting

R e n t in g

Use SSM

Renting a Car

d e si e r s

1 ..*

A n y P a rt y

Negotiation

1..*

signs

AnyParty

AnyAgreement

R e n te r

i n i t i a te s

N e g o ti a ti o n

desiers

initiates

O rg a n i z a t i o n R e p re s e n t a t i v e

sig n s

specifies

A ny A g re e m e n t

opens 1..*

sp e c i f i e s 1 . .*

o pe ns

L i n e It e m

p ays

Car

AnyAccount

LineItem

A ny A c c o u n t re c e i v e s

has

ha s 1 .. *

Concepts

1..*

A n y E ntry

AnyEntry

1 .. *

A nyLog

ha s

1 .. *

R ec e ip t

P aym ent

1..* C heck

C ash

C r e d it C a r d

AnyLog

3

Receipt

BO

EBTs

Second level of Abstraction Model Negotiation Using SSM concepts

Second level of Abstraction Model AnyAccount and AnyEntry Using SSM concepts

Build Stable Analysis Patterns

Negotiation Pattern

has 1..*

Build Stable Design Patterns

•

•

AnyAccount Pattern AnyEntry Pattern

Fig. 3. Summary of the Examples presented in this paper to illustrate the proposed concept of extracting patterns using software stability concepts

4 Example of Extracting Domain-Specific Patterns Through a simple case study, we will illustrate how the combination of the EBTs and the BOs of one system can serve as a domain-specific pattern that can be reused to model similar systems. Part of the system for renting a car, as modeled using the SSM concept, is presented in Figure 4. The model has two EBTs: Renting and Negotiation. One might think of Availability as a candidate EBTs; however, we do not considered so as it does not involve a process; it is simply a state of yes/no flag, so it does not have enough substance to warrant being modeled as an EBT. Objects AnyEntry, AnyAccount, Receipt, AnyParty, AnyLog, AnyAgreement, and LineItem are each externally stable and internally adaptable; they are the system’s

BOs. Each BO is mapped to a real life object using the appropriate IO. For instance, the BO “LineItem” is physically represented by the IO “Car”.

EBTs

BOs

IOs Organization Representative

Renting

d esiers

1..*

AnyParty Renter

initiates

Negotiation

signs

AnyAgreement specifies opens

1..*

LineItem

pays

Car

AnyAccount receives has 1..*

AnyEntry 1..*

AnyLog

has 1..*

Receipt

Payment

Check

Cash

Credit Card

Fig. 4. Stable Object Model for Car-Renting

The EBTs, BOs, and their relationships in this system are valid for any rental system independent of what is rented. Consequently, the pattern can be reused as a base for modeling the rental of any entity. To further illustrate the reusability of the Renting pattern, the pattern is used to model the renting of a system that deals with different kinds of furniture. In this case we assume that the renter provides different kinds of rooms (dining rooms and bed rooms) and couches. The renter policy is to accept only a credit card payment. A part of the problem model is shown in Figure 6.

desiers

Renting

1..*

AnyParty

i ni tia tes si gns

Negotiation

AnyAgreemen t speci fi es opens 1.. *

AnyAccount

LineItem

has 1 .. *

AnyEntry 1 .. *

AnyLo g

has

1..*

Rec eipt

Fig. 5. Renting Pattern Object Model

EBTs

BOs

IOs Organization Representative

Renting

desiers

1..*

AnyParty Renter

initiates

Negotiation

signs

AnyAgreement specifi es

Couch

re ceives

1..*

opens

LineItem pays

Room

AnyAccount has 1..*

DiningRoom

AnyEntry

BedRoom

1..*

AnyLog

has 1..*

Receipt

Payment

Credit Card

Fig. 6. Stable Object Model for Renting Furniture

5 Example of Extracting Domain-Neutral Patterns The previous section illustrated how the combination of the EBTs and BOs can form a stable pattern that can be reused to model applications within the same domain for which it was conceived. This section illustrates how to extract stable analysis and design patterns from the stability model of the system. One EBT and two BOs are chosen, and their models are built as stable analysis and design patterns. To illustrate the reusability of these patterns, two of them are reused to model three different applications. The EBT Negotiation can be used as a driver for building a stable analysis pattern by generating its second level of abstraction. This can be achieved by modeling this EBT further using software stability concepts. The resultant pattern is the Negotiation stable pattern that can be used to model the negotiation aspects whenever it appears. The stable object model of the Negotiation pattern is given in Figure 7 below.

AnyContext 1..* negotiates

AnyMedia

1..*

uses

Negotiation

hand les 1..*

AnyParty

generates 0..*

AnyAgreement

Fig. 7. Negotiation pattern object model

The Negotiation pattern comprises one EBT: Negotiation and four BOs: AnyMedia, AnyContext, AnyAgreement, and AnyParty. For instance, AnyParty is a stand-alone stable pattern that models the party notion; hence it can be used to model any party in different systems. The full documentation of the Negotiation pattern can be found in [11]. The first BO is Account. Account is a recurring problem that spans a wide range of applications. Using the stability concepts, we were able to construct a stable pattern that models the base of any account. This pattern is called AnyAccount and its stable object model is shown in Figure 8. In this pattern, Ownership is an enduring concept that is always needed for all accounts. AnyParty is a BO that is externally stable yet internally adaptable. We added the inheritance structure shown in the model to capture some situations that might occur in different kinds of accounts. For instance, a single credit card account can have more than one holder, such as a “primary holder” and a

“secondary holder.” This situation can be handled through the definition of the different roles corresponding to each holder.

has

Ownership ownership o wnership

1..* party

AnyParty

1..*

Role_1

Role_2

........

Role_n

controls

AnyAccount account

Fig. 8. AnyAccount pattern object model

The second BO is Entry. Using the stability concepts, we constructed a stable pattern that models any entry. This pattern is called AnyEntry and its stable object model is shown in Figure 9. Since the basic objective of an entry in any application is to keep records for something, Recording is an enduring business theme that will never change. Whenever we have an “entry” in any application, the object Recording will be there. The AnyEntry can be either formatted following defined structure, or unformatted (i.e. free-formatted).

keeps

Recording re cording

AnyParty party

record in g enters entry

1..*

AnyEntry

Unformat edEntry

FormatedEntry

Fig. 9. AnyEntry pattern object model

To show the reusability of the extracted patterns, the AnyAccount and the AnyEntry patterns are further used in the modeling of two different systems: a simple copy machine account, and an email account.

5.1 Copy Machine Account This simple problem shows how to use the “AnyAccount” pattern in the modeling of a simple copy machine account for students in one of the universities. Suppose that each student in the university has an account that he can use to access a central copy machine. Figure 10 gives the stable object model of the Copy Machine Account. For instance, the IO Student presents a one instance for the BO AnyParty. Each student has a CopyMachineAccount in order to use the copy machine.

EBTs Ownership

BOs ha s o wner sh ip

1..* party

AnyParty

IOs Student

ownership

c ont ol s 1..*

AnyAccount

Copy MachineAccoun t

acc ount

Fig. 10. Copy machine account stable object model

5.2 Email Account The stable object model of a simple email account is shown in Figure 11. As in the previous example, the AnyAccount and the AnyEntry patterns are reused in the modeling of this example. It is worth to notice how two stable patterns are connected together in one model. As shown in Figure 11, the connectivity between the two used patterns is realized in the EBT and BO layers but not the IOs layer.

EBTs

BOs has

Owner s hi p o wn e rsh i p o wn e rsh i p

1 ..* p a rty

IOs

A ny P arty

Em ai lUse r

co n to l s 1 ..*

A ny A c c ount

E m ailA cc ount

1 ..* i n serts

e n te rs

Rec ording re co rd i n g

1 ..* e n try

A ny E ntry

Unform atedE ntry

E m ailM es sage

F orm atedE ntry

Fig. 11. Email Account Stable Object Model

The two above examples demonstrate how can stable patterns, the AnyAccount and the AnyEntry patterns, be used to model different problems. The diversity nature of these applications reveals the stability and the reusability of the constructed patterns. The stability and the reusability of the constructed patterns are inherited from the stability characteristics of the original BOs (i.e. Account and Entry) that have been chosen to construct them.

6 Conclusion The Software Stability concept forms a base for building stable and reusable software patterns. The combination of the EBTs and BOs of one system can form a stable domain-specific pattern that can be reused to model similar systems. In addition, each EBT and BO in the SSM can be further modeled using stability concepts, and those models can be used to form domain-neutral patterns. The resultant patterns are stable and demonstrate efficient reusability while modeling different systems. However, there appear to be practical limits to this recursive approach. Although it seems to help if we reapply the concepts of software stability to an EBT or BO, repeatedly doing this can result in meaningless and/or useless patterns. The practical limit seems to be two levels of modeling. For instance, modeling the EBT Ownership in the AnyAccount pattern might be doable, but the resultant pattern will be very ab-

stract and therefore will lose its usefulness in practice. The extraction of stable software patterns using the Software Stability Models (SSM) is a promising approach that merits further research and investigation.

References 1. Cline, M., Girou, M.: Enduring Business Themes. Communications of the ACM, Vol. 43, No. 5, May (2000) 101-106 2. Fayad, M.E.: Accomplishing Software Stability. Communications of the ACM, Vol. 45, No. 1, January (2002) 3. Fayad, M.E., Altman, A.: Introduction to Software Stability. Communications of the ACM, Vol. 44, No. 9, September (2001) 4. Fayad, M.E.: How to Deal with Software Stability. Communications of the ACM, Vol. 45, No. 4, April (2002) 5. Fayad, M.E., Wu, S.: Merging Multiple Conventional Models into One Stable Model. Communications of the ACM, Vol. 45, No. 9, September (2002) 6. Gamma, E., et al.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York (1995) 7. Hamza, H.: A Foundation for Building Stable Analysis Patterns. Master thesis, University of Nebraska-Lincoln, USA, August (2002) 8. Hamza, H.: Building Stable Analysis Patterns Using Software Stability. 4 th European GCSE Young Researchers Workshop 2002 (GCSE/NoDE YRW 2002), Erfurt, Germany, October (2002) 9. Hamza. H., Fayad, M.E.: Model-based Software Reuse Using Stable Analysis Patterns. 12 th Model-based Software Reuse Workshop, 16 th ECOOP ’02, Malaga, Spain, June (2002) 10. Hamza. H., Fayad, M.E.: A Pattern Language for Building Stable Analysis Patterns. 9 th Conference on Pattern Language of Programs (PLoP 02), Illinois, USA, September (2002) 11. Hamza. H., Fayad, M.E.: The Negotiation Analysis Pattern. Eighth European Conference on Pattern Languages of Programs (EuroPLoP 03),Irsee, Germany, July (2003) 12. Mahdy, A., Fayad, M.E., Hamza, H., Tugnawat, P.: Stable and Reusable Model-Based Architectures. 12th Model-based Software Reuse Workshop, 16 th ECOOP ’02, Malaga, Spain, June (2002)