VIII-33 ISSN 2085-1944 1
Bachelor Informatics, Faculty of Information Technology, Maranatha Christian University Jl. Prof. Drg. Suria Sumantri 65 Bandung, INDONESIA
2
Department of Computer Science and Electronics, Gadjah Mada University Jl. Sekip Utara, Sleman, Yogyakarta, INDONESIA
email: 1awreman@gmail.com, 2{rw,jazi,khabib}@ugm.ac.id
ABSTRACT
Open Source Software (OSS) Projects currently become the trend in Computer Science / Information Technology. The previously assumed to be a chaotic and 'bazaar' style of software development has proven itself to be able to produce some of high quality software applications such as Linux Operating System, Openoffice.org productivity suite, Apache web server, and many more. These successes have triggered many studies to determine OSS Project success factors, and one of the identified key success factor is the modularity of the OSS applications. The modularity of software system itself also receives many interests from researchers. In this paper, five modularity techniques are analyzed against the ideal attributes of modular software in order to find the suitable modularity technique for OSS Project. The result shows that there are two modularity techniques suitable for this project.
Keywords: Open Source Software, modularity
technique, Object-Oriented Design Pattern, Feature-Oriented Programming
1
INTRODUCTION
Open Source Software (OSS) Projects currently become the trend in Computer Science / Information Technology. The previously assumed to be a chaotic and 'bazaar' style of software development has proven itself to be able to produce some of high quality software applications comparable to the proprietary / commercial software i.e. Linux Operating System, Openoffice.org productivity suite, Apache web server, and many more. These 'methodology' , which is seemingly the violation of the already established Software Engineering discipline, has triggered many studies to determine the project's success factors, and one of the identified success factors is the fact that most of successful OSS Projects are modular [8][10].
The modularity in software system itself also receives many interests from researchers. Modularity of software system could be achieved by some techniques such as Object-Oriented Design Pattern (OODP), Aspect-Oriented Programming (OAP), Feature-Oriented Programming (FOP), Service-oriented Architecture (SOA) and Rule-Based Programming (RBP). We believe that not all of these techniques are suitable for OSS Projects. This paper presents the analysis of the suitable techniques in achieving modularity for OSS Project by considering the characteristics of OSS Projects and the ideal properties of modular software system. The method used in this research is by defining the characteristics of ideal modular software system and then comparing the features in five techniques in achieving modularity to find the best approach for OSS Projects.
2
MODEL, ANALYSIS, DESIGN,
AND IMPLEMENTATION
2.1
Open Source Software Project
OSS Project is a software development methodology based on several distinct characteristics:
· The source code of the application is freely available for everybody to download, improve and modify [18].
· People who contribute to the development of the project is forming a group called Open Source Software Community which is voluntary [7].
· The primary concern of the developers in OSS Projects are building features and fixing bugs [10].
ISSN 2085-1944 If the project receives enough attention from other
developers, it will evolve into more complex project in which the growth of the source code is in super-linear rate [3]. In this evolution phase, the active role of project administrator is important to reduce the increasing complexity by performing anti-regressive work [5]. The OSS Project is then reaching its stable point which is indicated by the growth of the source code to about 10% in each release. At the end, the project will reach a phase out phase if there is no developer interested to contribute to the project.
The structure of the OSS Communities themselves are also evolve in parallel with the evolution of the software system. From the initial phase with only a single developer, the project will become small to medium project (< 100 developers) in which the actual roles in the project are only two roles [21]. When reaching stable point phase, the structure of the OSS Communities are in onion layer [16] with 7 or 8 distinct positions [16][7]. The most critical stage of the co-evolution of the OSS system and OSS Communities are during the evolution from initial phase into evolution phase in which new developers should be acquired to participate in developing the software system.
2.2
Software Modularity
Modularization involves breaking up of an software system into smaller, more independent elements known as module. Booch has defined modularity as the property of a system whose modules are cohesive and loosely-coupled [13]. Fenton stated that Modularity is the internal quality attribute of the software system [13]. It is also known that modularity is directly related to software architecture, since modularity is separation of a software system in independent and collaborative modules that can be organized in a software architecture [15]. Modular software has several advantages such as maintainability, manageability, and comprehensibility [14].
There are four attributes closely related to modularity in software system which are coupling / dependency, complexity, cohesion, and information hiding. The first attribute is coupling / dependency which consist of direct / syntactic which can be achieved through composition, method signatures, class instantiations, and inheritance[6]; and semantic or indirect coupling[12]. The second attribute is complexity that can be measured by using software metrics such as McCabe's Cyclomatic Complexity, Halstead's Software
Metrics, Function Points, or Physical Size such as LOC or SLOC [20]. The third attribute is cohesion which measure the integrity of the code inside each of the module. The term used to qualitatively measure cohesion are high cohesion or low cohesion. The last attribute is information hiding [6] which involves hiding the details of implementation from external modules.
The first approach is to define the qualitative measure of modularity. These attributes is then used as the benchmark against the available techniques to achieve modularity. The techniques that are suitable for OSS Projects are the preferred techniques. To have an ideal modular software system, the system should have the following attributes:
· Low coupling / dependency [4]: minimization or standardization of coupling / dependency e.g. through standard format i.e. published APIs [1], elimination of semantic dependencies, etc.
· Low complexity: hierarchy of modules that prefers flatter than taller dependency [13][1]. · High cohesion: high integrity of the internal
structure of software modules which is usually stated as either high cohesion or low cohesion. · Open for extension[4]: capability of the
existing module to be extended to create a more complex module.
· Close to modification [4]: avoid changing already debugged code. The creation of new modules should be encourage using available extension and not modifying the already tested module.
There are currently several techniques to achieve modularity in software system. These techniques are [4]:
· Object-Oriented Design Patterns (OODP): using combinations of several software design patterns. Software design pattern is first introduced by Gang of Four [9].
· Aspect-Oriented Programming (AOP): Separation of cross-cutting concerns called aspect from the already functional data and function logic. . This techniques is first proposed by Kiczales, et. al [11].
· Feature-Oriented Programming (FOP): programming techniques by creating many basic features. The more complex features or functions are created by combining these basic features in a stacked-layered format [17]. · Service-Oriented Architecture (SOA) [4]:
ISSN 2085-1944 that interact with each other via standardized
message exchange format such as XML. · Rule-Based Programming (RBP) [19]:
programming techniques based on strategies. These strategies are created from many rules or constrained. The modification of system's behavior is through the modification of rules and strategies.
The strategies of these techniques to achieve the five main attributes of modularity (low coupling, low complexity, and high cohesion, open for extension, close to modification) are studied and analyzed to find which techniques are suitable for OSS Project.
2.3
Strategies in Each Modularity
Techniques
These five preferred attributes of modularity are then analyzed against these five techniques to achieve modularity. Each of these techniques have different strategies in addressing the attributes of modularity.
Modularity Strategy in OODP
The modularity strategy OODP is shown in table 1.
Table 1. Modularity Strategy for Object-Oriented Design Pattern
Attributes OODP Strategy
Low Coupling
Separation of implementation and data by using Observer Design Pattern to reduce tight coupling among modules.
Low Complexity
Reducing the complexity by applying Strategy, Composite and Decorator Design Pattern, so that complex functionality is aggregated from collections of simple functionalities of lower level modules / classes.
High Cohesion
Creation of new classes or modules by using Abstract Factory, Factory Method, or Prototype design patterns. The simplicity of the simple function will result in high cohesion.
Open for Extension
Reduction of interface in module interconnection by using Façade or Proxy Design Pattern.
Close to Modification
Using Decorator and Composite Design Patterns in making complex function as collections of simple functions.
Table 1 shows that in OODP, the main feature is the combination of software design
patterns to achieve the desired modular software system.
Modularity Strategy in AOP
The modularity strategy in AOP is shown in table 2.
Table 2. Modularity Strategy for Aspect-Oriented Programming
Attributes AOP Strategy
Low Coupling
Minimize dependencies by eliminating semantic dependencies.
Low Complexity
Application of three layers implementation: application layer, aspect layer, data layer.
High Cohesion
Separation of the cross-cutting concerns (aspect) from functional data to create cohesive source code.
Open for Extension
Enforcing direct dependencies through published APIs.
Close to Modification
Emphasize on the easy modification of aspect layer without affecting the application and data layer.
Table 2 shows that the separation of cross-cutting concerns called aspects are the main feature in AOP. The ability to easily modify these aspects determine the modularity of the software system.
Modularity Strategy in FOP
The modularity strategy for FOP is shown in table 3.
Table 3. Modularity Strategy for Feature-Oriented Programming
Attributes FOP Strategy
Low Coupling
Standardized format of coupling /dependency among features to allow the combination of basic features into more complex features.
Low Complexity
Hierarchy of features in layered-stacked structure, from minor features up into higher level functions.
High Cohesion
Each minor features is created for a single simple function which to achieve high cohesion.
Open for Extension
Higher level function is the combination of lower level features using standardized format of interconnection.
Close to Modification
Modification of basic feature will only affect the more complex features that using that basic feature.
ISSN 2085-1944 combining two or more of these basic features. The
easy creation of more complex feature from combination of basic features determine the level of modularity in the software system.
Modularity Strategy in RBP
The modularity strategy for RBP is shown in table 4.
Table 4. Modularity Strategy for Rule-Based Programming
Attributes RBP Strategy
Low Coupling
There is no message passing among modules, communication only through shared data
Low Complexity
The structure of the system is centralized to the shared data, resulting in a simple architecture with no hierarchy.
High Cohesion
Each modules are independent to each other since the only communication is to the shared data.
Open for Extension
Addition of rules will change the strategy of the program.
Close to Modification
Modification of rules are allowed in which it will also affect the strategy.
Table 4 shows that the main feature of RBP is the repeated application of rules to the shared data. The easy modification of rules defines that level of modularity of the software system.
Modularity Strategy in SOA
The modularity strategy for SOA is shown in table 5.
Table 5. Modularity Strategy for Service-Oriented Architecture
Attributes Service Oriented Architecture
Low Coupling
Collection of services interact with each other using standardized format of message exchange such as XML. Each service is self-contained and loosely coupled
Low Complexity
There exist a management layer that coordinates all the interconnection of services.
High Cohesion
Each services in SOA is independent to each other.
Open for Extension
A new service can be added as long as it follows the standardized format of message exchange.
Close to Modification
Modification of a service will only affect on its own.
Table 5 shows that the main feature of SOA is the uniformity of message exchange using XML.
The degree of interaction among these services determine the level of modularity of the software system.
3
RESULT
In order to find the suitable modularity techniques for OSS Projects, the current problems of these projects should be identified. The following are some of the problems of OSS Projects as identified by some researchers:
· Lack of formal methodology, especially in managing large and complex project[7]. · Low participation of developers due to high
technical barrier [2].
· Lack of documentation due to the lack of interest in writing documentation [7].
In addressing these problems, three solutions are proposed . These three solutions are then used as the conditions that should be met by modularity techniques in order to be considered suitable to be used in OSS Projects:
· Standardized format of communication: there should be a common format of communication for developers of the project that should be easily understood by interested new participants of the project.
· Lowering the technical barrier: the high technical skill barrier that prevent new participants to contribute to the OSS Project should be lowered.
· Reduction of management task: The management task should be lessen especially for OSS Project administrator.
In achieving standardized mean of communication, every modularity techniques has different approaches. The software design patterns in OODP are the standard terminology that enables developers to communicate in the same language. AOP does not have specific format regarding communication media. The FOP focuses on the standard interfaces among basic features that must be obeyed by developers in order to built more complex functionality. The XML is the standard mean of communication in SOA, while in RBP the standard mean of communication is the shared data.
ISSN 2085-1944 software which creates additional difficulty. The
scope in enterprises level in SOA also makes it difficult for new developer to contribute further. In RBP, the understanding of the overall rules and strategies will not help new programmers.
If the OSS Project is evolving into larger project, the reduction of project administrator work is necessary. In OODP, there are delegation of work in each module for groups of developers so it will reduce administrator's work. The separation of aspects from the functional logic in AOP also reduce administrator's work since the aspect layer will make it easier to accommodate changing requirement. In FOP, the delegation similar to OODP exist by giving the control into the basic feature level. In RBP, the standard formation of rules and strategies will reduce administrator's work.
The summaries of above descriptions are shown in table 6. Check mark means the approach / strategy exist, while the dash means that the approach / strategy does not exist.
Table 6. OSS Project Solution in each Modularity Techniques
Condition OODP AOP FOP SOA RBP
Standard mean of
communication
√ - √ √ √
Lower technical barrier
√ - √ - -
Reduction of management task
√ √ √ √ √
Table 6 shows that OODP and FOP are the more suitable modularity techniques for OSS Project than AOP and RBP. Both techniques address all the ideal conditions for OSS Projects to evolve into more mature project.
4
CONCLUSION AND DISCUSSION
OSS Project is currently the new approach in developing software system. The success of some OSS Projects such as Linux OS, Apache Web Server, etc. has spark many interest to study the success factors of these projects and one of the main key success factor is the fact that these OSS Projects are modular. Modularity of software system itself has been the subject of many studies. Some studies have indicated that the ideal attributes of modular software system are the low coupling, low complexity, high cohesion, open for extension,
and close to modification. The approaches of each modularity strategy to achieve each of these ideal attributes are also discussed. Furthermore, there exist five modularity techniques i.e. Object-Oriented Design Pattern (OODP), Aspect-Object-Oriented Programming (AOP), Feature-Oriented Programming (FOP), Service-Oriented Architecture (SOA), and Rule-Based Programming (RBP).
By realizing the current problems in many OSS Projects and the strategies to overcome these problems, the suitable modularity techniques for OSS Project are analyzed. The strategies to overcome the problems include the standard mean of communication, lower technical barrier, and reduction of management task. It can be concluded that OODP and FOP are the more suitable modularity techniques for OSS Projects than AOP and RBP. The future work of this research includes the possibility in combining both techniques into a Software Framework that easily used by OSS Project's initiator to start his / her project with modularity as his/her early concern.
The authors of this paper would like to thank
Maranatha Christian University
(http://www.maranatha.edu) that provide the funding for this research and Department of Computer Science and Electronics at Gadjah Mada University (http://mkom.ugm.ac.id) which provide guideline and technical assistance for the research.
REFERENCES
[1]. Aruna M., M.P. Suguna Devi M.P, Deepa M. (2008) Measuring the Quality of Software Modularization using Coupling-Based Structural Metrics for an OOS System: Proceeding of the First International Conference on Emerging Trends in Engineering and Technology. 16 - 18 July 2008, pp 1130 – 1135.
[2]. Bird C., Gourley A., Devanbu P., Swaminathan A., Hsu G. (2007) Open Borders? Immigration in Open Source Projects: Fourth IEEE International Workshop on Mining Software Repositories. Minneapolis, Minnesota, 20 – 26 May 2007, pp 6.
ISSN 2085-1944 [4]. Cai Y., Huynh S. (2007) An Evolution Model
for Software Modularity Assessment: Proceeding of the Fifth International Workshop on Software Qualty 2007 (WoSQ'07). Minneapolis, Minnesota, 20 - 26 May 2007, pp 3.
[5]. Capiluppi A., Ramil J.F. (2004) Studying the Evolution of Open Source Systems at Different Levels of Granularity: Two Case Studies: Proceeding of the 7th International Workshop of Principles of Software Evolution. Kyoto, Japan, 6 – 7 September 2004, pp 113 - 118.
[6]. Capra E., Francalanci C., Merlo F. (2008) An Empirical Study on the Relationship among Software Design Quality, Development Effort, and Governance in Open Source Projects: IEEE Transactions on Software Engineering, Vol. 34, No. 6, Nov/Dec 2008, pp 765 - 782. [7]. Christley S., Madey G. (2007) Analysis of
Activity in the Open Source Software Development Community: Proceeding of the 40th IEEE Annual Hawaii International Conference on System Sciences. Big Island, Hawaii, 3 - 6 January 2007, 166b.
[8]. DeKoenigsberg G. (2008) How Successful Open Source Projects Work, and How and Why to Introduce Students to the Open Source World: 21st IEEE Conference on Software Engineering Education and Training. 14 – 17 April 2008, pp 274 – 276.
[9]. Gamma E., Helm R., Johnson R., Vlissides J. (2007) Design Patterns: Elements of Reusable Object-Oriented Software. 36th Edition 2007. Addison Wesley Longman Inc., ISBN: 0-201-63361-2.
[10].Gurbani V.K., Garvert A., Herbsleb J.D (2006) A Case Study of Open Source Tools and Practices in Commercial Setting. Proceeding of the fifth Workshop on Open Source Software Engineering. St Louis, Missouri, 17 May 2006, pp 1 - 6.
[11].Kiczales G., Lamping J., Mendhekar A., Maeda C., Lopes C.V., Loingtier J., Irwin J. (1997) Aspect-Oriented Programming. Proceeding of the European Conference on Object-Oriented Programming. Finland, June 1997. Springer Verlag.
[12].Matos Jr P., Duarte R., Cardim I., Borba P. (2007) Using Design Structure Matrices to Assess Modularity in Aspect-Oriented Software Production Lines. Proceeding on the First International Workshop on Assessment of Contemporary Modularization Techniques 2007 (ACoM'07). Minneapolis Minnesota, 20
– 26 May 2007, pp 6.
[13].Melton H., Tempero E. (2007) Toward Assessing Modularity. Proceeding of the First International Workshop on Assessment of Contemporary Modularization Techniques 2007 (ACoM'07). Minneapolis Minnesota, 20 – 26 May 2007, pp 3.
[14].Munelly J., Fritsch S., Clarke S. (2007) An Aspect-Oriented Approach to the Modularisation of Context. Proceedings of the Fifth Annual IEEE International Conference on Pervasive Computing and Communication (PerCom'07). White Plains, New York, 19 – 23 March 2007. pp 114 – 124.
[15].Nakagawa E.Y, de Sousa E.P.M., de Britto Murata K. (2008) Software Architecture Relevance in Open Source Software Evolution: A Case Study. Annual IEEE International Computer Software and Application Conference. 28 July – 1 August 2008, pp 1234 – 1239.
[16].Nakakoji K., Yamamoto Y., Nishinaka Y., Kishida K., Ye Y. (2002) Evolution Patterns of Open Source Software Systems and Communities. ACM IWPSE 2002. Orlando, Florida 2002, pp 76 – 85.
[17].Prehofer C. (1997) Feature-Oriented Programming: A Fresh Look at Object. Institut für Informatik Technische Universität
München, 1997. Available:
http://reference.kfupm.edu.sa/content/f/e/featu re_oriented_programming__a_fresh_lo_3555. pdf
[18].Raymond E.S (1999) The Cathedral and the Bazaar. Knowledge, Technology & Policy, vol. 12 no. 3 pp. 23 – 49, 1999.
[19].Vora U. (2007) Modularization with Externalization of Control Flow. First International Workshop on Assessment of Contemporary Modularization Techniques 2007 (ACoM'07). Minneapolis, Minnesota, 20 – 26 May 2007, pp 5.
[20].Wang Y., Shao J. (2003) Measurement of the Cognitive Functional Complexity of Software. Proceedings of the Second IEEE International Conference on Cognitive Informatics 2003 (ICCI'03). London, England, 18 – 20 August 2003, pp 67.
