Architecture Knowledge Management: Challenges, Approaches, Tools M. - - PDF document
Architecture Knowledge Management: Challenges, Approaches, Tools M. Ali Babar 1 & Ian Gorton 2 1 Senior Researcher, Lero, Ireland 2 Chief Architect, Data Intensive Computing, PNNL, USA Date 5/22/2007 ICSE 2007, Minneapolis, USA 1
Date 5/22/2007
1 ICSE 2007, Minneapolis, USA
1Senior Researcher, Lero, Ireland 2Chief Architect, Data Intensive Computing,
Date 5/22/2007
2 ICSE 2007, Minneapolis, USA
Date 5/22/2007
3 ICSE 2007, Minneapolis, USA
4 ICSE 2007, Minneapolis, USA
Date 5/22/2007
5 ICSE 2007, Minneapolis, USA
6 ICSE 2007, Minneapolis, USA
Date 5/22/2007
7 ICSE 2007, Minneapolis, USA
Date 5/22/2007
8 ICSE 2007, Minneapolis, USA
Date 5/22/2007
9 ICSE 2007, Minneapolis, USA
Date 5/22/2007
10 ICSE 2007, Minneapolis, USA
Date 5/22/2007
11 ICSE 2007, Minneapolis, USA
Improve management & reusability of architectural assets Knowledge extraction and acquisition techniques Architecture knowledge Repository (AKR) Various Metrics to track the usage & growth of reusable architecture knowledge
Date 5/22/2007
12 ICSE 2007, Minneapolis, USA
Date 5/22/2007
13 ICSE 2007, Minneapolis, USA
Date 5/22/2007
14 ICSE 2007, Minneapolis, USA
Source: David Skyrme associates
Date 5/22/2007
15 ICSE 2007, Minneapolis, USA
Date 5/22/2007
16 ICSE 2007, Minneapolis, USA
Date 5/22/2007
17 ICSE 2007, Minneapolis, USA
Date 5/22/2007
18 ICSE 2007, Minneapolis, USA
Date 5/22/2007
19 ICSE 2007, Minneapolis, USA
20 ICSE 2007, Minneapolis, USA
Date 5/22/2007
21 ICSE 2007, Minneapolis, USA
22 ICSE 2007, Minneapolis, USA
Date 5/22/2007
23 ICSE 2007, Minneapolis, USA
Date 5/22/2007
24 ICSE 2007, Minneapolis, USA
Date 5/22/2007
25 ICSE 2007, Minneapolis, USA
Date 5/22/2007
26 ICSE 2007, Minneapolis, USA
Date 5/22/2007
27 ICSE 2007, Minneapolis, USA
Date 5/22/2007
28 ICSE 2007, Minneapolis, USA
Date 5/22/2007
29 ICSE 2007, Minneapolis, USA
Date 5/22/2007
30 ICSE 2007, Minneapolis, USA
Date 5/22/2007
31 ICSE 2007, Minneapolis, USA
Date 5/22/2007
32 ICSE 2007, Minneapolis, USA
Date 5/22/2007
33 ICSE 2007, Minneapolis, USA
Date 5/22/2007
34 ICSE 2007, Minneapolis, USA
Date 5/22/2007
35 ICSE 2007, Minneapolis, USA
Date 5/22/2007
36 ICSE 2007, Minneapolis, USA
Date 5/22/2007
37 ICSE 2007, Minneapolis, USA
Date 5/22/2007
38 ICSE 2007, Minneapolis, USA
Date 5/22/2007
39 ICSE 2007, Minneapolis, USA
Date 5/22/2007
40 ICSE 2007, Minneapolis, USA
Knowledge management Interface
Date 5/22/2007
41 ICSE 2007, Minneapolis, USA
A conceptual framework of capturing implicit architecture knowledge Sources of implicit knowledge
Date 5/22/2007
42 ICSE 2007, Minneapolis, USA
Date 5/22/2007
43 ICSE 2007, Minneapolis, USA
Capturing architecture knowledge from human sources
Date 5/22/2007
44 ICSE 2007, Minneapolis, USA
Date 5/22/2007
45 ICSE 2007, Minneapolis, USA
Date 5/22/2007
46 ICSE 2007, Minneapolis, USA
Date 5/22/2007
47 ICSE 2007, Minneapolis, USA
Source: Experimental Psychology by Robert R. Hoffman, AI Magazine, summer 1987.
Date 5/22/2007
48 ICSE 2007, Minneapolis, USA
Date 5/22/2007
49 ICSE 2007, Minneapolis, USA
50 ICSE 2007, Minneapolis, USA
Process model for mining patterns for architecture knowledge
Date 5/22/2007
51 ICSE 2007, Minneapolis, USA
Date 5/22/2007
52 ICSE 2007, Minneapolis, USA
Date 5/22/2007
53 ICSE 2007, Minneapolis, USA
Some known examples of the usage of the pattern to solve the problems. Example S A textual, system independent specification of a quality attribute. S General scenarios Attributes hindered Attributes supported Negatively Positively Affected Attributes What tactics are used by the pattern to implement the solution? Tactics Factors affecting the problem and solution and pattern’s justification. Forces What is the solution suggested by the pattern to address the problem? Suggested What types of problem the pattern is supposed to address? Problem The situation for which the pattern is recommended. Context A brief description of the pattern. Description Pattern Type: Architecture, design, or style Pattern Name: Name of the pattern
Date 5/22/2007
54 ICSE 2007, Minneapolis, USA
E-commerce portals, online content providers, sports websites. Examples Services calls across network or tiers shall be minimized to avoid degraded performance. S3 System shall provide a caching mechanism to improve response to business service request. S2 Presentation-tier components shall not be exposed to the implementation details of the business services they use. S1 General scenarios Introduce new layer, increased complexity Reduce coupling, manageability, performance Negatively Positively Affected Attributes Delegate Proxy and Delegate Adapter Available tactics Presentation-tier clients require access to business service. It is desirable to minimize coupling to hide implementation details from clients. Forces Reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service... Suggested solution Presentation-tier components interact directly with business services. Such a direct interaction makes the clients vulnerable to any changes in the business services… Problem description A client may be exposed to the complexity of dealing with the distributed components… Context This pattern reduces coupling between tiers by providing an entry point for accessing the services another tier. It also supports results caching to improve performance… Brief description Pattern Type: Design pattern Pattern Name: Business Delegate
Date 5/22/2007
55 ICSE 2007, Minneapolis, USA
What are reasons for using the patterns/tactics? How does it provide the desired quality attributes? Design rational What are the design tactics used by the pattern/style to support the scenarios? Design tactics Name of the architectural pattern or style that can support this scenario. Pattern/Style How important is this scenario? Priority How complex is this scenario to realize? (Effect on macro or micro architecture) Complexity A measurable action that needs to be undertaken after the arrival of the stimulus Response A system’s condition when a stimulus occurs, e.g. overloaded, running etc. Context A condition that needs to be considered when it arrives at a system. Stimulus Concrete scenario A brief description of the scenario. Description Which quality attributes are required by this scenario? Attributes Which class of the stakeholders did suggest this scenario? Stakeholders Which business goals does this scenario achieve? Business goals Date: When was proposed? Scenarios No: Serial number assigned to the scenario Project Name: Which project needs this scenario? Project domain: Domain of the project
Date 5/22/2007
56 ICSE 2007, Minneapolis, USA
This pattern exposes an interface to the business service API by using proxy function to pass the client methods to the session bean. It can cache any necessary data and references to the session bean's home
Design rational Delegate proxy and Caching Design tactics Business Delete Pattern/Style High Priority Medium Complexity The system shall be able to respond to a request within 2 seconds. Response There are 1000 users, who may request for a service simultaneously. Context A user request needs to be processed. Stimulus Concrete scenario The response to a business service request shall be improved to avoid users’ frustration and system shall be able to handle up to 1000 users concurrently without any delay in the response time. Description Improved performance Attributes Business Manager, System sponsors, and End User. Stakeholders Customer satisfaction and process efficiency. Business goals Date: 12/06/2005 Scenarios No: Serial number assigned to the scenario Project Name: Qualification Verification System Project domain: E-Commerce application
Date 5/22/2007
57 ICSE 2007, Minneapolis, USA
58 ICSE 2007, Minneapolis, USA
Date 5/22/2007
59 ICSE 2007, Minneapolis, USA
Date 5/22/2007
60 ICSE 2007, Minneapolis, USA
Date 5/22/2007
61 ICSE 2007, Minneapolis, USA
Date 5/22/2007
62 ICSE 2007, Minneapolis, USA
Date 5/22/2007
63 ICSE 2007, Minneapolis, USA
64 ICSE 2007, Minneapolis, USA
Date 5/22/2007
65 ICSE 2007, Minneapolis, USA
Source: M.S. Abdullah et al. 3rd European Conf. on KM, 2002
Date 5/22/2007
66 ICSE 2007, Minneapolis, USA
Date 5/22/2007
67 ICSE 2007, Minneapolis, USA
Date 5/22/2007
68 ICSE 2007, Minneapolis, USA
Date 5/22/2007
69 ICSE 2007, Minneapolis, USA
Rationale Scenario Stakeholder Software Architecture Architecturally Significant Requirement Architecture Description Pattern Satisfies Influences Captured by Addresses Addressed by Documents Effected by Has Contains Extracted From Created by Participates Has Effects Specify Specified by Uses Creates Involves Architecture Design Decision View Used in Captures Documented by Includes Included in Interests to Interested in Has Belong to Captured by Contains Part of Consists of Used in Uses Needs Reviews
Date 5/22/2007
70 ICSE 2007, Minneapolis, USA
Date 5/22/2007
71 ICSE 2007, Minneapolis, USA
72 ICSE 2007, Minneapolis, USA
Date 5/22/2007
73 ICSE 2007, Minneapolis, USA
Date 5/22/2007
74 ICSE 2007, Minneapolis, USA
Date 5/22/2007
75 ICSE 2007, Minneapolis, USA
Date 5/22/2007
76 ICSE 2007, Minneapolis, USA
Date 5/22/2007
77 ICSE 2007, Minneapolis, USA
Date 5/22/2007
78 ICSE 2007, Minneapolis, USA
Date 5/22/2007
79 ICSE 2007, Minneapolis, USA
Date 5/22/2007
80 ICSE 2007, Minneapolis, USA
Requirements:
Specification Define Problem Description Architecture Description Desired Quality Attribute Measures BRedB Scenarios Design Tactics Patterns Quality Define Architecture Design Quality Attribute Measures and Risks Analytical Model / Reasoning Framework
Quality Attributes Projects
Date 5/22/2007
81 ICSE 2007, Minneapolis, USA
Date 5/22/2007
82 ICSE 2007, Minneapolis, USA
Date 5/22/2007
83 ICSE 2007, Minneapolis, USA
84 ICSE 2007, Minneapolis, USA
Date 5/22/2007
85 ICSE 2007, Minneapolis, USA
Date 5/22/2007
86 ICSE 2007, Minneapolis, USA
Date 5/22/2007
87 ICSE 2007, Minneapolis, USA
Date 5/22/2007
88 ICSE 2007, Minneapolis, USA
Date 5/22/2007
89 ICSE 2007, Minneapolis, USA
Date 5/22/2007
90 ICSE 2007, Minneapolis, USA
Date 5/22/2007
91 ICSE 2007, Minneapolis, USA
92 ICSE 2007, Minneapolis, USA
Date 5/22/2007
93 ICSE 2007, Minneapolis, USA
94 ICSE 2007, Minneapolis, USA
Date 5/22/2007
95 ICSE 2007, Minneapolis, USA
Date 5/22/2007
96 ICSE 2007, Minneapolis, USA
Date 5/22/2007
97 ICSE 2007, Minneapolis, USA
Date 5/22/2007
98 ICSE 2007, Minneapolis, USA
Date 5/22/2007
99 ICSE 2007, Minneapolis, USA