Software Design: The Next Step A presentation by Sean Matthews.

Slides:



Advertisements
Similar presentations
The Robert Gordon University School of Engineering Dr. Mohamed Amish
Advertisements

S Y S T E M S E N G I N E E R I N G.
Software Development Life Cycle
Alternate Software Development Methodologies
Chapter 2 Process Models
Rational Unified Process
SE curriculum in CC2001 made by IEEE and ACM: Overview and Ideas for Our Work Katerina Zdravkova Institute of Informatics
introduction to MSc projects
1 SWE Introduction to Software Engineering Lecture 5.
DEVELOPMENTAL RESEARCH  Mitch Kielb  Juanita Tilgner  Andy Sen.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
CAD/CAM Design Process and the role of CAD. Design Process Engineering and manufacturing together form largest single economic activity of western civilization.
Information Modeling: The process and the required competencies of its participants Paul Frederiks Theo van der Weide.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software Engineering Tools and Methods Presented by: Mohammad Enamur Rashid( ) Mohammad Rashim Uddin( ) Masud Ur Rahman( )
Computational Thinking Related Efforts. CS Principles – Big Ideas  Computing is a creative human activity that engenders innovation and promotes exploration.
Engineering Systems of.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Enhancing assessment capacity For teachers of Authority and Authority-registered subjects.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Software Engineering Reuse.
Rational Unified Process Fundamentals Module 4: Disciplines II.
Testing : A Roadmap Mary Jean Harrold Georgia Institute of Technology Presented by : Navpreet Bawa.
Chapter 2 소프트웨어공학 Software Engineering 임현승 강원대학교
Research in Computing สมชาย ประสิทธิ์จูตระกูล. Success Factors in Computing Research Research Computing Knowledge Scientific MethodAnalytical Skill Funding.
HCI in Software Process Material from Authors of Human Computer Interaction Alan Dix, et al.
Software development process ธนวัฒน์ แซ่ เอียบ. The development process Process –set of rules which define how a development project. Methodology and.
Cohesive Design of Personalized Web Applications Presented by Yinghua Hu Schwabe, D. Mattos Guimaraes, R. Rossi, G. Pontificia Univ. Catolica do Rio de.
Scientific Workflow Interchanging Through Patterns: Reversals and Lessons Learned Bruno Fernandes Bastos Regina Maria Maciel Braga Antônio Tadeu Azevedo.
John S Gero MIT Class Winter 2002 SITUATEDNESS.
An Introduction to Software Engineering. Communication Systems.
1 Introduction to Software Engineering Lecture 1.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
 What is Modeling What is Modeling  Why do we Model Why do we Model  Models in OMT Models in OMT  Principles of Modeling Principles of Modeling 
Basics of Research and Development and Design STEM Education HON4013 ENGR1020 Learning and Action Cycles.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
SE 361 Lecture-03. Science is defined as: a department of systematized knowledge as an object of study; knowledge or a system of knowledge covering.
Understanding and using patterns in software development EEL 6883 Software Engineering Vol. 1 Chapter 4 pp Presenter: Sorosh Olamaei.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Assoc. Prof. Dr. Ahmet Turan ÖZCERİT.  System and Software  System Engineering  Software Engineering  Software Engineering Standards  Software Development.
RE-ENGINEERING AND DOMAIN ANALYSIS BY- NISHANTH TIRUVAIPATI.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Introduction to Modeling Extracted from textbook: Object Oriented Modeling and Design with UML M. Blaha, J. Rumbaugh.
Is This a Pattern by Tiffany Winn Paul Calder Flinders University of South Australia.
February 19, February 19, 2016February 19, 2016February 19, 2016 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific.
Lectures 2 & 3: Software Process Models Neelam Gupta.
Introduction to Codes, Standards, and Regulations Chattanooga State CC.
Course: Software Engineering – Design I IntroductionSlide Number 1 What is a specification Description of a (computer) system, which:  is precise;  defines.
INTRODUCTION TO COGNITIVE SCIENCE NURSING INFORMATICS CHAPTER 3 1.
What is Research?. Intro.  Research- “Any honest attempt to study a problem systematically or to add to man’s knowledge of a problem may be regarded.
Planning Instruction A Review of the Cognitive Domain and Performance Objectives.
+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Design Pattern Support based on principles of model driven development Zihao Zhao.
Analysis and Critical Thinking in Assessment 1. What is the problem? Gathering information Using information to inform decisions/ judgment Synthesising.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
SYSE 802 John D. McGregor Module 0 Session 3 Systems Engineering QuickView.
CS646: Software Design and Architectures Introduction and Overview †  Definitions.  The general design process.  A context for design: the waterfall.
Chapter3:Software Processes
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Engineering Design Process
By Hyunsook Do, Sebastian Elbaum, Gregg Rothermel
System Analysis and Design:
Presentation transcript:

Software Design: The Next Step A presentation by Sean Matthews

Kruchen, P "Editor's Introduction: Software Design in a Postmodern Era." Software, IEEE 22 (2): Kruchten, P "Casting software design in the function-behavior-structure framework." Software, IEEE 22 (2):

Intro We’ve reached a plateau in software design We’ve reached a plateau in software design What are the next directions? What are the next directions? Where are we? Where are we? Where do we go from here? Where do we go from here?

Where are we? “…we can systematically harvest and organize our collective knowledge, experience, and wisdom– variously captured in design principles and heuristics, patterns, best practices, and bad smells– into a coherent whole.” “…we can systematically harvest and organize our collective knowledge, experience, and wisdom– variously captured in design principles and heuristics, patterns, best practices, and bad smells– into a coherent whole.”

Where do we go from here? We need to… We need to… Bridge the gap between user needs and the way we express requirements Bridge the gap between user needs and the way we express requirements Improve design analysis, validation, and verification techniques Improve design analysis, validation, and verification techniques Bridge the gap between design and code that programmers create manually Bridge the gap between design and code that programmers create manually

Requirements Engineering Design Coding

Where do we go from here? Expand the boundaries of software design to fill in the gaps Expand the boundaries of software design to fill in the gaps “When we program and test, we’re making decisions about the system under construction: this is doing design.” “When we program and test, we’re making decisions about the system under construction: this is doing design.” Design activities should be included in other parts of the software development process Design activities should be included in other parts of the software development process

Analogous situations To demonstrate how and why design should be combined with other phases of the SD process, the author casts it in a general, recently formulated engineering framework. To demonstrate how and why design should be combined with other phases of the SD process, the author casts it in a general, recently formulated engineering framework.

Functional-Behavior-Structure A development framework applicable to any engineering discipline A development framework applicable to any engineering discipline John Gero, design scientist John Gero, design scientist 8 processes link a set of five elements that lead us from a set of abstract functions to a design description 8 processes link a set of five elements that lead us from a set of abstract functions to a design description

Functional-Behavior-Structure FBS Elements FBS Elements F: functions F: functions Be: expected behaviors Be: expected behaviors Bs: behaviors (actual) Bs: behaviors (actual) S: synthesis S: synthesis D: documentation D: documentation

Functional-Behavior-Structure FBS Processes FBS Processes Formulation (F  Be) Formulation (F  Be) Synthesis (Be  S) Synthesis (Be  S) Analysis (S  Bs) Analysis (S  Bs) Evaluation (Be  Bs) Evaluation (Be  Bs) Documentation (S  D) Documentation (S  D) Structural reformulation (S  S) Structural reformulation (S  S) Behavioral reformulation (S  Be) Behavioral reformulation (S  Be) Functional reformulation (S  F) Functional reformulation (S  F)

FBS Framework

Applying FBS to SE “…design is making choices that will shape the final product.” “…design is making choices that will shape the final product.” Requirements, coding, and testing activities all involve some design Requirements, coding, and testing activities all involve some design Traditionally, design means “building a model of the system to be constructed up to the point at which coding can begin.” Traditionally, design means “building a model of the system to be constructed up to the point at which coding can begin.”

Applying FBS to SE

SE lessons from FBS Lack of fundamental theory Lack of fundamental theory Physics has its laws Physics has its laws Evaluation process is experimental Evaluation process is experimental Concrete S, almost no addition to D Concrete S, almost no addition to D

SE lessons from FBS Legacy systems Legacy systems D  S  Be  F D  S  Be  F Reuse Reuse F  Be  S F  Be  S “catalogue look-up” “catalogue look-up”

SE lessons from FBS Modeling Modeling …to automate the coding and deployment artifacts …to automate the coding and deployment artifacts …to describe a system’s expected behavior (Be), and thereby facilitate the synthesis (S) process …to describe a system’s expected behavior (Be), and thereby facilitate the synthesis (S) process

SE lessons from FBS Design patterns Design patterns If F 1 and Bs 1 = F 2 and Bs 2, then the designs are analogous If F 1 and Bs 1 = F 2 and Bs 2, then the designs are analogous We can communicate design fragments and share and reuse practical solutions for recurrent problems. We can communicate design fragments and share and reuse practical solutions for recurrent problems.

The BIG picture In software production, programming is primarily a design activity In software production, programming is primarily a design activity In software manufacturing it is not In software manufacturing it is not Decisions about structure and the way something is done Decisions about structure and the way something is done Also, testing to a smaller extent Also, testing to a smaller extent Assessment of test results determine whether design needs reworking Assessment of test results determine whether design needs reworking

Conclusions Generally, something gets lost between design and implementation. Generally, something gets lost between design and implementation. With FBS, design becomes part of coding and implementation. With FBS, design becomes part of coding and implementation. SE needs to find approaches to describing software that easily translate to static analysis and code generation. SE needs to find approaches to describing software that easily translate to static analysis and code generation.

Kruchen, P "Editor's Introduction: Software Design in a Postmodern Era." Software, IEEE 22 (2): Kruchten, P "Casting software design in the function-behavior-structure framework." Software, IEEE 22 (2): References