ARCHITECTURA L ADAPTATION TALIESIN SMITH. CONCEPTS Adaptation – Modification of a software system to satisfy new requirements and changing circumstances.

Slides:



Advertisements
Similar presentations
Technical and design issues in implementation Dr. Mohamed Ally Director and Professor Centre for Distance Education Athabasca University Canada New Zealand.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Chapter 2 – Software Processes
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Basic Concepts Software Architecture Lecture 3.
HOW DO PROFESSIONAL DEVELOPERS COMPREHEND TO SOFTWARE Report submitted by Tobias Roehm, Rebecca Tiarks, Rainer Koschke, Walid Maalej.
OASIS Reference Model for Service Oriented Architecture 1.0
The Role of Software Engineering Brief overview of relationship of SE to managing DSD risks 1.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors.
Architectural Adaptation Software Architecture Week 13, Lecture 1 Prepared by Dr. Richard Taylor Professor of Information and Computer Sciences University.
Foundations for the Study of Software Architecture by Dewayne Perry & Alexander Wolf ACM SIGSOFT, Oct Presented by Charles Reid 2/7/2005.
Software Connectors. Attach adapter to A Maintain multiple versions of A or B Make B multilingual Role and Challenge of Software Connectors Change A’s.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7.
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Dynamism in Software Architectures. Adaptation  Change is endemic to software –perceived and actual malleability of software induces stakeholders to.
Identifying Architectural Bad Smells Joshua Garcia, Daniel Popescu, George Edwards and Nenad Medvidovic University of Southern California.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Adaptation Software Architecture Lecture 25.
SE 555 – Software Requirements & Specifications Introduction
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Course Instructor: Aisha Azeem
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Adaptation Software Architecture Lecture 25.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors Software Architecture Lecture 7.
UML - Development Process 1 Software Development Process Using UML (2)
Architectural separation (MVC, arch model, Seeheim).
Architecture-Based Runtime Software Evolution Peyman Oreizy, Nenad Medvidovic & Richard N. Taylor.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
“Role” of Software Architecture 3 “fundamental” understandings about architecture: (not sure how “fundamental”-Tsui) 1.Every software application has an.
Travis Steel. Objectives What is the Agent Paradigm? What is Agent-Oriented Design and how is it different than OO? When to apply AOD techniques? When.
By Xiangzhe Li Thanh Nguyen.  Introduction  Terminology  Architecture  Component  Connector  Configuration  Architectural Style  Architectural.
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Design Concepts and Principles Instructor: Dr. Jerry Gao.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
GRASP: Designing Objects with Responsibilities
Documenting Software Architectures 1.Uses and Audiences for Architecture Documentation Architecture documentation serves as a means of education Architecture.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 CMPT 275 High Level Design Phase Modularization.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
CSE 303 – Software Design and Architecture
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 15. Review Interaction-Oriented Software Architectures – MVC.
Software Connectors Acknowledgement: slides mostly from Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic,
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Software Connectors in Practice Software Architecture.
Software Connectors. What is a Software Connector? 2 What is Connector? – Architectural element that models Interactions among components Rules that govern.
Basic Concepts of Software Architecture. What is Software Architecture? Definition: – A software system’s architecture is the set of principal design.
Architectural Adaptation
Software Architecture Lecture 3
Software Architecture
IS301 – Software Engineering V:
CS 389 – Software Engineering
Software Architecture Lecture 3
Chapter 2 – Software Processes
Software Architecture Lecture 3
Software Architecture Lecture 3
Software Connectors.
Architectural Adaptation
Software Architecture Lecture 3
Architectural Adaptation
Architectural Adaptation
Software Architecture Lecture 7
Architectural Adaptation
Software Architecture Lecture 7
Architectural Adaptation
Software Architecture Lecture 3
Software Architecture Lecture 7
ISO/IEC Systems and software Quality Requirements and Evaluation
Chapter 2: System models
Software Architecture Lecture 6
Presentation transcript:

ARCHITECTURA L ADAPTATION TALIESIN SMITH

CONCEPTS Adaptation – Modification of a software system to satisfy new requirements and changing circumstances Agent – People and/or software that perform the change Context – The factors behind the motivation for change

SOURCES AND MOTIVATION Corrective change Functional requirements Non-functional requirements Operating environment

SOURCES AND MOTIVATION Product-line forces New variant New branch point Merging product lines Observation and Analysis

BUILDING ANALOGY A building is made up of various layers Some layers are harder to change than others All layers change with varying frequency Architectural erosion

BUILDING ANALOGY Identify how layers interact Separate layers so that changing one affects few others Make changes based on complete structure, not local Look at overall effects of change, then incorporate changes down into local code

ELEMENTS SUBJECT TO CHANGE - COMPONENTS To facilitate adaptation, give components the following capabilities Self-knowledge and exposure of such to external entities Self-knowledge of component’s role in larger scheme Proactively engage other elements to adapt

ELEMENTS SUBJECT TO CHANGE - INTERFACES Changing interfaces requires changing that which they interface to Create adaptors that take data, translate, and pass on to the component This creates problems after too many changes

ELEMENTS SUBJECT TO CHANGE - CONNECTORS Usually changed to achieve new or different non- functional properties The more powerful the connector, the easier the adaptation

AGENTS Identity and Location Humans can deal with a wider range of problems Programs can identify and fix problems faster If agent is deployed with the system, it need not get to the application and has access to more contextual information Knowledge Risks, constraints, etc.

CONTEXT Timing The earlier change is initiated, the better Difficulty increases sharply after deployment Degree of Freedom More freedom is not always better Increases search space and decreases initial guidance Cost can be decreased by doing lower-quality assessment, but results in possible degradation o f the system

CONCEPTUAL FRAMEWORKS