CpSc 875 John D. McGregor C11 - Documentation. 2 sources Clements et al. – book that describes an approach called Views and Beyond IEEE 1471 adopted standard.

Slides:



Advertisements
Similar presentations
Kellan Hilscher. Definition Different perspectives on the components, behavioral specifications, and interactions that make up a software system Importance.
Advertisements

Software Architecture Lecture 2
Modelling Class T05 Conceptual Modelling – Domain References: –Conceptual Modeling of Information Systems (Chapters 1.2.1, 2, 3) –A practical Guide to.
INFO 425 Week 31 INFO 425 Design Problem I Week 3 – SDS Improvements Glenn Booker.
March R McFadyen1 Architecture Architecture involves the set of significant decisions about the organization of a software system, decisions.
UML – Class Diagrams.
CPSC 875 John D. McGregor C15 – Variation in architecture.
WKES 3202 SOFTWARE REQUIREMENTS ENGINEERING SEMESTER 1 SESSION 2004/2005.
Site Skin Structure Services Space plan Stuff Software Architecture and Software Architecture Patterns (1)
The Use of Zachman Framework Primitives for Enterprise Modeling
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Software Architecture in Practice
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
A Survey of Software Architecture Viewpoint Models Nicholas May
Developing Enterprise Architecture
Documenting Software Architectures
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Lesson 7 Guide for Software Design Description (SDD)
CPSC 872 John D. McGregor Session 16 Design operators.
An Introduction to Software Architecture
Software Requirements Engineering CSE 305 Lecture-2.
Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 Architecture: Component and Deployment Diagrams Patrick Bailey Keith Vander Linden Calvin College.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 27. Review UML dynamic view – State Diagrams.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
10 Software Architecture CSCU 411 Software Engineering.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Documenting Software Architectures 1.Uses and Audiences for Architecture Documentation Architecture documentation serves as a means of education Architecture.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
CPSC 372 John D. McGregor Module 3 Session 5 Assignment and References.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 2: Introduction to Object-Oriented Systems Analysis.
John D. McGregor Class 4 – Initial decomposition
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Concern Architecture View and Aspect-Oriented Design Mika Katara and Shmuel Katz Tampere U. T. Technion, Haifa.
1 OO Analysis & Design - Introduction to main ideas in OO Analysis & design - Practical experience in applying ideas.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 2: Introduction to Object-Oriented Systems Analysis.
CPSC 875 John D. McGregor C15 – Variation in architecture.
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
AutoDESA Presentation Project Documentation October 2005.
1 Here are some quotations to get an overview of the kinds of issues of interest.
CPSC 871 John D. McGregor Module 8 Session 3 Assignment.
Basic Concepts and Definitions
4+1 View Model of Software Architecture
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
Outlines Overview Defining the Vision Through Business Requirements
Foundations, Theory, and Practice Software Architecture Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Basic.
Documenting an Architecture 10 pages, half pictures.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
Documenting Software Architectures. Outline  Introduction  Uses of Architectural Documentation  Views  Choosing the Relevant Views  Documenting a.
1 IS 0020 Program Design and Software Tools Unified Modeling Language Lecture 13 November 30, 2004.
CpSc 875 John D. McGregor C11 - Documentation. Stock trading system trading-system-architecture- post/#prettyPhoto[slides]/7/
IEC TC3 Blank Detail Specification
Software Architecture and Quality BY
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Rumbaugh’s Objectmodeling Technique
OO Methodology OO Architecture.
Software Architecture Lecture 2
Software Architecture and
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Documenting an Architecture
An Introduction to Software Architecture
Requirements Document
John D. McGregor C15 – Variation in architecture
Presentation transcript:

CpSc 875 John D. McGregor C11 - Documentation

2 sources Clements et al. – book that describes an approach called Views and Beyond IEEE 1471 adopted standard Results in a two volume set of documentation. See the reference at the end of the slides to the pedagogical product line and follow the link to see an example two volume set.

Views and Viewpoints

Viewpoint Presents the information in the architecture from a certain perspective That is, it emphasizes certain aspects of the architecture over other aspects Example, the specification viewpoint shows the spec without showing the implementations available

Viewpoint define the types of elements, the relations among them, the significant properties they exhibit, and the constraints they obey for views conforming to this viewpoint. The basic structures in an architecture are one source of viewpoints Module viewpoint – Shows an individual module and information about that module

View Applies a viewpoint to the architecture for a specific stakeholder Every stakeholder should have at least one view that speaks to their concerns The view should put the information into context but not confuse the reader with extraneous material

View For example, a user interface designer would want a view that shows each module used in the interface from the viewpoint of that module’s definition.

View Name of view View description Primary presentation List of view packets Element catalog Context diagram Variability mechanisms Architecture background

View Packet Primary Presentation Element Catalog Properties of the elements Relations and their properties Element interfaces Element behavior Context Diagram Variation Guide Architecture Background Rationale. Analysis results. Assumptions. Other Information Related View Packets

Example Module Decomposition View In this section, we describe the basic structure of an AGM game. Game variations are addressed by substitution, parameterization, and specialization. Game-specific behaviors are provided by game-specific implementations of the interfaces in this document. Module Decomposition View Packet 1: Game The previous figure shows the Game component as the representation for the generic product. The following figure shows that component's interface as the top-level interface of the system (defined in the GameBoard Interface section) and the other major interfaces that are at the first level of decomposition within the GameInterface (defined later in this document). GameBoard Interface

Primary presentation

Elements and Responsibilities for Model Decomposition View Packet 1: Game ElementResponsibilities GameBoard interface This container component holds all the elements needed for the game. ScoreBoard interface This interface keeps and presents the score as the game specifies. It is defined in the ScoreBoard Interface section.ScoreBoard Interface SpeedControl interface This interface controls how often a tick is issued to the GameBoard. It is defined in the SpeedControl Interface section.SpeedControl Interface Element Catalog Elements and their properties. The following table displays element details. Relations and their properties. The primary relation is composition. Game is responsible for creating, managing, and killing the elements it composes.

Relations and their properties. The primary relation is composition. Game is responsible for creating, managing, and killing the elements it composes. Element interfaces. Game interface is the program's GUI. It provides the user with Game start, stop, pause, and save behaviors. The other interfaces are documented as follows: GameBoard SpeedControl ScoreBoard Element behavior. The behavior is the game that is displayed to the user. Context Diagram Game is the top level of the product and the top-level context. Variation Guide Game and ScoreBoard will each be replaced by a game-specific implementation as described in the Module Generalization View section.Module Generalization View

Variation Guide Game and ScoreBoard will each be replaced by a game-specific implementation as described in the Module Generalization View section.Module Generalization View Architecture Background Game encapsulates game-specific behavior. It arranges the GameBoard, keeps score, and determines the won/lost status based on its rules. The composed elements are mostly generic and can be reused and rearranged to implement other games. Other Information No other information applies. Related View Packets Module Generalization View Packet 1: Game ScoreBoard Interface

Next steps Read m m Select the “download the template” link on: / Here is example documentation for the pedagogical product line architecture: Fill in the template for your architecture and submit by 11:59pm March 2 nd