index.md (2721B)
1 +++ 2 title = 'Introduction' 3 +++ 4 # Introduction 5 What is software architecture? 6 - fundamental concepts/properties of system in its environment 7 - embodied in its elements, relationships, and principles of its design/evolution 8 - so: design + design decisions 9 10 Why? 11 - vehicle for stakeholder communication 12 - way for manager to reason about cost and schedule 13 - manifests earliest set of design decisions 14 - transferable abstraction of system 15 16 Characteristics of Software Architecture 17 - Iteration on functional/quality requirements 18 - Many stakeholders involved 19 - Balancing of functional/quality requirements 20 21 Architecturally significant requirements (ASRs): 22 - architectures are driven by quality attribute requirements (e.g. system must be modular, shall meet users' performance expectations) 23 - features/functionality shape architecture to lesser extent 24 25 Business goals: 26 - e.g. "we want to differentiate our product from competition and capture market share) 27 - may directly affect architecture 28 - often lead to quality attribute requirements 29 30 ## Architecture representations & styles 31 Structure: coherent set of architectural elements 32 View: representation of structure (picture) 33 34 Structures: 35 - modules: module is unit of implementation with assigned areas of functionality 36 - component-connector: elements with runtime behavior (components) and interactions (connectors) 37 - allocation: relationship between software elements and environment 38 39 Architectural style: description of component and connector types, pattern of their runtime control/data transfer 40 41 Design patterns: recurring structures of communicating components that solve general design problem in a context (e.g. Model-View-Controller) 42 43 ## Architecture assessment 44 Assesses whether architecture meets quality goals. 45 46 Software Architecture Analysis Method (SAAM) 47 48 * develop scenarios for 49 - activities system must support 50 - changes anticipated 51 * describe architectures 52 * classify scenarios 53 - direct: use requires no change 54 - indirect: use requires change 55 * evaluate indirect scenarios wrt changes and cost 56 * reveal scenario interaction 57 * overall evaluation 58 59 ## Architecture influence cycle 60 61  62 63 architecture affects: 64 - structure of developing organisation 65 - goals of developing organisation 66 - requirements for next systems 67 68 Building a system affects architect's experience 69 70 ## Role of software architect 71 Ineffective: police agent, documentalist, isolationist (no communication with stakeholders) 72 Effective: key tech consultant, decision maker, coach of dev team, design coordination, implementing key parts 73 74 A good architect (1) has experience, (2) has domain knowledge, (3) _communicates_.