Architecture Patterns for Mobile Games Product Lines Jin-Seok Yang POSTECH Information Research Lab, POSTECH edeward@postech.ac.kr Hojin Cho Dept. of Computer Science and Engineering, POSTECH NUCL23 @postech.ac.kr Abstract - Product line software engineering (PLSE) is a promising method for software reuse. For the key of success, a reusable and adaptable architecture design is necessary. In domain of mobile games product lines, architectures have some common structures because of circumstance properties of the domain and business constraints. In this paper, we classify them as architecture patterns. By doing this, we can expect increasing portability, reusability, adaptability, maintainability, and eventually productivity and improving quality. Keywords - Software Product Line, Architecture Pattern, Mobile Game, Software Reuse. 1. Introduction' Software reuse has been getting popularity more and more since it has been considered as one of the most effective ways of increasing productivity and improving quality of software. Product line software engineering (PLSE) is an emerging software engineering paradigm in which applications are developed by integrating existing product line assets. Feature-oriented product line software engineering [1] is a promising software development paradigm and an effective way for software reuse. In the domain of mobile game, mobile games (mobile applications in general) require obligatory non-functionalities (e.g., portability, performance, security) because of its intrinsic qualities of environments and business constraints. In [2], many of the variations from constrained resources are listed. However, by following the process of [1], we also should consider the results of market analysis. Accordingly, environmental difficulties and business constraints are as follows: UT features (e.g., various screen sizes, number of colors, pixel depth, sound, keypad display, and vibrations); available memory and maximum application size; company-specific libraries; non-functional features (e.g., fast time-to-market, portability). Although the PLSE becomes more popular for reuse, in the domain of mobile games, it has been rarely used. The reasons ' This work was supported by the Korea Research Foundation Grant funded by the Korean Government (MOEHRD, Basic Research Promotion Fund) (KRF-2006-33 1-D00475) and was supported by the IT R&D program of MIC/IITA [2007-S032-01, Development of mobile application software environment technology supporting development multi-platform]. -118- why not to apply PLSE into the domain ofmobile games are as follows: First, basically the develop cycle is too short to follow processes of product line. Second, though there suggested developing methods with low cost and risk [2], small to medium-sized companies and organizations even tend not to try to find more effective ways. Third, there has been no explicit method for implementing reusable architectures in that domain. Thus, the guidelines for mobile applications product lines and the explicit implementation or construction of reusable architectures are essential for success. Given contemporary methods for developing product lines in the domain of mobile games and suggested software architecture patterns which are directly applicable, we can expect to improve quality and to increase productivity through using the available resources. Moreover, if the architectures are independent from various platforms which are converted later into a platform specific model (PSM), we can also expect to obtain the adaptability, portability, and reusability. Hence, in this paper, we suggest the feature-oriented architecture patterns for mobile games product lines. 2. Mobile Game Domain In general, applications in mobile application domain are mainly classified into server-side applications and client-side applications. However, we are more familiar with ones in client-side. Hence, we primarily focus on eliciting architecture patterns in the domain of rich-clients of mobile games. Mo b ile Game Garne Play Style Turn-Based,Scenario-Based Real-Time Genre Netwo rk Conrnection Always Co ntents Ev olut ion No rie Partial Simfulatio n Arcad e J ump & un Puzzle RctgFght Shoot ing Sp o rits Flight Love Strategy NuUrtur Histo ry Co nstruction TBS RTS Hybrid RPG TRPG Tactics Action RP G Onlinee RPG Figure 1. A partial feature model of mobile game domain Figure 1 shows a partial feature model of the mobile game client domain. Since the features such as "Game Play Style", "Genre", and "Contents Evolution" can affect the software architecture organization, they are used to parameterize the software architecture patterns. Hence, through the feature
selection, semi-automatic derivation of architecture patterns can be conducted in the mobile games product line. Although there are some other important factors such as QoS and other quality attributes which affect software architecture, the result of the feature selection mere guide the architecture selection. In other words, they are too abstract and thus we are hard to choose concrete one through them. For example, most of the applications in mobile game domain require QoS (Quality of Service) such as safety, usability, security, and performance and development quality attributes such as maintainability, reusability, modifiability, and fast time-to-market. Hence, it is possible to derive almost all ofthe pattern candidates from those general requirements. Thus, we should do feature modeling in a more domain-specific way through the significant characteristics in mobile game domain. That is, the feature model should contain more valuable for deriving (Fig. 1). 3. Architecture Pattern Basis For the reusable architecture as patterns, we focus on module architecture patterns which are derived from real products by applying reverse engineering. Since, in general, performance and generalization (for reuse) are in inverse proportion, we should regulate qualities of the patterns between performance and reusability. 3.1 Canonical Form Like design patterns [3], we can classify architecture patterns. By using classification templates, we can easily apply patterns to problems. Here, we suggest that a canonical form for architecture patterns. Table 1. A template for the canonical form Variants The name of a pattern The context for applying a pattern How a pattern applies to the context Variation points of a pattern Other patterns related to a pattern It is noted that, in addition to these items, descriptions for an architecture pattern should contain a static diagram to show the overall organization of the pattern and a behavior diagram to show the significant dynamic behavior to know how the pattern works. In addition to these items, we have been augmenting the entries to contain more specific and useful information such as names which are also known as, examples to explain the need ofthe pattern, problems which will be addressed by the pattern, implementation guidelines, resolved examples, and so on. 3.2 Constituents For delineating architectures, we suggest a notation for constituents of architecture patterns. In Fig. 2, the "use" matches the required interface of a component and the "interface" is an abbreviation of the provided interface of a component. -119- C 6 rh r1) oie it use )~ n1te ifce Figure 2. A notation for architecture pattern primitives Contours of a component and two lines of "use" and "interface" can be dotted lines meaning that they are optional. A component is composed of at least one class. For the classes and their relationships inside a component, we use UML class diagram notation [4]. 3.3 Implementation Components can be implemented by AOP [5]. According to [6], it is effective to implement variable features using AOP. Moreover, for the advanced implementation of inclusion and exclusion of a component depending on the feature selection, we are able to use the framed aspects [7]. By using these contemporary methods, variations of architecture patterns can be conducted. 4. Architecture Pattern Exploitation At the outset of elicitation, it is noted that we omitted the diagrams except for the last one because of space limitation. In fact, first two patterns are relatively easy to understand than the last one. 4.1 Ut-oriented decentralized control pattern Basically, many mobile games are developed by a unit of screens. Development teams are classified and managed by following the boundary of screens. Besides, there exist patterns related to inside screens (UI). For example, screens of setting menus, of board games, of shooting games, and so on. We call these screen-related patterns shortly as Ut-patterns. In other words, the code-level reuse of Ut can be overcome by Ut-patterns. But, it is not within the scope of this study to outline all of the related detail patterns. Hence, we will limit ourselves to architectural patterns. Ut-oriented decentralized control pattern is described as follows: Table 2. Ul-oriented decentralized control pattern Variants Ut-oriented decentralized control pattern. Parallel programming (reduce dev. time). Overcome code level reuse of Uls. Reusability; Maintainability. Use Ul patterns and let Uls communicate using predefined interfaces. Similar Uls can be bound together. Aux. (-Manager components) components. Observer pattern (Push).
lcontrolk "IIiibration ISound I INlet 4rk... IStorage Figure 3. Contents-adaptable pattern 4.2 Centralized control pattern Ifwe look into the mobile games in detail, we will find easily that they are very small-scaled products and that they are composed of similar UTs and data. In that case, we can consider them as cohesive elements. Thus, we can implement the tightly related elements in single component. That is, we bind a controller with all small data used in the controller. The, it looks like a huge single MVC structure. Centralized control pattern is described as follows: Table 3. Centralized control pattern Centralized control pattern A few numbers of UTs. A few resources (storage size, memory) Performance (reducing class loading time). Make a model component and a view component be passive, and make a controller component use them. Variants A model data can be a data object of inside a controller component. Aux. (-Manager components) components. Pure fabrication pattern Observer pattern (Pull). 4.3 Contents-adaptable pattern Users often want to change requirements. It means that the application should have modifiability and/or scalability. In a mobile game domain, for example, users sometimes want to change stories or sounds. Thus, extension ofthe game contents should be addressed. To accept these requirements, we suggest contents-adaptable pattern. The pattern is described as follows: Table 4. Contents-adaptable pattern Contents-adaptable pattern In a fixed structure of software, contents of it vary and are reconfigured. Make a downloadable content package contain constitution information (i.e., UT transition, UT composition) and a content manager component reconfigures an application based on the information Variants With supporting of dynamic class loading, we can extend to architectural reconfiguration. Factory pattern -120-
Figure 3 represents an organizational view ofthis pattern. As we discussed before, dashed line components and arrows mean that they are optional. According to the feature model in [8], the optional elements are sometimes related to variable features. Later, when we develop products, we select features for each, and then the result of selection affects to the architectures. Even the optional elements are not related to features, we should go through the adaption phase. Solid line components mean that they are mandatory. The classes and their relations inside each component are obligatory for the right operation of components. In addition to the static relationships among components in the pattern, we have to show the dynamic relationships among them to convince the pattern users that how it works. The following scenario shows how the content is installed within the architecture. GameManaqer U IModel Invoker li- li- pos = getposition Figure 5. Dynamic behavior of contents-adaptable pattern (display refresh) ContentManager 5. Concluding Remarks and Future Work I As we explained above, architectures for mobile games have some patterns because of constraints and natures of mobile game domain. However, we merely proposed a few ofthem in this paper. They are specified as a platform independent model and generic, highly adaptable, and flexible. Later we can generate a skeleton code following steps in [1]. We already tested some of these patterns by applying tem into the real product development. Though it is a commercial product and thus we make no mention of it in detail, the development and release were successful. In short, the reusable architecture buildmodel builduimodel Figure 4. Dynamic behavior of contents-adaptable pattern (install) To install a new content, first, the "GameManager" component requests the installation of a new content to the "ContentManager" component. Then, the "ContentManager" downloads the content through the "ContentReceiver" and builds a data model and an UT model, and update state transition graph (STG) for the screen transition. Since this pattern uses a different mechanism to refresh a display because ofthe variety of models, we show the scenario for updating the display (See Fig. 5). To refresh the screen, firstly, the "GameManage" component requests drawing through the call "paint(" to the "UTModellnvoker". Then, the "UTModellnvoker" gathers screen composition information such as a position, a size, and a shape from the "UTModel" and composes display to draw the screen. In fact, this pattern is the consequence of selection of the feature, "Contents Evolution" (See Fig. 1). It is noted that more than one pattern can be used in a hybrid way. However, it needs careful analysis of potential problems such as an interaction problem. Hence, we have shown mere primitive patterns so far. -1 21 - patterns help effectively the product line engineering. The architecture patterns are effectively conducted to the real world products because we derived them from real products by the reverse engineering, then we associated them with the feature model. Thus, they are mapped intuitionally and easy to use by selection of features. Later, we will augment more architecture patterns and classify UT patterns. The support of a CASE tool is required for semi-automatic derivation of architecture patterns. Although we did not address the abstraction level of the patterns, various levels of abstraction are possible. Thus, we have to classify the levels and use them properly. REFERENCES [1] Kyo C. Kang, Jaejoon Lee, and Patrick Donohoe, Feature-Oriented Product Line Engineering. IEEE Software, Vol. 9, No. 4, July/August 2002, pp. 58-65. [2] Vander Alves, Pedro Matos Jr., Leonardo Cole, Paulo Borba, Geber Ramalho, 2005. Extracting and Evolving Mobile Games Product Lines. Proceedings of the SPLC 2005, Rennes, France, September 26-29, 2005, pp 70-81. [3] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
[4] Mandar Chitnis, Pravin Tiwari, Lakshmi Ananthamurthy, "The UML Class Diagram: Part 1", http://www.developer.com/design/article.php/2206791 [5] AspectJ Team, "AspectJ Project", http:llwww.eclipse.org/aspectj/ [6] Kwanwoo Lee, Kyo C. Kang, Minseong Kim, Sooyong Park, Combining Feature-Oriented Analysis and Aspect-Oriented Programming for Product Line Asset Development. Proceedings of the SPLC 2006, Baltimore, Maryland, USA, August 21-24, 2006, pplo3-1 12. [7] Loughran, N., Rashid, A., Framed Aspects: Supporting Variability and Configurability for AOP. Springer-Verlag Berlin Heidelberg, 2004. [8] Kyo C. Kang, Sholom G. Cohen, James A Hess, William E. Novak, and A. Spencer Peterson, Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1990. [9] Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, Euiseob Shin, and Moonhang Huh, FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. Annals of Software Engineering, 1998, pp. 143-168. -122-