Discovering quality attributes by applying "how well?" questions to functions in Use-Case structured scenarios, and then enriching the software architecture with additional functionality.
The quality of software systems may be expressed as a collection of Software Quality Attributes. When the system requirements are defined, it is essential also to define what is expected regarding these quality attributes, since these expectations will guide the planning of the system architecture and design.
Software quality attributes may be classified into two main categories: static and dynamic. Static quality attributes are the ones that reflect the system’s structure and organization. Examples of static attributes are coupling, cohesion, complexity, maintainability and extensibility. Dynamic attributes are the ones that reflect the behavior of the system during its execution. Examples of dynamic attributes are memory usage, latency, throughput, scalability, robustness and fault-tolerance.
Following the definitions of expectations regarding the quality attributes, it is essential to devise ways to measure them and verify that the implemented system satisfies the requirements. Some static attributes may be measured through static code analysis tools, while others require effective design and code reviews. The measuring and verification of dynamic attributes requires the usage of special non-functional testing tools such as profilers and simulators.
In this talk I will discuss the main Software Quality attributes, both static and dynamic, examples of requirements, and practical guidelines on how to measure and verify these attributes.
The document discusses quality attributes that are important factors in software engineering. It defines quality attributes as the degree to which software possesses desired characteristics like reliability, interoperability. Architecture alone cannot achieve qualities - it must consider factors for each attribute. Common quality attributes are grouped into design, runtime, system, user, non-runtime, architecture, and business qualities. Examples of attributes discussed include maintainability, performance, security, availability, testability and usability. Quality attributes are assessed using scenarios describing stimuli, environment, system response and measures.
This document provides an overview of an active workshop on functional specifications and use cases. It discusses the purpose of the workshop, which is to introduce a simple, practical, and precise methodology for writing functional specifications for software systems. The workshop agenda is then outlined, which will cover requirements, the use case model, a case study, system and software use cases, and use case realization. Finally, some basic concepts that will be covered in the workshop like stakeholders, actors, use cases, and use case diagrams are introduced at a high level.
SharePoint Server and Windows 2008 And SQL 2008 with Joel Oleson and Todd KlindtJoel Oleson
Learn what's new in Windows 2008 and SQL 2008 that SharePoint Admins should care about. These are the killer new features that will help you justify the upgrade or help you know what to investigate and validate by Joel Oleson and Todd Klindt.
The document discusses quality attributes that affect system design. It identifies four types of quality attributes: runtime system qualities, non-runtime system qualities, business qualities, and architecture qualities. Runtime system qualities include functionality, performance, security, and usability. Non-runtime qualities include modifiability, portability, reusability, and testability. Business qualities are cost and marketability. Architecture qualities are integrity and correctness. The document emphasizes that as an architect, understanding how design choices impact these quality attributes is important.
Quality Attributes In Software Architecture & Design PatternsGatte Ravindranath
Quality Attributes Topic from Software Architecture $ Design patterns in the relation to software product or any engineering architecture development process needs required by an architect.
1. Requirements analysis identifies customer needs, evaluates feasibility, and establishes system definitions and specifications. It bridges the gap between requirements engineering and system design.
2. Requirements analysis has several phases including problem recognition, evaluation and synthesis of possible solutions, help modeling, and writing definitions and specifications. It also considers management questions around effort, roles, challenges, and costs.
3. Requirements analysis determines functional requirements describing system behavior and inputs/outputs, as well as non-functional requirements around performance, interfaces, and user factors. It also validates that requirements are correct, consistent, complete, and testable.
Non-functional requirements specify system quality attributes such as performance, security, business considerations, configuration, operations, and enhancement capabilities. Performance attributes include efficiency, throughput, and scalability. Security attributes include security, privacy, and accountability. Business attributes include cost, adaptability, extensibility, and replaceability. Configuration attributes include configurability, integrability, portability, and deployability. Operations attributes include availability, fault tolerance, maintainability, monitorability, and alerting. Enhancement attributes include understandability, analyzability, and learnability.
The quality of software systems may be expressed as a collection of Software Quality Attributes. When the system requirements are defined, it is essential also to define what is expected regarding these quality attributes, since these expectations will guide the planning of the system architecture and design.
Software quality attributes may be classified into two main categories: static and dynamic. Static quality attributes are the ones that reflect the system’s structure and organization. Examples of static attributes are coupling, cohesion, complexity, maintainability and extensibility. Dynamic attributes are the ones that reflect the behavior of the system during its execution. Examples of dynamic attributes are memory usage, latency, throughput, scalability, robustness and fault-tolerance.
Following the definitions of expectations regarding the quality attributes, it is essential to devise ways to measure them and verify that the implemented system satisfies the requirements. Some static attributes may be measured through static code analysis tools, while others require effective design and code reviews. The measuring and verification of dynamic attributes requires the usage of special non-functional testing tools such as profilers and simulators.
In this talk I will discuss the main Software Quality attributes, both static and dynamic, examples of requirements, and practical guidelines on how to measure and verify these attributes.
The document discusses quality attributes that are important factors in software engineering. It defines quality attributes as the degree to which software possesses desired characteristics like reliability, interoperability. Architecture alone cannot achieve qualities - it must consider factors for each attribute. Common quality attributes are grouped into design, runtime, system, user, non-runtime, architecture, and business qualities. Examples of attributes discussed include maintainability, performance, security, availability, testability and usability. Quality attributes are assessed using scenarios describing stimuli, environment, system response and measures.
This document provides an overview of an active workshop on functional specifications and use cases. It discusses the purpose of the workshop, which is to introduce a simple, practical, and precise methodology for writing functional specifications for software systems. The workshop agenda is then outlined, which will cover requirements, the use case model, a case study, system and software use cases, and use case realization. Finally, some basic concepts that will be covered in the workshop like stakeholders, actors, use cases, and use case diagrams are introduced at a high level.
SharePoint Server and Windows 2008 And SQL 2008 with Joel Oleson and Todd KlindtJoel Oleson
Learn what's new in Windows 2008 and SQL 2008 that SharePoint Admins should care about. These are the killer new features that will help you justify the upgrade or help you know what to investigate and validate by Joel Oleson and Todd Klindt.
The document discusses quality attributes that affect system design. It identifies four types of quality attributes: runtime system qualities, non-runtime system qualities, business qualities, and architecture qualities. Runtime system qualities include functionality, performance, security, and usability. Non-runtime qualities include modifiability, portability, reusability, and testability. Business qualities are cost and marketability. Architecture qualities are integrity and correctness. The document emphasizes that as an architect, understanding how design choices impact these quality attributes is important.
Quality Attributes In Software Architecture & Design PatternsGatte Ravindranath
Quality Attributes Topic from Software Architecture $ Design patterns in the relation to software product or any engineering architecture development process needs required by an architect.
1. Requirements analysis identifies customer needs, evaluates feasibility, and establishes system definitions and specifications. It bridges the gap between requirements engineering and system design.
2. Requirements analysis has several phases including problem recognition, evaluation and synthesis of possible solutions, help modeling, and writing definitions and specifications. It also considers management questions around effort, roles, challenges, and costs.
3. Requirements analysis determines functional requirements describing system behavior and inputs/outputs, as well as non-functional requirements around performance, interfaces, and user factors. It also validates that requirements are correct, consistent, complete, and testable.
Non-functional requirements specify system quality attributes such as performance, security, business considerations, configuration, operations, and enhancement capabilities. Performance attributes include efficiency, throughput, and scalability. Security attributes include security, privacy, and accountability. Business attributes include cost, adaptability, extensibility, and replaceability. Configuration attributes include configurability, integrability, portability, and deployability. Operations attributes include availability, fault tolerance, maintainability, monitorability, and alerting. Enhancement attributes include understandability, analyzability, and learnability.
This document discusses scenarios for evaluating business and architectural quality attributes in software systems. For business qualities like time-to-market and cost/benefits, it provides example scenarios that describe the stimulus, artifacts, environment, system response, and how to measure the response. For architectural qualities like conceptual integrity, correctness/completeness, and buildability, it notes that these attributes are more difficult to capture in scenarios since they depend on multiple phases of development and involve complex relationships between components, teams, and available tools.
The document discusses software requirements and requirements engineering. It introduces concepts like user requirements, system requirements, functional requirements, and non-functional requirements. It explains how requirements can be organized in a requirements document and the different types of stakeholders who read requirements. The document also discusses challenges in writing requirements precisely and provides examples of requirements specification for a library system called LIBSYS.
The document discusses non-functional requirements (NFRs), including what they are, when they can be used, how acceptance criteria support NFRs, and NFR elicitation. It provides examples of functional vs. non-functional requirements for a fictional "Batmobile" project. It also discusses how Twitter failed to adequately plan for scalability, a common non-functional requirement. Finally, it shares examples of common NFRs like usability, reliability, performance, and maintainability.
Quality attributes in software architectureGang Tao
This document discusses various quality attributes in software architecture including responsiveness, scalability, usability, security, accessibility, serviceability, extensibility, distributability, maintainability, portability, reliability, testability, and compatibility. For each attribute, it provides definitions and considerations for how to achieve that attribute in architecture and design. It also discusses relationships between attributes and references quality models for evaluating software.
Critical System Validation in Software Engineering SE21koolkampus
The document discusses techniques for validating critical systems, with a focus on validating safety and reliability. Static validation techniques include design reviews and formal proofs, while dynamic techniques involve testing. Reliability validation uses statistical testing against an operational profile to measure reliability. Safety validation aims to prove a system cannot reach unsafe states, using techniques like safety proofs, hazard analysis, and safety cases presenting arguments about risk levels. The document also provides an example safety validation of an insulin pump system.
This document provides an introduction to complex system engineering. It defines what a system is, including that a system is more than the sum of its parts due to the relationships and interactions between parts. It also defines systems engineering as an interdisciplinary approach to satisfying customer needs throughout the lifecycle. Key aspects of systems engineering covered include requirements management, the iterative nature of the process, standard process models, and architecture modeling.
The document outlines the functional and non-functional requirements for designing a website. Functional requirements include following business rules, allowing transactions and corrections, having an external interface for users, complying with legal and regulatory standards, and providing authorization levels for users. Non-functional requirements include performance parameters like response time and throughput, recoverability so the system can recover from crashes, security measures to protect data, maintainability so the system can be maintained, and environmental compliance. The system should also have interoperability to work across different operating systems.
Requirements engineering involves analyzing user needs and constraints to define the services and limitations of a software system. It has several key steps:
1. Requirements analysis identifies stakeholders and understands requirements through client interviews to define both functional requirements about system services and non-functional constraints.
2. Requirements are documented in a requirements specification that defines what the system should do without describing how.
3. The document is validated through reviews and prototyping to ensure requirements accurately capture user needs before development begins.
The document defines an SRS as the official statement of what system developers should implement, providing a complete description of the system behavior. An SRS precisely defines the software product and is used to understand requirements to design the software. It includes the purpose, product scope, features, interfaces, and other functional and non-functional requirements. The SRS benefits include establishing agreement between customers and suppliers, reducing development effort, and providing a baseline for validation.
Software Requirements in Software Engineering SE5koolkampus
The document introduces software requirements and describes how they are used to define what a system should do. It explains that requirements can be functional or non-functional, and discusses how requirements are organized in documents. Requirements describe the services and constraints for the system from the perspectives of users and developers.
The document discusses requirements engineering for software systems. It introduces concepts like user requirements, system requirements, functional requirements and non-functional requirements. It explains the process of requirements analysis and specification. Requirements can be organized in a requirements document and must be specified precisely to avoid ambiguity. Both functional and non-functional requirements are important to define the key aspects of the system.
Depandability in Software Engineering SE16koolkampus
The document discusses key concepts related to dependability in critical systems, including reliability, availability, safety, and security. It defines each concept and explains how they are related but distinct. For example, reliability is the probability that a system operates as intended, while safety ensures a system can operate without threatening people or the environment. The document also outlines approaches for achieving dependability, such as avoiding faults, detecting and removing errors, and limiting damage from failures or attacks.
Requirement analysis involves understanding the application domain, required services, performance, and hardware limitations. There are functional requirements, specifying how the system should function, and non-functional requirements, which constrain the system's operation. Non-functional requirements include product requirements like performance, reliability, and security, as well as organizational and external requirements. Requirement analysis involves domain understanding, requirement collection, classification, conflict resolution, prioritization, and validation.
The presentation discusses software requirements and specifications. It defines user requirements as more abstract statements of what services the system should provide, while system requirements provide more detailed descriptions of the system's functions and constraints. Functional requirements describe what the system will do, including inputs, outputs, and business rules. Non-functional requirements describe emergent system properties like performance, availability, and security. Finally, a software requirements document formally specifies both the user and system requirements and serves as an agreement between developers and customers.
Software (requirement) analysis using umlDhiraj Shetty
The document discusses software requirement analysis for a hotel management system using UML. It describes creating requirement artifacts like use case models, class diagrams, sequence diagrams and activity diagrams. The use case model identifies key actors and elaborates use case scenarios for room reservation, room service, telephone service and billing. The document prioritizes top use cases and provides detailed use case specifications for making a reservation, corporate reservation and group reservation.
System Quality Attributes for Software ArchitectureAdnan Masood
Software Quality Attributes are the benchmarks that describe system’s intended behavior. These slides go through an overview of what some of these attributes are and how to evaluate them.
This document discusses functional and non-functional requirements. Functional requirements describe the behavior of a system and support user goals, while non-functional requirements describe how the system works and make it more usable. Functional requirements should include data descriptions, screen operations, workflows, and access controls. Non-functional requirements should cover usability, reliability, performance, and supportability. Non-functional requirements are further classified into categories like process, delivery, implementation, and external constraints.
This document discusses different types of software requirements. It outlines functional requirements that specify system behaviors and non-functional requirements that specify qualities like usability, reliability, and performance. Domain requirements capture characteristics specific to the application area. Inverse requirements specify what a system should not do. Design and implementation constraints provide guidelines for system development. Metrics are important for quantifying non-functional requirements so they can be objectively tested. Requirements should be explored from different perspectives and categorized to best inform system design and development.
6. FUNDAMENTALS OF SE AND REQUIREMENT ENGINEERING.pptPedadaSaikumar
This document discusses requirement engineering fundamentals including requirement elicitation, analysis, and system models. It defines what requirements are, describes different types of requirements like user requirements, system requirements, functional requirements, and non-functional requirements. It also discusses requirements engineering processes like requirements elicitation and analysis, specification, validation, and the use of system models. Key activities in requirements engineering include establishing customer needs, specifying services and constraints, and generating requirements descriptions.
Unit tests are great, they help a developer gain control over his code and catch bugs and regression issues.
Test Driven Development is a methodology that uses unit tests but it's not about writing unit tests - in fact the tests are only a design tool.
TDD is a methodology that solves problems in an iterative way, it's about emergent design that creates a maintainable solution.
In this session I'll talk about common mistakes and misconceptions, how to benefit from TDD and show how to design your code using unit tests.
The code for this talk can be found on GitHub: https://github.com/dhelper/DesignWIthTests
Adaptive Object Model - IASA IL Meeting on Software Evolution (3/2014)Atzmon Hen-Tov
Lecture on AOM (Adaptive-Object-Model) in the IASA Israel meeting held on April 2, 2014.
The animated version -
http://prezi.com/vjfqz2rth7ct/?utm_campaign=share&utm_medium=copy&rc=ex0share
This document discusses scenarios for evaluating business and architectural quality attributes in software systems. For business qualities like time-to-market and cost/benefits, it provides example scenarios that describe the stimulus, artifacts, environment, system response, and how to measure the response. For architectural qualities like conceptual integrity, correctness/completeness, and buildability, it notes that these attributes are more difficult to capture in scenarios since they depend on multiple phases of development and involve complex relationships between components, teams, and available tools.
The document discusses software requirements and requirements engineering. It introduces concepts like user requirements, system requirements, functional requirements, and non-functional requirements. It explains how requirements can be organized in a requirements document and the different types of stakeholders who read requirements. The document also discusses challenges in writing requirements precisely and provides examples of requirements specification for a library system called LIBSYS.
The document discusses non-functional requirements (NFRs), including what they are, when they can be used, how acceptance criteria support NFRs, and NFR elicitation. It provides examples of functional vs. non-functional requirements for a fictional "Batmobile" project. It also discusses how Twitter failed to adequately plan for scalability, a common non-functional requirement. Finally, it shares examples of common NFRs like usability, reliability, performance, and maintainability.
Quality attributes in software architectureGang Tao
This document discusses various quality attributes in software architecture including responsiveness, scalability, usability, security, accessibility, serviceability, extensibility, distributability, maintainability, portability, reliability, testability, and compatibility. For each attribute, it provides definitions and considerations for how to achieve that attribute in architecture and design. It also discusses relationships between attributes and references quality models for evaluating software.
Critical System Validation in Software Engineering SE21koolkampus
The document discusses techniques for validating critical systems, with a focus on validating safety and reliability. Static validation techniques include design reviews and formal proofs, while dynamic techniques involve testing. Reliability validation uses statistical testing against an operational profile to measure reliability. Safety validation aims to prove a system cannot reach unsafe states, using techniques like safety proofs, hazard analysis, and safety cases presenting arguments about risk levels. The document also provides an example safety validation of an insulin pump system.
This document provides an introduction to complex system engineering. It defines what a system is, including that a system is more than the sum of its parts due to the relationships and interactions between parts. It also defines systems engineering as an interdisciplinary approach to satisfying customer needs throughout the lifecycle. Key aspects of systems engineering covered include requirements management, the iterative nature of the process, standard process models, and architecture modeling.
The document outlines the functional and non-functional requirements for designing a website. Functional requirements include following business rules, allowing transactions and corrections, having an external interface for users, complying with legal and regulatory standards, and providing authorization levels for users. Non-functional requirements include performance parameters like response time and throughput, recoverability so the system can recover from crashes, security measures to protect data, maintainability so the system can be maintained, and environmental compliance. The system should also have interoperability to work across different operating systems.
Requirements engineering involves analyzing user needs and constraints to define the services and limitations of a software system. It has several key steps:
1. Requirements analysis identifies stakeholders and understands requirements through client interviews to define both functional requirements about system services and non-functional constraints.
2. Requirements are documented in a requirements specification that defines what the system should do without describing how.
3. The document is validated through reviews and prototyping to ensure requirements accurately capture user needs before development begins.
The document defines an SRS as the official statement of what system developers should implement, providing a complete description of the system behavior. An SRS precisely defines the software product and is used to understand requirements to design the software. It includes the purpose, product scope, features, interfaces, and other functional and non-functional requirements. The SRS benefits include establishing agreement between customers and suppliers, reducing development effort, and providing a baseline for validation.
Software Requirements in Software Engineering SE5koolkampus
The document introduces software requirements and describes how they are used to define what a system should do. It explains that requirements can be functional or non-functional, and discusses how requirements are organized in documents. Requirements describe the services and constraints for the system from the perspectives of users and developers.
The document discusses requirements engineering for software systems. It introduces concepts like user requirements, system requirements, functional requirements and non-functional requirements. It explains the process of requirements analysis and specification. Requirements can be organized in a requirements document and must be specified precisely to avoid ambiguity. Both functional and non-functional requirements are important to define the key aspects of the system.
Depandability in Software Engineering SE16koolkampus
The document discusses key concepts related to dependability in critical systems, including reliability, availability, safety, and security. It defines each concept and explains how they are related but distinct. For example, reliability is the probability that a system operates as intended, while safety ensures a system can operate without threatening people or the environment. The document also outlines approaches for achieving dependability, such as avoiding faults, detecting and removing errors, and limiting damage from failures or attacks.
Requirement analysis involves understanding the application domain, required services, performance, and hardware limitations. There are functional requirements, specifying how the system should function, and non-functional requirements, which constrain the system's operation. Non-functional requirements include product requirements like performance, reliability, and security, as well as organizational and external requirements. Requirement analysis involves domain understanding, requirement collection, classification, conflict resolution, prioritization, and validation.
The presentation discusses software requirements and specifications. It defines user requirements as more abstract statements of what services the system should provide, while system requirements provide more detailed descriptions of the system's functions and constraints. Functional requirements describe what the system will do, including inputs, outputs, and business rules. Non-functional requirements describe emergent system properties like performance, availability, and security. Finally, a software requirements document formally specifies both the user and system requirements and serves as an agreement between developers and customers.
Software (requirement) analysis using umlDhiraj Shetty
The document discusses software requirement analysis for a hotel management system using UML. It describes creating requirement artifacts like use case models, class diagrams, sequence diagrams and activity diagrams. The use case model identifies key actors and elaborates use case scenarios for room reservation, room service, telephone service and billing. The document prioritizes top use cases and provides detailed use case specifications for making a reservation, corporate reservation and group reservation.
System Quality Attributes for Software ArchitectureAdnan Masood
Software Quality Attributes are the benchmarks that describe system’s intended behavior. These slides go through an overview of what some of these attributes are and how to evaluate them.
This document discusses functional and non-functional requirements. Functional requirements describe the behavior of a system and support user goals, while non-functional requirements describe how the system works and make it more usable. Functional requirements should include data descriptions, screen operations, workflows, and access controls. Non-functional requirements should cover usability, reliability, performance, and supportability. Non-functional requirements are further classified into categories like process, delivery, implementation, and external constraints.
This document discusses different types of software requirements. It outlines functional requirements that specify system behaviors and non-functional requirements that specify qualities like usability, reliability, and performance. Domain requirements capture characteristics specific to the application area. Inverse requirements specify what a system should not do. Design and implementation constraints provide guidelines for system development. Metrics are important for quantifying non-functional requirements so they can be objectively tested. Requirements should be explored from different perspectives and categorized to best inform system design and development.
6. FUNDAMENTALS OF SE AND REQUIREMENT ENGINEERING.pptPedadaSaikumar
This document discusses requirement engineering fundamentals including requirement elicitation, analysis, and system models. It defines what requirements are, describes different types of requirements like user requirements, system requirements, functional requirements, and non-functional requirements. It also discusses requirements engineering processes like requirements elicitation and analysis, specification, validation, and the use of system models. Key activities in requirements engineering include establishing customer needs, specifying services and constraints, and generating requirements descriptions.
Unit tests are great, they help a developer gain control over his code and catch bugs and regression issues.
Test Driven Development is a methodology that uses unit tests but it's not about writing unit tests - in fact the tests are only a design tool.
TDD is a methodology that solves problems in an iterative way, it's about emergent design that creates a maintainable solution.
In this session I'll talk about common mistakes and misconceptions, how to benefit from TDD and show how to design your code using unit tests.
The code for this talk can be found on GitHub: https://github.com/dhelper/DesignWIthTests
Adaptive Object Model - IASA IL Meeting on Software Evolution (3/2014)Atzmon Hen-Tov
Lecture on AOM (Adaptive-Object-Model) in the IASA Israel meeting held on April 2, 2014.
The animated version -
http://prezi.com/vjfqz2rth7ct/?utm_campaign=share&utm_medium=copy&rc=ex0share
Technical debt is a metaphor for the gap between the current state of
a software system and its hypothesized ‘ideal’ state. One of the significant and
under-investigated elements of technical debt is documentation debt, which
may occur when code is created without supporting internal documentation,
such as code comments. Studies have shown that outdated or lacking
documentation is a considerable contributor to increased costs of software
systems maintenance. The importance of comments is often overlooked by
software developers, resulting in a notably slower growth rate of comments
compared to the growth rate of code in software projects. This research aims to
explore and better understand developers’ reluctance to document code, and
accordingly to propose efficient ways of using persuasive technology to
encourage programmers to document their code. The results may assist software
practitioners and project managers to control and reduce documentation debt.
The five expertise of a software architectLior Bar-On
The document discusses the five areas of expertise of a software architect:
1. Technology - Having strong technical skills including writing code, understanding technologies, and solving difficult problems.
2. Technical communication - Effectively communicating technical concepts to both technical and non-technical audiences.
3. Human communication - Having strong empathy, influencing, and communication skills to work with various teams.
4. Domain knowledge - Understanding the business domain including customers, competitors, and market factors.
5. Architectural methods - Applying design principles, patterns, and processes to software architecture.
The document summarizes a quality attribute workshop (QAW) method used by NASA and West Virginia University to systematically elicit software requirements from stakeholders. A QAW has eight steps: introductions, presentations on business/mission and architecture, identifying drivers, brainstorming scenarios, consolidating, prioritizing, and refining scenarios. The goal is to gather stakeholders to discuss desired system features, create scenarios around quality attributes, and document requirements.
Quality attributes in software architectureHimanshu
The document discusses software quality attributes and how they relate to software architecture. It defines quality attributes as factors that affect runtime behavior, system design, and user experience. It outlines common quality attributes including design qualities, runtime qualities, system qualities, and more. For each category, it provides examples of specific attributes like reliability, performance, usability, and maintainability. It includes diagrams to illustrate how quality attributes are defined in scenarios and how they can be measured. The document aims to explain how architecture should support and enable achieving various quality goals.
Title: The Role of the Software Architect
Speaker: Hayim Makabee, co-founder of the Israeli Chapter of the International Association of Software Architects (IASA)
Abstract:
In this talk Hayim will present the practical aspects of the role of the Software Architect, including:
- The four areas of expertise: Design, Domain, Technology and Methodology.
- The cooperation with stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.
Understanding the expected areas of expertise is essential for the architect to develop his/her professional skills.
Understanding how to cooperate with the diverse stakeholders is essential to improve the architect's impact and effectiveness.
This document discusses test-driven development (TDD) and its importance for software development. It notes that TDD is not just about unit testing code, but is a key part of software craftsmanship. When practicing TDD, tests should be written from the perspective of understanding by business analysts and customers, not just for code implementation. TDD promotes a short feedback loop to continually refine code through testing. Examples provided demonstrate how to use TDD for a FizzBuzz coding exercise by first writing tests to define requirements and then coding to pass those tests.
Quality attributes testing. From Architecture to test acceptanceIT Weekend
This document summarizes an expert's experience and qualifications in software architecture and automation testing, including 8 years of IT experience and a PhD in IT automation testing. It then discusses what software architecture is, how it is formed based on business, users and systems, and what quality attributes and acceptance criteria can be tested. Finally, it provides an example of defining acceptance criteria for a software error scenario using a specific methodology and tools.
July 2013 Talk, What Industry Needs from Architecture Description Languagesgrossd18
This document summarizes the results of an international survey on what industry needs from architectural description languages (ADLs). The survey found that practitioners need ADLs to be flexible and customizable to support different domains, projects and problems. ADLs also need to effectively communicate architectural information to both technical and non-technical stakeholders. Additionally, ADLs must provide good support for defining and analyzing extra-functional properties of software architectures. The survey indicates next-generation ADLs and tools should enable seamless adaptation, reuse, analysis and ensure traceability between architecture and other artifacts.
Hierarchical Composable Optimization of Web PagesHayim Makabee
Hierarchical Composable Optimization of Web Pages proposes FAME, a framework that models web pages as hierarchical and composable structures. FAME defines interfaces for operators like fetch, choice, and map to optimize page elements. It separates optimization from content creation and constraints to allow independent experimentation by algorithms. The framework instruments pages to provide real-time feedback and aims to enable agile experimentation across a variety of generated digital media experiences.
An Event-Driven Approach for the Separation of ConcernsHayim Makabee
This document proposes an event-driven approach for separating concerns in software. It defines separation of concerns as decomposing a system into parts that overlap as little as possible. It presents an event-driven programming framework called EventJ that uses events, event handlers, and an event dispatcher to separate cross-cutting concerns. Compared to object-oriented and aspect-oriented programming, the event-driven approach better supports encapsulation, inheritance, loose coupling, extensibility, reusability, and concurrency. It provides a methodology for identifying concerns that can be separated and triggering events to move the code to independent event handlers.
Introduction to Event Sourcing and CQRS (IASA-IL)Vladik Khononov
Slides for my "Introduction to Event Sourcing and CQRS" session at the IASA-IL meeting.
Abstract:
Event sourcing is a pattern for modeling the application’s business logic. It states that all changes to application state should be defined and stored as a sequence of events.
Its advantages are many:
* Gives freedom to refactor the business logic, allowing better response to new requirements.
* Suitable for building scalable, highly concurrent, distributed systems.
* Stored events give the true history of a system, which is required by law in some industries.
* The system’s state can be reversed to any point in the past for retroactive debugging.
* The required infrastructure is simple - no monstrous databases are involved.
Vladik will also describe CQRS, an architecture that goes hand in hand with Event Sourcing.
In this lecture I will present a unified Agile process and techniques that allow for a seamless transition from the system engineering level to the SW engineering level in an iterative and evolutionary way. I will also show the benefits the unifying the processes of the two levels and of the resulting component based architecture. I will also talk on the architect’s role and this role evolves over time and will conclude with presenting a small but real life project example.
How to extend the shelf life of software and enable long-lived, adaptable software architectures.
Herzliya - July 2015 @
ILTAM - Israeli Users' Association of Advanced Technologies in Hi-Tec Integrated Systems
IASA - International Association of Software Architects
Watch-It-Next: A Contextual TV Recommendation SystemRaz Nissim
This document describes a contextual TV recommendation system called Watch-It-Next that provides recommendations for shared smart TV devices. It uses the program currently being watched as contextual information to infer who is likely watching and narrow the recommendations. It presents a technique called "3-Way" that learns a standard matrix factorization model and scores recommendation candidates based on their agreement with both the device and context item vectors, without changing the learning algorithm. An evaluation on a large dataset of TV viewing data found the contextual recommendations outperformed non-contextual baselines, indicating the current context helps disambiguate who is watching on shared devices.
The concept of Antifragility was introduced by Nassim Taleb to describe systems that benefit from impacts and volatility.
In this talk we will discuss how this concept may be applied in the field of Software Design with the goal of developing Change-Resilient Systems.
In particular we will address two patterns which frequently appear in Antifragile systems:
1) The Barbell Strategy and the importance of the separation between high-level abstract elements and concrete implementation details.
2) The Componentization Strategy and its applications in SOA, Microservices and Software Product Lines.
The Role of the Software Architect (short version)Hayim Makabee
Talk at the First Israeli Conference on Software Architecture
http://www.iltam.org/sw-arch2014/
Abstract:
In this talk Hayim will present the practical aspects of the role of the Software Architect, including the architect's contribution at the diverse stages of the software development life cycle, and the cooperation with the diverse stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.
Bio: Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Research Engineer at Yahoo! Labs Haifa. He is also a co-founder of the International Association of Software Architects in Israel.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
The document describes the system architecture for an augmented cognition system. It includes sensors that assess cognitive state, a cognitive state assessor that analyzes sensor data, and various components that select and sequence tasks or switch modalities based on the assessed cognitive state. The goal is to maximize operator performance by detecting and mitigating cognitive overload. It provides details on the sensors used, cognitive state gauges, mitigation strategies like pacing and task sequencing, and how tasks are selected and routed through the system.
The document discusses use case diagrams and their components. It defines key terms like actors, use cases, and relationships between use cases. It explains that use case diagrams model interactions between actors and a system, and capture the system's functional requirements. Diagrams show actors outside the system boundary and use cases inside it. Relationships like "include", "extend", and "generalization" define relationships between use cases. The document provides examples and guidelines for creating use case specifications that describe use case scenarios in detail.
This is chapter 1 of ISTQB Specialist Performance Tester certification. This presentation helps aspirants understand and prepare the content of the certification.
This document summarizes a software engineering solved paper from June 2013. It discusses various topics in software engineering including attributes of good software, definitions of software engineering and different types of software products, emergent system properties with examples, critical systems and their types, the Rational Unified Process (RUP) methodology with block diagrams, security terminology, and metrics for specifying non-functional requirements. The requirement engineering process is also explained with the main goal being to create and maintain a system requirement document through various sub-processes like feasibility study, elicitation and analysis, validation, and management of requirements.
Platform Observability “is when you infer the internal state of a system only by observing the data it generates, such as logs, metrics, and traces”. When observability is implemented well, a system will not require operations teams to spend much effort on understanding its internal state.
Automated Discovery of Performance Regressions in Enterprise ApplicationsSAIL_QU
This document summarizes the author's research on automated discovery of performance regressions in enterprise applications. It discusses challenges with current performance verification practices, and proposes approaches at the design and implementation levels. At the design level, it suggests using layered simulation models to evaluate design changes early. At the implementation level, it presents techniques to analyze large performance datasets, detect regressions while limiting subjectivity, and deal with tests in heterogeneous environments. Case studies show the approaches achieve 75-100% precision and 52-80% recall. The research aims to help analysts efficiently identify performance regressions.
Chapter 3 - Performance Testing in the Software LifecycleNeeraj Kumar Singh
The document discusses performance testing activities across different software development lifecycles. It describes how performance testing should be conducted iteratively throughout sequential development models, with testing at each stage from concept to acceptance. For iterative models, performance testing is also iterative and can be part of continuous integration. Specific activities discussed include test planning, monitoring, analysis, design, implementation, execution and completion. Performance risks are also discussed for different architectures.
What Is Machine Learning?
Where do we deploy machine learning and what software and cloud services are out there to support it?
What are the trends in deploying these systems and what are the benefits for IT?
Do you have a IoT Machine Learning Case Study in the Cloud?
Softwarearchitecture in practice unit1 2sush-sushma
The document discusses software architecture, including quality attributes, architectural patterns and styles, tactics to achieve qualities, and designing architecture. It covers key topics like quality attribute scenarios, tactics for qualities like availability and modifiability, and how architectural patterns implement tactics. It emphasizes that architecture provides the foundation for achieving quality attributes through appropriate design decisions and tactics.
System Simulation and Modelling with types and Event SchedulingBootNeck1
System simulation and modelling involves creating models of real-world systems and using those models to simulate and analyze the performance of existing or proposed systems. A system consists of interrelated components that work together towards a common goal. Simulation is the process of using a model to study the performance of a system over time or space. Modelling involves creating a model that represents a system, while simulation operates that model. Simulation can be used across various domains like healthcare, engineering, and military applications. It provides advantages like testing changes without impacting real systems and identifying constraints.
A Runtime Evaluation Methodology and Framework for Autonomic SystemsIDES Editor
An autonomic system provides self-adaptive ability
that enables system to dynamically adjust its behavior on
environmental changes or system failure. Fundamental
process of adaptive behavior in an autonomic system is consist
of monitoring system or/and environment information,
analyzing monitored information, planning adaptation policy
and executing selected policy. Evaluating system utility is
one of a significant part among them. We propose a novel
approach on evaluating autonomic system at runtime. Our
proposed method takes advantage of a goal model that has
been widely used at requirement elicitation phase to capture
system requirements. We suggest the state-based goal model
that is dynamically activated as the system state changes. In
addition, we defined type of constraints that can be used to
evaluate goal satisfaction level. We implemented a prototype
of autonomic computing software engine to verity our proposed
method. We simulated the behavior of the autonomic
computing engine with the home surveillance robot scenario
and observed the validity of our proposed method
Functional Safety in ML-based Cyber-Physical SystemsLionel Briand
This document discusses verification and validation of machine learning systems used in cyber-physical systems. It presents research on developing practical and scalable techniques to systematically verify the safety of deep neural network-based systems. The goals are to efficiently test for safety violations and explain any violations found to enable risk assessment. The document outlines challenges in verifying DNN components and proposes focusing on testing entire DNN-based systems. It reviews existing work and identifies limitations, such as focusing only on single images rather than scenarios involving object dynamics. Standards like ISO 26262 and SOTIF that require testing under different environmental conditions are also discussed. Explanations of any misclassifications found during testing are important for interpreting results and performing risk analysis.
A SIMULATION APPROACH TO PREDICATE THE RELIABILITY OF A PERVASIVE SOFTWARE SY...Osama M. Khaled
This document discusses simulating a pervasive software system to predict its reliability. It begins by introducing pervasive computing and its importance. It then describes the reference architecture model, which includes a smart environment conceptual model, smart object model, and pervasive system architecture model. The document outlines the simulation approach, including scenarios, specifications of simulation entities, assumptions, and extreme assumptions. The simulation aims to predict reliability and availability under different scenarios and control variable values. Key metrics like MTBF and MTTR will be measured to calculate reliability and availability.
This is chapter 4 of ISTQB Specialist Performance Tester certification. This presentation helps aspirants understand and prepare the content of the certification.
This document describes a proposed Applicant Qualification Filtering System that uses tests and a weighted-sum calculation method to rank and shortlist job applicants for employers. The system would have applicants complete personality, aptitude, and skills tests. It would calculate scores for each test component, weight them, and total the scores to generate an overall percentage for each applicant. Applicants would be ranked based on their scores, and employers could view a shortlist of the highest scoring candidates to interview. The document outlines the system's introduction, problem statement, objectives, process model, data model, solution complexity involving the weighted-sum method, proof of concept, and references.
The document discusses requirements modeling and analysis modeling in software engineering. It provides information on:
1) The different types of models that can be created during requirements modeling, including requirements models, design models, scenario-based models, data models, class-based models, flow-oriented models, and behavioral models.
2) The purposes of requirements modeling, which include representing customer requirements, gaining a better understanding of the system, and providing information to help with system design and development.
3) Key principles of requirements modeling, such as representing the information, functional, and behavioral domains of the system and partitioning models in a layered/hierarchical way.
4) Specific modeling techniques like scenario-based modeling, data
Introduction to simulation and modeling will describe what is simulation, what is system and what is model. It will give a brief overview of simulation and modeling in computer science.
Automated Testing of Autonomous Driving Assistance SystemsLionel Briand
This document discusses automated testing techniques for autonomous driving assistance systems (ADAS). It proposes using decision tree classification models and a multi-objective genetic search algorithm (NSGAII) to efficiently explore the complex scenario space of ADAS. The objectives are to identify critical, failure-revealing test scenarios by characterizing input conditions that lead to safety violations, such as the car hitting a pedestrian. Simulator-based testing of the automated emergency braking system is computationally expensive, so decision trees provide better guidance to the search by partitioning the input space into homogeneous regions.
The document discusses the Unified Modeling Language (UML) and use case modeling. UML was developed to provide modeling languages for software design including use case diagrams, class diagrams, and other diagrams. It describes the typical phases of system development like requirements analysis, design, implementation, and testing. It then focuses on use case modeling, explaining what a use case is, how to identify actors and use cases, and how to describe use cases. Examples of use case diagrams are provided for different systems like an ATM machine and counseling.
Performance evaluation of a multi-core system using Systems development meth...Yoshifumi Sakamoto
I propose to apply Systems development method utilizing Reverse modeling and Model-based Simulation(SRMS), in order to solve the issues of derivational development. Derivational development is a development method for developing derived products based on products already been released. Many organizations developing embedded system have been applying derivational development to improve development efficiency, time-to-market, and product quality.
However, applying derivational development to large-scale embedded systems in a traditional way to performanec requirements of higher functionality is of high risk. In addition, as requirements of embedded systems for dependability are extremely high, the dependability of development process and safety of the product must be proven by evidence. Therefore, there is a possibility to significantly inhibit the evidence of dependability on embedded systems by continuing derivational development over many years. We apply SRMS in order to solve these issues.
In this presentation, I propose a methodology to solve issues of derivational development by applying SRMS to an SoC Equipped Multi Function Peripheral/Printer. Performance evaluation and energy consumption estimation of SoC are performed in the early stages of the SoC development. Estimating the performace and the energy consumption by a high level of abstraction model-based simulation. Because at the early stages of SoC development, modeling with a high level of abstraction is required for both the system architecture of the SoC and the behavior of the System.
The proposed method is applied for an actual embedded system in an MFP - Multi Function Peripheral/Printer. Proposed method SRMS is promising to solve the issues of derivational developmnrt in the embedded system development.
Similar to Extracting Quality Scenarios from Functional Scenarios (20)
There is a system out there! SW Engineering Education from Programming to Eng...Prof. Amir Tomer
This document discusses the challenges of software engineering education and proposes ways to improve it. It suggests extending the sustainability range from employment to career development; extending practice from programming and design to business and management; extending the software lifecycle from design-code-test to deploy-validate-maintain-reuse; extending scope from software to entire systems; and extending the profession from software engineering to software-intensive systems engineering. It emphasizes incorporating more real-world experience, career development, business skills, and systems thinking into software engineering education to better prepare students and address industry needs.
This document discusses software modeling from a system perspective. It defines key concepts such as a system, system element, and block. A system is composed of interacting elements organized to achieve a purpose. A system element may itself be a system or an atomic entity. The document recommends using unified modeling concepts like "block" to represent a system, subsystem, component or other entity. It presents different modeling views including context, services, structure and behavior, and discusses modeling techniques like use case diagrams, activity diagrams and more.
This document discusses how software affects system development from the perspective of software-intensive systems engineering. It begins by explaining that most systems today have software as an essential component, as software contributes to their design, construction, operation, and evolution. It then provides examples of how software influences system operation through its unique mathematical properties and vulnerability, as well as impacting system design through different development lifecycles and challenges of bring your own device integration. The document concludes by arguing that systems engineering and software engineering must work together through common standards, modeling languages, lifecycle models, and education.
The document proposes a methodological approach to modeling software-intensive systems. It defines a "block" as a unified concept for systems and elements at any level, with properties of purpose, elements, interaction, and organization. It describes modeling the system across four views - environment, services, structure, and behavior - and at different phases of a systems engineering process, including requirements analysis, functional analysis, and design synthesis. The approach aims to provide consistency within and between models of the system at different levels.
This document outlines an agenda for a seminar on methodological and effective system modeling with UML/SysML. The seminar will introduce principles of effective system modeling and useful modeling elements in UML and SysML. It will demonstrate applying a methodological modeling approach to computer embedded systems using a case study. The agenda includes topics such as modeling in systems engineering, modeling systems and blocks, modeling different views of a block, modeling in the system development life cycle, and modeling computer embedded systems.
Cost Effectiveness of Software Reuse AlternativesProf. Amir Tomer
A half-day tutorial presented at ISEC 2008, Hyderabad, India.
Based on the IEEE TSE paper:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1324647
This presentation was presented at IEEE SwSTE 2012 conference.
Link to publication: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6236617
This presentation describes a course on Software Project Management developed by the author. The course combines the general project management standard PMBOK® with specific software engineering practices.
Link to paper: http://www.cs.technion.ac.il/~tomera/publications/Tomer_EDUCON_2014_V02.pdf
Applying system thinking to model-based software engineeringProf. Amir Tomer
This presentation describes a Software Engineering academic course which was developed by the author and was taught ~50 times in various institutes. The course is based on the approach that software development must be done from a system perspective.
Link to paper: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6201185
How Can Hiring A Mobile App Development Company Help Your Business Grow?ToXSL Technologies
ToXSL Technologies is an award-winning Mobile App Development Company in Dubai that helps businesses reshape their digital possibilities with custom app services. As a top app development company in Dubai, we offer highly engaging iOS & Android app solutions. https://rb.gy/necdnt
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemPeter Muessig
Learn about the latest innovations in and around OpenUI5/SAPUI5: UI5 Tooling, UI5 linter, UI5 Web Components, Web Components Integration, UI5 2.x, UI5 GenAI.
Recording:
https://www.youtube.com/live/MSdGLG2zLy8?si=INxBHTqkwHhxV5Ta&t=0
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
UI5con 2024 - Bring Your Own Design SystemPeter Muessig
How do you combine the OpenUI5/SAPUI5 programming model with a design system that makes its controls available as Web Components? Since OpenUI5/SAPUI5 1.120, the framework supports the integration of any Web Components. This makes it possible, for example, to natively embed own Web Components of your design system which are created with Stencil. The integration embeds the Web Components in a way that they can be used naturally in XMLViews, like with standard UI5 controls, and can be bound with data binding. Learn how you can also make use of the Web Components base class in OpenUI5/SAPUI5 to also integrate your Web Components and get inspired by the solution to generate a custom UI5 library providing the Web Components control wrappers for the native ones.
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
Drona Infotech is a premier mobile app development company in Noida, providing cutting-edge solutions for businesses.
Visit Us For : https://www.dronainfotech.com/mobile-application-development/
Using Query Store in Azure PostgreSQL to Understand Query PerformanceGrant Fritchey
Microsoft has added an excellent new extension in PostgreSQL on their Azure Platform. This session, presented at Posette 2024, covers what Query Store is and the types of information you can get out of it.
Energy consumption of Database Management - Florina Jonuzi
Extracting Quality Scenarios from Functional Scenarios
1. Dr. Amir Tomer, PMP, CSEP
Head of Department
Software and Information Systems Engineering
amir@amirtomer.com
2. Quality Attributes
Quality Attributes & Constraints
(Non-functional Requirements)
• Define the solution quality
– How well does the system carry out its
functional requirements?
• Performance
• Availability
• Security
• Interoperability
• …
Functional Requirements
• Define the solution contents
– What is the system required to
do?
Quality Attributes & Constraints
Design /
Implementation
Functional Requirements
Solution Domain
Dr. Amir Tomer, ISQ Conference, 2014 2 Extracting Quality Scenarios from Functional Scenarios
3. The Conflict
• System specifications concentrate mainly on functional
requirements
– They describe the purpose of the system
– They are conceptual (implementation-free)
– They remain valid even when quality attributes change
Whereas…
• The system architecture is driven mainly by quality attributes, e.g.
– Using redundancy to improve availability
– Using load-balancing to improve performance
– Using fire walls to improve security
– …
These do not affect the
basic functionality,
but may impose
additional functionality to
provide quality
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 3 Quality Scenarios from Functional Scenarios
4. Car Navigation System
Define Trip
Locate Self
Send Report
Driver
Navigate along
Route
Maps Provider
Get Map
Get Road Status
GPS
Deviation from
Route
Reports Provider
Calculate Route
«include»
«include»
«include»
«include»
«include»
«include»
«extend»
Use Cases as Functional Scenarios
• Functional Scenarios are often specified as Use Cases
• A Use Case is a service (function) performed by a system through interaction with a set
of external Actors, of two kinds
– Primary Actors, who initiate Use Cases to achieve their goals
– Supporting Actors, with whom the system interacts for accomplishing the Primary
Actors’ goal
• UML’s Use Case Diagram depicts the set
of Use Cases within a system and their
associated Actors
• A single Use Case may have various scenarios,
but these are not depicted in the
Use Case Diagram
Example:
Use Case Diagram of a
Car Navigation System
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 4 Quality Scenarios from Functional Scenarios
5. Use Case Specifications (Functional Scenarios)
• The various courses of interaction through a certain Use Case are captured in
a Use Case Specification, which comprises the following ingredients:
UC-# UC Name
Actors & Goals Primary actors and their stated goals
Supporting actors and their roles
Other
Stakeholders
Stakeholders that are not actors and their interests (business benefits, quality attributes) in this
specific UC
Pre-conditions Conditions/presumptions which must hold to enable the use case
Post-Conditions Desirable (success) results after use case completion
Trigger The event (either by a primary actor or by the system itself) that “starts-up” the UC
Main Success
Scenario (MSS)
A set of steps which describe the “most straightforward” interaction to achieve the post-conditions
Branches Other possible scenarios which may lead either to success (alternatives) or failure (exceptions)
in fulfilling the post-conditions
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 5 Quality Scenarios from Functional Scenarios
6. Functional Analysis and Functional Architecture
• From the system’s point of view, a functional scenario is a sequence of
applying system functions
• Functional Analysis is the process of identifying system functions and
allocating each function to one or more functional components
• The set of functional components, their internal and external interface can be
considered as Functional Architecture
• For example, let us consider a simple car navigation system, arranged in a
client-server architecture, as follows:
Car Unit Maps & Reports Server
GPS Satellite
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 6 Quality Scenarios from Functional Scenarios
7. Functional Scenario – Example
• A typical Main Success Scenario (MSS) of the “Navigate Along
Route” use-case might look as follows:
Trigger The driver presses the “Start Navigation” button
Main Success Scenario
(MSS)
1. The system enters “Navigate” Mode
2. The system retrieves the pre-defined route (See “Define Trip” UC)
3. The system retrieves a relevant map area
4. If the locally stored map data is missing – the system downloads map data from the
server
5. The system displays the map and route
6. The system gets the current location from the GPS
7. If the location is off route – the system re-calculates the route (See “Calculate Route” UC)
8. Back to step 4
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 7 Quality Scenarios from Functional Scenarios
8. Functional Analysis and Functional Architecture – Example
• Applying the Functional Analysis process to the navigation scenario
might yield the following functional architecture:
GPS Signals
User
Commands
User
Displays
Locator
GUI
Map
Download
Nav igation App
Map Serv ices
Allocated Function
(Extracted from the
functional scenario):
“download map data
from the server”
Maps
Location
Commands
Displays
Static Binding
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 8 Quality Scenarios from Functional Scenarios
9. Quality Scenarios*
• Quality Scenarios specify how to prevent
a fault from becoming a failure
*Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, 3rd Edition, Addison-Wesley, 2012
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 9 Quality Scenarios from Functional Scenarios
10. Relations between Functional Scenarios and Quality Scenarios
• Quality scenarios do not stand by themselves
– They usually occur during functional scenarios
– Therefore it would be beneficial to associate the ingredients of quality
scenarios with those of functional scenarios (use cases) as follows:
• Actors
• Pre-conditions
• Trigger
• Main Success
Scenario
• Branches
– Alternatives
– Exceptios
• Post-conditions
Source •
Environment •
Stimulus •
Response •
Response Measurement •
Artifact •
Any system element
To which the relevant
Functionality is allocated
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 10 Quality Scenarios from Functional Scenarios
11. Discovering Quality Attributes in the Functional Scenario
• Quality attributes can be discovered in the functional scenarios by
applying the “how well?” questions to the functions in the scenario
– For example:
Trigger The driver presses the “Start Navigation” button
Main Success Scenario
(MSS)
Is the driver aware?
(usability)
1. The system enters “Navigate” Mode
2. The system retrieves the pre-defined route (See “Define Trip” UC)
3. The system retrieves a relevant map area
4. If the locally stored map data is missing – the system downloads map data from the
server
5. The system displays the map and route
6. The system gets the current location from the GPS
7. If the location is off route – the system re-calculates the route (See “Calculate Route” UC)
8. Back to step 4
Does the server respond
within TBD seconds?
(availability)
Is the location precise?
(performance)
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 11 Quality Scenarios from Functional Scenarios
12. Applying Response Tactics
• Regarding the server availability issue of the last example
– A stimulus (fault) occurs by getting no response from the server within TBD
seconds
– One of the tactics for handling availability is redundancy
• So the server may be multiplied
– This may add a branch (alternative) to the scenario, as follows:
Trigger The driver presses the “Start Navigation” button
Main Success Scenario
(MSS)
1. The system enters “Navigate” Mode
2. The system retrieves the pre-defined route (See “Define Trip” UC)
3. The system retrieves a relevant map area
4. If the locally stored map data is missing – the system downloads map data from the
server
5. The system displays the map and route
6. The system gets the current location from the GPS
7. If the location is off route – the system re-calculates the route (See “Calculate Route” UC)
8. Back to step 4
Branch A Alternative in step 4 of MSS: The server did not respond within TBD seconds
4A1. The system suggests an alternative server
4A2. Back to step 4 A new function!
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 12 Quality Scenarios from Functional Scenarios
13. Back to Functional Analysis
• The newly discovered function should now be allocated to a functional
component
– If none of the components can handle this function, a new functional component
may be added
• The following modified architecture applies 3 architecture techniques
– Redundancy
– Mediation (“broker”) pattern
– Late binding
GPS Signals
User
Commands
User
Displays
Locator
GUI
Map
Download
Nav igation App
Map Broker
Status
1..*
Map Serv ices
Static Binding
Map Requests
Dynamic Binding
Maps
Displays
Location
Commands
Mediation
Redundancy
Dynamic
Binding
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 13 Quality Scenarios from Functional Scenarios
14. Conclusion
• Quality Scenarios can be extracted from Functional (use-case)
scenarios
– They are added as branches to the existing scenario
– They may impose architectural changes
• This process is applied iteratively during architectural design
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 14 Quality Scenarios from Functional Scenarios
15. References
1. Jacobson I., Christerson M., Jonsson P., Övergaard G., Object-
Oriented Software Engineering - A Use Case Driven Approach,
Addison-Wesley, 1992
2. Cockburn, A., Writing Effective Use Cases. Addison-Wesley, 2001.
3. Writing Use Case Scenarios for Model Driven Development,
http://www.sparxsystems.com/downloads/quick/writing-structured-
use-case-scenarios-mdd.pdf
4. Bass, L., Clements, P. and Kazman, R., Software Architecture in
Practice, 3rd Edition, Addison-Wesley, 2012.
5. Bachmann, F., Use Cases Quality Attribute Scenarios, SEI, Carnegie-
Mellon University,
http://www.cac.cornell.edu/VW/usecases/default.aspx
Dr. Amir Tomer, ISQ Conference, 2014 Extracting 15 Quality Scenarios from Functional Scenarios
16. Any questions?
amir@amirtomer.com
052-8890202
16 Extracting Dr. Amir Tomer, ISQ Conference, 2014 Quality Scenarios from Functional Scenarios