Design Recovery 1 Informatics 122 Alex Baker. What is Design Recovery? Sort of like reverse engineering.

Slides:



Advertisements
Similar presentations
1 CS Tutorial 2 Architecture Document Tutorial.
Advertisements

Software Engineering 2003 Jyrki Nummenmaa 1 A BASIC OO SOFTWARE DEVELOPMENT PROCESS Earlier, we saw a number of different software lifecycle models.
CHAPTER 1 SOFTWARE DEVELOPMENT. 2 Goals of software development Aspects of software quality Development life cycle models Basic concepts of algorithm.
Software Engineering COMP 201
© 2009 University of California, Irvine – André van der Hoek1February 8, 2009 – 21:49:30 Informatics 122 Software Design II Lecture 9 André van der Hoek.
Week 2 Design Examples and Designing for Change Alex Baker.
© 2009 University of California, Irvine – André van der Hoek1June 13, 2015 – 18:19:12 Informatics 122 Software Design II Lecture 5 André van der Hoek &
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
© 2010 University of California, Irvine – André van der Hoek1June 14, 2015 – 15:24:35 Informatics 121 Software Design I Lecture 11 André van der Hoek &
Software Evolution Managing the processes of software system change
© 2009 University of California, Irvine – André van der Hoek1June 15, 2015 – 20:01:34 Informatics 122 Software Design II Lecture 1 André van der Hoek &
Week 8 Implementation Design Alex Baker. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what.
CS CS 5150 Software Engineering Lecture 13 System Architecture and Design 1.
Super-Design Informatics 122 Alex Baker. System Design Arch. Imp. Design Code In this class we’ve gone…
Design Recovery II Informatics 122 Alex Baker. Cake Recovery – Opinions? How difficult was this? Why?
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
© Copyright Eliyahu Brutman Programming Techniques Course.
(c) 2010 University of California, Irvine – André van der Hoek1June 29, 2015 – 08:55:05 Informatics 122 Software Design II Lecture 8 André van der Hoek.
An Introduction to Software Visualization Dr. Jonathan I. Maletic Software DevelopMent Laboratory Department of Computer Science Kent State University.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
CSC230 Software Design (Engineering)
The Re-engineering and Reuse of Software
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Software Development Concepts ITEC Software Development Software Development refers to all that is involved between the conception of the desired.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 1: Introduction.
1 Design and Integration: Part 1 Nuggets about Design vs Project Management.
Databases From A to Boyce Codd. What is a database? It depends on your point of view. For Manovich, a database is a means of structuring information in.
Lesson 7 Guide for Software Design Description (SDD)
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
CSC535 – Object Oriented Software Development Introduction.
Reverse Engineering and Design Recovery Informatics 122 Alex Baker.
Intro to the CS4240 Project Slides from Oct
Software development process ธนวัฒน์ แซ่ เอียบ. The development process Process –set of rules which define how a development project. Methodology and.
CSE 219 Computer Science III Program Design Principles.
DDI & Model-View-Controller: An Architectural Perspective Dennis Wegener, Matthäus Zloch, Thomas Bosch (GESIS) Dagstuhl,
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Object-Oriented Analysis and Design Fall 2009.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Rainbow: XML and Relational Database Design, Implementation, Test, and Evaluation Project Members: Tien Vu, Mirek Cymer, John Lee Advisor:
Design Recovery. Today’s Lecture Reverse engineering Assignment 3 Benumbered design continued (if time)
1 Software Design Lecture What’s Design It’s a representation of something that is to be built. i.e. design  implementation.
RE-ENGINEERING AND DOMAIN ANALYSIS BY- NISHANTH TIRUVAIPATI.
Informatics 122 Software Design II Lecture 12 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Chapter 7 Lecture 1 Design and Implementation. Design and implementation Software design and implementation is the stage in the software engineering process.
Contents What is Reverse Engineering (RE)? Why do we need Reverse Engineering? Scope and Tasks of Reverse Engineering Reverse Engineering Tools Reverse.
High-level language programming paradigms. Programming languages come in many forms or 'paradigms'. Each form of language offers advantages over other.
1 Use Cases Object-Oriented Modeling and Design with UML (Second Edition) Blaha & Rumbaugh Sections 7.1, 8.1.
Introduction to OOAD and UML
Definition CASE tools are software systems that are intended to provide automated support for routine activities in the software process such as editing.
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN
Software Maintenance
Authors: Khaled Abdelsalam Mohamed Amr Kamel
Informatics 121 Software Design I
Informatics 121 Software Design I
Object Oriented Analysis and Design
Systems Analysis Overview.
Informatics 122 Software Design II
Informatics 122 Software Design II
Informatics 121 Software Design I
Informatics 122 Software Design II
Informatics 122 Software Design II
Applying Use Cases (Chapters 25,26)
Informatics 122 Software Design II
System Reengineering Restructuring or rewriting part or all of a system without changing its functionality Applicable when some (but not all) subsystems.
Informatics 122 Software Design II
Informatics 122 Alex Baker
Chapter 13 Logical Architecture.
Presentation transcript:

Design Recovery 1 Informatics 122 Alex Baker

What is Design Recovery? Sort of like reverse engineering

What is Design Recovery? Design recovery recreates design abstractions from  Code  Existing design documentation (if available)  Personal experience / general knowledge about problem and application domains  Talking to people (Biggerstaff, 1989)

What is Design Recovery? Recovered abstractions need:  Formal specifications  Module breakdowns  Data abstractions  Dataflows  Informal knowledge All information required to understand  What  How  Why (Biggerstaff, 1989)

Also like a double-waterfall… General model for recovery (Byrne, 1992) Existing SystemTarget System Implementation Design Requirements Con- ceptual Con- ceptual Design Implementation re-think re-specify re-design re-build Alteration Reverse Engineering Abstraction Forward Engineering Refinement

Why do we need to know this? Working with others’ code…  Debugging  Maintenance  Reuse Working with your own code

Motivation: No design Lost design Build-and-fixed Agile methodologies Incomprehensible design

Motivation: Design Drift

Design not followed

Motivation: Design Drift Design deviations

Motivation: Design Drift Design deviations

Motivation: Design Drift Design deviations ?

Motivation: Design Drift Design deviations

??? Motivation: Design Drift Design deviations ???

Motivation: Design Drift Design deviations ???

Motivation: Design Drift Design deviations ???

Motivation: Design Drift ???

Motivation: Design Drift ???

Could even be your own code You’re often recovering, in some sense ???

Design Recovery in our Models Feasible Desirable Conceivable Outcome Space Design Space

Design Recovery (Product) Feasible Desirable Conceivable Outcome Space Design Space

Design Recovery (Product) Feasible Desirable Conceivable Outcome Space Design Space

Design Recovery (Product) Feasible Desirable Conceivable Outcome Space Design Space

Design Recovery in Our Models activities goals (languages)knowledge (languages) ideas (languages)representations (languages) tools

Design Recovery (Process) activities Ideas (languages) representations (languages) activities Ideas (languages) representations (languages) if(condition) functionCall(X); else functionCall(Y);

Design Recovery (Process) activities Ideas (languages) representations (languages) activities Ideas (languages) representations (languages) if(condition) functionCall(X); else functionCall(Y);

Design Recovery (Process) activities Ideas (languages) representations (languages) activities Ideas (languages) representations (languages) if(condition) functionCall(X); else functionCall(Y);

Design Recovery (Process) activities Ideas (languages) representations (languages) activities Ideas (languages) representations (languages) if(condition) functionCall(X); else functionCall(Y); goals knowledge

Design Recovery (Process) activities goals (languages)knowledge (languages) ideas (languages)representations (languages) tools

Also, remember Design recovery recreates design abstractions from  Code  Existing design documentation (if available)  Personal experience  General knowledge about problem and application domains

Isn’t this Reverse Engineering? Not just recreating the UML diagram…  Program flows  Rationale  Metaphor

Object Orientation Something of an advantage  Class names, function names  Established relationships (inheritance, members, etc.) Important details can be subtle

The Ideal Program (again!) … vs.

Also like a double-waterfall… General model for recovery (Byrne, 1992) Existing SystemTarget System Implementation Design Requirements Con- ceptual Con- ceptual Design Implementation re-think re-specify re-design re-build Alteration Reverse Engineering Abstraction Forward Engineering Refinement

Finding the structure (not the same as the design) Entities  Classes  Methods  Variables Relationships  Inheritance  Member Objects  Method calls

Approaches Reverse engineering tools  E.g. Omondo Reading documentation Code reading Reading class names Talking to people

But where’s the design? What principles were applied? What were their priorities? What patterns emerged? What actual patterns were used? What would developers making changes need to consider? This will save you a lot of trouble

An example: Jetris

Jetris Design Recovery Run the game Reading names What is HTMLLink? What is Figures.java? FigureFactory? TetrisGrid (wait, what’s with those arrays?) AddFigure, dropNext, addFigureToGrid… Actual loop? (nextMove) UI

Goals and Knowledge Of Tetris Based on other artifacts (running program) Of tendencies? Patterns?

What will you actually create? It depends:  How difficult?  Who else?  The future… We could make  UML  UI map  Program flow  Depiction of array metaphors  …

The other side of the coin… How easy is your program to understand? How is your:  Documentation  Naming  Code

Assignment 3 – Design Recovery Recover the design of VBoard  Sketching program developed for software engineering research  You may use any tools you like Get the VBoard code from the subversion repository, detailed instructions are here:

Assignment 3 – Design Recovery Each group must turn in:  A Complete UML (-ish) Diagram  At least 1 additional diagram of your choice (might be informal)  A document describing the design of VBoard (at least 4 pages)  Your audience is someone unfamiliar with VBoard who needs to make very significant changes to it  Graded on completeness, clarity, accuracy Each person also needs to submit a team evaluation (forms available on class webpage) Paper copy due Tuesday, Oct. 29 th, at start of class

Suggestions for Group Work Everyone start by taking their own look at the whole system  Multiple perspectives will be very useful Work out the high level architecture Understand program flows Look out for subtle details

Further tips Use representations of classes to organize Rote completeness is not the answer, will need to be elegant

Team Assignments Team 1 BAMBAEEROW, CAMERON DAUZ, JONATHAN JONAS, NICHOLAS LAVAVESHKUL, MICHAEL SHI, LINDA Team 2 DEMPSEY, MITCHELL KOLLA, SUBODH LAM, CYNTHIA LEE, RICK STEWART, DAVID Team 3 BEDFORD, AURORA CHIU, ARTHUR DYKZEUL, BRADLEY IGNACIO, JAN YEGANYAN, MICHAEL Team 4 BAUTISTA, JEREMIAH BOSCH, CHRISTOPHER ESQUENAZI, NATHAN PURPURA, DAVID Team 5 CHISLOM, ALTON HIRANO, SEN KWOK, MATHEW SAM, VINH Team 6 HUANG, ALLEN KNOBEL, JACOB LIU, ZHE SHAFER, THOMAS