10/27/2014. MTAT Software Engineering. Exams. Acknowledgements. Schedule of Lectures. A tale of two systems. Structure of Lecture 07
|
|
- Gavin Dennis
- 5 years ago
- Views:
Transcription
1 MTAT Software Engineering Lecture 07: Architecture and Design Exams Date Time Place: Exam 1: Friday, 09-Jan-2015, 14:15-16:15, room Exam 2: Friday, 16-Jan-2015, 14:15-16:15, room Re-take Exam: Friday, 23-Jan-2015, 14:15-16:15, room Capacity limit of 90 students Fall 2014 Dietmar Pfahl You must register: First-come-first-serve (FIFO) principle Schedule of Lectures Acknowledgements Week 01: Introduction to SE Week 02: Requirements Engineering I Week 03: Requirements Engineering II Week 04: Analysis Week 05: Dev. Infrastructure I Week 06: Dev. Infrastructure II Week 07: ICS Day / ATI Päev 2014 Week 08: Architecture and Design Week 09: Refactoring Week 10: Verification and Validation Week 11: Software Quality Management Week 12: Agile/Lean Methods Week 13: Measurement & Process Improvement Week 14: Course wrap-up, review and exam preparation Week 15: no lecture Week 16: no lecture Textbooks/Slides: Ian Sommerville: Software Engineering, 9th edition, 2010 ( Hans van Vliet: Software Architecture, Free University of Amsterdam, Lecture 2008 Richard Taylor et al.: Software Architecture, University of California at Irvine, Lecture 2011 Alexander Serebrenik: Software architecture: Domain-Specific Software Architecture and Architectural Patterns, TU Eindhoven, Lecture 2013 George Fairbanks: Just Enough Software Architecture, 2012 (Video: Structure of Lecture 07 A tale of two systems What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up 1
2 Let s design a system! The system is real Rackspace Rackspace: Architecture 1 Rackspace: Architecture 2 CSR: Customer Service Request CSR: Customer Service Request Rackspace: Architecture 3 Rackspace: Quality Attribute Trade-offs CSR: Customer Service Request ( 2
3 What if you don t think architecturally? Virtuosos and Roman Engineers Remember: All programs have an architecture... But not every architecture suits the program! Structure of Lecture 07 Terminology What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up Architect Person Architecting Process Architecture Product The Role of the Architect Pre-Architecture Life-Cycle client, users requirements architect solutions developers stakeholders (few) functionality quality assess creates assess Characteristics: Iteration mainly on functional requirements agreement appearance, behaviour visualises architectural design prescribes construction, co-operation Few stakeholders involved No balancing of functional and quality requirements development 3
4 Adding Architecture: The Easy Way Architecture in the Life-Cycle stakeholders (many) stakeholders (few) functionality quality functionality quality architecture detailed design implementation agreement development Characteristics: Iteration on both functional and quality requirements Many stakeholders involved architecture agreement development Balancing of functional and quality requirements Architecture Drivers Importance Difficulty Rational Architecture Decisions Design Issues, Options and Decisions A designer is faced with a series of design issues These are sub-problems of the overall design problem. For example, a design issue can be the type and level of security. Security can be decomposed into authentication, authorization, and privacy. Each issue normally has several alternative solutions (or design options) The designer makes a design decision to resolve each issue. This process involves choosing the best option from among the alternatives. Attribute-Driven Design (ADD) ADD Example Iterations Top-level: usability separate UI 3-tier architecture Lower-level, within user interface: security authenticate users Lower-level, within data layer: availability active redundancy 4
5 Decision Space The space of possible designs that can be achieved by choosing different sets of alternatives. Issues that can be relevant in the decision process could be: - level of flexibility; - outsourcing/external acquisition of client technology (that mans need for separate presentation also relevant for the budget); - if using the Web/Internet; - performance;... Tree or Graph? Issues and options are not independent... A number of options become invalid due to a desired NFR (quality). For example, flexibility could be achieved through certain architectural patterns, like MVC which facilitates separation of concerns and layered architecture restricting client-server interactions. If we choose any of the two, we exclude the 'monolithic' sub-tree and we need a separate GUI layer. More than just IT Technical and non-technical issues and options are intertwined Architects deciding on the type of database versus Management deciding on new strategic partnership or Management deciding on budget Once again: Why is documenting design decisions important? Prevents repeating (expensive) past steps Explains why this is a good (better: suitable) architecture Emphasizes qualities and criticality for requirements/goals Provides context and background Design rationale example: Architecture in Construction of Buildings Software Architecture Architecture is conceptual. Architectural descriptions are concrete, but the architecture itself is inherently conceptual, and cannot be captured in any (set of) views nor in the code. Architecture is about fundamental things. Abstraction!!! Architecture exists in some context. We can only understand qualities in context. -> Views!!! 5
6 Software Architecture Definition (1) Software Architecture Definition (2) The architecture of a software system defines that system in terms of computational components and interactions among those components. 2 (from Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996) statement procedure module (design) pattern architecture The software architecture of a system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. 3 (from Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003) Software Architecture Definition (3) Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution 4 (from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000) Architecture Sloppy Definitions Architecture is high-level design Architecture is overall structure of the system Architecture is components and connectors Architecture is the structure, the behavior (properties), and the principles and guidelines governing its design and evolution over time Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up Analogy with Building Architecture Overall picture of building (client) Front view (client, beauty committee) Separate picture for water supply (plumber) Separate picture for electrical wiring (electrician) etc 6
7 IEEE Model for Architectural Descriptions Kruchten s 4+1 View Model Env ironment Mission Sy stem Stakeholder Architecture Architecture Description Rationale System stakeholder: an individual, team, or organization (or classes hereof) with interests in, or concerns relative to, a system. View: a representation of a whole system from the perspective of a related set of concerns. End-user Functionality Logical Scenarios Programmers Software management Implementation Concern Library View Model : A viewpoint establishes the purposes (concerns) and audience (stakeholders) for a view and the techniques or methods employed in constructing a view. Process Integrators Performance Scalability Deployment System engineers Topology Communications Kruchten s 4+1 View Model Kruchten s 4+1 View Model Supports the functional requirements, i.e., the services the system should provide to its end users. Typically, it shows the key abstractions (e.g., classes and associations amongst them). End-user Functionality Logical Process Integrators Performance Scalability Scenarios Programmers Software management Implementation Deployment System engineers Topology Communications Takes into account some nonfunctional requirements, such as performance and system availability. It addresses concurrency and distribution, system integrity, and faulttolerance. The process view also specifies which thread of control executes each operation of each class identified in the logical view. So the process view describes the mapping of functions to runtime elements. It concerns the dynamics of the system. A process is a group of tasks which form a logical unit. A process can be started, stopped, resumed, etc., and there is communication between processes. End-user Functionality Logical Process Integrators Performance Scalability Scenarios Programmers Software management Implementation Deployment System engineers Topology Communications Kruchten s 4+1 View Model Kruchten s 4+1 View Model End-user Functionality Logical Process Integrators Performance Scalability Scenarios Programmers Software management Implementation Deployment System engineers Topology Communications Focuses on the organization of the actual software modules in the software-development environment. The software is packaged in small chunks (program libraries or subsystems) that can be developed by one or more developers. End-user Functionality Logical Process Integrators Performance Scalability Scenarios Programmers Software management Implementation Deployment System engineers Topology Communications => Physical view: Defines how the various elements identified in the logical, process, and implementation views (networks, processes, tasks, and objects) must be mapped onto the various nodes. Takes into account the system's non-functional requirements such as system availability, reliability (faulttolerance), performance (throughput), and scalability. 7
8 4 + 1: Scenario Structure of Lecture 07 Consists of a small subset of important scenarios (e.g., use cases) to show that the elements of the four views work together seamlessly. This view is redundant with the other ones (hence the "+1"), but it plays two critical roles: Acts as a driver to help designers discover architectural elements during the architecture design; Validates and illustrates the architecture design, both on paper and as the starting point for the tests of an architectural prototype. End-user Functionality Logical Process Integrators Performance Scalability Programmers Software management Implementation Scenarios Deployment System engineers Topology Communications What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up Standard Notation: UML Architecture presentations in practice By and large two flavors: Powerpoint slides for managers, users, consultants, etc UML diagrams, for technicians A small sample Conceptual View Customer, Users More technical view Developers (same system as on previous slide) 8
9 Runtime View Deployment View High-level overview of the architecture (Logical view Implementation view) A University Course Catalogue System Application layer This Application layer has all the boundary classes that represent the application screens that the user sees. Business Services layer The Business Services process layer has all the controller classes that represent the use case managers that drive the application behavior. This layer represents the client-to-mid-tier border. Middleware layer The Middleware layer supports access to Relational DBMS and OODBMS. Runtime Component Deployment View Component clientars User machine Search App. Server 1, App Server 2 (WebLogic 7.0) ReserveAndBuy App. Server 1, App Server 2 (WebLogic 7.0) Authenticate App. Server 1, App Server 2 (WebLogic 7.0) ArsStartup App. Server 1, App Server 2 (WebLogic 7.0) LocalRestart App. Server 1, App Server 2 (WebLogic 7.0) ARS Database DB Server (MS SQL Server) CreditCard Database DB Server (MS SQL Server) CreditCard Naming server & Replication mgr God Naming server & Replication mgr Base Reuse package The Base Reuse package includes classes to support list functions and patterns. (see doc on course wiki) Deployment view of the architecture. Process view of the architecture. Shows the tasks (processes and threads) involved in the system's execution, their interactions and configurations. Processes exist to support student registration, professor functions, registration closing, and access to the external Billing System and Course Catalog System. Shows the various physical nodes for the most typical platform configurations. Also shows the allocation of tasks (from the Process View) to the physical nodes. So, Different representations For different people For different purposes These representations are both descriptive and prescriptive Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up 9
10 Learning from Others: Patterns, Styles, and DSSAs How to solve a problem? Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission. Examples of Domains Domain-Specific Software Architectures Compilers for programming languages Consumer electronics Electronic commerce system/web stores Video game Business applications Basic/Standard/ Pro A DSSA is an assemblage of software components specialized for a particular type of task (domain), generalized for effective use across that domain, and composed in a standardized structure (topology) effective for building successful applications. DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development. We can subdivide, too: Avionics systems -> Boeing Jets -> Boeing Domain-Specific Software Architectures Reference Architecture Example A DSSA comprises: A reference architecture, which describes a general computational framework for a significant domain of applications A component library, which contains reusable chunks of domain expertise, and An application configuration method for selecting and configuring components within the architecture to meet particular application requirements Examples: ADAGE for avionics, AIS for adaptive intelligent systems, and MetaH for missile guidance, navigation, and control systems Structural view of Lunar Lander DSSA Invariant with explicit points of variation Satellite relay Sensors 10
11 Reference Architecture Reference Architecture Reference Architecture MURA: Microsoft Upstream Reference Architecture DSSAs also include Extreme Case of DSSA... Product Line Architecture 11
12 Product Line Architecture Why? How do Product Lines come to be? Example: Lunar Lander Game Example: Lunar Lander Game Product Lines in the Lunar Lander Game Product Lines: Components, Features, Products 12
13 Better Representation: Variability Model DSSAs vs. Product Lines Architectural Patterns State-Logic-Display (a.k.a. Three-Tier Pattern) State-Logic-Display (a.k.a. Three-Tier Pattern) State-Logic-Display in Web Development 13
14 Tiers and Layers Model-View-Controller (MVC) Note: The middle tier might be multitiered (resulting in an n-tier architecture) Model-View-Controller (MVC) Do you recall...? Boundary = View Entity = Model Control = Controller Two Flavors of MVC: Passive Model Two Flavors of MVC: Active Model The passive model is employed when one controller manipulates the model exclusively. The controller modifies the model and then informs the view that the model has changed and should be refreshed. The model is completely independent of the view and the controller, i.e. there is no means for the model to report changes in its state. The HTTP protocol is an example of this. There is no simple way in the browser to get asynchronous updates from the server. The browser displays the view and responds to user input, but it does not detect changes in the data on the server. Only when the user explicitly requests a refresh is the server interrogated for changes. Solution: Observer Design Pattern! 14
15 Two Flavors of MVC: Active Model Observer Pattern: Benefits and Liabilities of MVC The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems. Benefits Figure shows the structure of the active MVC using Observer and how the observer isolates the model from referencing views directly. Liabilities Java code example: Patterns, Styles, and DSSAs Patterns Styles Patterns Pipes and filters Data abstraction and object-oriented organization Layered systems Repositories Event-based, implicit invocation... and many more Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission. Architectural patterns <> Architectural styles <> Design patterns. While architectural styles define the components and connectors possible within the system (more asking what? ), architectural patterns define the implementation strategies of those same components and connectors (a bit more on how? ). Example: Model-View-Controller (MVC) pattern At the same time, a good architecture will make use of design patterns (on a more fine-granular level) Example: Observer pattern used to implement (active) MVC pattern Different architectural styles will find different architectural and design patterns more or less helpful. Design Patterns The Observer Pattern A design pattern is a way of reusing abstract knowledge about a problem and its solution. A pattern is a description of the problem and the essence of its solution. It should be sufficiently abstract to be reused in different settings. Pattern descriptions usually make use of object-oriented characteristics such as inheritance and polymorphism. ELEMENTS: Name A meaningful pattern identifier. Problem description. Solution description (might have an example) Not a concrete design but a template for a design solution that can be instantiated in different ways. Benefits and Consequences The results and trade-offs of applying the pattern. Name: Observer Problem description Situations where multiple displays of state are needed. Solution description Separates the display of object state from the object itself. See UML description. Consequences Optimisations to enhance display performance are difficult. 15
16 Three Types of Patterns Benefits of Design Patterns Creational patterns: Deal with initializing and configuring classes and objects Structural patterns: Deal with decoupling interface and implementation of classes and objects Composition of classes or objects Behavioral patterns: Deal with dynamic interactions among societies of classes and objects How they distribute responsibility Observer Design patterns enable large-scale reuse of software architectures and also help document systems Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available Patterns help improve developer communication Pattern names form a common vocabulary Structure of Lecture 07 Architecture Evaluation/Analysis What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up Assess whether architecture allows system to meet certain quality goals e.g. regarding maintainability, modifiability, reliability, performance,... Note: the architecture is assessed, while we hope the results will hold for a system yet to be built Software architecture Properties implementation properties? System Qualities Analysis Techniques and Scenarios Exercise: Analyse of Alarm Clock Architectures Questioning techniques: how does the system react to various situations; often make use of scenarios Measuring techniques: rely on quantitative measures; architecture metrics, simulation, etc. Different types of scenarios, e.g. usecases, likely changes, stress situations, risks, far-into-the-future scenarios Which stakeholders to ask for scenarios? When do you have enough scenarios? Consider standard alarm clocks that you have seen. For this exercise, consider each of the following to be representative of an architectural style of alarm clocks: An LED alarm clock for a bedroom, A LCD travel alarm, An analog alarm clock (there are several varieties; choose one). 16
17 List of Analysis Methods Scenario-based Architecture Analysis Method (SAAM) SAAM (Scenario-based Architecture Analysis Method) SAAMER (Software Architecture Analysis Method for Evolution and Reusability) ATAM (The Architecture Trade-Off Analysis Method) SBAR (Scenario-Based Architecture Reengineering)... and many more... Describe architecture(s) Based on desired system qualities, develop scenarios for kinds of activities the system must support kinds of changes anticipated Classify scenarios in direct & indirect direct -- execution of scenario requires no change of architecture indirect execution of scenario requires change of architecture Evaluate indirect scenarios: list changes and estimate cost Reveal scenario interaction Overall evaluation Scenario-based Architecture Analysis Method (SAAM) List of scenarios U1 and M1 interact because they require changes to the same components Scenario-based Architecture Analysis Method (SAAM) Overview: SAAM inputs and activities Examples: User U1 wants to have added another feature Maintainer M1 wants to port the system to platform XYZ Maintainer M2 wants to change the look-and-feel of the GUI Goal: By analysing the extend and difficulty (cost) of required changes (indirect scenarios) as well as the extent of scenario interactions, SAAM allows an insight to the future product capabilities, if the given architecture is chosen. Conditions for Successful Architecture Analysis/Evaluation Clear goals and defined quality requirements for the architecture Controlled scope focus on most important goals and quality requirements Cost-effectiveness Key personnel availability e.g. for scenario dev. Competent evaluation team ideally independent from developers/owners of architecture Managed expectations Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture s and View Models Notation Patterns, Styles and DSSAs Analysis/Assessment Wrap-up 17
18 Why is Architecture Important? Further Reading Architecture is the vehicle for stakeholder communication Architecture manifests the earliest set of design decisions Constraints on implementation Dictates organizational structure Inhibits or enables quality attributes Architecture is a transferable abstraction of a system Product lines share a common architecture Allows for template-based development Basis for training Len Bass et al, Sofware Architecture in Practice, 2008 (3 rd edition). Jan Bosch, Design & Use of Software Architectures, Frank Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, Part II: George Fairbanks: Just Enough Software Architecture, Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, C. Hofmeister et al., Applied Software Architecture, Philippe B. Kruchten, The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November Mary Shaw and David Garlan, Software Architecture; Perspectives of an Emerging Discipline, Richard Taylor et al.: Software Architecture, University of California at Irvine, Lecture Ian Sommerville: Software Engineering, 9th edition, ( Hans van Vliet: Software Architecture, Free University of Amsterdam, Lecture Next Lecture Date/Time: Friday, 31-Oct, 14:15-16:00 Topic: Refactoring (and TDD) For you to do: Finish and submit Lab Task 4 18
MTAT Software Engineering
MTAT.03.094 Software Engineering Lecture 07: Architecture and Design Dietmar Pfahl Fall 2015 email: dietmar.pfahl@ut.ee ATI Päev 2015 ICS Day 2015 When? Friday, 16-Oct-2015, 14:00-17:00 http://www.cs.ut.ee/en/ics-day
More informationMTAT Software Engineering
MTAT.03.094 Software Engineering Lecture 07: Architecture and Design Part I Dietmar Pfahl Fall 2013 email: dietmar.pfahl@ut.ee Schedule of Lectures Week 01: Introduction to SE Week 02: Requirements Engineering
More informationSoftware Architecture
Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment
More informationMTAT Software Engineering
MTAT.03.094 Software Engineering Lecture 07: Architecture and Design Dietmar Pfahl Fall 2017 email: dietmar.pfahl@ut.ee Schedule of Lectures Week 01: Introduction to SE Week 02: Requirements Engineering
More informationSoftware architecture: Introduction
2IW80 Software specification and architecture Software architecture: Introduction Alexander Serebrenik This week sources Slides by Johan Lukkien and Rudolf Mak Software architecture Software architecture
More informationSoftware Architecture
Software Architecture Architectural Design and Patterns. Standard Architectures. Dr. Philipp Leitner @xleitix University of Zurich, Switzerland software evolution & architecture lab Architecting, the planning
More informationSoftware Architectures
Software Architectures Richard N. Taylor Information and Computer Science University of California, Irvine Irvine, California 92697-3425 taylor@ics.uci.edu http://www.ics.uci.edu/~taylor +1-949-824-6429
More informationIntroduction to software architecture Revision : 732
Introduction to software architecture Revision : 732 Denis Conan Septembre 2018 Foreword The content of these slides is extracted from the following references: L. Bass, P. Clements, and R. Kazman. Software
More informationCoordination Patterns
Coordination Patterns 1. Coordination Patterns Design Patterns and their relevance for Coordination Oscar Nierstrasz Software Composition Group Institut für Informatik (IAM) Universität Bern oscar@iam.unibe.ch
More informationSoftware architecture: Introduction
2IW80 Software specification and architecture Software architecture: Introduction Alexander Serebrenik This week sources Slides by Johan Lukkien and Rudolf Mak Software architecture Software architecture
More informationChapter 6 Architectural Design. Chapter 6 Architectural design
Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying
More informationCreating and Analyzing Software Architecture
Creating and Analyzing Software Architecture Dr. Igor Ivkovic iivkovic@uwaterloo.ca [with material from Software Architecture: Foundations, Theory, and Practice, by Taylor, Medvidovic, and Dashofy, published
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationArchitectures in Context
Architectures in Context Software Architecture Lecture 2 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Learning Objectives Understand architecture in its relation
More informationSOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA
SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA PURPOSE OF THIS CLASS An introduction to software architecture What is an architecture Why it is important How it is represented
More informationWhat is Software Architecture
What is Software Architecture Is this diagram an architecture? (ATM Software) Control Card Interface Cash Dispenser Keyboard Interface What are ambiguities in the previous diagram? Nature of the elements
More informationIntroduction to Modeling
Introduction to Modeling Software Architecture Lecture 9 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Objectives Concepts What is modeling? How do we choose
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationChapter 18. Software Reuse
Chapter 18 Software Reuse Ian Sommerville Lutz Prechelt Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 1 Objectives To explain the benefits of software reuse and some
More informationSoftware Architectures. Lecture 6 (part 1)
Software Architectures Lecture 6 (part 1) 2 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements
More informationCS560 Lecture: Software Architecture Includes slides by I. Sommerville
CS560 Lecture: Software Architecture 2009 Includes slides by I. Sommerville Architectural Design Design process for identifying the sub-systems making up a system and the framework for sub-system control
More informationWHAT IS SOFTWARE ARCHITECTURE?
WHAT IS SOFTWARE ARCHITECTURE? Chapter Outline What Software Architecture Is and What It Isn t Architectural Structures and Views Architectural Patterns What Makes a Good Architecture? Summary 1 What is
More informationArchitectural Styles. Software Architecture Lecture 5. Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Architectural Styles Software Architecture Lecture 5 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Object-Oriented Style Components are objects Data and associated
More informationDescribing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms?
Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? CIS 8690 Enterprise Architectures Duane Truex, 2013 Cognitive Map of 8090
More informationChapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design
More informationDesigning Component-Based Architectures with Rational Rose RealTime
Designing Component-Based Architectures with Rational Rose RealTime by Reedy Feggins Senior System Engineer Rational Software Rose RealTime is a comprehensive visual development environment that delivers
More informationLecture 13 Introduction to Software Architecture
Lecture 13 Introduction to Software Architecture Software Systems Design and Implementation ITCS/ITIS 6112/8112 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at
More informationArchitectural Blueprint The 4+1 View Model of Software Architecture. Philippe Kruchten
Architectural Blueprint The 4+1 View Model of Software Architecture Philippe Kruchten Model What is a model? simplified abstract representation information exchange standardization principals (involved)
More informationSoftware Architecture Modeling
1 / 28 Canonical s 2 / 28 George Fairbanks Software Architecture ing Domain Design Code rof. Cesare autasso http://www.pautasso.info cesare.pautasso@usi.ch @pautasso Boundary Internal Domain 3 / 28 roblem
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationMinsoo Ryu. College of Information and Communications Hanyang University.
Software Reuse and Component-Based Software Engineering Minsoo Ryu College of Information and Communications Hanyang University msryu@hanyang.ac.kr Software Reuse Contents Components CBSE (Component-Based
More informationAnalyzing the Product Line Adequacy of Existing Components
Analyzing the Product Line Adequacy of Existing Components Jens Knodel and Dirk Muthig Fraunhofer Institute for Experimental Software Engineering (IESE), Fraunhofer-Platz 1, D-67663 Kaiserslautern, Germany
More information1 Software Architecture
Some buzzwords and acronyms for today Software architecture Design pattern Separation of concerns Single responsibility principle Keep it simple, stupid (KISS) Don t repeat yourself (DRY) Don t talk to
More informationImplementing Architectures
Implementing Architectures Software Architecture Lecture 15 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Learning Objectives Formulate implementation as a mapping
More informationChapter 6 Architectural Design
Chapter 6 Architectural Design Chapter 6 Architectural Design Slide 1 Topics covered The WHAT and WHY of architectural design Architectural design decisions Architectural views/perspectives Architectural
More informationADD 3.0: Rethinking Drivers and Decisions in the Design Process
ADD 3.0: Rethinking Drivers and Decisions in the Design Process Rick Kazman Humberto Cervantes SATURN 2015 Outline Presentation Architectural design and types of drivers The Attribute Driven Design Method
More informationOverview (and reorientation) of SE
Overview (and reorientation) of SE Richard N. Taylor Institute for Software Research University of California, Irvine The Origins Many ideas originated in other (noncomputing) domains Software Engineers
More informationApplied Architectures, Part 2
Applied Architectures, Part 2 Lecture 18 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Decentralized Architectures Networked applications where there are multiple
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationLecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process
More informationQuality-Driven Architecture Design Method
Quality-Driven Architecture Design Method Matinlassi Mari, Niemelä Eila P.O. Box 1100, 90571 Oulu Tel. +358 8 551 2111 Fax +358 8 551 2320 {Mari.Matinlassi, Eila.Niemela}@vtt.fi Abstract: In this paper
More informationOT TU1 Software Architecture Using Viewpoints and Perspectives
Eoin Woods Artechra Limited OT2004 - TU1 Software Architecture Using Viewpoints and Perspectives Nick Rozanski French Thornton eoin.woods@ nick.rozanski@ artechra.com french-thornton.co.uk (C) 2004 Artechra
More informationICS 52: Introduction to Software Engineering
ICS 52: Introduction to Software Engineering Fall Quarter 2004 Professor Richard N. Taylor Lecture Notes Week 3: Architectures http://www.ics.uci.edu/~taylor/ics_52_fq04/syllabus.html Copyright 2004, Richard
More informationSeminar report Software reuse
A Seminar report On Software reuse Submitted in partial fulfillment of the requirement for the award of degree of Bachelor of Technology in Computer Science SUBMITTED TO: www.studymafia.com SUBMITTED BY:
More informationSoftware Architecture and Design I
Software Architecture and Design I Instructor: Yongjie Zheng February 23, 2017 CS 490MT/5555 Software Methods and Tools Outline What is software architecture? Why do we need software architecture? How
More informationApplication Architectures, Design Patterns
Application Architectures, Design Patterns Martin Ledvinka martin.ledvinka@fel.cvut.cz Winter Term 2017 Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design Patterns Winter Term
More informationINTERACTION ARCHITECTURAL MODELING. Lecture 9 Interaction Architectureal Modeling
User Centred Design 09 INTERACTION ARCHITECTURAL MODELING Lecture 9 Interaction Architectureal Modeling PREVIOUS LESSON(S) Synthetizing User Research Personas Actors / User Roles Scenarios Essential Use
More informationAn Introduction to Software Architecture. David Garlan & Mary Shaw 94
An Introduction to Software Architecture David Garlan & Mary Shaw 94 Motivation Motivation An increase in (system) size and complexity structural issues communication (type, protocol) synchronization data
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationICS 52: Introduction to Software Engineering
ICS 52: Introduction to Software Engineering Fall Quarter 2002 Professor Richard N. Taylor Lecture Notes Week 3: Architectures http://www.ics.uci.edu/~taylor/ics_52_fq02/syllabus.html Copyright 2002, Richard
More informationLOG8430: Architecture logicielle et conception avancée
LOG8430: Architecture logicielle et conception avancée Modeling, OO Concepts, and Design Patterns Winter 2018 Fabio Petrillo Chargé de Cours This work is licensed under a Creative 1 Commons Attribution-NonCommercialShareAlike
More informationLectures 24 and 25 Introduction to Architectural Styles and Design Patterns
Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More information5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered
Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process
More informationRequirements to models: goals and methods
Requirements to models: goals and methods Considering Garlan (2000), Kruchen (1996), Gruunbacher et al (2005) and Alter (2006-08) CIS Department Professor Duane Truex III Wojtek Kozaczynski The domain
More informationDog Houses to sky scrapers
CSC40232: SOFTWARE ENGINEERING Professor: Jane Cleland Huang Architecture Wednesday, April 19th sarec.nd.edu/courses/se2017 Department of Computer Science and Engineering Dog Houses to sky scrapers WHY
More informationWhat is your definition of software architecture?
What is your definition of software architecture? WHAT IS YOUR DEFINITION OF SOFTWARE ARCHITECTURE? The SEI has compiled a list of modern, classic, and bibliographic definitions of software architecture.
More informationFoundations of Software Engineering
Foundations of Software Engineering Lecture 8: Software Architecture II Christian Kästner (with slides by Ivan Ruchkin) 2 Learning Goals Understand key parts of architectural process Use architectural
More informationAn introduction to the IBM Views and Viewpoints Framework for IT systems
An introduction to the IBM Views and Viewpoints Framework for IT systems By Denise Cook, Software Engineer Peter Cripps, Senior IT Architect Philippe Spaas, Executive IT Architect IBM Corporation December
More informationTECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica
TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica Examination Architecture of Distributed Systems (2IMN10 / 2II45), on Monday November 2, 2015, from 13.30 to 16.30 hours. Indicate on
More informationPattern-Based Architectural Design Process Model
Pattern-Based Architectural Design Process Model N. Lévy, F. Losavio Abstract: The identification of quality requirements is crucial to develop modern software systems, especially when their underlying
More informationWhat is Software Architecture? What is Principal?
What is Software Architecture? Definition: A software system s architecture is the set of principal design decisions about the system Software architecture is the blueprint for a software system s construction
More informationSoftware Architecture. Lecture 5
Software Architecture Lecture 5 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics
More informationUsing the UML for Architectural Description Rich Hilliard
Using the UML for Architectural Description Rich Hilliard rh@isis2000.com Outline What is IEEE P1471? The IEEE P1471 Conceptual Framework Requirements on Architectural Descriptions Using the UML in the
More informationTopic : Object Oriented Design Principles
Topic : Object Oriented Design Principles Software Engineering Faculty of Computing Universiti Teknologi Malaysia Objectives Describe the differences between requirements activities and design activities
More informationDesign Patterns. Observations. Electrical Engineering Patterns. Mechanical Engineering Patterns
Introduction o to Patterns and Design Patterns Dept. of Computer Science Baylor University Some slides adapted from slides by R. France and B. Tekinerdogan Observations Engineering=Problem Solving Many
More informationWhat is a software architecture?
What is a software architecture? Peter Eeles, Senior IT Architect, IBM, 15 Feb 2006 There is no doubt that the world is becoming increasingly dependent on software. Software is an essential element of
More informationEPL603 Topics in Software Engineering
Lecture 5 Architectural Design & Patterns EPL603 Topics in Software Engineering Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740 Topics covered Software
More informationDesign Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1
What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely
More informationSommerville Chapter 6 The High-Level Structure of a Software Intensive System. Architectural Design. Slides courtesy Prof.
Sommerville Chapter 6 The High-Level Structure of a Software Intensive System Architectural Design Slides courtesy Prof.Mats Heimdahl 1 Fall 2 2013 Architectural Parallels Architects are the technical
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationConcurrent Object-Oriented Development with Behavioral Design Patterns
Concurrent Object-Oriented Development with Behavioral Design Patterns Benjamin Morandi 1, Scott West 1, Sebastian Nanz 1, and Hassan Gomaa 2 1 ETH Zurich, Switzerland 2 George Mason University, USA firstname.lastname@inf.ethz.ch
More informationReview Sources of Architecture. Why Domain-Specific?
Domain-Specific Software Architectures (DSSA) 1 Review Sources of Architecture Main sources of architecture black magic architectural visions intuition theft method Routine design vs. innovative design
More informationAn Introduction to Software Architecture By David Garlan & Mary Shaw 94
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion An Introduction to
More informationReview Software Engineering October, 7, Adrian Iftene
Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)
More informationEngr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Software Design and Architecture Software Design Software design is a process of problem-solving
More informationArchitectural Design. Architectural Design. Software Architecture. Architectural Models
Architectural Design Architectural Design Chapter 6 Architectural Design: -the design the desig process for identifying: - the subsystems making up a system and - the relationships between the subsystems
More informationSoftware Reuse and Component-Based Software Engineering
Software Reuse and Component-Based Software Engineering Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Contents Software Reuse Components CBSE (Component-Based Software Engineering) Domain Engineering
More informationImplementation Architecture
Implementation Architecture Software Architecture VO/KU (707023/707024) Roman Kern ISDS, TU Graz 2017-11-15 Roman Kern (ISDS, TU Graz) Implementation Architecture 2017-11-15 1 / 54 Outline 1 Definition
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationChapter 13: Architecture Patterns
Chapter 13: Architecture Patterns SAiP Chapter 13 J. Scott Hawker/R. Kuehl p. 1 Len Bass, Paul Clements, Rick Kazman, Topics What is a Pattern? Pattern Catalog Module patterns Component and Connector Patterns
More informationLecture 16: (Architecture IV)
Lecture 16: (Architecture IV) Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct.
More informationObjectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture
Objectives Architectural Design To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More informationDESIGN: ARCHITECTURE AND METHODOLOGY
DESIGN: ARCHITECTURE AND METHODOLOGY Software Engineering CS 130 Donald J. Patterson Content adapted from Essentials of Software Engineering 3rd edition by Tsui, Karam, Bernal Jones and Bartlett Learning
More informationVendor: The Open Group. Exam Code: OG Exam Name: TOGAF 9 Part 1. Version: Demo
Vendor: The Open Group Exam Code: OG0-091 Exam Name: TOGAF 9 Part 1 Version: Demo QUESTION 1 According to TOGAF, Which of the following are the architecture domains that are commonly accepted subsets of
More informationPresenter: Dong hyun Park
Presenter: 200412325 Dong hyun Park Design as a life cycle activity bonds the requirements to construction Process of breaking down the system into components, defining interfaces and defining components
More informationIntroduction. ADL Roles
Architecture Description Languages (ADLs) 1 Introduction Architecture is key to reducing development costs development focus shifts to coarse-grained elements Formal architectural models are needed ADLs
More informationbe used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate
UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,
More informationUnit Wise Questions. Unit-1 Concepts
Unit Wise Questions Unit-1 Concepts Q1. What is UML? Ans. Unified Modelling Language. It is a Industry standard graphical language for modelling and hence visualizing a blue print of all the aspects of
More informationArchitectural design
6 Architectural design Objectives The objective of this chapter is to introduce the concepts of software architecture and architectural design. When you have read the chapter, you will: understand why
More informationIntroduction to Software Engineering 10. Software Architecture
Introduction to Software Engineering 10. Software Architecture Roadmap > What is Software Architecture? > Coupling and Cohesion > Architectural styles: Layered Client-Server Blackboard, Dataflow,... >
More informationIntroduction to Design Patterns
Dr. Michael Eichberg Software Technology Group Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering Introduction to Design Patterns Patterns 2 PATTERNS A
More informationADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE
ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE Dave Clarke 1 THIS LECTURE At the end of this lecture you will know notations for expressing software architecture the design principles of cohesion
More informationESE Einführung in Software Engineering!
ESE Einführung in Software Engineering! 10. Software Architecture! Prof. O. Nierstrasz" Roadmap! > What is Software Architecture?" > Coupling and Cohesion" > Architectural styles:" Layered" Client-Server"
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures PART 1 ARCHITECTURAL DESIGN DECISIONS Recap on SDLC Phases
More informationOver All Idea about MVC: How to use Model- View-Controller (MVC)
Over All Idea about MVC: How to use Model- View-Controller (MVC) Parth Jivani B. H. Gardividyapith Engg. &Tech. Chhaya Chopara B. H. Gardividyapith Engg. & Tech. Mehta Prashant B. H. Gardividyapith Engg.
More informationImplementation Architecture
Implementation Architecture Software Architecture VO/KU (707023/707024) Roman Kern KTI, TU Graz 2014-11-19 Roman Kern (KTI, TU Graz) Implementation Architecture 2014-11-19 1 / 53 Outline 1 Definition 2
More informationINTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2
INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:
More informationITE 205 Software Design and Programming I
Computer Science Department cs.salemstate.edu ITE 205 Software Design and Programming I 4 cr. Catalog description: This course introduces a set of fundamental design principles and problem-solving techniques
More informationWhite Paper. Major Performance Tuning Considerations for Weblogic Server
White Paper Major Performance Tuning Considerations for Weblogic Server Table of Contents Introduction and Background Information... 2 Understanding the Performance Objectives... 3 Measuring your Performance
More informationApplying Experiences with Declarative Codifications of Software Architectures on COD
Applying Experiences with Declarative Codifications of Software Architectures on COD Position Paper Roel Wuyts Stéphane Ducasse Gabriela Arévalo roel.wuyts@iam.unibe.ch ducasse@iam.unibe.ch arevalo@iam.unibe.ch
More information