Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004.

Slides:



Advertisements
Similar presentations
Database System Concepts and Architecture
Advertisements

By Philippe Kruchten Rational Software
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 6, System Design Lecture 1 Utdrag ur Bruegges OH-bilder för första.
Conquering Complex and Changing Systems Object-Oriented Software Engineering TJSS System Design Lecture 12 Päivi Ovaska.
© 2005 Prentice Hall7-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Design Creative Process of transferring the problem into a solution
Component-Level Design
Designing the system Conceptual design and technical design
Moving from Analysis to Design. Overview ● What is the difference between analysis and design? ● Logical v. physical design ● System v. detailed design.
System Design: Decomposing the System
Feb. 2, 2004CS WPI1 CS 509 Design of Software Systems Lecture #3 Monday, Feb. 2, 2004.
1 System Design: Addressing Design Goals We are starting from an initial design, along with a set of design goals. What is the next step?
Oct. 9, 2003CS WPI1 CS 509 Design of Software Systems Lecture #6 Thursday, Oct. 9, 2003.
CS CS 5150 Software Engineering Lecture 13 System Architecture and Design 1.
Oct. 2, 2003CS WPI1 CS 509 Design of Software Systems Lecture #5 Thursday, Oct. 2, 2003.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
Ch 6: Sys. Architecture Design: System Decomposition
March 22, 2004CS WPI1 CS 509 Design of Software Systems Lecture #9 Monday, March 22, 2004.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering October 10, 2001 System.
Feb. 20, 2001CSci Clark University1 CSci 250 Software Design & Development Lecture #11 Tuesday, Feb. 20, 2001.
1 A Student Guide to Object- Orientated Development Chapter 9 Design.
System Design Decomposing the System. Sequence diagram changes UML 2.x specifications tells that Sequence diagrams now support if-conditions, loops and.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Chapter 6: Architectural Design
System Design & Software Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 1 The Systems.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system design 1 what is systems design? preparation of the system’s specifications with.
Chapter 10 Architectural Design
The Design Discipline.
Software Waterfall Life Cycle Requirements Construction Design Testing Delivery and Installation Operations and Maintenance Concept Exploration Prototype.
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
Addressing design Goals  We decompose the system to address complexity  Assigning each subsystem to team to work on  But we also need to address system.
RUP Design RUP Artifacts and Deliverables
4/2/03I-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Software Architecture and Design Readings: Ambler, Chap. 7 (Sections to start.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 6 System Design: Decomposing the System.
CEN Advanced Software Engineering
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 CMPT 275 High Level Design Phase Modularization.
Design CIS 4800 Kannan Mohan Department of CIS Zicklin School of Business, Baruch College Copyright © 2009 John Wiley & Sons, Inc. Copyright © 2008 Course.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system architecture 1 after designing to meet functional requirements, design the system.
Lecture 18: Object-Oriented Design
 Design goals are derived form the non- functional requirements  Every subsystem is assigned to a team and realized independently  During system design,
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 6, System Design Lecture 1.
March 1, 2004CS WPI1 CS 509 Design of Software Systems Lecture #6 Monday, March 1, 2004.
Chapter : 9 Architectural Design
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 6, System Design Lecture 1.
Oct. 16, 2003CS WPI1 CS 509 Design of Software Systems Lecture #7 Thursday, Oct. 16, 2003.
Introduction. System Design Hardware/Software Platform Selection Software Architectures Database Design Human-Computer Interaction (HCI) Interface Object.
System Architecture CS 560. Project Design The requirements describe the function of a system as seen by the client. The software team must design a system.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
Chapter 6 System Design: Decomposing the system. What is system design  Decompose the system into smaller subsystems  Define the design goals of the.
CS 325: Software Engineering
Review for Final, Fall 2010 Close book, Close notes
Software models - Software Architecture Design Patterns
CHAPTER 9 (part a) BASIC INFORMATION SYSTEMS CONCEPTS
Addressing Design Goals
Decomposing the System
Design Yaodong Bi.
Chapter 6: Architectural Design
Design.
Presentation transcript:

Feb. 9, 2004CS WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004CS WPI2 §Term Project Administration §Questions §Quiz #2 §Review of Chapters 6 & 7: §Design Exercises: l Discuss how to organize design documentation l Begin CTS system design Class Format for Today

Feb. 9, 2004CS WPI3 CTS Project & Questions §Phase 2 (Functional Specs) documents and Project Journals are due today. §Hand out Phase 3 (Design) assignment §Questions? l About Term Project l From last week’s class l From the reading l Anything else?

Feb. 9, 2004CS WPI4 Quiz #2 Chapters 3, 5, 6 You have 15 minutes

Feb. 9, 2004CS WPI5 Chapter 6 System Design: Decomposing the System

Feb. 9, 2004CS WPI6 Intro to System Design §Define design goals of system §Decompose system into smaller subsystems §Select strategies for building system: l Hardware & software l Persistent data management l Global control flow l Access control policies l Handling of boundary conditions

Feb. 9, 2004CS WPI7 Purpose of System Design §Make trade-off decisions: l Identify & prioritize qualities to optimize l Decide how to achieve various goals l Goals may conflict with each other §Produce design model of system including: l System decomposition addressing design goals l Description of design strategies

Feb. 9, 2004CS WPI8 Overview of System Design §Design goals derived from nonfunctional req’s §Software architecture describes decomposition: l Subsystem responsibilities l Dependencies among subsystems l Mappings to hardware l Policy decisions (control flow, access control, etc.) §Boundary use cases: l Config, startup, shutdown, exception handling

Feb. 9, 2004CS WPI9 System Design Concepts §Decomposition: l Subsystems, Packages, Classes §Services & subsystem interfaces §Coupling vs. Cohesion §Layering and Partitioning §Architectural Styles

Feb. 9, 2004CS WPI10 Decomposition §What’s the difference between a Subsystem and a Package? §How many subsystems or packages do we need? §What classes make up a subsystem/package? §Where do we draw the lines?

Feb. 9, 2004CS WPI11 Services & Interfaces §A subsystem is characterized by the services it provides to other subsystems. §A service is a set of related operations that share a common purpose. §Examples of types of services? l What operations are involved? §Interface independent of implementation, often defined during Object Design

Feb. 9, 2004CS WPI12 Coupling and Cohesion §Coupling measures dependencies between 2 subsystems §Cohesion measures dependencies among classes within a subsystem l Want to minimize coupling and maximize cohesion l How can we do both? How are they related?

Feb. 9, 2004CS WPI13 Layers & Partitions §Both are ways to manage complexity §Layers are hierarchical; partitions are not §Each layer uses services provided by which other layer(s)? §Layers have no knowledge of which other layer(s)? §Difference between open and closed architectures?

Feb. 9, 2004CS WPI14 Architectural Styles §Repository §Model-View-Controller (MVC) §Client-server §Peer-to-peer §Tiered styles (3-tier, 4-tier) §Pipe and filter

Feb. 9, 2004CS WPI15 Chapter 7 System Design: Addressing Design Goals

Feb. 9, 2004CS WPI16 Activities Overview §Select off-the-shelf and legacy components §Mapping of subsystems to hardware §Design of persistent data management §Specification of access control policy §Design of global control flow §Handling of boundary conditions §Reviewing system design

Feb. 9, 2004CS WPI17 Select Existing Components §What is a legacy component? l How do we know if it’s useful? §Other pre-existing components l 3 rd party packages may need to be “wrapped” What does this mean? §What are the trade-offs? §Does building a component cost more than buying it?

Feb. 9, 2004CS WPI18 Mapping to Platform §Select deployment hardware configuration l “Who” is responsible for which functionality? l How is communication realized? §Select software platform: l Operating system l Virtual machine for development l Other needed SW components §Reliability and performance issues

Feb. 9, 2004CS WPI19 Persistent Data §Data that outlives a single run of the system §Identification of storage subsystem(s) l What data should be persistent? l Where and how is data stored? l How is it retrieved? (Who has access to what?) §Storage management strategies: l Flat files (serialization), RDBMS, OODB, etc.

Feb. 9, 2004CS WPI20 Access Control Policy §Shared objects are protected to control use l How is access specified and realized? l Impacts how objects are distributed §Policy should be consistent system-wide l User roles & authentication Who has access to what, how are users identified? l Who can change access rights / privileges l Data encryption, etc. §Use cases can help define policy

Feb. 9, 2004CS WPI21 Global Control Flow §Determine sequence of operations from 3 types: l Procedure-driven Operations wait for input from user Top-down, step-by-step, pre-defined flow Well suited to procedural or functional languages l Event-driven Flow determined by user action at run time Better suited to object-oriented languages l Multi-threaded (concurrent) Handle > 1 user or system interaction at the same time Requires language support

Feb. 9, 2004CS WPI22 Boundary Conditions §System initialization, startup and shutdown §Detection & handling of exceptional cases l Hardware failures including system crash, data corruption, network outages l Changes in operating environment l User errors such as data input §Impossible to anticipate all SW failures l Can anticipate some unusual circumstances l Handle in an appropriate way – “nice” messages

Feb. 9, 2004CS WPI23 Reviewing System Design §Peer review helps ensure quality of design §Strive for following properties: l Correct – based on req’s & analysis l Complete – all req’s & design issues addressed l Consistent – model contains no contradictions l Realistic – possible to implement system l Readable / understandable

Feb. 9, 2004CS WPI24 Design Exercise CTS System Design

Feb. 9, 2004CS WPI25 Meeting Agenda §Objective: l Get started on system design of CTS §Tasks: l How to organize design documentation l Who will design what l Discuss system design goals §Request for volunteer: l To record minutes

Feb. 9, 2004CS WPI26 For Next Time §No class next week (2/16) – Presidents Day §Read Chapters 8 & 9 – Object Design §Begin working on System Design document §Next class (2/23) l Quiz #3 on Chapters 7, 8, 9 l Lecture on Object Design l More in-class work on design documents