2007 1st Annual IEEE Systems ConferenceWaikiki Beach, Honolulu, Hawaii, USA April 9-12, 2007

TOWARDS STRATEGIC DESIGN REUSE BYLEVERAGING COMMONALITY AND MANAGING VARIABILITY

Shihong Huang Ravi Shankar Jan MangsDept. of Computer Dept. of Computer Dept. of Computer

Science & Engineering Science & Engineering Science & EngineeringFlorida Atlantic Florida Atlantic Florida Atlantic

University University UniversityBoca Raton, FL 33431 Boca Raton, FL 33431 Boca Raton, FL 33431

+ 1 561-297-1275 + 1 561-297-3470 + 1 561-929-4894shihong@cse.fau.edu ravi@cse.fau.edu jmangs@fau.edu

Abstract - Increasing software productivity Increasing software productivity and shorten theand shortening the software development software development cycle have become criticalcycle have become critical to the success of to the success of an organization. This paperan organization. Some commonly used proposes a methodology to support this goalstrategies to shorten the software through the strategic reuse of design artifacts.development cycle while simultaneously In particular, we propose to develop aincreasing programmer productivity and methodology for identifying commonality andproduct quality include improving software variabilityin core design assets as represented bprocesses, deploying new technologies, and UMlygI We yill alsotseveloppreseries ofreusing software artifacts. This paperpresents UML diagrams. We will also develop a series ofa ongoing work that focuses on strategic tools that realize the methodology (implementedadongoingnreuse bytleraggfocu onsratgitya as a series of Eclipse plug-ins). This work is partdesign reuse by leveraging commonality and ofalreefrtocsdnmiaigtwrsamanaging variability in design artifacts. It of a larger effort focused on migrating towards autilizes the methodologies of Model Driven model-driven engineering approach for effectiveEngineering (MDE) and Software Product enterprise software development. Precise modelsLines (SPL). This work is part of a larger effort enable automation and productivity.focused on migrating towards model-driven Some of the commonly used strategies to shortenengineering approach for effective enterprise the software development cycle whilesoftware development, simultaneously increasing programming

productivity and product quality include improvingKeywords: model-driven engineering, software sotaepcs,dplyn nwtchlgi,product lines, reuse, design, UML software process, deploying new technologies,

product linesreuse,design,UMLand reusing software artifacts. These three

1. INTRODUCTION aspects are briefly discussed in the followingsections.

Software has become ubiquitous in almost every 1.1 Improving Software Processsector of life. Some of the universal businessgoals include producing high quality software, Process improvement is a series of actions takenquick time to market, maintaining low cost, and to identify, analyze, and improve existing processsatisfying customers' needs. within an organization to meet new goals andAcknowledgement: This work has been supported in objectives. Process improvement has been shownpart by the One Pass to Production(OPP) grant, a multi- to be an effective way to lower costs, improveyear research project sponsored by Motorola Inc. productivity and quality, and deliver products and

services on time. Process improvement hasproven to be a successful method of achieving

1-4244-1041-X/07/$25.00 ©)2007 IEEE 1

some of these goals. The benefits of adopting a needs of a particular market segment or mission,process improvement program such as the SW- and that are developed from a common set ofCMM are well documented. However, there is a core assets in a prescribed way" [6]. Softwarelimit as to how far one can go with changing the product lines can help facilitate high-level,management process without changing the strategic design reuse by leveraging commonalityengineering process. and managing variability across multiple

applications with a common architecture. In this1.2 Deploying New Technologies way, product lines are a direct response to the

perceived shortcomings of lower-level reuseNew technologies, such as automation, also have methods that were described in the previousan important role to play in achieving some of the section.goals listed above. Codification of best practice in SPLs have already proven themselves successfula particular application domain in a tool is a tried- in several applications domains. For example,and-true technique for reducing the complexity of Cummins Inc. produces diesel engine controlthe problem space for less-experiences systems. They have over 20 product groups withengineers. A difficulty with this approach is the more than 1,000 separate engine applications. Bycost needed to train the engineers to use the new adopting a product-line approach, product cycletools in an effective manner. time was slashed from 250 person-months to aAs illustrated in [6], software component reuse few person-months, and build and integration timewas the focus on considerable attention in the was reduced from one year to one week [2]. They1990s. Unfortunately, results from this strategy fell found that their quality goals were exceeded andshort of expectations and did not achieve that their customer satisfactions was higher thansignificant ROI and business value. This was due before.in part to the nature of code (component) reuse, In the Command and Control (C2) domain,which is low-level, fine-grained, and opportunistic. Raytheon developed a ground-based spacecraftThere are inherent limitations to this type of reuse. command and control system called the ControlHowever, reuse as an improvement strategy is Channel Toolkit using a product-line approach [2].still a promising avenue to explore - just need to They found that quality increased quality by lOx,be at a different (higher) level of abstraction: incremental build time was reduced from monthsdesign. to weeks, software productivity increased by 7x,

development time and cost decreased by 50%,1.3 Reusing Software Artifacts and product risk was significantly decreased.

One application area that has enjoyedLow-level components can be made reusable, buttheir r pconsiderable success through software producttheir reuse potential IS closely linked to the lines is mobile phones. Indeed, mobile phones are

implementation domain. True reuse value is better an id pla for softwar eprc nes,seachievd whe the rtifat beig reued is an Ideal platform for software product lines, sinceachieved when the artifact being reused IS

coarser-grained (e.g., frameworks) than relatively there is a high degree of commonality across allsimple components that often lack the context models, yet there is also a significant amount ofprovided by an architecture. Furthermore, variability in terms of the user features and theopportunistic reuse.reliesonad-hoc implementation characteristics. For example,opportunistic reuse relies on ad-hoc scavenging different phones will have a varying number of

from a repository. Greater benefit can be achieved keys, with varying display sizes, offering a varyingthrough pre-planned strategic reuse - something sets of features. There is a need to run multiplethat can be realized through the use of software operating systems (e.g., Symbian, Windowsproduct lines. Mobile, Linux), support multiple protocols (e.g.,

CDMA, GSM), and support multiple national2. SOFTWARE PRODUCT LINES AND languages (e.g., English, Chinese, Spanish) [4].

MODEL DRIVEN ENGINEERINGIn one much-publicized case study [9], Nokiadocumented how they adopted a product-line

2.1 Software Product Lines approach to Web browsers for their cell phones.Although there were costs associated with the

A software product line (SPL) is "...............a set of introduction of product lines into their processes,software-intensive systems sharing a common, they found the benefits outweighed the drawbacksmanaged set of features that satisfy the specific by a measurable amount. One of the keys to their

2

success was retroactively identifying artifacts that 4. RESEARCH METHODOLOGYwere common across multiple products, andclearly delineating these common features from 4.1 Goalrelease-specific variabilities.

2.2 Model-Driven Engineering The primary goal of this research is to develop amethod for identifying commonality and variabilityin core design assets - leveraging commonality

Software Product Lines approaches directly and managing variability (LCMV).support Model Driven Engineering, which is one ofthe primary philosophy to shorten software life Towards this end, as a secondary goal we willcycle and in the meantime increase software develop distance measures that capture thequality. In Alan Brown's article [14] he shows the relative "sameness" of a collection of high-levelmodeling spectrum from code-only to model-only software designs.approach in software development in the context These measures will be used to identify commonof MDE. Model-driven engineering has become features that cut across multiple designs, andone of the best approaches for effective enterprise isolate variabilities that are specific to uniquesoftware development. Precise models enable designs. The measures will be highly tailorable byautomation and productivity. the end-user, so that they can be applied to

specific application areas with more refinement.3. COMMONALITY AND VARIABILITY

4.2 MethodologyAt the heart of software product lines are thenotions of commonality and variability. Artifacts In order to make the problem more tractable, wethat share a sufficient number of common features will assume that design artifacts are representedare candidates to become part of the "core as UML diagrams. For legacy systems whereassets" of the product line. Those artifacts that fall such diagrams are not available, a pre-processingoutside of this commonality threshold are not part stage will be needed to recreate such designsof the core assets, but instead are specific to a from source code and other artifacts [11]. Thesingle product due to variances in key features. UML representation is needed because it offers aThe benefit of identifying design commonality and standardized representation of design that isvariability is to support multiple target platforms. understandable by software engineers yet is alsoPlatform independent models (PIM) (commonality) machine processable.capture the functionality of a system but don't The methodology will be based on three differentdepend on a specific implementation platform, so analysis techniques.it is easier to switch between platforms. Commonfunctionality is modeled and transformed to be * The first is graph-based. This approachused to generate implementations for the different does not incorporate domain knowledge,platform (variability), therefore, reducing the cost but does leverage the extensive body ofof supporting multiple platforms and ensuring research from graph theory and toolconsistency across them. support for graph matching.In order to determine whether or not an artifact is * The second approach is text-based. Ita candidate for promotion to a core assets, one analyzes the XMI representation of themust first determine how to measure similarity UML design artifacts, leveraging previousbetween the artifacts. One must also set a work in areas such as pattern recognition,threshold for this measure, to distinguish between data mining, and machine learning.common and variable assets. * The third approach incorporates spatialFor design artifacts, such as UML diagrams, layout information and stylistic guidelines insimilarity measures can take into consideration a the models that capture design intent.wide variety of characteristics. These include Using UML also builds upon our existing strengthsclassic design quality indicators such as coupling in the area. For example, we have been workingand cohesion, graphical style and spatial layout for some time on developing style guidelines forinformation, graph-theoretic measures (e.g., UML diagrams in the context of graphicalconnectivity), application- and domain-specific documentation [12]. More recently, we begandesign patterns, and so on.

3

work on a project to develop an assessment [2] Clements, P. and Northrop, L. Softwareinstrument to evaluate the fidelity of UML diagram Product Lines: Practices and Patterns.tools in support of design reuse [8]. Addison Wesley Professional, 2001.

In developing the design distance measures, we [3] Everitt, B. Cluster Analysis. Heinemanwill leverage previous work in related areas Educational Books, London, 1974.wherever appropriate. Such areas include clusteranalysis [3][13], pattern recognition, data mining, [4] Heie, A. "Global Software Product Lines and.' '. ~~~~~~~Infinite Diversity." In Proceedings of the 2ndmachine learning, reverse engineering [10], and Software Product Line Conference. Augustsoftware clustering and decomposition via 19-22, 2002; San Diego, CA.coupling and cohesion metrics [1].The tools that implement the design reuse [5] http//www.sei.cmu.edu/architecturemethodology will be implemented as a series of [6] http://www.sei.cmu.edu/productlinesEclipse plug-ins. They will be end-userprogrammable so that they afford extensive [7] http//www.softwareproductines.comcustomization and guidance by the software [8] Huang, S. "UMLIO: Development of anengineer. For example, the granularity of the Assessment Instrument to Evaluate thematching between design artifacts will be tunable, Fidelity of UML Diagram Tools in Support offrom very rough matches based solely on graph Design Reuse." Research project, Floridaconnectivity, to more exact matches that Atlantic University, June 2006.incorporate characteristics of the UML diagrams(e.g., relationships types, methods, naming [9] Jaaksi, A. "Developing Mobile Browsers in aconventions). The tools will first be implemented Product Line." IEEE Software, pp. 73-80.to support UML use case and class diagrams. July/August, 2002.

[10] Muller, H. A; Orgun, M. A; and Tilley, S.: "A5. SUMMARY Reverse-Engineering Approach to

Subsystem Structure Identification." JournalModel driven engineering (MDE) is a style of of Software Maintenance: Research andsoftware development where the primary software Practice, 5:181-204, 1993.artifacts are models from which code and other [11] Ning, J.; Engbets, A.; and Kozaczynski, W.artifacts are generated. One of the primary goals " R C froof One Pass to Production (OPP) project is to Legacy Systems." Proceedoings of theshorten software life cycle. Precise models enable Working Conference on Reverseautomation and productivity. Software Product Engineering, pp. 64-72. IEEE ComputerLine (SPL) approach directly supports MDE by Society Press, 1993identifying the core assets among family products,rather than focusing a single product, so the [12] Tilley, S.; Murphy, S.; and Huang, S. "5thproduction of new products are a matter of days International Workshop on Graphicalor weeks. LCMV takes the first step of identifying Documentation: Determining the Barriers todesign commonality and variability to support Adoption of UML Diagrams" (GDOC 5: Sept.multiple target platforms, with the final goal to 21, 2005; Coventry, UK). Held in conjunctionmigrating towards a model-driven engineering with The 23rd International Conference onapproach for effective enterprise software Design of Communication (SIGDOC 2005:development. Sept. 21-23, 2005; Coventry, UK).

[13] Wiggerts T. "Using Clustering Algorithms inREFERENCES Legacy Systems Remodularization," pp 33-

43. In Proceedings of the IEEE 4th Working[1] Anquetil N. and Lethbridge T. "Experiments Conference on Reverse Engineering

with Clustering as a Software (WCRE'97). IEEE Computer Society Press.Remodularization Method," 235-255. In October 1997.Proceedings of the IEEE 6th WorkingConference on Reverse Engineering [14] Alan Brown: "An Introduction to Model Driven(WCRE'99). IEEE Computer Society Press. Architecture", (ht:/w -October 1999.12.bmcm/e&prrk/tinWrr/

4