Page 1 6/30/2015 Reconciling Systems, Software, and other Architectures Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation © 2008 The.

Slides:



Advertisements
Similar presentations
Outline About author. The problem that discussed in the article.
Advertisements

Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Development and Use of Architectures in System Engineering Rosalind Lewis USC-CSSE Workshop October 2007 © 2007 The Aerospace Corporation Motivated by.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Domain-Specific Software Engineering Alex Adamec.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
What is Software Architecture?
Software Architecture in Practice (3rd Ed) Introduction
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
ECE 355: Software Engineering
The Rational Unified Process
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
An Introduction to Software Architecture
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
INT-Evry (Masters IT– Soft Eng)IntegrationTesting.1 (OO) Integration Testing What: Integration testing is a phase of software testing in which.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architecting Web Services Unit – II – PART - III.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
10 Software Architecture CSCU 411 Software Engineering.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Chapter 7 System models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
University of Windsor School of Computer Science Topics in Artificial Intelligence Fall 2008 Sept 11, 2008.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Basic Concepts and Definitions
4+1 View Model of Software Architecture
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Software Design and Architecture Muhammad Nasir Software Architecture Documentation
OBJECT ORIENTED VS STRUCTURED WHICH ONE IS YOUR CHOICE.
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.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Integration Testing.
Architecting Web Services
IS301 – Software Engineering Dept of Computer Information Systems
Architecting Web Services
OO Methodology OO Architecture.
CS701 SOFTWARE ENGINEERING
Chapter 13 Logical Architecture.
CS 425/625 Software Engineering Architectural Design
Chapter 13 Logical Architecture.
An Introduction to Software Architecture
PPT and video are due no later than February 15, 2019
Chapter 11: Integration- and System Testing
From Use Cases to Implementation
Chapter 13 Logical Architecture.
Presentation transcript:

Page 1 6/30/2015 Reconciling Systems, Software, and other Architectures Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation © 2008 The Aerospace Corporation,

Page 2 6/30/2015 Topics To Consider l Reconciliation of what? »Of “Architectures” (treated as decisions)? »Of “Architecture Descriptions?” »Of programs and processes? l A discussion of the need to “reconcile system and software architectures” may be something of a cover for a variety of problems »A desire for common notations and tools (whether needed or not) »Poor compatibility between basic architectural decisions about the software with basic architectural decisions about the hardware within the system being developed »Poor compatibility between basic architectural decisions about the program with basic architectural decisions about the system being developed »Inefficient ordering of information developed in software-centric systems l We’ll consider the major cases in turn

Page 3 6/30/2015 Architecture and Program Sequence l Take software- centric or intensive as meaning 70-80% of development is spent on software development l Then, architecting of software will/must start early, before systems engineering is complete, and will be very enduring l Needs at system level induced by software architecture should have priority

Page 4 6/30/2015 Top Down vs Bottom Up Architecting l Stakeholders »Stakeholder Concerns »System level use-cases and objectives l Software architecture »Identification of the logical structure of the software »Concurrency and synchronization requirements, induced by software boundary Objectives-driven Function-centric Value-based invariants Design-needs-driven Object-centric Design-based invariants Many areas likely to gap Typically poor attention to HW/SW drivers Mismatched SE and SW-Architecture order

Page 5 6/30/2015 Program and System l Systems engineering classically looks in physically oriented hierarchies l Software is now more typically structured in layers »At least in modern, complex systems l What happens when the WBS is written to follow the systems hierarchy, not the software layers? l Classic example of mismatch of the structure of the program (via the system) with the structure of the software to be developed by the program

Page 6 6/30/2015 Which are the Subsystems? Backbone Interface Layer Shared Functions Platform Unique

Page 7 6/30/2015 The Four Way Tension Organization Who’s doing what? One or several? What are they good/bad at? What is their “strategic identity?” System What are we building? What are the key tech decisions? What are the components? How is it tested? Problem What are we doing? What delivers value? What is the environment? What is success? Program How do we build/operate? Separation of responsibilities

Page 8 6/30/2015 A Little Exercise Question l What aspects of the problem domain lead you to make a decision in favor of incremental development? »What aspects of the problem domain lead you to make a decision to avoid any sort of incremental development? l Given that you want an incremental development architecture for the program… »How does it (should it) change the architecture of the system? What system architectures are “consistent” with incremental development, and which ones are not? »How does it change design decisions in supporting areas (e.g. testing, verification, validation)? »How does it effect the organization that carries out development and the supported missions?

Page 9 6/30/2015 Notations and Methods l Lack of attention to notations and methods may be the problem l Or, too much attention to notations and methods may be the problem »Can’t fix bad decisions by changing the description framework l And…it can also be part of a solution l The “right” notation can directly incorporate the bottom-up concerns of software developers l The right notation composition rules can support explicit layering, and parallel subsystem decomposition l The right descriptions can highlight issues between the system and program

Page 10 6/30/2015 Some Pieces to Use Hard-coupled Push Hard-coupled Pull Soft-coupled Push Soft-coupled Pull Queued Transfer Blocking Push Blocking Pull

Page 11 6/30/2015 Conclusions l Bringing architecture (and architecture description) together among systems and software is important stuff l But…the systems/software divide is only part of the story l Consider from the position of fundamentals »Things (software, systems, programs) have architectures. Those architectures are formed from the basic structural decisions. »Compatibility means (largely) consistent, coherent decisions between and among those levels –Between hardware and software –Between problem and system-solution –Between system, program, and organization »Compatibility of “architecture descriptions,” (models and documents) also is an issue »Good choices in tools and methods can help with compatibility, but isn’t a panacea