Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
ZEIT2301 Design of Information Systems Behavioural Design: State Machines School of Engineering and Information Technology Dr Kathryn Merrick.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
ICE1341 Programming Languages Spring 2005 Lecture #5 Lecture #5 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Problem Frames 8 - Variant frames. Variants Model Operator Description Connection Control.
CHAPTER 3 COLLECTIONS Abstract Data Types. 2 A data type consists of a set of values or elements, called its domain, and a set of operators acting on.
Communication Notation Part V Chapter 15, 16, 18 and 19.
Knowledge Acquisitioning. Definition The transfer and transformation of potential problem solving expertise from some knowledge source to a program.
CS 425/625 Software Engineering System Models
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models September 29, 2008.
1 Institute for Software Research, International Methods of Software Development Problem Frames 1 (This lecture is largely based on material graciously.
Unified Modeling (Part I) Overview of UML & Modeling
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
Foundations This chapter lays down the fundamental ideas and choices on which our approach is based. First, it identifies the needs of architects in the.
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 2: Jackson Problem Frames Rob DeLine 31 Mar 2004 Thanks.
USE Case Model.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
Chapter 5 – System Modeling
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
October 2002J. B. Wordsworth: J2ISDPPS1 Information Systems Development Problem Frames: Problems and Subproblems.
Lecture 9: Chapter 9 Architectural Design
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 Object-oriented and Structured System Models.
Approaching a Problem Where do we start? How do we proceed?
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
1 Institute for Software Research, International Methods of Software Development Problem Frames 2 (This lecture is largely based on material graciously.
March 5, ICE 1341 – Programming Languages (Lecture #4) In-Young Ko Programming Languages (ICE 1341) Lecture #4 Programming Languages (ICE 1341)
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 15: Object-Oriented Data Modeling Modern Database Management 9 h Edition Jeffrey A.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 8: Analysis Modeling Software Engineering: A Practitioner’s Approach, 6/e Chapter.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
What is Object-Oriented?  Organization of software as a collection of discreet objects that incorporate both data structure and behavior.
Modelling Class T07 Conceptual Modelling – Behaviour References: –Conceptual Modeling of Information Systems (Chapters 11, 12, 13 and 14)
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
CS251 – Software Engineering Lecture 9: Software Design Slides by Mohammad El-Ramly, PhD
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
 Week08.  Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST Engineering Quality Systems.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 Click to edit Master title style What is Business Analysis Body of Knowledge?
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Appendix Object-Oriented Analysis and Design: Use Cases and Sequence Diagrams Modern Systems Analysis and Design Fifth Edition Jeffrey A. Hoffer Joey F.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 14 Slide 1 Object-Oriented Design.
Chapter 4 – System Modeling Lecture 1 1Chapter 5 System modeling.
Chapter 5 – System Modeling Lecture 1 1Chapter 5 System modeling.
1 Ivan Marsic Rutgers University LECTURE 13: Problem Frames Part II: Modeling & Recombination.
CompSci 280 S Introduction to Software Development
Chapter 5 – System Modeling
Object-Oriented Analysis and Design
System Modeling Chapter 4
Informatics 121 Software Design I
Chapter 20 Object-Oriented Analysis and Design
Chapter 4 System Modeling.
Presentation transcript:

Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture #11 Problem Frames II

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Announcements Please check the updated course schedule Please check the updated course schedule 11/8 & 11/11: No fall recession, regular classes will be held 11/8 & 11/11: No fall recession, regular classes will be held 11/18: No class 11/18: No class 11/25: Special session: Software Engineering Economics 11/25: Special session: Software Engineering Economics 12/13: Regular class 12/13: Regular class 12/16: No class 12/16: No class

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Picture of the Day: PNC Park

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University The One-way Traffic Lights Problem Lights regime Light units Lights controller a: LC! {Rpulse[i], Lpulse[i] b: LU! {Stop[I], Go[I]} a b Is this Designed? Given? Machine? Causal? Biddable? Lexical? Static? Dynamic? Discrete? Continuous? Active? Passive? Reactive? The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Lights controller Is this Designed? Given? Machine? Causal? Biddable? Lexical? Static? Dynamic? Discrete? Continuous? Active? Passive? Reactive? Lights regime Light units a: LC! {Rpulse[i], Lpulse[i] b: LU! {Stop[I], Go[I]} a b The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. The One-way Traffic Lights Problem

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Highlights of problem frames Highlights of problem frames Separation of concerns as a way to manage complexity Separation of concerns as a way to manage complexity Expertise as a large body of knowledge Expertise as a large body of knowledge Language as a way to describe phenomena Language as a way to describe phenomena Abstraction as a way to manage detail Abstraction as a way to manage detail The relation between requirement and specification The relation between requirement and specification Types as a way to identify allowable operations Types as a way to identify allowable operations Revisit language, associate types with primitives Revisit language, associate types with primitives Template matching as a way to search alternatives Template matching as a way to search alternatives Types to judge how tight the fit is Types to judge how tight the fit is State transition models as a way to describe activity State transition models as a way to describe activity Relation to individual scenarios, cases Relation to individual scenarios, cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Frame Concerns Chapter 5 of Problem Frames deals with how you argue the correctness of your analysis Chapter 5 of Problem Frames deals with how you argue the correctness of your analysis You ’ ll see similarities to the ADT example You ’ ll see similarities to the ADT example You ’ ll also see how this associates semantics with a diagram formulated in the problem frame language You ’ ll also see how this associates semantics with a diagram formulated in the problem frame language The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Lights regime Light units Lights controller … we’ll be sure the resuming lights sequence will be this [rqt] 3 … knowing that the light units work like this, … [domain] 2 We will build the machine to behave like this, so that … [spec] 1 The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University. The One-way Traffic Lights Problem

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Simple Workpieces Frame Concern Data entry rules Medical staff PREdit machine Periods & ranges When the user issues this command, it may be out of context or syntactically incorrect, then … [rqt] 1 …in that case the machine will reject it … [spec] 2 … or ignore it if it isn’t viable, or else invoke these operations … [spec] 3 … resulting in this change of workpiece values and states … [dom] 4 … thus achieving the desired result in every case [rqt] 5 Correct editing John & Lucy Party editor Party plan The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Highlights of problem frames Highlights of problem frames Separation of concerns as a way to manage complexity Separation of concerns as a way to manage complexity Expertise as a large body of knowledge Expertise as a large body of knowledge Language as a way to describe phenomena Language as a way to describe phenomena Abstraction as a way to manage detail Abstraction as a way to manage detail The relation between requirement and specification The relation between requirement and specification Types as a way to identify allowable operations Types as a way to identify allowable operations Revisit language, associate types with primitives Revisit language, associate types with primitives Template matching as a way to search alternatives Template matching as a way to search alternatives Types to judge how tight the fit is Types to judge how tight the fit is State transition models as a way to describe activity State transition models as a way to describe activity Relation to individual scenarios, cases Relation to individual scenarios, cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Programming Languages, Revisited A symbolic language has syntax A symbolic language has syntax Primitive elements (entities) Primitive elements (entities) Primitive operations (things you can do to entities) Primitive operations (things you can do to entities) Encapsulation and composition mechanism Encapsulation and composition mechanism Extension mechanism (a way to add new primitives) Extension mechanism (a way to add new primitives) To be useful, it also has semantics To be useful, it also has semantics Rules for relating consequences within the language to consequences in the larger world Rules for relating consequences within the language to consequences in the larger world Types provide a way to distinguish entities that allow different operations Types provide a way to distinguish entities that allow different operations The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Domain Types Domain: {Problem, Machine} [p21] Domain: {Problem, Machine} [p21] Set of related phenomena treated as a unit Set of related phenomena treated as a unit Problem = {Designed, Given, Connection, [more later]} Problem = {Designed, Given, Connection, [more later]} Role of designer: Role of designer: constructs machine, constructs machine, creates representation for designed, creates representation for designed, accepts given, accepts given, interposes connection between machine & problem domain interposes connection between machine & problem domain Domain types: {Causal, Biddable, Lexical} [p83] Domain types: {Causal, Biddable, Lexical} [p83] Causal: predictable causal relations among causal phenomena Causal: predictable causal relations among causal phenomena Biddable: physical but not fully predictable Biddable: physical but not fully predictable Lexical: physical (symbolic) representation of data Lexical: physical (symbolic) representation of data The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Domain Flavors Domain characteristics need finer discriminations to describe the particular needs of various frames [p145] Domain characteristics need finer discriminations to describe the particular needs of various frames [p145] Static: structural distinctions (e.g. sequence, tree) useful in lexical and some causal (static physical) domains Static: structural distinctions (e.g. sequence, tree) useful in lexical and some causal (static physical) domains Dynamic: small-scale, short-term behavioral differences Dynamic: small-scale, short-term behavioral differences {Robust, Inhibiting, Fragile} behavior {Robust, Inhibiting, Fragile} behavior {Continuous, Discrete} behavior {Continuous, Discrete} behavior Control: larger-scale behavior {Active, Passive} + Control: larger-scale behavior {Active, Passive} + Informal: things that make formal reasoning hard Informal: things that make formal reasoning hard Conceptual: things that are inconveniently subjective Conceptual: things that are inconveniently subjective The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Domain Descriptions Domain descriptions: {Indicative, Optative} Domain descriptions: {Indicative, Optative} Problem domain descriptions are indicative (descriptive) Problem domain descriptions are indicative (descriptive) Machine domain descriptions are optative (prescriptive) Machine domain descriptions are optative (prescriptive) Domain characteristics: {Active, Autonomous, Inert (Passive)} Domain characteristics: {Active, Autonomous, Inert (Passive)} Active: can initiate activity (events, state changes) without external stimulus from another domain [p93] Active: can initiate activity (events, state changes) without external stimulus from another domain [p93] Autonomous: active, and nothing outside affects it [p93] Autonomous: active, and nothing outside affects it [p93] Inert: may react to external events, does not initiate – domains with passive states [p97] Inert: may react to external events, does not initiate – domains with passive states [p97] Informal domains: no exact descriptions [p124] Informal domains: no exact descriptions [p124] The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Phenomena Phenomena = {Individuals, Relations} [p78] Phenomena = {Individuals, Relations} [p78] Individuals = {Entities, Events, Values} Individuals = {Entities, Events, Values} Relations = {Roles, States, Truths} Relations = {Roles, States, Truths} Most common: {Events, Values, States} Most common: {Events, Values, States} {Causal, Symbolic} phenomena [83] {Causal, Symbolic} phenomena [83] Causal: events, roles, or states relating entities Causal: events, roles, or states relating entities Symbolic: values, truths, states relating only values Symbolic: values, truths, states relating only values {Specification, Requirement} phenomena {Specification, Requirement} phenomena Specification: shared with problem machine Specification: shared with problem machine Requirement: subject of requirement references Requirement: subject of requirement references Interfaces are physical sharing of phenomena Interfaces are physical sharing of phenomena The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Today ’ s Plan Highlights of problem frames Highlights of problem frames Separation of concerns as a way to manage complexity Separation of concerns as a way to manage complexity Expertise as a large body of knowledge Expertise as a large body of knowledge Language as a way to describe phenomena Language as a way to describe phenomena Abstraction as a way to manage detail Abstraction as a way to manage detail The relation between requirement and specification The relation between requirement and specification Types as a way to identify allowable operations Types as a way to identify allowable operations Revisit language, associate types with primitives Revisit language, associate types with primitives Template matching as a way to search alternatives Template matching as a way to search alternatives Types to judge how tight the fit is Types to judge how tight the fit is State transition models as a way to describe activity State transition models as a way to describe activity Relation to individual scenarios, cases Relation to individual scenarios, cases The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Frame Signatures Problem FrameProblem Domain Characteristics Required behavior1 causal Commanded behavior1 causal, 1 biddable Information display2 causal Simple workpieces1 lexical, 1 biddable Transformation2 lexical Patient monitoring, periods and ranges1 lexical, 1 biddable Domain mismatch indicates the frame isn ’ t applicable, BUT match does not assure the frame is applicable The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Next Weeks For Tuesday (10/18): For Tuesday (10/18): Read Jackson, Ch Read Jackson, Ch We ’ ll skip 7-9, though you may need to refer to those We ’ ll skip 7-9, though you may need to refer to those Tuesday (10/18): Tuesday (10/18): Finding the subproblems in a larger problem Finding the subproblems in a larger problem Framing them individually Framing them individually Fitting them together to solve the main problem Fitting them together to solve the main problem Tuesday (10/25): Tuesday (10/25): Problem frames for your studio problem Problem frames for your studio problem Use Sec 10.2 as a template Use Sec 10.2 as a template The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Fall ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University Questions??