Towards a framework for architectural design decision support

Towards a framework for architectural design decision support Manoj Mahabaleshwar, Garching, 17. 02. 2017 Software Engineering betrieblicher Informationssysteme (sebis) Fakultät für Informatik Technische Universität München wwwmatthes. in. tum. de 1

Overview A framework for architectural knowledge management (domain models, rule engine, and visualization components) - Automatic annotation of architectural-significant elements - Population & recommendation of architecture alternatives and software solutions to realize architectural design decisions - Extract architectural decisions (focus on technical decisions) from issue management system - Classify them as either structural, behavioral, or banned decisions - Extract – who raised the concern, who took the decision and when was the decision made from the issue management system (what is implicit) - Build user profiles based on the above information Use the AKM model, user model, and a set of simple heuristics to predict the possible architectural decisions that will be taken by an architect 170217 Manoj (© Florian Matthes, 2016)

A framework for architectural knowledge management Client Apps Source tools Sync. Pipes Non-structural data Model designer IR-application Rules manager Value Added Services REST API Access control Platform Rule engine (Reasoning knowledge) Events & notifications Model-based expressions Meta-model Static knowledge model Dynamic knowledge model Static knowledge base Dynamic knowledge base Bhat, M. ; Shumaiev, K. ; Biesdorf, A. ; Hohenstein, U. ; Hassel, M. ; Matthes, F. : Meta-model Based Framework for Architectural Knowledge Management, SAGRA workshop at European Conference on Software Architecutre 2016, Nov. 28 - Dec. 02, 2016, Copenhagen, Denmark 170217 Manoj (© Florian Matthes, 2016) 3

Architecture design decision model 170217 Manoj (© Florian Matthes, 2016) 4

Sync. Pipes A platform for implementing reusable adapters 1 ectio nnec ti lish c o estab Output configuration conn 2 Sync configuration blish Input configuration esta on Sync. Pipes Configurator n Sync. Pipes Mapper concept mapper Sync. Pipes Execution es tities Update Get Entiti 4 SC KB Entities 3 attribute mapper SC model te En Get Types and Properties Crea Tool A Data model A Sync. Pipes Synchronizer https: //github. com/sebischair/syncpipes-server, https: //github. com/sebischair/syncpipes-client 170217 Manoj (© Florian Matthes, 2016) 5

An ontology-based approach for software architecture recommendations https: //github. com/sebischair/akre-server, https: //amelietor-9 f 8 c 3. firebaseapp. com 170217 Manoj (© Florian Matthes, 2016) 6

Automatic extraction and classification of design decisions from issue management systems Structural decision Issues load Decision detector uses Decision detection model classify Decision Not a decision load Decision classifier uses Decision classification model classify Behaviora l decision Ban decision https: //github. com/sebischair/Doc. Classification 170217 Manoj (© Florian Matthes, 2016) 7

Next steps (1) Automatic extraction of relationships between design decisions § Focus on extracting relationship between design decisions (influences, refined. By, decomposes. Into, compatible. With, incompatible. With) § Important for § Defining dependencies between ADDs § Specifying constraints on ADDs § Visual representation of constraint graph model § Specify constraints using an expression language § Modeling constraints required for predication purposes ADTopic contains priority status influences refined. By decomposes. Into ADIssue contains triggers belongs. To ADOutcome ADAlternative preference risk; cost 170217 Manoj (© Florian Matthes, 2016) forces compatable. With in. Compatable. With 8

Next steps (2) Who did what and when? Existing work on ADD models do not consider user preferences, project context, and heuristics to support the decision making process AIM • Extract who took the decision, how long did it take to implement, complexity of tasks involved based on source code changes • Extract a decision makers’ preferences related to technologies and types of issues handled to build user profiles. RESULT • Combining user profiles with the ADD model should support the recommendation of • Who should be responsible to address a specific concern? • What is the cost of addressing a specific concern? • • Use issue management system as the main input source Focus on a specific domain (e. g. analytics domain) and system (e. g. component-based) 170217 Manoj (© Florian Matthes, 2016) ? 9

Big picture Web-based editor Software architects Software developers current project Sync. Pipes load project ADD explorer recommend alternative architectural solution relationships between ADDs Document Classifier generate past projects annotate text with meta-information read architecture description apply ML model for new issues load projects read labeled issues AMELIE Sync. Pipes ADD recommender Document Annotator ADDs to address similar concerns users who have addressed similar concerns estimated effort to address similar concerns Facilitators Domain experts uses ML model for decision detection and classification 170217 Manoj (© Florian Matthes, 2016) 10

MSc. Manoj Mahabaleshwar Research Assistant Technische Universität München Faculty of Informatics Chair of Software Engineering for Business Information Systems Boltzmannstraße 3 85748 Garching bei München Tel Fax +49. 89. 289. 18162 +49. 89. 289. 17136 Manoj. Mahabaleshwar@tum. de wwwmatthes. in. tum. de © Google 170217 Manoj (© Florian Matthes, 2016) 11