Journal of Software Engineering and Applications, 2014, 7, 104-117 Published Online February 2014 (http://www.scirp.org/journal/jsea ) http://dx.doi.org/10.4236/jsea.2014.72012 OPEN ACCESS JSEA Software Composition Using Behavioral Models of Design Patterns Sargon Hasso 1 , Carl Robert Carlson 2 1 Technical Product Development, Wolters Kluwer Law and Business, Chicago, USA; 2 Information Technology and Management, Illinois Institute of Technology, Wheaton, USA. Email: sargon.hasso@wolterskluwer.com Received January 1 st , 2014; revised January 30 th , 2014; accepted February 7 th , 2014 Copyright © 2014 Sargon Hasso, Carl Robert Carlson. This is an open access article distributed under the Creative Commons Attri- bution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. In accordance of the Creative Commons Attribution License all Copyrights © 2014 are reserved for SCIRP and the owner of the intellectual property Sargon Hasso, Carl Robert Carlson. All Copyright © 2014 are guarded by law and by SCIRP as a guardian. ABSTRACT Given a set of requirements structured as design problems, we can apply design patterns to solve each problem individually. Much of the published literature on design patterns addresses this problem—pattern association; however, there is no systematic and practical way that shows how to integrate those individual solutions together. We propose a compositional model based on design patterns by abstracting their behavioral model using role modeling constructs. This approach describes how to transform a design pattern into a role model that can be used to assemble a software application. The role model captures the behavioral relationship between participant components in the design pattern. Our approach offers a complete practical design and implementation strate- gies, adapted from DCI (Data, Context, and Interaction) architecture. We demonstrate our technique by pre- senting a simple case study complete with design and implementation code. We also present a simple to follow process that provides guidelines of what to do and how to do it. KEYWORDS Software Composition; Design Patterns; Integration; Role Model; Architecture; DCI Architecture; System Responsibilities; Traits 1. Introduction In our prior research [1], we laid out the foundational theory for constructing system architecture by composing components using design patterns [2] as solutions to in- tegration problems. The use of patterns as integration mechanism is different from using them, as originally conceived, as solutions to design problems. Integration based on design patterns, as we will show later, is be- havioral in nature, i.e. based on collaboration, and is se- mantically richer than the traditional structural-based ap- proach using generalization, aggregation, and association. The literature abounds with techniques to help designers practice and apply design patterns in building applica- tions; however, very little attention is paid to how to as- semble applications in a systematic way from pattern- based components. In examining how the Lexi editor case study was as- sembled in Gamma et al. [2] book, or how the hierarchi- cal file system (HFS) case study was assembled in Vlis- sides [3] book, it is not very obvious how the final appli- cation is assembled from components without explaining the assembly, or composition, process explicitly. From our teaching experience to students who are assigned design projects to build applications using design pat- terns, similar to Lexi and HFS, we found out that they struggle with integrating components together. This prob- lem motivated us to research this problem and come up with an approach to integrate components using design patterns themselves as an abstraction mechanism and transforming those abstractions into realization during implementation. To emphasize, we are introducing de- sign patterns as abstract modeling elements to solve con- crete software composition problems. Here is how this paper is organized. In Section 2, we briefly survey the current design patterns-based tech-