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 ...

12.07.2015 Views

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

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!