Despite a common agreement on the necessity of the application of the separation of concerns (SOC) principle, there is not yet a consensus for its key issues. The separation of the concerns is usually based on the adopted programming paradigm, the applied method or even the programming language. This paper presents the so-called six ‘C’ properties that can be applied as a guideline for defining and evaluating the approaches that adopt the SOC principle

Aksit, Mehmet

Bergmans, Lodewijk

Tekinerdogan, Bedir

English

Tekinerdogan, B.

NARCIS 

The Six concerns for Separation of Concerns

University of Twente Research Information

1The Six Concerns for Separation of ConcernsMehmet AkşitBedir TekinerdoğanLodewijk BergmansSoftware Engineering, Dept. of Computer Science, University of Twente,P.O. Box 217, 7500 AE, Enschede, The Netherlands{aksit|bedir|bergmans}@cs.utwente.nlAbstractDespite a common agreement on the necessity of theapplication of the separation of concerns (SOC) principle,there is not yet a consensus for its key issues. Theseparation of the concerns is usually based on theadopted programming paradigm, the applied method oreven the programming language. This paper presents theso-called six ‘C’ properties that can be applied as aguideline for defining and evaluating the approaches thatadopt the SOC principle.1. IntroductionOne of the most important principles in softwareengineering is the separation of concerns (SOC) principle.This principle states that a given problem involvesdifferent kinds of concerns, which should be identifiedand separated to cope with complexity, and to achieve therequired engineering quality factors such as robustness,adaptability and reusability.Despite a common agreement on the necessity of theapplication of the SOC principle, there is not a well-established understanding of the notion of concern. Theseparation of the relevant concerns is usually based on theadopted programming paradigm, the applied method oreven the programming language. In object-orientedmethods, for example, the separated concerns aremodeled as objects and classes, which are generallyderived from the entities in the requirement specificationand use cases. In structural methods, concerns arerepresented as procedures. In aspect-orientedprogramming, the term concern is extended with the so-called crosscutting properties such as synchronization,memory management and monitoring.We think that there is a need of renewed understanding ofthe requirements for the SOC principle. For this purpose,this paper presents the so-called six ‘C’ properties:Concern-oriented, Canonicality, Composability,Computability, Closure property and Certifiability. In thefollowing sub-sections, by using an example we willexplain these in more detail.2. The Six C Properties2.1 Concern-OrientedIn natural language the word concern usually means 'thematter for consideration', or 'marked interest or regard'[7]. The concern-oriented property ensures that thesoftware system is relevant and as such is valid for thecontext as defined by the problem. However, identifyingthe relevant concerns is not trivial. To support this, wedistinguish basically between the following two concerntypes:•  Problem domain concerns, represent the concerns asit is defined from the client perspective. It basicallyfocuses on the functionality of the system as theclient expects it.•  Solution domain concerns, represent the concerns asdefined by the solution techniques.Assume for example that a software system has to bedesigned and implemented for a group of car dealersconnected together through a network. This system mustprovide services such as repair and maintenance,registration, tax management and insurance. Further, thesystem must minimize the material and labors costs, andoptimize the speed performance. To reduce the number ofspare parts, the dealers share some of the componentsstored in their stocks. For example, expensive car modelsmay only be kept by a selected number of dealers.Further, the components that are not frequently requiredmay be shared among the dealers that are not far fromeach other. To minimize the costs, the software system2can keep track of these shared car models and sparecomponents.The above requirements include the problem domainconcerns, which can also be represented in more detail byuse-cases and scenarios.The problem domain concerns, however, may not includethe necessary concerns for implementing the softwaresystem. This is because, many important concerns may betransparent to the user.We claim that the relevant concerns must be derived fromthe solution domain [1]. For example, sharingcomponents across a network requires mechanisms formanaging consistency. The theory of atomic transactions,for example, can be adopted to solve this technicalproblem. Further, mathematical techniques may be usedto optimally distribute the components across the stocks.This requires knowledge on optimization techniques. Inaddition, to tune the system performance, the transactionsystem may be monitored and controlled. This requiresknowledge on control systems. All these solution domainsare necessary for implementing a robust and fastdistributed stock management although they are notexplicitly included in the requirement specification.The utilization of the solution domain concerns does notexclude the problem domain concerns, however. Theproblem domain concerns are particularly useful inidentifying the solution domain concerns and fordesigning user-interfaces.2.2 CanonicalThe canonical form property requires that the concernsare general and represented as succinct as possible. Thegenerality property refers to the common and stable partsof the software system. The succinct property avoidsredundancy and as such unnecessary complexity. Theseproperties are important in designing robust, adaptableand reusable software systems.Canonical models can be identified by comparing themultiple relevant solutions for the same problem. Forexample, after comparing a large number of transactiontechniques, we have identified the following set ofcommon concerns: Transaction, Transaction Manager,Policy Manager, Data Manager, Scheduler and RecoveryManager [6]. Similarly, the scheduler concern could bedecomposed further into the following common sub-concerns: Synchronization Scheme, SynchronizationStrategy and Performance Detector.Numerous synchronization schemes exist of which eachperforms differently depending on the execution context.To tune the performance of the transaction system withrespect to the changing context, it is necessary to specifythe stable and the variable parts so that thesynchronization scheme can be adapted. This inherentlyrequires the canonicality property.2.3 ComposableTo define higher-level concerns requires compositionoperators for manipulating, combining and extending theconcerns.Assume that the concern C3 is composed from C1 and C2using the composition operator ⊕ :C3 = C1 ⊕  C2.The composition operator may be applied at differentbinding times such as compile-time or run-time. In object-oriented languages, for example, inheritance andaggregation are provided as compile-time and run-timemechanisms, respectively. The operator ⊕  may alsorepresent a more complex composition mechanism suchas middleware.Sometimes, the composition cannot be realized if theadopted language (1) cannot represent the necessaryconcerns separately and/or (2) cannot provide theappropriate composition operators.Some concerns may be naturally non-separable, which aretermed as crosscutting concerns. Hereby crosscuttingrefers to inevitable scattering of concerns to multipleabstractions.For example, in the car dealer management system, totune the performance of the transaction system, varioussoftware modules need to be monitored. This requiresrepetitive implementation of the monitoring code in thecorresponding operation. The monitoring code is said tocrosscut the transaction system because it is scatteredacross many operations in different modules. Because ofthe tangled code, crosscutting hinders the adaptation andextension of the monitoring concern.Aspect-oriented programming languages [4][2] aim atproviding implementation mechanisms for composing thecrosscutting concerns.2.4 ComputableThe fourth issue is to express the concerns in a commoncomputable platform. The computability property isnecessary for creating executable software systems. Forthis the concerns must be expressed as first classabstractions in the implementation language so that theycan be manipulated individually. This means that giventhe set of solution abstractions as defined by SA = (sa1,sa2, sa3, .. ,san), we can define an implementation modelIA in a language such that:IA = (ia1, ia2, ia3, .. ,ian)3where there is a bijective mapping from SA to IA. This isto say that every abstraction in SA, can be separatelyrepresented by an abstraction in IA. Implementationabstractions may correspond to the abstractions providedby the implementation environment such as Java languageconstructs, CORBA IDL, operating systems API's, etc.In theory, for every individual technical problem, an idealimplementation language can be defined. In practice,however, there is a large set of technical problems thatrequire different implementation languages. Given therestricted resources, however, this is not a viable optionand usually a general-purpose language is used instead.This may cause certain concerns crosscut in theimplementation. For example, in current object-orientedlanguages, synchronization and real-time constraintspecifications cannot be represented and composed asseparate concerns [5]. This may hinder the adaptabilityand reusability of these concerns in the implementation.2.5 ClosureThe fifth issue is to preserve the canonical structure andthe composition operations of the design in theimplementation platform. This is called the closureproperty, and is necessary for maintaining the qualityfactors of the design at the implementation level. Theclosure property can be expressed using the followingfunction:⊕  : C × C → C.Here, the composition operator ⊕  is a function that mapsthe product of two concerns into a new concern.In the transaction system design example, the Schedulerand RecoveryManager concerns are expressed separately.The DataManager concern composes these concernstogether. Because of the closure property, scheduling andrecovery mechanisms can be replaced freely at run-time.2.6 CertifiabilityThe sixth issue is to certify the implementation of theconcerns with respect to functional and/or qualityrequirements. The certifiability property is necessary forevaluating and controlling the quality of design andimplementation models.In the transaction design example, certifiability can beprovided by using the semantics of solution domainabstractions. For example, the correct adaptation of theconcern Scheduler has been specified in the solutiondomain. This information can be utilized in verifying thecorrectness of the adaptation of Scheduler [6].Furthermore, simulation techniques can be used to justifythe tuning of the performance.3. ConclusionsIn this paper, we have identified six fundamental keyissues of the separation of concerns principle, that wetermed as the six ‘C’-properties: Concern-Oriented.Canonical, Composable, Computable, Closure,Certifiable.References[1] G. Arrango. Domain Analysis Methods. In SoftwareReusability, Schäfer, R. Prieto-Díaz, and M. Matsumoto(Eds.), Ellis Horwood, New York, New York, pp. 17-49,1994.[2]  [Bergmans & Akşit 96] L. Bergmans and M. Aksit,Composing Synchronisation and Real-Time Constraints,Journal of Parallel and Distributed Computing 36,  pp. 32-52, 1996.[3] [Bernstein et al. 87] P.A. Bernstein, V. Hadzilacos & N.Goodman, N. Concurrency Control & Recovery inDatabase Systems, Addison Wesley, 1987.[4] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C.Lopes, J.-M. Loingtier, J. Irwin, Aspect-OrientedProgramming. In proceedings of ECOOP '97, Springer-Verlag LNCS 1241.  June 1997.[5] S. Matsuoka & A. Yonezawa, Inheritance Anomaly inObject-Oriented Concurrent Programming Languages, inResearch Directions in Concurrent Object-OrientedProgramming, (eds.) G. Agha, P. Wegner & A. Yonezawa,MIT Press, pp. 107-150, 1993.[6] B.Tekinerdoğan. Synthesis-Based Software ArchitectureDesign, PhD Thesis, Dept. of Computer Science,University of Twente, The Netherlands, 2000.[7] On Line Webster’s Dictionary, 2000

The Six concerns for Separation of Concerns

Abstract

Similar works

Full text

Available Versions

NARCIS

University of Twente Research Information