13th International Workshop on Models@run.time Towards software architecture runtime models for continuous adaptive monitoring Thomas Brand, Holger Giese 14.10.2018
Agenda Show why it is relevant to investigate and support: ▪ Continuous adaptive monitoring ▪ Modeling languages for long living runtime model instances ▪ Demonstrate the significance of the modeling language ▪ Describe the planned roadmap for proposing an evaluated solution ▪ Derive requirements from illustrative scenarios and indicate how they are ▪ supported by two existing approaches Questions and discussion ▪ 2
Relevancy How does the runtime model modeling language relate to this? Why is monitoring adaptation without interruption important? Why does monitoring need to be adaptive? 3
Setting the context “ models@run.time is an abstraction of a running system that is being manipulated at runtime for a specific purpose ” [Bencomo.2013] Please imagine a software architecture runtime model thinking of: graph in a datastore ▪ running system ▪ current monitoring results ▪ analysis and phenomena detection processes ▪ 4
Classical Model-Driven Engineering approach QueryService pooledConnectionsCount: Integer pooledConnectionsMax: Interger Modeling language Meta-model level Modeling language definition content implementation Runtime model level System representation content with an API to <<instanceOf>> create models qs1:QueryService Query based on types e.g.: 4.) access 2.) use pooledConnectionsCount = 5 pooledConnectionsMax =10 QueryService. pooledConnectionCount > 5 Monitoring 5
Motivation Monitored system and information demands change over time ▪ Usage measurement and experimentation in software product development ▪ Highly dynamic architectures based on microservices ▪ Exploration and exploitation with machine learning … ▪ Modeling language determines possible information types ▪ Evolving the modeling language requires a model re-instantiation ▪ Re-instantiations interrupt the monitoring and phenomena detection processes ▪ and endanger continuous system operation A flexible modeling language regarding the types of information in the runtime model ▪ Makes long living runtime model instances possible and supports continuous ▪ adaptive monitoring and system operation Increases the feasibility of runtime models for additional fields of application ▪ 6
Significance of the modeling language To better understand: Can you show how the modeling language is actually significant? 7
Information demand changes - Filtering QueryService pooledConnectionsCount: Integer pooledConnectionsMax: Interger Modeling language Meta-model level Modeling language definition content implementation Runtime model level System representation content with an API to <<instanceOf>> create models qs1:QueryService Query based on types e.g.: 3.) access 1.) use pooledConnectionsCount = 5 pooledConnectionsMax =10 QueryService. pooledConnectionCount > 5 5.) adapt Monitoring Monitoring adaptation engine [Brand.2018] 8
Running system changes - System adaptation QueryService pooledConnectionsCount: Integer pooledConnectionsMax: Interger Modeling language Meta-model level Modeling language definition content implementation Runtime model level System representation content with an API to <<instanceOf>> <<instanceOf>> create models qs1:QueryService qs2:QueryService pooledConnectionsCount = 5 pooledConnectionsCount = 5 1.) use pooledConnectionsMax =10 pooledConnectionsMax =10 Query based on types e.g.: QueryService. pooledConnectionCount > 5 Monitoring 9
Running system changes - System evolution RegionItemFilter QueryService mode: Integer pooledConnectionsCount: Integer pooledConnectionsMax: Interger Modeling language Meta-model level Modeling language definition content implementation Runtime model level System representation content with an API to <<instanceOf>> <<instanceOf>> create models :RegionItemFilter :QueryService € 2.) use pooledConnectionsCount = 5 mode = 51 pooledConnectionsMax =10 Query based on types e.g.: QueryService. pooledConnectionCount > 5 Discontinuity! Monitoring 10
Running system changes - Software evolution QueryService pooledConnectionsCount: Integer pooledConnectionsMax: Interger cachedStatementsCount : Integer cachedStatementsMax: Integer Modeling language Meta-model level Modeling language definition content implementation Runtime model level System representation content with an API to <<instanceOf>> create models :QueryService Query based on pooledConnectionsCount = 5 types e.g.: 2.) use 4.) access pooledConnectionsMax =10 € cachedStatementsCount = 27 QueryService. cachedStatementsMax = 50 pooledConnectionCount > 5 Discontinuity! Monitoring 11
The CompArch approach There is a way to improve the situation compared to the classical approach!? 12
Dynamic Object Model pattern Model level type instance ComponentType Component 1 * * 1 propertyType * property * type instance PropertyType Property Value 1 * 1 1 Classifier definition content Model content [Riehle.2005] 13
The CompArch approach Modeling language definition content MonitoredProperty name : String * type : String value : String 1 * ParameterType Parameter * * name : String value : String type : String 1 1 1 ComponentType Component 1 * name : String Meta-model level Runtime model <<instanceOf>> <<instanceOf>> level classifies 4 <<instanceOf>> ComponentType :Component name = "QueryService" <<instanceOf>> classifies 4 :Parameter ParameterType name = "pooledConnectionsMax" value = "10" type = "Integer" <<instanceOf>> :MonitoredProperty name = "pooledConnectionsCount" [Vogel.2018] type = "Integer" value = "5" Classifier definition content System representation content 14
Planned roadmap towards a prospective solution How shall the proposed solution be evaluated? What actually are the important requirements? Does this approach fulfill the requirements? 15
Planned roadmap towards a prospective solution Running system changes Survey existing Describe illustrative languages scenarios Information demand Validate changes Discover a coherent set of requirements Elaborate and evaluate a solution 16
Illustrative scenarios and requirements Can you give us some examples of scenarios and requirements? 17
Scenarios and requirements overview Illustrative scenarios Requirements S1 - System adaptation R1 - Updating system representation structure and values Running S2 - System evolution R2 - Indicating the actual information demand system S3 - Software evolution R3 - Introducing new classifiers including classifier versions changes S4 - Systems integration and division R4 - Withdrawing obsolete classifiers S5 - Filtering R5 - Establishing new kinds of relationships Information S6 - Aggregation R6 - Assigning multiple classifiers progressively demand S7 - Itemization R7 - Integrating multiple classifier systems changes S8 - Generalization and specialization R8 - Introducing new logical elements and relationships 18
Example system Multiple tenants Simplified mRUBiS runtime model [Vogel.2018] 19
Running system changes S3 - Software evolution Runtime model level classifies 4 ▪ Conduct an experiment with new ComponentType :Component software product version version = "2.0.0" name = "QueryService" ▪ Deploy a new version of the QueryService component to early classifies 4 ParameterType :Parameter adopter tenants name = "pooledConnectionsMax" value = 10 classifies 4 ▪ Represent new component version ParameterType :Parameter with additional properties besides name = "cachedStatementsMax" value = 50 the old Classifier definition content System representation content Requirements Classic ComArch R3 - Introducing new classifiers including classifier versions -- ( ✓ ) S3 - Software evolution -- ( ✓ ) 20
Information demand changes S6 - Aggregation - Case 1: Invisible Aggregation not visible in the runtime model (on the monitoring instrument level) Runtime model Monitoring instrument Monitoring Monitoring instrument instrument Running system 21
Information demand changes S6 - Aggregation - Case 2: Visible Aggregation visible in the runtime model Case 2.a: Functional aggregation Case 2.b: Structural aggregation Runtime model level Runtime model level classifies 4 classifies 4 ComponentType :Component ComponentType :Component name = "QueryService" name = "QueryComponent" aggregates aggregates :Property value = 12 ComponentType :Component PropertyType name = "QueryOptimizer" name = "pooledConnectionsCount" :Component ComponentType :Component :Property ComponentType name = "Indexer" value = 4 name = "QueryComponent" :Component :Property value = 8 Classifier definition content System representation content Classifier definition content System representation content 22
Recommend
More recommend
