ARMMS - Architecture Reference Model for Multilingual Software

ARMMS - Architecture Reference Model for Multilingual Software V. Prasanna Venkatesan, S. Kuppuswami ARMMS - Architecture Reference Model for Multilingual Software V. Prasanna Venkatesan *1, S. Kuppuswami *2 *1, Corresponding author Research Scholar, Department of Computer Science, Ramanujan School of Mathematics and Computer Science, R. V. Nagar, Kalapet, Pondicherry University, Pondicherry 605 014 *2 Director of Studies, Educational Innovations & Rural Reconstruction Pondicherry University, R. V. Nagar, Kalapet, Pondicherry 605 014 prasanna_v@yahoo.com, skswami@yahoo.com Abstract Multilingual software development is put in limelight due to the globalization efforts of the organization. But these development approaches do not have any reference model or framework from the language perspective. This situation limits multilingual software development. In order to address this, we developed architectural reference model for multilingual software (ARMMS) using unit operation. This model ensures the qualities like maintainability, understandability, reusability, adaptability and language neutrality. Also, we present views of ARMMS. Furthermore, a discussion is made on relating unit operation and above said non-functional qualities of multilingual software. Keywords Reference model, Multilingual Software, Multilingual Software Development 1. Introduction Multilingualism got its significance in software due to globalization [6][7]. In the present scenario, each human has to know more than one language for their official life and/or social life. Therefore, the gadgets designed have to exhibit multilingualism [1][12]. Human s key gadget, i.e. computer, also has to meet this requirement. In order to make computer multilingual, appropriate software has to be designed. Multilingual software is the one which exhibits multilingualism in one or more aspects like IO, UI, storage, process etc.[1][2][3][4]. The development of multilingual software is driven by its stakeholders namely software engineers, computational linguists, language engineers and end users. The stakeholders requirements have been captured and realized in multilingual software. The multilingual software development efforts were made in software industries [3][5], academic institution [2] and research and development organization[4]. In the software development process, in general, application domain expertise should be captured in order to document the key domain information in the form of a domain model and the model should capture the different views of the products from the perspectives of relevant stakeholders [8]. Once the model is formed then it can be used as the vehicle for analysis and reasoning. Unfortunately, there is no reference model for multilingual software and also the multilingual software lacks in the non-functional qualities demanded by the stakeholders. This has made the multilingual software development more difficult. In order to overcome the difficulties in developing multilingual software we have proposed an architectural reference model for multilingual software (ARMMS) by studying the existing multilingual software using unit operations. The layers of ARMMS are explained and the views of ARMMS are presented. A discussion on the qualities of the proposed model is also presented, which provides a basis for the future direction of multilingual software development process. Initially, section 2 of this paper is briefs about the recent developments of multilingual software. Section 3 dedicated for a brief survey on reference models and unit operations. Construction of ARMMS by applying unit operations and layers of ARMMS are presented in section 4. Section 5 presents the views of ARMMS. A discussion about the qualities of the model is depicted in section 6. Section 7 summarizes the paper. 74

Journal of Convergence Information Technology Vol. 3 No. 2, June 2008 2. Multilingual Software A Brief Study Lots of research and commercial initiatives of developing multilingual software are going on. These initiatives are briefed below in order to gain a better understanding about the multilingual software development. According to Multilingualization group (m17n) [4], multilingualization in most software is peripheral, that is, multilingual facilities can be isolated from other (main) parts of the software. At the same time, most software has common requirement for their multilingual interfaces. A general library is being proposed that fulfils those requirements to make software development more efficient and inexpensive. Domain level language requirements have a lot of significance in multilingual software development as seen in [6][7]. In [7], we can find a framework for analyzing the multinational corporation (MNC) as a multilingual community in which parent functional language and subunit functional languages are concurrently used and recursively linked through an intra-corporate communication network. These efforts inherently have some model but they are not explicitly revealed. Obviously we need an effort in this direction to extract the models of the existing multilingual software. Consequently these models help us in simplifying the multilingual software development process. 3. A Survey on Reference Model and Unit Operations It is clearly evident that software model is essential for better understanding, analyzing and designing software by the stakeholders of the software. Models enable the designers for making better planning and design which is vital in making the software. One can acquire more fine points about the software model in [9][10][11]. A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem [9]. If the foundations of domain are firm and unlikely change radically, the model can be static. Otherwise, models will be changed and evolved. According to David L. Parnas [10], a model is a simplified or reduced size version of a product. Models have some, but not all, of the properties of the real product and are used because they are easier to study than the actual product. The relation of the model to the product i.e., which properties of the model are also properties of the product must be clearly stated. The views of stakeholders are addressed in [11] as, it is essential to have the repository of the organization s domain expertise to document the key domain information in the form of a domain model. But these models have to be represented formally in order to understand and analyze them better. According to Mary Shaw and David Garlan [8] which highlights the values of software design formalism, as it is generally agreed that formal models and techniques, are corner-stones of a mature engineering disciplines. Formalisms can be used to provide precise, abstract models and to provide analytical techniques based on these models. They are also useful for simulating behavior. 3.1 Reference Model Reference model is a notion used in standard conceptual computing models. It is an abstract representation of the entities and relationships involved in a problem space, and form the conceptual basis for the development of more concrete models of the space, and ultimately implementations, in a computing context. It thereby serves as an abstract template for the development of more specific models in a given domain, and allows for comparison between complying models. Instances of reference models include, among others: the Open Systems Interconnection Basic Reference Model, the Open Geospatial Consortium reference models, the Von Neumann architecture as a sequential computing referential model, and the Federal Enterprise Architecture reference models [16]. A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations [15]. 3.2 Unit Operations In order to achieve a model, a set of design operations are commonly used in software architectures. These design operations are called as unit operations, following the long-time practice in chemical engineering. These software operations are compression, abstraction, resource sharing, uniform decomposition, and replication [9][13][14]. Unit operations are different from architectural styles and 75

ARMMS - Architecture Reference Model for Multilingual Software V. Prasanna Venkatesan, S. Kuppuswami design patterns in that they are more primitive. Design patterns and styles use, or are derived from, the engineering principles reflected by unit operations. As a consequence, unit operations are more abstract than design patterns, farther from implementation [9]. Architecture Reference Model for Multilingual Software (ARMMS) is formed using unit operations and it is explained in the next section. 4. Construction of ARMMS by applying Unit Operations and Layers of ARMMS The layers of the ARMMS are constructed by applying unit operations like separation, uniform decomposition and abstraction and it is shown in the figure 1. Language independent domain layer, language neutral domain layer and language dependant domain layer are constructed using separation. Multi-language neutral domain layer is constructed using the compostion of multilingual library layer. An aggregation of language library layer forms the multilingual library layer. An abstraction of language library layer is created to separate the interfaces and implementations. Uniform decompostion opeation is used to separate language aspects layer from the language library layer. The details about the layers of ARMMS is presented below. Language Independent Domain Layer This layer separates the domain software components from the language issues. It helps the designers to concentrate on the domain functionalities. Components in this layer are highly reusable in similar domain applications with different language constraints. In brief, the designer can design the application focusing the domain aspects using language neutral components. Language aspects are bound dynamically by the language neutral components. Language Neutral Domain Layer It is comprised of multilingual component library and abstract language component library. This layer detaches language issues from the upper layer and also achieves loose coupling between Language Independent Domain Layer and Language Dependent Domain Layer. It is comprised of three sub layers, namely Multi Language Neutral Domain Layer Multi Lingual Library Layer Abstract Language Library Layer Language Independent Domain Layer Language Neutral Domain Layer Multi-Language Neutral Domain Layer Multilingual Library Layer Abstract Language Library Layer Language Dependent Domain Layer Concrete Language Library Layer Language Aspects Layer Figure 1. Layers of ARMMS 76

Journal of Convergence Information Technology Vol. 3 No. 2, June 2008 Multilanguage Neutral Domain Layer This layer is comprised of domain components with multilingual characteristics in a generic form. So, specific language dependencies of the Multilingual Domain components are avoided. Hence, it enables to design language adaptable software which supports effective language management. Multilingual Library Layer This layer is comprised of multilingual component library. The multilingual components provide the mechanism for language co-existence and dynamic language switching. Importantly, these multilingual components are independent of a specific language. This layer helps in achieving language neutrality quality. This feature is achieved with the help of effective writable operations in multilingual components along with parameterized interfaces. Abstract Language Library Layer This is dedicated to aggregate the language library in multilingual library in an abstract fashion. It detaches the language specific implementation from the multilingual library components. It also helps in language maintainability qualities in the multilingual software. Language Dependent Domain Layer This layer is designed to take care of language implementations. Language components are created by the dynamic composition of language aspects. This layer is the foundation layer for any multilingual software with qualities like reusability, maintainability, understandability, adaptability and language neutrality. It comprises two sub layers and they are Concrete Language Library Layer Language Aspect Layer Concrete Language Library Layer Language specific characteristics are designed in the form of language components. Collection of language components forms language library. This layer takes care of realization of language in the software. Hence the language components are designed by the composition of language aspects. Language Aspect Layer Language aspects are separated from language components and built as separate components. This increases reusability and maintainability of language aspects and language components. Language aspects are categorized as Linguistic-level language aspects Implementation-level language aspects Domain-level language aspects Linguistic-level Language Aspects Any language has its own character set in script form and phonetic form, syntax rules and semantic rules. The character set and rules may differ between communities. Moreover modernization of language will alter the grammar rules and sometimes the character set too. Government also alters the character set and grammar rules in order to satisfy the society. These entities are called as linguistic-level language aspects. This revolves in realizing the languages in computer with the various aspects like character set, syntax rules, semantic rules, etc. Implementation-level Language Aspects When we implement a language, we have to address various implementation-level language aspects. These aspects are Coding Schemes KB Layout Display standards Output standards, etc., We can see many efforts are started to standardize these aspects. Until the universal standards are established, this aspect will be supported by different implementations and it introduces the complexity in the design process. Domain-Level Language Aspects Each business domain has its own requirements and demands. Also, today the software systems are aimed at user-centric than process-centric. On the other hand internet-enabled and pervasiveness of the software introduces much more demands in multilingualism. Domain-level language aspects are also a part of the demands to be addressed. The domain-level language aspects are I/O voice input/output, Process-parsing, Domain based indexing etc., 5. Views of ARMMS The search for commonalities and principles lead to see that software architecture has four distinct views: conceptual, module, execution, and code. Although there is not yet a general agreement about which views are the most useful, the reason behind multiple views is same i.e.; separating different aspects into separate views helps people manage complexity [33]. In order to represent architectural 77

ARMMS - Architecture Reference Model for Multilingual Software V. Prasanna Venkatesan, S. Kuppuswami views of ARMMS, conceptual view and module view are chosen. Code view and execution view will be used when the architecture is derived using ARMMS. Conceptual View of ARMMS The conceptual view describes the system in terms of its major design elements and the relationships among them. Some of today s advanced systems were designed with an explicit conceptual view. This view is usually tied closely to the application domain. Some models of conceptual views use communicating objects as the basic design element. Others are used to show the components, connectors and the assemblies of components. The conceptual view of ARMMS has four modules and they are input module, process module and output module and it is presented in figure 2. Input module takes care of multilingual input requirements. Multilingual component which takes care of multilingual output are grouped under the output module. Process module comprises the components which are responsible for language computations like Translation, Transliteration, Spell check etc. Even though these modules are formed on the functionalities of multilingual components, they are conceptually designed using the conceptual model. Module View of ARMMS When the systems increased in size and in number of programmers, techniques arose for handling complexity due to size, and for partitioning work among programmers. Abstraction, encapsulation, and the notion of an interface became well-known concepts. Specific techniques for supporting them were designed, such as Ada packages and module inter-connection languages. The decomposition of the system and the partitioning of modules into layers is the main purpose of the module view. Module view of this reference model is presented shown in figure 3. It shows how to logically modularize the multilingual concerns of the software. Each layer is represented with the help of components and required relationships like aggregation, composition and inheritance are also used. Figure 2. Conceptual View of ARMMS 78

Journal of Convergence Information Technology Vol. 3 No. 2, June 2008 Figure 3. Module View of ARMMS 6. Discussion Stakeholders drive the software development by feeding their requirements. Based on the requirements, the architect will develop the model. Models are helpful in presenting the software development at the earlier stage of software development in more abstract form. On the other hand, models enable the architect to derive the software architecture. Obviously, the multilingual software models proposed in this paper are useful to the stakeholders in various ways. Here we provide the impacts of the models from the perspective of the stakeholders, namely architect, developer and end user. Architect plays the key role in the software development process. Multilingual software models can be used as communication vehicle by the architect to the stakeholders in order to present an overview about the project. On the other hand, they aid the architect to carry out the software design with ease. Also architect can get different architecture alternatives on combining the multilingual software models with different architecture styles. Moreover, multilingual software models give a prior knowledge about the software that help the architect in planning the required human resources like computational linguists, language engineers, etc., at the appropriate stages of software development. Developers also get benefit from this model. They have to understand the architect s views for proceeding further with the detailed design and development of software. Multilingual software model gives clarity to the developers in order to progress with their work at various stages like inception, design, development, testing and deployment. It further guides them in mining and applying the design patterns and creating the reusable libraries. This simplifies the developers work. In brief, these models offer non functional qualities like maintainability, understandability, reusability, adaptability and language neutrality which are the primary concerns and how they can 79

ARMMS - Architecture Reference Model for Multilingual Software V. Prasanna Venkatesan, S. Kuppuswami achieved are briefed below from the language perspective. Modifiability The following are the agenda to be met to achieve this quality from the language perspective Existing language Components addition Components modification Components deletion Deletion of existing language and its components Addition of new language and language components Understandability The following are the list of items to be assembled to attain this quality from the language concern Language components are clearly captured, designed and developed to meet the requirements of stakeholders and help them to identify their Requirements Roles Responsibilities Reusability The following are the schema to be met to realize this quality from the language concern Separating the language aspects Possible level of language abstraction Encouraging and ensuring this quality in all stages of software development Adaptability The following are the list of items to be met to achieve this quality from the language concern Software have to work in the language of user s choice which is made directly or indirectly Language switching in software should be supported at run time Language Neutrality Abstracting the language from the domain and at the run-time the instance of the language is composited with the domain modules. It will enable the language independent application development at domain level. At the same time the application will be made to work in multilingual. We are concerned in understanding the effect and interactions of unit operations with respect to maintainability, understandability, reusability, adaptability and language neutrality. Based on [9], we can summarize the gross relationships among three unit operations and the five distinct qualities as shown in table 1. A + in the table indicates a positive relationship between an operation and a quality attribute: that is, the use of this operation aids in the achievement of the quality goal. A blank cell indicates that, depending on the context of use, the operation might have a positive or negative effect. For example, partwhole decomposition aids in maintainability if and only if the language aspects that change from component to component have been isolated into a single part. Otherwise, the decomposition actually hinders maintainability, because the changes to be made are nonlocal; they are spread out among the language components. Both qualities and unit operations are abstract and only guide us in our choices among design alternatives. The rationale behind the rankings provides valuable insights into when and how to use a particular operation. 7. Summary Like any other domain, multilingual software also need reference model which will be helpful in design process. This paper mainly focuses in proposing architectural reference model for multilingual software (ARMMS). Also, we put an effort to present the details of layers of ARMMS and the views of ARMMS with implementation independent representation. Table 1. Relationships between Unit Operations and Non-functional qualities Operation Abstraction Part-whole decomposition is-a decomposition Maintainability + + + Understandability + + + Reusability + + Adaptability + + + Language Neutrality + + 80

Journal of Convergence Information Technology Vol. 3 No. 2, June 2008 Also a discussion is made to present the impact of these models from perspectives of the stakeholders and we have analyzed these models with language aspects and software qualities which are demanded by the stakeholders. We are in process of applying ARMMS to a multilingual software development to study the impact of ARMMS. [15]http://www.oasis-open.org/ committees/soa-rm/faq.php [16] http://en.wikipedia.org/wiki/reference_model 8. References [1] Multilingual terminal: a universal approach, J.Dougnac, Télécom Review, Paris, France, Dec 1995 [2] http://acharya.iitm.ac.in/acharya.html [3] International Programming for Microsoft Windows, David. A. Schmitt, WP Publishers, 2001 [4] http://www.m17n.org/m17n-lib-en/ overview.html [5]http://www.mithi.com/products/indiainteractive/ whybuy/overview/platform.html [6] http://www.fraber-consulting.com/ index.html [7] The multinational corporation as a multilingual community: Language and organization in a global context, Yadong Luo, Oded Shenkar, Journal of International Business Studies, Vol 37, 2006 [8] Software Architecture: Perspectives on an engineering discipline, Mary Shaw and David Garlan, Prentice-Hall of India private limited, 2000 [9] Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, Pearson Education, Third Indian Reprint, 2002 [10] Software Fundamentals: Collected papers by David L. Parnas edited by Daniel M. Hoffman and David M.Weiss, Pearson Education, 2001 [11] Software Product Lines: Practices and Patterns, Paul Clements and Linda Northrop, Addison Wesley, 2002 [12] Multilingual Technology and Tools for IT Developments in India, S. Kuppuswami, T.Chitralekha, and V. Prasanna Venkatesan, Technorama, India, October 2003 [13] Measuring the Performance and Intelligence of Systems: Proceedings of the 2002, Edited by: E.R. Messina and A.M. Meystel, PerMIS Workshop, 2002 [14] Toward a Software Engineering Model of Human- Computer Interaction, R. Kazman, L. Bass, R. Little, Engineering for Human-Computer Interaction, Proceedings of the IFIP WG2.7 Working Conference, North Holland, August 1993, 131-153. 81