James Martin CpE 691 February 4, 2010.  Problem Overview  The pattern solution  Comparing patterns and decision  The pattern-decision relationship.

Slides:



Advertisements
Similar presentations
Chapter 4 Design Approaches and Methods
Advertisements

By Philippe Kruchten Rational Software
Documenting a Software Architecture By Eng. Mohanned M. Dawoud.
By Xiangzhe Li Thanh Nguyen.  Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
Applying Architectural Styles and Patterns. Outline  Defining Architectural Patterns and Style The activation model Styles and Quality Attributes  Common.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Oct. 30, 2003CS WPI1 CS 509 Design of Software Systems Lecture #9 Thursday, Oct. 30, 2003.
Software Architecture in Practice
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Chapter 10: Architectural Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 16 Slide 1 User interface design.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
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.
Architectural Design.
Product Evaluation the outcome phase. Do the magic bullets work? How do you know when an innovative educational program has “worked”? How do you know.
9/2/2015 | 1 Neil B. Harrison Paris Avgeriou University of Groningen Groningen, The Netherlands Incorporating Fault Tolerance Tactics in Software Architecture.
1 Design and Integration: Part 1 Nuggets about Design vs Project Management.
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
CPSC 871 John D. McGregor Module 4 Session 3 Architecture Evaluation.
Text CONSEG 09 Domain Knowledge assisted Requirements Evolution (K-RE)
An Introduction to Software Architecture
[ §3 : 1 ] 2. Life-Cycle Perspective Overview 2.1 Motivation 2.2 Waterfall Model 2.3 Requirements in Context.
Lecture 9: Chapter 9 Architectural Design
Secure Systems Research Group - FAU Classifying security patterns E.B.Fernandez, H. Washizaki, N. Yoshioka, A. Kubo.
Slide 1 Introduction to Software Architecture TV Prabhakar.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
Experimental Research Methods in Language Learning Chapter 16 Experimental Research Proposals.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
10 Software Architecture CSCU 411 Software Engineering.
Patterns and Reuse. Patterns Reuse of Analysis and Design.
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Design Process Overview. What is Design? The word “design” is often used as a generic term that refers to anything that was made by a conscious human.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
Software Engineering COSC 4460 Class 4 Cherry Owen.
Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns - Architectural Architectural Patterns:
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
Model View Controller MVC Web Software Architecture.
Software Architecture & Object Oriented Analysis
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
CSCI 578 Software Architectures Exam #1 Review. Materials you are responsible for Chapters 1-8 in the text book All lecture material up to but not including.
Software Architectural Views By the end of this lecture, you will be able to: list and describe the views in the 4+1 view model of software architecture.
John D. McGregor Architecture Evaluation
Software Architecture Transformation Jan Bosch Professor of Software Engineering University of Groningen, Netherlands
+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
1 of 9 DetaiLogic ™ Patent Pending Developer’s Introduction ■
Design Process Overview. A design process is a systematic problem-solving strategy, with criteria and constraints, used to develop many possible solutions.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
Basic Concepts of Software Architecture. What is Software Architecture? Definition: – A software system’s architecture is the set of principal design.
CSCI 578 Software Architectures
Master thesis: Automatic Extraction of Design Decision Relationships from a Task Management System Kick-Off Matthias Ruppel, 8th of May 2017, Munich.
Requirement Prioritization
Object-Oriented Software Engineering Using UML, Patterns, and Java,
CS 641 – Requirements Engineering
CS 641 – Requirements Engineering
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Ontology Evolution: A Methodological Overview
The Extensible Tool-chain for Evaluation of Architectural Models
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Introduction to Design Patterns Part 1
A Pattern Language for Software Architecture
CSCI 578 Software Architectures
Software Architecture
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
CSCI 578 Software Architectures
Presentation transcript:

James Martin CpE 691 February 4, 2010

 Problem Overview  The pattern solution  Comparing patterns and decision  The pattern-decision relationship  Using patterns  Limitations and further research 2

 Decisions made during software architecting have a substantial impact on the system  Design decisions aren’t documented by architects thoroughly enough by architects. ◦ All aspects (i.e. alternatives, rationale, expected consequences, etc) are not usually captured  Leads to “knowledge vaporization” 3

 Decisions are not recorded  Development and evolution cycles of software do not have appropriate access to decisions that were made during the architectural design  The decisions might reside in the heads of architects, but people eventually forget  “If something is not written down, it does not exist” 4

 It takes a lot of effort  Decisions are made without thought  Can be disruptive to the flow of design  Architects don’t know how 5

 A.K.A. architectural style  Patterns help document decisions because they: ◦ Include general structural and behavioral info ◦ When a pattern is chosen, a decision is made so it can be documented ◦ Architects already use patterns so they aren’t disruptive ◦ Patterns are typically easy to follow ◦ They are solutions to recurring problems 6

 Layers  Pipes and filters  Blackboard  Model-View-Controller (MVC)  Presentation-Abstraction-Control (PAC) 7

 Issue being decided  Decision that was made  Alternatives  Reasons for making the decision 8

Pattern sectionDecision Section Name ProblemIssue CategoryGroup Status ContextAssumptions, constraints Solution variants according to forcesPositions SolutionDecision RationaleImplications Resulting context / consequences Example, know issues Related patternsRelated decisions, requirements, artifacts, or principles Notes 9

 Two types of knowledge 1.Application-generic knowledge  Implicate knowledge gained through previous experiences (such as from patterns)  Used to make decisions 2.Application-specific knowledge  Involves decisions made during the architecting process, as well as the solutions  It is the decisions  Patterns comprise #1  Decisions comprise #2 10

 Architecting is decision-intensive  Making a lot of decisions means doing a lot of documentation  Using patterns helps alleviate the need for as much documentation since the documentation is implicit  When a pattern is selected the architectural decision is documented via the pattern’s usage 11

 Application specific decisions must still be documented  Not all decisions can be captured via patterns ◦ Organization decisions ◦ Financial decisions  Using multiple patterns together without understanding them can lead to conflicts  Why a decision was made is not documented via patterns 12