Migration of a Chosen Architectural Pattern to Service Oriented ...

More documents

Recommendations

Info

Chapter 2. Related Work 20/ response messages and corresponding screens are gathered and followingoutputs are generated [23]:(a) Finite State Automation – contains all identified states, transitionsbetween the states and transition triggers. The automation is not deterministicbecause given the same input; user may have a few availablepaths to follow.(b) Screen Templates – contain sets of screens that correspond to eachstate from FSA. Each screen contains features like labels and theirlocalisation. This information is necessary for automatic identification.(c) Interface –more precisely service contract with all the input and outputvariables (see 4.2.4).3. Wrapper Design – the last process makes use of previously created InteractionModel. Designing is meant to make a model interpretable by AutomationEngine. In order to achieve interpretability, the model has tobe enhanced by an additional information regarding activities executed byEngine on Automation Variables or screen fields. The additional data maycontain localization of a field, commands, input /output fields etc.Deploying and validating the wrapped use case The last process is nothingmore than establishing infrastructure for services and testing whether theyfulfill requirements [23].1. Deployment –includes all the information required to export and publishservices. The process is dependent on selected technology, for instance:selection of Web Service requires creation of WSDL document [23]2. Validation –since a significant part of the second process uses automation forcreation of Finite State Automation, validation gains in value and becomesa mandatory activity. The Validation aims at identification of failures. Thefailures may manifest as a lack of screen or an a received message is differentthan expected. Validation process can be performed in following manner[23]:(a) Regressive testing – tests take as an input data used during Reverse Engineeringand check whether expected output is delivered by a legacysystem. The tests require coverage on scenario level, what means thatevery scenario of each use case have to be executed at least once [23].(b) Path testing – the second approach requires analysis of FSA in orderto design tests covering each independent path. This means that allnodes and edges of the FSA need to be visited at least once. PathCoverage is a high level testing that requires a lot of effort to identifyall possible paths.
Chapter 2. Related Work 21Advantages and drawbacks of WrappingWrapping is a technique that does not examine code of the migrated application.In turn, this approach requires a documentation that is up to date. The migratedsystem also must be developed as a set of separated artifacts.Advantages1. The technique is systematic2. Execution of the technique is semi automatic3. There is no need to have code of the migrated applicationDrawbacks1. Documentation of the migrated system is a must. The documentation mustbe up to date.2. A full list of use cases is needed. The use cases are described in documentationthat may be missing or not maintained3. The technique bases on inputs and outputs of the system. It is hard todefine all possible combinations of input-output pairs.4. The technique does not consider properties of architecture of migrated system5. Wrapping requires very complex and time consuming testing at the end ofmigration.6. The application must be developed as a set of components that can beseparately wrapped.2.1.4 Gray– Box: Taxonomy analysisGray–Box is a compromise between white and Black–Box techniques. It takesanalysis the migrated system on both code and system level. The approachpresented in this section derives from clustering analysis. The clustering analysisis applied in order to allocate fully functionally and reusable services. Clusteringanalysis is a sequence of following processes 2.1.4:
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: Chapter 2. Related Work 19Figure 2.
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 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:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Chapter 5. Guidelines 1035.1 Patter
Page 115 and 116:
Chapter 5. Guidelines 105Descriptio
Page 117 and 118:
Chapter 5. Guidelines 107Result Con
Page 119 and 120:
Chapter 5. Guidelines 109ContextAn
Page 121 and 122:
Chapter 5. Guidelines 111Result Con
Page 123 and 124:
Chapter 5. Guidelines 113System’s
Page 125 and 126:
Chapter 5. Guidelines 115ViewSchema
Page 127 and 128:
Chapter 5. Guidelines 117ViewViewCo
Page 129 and 130:
Chapter 5. Guidelines 119ViewViewCo
Page 131 and 132:
Chapter 5. Guidelines 121ViewViewPr
Page 133 and 134:
Chapter 5. Guidelines 123FrontendFr
Page 135 and 136:
Chapter 5. Guidelines 125complicati
Page 137 and 138:
Chapter 5. Guidelines 127Concluding
Page 139 and 140:
Chapter 5. Guidelines 129UsecasesTh
Page 141 and 142:
Chapter 5. Guidelines 131puter (ext
Page 143 and 144:
Chapter 5. Guidelines 133Group 3 ma
Page 145 and 146:
Chapter 5. Guidelines 135Output: Du
Page 147 and 148:
Chapter 5. Guidelines 137generation
Page 149 and 150:
Chapter 5. Guidelines 139(a) Fronte
Page 151 and 152:
Chapter 5. Guidelines 141Figure 5.1
Page 153 and 154:
Chapter 5. Guidelines 143Figure 5.1
Page 155 and 156:
Chapter 5. Guidelines 145FrontendSc
Page 157 and 158:
Chapter 6. Conclusion 147There are
Page 159 and 160:
Chapter 6. Conclusion 149RQ.6 How t
Page 161 and 162:
References[1] http://www.soa-manife
Page 163 and 164:
References 153[22] Frank Buschmann,
Page 165 and 166:
References 155[46] Dirk Krafzig, Ka
Page 167 and 168:
References 157[67] Xiaohong Qiu. Bu
show all

Migration of a Chosen Architectural Pattern to Service Oriented ...

Create successful ePaper yourself

Delete template?

Save as template?