John D. McGregor Class 4 – Initial decomposition

Slides:



Advertisements
Similar presentations
A component- and message-based architectural style for GUI software
Advertisements

CPSC 875 John D. McGregor Wrap-up. Model-driven development (MDD) Model-driven development refers to a development approach that focuses on models as.
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
Software Architecture Design Instructor: Dr. Jerry Gao.
Lecture 23: Software Architectures
Establishing the overall structure of a software system
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
Objectives The key roles an architecture description plays in a software project. The key roles an architecture description plays in a software project.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Chapter 6: Architectural Design
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
What is Software Architecture?
Software Architecture in Practice (3rd Ed) Introduction
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CPSC 372 John D. McGregor Module 3 Session 2 Architecture Analysis/Design.
CPSC 872 John D. McGregor Session 16 Design operators.
CS451 Lecture 13: Architectural Design Chapter 10
Architectural Design. Recap Introduction to design Design models Characteristics of good design Design Concepts.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 13Slide 1 Architectural Design u Establishing the overall structure of a software system.
1 CMPT 275 High Level Design Phase Architecture. Janice Regan, Objectives of Design  The design phase takes the results of the requirements analysis.
An Introduction to Software Architecture
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
Architectural Design To explain the advantages and disadvantages of different distributed systems architectures To discuss client-server and distributed.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architecture styles Pipes and filters Object-oriented design Implicit invocation Layering Repositories.
CPSC 875 John D. McGregor C9 - Tactics. Everything is a plugin.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Styles.
What is Software Architecture? | Website for Students | VTU NOTES | QUESTION PAPERS | NEWS | RESULTS Chapter 2, Authors: Len Bass, Paul,
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
Software Architectural Styles Andrew Midwinter, Mark Mullen, Kevin Wong, Matt Jones 1.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
An Introduction to Software Architecture Software Engineering Lab.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
 Repository Model  Client-Server Model  Layered Model  Modular decomposition styles  Object Models  Function Oriented Pipelining  Control Styles.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
1 CMPT 275 High Level Design Phase Modularization.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
CPSC 875 John D. McGregor C9 - Tactics. Tactics A tactic is a transformation Given that the pre-condition of the tactic is true The tactic defines changes.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 1 after designing to meet functional requirements, design the system.
Chapter 7: Architectural Design Chapter 11 in textbook 1.
CSC480 Software Engineering Lecture 10 September 25, 2002.
CPSC 875 John D. McGregor Design Concept. Functional decomposition.
Overview of SAIP and LSSA. Software Architecture in Practice Provides a set of techniques, not a prescriptive method for architectural design. Based on.
Lecture VIII: Software Architecture
CS223: Software Engineering Lecture 13: Software Architecture.
Architectural Mismatch: Why reuse is so hard? Garlan, Allen, Ockerbloom; 1994.
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
CPSC 875 John D. McGregor Design Concept C5. ALISA
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Wrap up. Structures and views Quality attribute scenarios Achieving quality attributes via tactics Architectural pattern and styles.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
CPSC 875 John D. McGregor C8 - Tactics. Everything is a plugin.
SOFTWARE DESIGN AND ARCHITECTURE
Software Design and Architecture
Part 3 Design What does design mean in different fields?
John D. McGregor Quality attributes
John D. McGregor C8 - Tactics
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Software Architecture
Software models - Software Architecture Design Patterns
An Introduction to Software Architecture
John D. McGregor Design Concept C5
Software Architecture
Design Yaodong Bi.
John D. McGregor Quality attributes
Presentation transcript:

John D. McGregor Class 4 – Initial decomposition CpSc 875 John D. McGregor Class 4 – Initial decomposition

Ground station Relays signals between satellites and ground controllers It has to be: very fast and very reliable.

Example architecture Satellite ground station Bus architecture Any module on the bus can communicate with any other Modifiability +

Ground station design principles One look at qualities But there are more formal ones.

Quality attributes IEEE Std. 1061 subfactors: Efficiency                                    Portability • Time economy                           • Hardware independence • Resource economy                    • Software independence Functionality                               • Installability • Completeness                            • Reusability • Correctness                              Reliability • Security                                    • Non-deficiency • Compatibility                             • Error tolerance • Interoperability                          • Availability Maintainability                           Usability • Correctability                             • Understandability • Expandability                             • Ease of learning • Testability                                  • Operability                                                   • Comunicativeness http://en.wikipedia.org/wiki/ISO/IEC_9126

Qualities Trade-offs (a trade off is when one quality degrades another quality as the first quality increases Testability & modifiability Performance and modularity Develop a catalog of trade-offs

Perspectives on quality The executive The customer The developer The tester

Quality without a name Naming something denotes certain properties more than others. By not putting into words what we see or feel about this scene we allow each viewer to emphasize what is important to them.

Standard architecture structures Module structures Which piece is responsible for what Component and connector structures How do the major pieces interact at runtime Allocation structures Associates pieces of the architecture with pieces of the external environment

Module structures Decompose – module into sub modules. Pieces related to the whole Uses – one module expects another to be present Layered – decomposition in which there is an ordering Class – specialization relationships module decomposition class uses layered

Decomposition Taking one big thing and making it several smaller things The relationships among these pieces determines what qualities the design enhances and which it degrades. Other operations such as combination also affect the product qualities.

Component and Connector Client/server – multiple modules go to a common module for the same action Concurrency – logical threads Process – actual threads/ processes of the system Shared Data – how is data stored and accessed Component and Connector Client/server Shared data process concurrency

Allocation structures work assignment– module assigned to a team deployment – which processor has which threads implementation – where in CM are the files for this module allocation Work assignment implementation deployment

Architecture Styles Greek Revival French Colonial Queen Anne

Architectural styles Set of element types A topological layout Pipes and filters A topological layout A pipe connects two filters Set of semantic constraints A filter transforms its inputs to create its outputs Set of interaction mechanisms The output of a filter is carried in a pipe to another filter

Client/server Server provides some service that we wish to keep centralized. Many clients may all go to the same source for a function Client Server

c/s example User in one place Code in another

Layered style Functionality is divided into buckets The buckets are arranged in a hierarchy Data and control can flow up and down the hierarchy Functionality in a bucket may only invoke functionality in an adjacent bucket

Layered style Example: OSI network protocol stack each layer provides a specific type of network service. It illustrates why groups of related protocols are frequently called protocol stacks

Pipe and filter style "The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data [are] passed through pipes between adjacent filters. Recombining filters allows you to build families of related filters." [Buschmann] Example: ray tracer

Ray tracing architecture Each step has a specific purpose Each step can be developed independently Each step can be replaced or modified independently (assuming the results are the same type of information)

Similar The layered and pipe and filter styles are very similar What could be different between them? It isn’t geometry obviously

GUI design Separates the data model from the means of viewing it Interaction is handled by the controller(s) Data is presented in the view(s) Multiple views can register with the model. The model does not know how many views are registered. There is one or more controllers associated with each view. http://martinfowler.com/eaaDev/uiArchs.html

Model-View-Controller View and Controller are used to create specialized Views and Controllers which can be polymorphically substituted Reading is the model of a reading from some sensor

Model-View-Controller This shows normal operation Update – is the way Reading notifies Views when new data is available Perform – the Views are asking the Model to do some standard action

Infotainment A start Many competing architectures

Next steps Form a team of two or three. Each take on the identity of one of the stakeholders for the product (auto maker rep, developer, project manager, architect). Each of you create a list of quality attributes in priority order based on your role. Submit by 6 am Thursday Feb 3. Share use cases in your group. Consolidate a single set of use cases.