Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the.

Slides:



Advertisements
Similar presentations
Architecture Representation
Advertisements

Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Applying Architectural Styles and Patterns. Outline  Defining Architectural Patterns and Style The activation model Styles and Quality Attributes  Common.
Architectural Styles. Definitions of Architectural Style  Definition. An architectural style is a named collection of architectural design decisions.
Chapter 14: Design Method --- data and architectural design Design -- A multistep process in which representations of data structure, program structure,
Architecture-driven Modeling and Analysis By David Garlan and Bradley Schmerl Presented by Charita Feldman.
Unified Modeling (Part I) Overview of UML & Modeling
Establishing the overall structure of a software system
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Demystifying Architectural Styles Nikunj Mehta 3/11/02Demystifying Architectural Styles2 Architectural Styles Characterize –Structure, i.e. external.
Institute for Software Research©2001, University of California, Irvine Product-Line Architectures André van der Hoek Institute for Software Research University.
Course Instructor: Aisha Azeem
Chapter 10: Architectural Design
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
System Design & Software Architecture
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Architectural Design.
What is Software 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.
Chapter 6 – Architectural Design Lecture 2 1Chapter 6 Architectural design.
Chapter 10 Architectural Design
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
CS451 Lecture 13: Architectural Design Chapter 10
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
An Introduction to Software Architecture
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
1 Chapter 14 Architectural Design 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
1 5/18/2007ã 2007, Spencer Rugaber Software Architecture (Informal Definition) The organization of a system into component subsystems or modules Box and.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
Lecture 9: Chapter 9 Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
SOFTWARE DESIGN.
Slide 1 Introduction to Software Architecture TV Prabhakar.
Chapter 13 Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Developing Component- Based Systems X LIU, School of Computing, Napier University TIP This chapter discusses the techniques to develop component-based.
Unit 2 Architectural Styles and Case Studies | Website for Students | VTU NOTES | QUESTION PAPERS | NEWS | RESULTS 1.
ARCHITECTURAL DESIGN. Why is Architecture Important? Representations of software architecture are an enabler for communication between all parties (stakeholders)
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,
CSC480 Software Engineering Lecture 10 September 25, 2002.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
CS223: Software Engineering
Chapter 13 설계 개념 Architectural Design 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software Engineering: A Practitioner’s.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
1 Chapter : Architecture & User Interface Design.
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
1 Chapter 2: Architectural Design. 2 Introduction Structure or structures of the system, which comprise software components, the externally visible properties.
Chapter 13 Architectural Design
Architectural Design.
Software Design and Architecture
Chapter 13 Architectural Design
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Chapter 9 Architectural Design
Software Architecture
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Chapter 13 Architectural Design
An Introduction to Software Architecture
Chapter 9 Architectural Design.
Chapter 5 Architectural Design.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 10 Architectural Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For.
Presentation transcript:

Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.

Why is Architecture Important? Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system. The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity. Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”.

Why is Architecture Important? It is important to start reasoning about the system as early as possible The architectural specification helps us see a match between the requirements a certain set of constraints before identifying concrete solutions

Architecture definition Perry, Wolf: Elements Elements processing elements (data transformer) processing elements (data transformer) data elements (data) data elements (data) connecting elements (glue that holds pieces together) connecting elements (glue that holds pieces together) Form Form weighted properties and relationships weighted properties and relationships constraints for choice of elements and placement constraints for choice of elements and placement Rationale Rationale motivation for choices

Architecture vs design Architecture – concerned with the selection of architectural elements, their interactions, and the constraints on those elements and interactions to provide a framework in which to satisfy the requirements and serve as basis for the design Design - concerned with the modularization and detailed interfaces and procedures, and the data types needed to support the architecture and to satisfy the requirements

Uses for Architectural specification Prescribe the architectural constraints to the desired level (specify the constraints and their generalization level instead of specific solutions) Separate aesthetics from engineering (load-bearing vs decoration) Express different aspects of the architecture in an appropriate manner Perform dependency and consistency analysis (requirements, architecture, design must be consistent, their interdependencies specified)

Architectural style Architecture can be thought of as a formal arrangement of architectural elements; a specific architecture Style – less constrained, less complete; a template architecture

Architectural erosion and drift Evolution and customization – major contributors to software cost Due to problems with architecture: erosion – violations of architectural constraints, leads to disasters drift – lack of coherence and clarity of form, leads to inadaptability

Shaw and Garlan[‘96] define architecture in terms of design elements and the constraints on the elements, but differ from Perry and Wolf in that the elements are: components and connectors, described in some idiom specific manner. Idioms are represented as topologies of the component/connector vocabulary, along with constraints on how the topologies can be arranged. Shaw and Garlan have developed a taxonomy based on case studies of actual systems. The eventual goal is to develop a handbook for the selection and application of appropriate styles. Taxonomy of styles

Shaw & Garlan Taxonomy

Data Flow style: Batch Sequential - each step runs to completion; old style data processing architecture Pipes and Filters - linked stream transformers Each filter is a stand-alone process that incrementally transforms its input streams into output streams. Call and Return style: Main program and subroutines - traditional functional decomposition, a controlling main program determines flow of control Hierarchical layers - well defined interfaces and information hiding (e.g., kernels, shells) Object-oriented systems - abstract data types with inheritance; objects only interact through defined interfaces Common Architectural Styles

Independent Components style: Communicating processes - asynchronous message passing Event systems - implicit invocation; rather than invoking a procedure directly, a component generates a request for service event that is broadcast Virtual Machines style: Interpreters - input driven state machine Rule-based systems - rule based interpreter Data-centered systems: Transactional Database Systems - central data repository/query driven Blackboards - central shared representation/opportunistic execution Common Architectural Styles

Distributed Processes and Client/Servers Processes connected by a specific communication topology (ring, star, etc.) along with protocols for communication. Servers don't know their clients beforehand, while clients can dynamically chose among servers. Client-server interactions can be direct - where the client activates the server directly (for example by calling the server as a procedure) polled - where the client indicates that it would like a service and the server periodically checks to see if any client requests are pending. interrupt driven - where the server is dormant, and the client generates an event that eventually activates the server. Common Architectural Styles

Model, View, Controller Typical paradigm of user interface design. The underlying element is modeled by some object. Various representations of this object are presented through views. Alterations of the state of the object are achieved through controllers. State Transition Systems Standard design of many reactive systems. Process Control Systems Dynamic control via feedback loops. Heterogeneous Common Architectural Styles

Control Equations Inputs Outputs Control Feedback (monitor pressure & temperature) (set control valves and pumping rates) Process control architecture

Systems are not usually developed according to a single, consistent idiom. Variations may occur at different levels of refinement/abstraction. Combining styles

Architectural idioms need not be constrained to usage within system development. They can also serve as tools for the analysis of system design. For example, a natural language processing system viewed through the interpreter and blackboard idioms. Reference Architectures

Organizes a description of software architecture using five concurrent views. Architects capture their design decisions in four views and use the fifth to illustrate and validate the other four. 4+1 View of Architecture

The 4 Views  The logical view describes the design's object model when an object-oriented design method is used. To design an application that is very data-driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. [Use UML Class Diagram]  The process view describes the design's concurrency and synchronization aspects. [Use UML Collaboration Diagram/ Sequence Diagram]  The development view describes the software's static organization in its development environment. [Use UML Component Diagram]  The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. [No UML Counterpart]

Logical View

Process View

Development View

Physical View

Some architecture description languages C2ADL (UCI, ) xArch (UCI) xADL (UCI) ACME (CMU, ) Wright (CMU) adapting UML adapting other formal languages (e.g. Z)

Architectural Styles Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

Data-Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism operating system process management pattern task scheduler pattern Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common: a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture an application level persistence pattern that builds persistence features into the application architecture Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment A broker acts as a ‘middle-man’ between the client component and a server component.

Place of architecture It is important to start reasoning about the system as early as possible The architectural specification helps us see a match between the requirements a certain set of constraints before identifying concrete solutions