Pattern-Oriented Analysis and Design (POAD) Theory

Pattern-Orient ed Analys is and Design (POAD) Theory Jerry Overton Computer Sciences Corporation, CSC joverton@csc.com Abstract Pattern-Oriented Analysis and Design (POAD) is the pr actice of buildi ng complex software by applying proven desi gns to specific problem domains. Although a great de al of research and practice has been devoted to formalizing existing design patterns and discovering new ones, there has been relativel y little research into methods for combining these pat terns into software applications. This is partly because the creation of complex software applications is so expensive. This paper proposes a mathematical model of POAD t hat may allow future research in pattern-ori ented techniques to be performed using less expensive formal techniques rat her than expensive, complex software development. Keyw ords: software design patterns; softw are architecture; soft ware engineerin g; Pattern-Oriented Analy sis and Des ign (POAD); Kolmogorov comp lexity 1. Intr od uction With Pattern-Oriented Analysis and Design (POAD), complex software solutions are created by applying proven design patterns to existing problem domains . By building from proven designs, POAD allows software architects to build complex software faster and wit h greater quality. This paper introduces a met hod for describing pattern-oriented practices using a mathe matical language . The goal of this work is to introduce a theory that will allow the examinati on of abstract patterns in the practice of POAD. Soft ware is typicall y much more expensive and t ime consum ing to build and test than new mathem atical concepts. Although mathe matical models cannot replace research using real software, they may be a relatively inexpensiv e tool for discovering which new ideas ar e worth inves tigating. The mathem atical model of POAD developed in this paper may allow future research in pattern-oriented techniques to be conducted by formul ating quest ions as mathemat ical problems and using calculations to sug gest viable solutions (see section 9 for example s). To be applicable in the actual practice of software engineeri ng, the defi nitions and predictions o f this model must be validated by em pirical observat ion. Yacoub and Amma r [13] describes POAD concepts and methods based on the results of applying pa ttern- oriented techniques in 4 different case studies. This paper compares formal mathem atical definitions to the concepts informally described in Y acoub and Amma r [13] and compares predictions based on calculation to the actual meth ods used in Yacoub and Am mar [13]. Sections 3 and 4 define the idea of a concept space as a normed, linear space in which each point in the space represents a conce pt, and distances betw een points represent the dissimilarit y betw een the corresponding concepts. Section 4 goes on t o define softwar e design patterns as functions in concept space. Section 5 uses addition and mult iplication to describe the composition of softwar e patterns. Section 6 further extends the theory to include a model of softwar e problems and solutions. Section 7 demonstrates the application of POAD theory to predict ing the existence of pattern-oriented techniques and to giving clues about the characteristics of those techniques. Section 8 compares this paper to previous works, and section 9 describes possible future applications. 2. Limitations of POAD Theory Altho ugh a mathemati cal description of POAD may be a powerful tool for discovering quantifiable relationships, it is also a very abstract way of looking at this complex software engineering tech nique. To build a mathemati cal description of POAD, it is necessary to l imit the theory only to those features that can be quantified and to look for meaningf ul relationships between those features. The only features that can be described by such a model are those that can be ascribed nume rical values – relative software complexi ty in the case of th is paper. The result is a theory that can provide a description of phenomenon of interest but cannot give an explanation of that phenomenon. For example, Equation 10 describe s a process for composing patterns in a way that allows the creation of completely new informat ion. However, it does not explain from where this new informa tion comes. In contrast, in the role- based pattern compositions of Riehle [11] and Yacoub and Amma r [13] , this a dditional information is explained to be the result of classes from different patterns participating in mor e than 1 role. 3. Absolute Information Section 4 introduces a concept space that uses absolute information as a way to measure distances between points in the space. This section gives a formal de finition of absolute inform ation. The amount of i nformation in an en tity can be defined by its Kolmogorov complexit y: the length of the shortest computer pr ogram capable of describing that entity. The concepts in this paper are built using a continuou s form of Kolmogorov complexity called second quantized Kolmogor ov complexity ( SQKC). SQKC is developed using the notion of a theoretical quantum computer U . Howev er, quantum computin g is not an essential e lement of POAD. The introduction of U is necessary only to establish a continuou s form of Kolmo gorov complexity . In SQKC, a universal quantum computer U takes in an initial quantum string   and produces an output quantu m string   . The input quantu m string   m ay be in a superposition of string s of many different le ngths:   = ∑ i = 0 ∞  i  i 1 The average length  l of the quant um string   is the average leng th of its compos ites:  l     = ∑ i = 0 ∞ ∣  i ∣ 2 l  i  2 Definition 1 SQKC , denoted K , of a quantum string   is the mini mum ave rage length of a program tha t produce s   : K     = min U     =    l     3 In cases where U     =   i s empty, SQKC is defined as  l     . The length of a program varies by programming language . However, for any 2 programmin g language s, there exists a program that can convert a program from the first langua ge into the equivalent program in the second. The difference in pr ogram length s of different language s is invariant up to an additive constant proportional to the size of the conversion program. This invariance makes SQKC independent of an y programmi ng language (up to an additive constant), and it is also a suitable measure of the absolute amount of informa tion present in any entity. SQKC is not computable. It is a theoretical measur e used in Section 5 to define the a ct of pattern composition as the manipulation of information in a given pattern. Definition 2 The Conditional SQKC of a program   compared to   is the minimu m SQKC of all programs capable of producing   given only   : K    ∣   = min U    ,    =   K     4 Conditional SQKC is a measure of the amount of informat ion needed to produce a final state given an initial one. Definition 3 The SQKC Distance between 2 programs   and   is the minimal amount of informat ion needed to translate   into   and   into   :     ,    = K    ∣    K    ∣    5 The SQKC distance is a measure of all effective simil arities between   and   . It fits an intuitive notion of distance. It is sym metric, positive and obeys the triangle inequality. 4. Software Design Patt erns A design pattern describes a pr oblem that frequentl y occurs in sof tware desig n along wi th its prove n solution. For example, the Model-View -Controller (MVC) pattern is used t o solve the problem of creating flexible graphical user interfaces. With MVC, a Model represents an instance of a domain- specific c oncept, a View realizes a specific user interface repre sentation of the Model, and a Controller relays inputs from the user to the Model. The following is a series of definitions that lead to the mathema tical definition of a pattern and a pattern's behavior. Definition 4 A concept is a quantum string   in a unique superposition with all other concepts such that:   = ∑ i = 0 ∞  i  i 6 The concept   has properties analogous to the intuitive notion of a concept w here  i can be interpreted as a measure of how well  i typif ies   . Definition 5 A concept space  is a normed linear space of concepts where the distance between 2 concepts   1 and   2 is     1 ,   2  . Definition 6 A pattern f     :    is a function that maps concepts to other concepts. The domain of a pattern is the pattern's context and the range is t he pattern's structure . For example, the context of the MVC pattern is the collection of events received from the user. The structure of the pattern is the relationship maintai ned between the Mode l, View and Controller participants. Definition 7 The behavior of a patt ern f is its derivative f ' . The derivative of a function is itself a functio n. This new function desc ribes changes in the or iginal function at any point. Similarly , t he behavior of a pattern is itself a pattern. This new pattern describes how the original pattern changes given a particular context. The behavior of the M VC pattern, for example, describes how events from the user are process ed by the controller, how t he controller updates the model, and how the views respond to changes in the model. 5. Composition of Design Patterns Simpl er patterns can be composed into more complex patterns. For exa mple, the MVC pattern is the result of multiplication of the Observer and Strategy patterns. A model class is introduced that implem ents both the Observer's subject class and the Stra tegy 's strategy class. The resulting MVC pattern has qualities (such as dynam ic user event handling) found in neither original pattern. The POAD practice described in Yaco ub and Amm ar [ 13] relies on 2 basic patt ern operations: stringin g patterns and overlapping patterns. Two patterns are strung together by combin ing the participants of the patterns. F or example, stringing together a Str ategy pattern and an Observer pattern, will result in a pattern that has all the classes of the Strategy pattern and all the classes of the Observer pattern. When stringi ng together patterns, the resulting composite pattern is never more complicated than the sum of the originals. Stringing together patte rns is commu tative and associative: no matter what order a series of pa tterns are strung together, the result will be the same. Any pattern strung together with the null pattern would resul t in the original pattern. Any pattern strung togeth er with its anti- pattern would result in the null pattern. With pattern overlapping, a single class participant from a pattern is also made to be a class participant of other patterns in a singl e design. For example, one w ay of overla pping the Observer pattern with the Strategy pattern is to use a ll participants of both patt erns, but make the Abstract Strategy class of the strategy pattern also play the role of Abstract Subject in the Observer pattern. Overlapping patt erns can produce complexity not present in the original patterns. Any pattern overlapped with a pattern c onsistin g of a single, empty c lass will result in the original pa ttern. Changing the order of overlapping a ser ies of patterns does not chang e t he outcome. A particular pattern overlap can be performed on individual patterns before they are s trung together or on a composite after pa tterns are strung together wit h the same result. The following introduces a pattern algebra that models, mathem atically, the c omposi tion of design patterns desc ribed in Y acoub and Amma r [13]. In this model, pattern addition is an abstract model of stringin g t ogether patterns, and pattern multiplication is an abstract model of overlapping patterns. Definition 8 The pattern d istance ∥ f − g ∥ between 2 patterns f and g on the interval [   a ,   b ] is: ∫   f     , g     d   7 Pattern distance measures the amount of dissimilarity between patt erns. The distance be tween 2 patterns is the total amount of dissimilari ty between the patterns whe n compared using a common c ontext. Definition 9 A pattern space ℘ is a normed linear space of pa tterns where the distance between 2 patterns f and g is ∥ f − g ∥ . From Definitio n 8, the norm ∥ f ∥ = ∥ f − 0 ∥ for ℘ is a numeri cal functio n that satisfies: a) ∥ f ∥ ≥ 0 b) ∥ f ∥ = 0 ⇔ f = 0 c) ∥  f ∥ = ∣  ∣ ⋅ ∥ f ∥  if  ∈ ℝ  d) ∥ f  g ∥ ≤ ∥ f ∥  ∥ g ∥ 8 In ℘ , t he pattern operations of addition and multi plication of patterns f , g and h and real numbe rs  and  are defined as: Pattern addition : a) f + g = g + f b)  f  g  h = f  g  h  c) ∀ f ∈ ℘ , f  0 = f d) for each f ∈ ℘ , f  − f  = 0 9 Pattern multiplication: a) ∀ f ∈ ℘ , f ⋅ 1 = f b)    f =     f c)      f = f   f d)   f  g =  f   g 10 The norm of a pattern turns out to be a measure of the amount of informatio n in that pattern. From definitions 3, 9 and 8 it follows that: ∥ f ∥ = ∥ f − 0 ∥ = ∫   f     , 0  d  = ∫ K  f     ∣ 0   K  0 ∣ f     d  = ∫ K  f     d  11 For patte rn addition: ∥ P 1  P 2 ∥ ≤ ∥ P 1 ∥  ∥ P 2 ∥ . This places a limit on the amount of complexity that can be produced as a result of an a ddition operation. With patt ern addition, the r esult can never be more complex t han the sum of the original patterns. For patte rn multip lication: ∥  P ∥ = ∣  ∣ ⋅ ∥ P ∥ . Unlike pattern addition, the amount of complexi ty produced is not by to the complexity of the original pattern. It is possible to create new informatio n as a result of pattern mul tiplication. 6. Software Pr obl ems This section extends POAD theory t o i nclude a model of soft ware problems and patterns solu tions. Definition 10 A software problem i s a functional (a function of function s) J [ y 1,  , y n ] of the patterns y 1   x  ,  , y n   x  of the form : J [ y 1,  , y n ] = ∫ b a F   x , y 1,  , y n  d  x 12 Where its solution is J [ s 1,  , s n ] such that J is an extrema. Solving the problem means finding the patterns that r esult in the opt imal solution: the fastest completion time, the least amoun t of r esources, the best user experience, etc. 7. Application of POAD Theory This section demonstrates the application of POAD theory to predicting the existence of pattern-oriented techniques and to giving clues about the characteristics of those techniques. The predictions made by the theory ar e compared t o conclusions reached in actual practice. Using the results of 4 case studies, Yacoub and Amm ar [13] concluded POAD is a viable application development technique. It is possible to build softwa re applications entirely by stringing t ogether and overlapping de sign patterns. Using POAD Theory, this same co nclusion can now be derived mathemati cally. In terms of POAD Theory, t he question becomes: Is it possible to approximate the solution S = J [ s 1,  , s n ] to an arbitrary soft ware problem J , with a pattern composition P =  1 p 1     n p n that mini mizes: max 1 ≤ i ≤ m ∥ ∑  i p i   x i  − S   x i  ∥ 13 In other words, is it possible t o find a pattern P that best approximates the solution S , given t hat the only thing s that ar e known about S are S   x i  ,  , S   x n  ? Ans wering this question is the same as asking if there is a solution to the li near system of equations: [ p 1   x 1  ⋯  p n   x 1  ⋮ p 1   x n  ⋯  p n   x n  ] [  1 ⋮  n ] = [ S   x 1  ⋮ S   x n  ] 14 Equation 14 is exactly determined and, therefore, has a solution. For every pr oblem J , there is a pattern composition P =  1 p 1     n p n that best approximates t he solution S to J given that S   x i  ,  , S   x n  is kno wn. POAD Theory can be also be used to give clues about t he qualities of a successful pattern- oriented technique. For example, the dependencies between the patterns s 1   x  ,  , s n   x  that s olve the problem J can be re presented as a sys tem of simul taneous of differential equatio ns: s 1 ' = f 1  s 1,  , s n  ⋯ s n ' = f n  s 1,  , s n  15 Equation 15 assum es that any change in a pat tern is some function of all other patterns, and changes in any one pattern has some effect on all the others. Howev er, one of the conditions necessary for the patterns s 1   x  ,  , s n   x  to solve J is that they satisfy a condition: s i ' = z i 16 of the canonical form of the Euler equations, where z i is a funct ion independent of all other variables of Equation 15. Under this condition, the patterns s 1,  , s n are elimi nated from the fun ctions f 1,  , f n leaving patterns that are c ompletel y independent of each other. Every pa ttern-oriented solution J [ s 1,  , s n ] , in the simplest form, consists of patterns s 1,  , s n that a re functionall y independent of each other. Yacoub and Amm ar [13] r eached this same conclusion by applyin g pa ttern-oriented techniques in 4 different case studies. They recommend that solutions be documented as a collection of constructional design patterns. These patterns interact with each other only through well-define d interfaces that allow all patterns to be treated as black boxes with hidden in ternal structures. 8. Related W ork Yacoub and Amm ar [13] use several case studies to explore the viability of actual pattern-oriented techniques. Their work is used as an empirical basis for the mathema tical model developed in this pa per. Thi s paper compares its formal mathema tical definitions t o their infor mal concepts and com pares pr edictions based on calculation to the actual meth ods they us ed. Patterns in t his paper match abstract m odels of lattices described by Eden, Yehudai and Gil [6]. A lattice is a meta programmi ng tool that, similar to this paper's def inition of a pattern, produces a solution structure given an input context. Unlike the model of patterns in this paper, lattices also include a detailed description of the semant ics of how the conversion from context to solution occurs. These se mantics included specific techniques called tricks. Although tricks ma y be used for pattern com position, Eden, Yehudai and Gil [6] focused mainly on using tricks to implem ent a single pattern and did not explore the possibility or limitati ons of using tricks for pattern composition. Patterns in this paper also match abs tract models of the patterns described by Hallstrom and Soundarajan [9]. Ha llstrom and Soun darajan [9] define patterns as a construct that produces a solution structure (called a reward), given an input c ontext (called a responsibility). Unlike this paper, Hallstrom and Soundarajan [9] focus on reasonin g a bout patterns thems elves rather than exploring pattern-oriented techniques. Their formal specifications ar e designed to identify the standard and s pecialized portions of a pattern, discover r estrictions on the application of a pattern, and predict the rewards of applying a pattern. Riehle [11] presents examples o f how to create composite design patterns using a role-based analysis . Required col laborations are grouped and assig ned to roles. Pattern composition occurs when objects from different patterns are assigned to roles based on composition constraints associated with the role. The model of pattern composition presented in this paper work s as an abstract model of t he role-based composition approach of Riehle [11]. This makes sense because the pattern composition of Y acoub and Amm ar [13] is based on the approach described in Riehle [11]. 9. Futur e Applications With further development, it may be possible to use POAD Theory to discover completely new techniques. For example, S ection 7 concluded that it was pos sible to compose softwar e solutions completely from softwar e design patterns. However, it also requires t hat points of the solution S   x i  ,  , S   x n  be known a priori. Are there methods th at allow the compositi on of softwar e solution s using patterns while requiring a limited kn owledge o f the solution? Is it possible to approxi mate the solutio n S = J [ s 1,  , s n ] to the software problem J by creating a pattern composition P = f  p 1,  , p n  in iterations knowing only S   x i  in the i th step? If so, how many iterations a re needed to a pproximate the solution to desired accuracy? A serial approach to definin g detailed requirements early in a softwa re development projec t often leads to a signif icant a mount of wasted effort, according to Amble r [1]. Ans wers to the questions about what could be done with limit ed knowled ge of the solution may lead t o new techniques that all ow complex softwar e problems to be solved w ithout requiring detailed upfront specifi cations of the solution. Missing from POAD theor y is the notio n of a softwar e quality. Software qualities are attributes of design pa tterns such as reliability, usability and performance. Any notion of a softw are quality Q woul d mos t likely be expres sed as some functio n Q  P  of a pattern P . Are there method s of composin g a pattern P = f  p 1,  , p n  that can guarantee that the final composite pattern P will preserve the qualities of its c omposite elements: Q i  P  = Q i  p i  ? The a bility to predict the qualities of complex softwar e prior to its construction is a holy grail of softwar e engineeri ng, according to Bass, Clements , and Kazman [2]. An affirmat ive answer to the questions about predicting softwar e qualities could lead to techniques that would allow the prediction of even the most complex syste m’s qualities pr ior to c onstruction. A negative answer may a t least indicate that it is not wise to spend time and effort purs uing this goa l. 10. Refer ences [1] Ambler, S. W., Examining the “Big Requirements Up Front (BRUF) Approach”, http ://www.ag ilemodeling.com/ essays/ examiningBRUF.htm, 2007 [2] Bass, L. Clements, Kazman, Softw are Architecture in Practice Second Edition, Addison- Wesle y, Boston, 2003 [3] Buschmann, F., Meunier, Rohnert, Sommerlad, Stal, Pattern-Oriented Softw are Architecture , Wiley, West Sussex, England, 19 96. [4] Cheney, E.W. Approximatio n Theory , AMS Chels ea Publish ing, Provi dence, Rhode Island, 1966. [5] Devlin, K., The Langu age of Mathematics: Making the Invisible Visible , Henry Holt and Co mpany, New York, 2000. [6] Eden, A ., Gil, Yehudai, Precise Specificati on and Automatic Applicatio n of Design Patterns , Proceedings of 1997 International Conference on Automated Software Engineering, 19 97 [7] Gelfand, I.M. and S.V. Fomin, Calculus of Variati ons , Dover Publicatio ns, Inc , New York, 1963. [8] D. Johnson, “Challenges for T heoretical Computer Science: DRAFT,” http://www.research.att.com/~dsj/ nsflist.html, 2000. [9] Hallstrom, J., Soundarajan, Reasoning About Design Patterns: A Case Study, http://www.cse.ohio- state.edu/~neelam/papers/sea04.pdf [10] Li, M. and P. Vitanyi, An Introducti on to Kolmogor ov Complexity and Its Applica tions , Springer, New York, 1997. [11] D. Riehle, Composite Design Patterns , Proceedings of the 12 th ACM SIGPLAN Conference on Object-Oriente d Programming, Systems, Languages and Applicatio ns, ACM Press, New York, 1997 [12] C. Rogers, and V. Ven dral, “The Second Quantized Turing Machine and Kolmogorov Complexity,” http://www.citebase.org/cgi-bin/fulltext?format =application /pdf&identifier=oai:arXiv.org:quant- ph/0 506266 , 200 5. [13] Ya coub, S.M. and H.H. A mmar, Pattern- Oriented Analysis and Design , Addison- Wesley, Boston, 2003.