Case Study on Systematic Functional Decomposition in a ... - CiteSeerX

Case Study on Systematic Functional Decomposition in a Product Line using Aspect Oriented Software Development ∗ Tegegne Marew, Jungyoon Kim, Doo Hwan Bae Division of Computer Science, Korea Advanced Institute of Science and Technology, Daejon 305-701, Korea {tegegnem, jkim, bae}@se.kaist.ac.kr Abstract Systematic configuration management is important for successful software product lines. We can use aspect oriented software development to decompose software product lines based on features that can ease configuration management. In this paper, we present a military maintenance product line that employs such strategy. In particular, we employed a specific approach, feature based modeling (FBM), in the construction of the system. We will discuss the specific advantages of FBM when applied to product lines. Such advantages include the functional decomposition of the system along user requirements (features) as aspects. Moreover, those features exhibit unidirectional dependency (i.e. among any two features, at most one depend on another) that enables developers analyze the effect of any modification they may make on any feature. In addition, any variations can be captured as aspects which can also be incorporated easily into the core asset if such variation is deemed to be important enough to be included in the product line for further evolution.

1. Introduction Software product line has been recognized as reuse intensive software development methodology. It relies on capturing potentially reusable behavior as core assets and product specific ones as variations. Since software product lines heavily rely on software decomposition based on user visible functions (features) [1], the approach used to realize software product lines should possess such property. One candidate is aspect-oriented software engineering [2]. Aspects which were originally created for capturing “crosscutting concerns” can also be used to capture basic func∗

This work was supported by the Ministry of Information & Communication, Korea, under the Information Technology Research Center (ITRC) Support Program.

tionality [3]. Such approach allows software product lines to profit from the advantages of aspect oriented software engineering. This paper presents a case study where we applied an aspect-oriented software development approach to realize a product line for a maintenance software system of a military. The aspect-oriented approach we use in the construction of the product line is called Feature Based Modelling (FBM)[4]. It was originally developed to enhance the trustworthiness of a software system by unidirectionally aligning features. Among the many characteristics of software product lines, their ability to systematically manage the evolution of a specific product as well as the entire product line (configuration management) has paramount importance. The challenges of configuration management are numerous and very difficult to address. In this paper we discuss only two of such challenges. The first is how we know what part of the software to change (add, delete, or modify) to realize the evolution we want. The second one is how we know the effect of the change on the rest of the system. We will show how FBM is used to address those two specific challenges of software product lines. This paper is organized as follows. Section 2 is devoted for the detailed discussion behind the motivation for this paper. In section 3, we present the related work specific to configuration management of software product lines. FBM, the approach we used in the construction of the military maintenance system is discussed in section 4. Then, the military system itself is presented in section 5 where we also describe the application of FBM to the construction of the system. Section 6 concludes the paper by summarizing the main points and pointing possible future work.

2. Motivation As described in the previous section, in this paper, we present a case study where FBM is applied for the construction of a product line for a maintenance software sys-

tem of a military. The motivation behind choosing FBM, an aspect-oriented approach, is mainly due to the advantage of AOP over OOP [5]. Specifically, we believe that the ease to achieve transparency through features using AOP and the ability of FBM to manage dependencies among different software modules make it a better approach. These properties play a significant role in reducing the complexity in configuration management of a software product line. Aspect oriented software engineering is originally introduced to complement OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Often, AOP is used to capture non-functional requirements as they are usually “cross cutting concerns”. As a result, many case studies on applying AOP in product lines use AOP only to capture the non-functional requirements and variations in specific products [6, 7, 8]. However, classes are not ideal to capture functional requirements entirely as features of the software in a modular way [7]. Aspects, on the other hand, have been suggested as a good candidate for capturing such features [10, 11]. In software product lines, usually there is no specific structure between the modules of the core assets at implementation level. If we modify one module, it is not easy to find what and how that change affects the rest of the system. Some [12] have suggested to keep a list of required and affected modules along with each core asset which easily doesn’t show the module/s that may have wide reaching effect if modified. Such knowledge is important for a single product development as well as family of products. What we need is an approach that explicitly captures the dependencies among different modules. FBM, to be explained in section 4, has such a property for improving the trustworthiness of a single product. In fact, this case study is conducted to see the application of FBM for a product line. FBM has shown promising results as a complementary approach to other established software methodologies in the development of single products [4]. We believe three related characteristics of FBM makes it a good candidate for an approach to realize software product lines. These are: • The ability to capture user requirements as features and realizing them as aspects. This will enable us to know what software module to modify in case of requirement changes either in the core assets or variations.

tematically control the ripple effect caused by modification. All these advantages become very handy during not only the configuration management of product lines but even during the construction of the software product lines. By mapping each user requirement to features realized as aspects, developers can enjoy better transparency during the different phases of development.

3. Related Work There have been researches conducted investigating the merit of aspect-orientation in product line development. There are case studies that use aspect-oriented programming in realizing software product lines. As we discuss below, such work mainly uses aspects either to capture nonfunctional requirements or introduce variations in specific products. M. Anastasopoulos and D. Nutig [3] have conducted a case study for a hypothetical mobile company that employs aspects in the implementation stage of a mobile phone software product line. They identified a group of criteria to systematically analyze the advantage of aspects. After using those criteria in their case study, they concluded AOP is especially suitable for variability across several components. The same conclusion is reached in [13]. In our work, we contend aspects can also be used effectively during core asset development. W. Gilani, et. al [6] have presented another case study involving aspects in implementing a product line. This time it is for adaptable middleware product lines. They used aspects to capture such middleware behaviors as security, transactions, and naming. These are commonly known as non-functional requirements and aspects are ideal to capture those requirements. Yet, we can also use aspects to capture functionalities as we will show in our case study.

4. Feature Based Modelling

• The ability to create a dependency graph between features. The graph readily answers the question “ Which modules or features are affected by a specific modification?”.

Feature Based Modelling(FBM) is an aspect-oriented software modelling approach that complements established methodologies like Rational Unified Process(RUP). FBM extracts features from use cases and aligns them in one direction. Since the features reflect functionalities in users requirements, users can easily map the functionalities to the features in design and code. FBM process consists of the following four phases:

• The ability to create a lattice among features thus enabling unidirectional dependencies. We can easily know not only which modules affect which ones but which ones have a wide ranging effect and thus sys-

• Functionality Alignment: Using an inquiry form, functionalities identified at requirement phase are categorized as essential and accidental. Accidental functionalities are dependent on essential ones but not

Rule 1 Rule 2

Feature 1

Feature 2

Feature 1

Communication Fire Arms Aircraft

A Feature

Feature 2

write

read only

Feature 1

Rule 3 Rule 4

Feature 2

Organizational

Feature 1

Feature 2

call

call

Feature 1

Depot Maintenance Plan

Feature 2

Tactical Standard Feature 1

General Ship

Feature 2

System State Feature 1

Fire Missile

Field Personnel Management

Maintenance Activities

Feature 2

Shared Unit

Figure 1. Rules for Feature Alignment

Management Data Colllection

Technical Standard

Maintenance Data Colllection

vice versa so that modifying accidental functionalities doesn’t affect essential user requirements. Such decision is made by an expert who identifies the dependence between user requirements in a tabular form. Such identification should also be based on factors like anticipation for change and change frequency. The result of the inquiry form can be represented in a directed graph. • Identify Features: Features are extracted from the functionalities identified in the previous phase. Often the functionalities become feature themselves. In cases, where functionalities share a sequence of activities (which is the result of analyzing their respective sequence diagrams), such shared activities become features themselves. • Identify Shared Units: This phase identifies any unit shared by more than one feature. The shared unit will be implemented in only one feature among all features that share the unit. For simple example, assume two features sharing one unit. At first, this unit sharing does not indicate any dependency direction, but this association will be replaced by a dependency arrow when one feature is selected to have the unit implementation. The selection is decided through consideration for essentiality of the two features. • Decide dependencies among features: This phase decides the dependency direction among features based on the result of the previous phases. Decisions are made according to the rules shown in Figure 1.(For detailed information on FBM, please check the home page at “http://www.salmosa.kaist.ac.kr/˜jkim”)

5. Case Study The product line we are developing is a product line for a maintenance software system of a military. The overview of the system is shown in Figure 2. Maintenance activities are generalized and grouped into seven major functionalities

Figure 2. Maintenance Support System for A Military

like tactical support and management data collection. Also each maintenance activity can be categorized into three levels according to the difficulties (organizational, field, and depot). All levels have similar maintenance activities (the seven mentioned earlier). The specific products are maintenance software system for eight departments such as aircraft and communication. Even at the specific product level, we still have the three levels of difficulties. During the design of the product line, the first step is to identify the functionalities in the core asset. These are: • Maintenance Activities: are actual maintenance on equipment with phases like job order, troubleshooting, dissemble and assemble. • Maintenance Plan: plans maintenance activities for each equipment. • Technical Standard:provides standard for maintenance. Technical orders or manuals that describes procedures for maintenance activities • Personnel management: manages data of personnel such as maintenance skill level, licenses for specialties • Tactical support: provides maintenance data to tactical department such as current status of resources that can be required for combat situation • Maintenance data collection/analysis: gathers data of equipment during maintenance activities such as operation time, fault occurrence frequencies and analyze to produce data such as mean time between failure (MTBF) • Management data collection/analysis: gathers data of management such as man hour,

F3

User registration Administrator Maintenance PlanIncludes

A :ActManager I

C WhoManager

Includes

who(Int,Int) selection(int)

technical(Int,Int,Int)

Display

Includes

selection(int)

Technician

Databae

DBManager

Display

Tactical Standards

Technical Standards Includes

H

StanSelectionr

when(Int)

Display

selection(int) Includes

G

B WhenManager

Technician Selection(Int)

Planner

standard(Int)

query

Display

Login Includes Includes

Maintenence Activities Maintenance Data Collection

Includes

Figure 4. Sequence Diagram of Technical Standard

Extends

Management Data Collection

Figure 3. Use Case Diagram of the Core Assets

F3

A :ActManager I

B

C

WhenManager

WhoManager

E Databae

DBManager

Technician Selection(Int)

After use case analysis of the functionalities, we have the use case diagram for the core assets as shown in Figure 3. As we see, there are three actors: the planner who takes care of the scheduling and the assignment of maintenance jobs, the technician who actually does the maintaining and finally the administrator who takes care of the personnel management. We have identified the functionality Personnel Management should be decomposed into two use cases: Login and Registration, because users need log in each time they use the system but need only to register once. Moreover almost all use cases need Login so it is included virtually by every use case. Since the planner needs to have information regarding the standards ( both technical and tactical) before planning a specific maintenance activity, we decided the maintenance plan to include both use cases related to standards. Finally, the management data collection extends the maintenance data collection since the data collected and analyzed by the management is a special case of total data collected by the maintenance data collection. Now, we are ready to extract features. Unlike approaches like Feature Oriented Domain Analysis (FODA) [1], our approach extracts features that are not necessarily user-visible but still are shared by a number of functionalities that are identified during use-case analysis. Often, use cases themselves end up being complete features but that will be decided after we draw the sequence diagrams of each use case. A portion of use cases (actually, part of their respective sequence diagrams) that occur in more than one sequence diagram is considered as a feature. This is in-line with our intent to use aspects as decomposition units. The original functionalities are still achieved since these shared features (later realized as aspects) are weaved to achieve the original functionality. In our product line, such phenomenon is observed in the use cases for technical standard and tactical standard whose

Display

when(Int) selection(int)

who(Int,Int)

Display selection(int) Display

tactical(Int,Int,Int) query

Display

Figure 5. Sequence Diagram of Tactical Standard

sequence diagrams are shown in Figure 4 and Figure 5. The rectangles in both sequence diagrams show the shared sequences among those diagrams. We create a new feature called “selection” which represents the shared sequences. By extracting such shared units, we guarantee modification is consistent and less time consuming which are important in configuration management. We describe such feature sharing as follows. Let S1 and S2 be the two sequence diagrams for technical standard and tactical standard respectively with A, B, C, D, and E describing the classes. When we say A.ma1, we mean the first method in class A. We can now describe the situation as shown in Figure 6. It shows how two sequence diagrams give rise to three features that are realized as aspects. In the first feature, F1, the aspect F3 is used at the beginning indicating F3 will be weaved into F1 during execution as in Fig. 7 (The {s:F3} in F1 indicate that F1 depends on an instance of F3). The same is true for F2. Therefore F1 and F2 are dependent on F3. Since, the sequence diagrams of the other use cases don’t have such property, no shared feature extraction is performed. We have reached to the phase where we identify shared units. Unlike shared sequences, we are not going to have a new feature. Instead, we select one of the features that share

S1

A.ma1

B.mb1

B.mb2

C.mc1

C.mc2

D.md1

S2

A.ma1

B.mb1

B.mb2

C.mc1

C.mc2

E.me2

E.me1

Registration Selection Log in

F1

{s: F3}

D.md1

F2

{t: F3}

D.md2

F3

A.ma1

B.mb1

Technical Standard

E.me1

B.mb2

C.mc1

C.mc2

Figure 6. Feature Extraction during shared sequences

feature 3

A ma1

B mb1 mb2

C mc1 mc2

Control3

Tactical Support

Maintenance Plan

Legend Read-write Includes Shared feature Proxy (shared unit) Extends

Maintenance Activities

Maintenance Data Collection

unit_composer

feature 1

D

E

md1

me1

Control 1 unit_composer

Management Data Collection

(a) Partial definition of classes in features Composed implementation

A ma1

B mb1 mb2

C mc1 mc2

D

E

md1

me1

Figure 9. Dependency among Features of the Core Asset

(b) Composed classes

Figure 7. Composing two features realized as Aspects

the unit to implement the feature and the other features that share the unit to have the proxy of that unit. During the analysis of the sequence diagrams of maintenance activity, management data collection and maintenance data collection we find such an instance. To perform their functionality, all three features need to specify the scheduled maintenance work they want to work on . As we can see from the features of for each use case (Fig. 8), they all have G.mg1 to indicate such selection of a particular scheduled maintenance work (the features are derived from their respective sequence diagrams (not shown) as the previous case). We chose maintenance activity (F1) to implement the G.mg1 while the other F2 and F3 have the proxy of G.mg1. As a result features F2 (for management data collection) and F3 (for maintenance data collection) are dependant on F1 (for maintenance activities). Finally we need to sort out all the dependencies based on the previous phases and the rules in Figure 1. The following are the dependencies among the features of the core asset. • L OGIN feature has a read/write dependency with R EG S1

G.mg1

H.mh1 I.mi2

S2

G.mg1

L.ml1

S3

G.mg1

K.mk2 F.mf3 K.mk3

N.mn1 N.mn2 I.mi1 J.mj2

F.mf1 I.mi1

I.mi3

Figure 8. Features with shared unit (G.mg1)

ISTRATION

since login needs the data collected during

registration • T ECHNICAL S TANDARD as well as TACTICAL S TAN DARD are dependent on S ELECTION feature as we extracted it from them because it is shared among them • M AINTENANCE P LAN depends on both T ECHNICAL S TANDARD as well as TACTICAL S TANDARD since it includes them (in the use case sense of  includes ). • M AINTENANCE P LAN depends on L OGIN since Login is included in Maintenance Plan. • M AINTENANCE ACTIVITY has a read/write dependency M AINTENANCE P LAN since the latter assigns the activities the former maintains. • M ANAGEMENT DATA C OLLECTION and M AINTE NANCE DATA C OLLECTION depends on M AINTE NANCE ACTIVITIES since they share a unit and we chose M AINTENANCE ACTIVITY to implement that unit. • M ANAGEMENT DATA C OLLECTION depends on M AINTENANCE DATA C OLLECTION because the former extends the latter (in the use case sense of  extends ) The unidirectional dependency achieved by applying FBM is shown in Figure 9. When it is time to develop the specific products, we don’t add new features to our core assets because we decide to follow a generalization approach where the core assets provide all the possible functionalities and each specific product enables specific features in the core asset. We are still study-

ing how to design each specific product. So far, we have decided how to design Aircraft, Missile, Communication, Personnel Management, Fire Arms and General. Aircraft and Missile needs all the core asset so we just use as-is. In case of Communication and Personnel Management, they don’t have M ANAGEMENT DATA C OLLEC TION feature. Since in the Core Asset Feature Dependency graph (Fig. 9) there is no feature that depends on it, we can use the other core assets as-is. The problem comes in case of Fire Arms and General which don’t need the TACTICAL S TANDARD feature. As we see in Fig. 9 a lot of features are dependent on TACTICAL S TANDARD feature. This indicates modifying it (deleting, adding new property, changing existing property), affects other core assets. Whatever approach is used to implement this product line has to provide two versions of M ANAGEMENT DATA C OLLECTION: one that depends on TACTICAL S TANDARD and another that doesn’t. The strength of our approach is it shows which features can be easily modified (have variants) and which are difficult to have variant for fear of affecting other features.

6. Conclusion and Future Works We have presented an on-going case study that shows the application of FBM to the construction of a military product line. We have shown how aspects can be used to represent functionalities whether they are i) functional or nonfunctional requirements, ii) user-visible or not (extracted features) and iii)in the core assets or in specific products. By applying FBM, we succeeded in identifying dependencies among features more clearly. Often feature modelling [1, 7, 11] is confined to domain engineering. As a result, there is no clear traceability between identification of features and their implementation. Because of such lack of traceability, even if we know the dependency among features in the domain, we have difficulty identifying the dependency at the implementation level. Our approach, by using aspects, solves that problem. We finally have shown, using FBM, how a dependency graph can be constructed among features which can be used to see how modification of a given feature affects other features. Therefore, we can to manage the ripple effect caused by the modification. We also learned during the development of specific products, how such graph can be used to see the difficulty associated with creating each product. In the future, we plan to finish the case study (including the implementation). We will also try to evolve the product line as a whole as well as each product to see how our approach helps us with configuration management.

References [1] K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson,“FeatureOriented Domain Analysis (FODA) Feasibility Study,” In Tech-

[2] [3]

[4]

[5]

nical Report CMU/SEI-90-TR-21., Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (1990). G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwi, “Aspect-oriented programming.,” In Proceedings ECOOP97 ,LNCS 1241, pages 220-242, Springer, 1997. M. Anastasopoulos, and D. Muthig “An evaluation of aspectoriented programming as a product line implementation technology”, In Proceedings of ICSR 2004, LNCS 3107, pages 141-156, Springer, 2004. J. Kim, D. H. Bae, “An Approach to Feature Based Modelling by Dependency Alignment for the Maintenance of the Trustworthy System”, COMPSAC 2004, 2004. C. Rathman, “A Short Interview with G”. Kiczales, lambdatheul-

timate.org/ classic/ message3189.html. [6] W. Gilani, N. Hasan Naqvi, and O. Spinczyk,, “On Adaptable Middleware Product Lines”,ACM/IFIP/USENIX 5th International Middleware Conference,2004. [7] M. Mezini, K. Ostermann, “Variability Management with FeatureOriented Programming and Aspects”,SIGSOFT04/FSE12, 2004. [8] A. Colyer and A. Clement, “Large-scale AOSD for Middleware”,ACM AOSD2004, 2004. [9] D. Batory, J. N. Sarvela, and A. Rauschmayer, “Scaling stepwise refinement.”,International Conference on Software Engineering (ICSE 03), 2003. [10] M. Griss, “Implementing Product-Line Features by Composing Aspects. In: Donohoe, P. (Ed.), Software Product Lines: Experience and Research Directions.”,Kluwer Academic Publishers), 2000. [11] D. Batory, J. N. Sarvela, and A. Rauschmayer, “Scaling stepwise refinement.”,International Conference on Software Engineering (ICSE 03), 2003. [12] N. Eickelmann, “A Case Study in Product Line Implementaion (Motorolla Labs)”, Fifth Ground System Architectures Workshop, 2001. [13] D. Batory, C. Johnson, B. Macdonald, and D. Heeder, “Achieving Extensibility Through Product-Lines and Domain-Specific Languages: A Case Study”,ACM Transactions on Software Engineering and Methodology, Vol. 11, No. 2, Pages 191-214,April 2002.