Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.

Slides:



Advertisements
Similar presentations
Dr. Rogelio Dávila Pérez
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Privacy By Design Draft Privacy Use Case Template
Software Architecture in Practice (3 rd Ed) Understanding Quality Attributes Understanding the following: How to express the qualities we want our architecture.
Software Process Models
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 1998 by Carnegie Mellon.
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
Encapsulation. Encapsulation Encapsulation means the bringing together of a set of attributes and methods into an object definition and hiding their implementational.
The Architecture Design Process
SE 555 Software Requirements & Specification Requirements Management.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Software Architecture in Perspective SENG 480/580 (H. Muller) Today: Margaret-Anne Storey
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Software Architecture in Practice
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Systems.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
Software Architecture for DSD The “Uses” Relation.
What is Software Architecture?
Software Architecture in Practice (3rd Ed) Introduction
Chapter 10 Architectural Design
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
An Introduction to Software Architecture
The Architecture Business Cycle. Software Architecture Definition The software architecture of a program or computing system is the structure or structures.
Architecture Business Cycle
Chapter 2 Process: A Generic View
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
1 Introduction to Software Architectures Lecture - 3.
SOFTWARE DESIGN.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Drexel University CS 451 Software Engineering Winter Yuanfang Cai Room 104, University Crossings
SE: CHAPTER 7 Writing The Program
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
CSE 303 – Software Design and Architecture
Overview of SAIP and LSSA. Software Architecture in Practice Provides a set of techniques, not a prescriptive method for architectural design. Based on.
Requirements Analysis
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Wrap up. Structures and views Quality attribute scenarios Achieving quality attributes via tactics Architectural pattern and styles.
 System Requirement Specification and System Planning.
Unit-1 INTRODUCTION Presented by Sushma Narasimhan Asst. Professor,
Chapter 7: Modifiability
CompSci 280 S Introduction to Software Development
The Systems Engineering Context
Software Quality Engineering
Software Product Lines
Software Configuration Management
Software Requirements analysis & specifications
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Systems Architecture and Engineering
Presentation transcript:

Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003

Architecture The result of technical, business, and social influences and it is a crucial part of the system design process The result of technical, business, and social influences and it is a crucial part of the system design process The realization of early design decisions made with respect to the various parts of a system The realization of early design decisions made with respect to the various parts of a system Serves as an important communication, reasoning, analysis, and growth tool for systems Serves as an important communication, reasoning, analysis, and growth tool for systems

The Architecture Business Cycle (ABC) The relationship among the technical, business and social environments that subsequently influence future architecture The relationship among the technical, business and social environments that subsequently influence future architecture Influencing factors include organizational goals, business and technical requirements and processes that bring about new organizational capabilities Influencing factors include organizational goals, business and technical requirements and processes that bring about new organizational capabilities

Software Architecture Concerns the structure of large software systems Concerns the structure of large software systems Architectural view is an abstraction that distills away details of implementation, algorithm and data representation and concentrates on the behavior and interaction of “black-box” components Architectural view is an abstraction that distills away details of implementation, algorithm and data representation and concentrates on the behavior and interaction of “black-box” components Developed as the initial step toward designing a system that has a collection of desired properties Developed as the initial step toward designing a system that has a collection of desired properties

Software Architecture (cont’d) Consists of software components, the externally visible properties of those components and the relationships between them Consists of software components, the externally visible properties of those components and the relationships between them The earliest artifact that enables the priorities among competing concerns to be analyzed The earliest artifact that enables the priorities among competing concerns to be analyzed

Feedback mechanisms The architecture can affect the business goals of the developing organization. The architecture can affect the business goals of the developing organization. The architecture can affect the customer requirements for the ensuing system by presenting the customer with an opportunity to receive an upgraded system in a more reliable, timely and economical manner. The architecture can affect the customer requirements for the ensuing system by presenting the customer with an opportunity to receive an upgraded system in a more reliable, timely and economical manner. The system building process will affect the architect’s experience by adding to the corporate experience base. The system building process will affect the architect’s experience by adding to the corporate experience base.

Feedback mechanisms (cont’d) A few systems will influence and actually change the software engineering culture and technical environment. A few systems will influence and actually change the software engineering culture and technical environment.

Activities involved in creating a software architecture Creating the business case for the system Creating the business case for the system Understanding the requirements Understanding the requirements Creating or selecting the architecture Creating or selecting the architecture Representing and communicating the architecture Representing and communicating the architecture Analyzing or evaluating the architecture Analyzing or evaluating the architecture Implementing the system based on the architecture Implementing the system based on the architecture Ensuring that the implementation conforms to the architecture Ensuring that the implementation conforms to the architecture

Process Recommendations The architecture should be the product of a single architect or a small group with an identified leader. The architecture should be the product of a single architect or a small group with an identified leader. The architect (or team) should have the technical requirements for the system and an articulated, prioritized list of qualitative properties that the architecture is expected to satisfy. The architect (or team) should have the technical requirements for the system and an articulated, prioritized list of qualitative properties that the architecture is expected to satisfy. The architecture should be well documented using an agreed on notation that all stakeholders can understand. The architecture should be well documented using an agreed on notation that all stakeholders can understand.

Process Recommendations (cont’d) The architecture should be circulated to the system’s stakeholders, who should be actively involved in its review. The architecture should be circulated to the system’s stakeholders, who should be actively involved in its review. The architecture should be analyzed for applicable quantitative measures and formally reviewed for qualitative properties before it is too late to make changes to it. The architecture should be analyzed for applicable quantitative measures and formally reviewed for qualitative properties before it is too late to make changes to it. The architecture should lend itself to implementation via the creation of a “skeletal” system in which the communication paths are exercised but which at first has minimal functionality. The architecture should lend itself to implementation via the creation of a “skeletal” system in which the communication paths are exercised but which at first has minimal functionality.

Process Recommendations (cont’d) The architecture should result in a specific and small set of resource contention areas, the resolution of which are clearly specified, circulated, and maintained. The architecture should result in a specific and small set of resource contention areas, the resolution of which are clearly specified, circulated, and maintained.

Structural Recommendations The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns. The architecture should feature well-defined modules whose functional responsibilities are allocated on the principles of information hiding and separation of concerns. The modules should allow development teams to work largely independently of each other. The modules should allow development teams to work largely independently of each other. The information-hiding modules should include those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the software from platform changes. The information-hiding modules should include those that encapsulate idiosyncrasies of the computing infrastructure, thus insulating the software from platform changes.

Structural Recommendations (cont’d) The architecture should never depend upon a particular version of a commercial product or tool. The architecture should never depend upon a particular version of a commercial product or tool. Modules that produce data should be separate from modules that consume data to increase modifiability. Modules that produce data should be separate from modules that consume data to increase modifiability. Every task or process should be written so that its assignment to a specific processor can be easily changed even at run time. Every task or process should be written so that its assignment to a specific processor can be easily changed even at run time.

Conclusion