This document introduces architectural modeling and discusses key concepts including:
- Architectural models capture principal design decisions about a system's architecture. Architectural modeling is documenting these decisions.
- When modeling, architects choose what to model based on stakeholder concerns, desired level of detail, and cost/benefit. Aspects that are more important to stakeholders receive more modeling depth.
- Common things modeled include architectural elements like components, connectors and interfaces, as well as static and dynamic aspects, and functional and non-functional properties. Models are organized into views that focus on specific concerns or viewpoints.
The document discusses modeling software architecture, including what is modeled, how models are chosen and organized, and how models can be evaluated. Key points covered include:
- Architectural models capture principal design decisions of a system. Modeling is the documentation of these decisions.
- Stakeholders decide what to model based on their concerns and the cost/benefit of modeling different aspects.
- Common things modeled include components, connectors, interfaces, configurations, and rationale. Both functional and non-functional aspects can be modeled.
- Models are organized into views and viewpoints to manage complexity. Views focus on a particular concern.
The document discusses architectural analysis, which involves discovering important system properties using architectural models. It covers the goals of analysis including completeness, consistency, compatibility, and correctness. Additionally, it examines the scope of analysis, level of formality, type of analysis, and stakeholders involved in the analysis process.
In search of the Higgs or What's wrong with SEMAT?Rich Hilliard
This document summarizes an argument about concerns missing from SEMAT, a proposed "theory of everything" for software engineering. The author argues that concerns - what stakeholders care about in a system - must be modeled as first-class entities, but are missing from SEMAT and other process models. Concerns bind elements like processes, artifacts and people by giving them relevance and purpose. Existing work on concerns supports their importance, but SEMAT only acknowledges concerns at a high level without following through.
Architectural analysis involves discovering important system properties using architectural models. It is important to conduct analysis early using informal models to get stakeholder clarification and ensure project scope, while more formal models help with implementation decisions, component selection, and code generation. Architectural analysis aims to evaluate completeness, consistency, compatibility, and correctness. It considers various concerns like structural elements, data flow, interaction, and non-functional properties at different levels of the system.
This document provides an introduction to software architecture. It discusses how software engineers have long employed architectures without realizing it and how architecture addresses issues identified by researchers. It differentiates between accidental difficulties that have been solved through advances like programming languages and essential difficulties like complexity, conformity, changeability and intangibility that cannot be fully solved. It uses an analogy to building architecture to illustrate key parallels and roles. Examples of the World Wide Web and Unix architectures are provided to demonstrate architecture in action.
This document appears to be a resume or CV for Tyler Triggs who is a LAT, ATC. It lists his last research project on predictors of non-contact injury, current research, and presentation experience which has mainly been for school projects at a research symposium. It also mentions course expectations and career goals but provides no details on those sections.
This document provides an introduction to design patterns. It begins by explaining what design patterns are, their benefits, and common elements of design patterns like name, problem, solution, and consequences. It then discusses different types of design patterns classified by purpose (creational, structural, behavioral) and scope (class, object). An example of applying the strategy pattern to a duck simulation is used to illustrate how patterns can solve common object-oriented design problems by separating variable aspects from those that remain the same. The document advocates programming to interfaces rather than implementations to avoid tight coupling and allow independent extension of behavior.
Concepts Development : How To Create Products Customers LoveBernardo A. Delicado
The document discusses concepts development and creating products that customers love. It emphasizes that concept development is important for being creative in solving problems and addressing customer needs. A good concept explains what it is, why it is needed, and how it might be done. The document also stresses that systems engineers need to think holistically and take a big picture view of problems. It promotes the idea of being a "T-shaped professional" with both broad and deep skills to effectively develop concepts for complex systems.
The document discusses modeling software architecture, including what is modeled, how models are chosen and organized, and how models can be evaluated. Key points covered include:
- Architectural models capture principal design decisions of a system. Modeling is the documentation of these decisions.
- Stakeholders decide what to model based on their concerns and the cost/benefit of modeling different aspects.
- Common things modeled include components, connectors, interfaces, configurations, and rationale. Both functional and non-functional aspects can be modeled.
- Models are organized into views and viewpoints to manage complexity. Views focus on a particular concern.
The document discusses architectural analysis, which involves discovering important system properties using architectural models. It covers the goals of analysis including completeness, consistency, compatibility, and correctness. Additionally, it examines the scope of analysis, level of formality, type of analysis, and stakeholders involved in the analysis process.
In search of the Higgs or What's wrong with SEMAT?Rich Hilliard
This document summarizes an argument about concerns missing from SEMAT, a proposed "theory of everything" for software engineering. The author argues that concerns - what stakeholders care about in a system - must be modeled as first-class entities, but are missing from SEMAT and other process models. Concerns bind elements like processes, artifacts and people by giving them relevance and purpose. Existing work on concerns supports their importance, but SEMAT only acknowledges concerns at a high level without following through.
Architectural analysis involves discovering important system properties using architectural models. It is important to conduct analysis early using informal models to get stakeholder clarification and ensure project scope, while more formal models help with implementation decisions, component selection, and code generation. Architectural analysis aims to evaluate completeness, consistency, compatibility, and correctness. It considers various concerns like structural elements, data flow, interaction, and non-functional properties at different levels of the system.
This document provides an introduction to software architecture. It discusses how software engineers have long employed architectures without realizing it and how architecture addresses issues identified by researchers. It differentiates between accidental difficulties that have been solved through advances like programming languages and essential difficulties like complexity, conformity, changeability and intangibility that cannot be fully solved. It uses an analogy to building architecture to illustrate key parallels and roles. Examples of the World Wide Web and Unix architectures are provided to demonstrate architecture in action.
This document appears to be a resume or CV for Tyler Triggs who is a LAT, ATC. It lists his last research project on predictors of non-contact injury, current research, and presentation experience which has mainly been for school projects at a research symposium. It also mentions course expectations and career goals but provides no details on those sections.
This document provides an introduction to design patterns. It begins by explaining what design patterns are, their benefits, and common elements of design patterns like name, problem, solution, and consequences. It then discusses different types of design patterns classified by purpose (creational, structural, behavioral) and scope (class, object). An example of applying the strategy pattern to a duck simulation is used to illustrate how patterns can solve common object-oriented design problems by separating variable aspects from those that remain the same. The document advocates programming to interfaces rather than implementations to avoid tight coupling and allow independent extension of behavior.
Concepts Development : How To Create Products Customers LoveBernardo A. Delicado
The document discusses concepts development and creating products that customers love. It emphasizes that concept development is important for being creative in solving problems and addressing customer needs. A good concept explains what it is, why it is needed, and how it might be done. The document also stresses that systems engineers need to think holistically and take a big picture view of problems. It promotes the idea of being a "T-shaped professional" with both broad and deep skills to effectively develop concepts for complex systems.
The document discusses the importance of evaluating software architectures. It states that an architecture lays the foundation for a software system and determines its quality attributes like modifiability, performance, security and reliability. Evaluating architectures allows stakeholders to assess if the architecture is suitable and reduces risks before significant resources are spent on development. The document introduces three methods - ATAM, SAAM and ARID - that can be used to evaluate any software system's architecture and have been applied successfully on many projects.
A design pattern names, abstracts, and identifies key aspects of a common design structure to create a reusable object-oriented design. It identifies participating classes and objects, their roles and collaborations, and the distribution of responsibilities. Each pattern focuses on a particular design problem. Design patterns are organized based on their purpose (creational, structural, behavioral) and scope (class, object). Creational patterns concern object creation, structural patterns deal with class/object composition, and behavioral patterns characterize class/object interaction and responsibility distribution.
The document provides background information on the origins of design patterns. It discusses how Christopher Alexander introduced patterns for building architecture. In 1987, Kent Beck and Ward Cunningham began applying patterns to programming and presented their results at OOPSLA. Design patterns provide general reusable solutions to commonly occurring problems in software design. They describe relationships and interactions between classes or objects without specifying final classes or objects.
The document summarizes a presentation on systems engineering and technical leadership given at the Escuela Técnica Superior de Ingenieros Industriales, Universidad Politécnica de Madrid on May 22, 2017. It discusses systems engineering as an interdisciplinary approach that requires technical leadership to integrate different skills and address increasingly complex problems. It also examines the skills and career path of systems engineers, including their roles in facilitating collaboration and enabling successful project outcomes through systems thinking.
Systems Engineering is a very broad , overarching, and generally applicable engineering discipline. Many types of systems are developed using SE. These include biomedical systems, space vehicle systems, weapon systems, transportation systems, and so on.
Systems Engineering involves the coordination of work performed by engineers from all other engineering disciplines (electrical, mechanical, computer, software, etc.) as required to complete the engineering work on the project/program.
This document provides information about a course on design patterns taught by Dr. Asma Cherif. It includes the course code, instructor details, learning objectives, textbooks, and topics that will be covered such as architectural design, what patterns are, and different types of patterns. Design patterns provide solutions to common software design problems and promote reuse of successful designs. The course aims to help students understand design patterns, identify patterns in code and designs, and implement patterns to design and develop quality software applications.
This document introduces design patterns and provides an overview of the Singleton pattern. It discusses different ways to implement the Singleton pattern, including eager initialization, static block initialization, lazy initialization, thread-safe implementations using synchronization and double-checked locking, and Bill Pugh's inner static class approach. It also notes that reflection can be used to circumvent Singleton implementations and destroy the singleton nature of the class. The document categorizes design patterns and provides examples of creational, structural, and behavioral patterns.
This document provides an introduction to design patterns, explaining that patterns are reusable solutions to common problems in software design. It describes the key elements of patterns, including their names, contexts for application, solutions, consequences, and benefits such as improved reuse and education. The document also categorizes common patterns into creational, structural, and behavioral groups and provides examples. It cautions that patterns should not be overused and that their implementation can vary.
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.it/.
http://www.ivanomalavolta.com
INCOSE ASEC 2010. Human Factors - On the Right TRAK? Companion PaperNic Plum
Companion paper to presentation given at the UK INCOSE Annual Systems Engineering Conference (ASEC) 2010 at Heythrop Park, Oxfordshire by Chris Lowe (Liv Systems Ltd.) and Nic Plum (Eclectica Systems Ltd.).
http://www.incoseonline.org.uk/Program_Files/Calendar/Show_Event_Details.aspx?CatID=Events&EventID=138
It describes the application of human factors/user-centred design in unusual places - in the design of an architecture framework (TRAK) and the use of TRAK for human factors tasks.
Abstract:
Though in essence an engineering discipline, software engineering research has always been struggling to demonstrate impact. This is reflected in part by the funding challenges that the discipline faces in many countries, the difficulties we have to attract industrial participants to our conferences, and the scarcity of papers reporting industrial case studies.
There are clear historical reasons for this but we nevertheless need, as a community, to question our research paradigms and peer evaluation processes in order to improve the situation. From a personal standpoint, relevance and impact are concerns that I have been struggling with for a long time, which eventually led me to leave a comfortable academic position and a research chair to work in industry-driven research.
I will use some concrete research project examples to argue why we need more inductive research, that is, research working from specific observations in real settings to broader generalizations and theories. Among other things, the examples will show how a more thorough understanding of practice and closer interactions with practitioners can profoundly influence the definition of research problems, and the development and evaluation of solutions to these problems. Furthermore, these examples will illustrate why, to a large extent, useful research is necessarily multidisciplinary. I will also address issues regarding the implementation of such a research paradigm and show how our own bias as a research community worsens the situation and undermines our very own interests.
On a more humorous note, the title hints at the fact that being a scientist in software engineering and aiming at having impact on practice often entails leading two parallel careers and impersonate different roles to different peers and partners.
Bio:
Lionel Briand is heading the Certus center on software verification and validation at Simula Research Laboratory, where he is leading research projects with industrial partners. He is also a professor at the University of Oslo (Norway). Before that, he was on the faculty of the department of Systems and Computer Engineering, Carleton University, Ottawa, Canada, where he was full professor and held the Canada Research Chair (Tier I) in Software Quality Engineering. He is the coeditor-in-chief of Empirical Software Engineering (Springer) and is a member of the editorial boards of Systems and Software Modeling (Springer) and Software Testing, Verification, and Reliability (Wiley). He was on the board of IEEE Transactions on Software Engineering from 2000 to 2004. Lionel was elevated to the grade of IEEE Fellow for his work on the testing of object-oriented systems. His research interests include: model-driven development, testing and verification, search-based software engineering, and empirical software engineering.
Dealing with non-functional requirements in Model-driven developmentJordi Cabot
Outline of a framework to integrate non-functional requirements into the core of MDD processes.
Work presented at the RE'10 conference (18th IEEE Int. Conf. on Requirements Engineering)
1. American Express improved loan approval accuracy from 85-90% to over 70% by using machine learning to predict outcomes in the "gray area" cases that loan officers previously only got right 50% of the time.
2. Knowledge engineering deals with acquiring, representing, validating, and maintaining knowledge to build expert systems. It involves extracting knowledge from experts and representing it in a knowledge base.
3. There are challenges to acquiring knowledge from experts, including experts having difficulty articulating their knowledge and biases in their reports. Computer-aided knowledge acquisition tools and machine learning techniques can help address these challenges.
This document discusses modeling software architecture. It begins by defining architectural modeling as capturing architectural design decisions through artifacts. It discusses choosing what to model based on stakeholder concerns, modeling common architectural elements and views, and characteristics of effective models like accuracy and precision. The document also surveys example modeling approaches including natural language, UML, Darwin, Koala and AADL.
This document discusses modeling software architecture. It begins by defining architectural modeling as capturing architectural design decisions through artifacts. Key points made include:
- Models should focus on important stakeholder concerns and be at an appropriate level of detail.
- Common things to model include components, connectors, interfaces and configurations.
- Views and viewpoints are used to organize modeling efforts around specific concerns.
- Consistency among views must be maintained.
The document then surveys common modeling approaches and notations.
This document discusses key concepts in software architecture. It defines software architecture as the set of principal design decisions about a software system. These decisions encompass structure, behavior, interaction, and non-functional properties. The document also discusses architectural styles, patterns, models, views and visualizations as important concepts for understanding and communicating a system's architecture.
This document discusses an introduction to software architecture lecture. It covers:
1) The course logistics including assessments, textbooks, and origins of software architecture from addressing issues in other domains.
2) "Accidental difficulties" that have been overcome through advances like programming languages and "essential difficulties" that remain like complexity, conformity, changeability and intangibility.
3) Examples of software architectural styles like the World Wide Web and pipe and filter architectures.
Software architecture is the set of principal design decisions about a software system. It includes decisions about the system's structure, behavior, and interactions. Principal design decisions are those that have a significant impact on the system and are important to stakeholders. A software system's architecture can change over time as design decisions are made and remade throughout the system's lifetime.
The document discusses various approaches to designing software architectures and systems. It covers the standard engineering design process, potential problems that can arise, and alternative design strategies like cyclic, parallel, adaptive, and incremental processes. It also discusses tools for design like abstraction, separation of concerns, and applying experience. Architectural patterns, styles, and domain-specific software architectures are introduced as ways to apply lessons learned to new designs.
The document discusses several key points about software architecture:
1. Every application has an architecture and at least one architect. Architecture is not just a phase of development but foundational to software design.
2. Requirements analysis and design must be considered together. Existing architectures provide context for requirements and help assess feasibility.
3. The implementation phase aims to faithfully represent the architectural design in code. Deviations from the architecture can undermine its benefits.
4. Architecture centric development sustains focus on the architectural model through all phases from requirements to evolution. This helps manage quality and complexity over the system's lifetime.
This document discusses key concepts of software architecture. It makes three main points:
1) Architecture is not just a phase of development but rather is fundamental to software. Every application has an architecture and architect.
2) Considering architecture throughout the development lifecycle leads to better requirements analysis, design, implementation, testing, and evolution.
3) The "Turbine Model" visualizes development activities over time to show how architecture can be central to the process.
The document discusses the importance of evaluating software architectures. It states that an architecture lays the foundation for a software system and determines its quality attributes like modifiability, performance, security and reliability. Evaluating architectures allows stakeholders to assess if the architecture is suitable and reduces risks before significant resources are spent on development. The document introduces three methods - ATAM, SAAM and ARID - that can be used to evaluate any software system's architecture and have been applied successfully on many projects.
A design pattern names, abstracts, and identifies key aspects of a common design structure to create a reusable object-oriented design. It identifies participating classes and objects, their roles and collaborations, and the distribution of responsibilities. Each pattern focuses on a particular design problem. Design patterns are organized based on their purpose (creational, structural, behavioral) and scope (class, object). Creational patterns concern object creation, structural patterns deal with class/object composition, and behavioral patterns characterize class/object interaction and responsibility distribution.
The document provides background information on the origins of design patterns. It discusses how Christopher Alexander introduced patterns for building architecture. In 1987, Kent Beck and Ward Cunningham began applying patterns to programming and presented their results at OOPSLA. Design patterns provide general reusable solutions to commonly occurring problems in software design. They describe relationships and interactions between classes or objects without specifying final classes or objects.
The document summarizes a presentation on systems engineering and technical leadership given at the Escuela Técnica Superior de Ingenieros Industriales, Universidad Politécnica de Madrid on May 22, 2017. It discusses systems engineering as an interdisciplinary approach that requires technical leadership to integrate different skills and address increasingly complex problems. It also examines the skills and career path of systems engineers, including their roles in facilitating collaboration and enabling successful project outcomes through systems thinking.
Systems Engineering is a very broad , overarching, and generally applicable engineering discipline. Many types of systems are developed using SE. These include biomedical systems, space vehicle systems, weapon systems, transportation systems, and so on.
Systems Engineering involves the coordination of work performed by engineers from all other engineering disciplines (electrical, mechanical, computer, software, etc.) as required to complete the engineering work on the project/program.
This document provides information about a course on design patterns taught by Dr. Asma Cherif. It includes the course code, instructor details, learning objectives, textbooks, and topics that will be covered such as architectural design, what patterns are, and different types of patterns. Design patterns provide solutions to common software design problems and promote reuse of successful designs. The course aims to help students understand design patterns, identify patterns in code and designs, and implement patterns to design and develop quality software applications.
This document introduces design patterns and provides an overview of the Singleton pattern. It discusses different ways to implement the Singleton pattern, including eager initialization, static block initialization, lazy initialization, thread-safe implementations using synchronization and double-checked locking, and Bill Pugh's inner static class approach. It also notes that reflection can be used to circumvent Singleton implementations and destroy the singleton nature of the class. The document categorizes design patterns and provides examples of creational, structural, and behavioral patterns.
This document provides an introduction to design patterns, explaining that patterns are reusable solutions to common problems in software design. It describes the key elements of patterns, including their names, contexts for application, solutions, consequences, and benefits such as improved reuse and education. The document also categorizes common patterns into creational, structural, and behavioral groups and provides examples. It cautions that patterns should not be overused and that their implementation can vary.
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.it/.
http://www.ivanomalavolta.com
INCOSE ASEC 2010. Human Factors - On the Right TRAK? Companion PaperNic Plum
Companion paper to presentation given at the UK INCOSE Annual Systems Engineering Conference (ASEC) 2010 at Heythrop Park, Oxfordshire by Chris Lowe (Liv Systems Ltd.) and Nic Plum (Eclectica Systems Ltd.).
http://www.incoseonline.org.uk/Program_Files/Calendar/Show_Event_Details.aspx?CatID=Events&EventID=138
It describes the application of human factors/user-centred design in unusual places - in the design of an architecture framework (TRAK) and the use of TRAK for human factors tasks.
Abstract:
Though in essence an engineering discipline, software engineering research has always been struggling to demonstrate impact. This is reflected in part by the funding challenges that the discipline faces in many countries, the difficulties we have to attract industrial participants to our conferences, and the scarcity of papers reporting industrial case studies.
There are clear historical reasons for this but we nevertheless need, as a community, to question our research paradigms and peer evaluation processes in order to improve the situation. From a personal standpoint, relevance and impact are concerns that I have been struggling with for a long time, which eventually led me to leave a comfortable academic position and a research chair to work in industry-driven research.
I will use some concrete research project examples to argue why we need more inductive research, that is, research working from specific observations in real settings to broader generalizations and theories. Among other things, the examples will show how a more thorough understanding of practice and closer interactions with practitioners can profoundly influence the definition of research problems, and the development and evaluation of solutions to these problems. Furthermore, these examples will illustrate why, to a large extent, useful research is necessarily multidisciplinary. I will also address issues regarding the implementation of such a research paradigm and show how our own bias as a research community worsens the situation and undermines our very own interests.
On a more humorous note, the title hints at the fact that being a scientist in software engineering and aiming at having impact on practice often entails leading two parallel careers and impersonate different roles to different peers and partners.
Bio:
Lionel Briand is heading the Certus center on software verification and validation at Simula Research Laboratory, where he is leading research projects with industrial partners. He is also a professor at the University of Oslo (Norway). Before that, he was on the faculty of the department of Systems and Computer Engineering, Carleton University, Ottawa, Canada, where he was full professor and held the Canada Research Chair (Tier I) in Software Quality Engineering. He is the coeditor-in-chief of Empirical Software Engineering (Springer) and is a member of the editorial boards of Systems and Software Modeling (Springer) and Software Testing, Verification, and Reliability (Wiley). He was on the board of IEEE Transactions on Software Engineering from 2000 to 2004. Lionel was elevated to the grade of IEEE Fellow for his work on the testing of object-oriented systems. His research interests include: model-driven development, testing and verification, search-based software engineering, and empirical software engineering.
Dealing with non-functional requirements in Model-driven developmentJordi Cabot
Outline of a framework to integrate non-functional requirements into the core of MDD processes.
Work presented at the RE'10 conference (18th IEEE Int. Conf. on Requirements Engineering)
1. American Express improved loan approval accuracy from 85-90% to over 70% by using machine learning to predict outcomes in the "gray area" cases that loan officers previously only got right 50% of the time.
2. Knowledge engineering deals with acquiring, representing, validating, and maintaining knowledge to build expert systems. It involves extracting knowledge from experts and representing it in a knowledge base.
3. There are challenges to acquiring knowledge from experts, including experts having difficulty articulating their knowledge and biases in their reports. Computer-aided knowledge acquisition tools and machine learning techniques can help address these challenges.
This document discusses modeling software architecture. It begins by defining architectural modeling as capturing architectural design decisions through artifacts. It discusses choosing what to model based on stakeholder concerns, modeling common architectural elements and views, and characteristics of effective models like accuracy and precision. The document also surveys example modeling approaches including natural language, UML, Darwin, Koala and AADL.
This document discusses modeling software architecture. It begins by defining architectural modeling as capturing architectural design decisions through artifacts. Key points made include:
- Models should focus on important stakeholder concerns and be at an appropriate level of detail.
- Common things to model include components, connectors, interfaces and configurations.
- Views and viewpoints are used to organize modeling efforts around specific concerns.
- Consistency among views must be maintained.
The document then surveys common modeling approaches and notations.
This document discusses key concepts in software architecture. It defines software architecture as the set of principal design decisions about a software system. These decisions encompass structure, behavior, interaction, and non-functional properties. The document also discusses architectural styles, patterns, models, views and visualizations as important concepts for understanding and communicating a system's architecture.
This document discusses an introduction to software architecture lecture. It covers:
1) The course logistics including assessments, textbooks, and origins of software architecture from addressing issues in other domains.
2) "Accidental difficulties" that have been overcome through advances like programming languages and "essential difficulties" that remain like complexity, conformity, changeability and intangibility.
3) Examples of software architectural styles like the World Wide Web and pipe and filter architectures.
Software architecture is the set of principal design decisions about a software system. It includes decisions about the system's structure, behavior, and interactions. Principal design decisions are those that have a significant impact on the system and are important to stakeholders. A software system's architecture can change over time as design decisions are made and remade throughout the system's lifetime.
The document discusses various approaches to designing software architectures and systems. It covers the standard engineering design process, potential problems that can arise, and alternative design strategies like cyclic, parallel, adaptive, and incremental processes. It also discusses tools for design like abstraction, separation of concerns, and applying experience. Architectural patterns, styles, and domain-specific software architectures are introduced as ways to apply lessons learned to new designs.
The document discusses several key points about software architecture:
1. Every application has an architecture and at least one architect. Architecture is not just a phase of development but foundational to software design.
2. Requirements analysis and design must be considered together. Existing architectures provide context for requirements and help assess feasibility.
3. The implementation phase aims to faithfully represent the architectural design in code. Deviations from the architecture can undermine its benefits.
4. Architecture centric development sustains focus on the architectural model through all phases from requirements to evolution. This helps manage quality and complexity over the system's lifetime.
This document discusses key concepts of software architecture. It makes three main points:
1) Architecture is not just a phase of development but rather is fundamental to software. Every application has an architecture and architect.
2) Considering architecture throughout the development lifecycle leads to better requirements analysis, design, implementation, testing, and evolution.
3) The "Turbine Model" visualizes development activities over time to show how architecture can be central to the process.
This document discusses different approaches to designing software architectures, including methods, creativity, and developing judgment. It outlines an engineering design process and potential problems that can arise. Alternative design strategies like cyclic, parallel, adaptive, and incremental processes are presented. Key concepts of abstraction, separation of concerns, and leveraging experience are emphasized as fundamental design tools. The document also introduces domain-specific software architectures, architectural patterns, and architectural styles as ways to apply lessons learned from prior work. Specific patterns like model-view-controller and sense-compute-control are described, along with an example application to a lunar lander game.
Ask 5 Software Architects for a definition of Software Architecture and you'll get 10 definitions. However definition important to understand responsibilities, skills requirements and activities. Furthermore, separation of Software Architecture and Application Design has many practical benefits.
The document discusses software connectors, which are architectural elements that model interactions between components. Connectors provide interaction ducts to transfer control and data between components. While connectors may be distributed across code modules in implementations, they are first-class entities in software architectures with their own specifications and abstractions. Treating connectors as independent elements separates computation from interaction and provides benefits such as flexibility, evolution, and analysis of systems. The document outlines different roles and types of connectors.
The document discusses different techniques for analyzing software architectures, including inspections and reviews, model-based analysis, and simulation-based analysis. Inspections and reviews involve human stakeholders manually examining architectural models to identify properties like scalability. Model-based analysis uses tools to analyze architectural models for properties like consistency and uses techniques like formal modeling. Simulation-based analysis translates architectural models into an executable simulation to analyze dynamic and non-functional properties through scenario-based testing.
Lecture-_-5-_SDA_software design and architecture.docesrabilgic2
This lecture discusses software architecture. It begins by explaining that software architecture refers to the structure of a system, including its software elements, their properties, and relationships. An example diagram is shown but it is noted that the diagram alone does not represent the full architecture. Common architectural structures like patterns, reference models, and reference architectures are introduced. The lecture emphasizes that architecture is important because it enables communication between stakeholders, represents early critical design decisions, and can provide reusable abstractions of systems.
The document describes several common architectural styles, including object-oriented, layered, client-server, data-flow, blackboard, mobile code, implicit invocation, publish-subscribe, event-based, peer-to-peer, and heterogeneous styles. For each style, the document outlines the typical components, connectors, topology, advantages, and disadvantages. It also provides examples and line diagrams to illustrate how each style can be implemented.
The document discusses key concepts about software architecture:
1) Architecture is a set of principal design decisions that affect every aspect of software development.
2) Every application has an architect and an architecture, even if not explicitly defined.
3) Architecture should not be treated as just a phase of development but rather as foundational to development.
1. The document discusses key concepts of software architecture, including that every application has an architecture and architect, and that architecture is not just a phase of development but rather a foundational part of software development.
2. It describes how requirements analysis and design are intertwined with architecture considerations, and how non-functional properties depend on architectural choices.
3. The document presents different models of software development processes, including one called the "Turbine Model" that visualizes project activities and artifacts over time.
This document provides an overview of software architecture concepts including:
- Definitions of software architecture as the high-level structure of a software system and main design decisions.
- Taxonomies including architectural styles, patterns, quality attributes, and constraints.
- Descriptions of common architectural elements like components, connectors, and views.
- Discussions of prescriptive versus descriptive architecture, architecture evolution, and recovery.
This document outlines the course objectives and content for a software architectures course. The key topics covered include:
- Understanding what constitutes software architecture, architectural drivers, styles and views.
- Examining quality attribute workshops, architectural views, styles and documenting architectures.
- Exploring specific architectural styles, views, patterns and how they are used to specify system architecture.
- Analyzing architectures for emerging technologies like service-oriented architectures, cloud computing and adaptive structures.
The course aims to help students understand how to design architectures that meet requirements and explain the influence of architecture on technical and business activities. It covers important architectural concepts and how to apply styles and views.
Architectural Thinking - What Is Architecture?ingo
The document discusses the concept of architecture in the context of company information systems. It defines architecture as comprising processes, function points and applications, data structures and containers, and technological infrastructure. The role of the architect is to arrange these components to establish and maintain the system based on the business models and requirements, though the specific technologies may change over time. Good architecture balances the needs of various stakeholders and follows recognized architectural styles. Architecture is concerned with high-level structural decisions that impact a system's long-term evolution and quality attributes.
This document discusses software architecture and the role of the software architect. It defines software architecture as the structure of the system comprising software elements, their relationships and properties. Good architecture balances structure and vision. The architect role involves requirements analysis, technology selection, design, evaluation and evolution of the software architecture. Architects can operate at different levels from component to enterprise. Their role varies depending on a team's maturity but generally involves guidance, standards and balancing concerns. The document also discusses architectural drivers, views, reference architectures and the architect's involvement within an organization.
Similar to Cs 1023 lec 7 architecture (week 1) (20)
The document discusses various microbiology techniques for culturing microbes including inoculation, isolation, incubation, inspection, and identification. It describes how to produce pure cultures through methods like streak plating and describes different types of culture media including solid, liquid, enriched, selective, and differential media. The goals are to transfer microbes to produce isolated colonies, grow them under proper conditions, observe characteristics, and identify organisms through comparing data.
The document provides instructions for creating a research poster, including reviewing sample posters and an article on best practices. It discusses font size, logo placement, poster size, image and graphic quality, and elements that make a poster engaging. A sample student research poster is also included, with sections on the problem, methodology, results, conclusions, and references. The poster summarizes a study on the occupations of school-aged children who have siblings with cognitive or behavioral disabilities.
The document provides instructions for creating an effective research poster. It discusses reviewing sample posters to understand best practices like font size, logo placement, size of the poster, and quality of images. It also recommends considering what makes sample posters visually engaging and how one's own poster could be improved.
Position Your Body for Learning implements evidence-based measurements to assess optimal positioning for learning. The document describes three simple assessments - "roll", "rattle", and "rumble" - to determine if desk height matches elbow rest height and chair height matches popliteal height. It explains that proper ergonomic positioning through adjustments can improve students' attention, fine motor skills, and performance on standardized tests. The document provides a form called "Measuring for Optimal Positioning" to document student measurements and identify furniture adjustments needed.
The agenda outlines a thesis dissemination meeting that will include welcome and introductions, a syllabus review, project summaries from students, breaks, a presentation on APA style and thesis document preparation from the writing center, library resources overview, and discussion of thesis resources and dismissal. The document also lists various thesis course, poster, article, and conference resources that will be made available to students.
This document discusses program evaluation, outlining key concepts and approaches. It describes the purposes of program evaluation as determining if objectives are met and improving decision making. Formative and summative evaluations are explained, with formative used for ongoing improvement and summative to determine effects. Both quantitative and qualitative methods are appropriate, including experimental, quasi-experimental and non-experimental designs. Stakeholder involvement, utilization of results, and addressing ethical considerations are important aspects of program evaluation.
The document outlines topics from Chapter 6 of a course, including similarities and differences between intervention planning for individuals and community programs, best practices for developing mission statements and effective teams, and issues related to program sustainability. It also provides examples and activities for developing SMART goals, vision and mission statements, and sustainability plans for a fall prevention program. Resources and considerations are presented for each step of the program development process.
Compliance, motivation, and health behaviors stanbridge
This document provides information about compliance, motivation, and health behaviors as they relate to learners. It introduces several occupational therapy students and their backgrounds. The objectives cover defining key terms and discussing theories of compliance, motivation concepts, and strategies to facilitate motivation. The document then matches vocabulary terms to their definitions and discusses several theories of behavior change, including the health belief model, self-efficacy theory, protection motivation theory, stages of change model, and theory of reasoned action. Motivational strategies and the educator's role in health promotion are also outlined.
Ch 5 developmental stages of the learnerstanbridge
This document provides an overview of developmental stages of the learner from infancy through older adulthood. It begins with introductions of the presenters and learning objectives. Key terms are defined. Development is discussed in terms of physical, cognitive, and psychosocial characteristics at each stage: infancy/toddlerhood, early childhood, middle/late childhood, adolescence, young adulthood, middle-aged adulthood, and older adulthood. Teaching strategies are outlined for each developmental stage. The role of family in patient education is also addressed.
This document summarizes the content covered in Week 2 of a course on community-based occupational therapy practice. Chapter 3 discusses using theories from related disciplines in community practice and identifying strategies for organizing communities to meet health needs. Chapter 4 covers understanding relevant federal legislation, including laws supporting reimbursement and those focused on education, medical rehabilitation, consumer rights, and environmental issues. The document also lists vocabulary terms and guest speakers for the week.
This document outlines the topics and activities to be covered in Week 3 of a course on community health and health promotion program development. It will describe processes of environmental scanning, trend analysis, and the key steps of community health program development. Students will learn about needs assessments, theories in health promotion planning, goals and objectives, and the ecological approach. They will develop implementation strategies at different levels of intervention and learn the purposes of program evaluation. Readings, discussions, and activities are planned, including a scenario analyzing a sheltered workshop using SWOT analysis. Key terms and concepts are defined.
This document outlines the topics that will be covered in the first two chapters of a course on community-based occupational therapy practice. Chapter 1 will discuss the history and roles of OT in community-based practice as well as characteristics of effective community-based OTs. It will also cover paradigm shifts in OT. Chapter 2 will address concepts in community and public health, determinants of health, and strategies for prevention. It will discuss OT's contributions to Healthy People 2020 and its role in health promotion. The schedule includes lectures, small group work, and a guest speaker.
This document discusses how to critically appraise quantitative studies for clinical decision making. It covers evaluating the validity, reliability, and applicability of studies. Key points include assessing for bias, determining if results are statistically and clinically significant, and considering how well study findings can be applied to patients. Study designs like randomized controlled trials, case-control studies, and cohort studies are examined. The importance of systematic reviews and meta-analyses in evidence-based practice is also covered.
This document discusses the importance of clinical judgment in evidence-based nursing practice. It states that research evidence must be considered alongside patient concerns and preferences. Good clinical judgment requires carefully examining the validity of evidence and how it is applied to specific patients. The fit between evidence and each patient's unique situation is rarely perfect. Nurses must understand patients narratively and use judgment over time to determine the most appropriate care based on evidence and the patient's needs. Experiential learning and developing expertise in caring for particular patient populations enhances a nurse's clinical grasp and judgment.
This document discusses qualitative research and its application to clinical decision making. It describes how qualitative evidence can inform understanding of patient experiences and perspectives, which are important components of evidence-based practice. The document outlines different qualitative research traditions like ethnography, grounded theory, and phenomenology. It also discusses techniques for appraising qualitative studies based on their credibility, transferability, dependability, and confirmability. The key point is that qualitative evidence provides insights into human experiences, values, and meanings that can help inform clinical decisions.
This document discusses critically appraising knowledge for clinical decision making. It explains that practice should be based on unbiased, reliable evidence rather than tradition. The three main sources of knowledge for evidence-based practice are valid research evidence, clinical expertise, and patient choices. Clinical practice guidelines are the primary source to guide decisions as they synthesize research evidence. Internal evidence from quality improvement projects applies specifically to the setting where it was collected, unlike external evidence which is more generalizable. Both internal and external evidence should be combined using the PDSA (Plan-Do-Study-Act) cycle for continuous improvement.
This document discusses implementing evidence-based practice (EBP) in clinical settings. It emphasizes that engaging all stakeholders, including clinical staff, administrators, and other disciplines, is key. It also stresses that assessing and addressing barriers like knowledge, attitudes, and resources is important. Finally, it highlights that evaluating outcomes through quantifiable measures can help determine the impact of EBP changes on patient care.
This document discusses clinical practice guidelines (CPGs), including how they are developed based on evidence, how they can standardize care while allowing flexibility, and how to evaluate and implement them. It notes that CPGs systematically develop statements to guide regional diagnosis and treatment based on the best available evidence. While CPGs provide time-effective guidance, the commitment of caregivers is most important for successful implementation.
This document discusses key aspects of writing a successful grant proposal. It explains that grant proposals request funding for research or evidence-based projects by outlining specific aims, background, significance, methodology, budget, and personnel. Successful grant writers are passionate, meticulous planners who can persuade reviewers of a project's importance and address potential barriers. The most important initial question is whether a project meets the funding organization's application criteria. Proposals need compelling abstracts that explain why a project deserves funding and clearly written background and methodology sections. Common weaknesses that can lead to rejection are a lack of significance or novel ideas and inadequate description of study design.
The document discusses ethical considerations for evidence implementation and generation in healthcare. It outlines key ethical principles like beneficence, nonmaleficence, autonomy and justice. These principles form the foundation for core dimensions of healthcare quality according to the Institute of Medicine. The document also differentiates between clinical research, quality improvement initiatives, and evidence-based practice. It notes some controversies around applying different ethical standards to research versus quality improvement. Overall, the document provides an overview of how ethical principles guide evidence-based healthcare practices and quality improvement efforts.
Chapter wise All Notes of First year Basic Civil Engineering.pptxDenish Jangid
Chapter wise All Notes of First year Basic Civil Engineering
Syllabus
Chapter-1
Introduction to objective, scope and outcome the subject
Chapter 2
Introduction: Scope and Specialization of Civil Engineering, Role of civil Engineer in Society, Impact of infrastructural development on economy of country.
Chapter 3
Surveying: Object Principles & Types of Surveying; Site Plans, Plans & Maps; Scales & Unit of different Measurements.
Linear Measurements: Instruments used. Linear Measurement by Tape, Ranging out Survey Lines and overcoming Obstructions; Measurements on sloping ground; Tape corrections, conventional symbols. Angular Measurements: Instruments used; Introduction to Compass Surveying, Bearings and Longitude & Latitude of a Line, Introduction to total station.
Levelling: Instrument used Object of levelling, Methods of levelling in brief, and Contour maps.
Chapter 4
Buildings: Selection of site for Buildings, Layout of Building Plan, Types of buildings, Plinth area, carpet area, floor space index, Introduction to building byelaws, concept of sun light & ventilation. Components of Buildings & their functions, Basic concept of R.C.C., Introduction to types of foundation
Chapter 5
Transportation: Introduction to Transportation Engineering; Traffic and Road Safety: Types and Characteristics of Various Modes of Transportation; Various Road Traffic Signs, Causes of Accidents and Road Safety Measures.
Chapter 6
Environmental Engineering: Environmental Pollution, Environmental Acts and Regulations, Functional Concepts of Ecology, Basics of Species, Biodiversity, Ecosystem, Hydrological Cycle; Chemical Cycles: Carbon, Nitrogen & Phosphorus; Energy Flow in Ecosystems.
Water Pollution: Water Quality standards, Introduction to Treatment & Disposal of Waste Water. Reuse and Saving of Water, Rain Water Harvesting. Solid Waste Management: Classification of Solid Waste, Collection, Transportation and Disposal of Solid. Recycling of Solid Waste: Energy Recovery, Sanitary Landfill, On-Site Sanitation. Air & Noise Pollution: Primary and Secondary air pollutants, Harmful effects of Air Pollution, Control of Air Pollution. . Noise Pollution Harmful Effects of noise pollution, control of noise pollution, Global warming & Climate Change, Ozone depletion, Greenhouse effect
Text Books:
1. Palancharmy, Basic Civil Engineering, McGraw Hill publishers.
2. Satheesh Gopi, Basic Civil Engineering, Pearson Publishers.
3. Ketki Rangwala Dalal, Essentials of Civil Engineering, Charotar Publishing House.
4. BCP, Surveying volume 1
This document provides an overview of wound healing, its functions, stages, mechanisms, factors affecting it, and complications.
A wound is a break in the integrity of the skin or tissues, which may be associated with disruption of the structure and function.
Healing is the body’s response to injury in an attempt to restore normal structure and functions.
Healing can occur in two ways: Regeneration and Repair
There are 4 phases of wound healing: hemostasis, inflammation, proliferation, and remodeling. This document also describes the mechanism of wound healing. Factors that affect healing include infection, uncontrolled diabetes, poor nutrition, age, anemia, the presence of foreign bodies, etc.
Complications of wound healing like infection, hyperpigmentation of scar, contractures, and keloid formation.
Walmart Business+ and Spark Good for Nonprofits.pdfTechSoup
"Learn about all the ways Walmart supports nonprofit organizations.
You will hear from Liz Willett, the Head of Nonprofits, and hear about what Walmart is doing to help nonprofits, including Walmart Business and Spark Good. Walmart Business+ is a new offer for nonprofits that offers discounts and also streamlines nonprofits order and expense tracking, saving time and money.
The webinar may also give some examples on how nonprofits can best leverage Walmart Business+.
The event will cover the following::
Walmart Business + (https://business.walmart.com/plus) is a new shopping experience for nonprofits, schools, and local business customers that connects an exclusive online shopping experience to stores. Benefits include free delivery and shipping, a 'Spend Analytics” feature, special discounts, deals and tax-exempt shopping.
Special TechSoup offer for a free 180 days membership, and up to $150 in discounts on eligible orders.
Spark Good (walmart.com/sparkgood) is a charitable platform that enables nonprofits to receive donations directly from customers and associates.
Answers about how you can do more with Walmart!"
Temple of Asclepius in Thrace. Excavation resultsKrassimira Luka
The temple and the sanctuary around were dedicated to Asklepios Zmidrenus. This name has been known since 1875 when an inscription dedicated to him was discovered in Rome. The inscription is dated in 227 AD and was left by soldiers originating from the city of Philippopolis (modern Plovdiv).
Philippine Edukasyong Pantahanan at Pangkabuhayan (EPP) CurriculumMJDuyan
(𝐓𝐋𝐄 𝟏𝟎𝟎) (𝐋𝐞𝐬𝐬𝐨𝐧 𝟏)-𝐏𝐫𝐞𝐥𝐢𝐦𝐬
𝐃𝐢𝐬𝐜𝐮𝐬𝐬 𝐭𝐡𝐞 𝐄𝐏𝐏 𝐂𝐮𝐫𝐫𝐢𝐜𝐮𝐥𝐮𝐦 𝐢𝐧 𝐭𝐡𝐞 𝐏𝐡𝐢𝐥𝐢𝐩𝐩𝐢𝐧𝐞𝐬:
- Understand the goals and objectives of the Edukasyong Pantahanan at Pangkabuhayan (EPP) curriculum, recognizing its importance in fostering practical life skills and values among students. Students will also be able to identify the key components and subjects covered, such as agriculture, home economics, industrial arts, and information and communication technology.
𝐄𝐱𝐩𝐥𝐚𝐢𝐧 𝐭𝐡𝐞 𝐍𝐚𝐭𝐮𝐫𝐞 𝐚𝐧𝐝 𝐒𝐜𝐨𝐩𝐞 𝐨𝐟 𝐚𝐧 𝐄𝐧𝐭𝐫𝐞𝐩𝐫𝐞𝐧𝐞𝐮𝐫:
-Define entrepreneurship, distinguishing it from general business activities by emphasizing its focus on innovation, risk-taking, and value creation. Students will describe the characteristics and traits of successful entrepreneurs, including their roles and responsibilities, and discuss the broader economic and social impacts of entrepreneurial activities on both local and global scales.
2. Software Architecture: Foundations, Theory, and Practice
Objectives
Concepts
What is modeling?
How do we choose what to model?
What kinds of things do we model?
How can we characterize models?
How can we break up and organize models?
How can we evaluate models and modeling notations?
Examples
Concrete examples of many notations used to model software
architectures
Revisiting Lunar Lander as expressed in different modeling
notations
2
3. Software Architecture: Foundations, Theory, and Practice
What is Architectural Modeling?
Recall that we have characterized architecture as the set of
principal design decisions made about a system
We can define models and modeling in those terms
An architectural model is an artifact that captures some or
all of the design decisions that comprise a system’s
architecture
Architectural modeling is the reification and
documentation of those design decisions
How we model is strongly influenced by the notations we
choose:
An architectural modeling notation is a language or
means of capturing design decisions.
3
4. Software Architecture: Foundations, Theory, and Practice
How do We Choose What to
Model?
Architects and other stakeholders must make critical
decisions:
1. What architectural decisions and concepts should be
modeled,
2. At what level of detail, and
3. With how much rigor or formality
– These are cost/benefit decisions
The benefits of creating and maintaining an
architectural model must exceed the cost of doing so
4
7. Software Architecture: Foundations, Theory, and Practice
What do We Model? (cont’d)
Elements of the architectural style
Inclusion of specific basic elements (e.g.,
components, connectors, interfaces)
Component, connector, and interface types
Constraints on interactions
Behavioral constraints
Concurrency constraints
…
7
8. Software Architecture: Foundations, Theory, and Practice
What do We Model? (cont’d)
Static and Dynamic Aspects
Static aspects of a system do not change as a
system runs
e.g., topologies, assignment of
components/connectors to hosts, …
Dynamic aspects do change as a system runs
e.g., State of individual components or
connectors, state of a data flow through a
system, …
This line is often unclear
Consider a system whose topology is relatively
stable but changes several times during system
startup 8
9. Software Architecture: Foundations, Theory, and Practice
What do We Model? (cont’d)
Important distinction between:
Models of dynamic aspects of a system (models
do not change)
Dynamic models (the models themselves change)
9
10. Software Architecture: Foundations, Theory, and Practice
What do We Model? (cont’d)
Functional and non-functional aspects of a system
Functional
“The system prints medical records”
Non-functional
“The system prints medical records quickly and
confidentially.”
Architectural models tend to be functional, but like
rationale it is often important to capture non-functional
decisions even if they cannot be automatically or
deterministically interpreted or analyzed
10
11. Software Architecture: Foundations, Theory, and Practice
Important Characteristics of
Models
Ambiguity
A model is ambiguous if it is open to more than one
interpretation
Accuracy and Precision
Different, but often conflated concepts
A model is accurate if it is correct, conforms to
fact, or deviates from correctness within
acceptable limits
A model is precise if it is sharply exact or
delimited
11
13. Software Architecture: Foundations, Theory, and Practice
Views and Viewpoints
Generally, it is not feasible to capture everything we
want to model in a single model or document
The model would be too big, complex, and confusing
So, we create several coordinated models, each
capturing a subset of the design decisions
Generally, the subset is organized around a particular
concern or other selection criteria
We call the subset-model a ‘view’ and the concern (or
criteria) a ‘viewpoint’
13
15. Software Architecture: Foundations, Theory, and Practice
Commonly-Used Viewpoints
Logical Viewpoints
Capture the logical (often software) entities in a
system and how they are interconnected.
Physical Viewpoints
Capture the physical (often hardware) entities in a
system and how they are interconnected.
Deployment Viewpoints
Capture how logical entities are mapped onto physical
entities.
15
16. Software Architecture: Foundations, Theory, and Practice
Commonly-Used Viewpoints
(cont’d)
Concurrency Viewpoints
Capture how concurrency and threading will be
managed in a system.
Behavioral Viewpoints
Capture the expected behavior of (parts of) a
system.
16
17. Software Architecture: Foundations, Theory, and Practice
Consistency Among Views
Views can contain overlapping and related design
decisions
There is the possibility that the views can thus become
inconsistent with one another
Views are consistent if the design decisions they
contain are compatible
Views are inconsistent if two views assert design
decisions that cannot simultaneously be true
Inconsistency is usually but not always indicative of
problems
Temporary inconsistencies are a natural part of
exploratory design
Inconsistencies cannot always be fixed 17
19. Software Architecture: Foundations, Theory, and Practice
Common Types of Inconsistencies
Direct inconsistencies
E.g., “The system runs on two hosts” and “the system
runs on three hosts.”
Refinement inconsistencies
High-level (more abstract) and low-level (more
concrete) views of the same parts of a system conflict
Static vs. dynamic aspect inconsistencies
Dynamic aspects (e.g., behavioral specifications)
conflict with static aspects (e.g., topologies)
19
20. Software Architecture: Foundations, Theory, and Practice
Common Types of Inconsistencies
(cont’d)
Dynamic vs. dynamic aspect inconsistencies
Different descriptions of dynamic aspects of a
system conflict
Functional vs. non-functional inconsistencies
20
21. Software Architecture: Foundations, Theory, and Practice
Evaluating Modeling Approaches
Scope and purpose
What does the technique help you model? What does
it not help you model?
Basic elements
What are the basic elements (the ‘atoms’) that are
modeled? How are they modeled?
Style
To what extent does the approach help you model
elements of the underlying architectural style? Is the
technique bound to one particular style or family of
styles?
21
22. Software Architecture: Foundations, Theory, and Practice
Evaluating Modeling Approaches
(cont’d)
Static and dynamic aspects
What static and dynamic aspects of an architecture
does the approach help you model?
Dynamic modeling
To what extent does the approach support models
that change as the system executes?
Non-functional aspects
To what extent does the approach support (explicit)
modeling of non-functional aspects of architecture?
22
23. Software Architecture: Foundations, Theory, and Practice
Evaluating Modeling Approaches
(cont’d)
Ambiguity
How does the approach help you to avoid (or
embrace) ambiguity?
Accuracy
How does the approach help you to assess the
correctness of models?
Precision
At what level of detail can various aspects of the
architecture be modeled?
23
24. Software Architecture: Foundations, Theory, and Practice
Evaluating Modeling Approaches
(cont’d)
Viewpoints
Which viewpoints are supported by the approach?
Viewpoint Consistency
How does the approach help you assess or
maintain consistency among different views?
24
25. Software Architecture: Foundations, Theory, and Practice
Surveying Modeling Approaches
Generic approaches
Natural language
PowerPoint-style modeling
UML, the Unified Modeling Language
Early architecture description languages
Darwin
Rapide
Wright
Domain- and style-specific languages
Koala
Weaves
AADL
Extensible architecture description languages
Acme
ADML
xADL
25
26. Software Architecture: Foundations, Theory, and Practice
Natural Language
Spoken/written languages such as English
Advantages
Highly expressive
Accessible to all stakeholders
Good for capturing non-rigorous or informal architectural
elements like rationale and non-functional requirements
Plentiful tools available (word processors and other text editors)
Disadvantages
Ambiguous, non-rigorous, non-formal
Often verbose
Cannot be effectively processed or analyzed by
machines/software
26
27. Software Architecture: Foundations, Theory, and Practice
27
Natural Language Example
“The Lunar Lander application consists of three components: a data store
component, a calculation component, and a user interface component.
The job of the data store component is to store and allow other components
access to the height, velocity, and fuel of the lander, as well as the current
simulator time.
The job of the calculation component is to, upon receipt of a burn-rate
quantity, retrieve current values of height, velocity, and fuel from the data
store component, update them with respect to the input burn-rate, and store
the new values back. It also retrieves, increments, and stores back the
simulator time. It is also responsible for notifying the calling component of
whether the simulator has terminated, and with what state (landed safely,
crashed, and so on).
The job of the user interface component is to display the current status of
the lander using information from both the calculation and the data store
components. While the simulator is running, it retrieves the new burn-rate
value from the user, and invokes the calculation component.”
28. Software Architecture: Foundations, Theory, and Practice
Related Alternatives
Ambiguity can be reduced and rigor can be increased
through the use of techniques like ‘statement templates,’
e.g.:
The (name) interface on (name) component takes (list-of-
elements) as input and produces (list-of-elements) as output
(synchronously | asynchronously).
This can help to make rigorous data easier to read and interpret,
but such information is generally better represented in a more
compact format
28
29. Software Architecture: Foundations, Theory, and Practice
Natural Language Evaluation
29
Scope and purpose
Capture design decisions in
prose form
Basic elements
Any concepts required
Style
Can be described by using
more general language
Static & Dynamic Aspects
Any aspect can be modeled
Dynamic Models
No direct tie to
implemented/ running
system
Non-Functional Aspects
Expressive vocabulary
available (but no way to
verify)
Ambiguity
Plain natural language tends to
be ambiguous; statement
templates and dictionaries help
Accuracy
Manual reviews and inspection
Precision
Can add text to describe any
level of detail
Viewpoints
Any viewpoint (but no specific
support for any particular
viewpoint)
View consistency
Manual reviews and inspection
30. Software Architecture: Foundations, Theory, and Practice
Informal Graphical Modeling
General diagrams produced in tools like PowerPoint and
OmniGraffle
Advantages
Can be aesthetically pleasing
Size limitations (e.g., one slide, one page) generally constrain
complexity of diagrams
Extremely flexible due to large symbolic vocabulary
Disadvantages
Ambiguous, non-rigorous, non-formal
But often treated otherwise
Cannot be effectively processed or analyzed by
machines/software
30
32. Software Architecture: Foundations, Theory, and Practice
Related Alternatives
Some diagram editors (e.g., Microsoft Visio) can be
extended with semantics through scripts and other
additional programming
Generally ends up somewhere in between a custom
notation-specific editor and a generic diagram editor
Limited by extensibility of the tool
PowerPoint Design Editor (Goldman, Balzer) was an
interesting project that attempted to integrate semantics
into PowerPoint
32
33. Software Architecture: Foundations, Theory, and Practice
Informal Graphical Evaluation
33
Scope and purpose
Arbitrary diagrams
consisting of symbols and
text
Basic elements
Geometric shapes, splines,
clip-art, text segments
Style
In general, no support
Static & Dynamic Aspects
Any aspect can be modeled,
but no semantics behind
models
Dynamic Models
Rare, although APIs to
manipulate graphics exist
Non-Functional Aspects
With natural language
annotations
Ambiguity
Can be reduced through use
of rigorous symbolic
vocabulary/dictionaries
Accuracy
Manual reviews and inspection
Precision
Up to modeler; generally
canvas is limited in size (e.g.,
one ‘slide’)
Viewpoints
Any viewpoint (but no specific
support for any particular
viewpoint)
View consistency
Manual reviews and inspection
34. Software Architecture: Foundations, Theory, and Practice
UML – the Unified Modeling
Language
13 loosely-interconnected notations called diagrams that
capture static and dynamic aspects of software-intensive
systems
Advantages
Support for a diverse array of viewpoints focused on many
common software engineering concerns
Ubiquity improves comprehensibility
Extensive documentation and tool support from many
vendors
Disadvantages
Needs customization through profiles to reduce ambiguity
Difficult to assess consistency among views
Difficult to capture foreign concepts or views
34
36. Software Architecture: Foundations, Theory, and Practice
UML Evaluation
36
Scope and purpose
Diverse array of design
decisions in 13 viewpoints
Basic elements
Multitude – states, classes,
objects, composite nodes…
Style
Through (OCL) constraints
Static & Dynamic Aspects
Some static diagrams (class,
package), some dynamic
(state, activity)
Dynamic Models
Rare; depends on the
environment
Non-Functional Aspects
No direct support; natural-
language annotations
Ambiguity
Many symbols are interpreted
differently depending on
context; profiles reduce
ambiguity
Accuracy
Well-formedness checks,
automatic constraint
checking, ersatz tool
methods, manual
Precision
Up to modeler; wide flexibility
Viewpoints
Each diagram type represents
a viewpoint; more can be
added through
overloading/profiles
View consistency
Constraint checking, ersatz
tool methods, manual