Week 6 Software Architecture in Practice, 2024-2025

YMH359 2024-2025 Güz YMH359 Yazılım Tasarım ve Mimarisi Mimarinin Tasarlanması Bu ders notunun hazırlığı için kullanılan Kaynaklar:...

YMH359 2024-2025 Güz YMH359 Yazılım Tasarım ve Mimarisi Mimarinin Tasarlanması Bu ders notunun hazırlığı için kullanılan Kaynaklar: Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, 3 rd Edition,Chapter 19-22 Designing an Architecture Documenting an Architecture 2 1- Gathering Architecturally Significant Mimari(ASR) Requirements Açıdan Önemli Gereksinimler The most important single aspect of software development is to be clear about what you are trying to build What are Architecture Significant Requirements (ASR)? An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. Comprise both software and hardware requirements. They are a subset of requirements, the subset that affects the architecture of a system in measurably identifiable ways. 25 How to Gather Architecture Significant Requirements (AS Gathering ASRs from Requirements Documents Gathering ASRs by Interviewing Stakeholders Gathering ASRs by Understanding the Business Goals Capturing ASRs in a Utility Tree 25  Requirements Architectures exist to build systems that satisfy requirements. But, to an architect, not all requirements are created equal. An architecturally significant requirement ( ASR) is a requirement that will have a profound effect on the architecture. How do we find those? © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License ASRs and Requirements Documents An obvious location to look for candidate ASRs is in the requirements documents or in user stories. Requirements should be in requirements documents! Unfortunately, this is not usually the case. Why? © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License ASRs and Requirements Documents Many projects don't create or maintain the detailed, high- quality requirements documents. Standard requirements pay more attention to functionality than quality attributes. Quality attributes, when captured at all, are often captured poorly. "The system shall be modular" "The system shall exhibit high usability“ "The system shall meet users' performance expectations" © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License ASRs and Requirements Documents Most of what is in a requirements specification does not affect the architecture. No architect just sits and waits until the requirements are "finished" before starting work. In practice, we rarely see adequate capture of QA requirements. Much of what is useful to an architect won’t be found in even the best requirements document. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License ASRs- Look for Requirements addressing: Usage (Responsibilities): User roles versus system modes Time: Timeliness and element coordination. External elements: External systems, protocols, sensors or actuators (devices), middleware. Networking: Network properties and configurations (including their security properties). Orchestration: Processing steps, information flows, major domain entities. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License ASRs- Look for Requirements addressing: Security properties: User roles, permissions, authentication. Data: Persistence and currency. Resources: Time, concurrency, memory footprint, scheduling, multiple users, multiple activities, devices, energy usage, soft resources (e.g., buffers, queues), scalability requirements. Project management: Plans for teaming, skill sets,, training, team coordination. Hardware choices: Processors, families of processors, evolution of processors. Flexibility of functionality, portability, configurations. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Named technologies, commercial packages. Gathering ASRs - Interviewing Stakeholders Stakeholders often have no idea what QAs they want in a system — if you insist on quantitative QA requirements, you're likely to get numbers that are arbitrary. — at least some of those requirements will be very difficult to satisfy. Architects often have very good ideas about what QAs are reasonable to provide. Interviewing the relevant stakeholders is the surest way to learn what they know and need. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Gathering ASRs - Interviewing Stakeholders The results of stakeholder interviews should include: a list of architectural drivers a set of QA scenarios that the stakeholders prioritized. This information can be used to: refine system and software requirements understand and clarify the system's architectural drivers provide rationale for why the architect subsequently made certain design decisions guide the development of prototypes and simulations © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License  Quality Attribute Workshop The QAW is a facilitated, stakeholder- focused method to generate, prioritize, and refine quality attribute scenarios before the software architecture is completed. The QAW is focused on system-level concerns and specifically the role that software will play in the system. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License QAW Steps Step 1: QAW Presentation and Step 5: Scenario Brainstorming. Introductions. - Each stakeholder expresses a scenario representing his or her concerns with respect to - QAW facilitators describe the motivation for the QAW the system. and explain each step of the method. - Facilitators ensure that each scenario has an Step 2: Business/Mission Presentation. explicit stimulus and response. - The stakeholder representing the business concerns - The facilitators ensure that at least one behind the system presents the system's business representative scenario exists for each context, broad functional requirements, constraints, and architectural driver listed in Step 4. known quality attribute requirements. Step 6: Scenario Consolidation. - The quality attributes that will be refined in later steps will be derived largely from the business/mission needs - Similar scenarios are consolidated where presented in this step. reasonable. Step 3: Architectural Plan Presentation. - Consolidation helps to prevent votes from being spread across several scenarios that are - The architect will present the system architectural expressing the same concern. plans as they stand. Step 7: Scenario Prioritization. - This lets stakeholders know the current architectural - Prioritization of the scenarios is accomplished by thinking, to the extent that it exists. allocating each stakeholder a number of votes Step 4: Identification of Architectural equal to 30 percent of the total number of scenarios Drivers. - The facilitators will share their list of key architectural Step 8: Scenario Refinement. drivers that they assembled during Steps 2 and 3, and - The top scenarios are refined and elaborated. ask the stakeholders for clarifications, additions, - Facilitators help the stakeholders put the deletions, and corrections. © Len Bass, Paul Clements, Rick Kazman, distributed scenarios under Creative in the six-part Commons Attribution scenario License form of source- - The idea is to reach a consensus on a distilled list of stimulus-artifact-environment-response-response ASRs from Business Goals FIGURE 16.1 (which lead to architectures), or lead directly to architectural decisions, or lead to nonarchitectural solutions. © Len Bass, Paul Clements, Rick Kazman, distributed under Crea@ve Commons ACribu@on License ASRs from Business Goals- Example-1 Genel Veri Koruma Yönetmeliği (GDPR - General Data Protection Regulation) © Len Bass, Paul Clements, Rick Kazman, distributed under Crea@ve Commons ACribu@on License ASRs from Business Goals- Example-2 © Len Bass, Paul Clements, Rick Kazman, distributed under Crea@ve Commons ACribu@on License PALM: A Method for Eliciting Business Goals Pedigreed Attribute eLicitation Method (PALM) The method's name is derived from the outcome of quality attribute requirements with a pedigree rooted in business goals. PALM is a seven-step method. Nominally carried out over a day and a half in a workshop. Attended by architect ( s) and stakeholders who can speak to the relevant business goals. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License PALM Steps 1.PALM overview presentation 2.Business drivers presentation 3.Architecture drivers presentation 4.Business goals elicitation 5.Identifying potential quality attributes from business goals 6.Assignment of pedigree to existing© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License quality attribute drivers Capturing ASRs in a Utility Tree An ASR must have the following characteristics: A profound impact on the architecture — Including this requirement will very likely result in a different architecture than if it were not included. A high business or mission value — If the architecture is going to satisfy this requirement it must be of high value to important stakeholders. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Utility Tree A way to record ASRs all in one place. Establishes priority of each ASR in terms of - Impact on architecture - Business or mission value ASRs are captured as scenarios. Root of tree is placeholder node called "Utility". Second level of tree contains broad QA categories. Third level of tree refines those categories. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Utility Tree- Example Key: H=high M=medi um L=low ASRs that rate a (H,H) rating are the ones that deserve the most attention Stakeholders can review the utility tree to make sure their concerns are addressed. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Tying the Methods Together How should you employ requirements documents, stakeholder interviews, Quality Attribute Workshops, PALM, and utility trees in concert with each other? - If you have a requirements process that gathers, identifies, and prioritizes ASRs, then use that and consider yourself lucky. - Otherwise use one or more of the other approaches. - If nobody has captured the business goals behind the system you're building, use PALM. - If important stakeholders have been overlooked in the requirements-gathering process, use interviews or a QAW. - Build a utility tree to capture ASRs along with their prioritization. - You can blend all the methods together Use PALM as a "subroutine call" from a QAW for the business goal step Use a quality attribute utility tree as a repository for the scenarios produced by a QAW. Pick the approach that fills in the biggest gap in your existing requirements. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License Summary Architectures are driven by architecturally significant requirements. An ASR must have: ♦ A profound impact on the architecture. ♦ A high business or mission value. ASRs can be extracted from a requirements document, captured from stakeholders during a workshop (e.g., a QAW), captured from the architect in a utility tree, or derived from business goals. 21 Örnek Sorular: Aşağıdaki ifadeleri Doğru (D) veya Yanlış (Y) olarak işaretleyiniz. 1- Bir fayda ağacında (Utility Tree) bir senaryonun iş değeri Yüksek ve teknik değeri Yüksek olarak etiketlenmişse, bu, mimari için en düşük önceliğe sahip olduğu anlamına gelir. 2- Kalite nitelik gereksinimleri sadece gereksinim dokümanı kullanılarak çıkarılabilir. 3- Bir gereksinim belgesinde ağ özellikleri, kaynakların kullanımı ve dış sistemlerle iletişim, kalite nitelik gereksinimlerinin çıkarılmasına yardımcı olabilir. 22 Yanıtlar: Aşağıdaki ifadeleri Doğru (D) veya Yanlış (Y) olarak işaretleyiniz. 1- Bir fayda ağacında (Utility Tree) bir senaryonun iş değeri Yüksek ve teknik değeri Yüksek olarak etiketlenmişse, bu, mimari için en düşük önceliğe sahip olduğu anlamına gelir.- Yanlış 2- Kalite nitelik gereksinimleri sadece gereksinim dokümanı kullanılarak çıkarılabilir.- Yanlış 3- Bir gereksinim belgesinde ağ özellikleri, kaynakların kullanımı ve dış sistemlerle iletişim, kalite nitelik gereksinimlerinin çıkarılmasına yardımcı olabilir.- Doğru 22 2- Designing an Architecture  Attribute Driven Design (ADD) Attribute-driven design is a methodology to create software architectures that takes into account the quality attributes of the software. allows ancan Design architecture (and should) beto be designed performed in a systematic in a systematic and cost- way & design decisions should be justifie effective way. 21 Attribute Driven Design (ADD) Design can (and should) be performed in a systematic way & design decisions should be justifie 21 Attribute Driven Design (ADD) determine the scope of the system - what is in and what is out, and which external entities your system will interact with  Steps of Attribute Driven Design (ADD) Attribute-Driven Design (ADD) is a systematic approach to designing software architecture based on the desired quality attributes (such as performance, security, usability, etc.) of the system. to produce a design for early estimation to refine an existing design to build a new increment of the system to design and generate a prototype to Steps of Attribute Driven Design (ADD)-1 Steps of Attribute Driven Design (ADD)-2 Steps of Attribute Driven Design (ADD)-3 Steps of Attribute Driven Design (ADD)-4 Steps of Attribute Driven Design (ADD)-5 Steps of Attribute Driven Design (ADD)-6 Steps of Attribute Driven Design (ADD)-7  [.. References r Software Architecture in Practice, 4th edition, Part : 19-22 r(O 7y* ~ - 75