Software Architecture Summary PDF

Software Architecture Summary (V 2.0) LC1 Software Architecture: is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties. Software Design: provides a design plan that descr...

Software Architecture Summary (V 2.0) LC1 Software Architecture: is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties. Software Design: provides a design plan that describes the elements of a system, and how they fit, and work together to fulfill the requirement of the system. Architecture: describes its major components, their relationships (structures), and how they interact with each other, Serves as a blueprint for a system. Software Architecture Contributory Factors: 1. Quality Attributes. 2. Design. 3. IT Environment. 4. Business Strategy. 5. Human Dynamics. Architecture: In Architecture, nonfunctional decisions are cast and separated by the functional requirements. Serves as a blueprint for a system. Defines a structured solution to meet all the technical and operational requirements, while optimizing the common quality attributes like performance and security. Involves a set of significant decisions related to software development: o Selection of structural elements and their interfaces. o Behavior as specified in collaborations among those elements. o Composition of these structural and behavioral elements into large subsystems. o Architectural decisions that align with business objectives. o Architectural styles that guide the organization. Software Design: Comes before the detailed design, coding, integration, and testing and after the domain analysis, requirements analysis, and risk analysis. Objectives: o Negotiate system requirements, and set expectations with customers, marketing, and management personnel. o Act as a blueprint during the development process. o Guide the implementation tasks, including detailed design, coding, integration, and testing. Goals of Architecture: - Primary goal: identify requirements that affect the structure of the application which reduces the business risks. - Display the structure of the system, but hide its implementation details. - Realize all the use cases and scenarios. - Try to address the requirements of various stakeholders. - Handle both functional and quality requirements. - Improve the quality and functionality offered by the system. - Improve external confidence in either the organization or the system. Software architecture makes software development easier by: 1- Defining the structure of a system. 2- Defining the structure of a system. 3- Defining the behavior of a system. 4- Defining communication structure. 5- Balancing stakeholders’ needs. 6- Focusing on significant elements. 7- Influencing team structure. 8- Capturing early design decisions. System Architecture: concerned with a total system, including hardware, software, and humans. The three categories of architectural structures: 1- Module Structures (implementation units): composed of logical and static elements that exist at development time, such as files, modules, and classes. 2- Component-and-Connector structures [C&C] (Runtime Structures): composed of dynamic elements that exist at runtime, such as processes and threads. Embody decisions as to how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors). 3- Allocation Structures: define how the elements from C&C or module structures map onto things that are not software: hardware, teams, and file systems. Useful Module Structures: 1) Decomposition structure. 2) Uses structure. 3) Layer structure 4) Class (or generalization) structure: The module units in this structure are called classes and the relation is inheriting from or is an instance of. 5) Data model: describes the static information structure in terms of data entities and their relationships. Useful C&C Structures: 1) Service structure. 2) Concurrency structure: - The units are components and the connectors are their communication mechanisms. - Component-and-connector structures show a runtime view of the system. Useful Allocation Structures: 1) Deployment structure: shows how software is assigned to hardware processing and communication elements. Relations are allocated to show on which physical units the software elements reside. 2) Implementation structure: shows how software elements (usually modules) are mapped to the file structures in the system's development. 3) Work assignment structure: assigns responsibility for implementing and integrating the modules to the teams who will carry it out. Architectural Patterns Module Layered pattern: A layer is a coherent set of related functionalities. Patterns - In a strictly layered structure, a layer can only use the services of the layer immediately below it. 1. Shared-data (or repository) pattern. C&C 2. Client-server pattern. Patterns - The components are the clients and the servers, and the connectors are protocols and messages and they share with each other to carry out the system's work. 1. multi-tier pattern: describes how to distribute and allocate the components of a Allocation system in distinct subsets of hardware and software, connected by some communication Patterns medium. 2. Competence center and platform.  LC2 Software Architectural Design: represents the structure of the data and program components that are required to build a computer-based system. Why Software Architecture is important? 1) Allows software engineers to analyze the effectiveness of the design. 2) Reduce the risks associated with the construction of the software. 3) Highlights early design decisions. 4) Enables communication between all parties (stakeholders) interested in the development of a computer-based system. 5) Constitutes a small prototype of how the system is structured and how its components work together. Architecture design process: - Creation of the data design. - Derivation of one or more representations of the architectural structure of the system. - Analysis of alternative architectural styles to choose the one best suited. - Elaboration of the architecture based on the selected architectural style. Architectural Style: is a description of component and connector types and a pattern of their runtime control and data transfer. Ex: (Main program with subroutines - Data abstraction - Implicit invocation - Pipes and filters – Repository - Layers). Components: are the building blocks with which an architecture can be described and are connected by connectors. Types of components: - Computational: does a computation of some sort. (Function, filter). - Memory: maintains a collection of data. (File system, database). - Controller: governs time sequence of events. (Control module, scheduler). Types of connectors: - Procedure call. - Data flow. - Implicit invocation. - Message passing. - Shared database. Each architectural style describes: 1. A set of components (a database, computational modules) that perform a function required by a system. 2. A set of connectors (subroutine call, remote procedure call) that enable communication among components. 3. A set of constraints that define how components can be integrated to form the system. View: consists of a representation of a set of elements and the relations among them (a representation of a structure). Structures: are groupings of, and relations between, elements. Element: is a generic term that can be used to represent any of the following terms: system, subsystem, module, or component. Architectural views: - Module views. - Component and connector views (C&C). - Allocation views. System quality attributes and how to enable them: - High performance, pay attention to managing the time-based behavior of elements, their use of shared resources, and the frequency and volume of inter-element communication. - High security, manage and protect inter-element communication, and control which elements are allowed to access which information. - Scalability, localize the use of resources to facilitate the introduction of higher-capacity replacements. - Modifiability, making informed decisions that require a comprehensive understanding of the relationships, performance, and behaviors of its software elements. Software development processes: - Waterfall: A sequential software development process that proceeds linearly from requirements to maintenance. - Iterative: A process where software development is organized as a series of short cycles, with each iteration delivering working software. - Agile: An incremental and iterative process that emphasizes early and frequent delivery of working software, collaboration between developers and customers, and adaptation to changing circumstances. - Model-driven development: A process that involves creating models of the domain, which are used to generate running code automatically. The role of the architect: Leadership. Communication. Negotiation. Technical skills. Project skills. Analytical skills. The architecture design process: 1) Review inputs. 2) Establish the iteration goal by selecting drivers. 3) Choose one or more elements of the system to refine. 4) Choose one or more design concepts that satisfy the selected drivers. 5) Express architectural elements, allocate responsibilities, and define interfaces. 6) Sketch views and record design decisions. 7) Perform analysis of current design and review iteration goal and achievement of design purpose. Interfaces: are the externally visible properties of elements that allows elements to collaborate and exchange information. Two types (internal-external). Internal Interfaces External Interfaces - Internal interfaces are interfaces between - include interfaces from other systems that the elements that result from the are required by the system that we are realization of design concepts. developing and interfaces that are provided by the system to other systems. Software architecture documentation: a set of views, which represent the different structures that compose the architecture. The documentation serves three purposes: - Analysis. - Construction. - Education.  LC3 Software system: represents the entire software project, including all of its subsystems. - is the highest level of abstraction in a software architecture design. Subsystems: are logical groupings of elements that make up a larger system. - software system may be composed of multiple subsystems, and they can be a standalone application and the application might be external (developed by another organization). - Each subsystem is made up of one or more modules. Modules: are logical groupings of elements. - Contained within a subsystem and consists of other modules/components. Components: are execution units that represent some well-defined functionality and encapsulate their implementation and expose their properties and behaviors through an interface. - are the smallest level of abstraction and have a small scope. Architectural drivers: are inputs into the design process, they drive and guide the design of the software architecture. Quality attributes: are measurable properties of a software system, such as maintainability, usability, testability, and interoperability, and are typically described in the context of a particular scenario. Quality attributes Include: 1) Design objectives: are a set of goals that focus on the purpose of a specific architecture design, and commonly include designing an architecture for a solution to satisfy requirements, creating a prototype, or developing project proposals. 2) Primary functional requirements: are those that are critical to the organization's business goals. 3) Quality attribute scenarios: are short descriptions of how a software system should respond to a particular stimulus. Can be prioritized by ranking them based on two criteria: their business importance and the technical risk associated with the scenario. 4) Constraints: refer to fixed limitations that are present from the beginning of a project and can be either technical or non-technical or internal or external. Technical constraints may involve using a specific technology or programming language. Non-technical constraints may involve regulatory compliance or project deadlines. 5) Architectural concerns: are the interests of the software architect that impact the software architecture.  Design Approaches Top-Down Approach Bottom-Up Approach - The top-down approach is a design - The bottom-up approach starts with the methodology that starts with the highest components needed for the solution and level of abstraction. works upwards towards higher levels of - It involves decomposition to break the abstraction. system down into smaller, more - Components are used together like manageable parts and becomes more building blocks to create other detailed as decomposition progresses until components and larger structures. And the component level is reached. the process continues until all the - Public interfaces of components are an requirements have been met. essential part of the design to understand - Is referred to as emergent design or how components interact. architecture. - effective when the domain is well - Doesn't require a well-understood understood. domain, as the team focuses on small - Enterprises prefer this approach because pieces at a time. it helps with time and budget estimates. - The system grows incrementally as the team learns more about the problem domain and solution. Advantages - Breaks a system down into smaller parts - a greater level of simplicity. which allow for tasks to be assigned to - works well with agile development individual team members, making project methodologies. management easier. - Refactoring can take place to add new or - Supports scheduling and budgeting, which change existing functionality. is attractive to enterprises. - Getting feedback earlier in the process - makes a large project more manageable. allows the team to identify any necessary changes earlier. Disadvantages - Runs the risk of a big design up front - Design flaws may not be detected until (BDUF), sometimes referred to big up- later, leading to costly refactoring. front design (BUFD). - The entire scope of work may not be - Software is complex and it can be difficult known when using this approach which to create the entire architecture up front. makes it difficult to plan and estimate the - Design flaws or missing functionality in the entire project. architecture may not be uncovered until later in the process. - Modifications in the higher level of the architecture are difficult to implement. Should be used when? - The project is large in size. - The project is small in size. - The project is complex. - The project is not very complex. - The team is large, or there are multiple - The team is small, or there is only a single teams that will be working on the project. team. - The domain is well-understood. - The domain is not well-understood. Design concepts/Architecture design principles & solutions: are building blocks used to design software architecture. Design Concepts: - Software architecture patterns: provide solutions for recurring architecture design problems. - Reference architecture: is a template for an architecture that is best suited to a particular domain and is composed of design artifacts for a software architecture that provides recommended structures, elements, and the relationships between the elements. - Tactics. - Externally developed software. Main design activities of the general model of software architecture design - Involves identifying the problems the architecture is meant to solve. - These problems are known as architecturally significant requirements (ASRs). - All architectural drivers, including design objectives, primary functional Architectural requirements, quality attribute scenarios, constraints, and architectural Analysis concerns, must be addressed during the analysis. Output: a set of architectural drivers that will serve as input for architectural synthesis. - Involves designing solutions based on the set of architectural drivers identified during architectural analysis. Architectural - This activity leverages design concepts such as architecture patterns, reference Synthesis architectures, tactics, and externally developed software to design structures, elements, and relationships between the elements. Output: is one or more candidate solutions for the identified problems. - is the process of assessing the candidate solutions designed during architectural synthesis to ensure they solve the intended problems and that all design decisions are correct. Architectural - This evaluation helps to identify any potential issues with the chosen solution Evaluation and ensures that it meets the required architectural standards. Output: is a set of findings and recommendations that can be used to improve the candidate solution.  Three of the architecture design processes available - ADD is an iterative, step-by-step method that considers quality attributes early in the design process. - ADD is specifically focused on architecture design and doesn't cover the entire architectural life cycle or include gathering architectural drivers, documenting the architecture, or evaluating it. - ADD can be combined with other methods to fill in these stages. - ADD is widely used for software architecture design and has been successfully used on various software applications. Steps: Attribute-driven design (ADD) 1) Reviewing inputs 2) Establishing the iteration goal and selecting inputs to be considered in the iteration. 3) Choosing one or more elements of the system to refine. 4) Choosing one or more design concepts that satisfy the inputs considered in the iteration. 5) Instantiating architectural elements, allocating responsibilities, and defining interfaces. 6) Sketching views and recording design decisions. 7) Performing analysis of the current design and reviewing the iteration goal and design objectives. 8) Iterating if necessary. - is an iterative, step-by-step method. - can be used to design the initial architecture as well as to refine it later, if necessary. Microsoft's technique for Steps: architecture and design 1) Identifying architecture objectives. 2) Identifying key scenarios. 3) Creating application overview. 4) Identifying key issues. 5) Defining candidate solutions. - guides software architects as they design architecture. Steps: Architecture- 1) Discovering architectural drivers. centric design 2) Establishing project scope. method 3) Creating notional architecture. (ACDM) 4) Architectural review. 5) Production go/no-go. 6) Experiment planning. 7) Experimenting with and refining the architecture.  LC4 Software Architecture Patterns (6 patterns): 1) Layered Architecture: In a layered architecture, the software application is divided into various horizontal layers, with each layer located on top of a lower layer and each layer is dependent on one or more layers below it. Layered architectures can have layers that are designed to be open or closed. Closed layer: requests that are flowing down the stack from the layer above must go through it and cannot bypass (ignore) it. ▪ Closed layers provide layers of isolation, which makes code easier to change. Layers are logical separations of a software application. Tiers Are physical separations of a software application. Multi-layer architecture: a software architecture that is organized into more than one layer. Advantages and disadvantages of Layered Architectures Advantages Disadvantages - Reduces complexity by achieving a - A requirement change may require Separation of Concerns (SoC). changes in multiple layers. - Each layer is independent. - Requires more code. - Complexity can be lowered. - More expensive to develop. - Dependencies between layers can be minimized. - Can make development easier. - Allows isolating a layer for testing. Example on layered architecture: N-Tier (Multi-tier) Architecture – most widely used. N-Tier (Multi-tier) Architecture tiers Presentation - Provides functionality for the application's UI with some validation. Tier - Usability quality attribute, should be the concern of the presentation tier. - Provides the implementation for the business logic of the Business application. (application) - Is the center of the application and serves as an intermediary Tier between the presentation and data tiers. - Provides the presentation tier with services, commands, and data. - Provides functionality to access and manage data. Data Tier - Contains a data store, such as an RDBMS (relational database management system). - Provides services and data for the business tie 2) Event-driven architecture: Event: is the occurrence of something significant in a software application, such as a state change, that may be of interest to other applications or other components within the same application. Event-driven architecture (EDA): is a distributed, asynchronous software architecture pattern that integrates applications and components through the production and handling of events and can be complemented by SOA (Service-oriented architecture) because service operations can be called based on events being triggered. Event Channels: are flows of event messages and are implemented as message queues, which use the point-to-point channel pattern, or message topics, which use the publish-subscribe pattern. Point-to-point channel pattern: is a messaging pattern used when we want to ensure that there will be exactly one receiver for a given message. Message topics: allow multiple event consumers to receive an event message and implemented by the Publish-Subscribe patter. Publish-Subscribe pattern: is a messaging pattern that provides a way for a sender (publisher) to broadcast a message to interested parties (subscribers). Event driven architecture topologies: ▪ Mediator Topology: o Uses a single event queue and an event mediator to route events to the relevant event processors. o Commonly used when multiple steps are required to process an event. ▪ Broker Topology: o The event messages created by event producers (sometimes called event bus) enter an event broker. o The event channels may be message queues, message topics, or some combination of the two. o Unlike the mediator topology, there is no event queue with the broker topology. o The event processors are responsible for picking up events from an event broker.  Types of event-driven functionality: ▪ Event notification: o An architecture that provides event notification is one in which the software system sends a message when an event takes place. o Most common in software systems that have an EDA. o The mediator and broker topologies allow to implement event notifications. ▪ Event-carried state transfer: o Is a variation on event notification. o Its use is not as common as regular event notification. ▪ Event sourcing: o The events that take place in a system, such as state changes, and are stored in an event store. 3) The Model-View-Controller pattern: The Model-View-Controller (MVC) pattern: is a software architecture pattern that is used for the UI of an application. Model-View-Controller pattern components: ▪ Model: o Manages the application data and the state. o Responsible for processing of data to and from a data store, such as a database. o Independent of the controllers and the views, allowing them to be reused with different user interfaces. ▪ View: o Is responsible for the presentation of the application. o Is the part of the application that is visible to the user. o Displays data to the user in an appropriate interface based on information received from the controller. ▪ Controller: o Acts as an intermediary between the model and the view. o Executes application logic to select the appropriate view and sends it the information that it needs to render the user interface. o Views notify controllers of user actions so that the controller can respond to them. o Controllers will update the model based on user actions. Advantages of the MVC pattern - Easy to change and test presentation or data without affecting the other. - Allows UI components to be reused because UI is separated from the data. - Allows developers to specialize in either frontend or backend development which can also speed up development. 4) The Model-View-Presenter pattern: Model-View-Presenter (MVP) pattern: is a variation on the MVC pattern where the presenter takes the place of the controller in the MVC pattern. Model-View-Presenter pattern components: ▪ Model: o It interacts with the database to retrieve and update data. o Receives messages from the presenter for updates and reports state changes back to the presenter. o Do not interact directly with views and only interact with the presenter. ▪ View: o Is responsible for displaying the user interface and data. o Each view in the MVP pattern implements an interface (view interface). o As the user interacts with the view, the view will send messages to the presenter to act on the events and data. ▪ Presenter: o Acts as an intermediary between the model and the view. o Updates the model and receives state changes from the model. o Will receive data from the model and format it for the view to display, taking an active role in presentation logic. o Each view has a presenter and the view notifies the presenter of user actions. o Unlike the MVC pattern, where a controller can interact with multiple views, in the MVP pattern, each presenter handles one, and only one, view. 5) The Model-View-View Model pattern: Model-View-View Model pattern: separates the UI from the rest of the application. works well for desktop applications, although it can be used for other types of application, such as web and mobile applications. Model-View-Controller pattern components: ▪ Model: o Same as MVC and MVP. ▪ View: o Is responsible for the presentation of the application to the user. ▪ View Model: o Acts as an intermediary between the model and the view like controller. o Provide data to views for display and manipulation. o must be capable of handling user actions and data input sent from views. o Views and View Models communicate through multiple methods (Interaction logic), such as: data binding, commands, method calls, properties, and events. 6) Service-oriented architecture pattern: Service: is a part of a software application that performs a specific task, providing functionality to other parts of the same software application or to other software applications. Service-oriented architecture: is an architectural pattern for developing software systems by creating loosely coupled, interoperable services that work together to automate business processes. SOA decomposes application logic into smaller units that can be reused and distributed which reduces complexity. Each service in a SOA encapsulates a certain piece of logic that may be responsible for a very specific task, a business process, or a subprocess. SOA delivery strategies - Begins with analysis. Top-down - Centers on the organization's business logic and requires that business processes become service-oriented. - Requires many resources, in terms of time (pre-work) and money. - Begins with the services themselves that are created on an as-needed Bottom-up basis. - Used when integrating with an existing system is needed. - analysis can occur concurrently with design and development. Agile - design and development can begin as soon as enough analysis has been completed. Service-oriented analysis: is a stage in the SOA project life cycle and is used to decide what services should be built and what logic should be encapsulated by each service and is an iterative process. Service-oriented analysis steps: 1. Defining business automation requirements. 2. Identifying existing automation systems. 3. Modeling candidate services: identifying service operation candidates and grouping them into candidate services. Enterprise logic: consists of both business and application logic. Business logic: is an implementation of the business requirements and includes an organization's business processes such as constraints, dependencies, pre-conditions, and post- conditions. Application logic: is the implementation of business logic in a technology solution.  LC5 Uses of software architecture documentation: 1) Communicate the architecture to others. 2) Assist the development team. 3) Educate team members (developers). 4) Facilitate architecture reviews (to make sure they meet requirements). 5) Allow for the reuse of architectural knowledge. 6) Help the software architect memorize and communicate the software architecture. Reasons to document software architecture: 1. Guides developers in implementing functionality based on the architecture's design decisions. 2. Provides insights into the structures and interactions of the software system's architecture. 3. Highlights available interfaces, aiding developers in determining what needs to be implemented. 4. Imposes constraints on design choices and implementation, reducing system complexity. 5. Communicates design decisions, preventing incorrect implementation choices. Architecture description (AD): is a work product used to express and communicate an architecture and they consist of one or more architecture views, with the views addressing the different concerns of the stakeholders. Software architecture views: are different perspectives or representations of a software system's architecture that focus on specific aspects or concerns. Software architecture notation: refers to a system of symbols, diagrams, or representations used to communicate information about the architecture of a software system. Three main types of software architecture notation: 1) Informal notations: are views of the architecture often created with general-purpose tools. ▪ Helps communicate the software architecture to customers and stakeholders. ▪ Helps project management understand the scope of the project. ▪ Natural language is used with this notation. 2) Semiformal notation: is a standardized notation that can be used in diagrams. ▪ Allows for some level of analysis and can be used to automatically generate code from the models. ▪ UML is used with this notation. 3) Formal notation: have semantics, usually mathematically based. ▪ Tools can use artifacts created with a formal notation for automated code generation. ▪ Some software projects choose to not use a formal notation because they require more effort to use and understand. ▪ Architecture description languages (ADLs) are used with this notation. Architecture description languages (ADLs): a formal type of expression used to represent and model a software architecture. Two examples of (ADLs): ▪ Architecture Analysis and Design Language (AADL): model both hardware and software. o Can be used to describe a software architecture, create documentation, generate code. ▪ Systems Modeling Language (SysML): a general-purpose, graphical modeling language for systems. (a subset of UML and reuses some of the same diagram types). o Can be used for specification, analysis, design, and verification. SysML diagram types Reused from - Use case diagrams. UML without - Sequence diagrams. modification - State diagrams. - Package diagrams. Reused from - Activity diagrams. UML but - Block definition diagrams. modified - Internal block diagrams. Completely - Requirement diagrams. new - Parametric diagrams. (Not reused) Structural modeling: focuses on the static structure, parts, and how they are related to each other. Behavioral modeling: shows the dynamic behavior of the components in a system. Classes: are blueprints for creating objects in a software system. Packages: logically group elements together and provide a namespace for the groups Artifact: is a physical piece of information, such as a source code file, binary file, script, table in a database, or document. Node: is a computational resource that artifacts are deployed on for execution. Two types: device nodes, execution environment nodes (EENs)). Device: A represents a physical computational resource (hardware) that can execute a program. Ex: server, laptop… Execution environment: An execution environment is a software container that resides in a device and provides an execution environment for artifacts that are deployed on it. Ex: operating system. Actor: is the role for someone or something that interacts with the system and can be a person, organization, or an external system.  UML modeling types and their diagrams Class diagrams show the structure of a software system by allowing to see the classes and their relationships. Class Uses a Rectangle to represent a class separated into 3 sections: Diagrams - Upper section: name of the class. - Middle section: attributes of the class - Bottom section: operations (methods). Component diagrams detail the structural relationship Component between components of a system. Structural Diagrams Uses a rectangle with component symbol to Modeling represent a component. Package Package diagrams show the dependencies between Diagrams packages in a software system. Uses a folder symbol to represent a package. Deployment diagrams show the software elements in Deployment an architecture and how they will be deployed to Diagrams hardware elements. Use case diagram is a graphic representation of a use case, the relevant actors, and their relationships. Use Case Actors are represented by a stick figure with Diagrams the name of the actor's role appearing Behavioral underneath it. Modeling Use cases are graphically represented with a horizontally shaped oval and the name of the use case appears inside the oval. Sequence Sequence diagrams model how components in a software system interact Diagrams and communicate and describe a sequence of events from the software (Event system. Diagrams) (Event Scenarios) Activity diagrams allows representing a series of actions in the form of a workflow. It shows a control flow and is similar to a flowchart. Can be used to model things such as a business process, flow within a use case, and procedural logic. Activity Activities in an activity diagram can either be sequential or Diagrams concurrent. An activity is shown as a rectangle with rounded corners. Software architecture evaluation methods: 1) Software architecture analysis method (SAAM): - One of the first documented methods for evaluating software architectures. - Is a scenario-based review method - The purpose of it is to review a software architecture for a variety of quality attributes, including reliability, portability, extensibility, performance. Scenario: is a description of the interaction between some source, such as a stakeholder, and a software system. A software quality attribute scenario consists of the following parts: Source of stimulus: is some entity, such as a stakeholder or another software system, which generates a particular stimulus. Stimulus: is some condition that requires a response from the software system. Artifact: is the software that is stimulated and can be a part of the software system, the entire software system, or a collection of multiple systems. Environment: is the set of conditions under which the stimulus occurs. Ex: a particular configuration of the software or specific values in the data may be necessary for the stimulus to exist. Response: is the activity that takes place when the stimulus arrives at the artifact. Measure: When a response occurs, it should be measurable which allows us to test the response to ensure that the software system meets the requirements. Software architecture analysis method (SAAM) steps: 1. Develop scenarios. 2. Describe the architecture. 3. Classify and prioritize scenarios. 4. Evaluate scenarios. 5. Assess scenario interaction. 6. Create an overall evaluation. 2) Architecture tradeoff analysis method (ATAM): - Scenario-based architecture review method. - The main participant roles during ATAM evaluation are the evaluation team, project decision makers, and stakeholders. - The evaluation team consists of: (leader, evaluation leader, scenario scribe, proceedings scribe, and questioner). Team leader: responsible for creating the evaluation team as well as ensuring that the final report is produced. Evaluation leader: runs the actual review which includes facilitating sessions that create/ prioritize/ select/ evaluate scenarios. Scenario scribe: writes notes about the scenarios as the evaluation is taking place. Proceedings scribe: responsible for capturing notes in electronic format. Questioner: focuses on raising issues and asking questions related to the architecture, with a particular focus on quality attributes. Project decision makers: are the individuals who have the authority to make changes to the software if necessary, including the power to assign/approve resources for work. Stakeholders: include anyone who has an interest in the software architecture and the system as a whole. Architecture tradeoff analysis method (ATAM) Phases: ▪ Phase 0: Partnership and preparation. ▪ Phase 1: Evaluation (consists of the following steps): 1- Present the ATAM. 2- Present the business drivers. 3- Present the architecture. 4- Identify architectural approaches. 5- Generate the quality attribute utility tree. 6- Analyze architectural approaches. ▪ Phase 2: Evaluation (continued) (consists of the following steps): 7- Brainstorm and prioritize scenarios. 8- Analyze architectural approaches. 9- Present results. ▪ Phase 3: Follow-up. 3) Active design review (ADR). 4) Active reviews of intermediate designs (ARID).  LC6 DevOps: is the set of tools, practices, and culture that enable both the development and operations terms to work together during the entire life cycle of building software applications which enables the continuous delivery of software. Shift left: (a common term associated with DevOps) is to perform tasks earlier in the life cycle, or to shift them left in the timeline. CALMS: is an acronym that represents the core values of DevOps. CALMS stands for the following: 1) Culture: - requires changing the culture of an organization so that teams with different backgrounds, knowledge and skills can work together. 2) Automation: - Involves taking manual processes and making them operate automatically which includes testing, build, and deployment processes. 3) Lean: - Lean software development (LSD): means taking the best practices of lean manufacturing and applied them to software development. - aims to optimize processes and minimize waste during the software development process. There are seven lean development principles: 1) Eliminate waste. 2) Build quality in. 3) Create knowledge. 4) Defer commitment. 5) Deliver fast. 6) Respect people. 7) Optimize the whole. 4) Measurement: - Improvement must be measurable by the team to determine if DevOps practices are working or not. 5) Sharing: - Lessons learned and feedback received should be shared between development and operations so that continuous improvement is possible. Why DevOps are important: 1. Allows the organization to deliver value faster. 2. Enables the delivery of new versions of the software quickly and with high quality. 3. Helps with complicated software. 4. Leads organizations to automate their builds, eliminating the possibility of manual errors. 5. Results in better co-operation between development and operation teams which saves time. Toolchains: a set of programming tools that are used in combination to perform a task. DevOps tools categories: ▪ Plan tools: help you to define the requirements of the application and plan the work. ▪ Create tools: are software that help in design, coding, and building activities. Ex: integrated development environments (IDEs), version control repositories, build automation tools, and configuration management tools. ▪ Verify tools: consist of software that help to ensure the quality of a software release, they automate performance, acceptance, regression, and release testing to ensure software quality during and after development, supported by functional and non-functional testing. ▪ Package tools: are used for the tasks associated with preparing a release once it has been verified and is ready for deployment. ▪ Release tools: assist teams with the scheduling and coordination of deploying software systems into different environments, including production. ▪ Configure tools: help with configuration management, and the configuration of infrastructure resources. ▪ Monitor tools: ensure that end users do not encounter bottlenecks when they use the software. DevOps release cycle activities: 1) Development. 2) Integration. 3) Build and unit testing. 4) Delivery to staging. 5) Acceptance testing. 6) Deployment to production. Important quality attributes for DevOps: 1. Testability: components need to be isolated from each other to be tested independently to determine if components are working probably or not. 2. Maintainability: must minimize complexity as much as possible to achieve, which makes it easier to understand the system and implement changes and enables shorter cycle times. 3. Deployability: is a measure of how easily and reliably a software system can be deployed from development into production. Three main DevOps practices: 1) Continuous integration (CI): Continuous integration (CI): is the practice of developers merging their changes into a shared source control repository as often as possible which reduces the number of conflicting changes and makes it easier to resolve conflicts when any exist. Activities covered by continuous integration: 1) Development. 2) Integration. 3) Automated build with Automated unit testing. Build: converts source code, files, and other assets into a software project that is in its final, usable form. Ex: (Dependency checking - Compiling source files - Creating installers…). - Automated builds eliminate the variation that can take place with manual builds, ensuring consistency between builds. - Automated tests will increase quality and reduce the amount of time that quality assurance must spend using manual testing techniques. 2) Continuous delivery (CD): Continuous delivery (CD): is the ability of an organization to release changes to users quickly. Activities covered by continuous delivery: 1) Development. 2) Integration. 3) an automated build with automated unit testing. 4) automated delivery to staging. 5) automated acceptance testing. 6) deployment to production. 3) Continuous deployment: Continuous deployment: aims to enable organizations to release changes to software systems quickly and reliably and differs from continuous delivery in that it automates the deployment to production. - Some organizations prefer that the final step, the deployment to production, be a manual process.