Migration of a Chosen Architectural Pattern to Service Oriented ...
Migration of a Chosen Architectural Pattern to Service Oriented ... Migration of a Chosen Architectural Pattern to Service Oriented ...
Chapter 3. Architectural Patterns 34Selection of literature sourcesSelection of architectural patterns from the literature sourcesRemoval of patterns that exist in only one sourceAssignment of architectural patterns to selected categorySelection of representatives for categoriesRemoval of rarely interacting patternsPrefeasibility StudyFinal SelectionFigure 3.1: Procedure of selection of Pattern for migration4. Identified Architectural Patterns– presents a list of identified ArchitecturalPattern. The identified patterns are selected from literature presented insection Sources of Architectural Patterns. The list is further reduced to thepatterns existing in two out of three sources.3.1.1 Patterns in Software EngineeringPattern is not a brand new idea. The first person who defined a pattern as [56]: “A recurring solution to a common problem in a given context and system offorces.” was Christopher Alexander [24] [56] – an architect born in Vienna. Hepublished (1977) in his book more than two hundreds of architectural solutions,which included both very general and abstract tasks like city planning as well
Chapter 3. Architectural Patterns 35as very detailed tasks like room planning. The Alexander’s idea inspired KentBeck and Ward Cunningham. They presented their observations and adaptationsof patterns to Software Engineering during Object Oriented Programming, Systemand Language (OOPSLA) conference in 1987 [56]. However , the origin ofpatters are patterns used in architecture, the patterns in Software Engineeringdo not refer only to architecture of system. The general classification presentedin “Patterns in the field of software engineering”[56] groups patterns into threemain categories that in turn are divided into seven subcategories (see figure 3.2.The main categories are[56] :1. Implementation patterns – present implementation of the system from differentpoints of view. Those patterns are further broken into four morecategories.(a) Reference Architectural Patterns – this category contains patterns thatare dedicated to a particular domain [56].(b) Design Patterns – in general, design patterns define, explain and solvedesign problems in an object oriented system [56].(c) Analysis Patterns – those patterns are rather a group of concepts thatrepresent a common modeling in business [56].(d) Architectural Patterns – architectural patterns provide predefined subsystemswith relations between them and responsibilities of those subsystems[56].2. Process and improvement patterns – this type of patterns present solutionsfor tasks that are common during development and improvement activities.The category is further broken into two subcategories:(a) Process Patterns – the patterns show and guide how to conduct specifictasks in the development of process [56].(b) Software process Improvement Patterns – define improvements for alreadyintroduced processes [56].3. Configuration management patterns – contains only one subcategory.(a) Software configuration management patterns – the patterns describeprocesses that are associated with whole lifecycle of a product(see [56]for more detailed information about types of patterns ).3.1.2 Definition of Architectural PatternsDespite the fact that the classification [56] of patterns in Software Engineeringclearly separates Architectural Patterns from Design Patterns, it is not always
- Page 1 and 2: Master ThesisSoftware EngineeringTh
- Page 3 and 4: AbstractContext: Several examples o
- Page 5 and 6: List of Figures1.1 Research methodo
- Page 7 and 8: List of Tables3.1 Summary of archit
- Page 9 and 10: 3.3.1 Definition of Pattern Languag
- Page 11 and 12: Chapter 1Introduction1.1 Background
- Page 13 and 14: Chapter 1. Introduction 3technique
- Page 15 and 16: Chapter 1. Introduction 5was notice
- Page 17 and 18: Chapter 1. Introduction 7do not pro
- Page 19 and 20: Chapter 1. Introduction 9Chapter 4
- Page 21 and 22: Chapter 2. Related Work 11This chap
- Page 23 and 24: Chapter 2. Related Work 13(b) Chara
- Page 25 and 26: Chapter 2. Related Work 15Figure 2.
- Page 27 and 28: Chapter 2. Related Work 17Drawbacks
- Page 29 and 30: Chapter 2. Related Work 19Figure 2.
- Page 31 and 32: Chapter 2. Related Work 21Advantage
- Page 33 and 34: Chapter 2. Related Work 23between a
- Page 35 and 36: Chapter 2. Related Work 252. Applic
- Page 37 and 38: Chapter 2. Related Work 274. Mediat
- Page 39 and 40: Chapter 2. Related Work 292.3 Summa
- Page 41 and 42: Chapter 3. Architectural Patterns 3
- Page 43: Chapter 3. Architectural Patterns 3
- Page 47 and 48: Chapter 3. Architectural Patterns 3
- Page 49 and 50: Chapter 3. Architectural Patterns 3
- Page 51 and 52: Chapter 3. Architectural Patterns 4
- Page 53 and 54: Chapter 3. Architectural Patterns 4
- Page 55 and 56: Chapter 3. Architectural Patterns 4
- Page 57 and 58: Chapter 3. Architectural Patterns 4
- Page 59 and 60: Chapter 3. Architectural Patterns 4
- Page 61 and 62: Chapter 3. Architectural Patterns 5
- Page 63 and 64: Chapter 3. Architectural Patterns 5
- Page 65 and 66: Chapter 3. Architectural Patterns 5
- Page 67 and 68: Chapter 3. Architectural Patterns 5
- Page 69 and 70: Chapter 3. Architectural Patterns 5
- Page 71 and 72: Chapter 3. Architectural Patterns 6
- Page 73 and 74: Chapter 3. Architectural Patterns 6
- Page 75 and 76: Chapter 3. Architectural Patterns 6
- Page 77 and 78: Chapter 3. Architectural Patterns 6
- Page 79 and 80: Chapter 3. Architectural Patterns 6
- Page 81 and 82: Chapter 3. Architectural Patterns 7
- Page 83 and 84: Chapter 3. Architectural Patterns 7
- Page 85 and 86: Chapter 4. Service Oriented Archite
- Page 87 and 88: Chapter 4. Service Oriented Archite
- Page 89 and 90: Chapter 4. Service Oriented Archite
- Page 91 and 92: Chapter 4. Service Oriented Archite
- Page 93 and 94: Chapter 4. Service Oriented Archite
Chapter 3. <strong>Architectural</strong> <strong>Pattern</strong>s 35as very detailed tasks like room planning. The Alexander’s idea inspired KentBeck and Ward Cunningham. They presented their observations and adaptations<strong>of</strong> patterns <strong>to</strong> S<strong>of</strong>tware Engineering during Object <strong>Oriented</strong> Programming, Systemand Language (OOPSLA) conference in 1987 [56]. However , the origin <strong>of</strong>patters are patterns used in architecture, the patterns in S<strong>of</strong>tware Engineeringdo not refer only <strong>to</strong> architecture <strong>of</strong> system. The general classification presentedin “<strong>Pattern</strong>s in the field <strong>of</strong> s<strong>of</strong>tware engineering”[56] groups patterns in<strong>to</strong> threemain categories that in turn are divided in<strong>to</strong> seven subcategories (see figure 3.2.The main categories are[56] :1. Implementation patterns – present implementation <strong>of</strong> the system from differentpoints <strong>of</strong> view. Those patterns are further broken in<strong>to</strong> four morecategories.(a) Reference <strong>Architectural</strong> <strong>Pattern</strong>s – this category contains patterns thatare dedicated <strong>to</strong> a particular domain [56].(b) Design <strong>Pattern</strong>s – in general, design patterns define, explain and solvedesign problems in an object oriented system [56].(c) Analysis <strong>Pattern</strong>s – those patterns are rather a group <strong>of</strong> concepts thatrepresent a common modeling in business [56].(d) <strong>Architectural</strong> <strong>Pattern</strong>s – architectural patterns provide predefined subsystemswith relations between them and responsibilities <strong>of</strong> those subsystems[56].2. Process and improvement patterns – this type <strong>of</strong> patterns present solutionsfor tasks that are common during development and improvement activities.The category is further broken in<strong>to</strong> two subcategories:(a) Process <strong>Pattern</strong>s – the patterns show and guide how <strong>to</strong> conduct specifictasks in the development <strong>of</strong> process [56].(b) S<strong>of</strong>tware process Improvement <strong>Pattern</strong>s – define improvements for alreadyintroduced processes [56].3. Configuration management patterns – contains only one subcategory.(a) S<strong>of</strong>tware configuration management patterns – the patterns describeprocesses that are associated with whole lifecycle <strong>of</strong> a product(see [56]for more detailed information about types <strong>of</strong> patterns ).3.1.2 Definition <strong>of</strong> <strong>Architectural</strong> <strong>Pattern</strong>sDespite the fact that the classification [56] <strong>of</strong> patterns in S<strong>of</strong>tware Engineeringclearly separates <strong>Architectural</strong> <strong>Pattern</strong>s from Design <strong>Pattern</strong>s, it is not always