ACM International Conference on Software Engineering (ICSE) T.H. Ng, S.C. Cheung, W.K. Chan, Y.T. Yu Presented by Jason R. Beck and Enrique G. Ortiz.

Slides:



Advertisements
Similar presentations
Department of Computer Engineering Faculty of Engineering, Prince of Songkla University 1 5 – Abstract Data Types.
Advertisements

Stepping StonesStepping Stones Programme Stepping Stones Stepping Stones Programme Next Step The Requirements Sylvia Tevlin Human Resources Manager.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Alternate Software Development Methodologies
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Using the Semantic Web to Construct an Ontology- Based Repository for Software Patterns Scott Henninger Computer Science and Engineering University of.
The Role of Software Engineering Brief overview of relationship of SE to managing DSD risks 1.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
Liang,Introduction to Java Programming,revised by Dai-kaiyu 1 Chapter 10 Object-Oriented Modeling.
1 Postdelivery Maintenance Xiaojun Qi. 2 Why Postdelivery Maintenance Is Necessary Corrective maintenance: To correct residual faults –Analysis, design,
1 IS371 WEEK 8 Last and Final Assignment Application Development Alternatives to Application Development Instructor Online Evaluations.
University of Southern California Center for Systems and Software Engineering © 2009, USC-CSSE 1 Assessing and Estimating Corrective, Enhancive, and Reductive.
1 Object-Oriented Design. 2 Objectives F To become familiar with the process of program development. F To the relationship types: association, aggregation,
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
Software Configuration Management (SCM)
 A set of objectives or student learning outcomes for a course or a set of courses.  Specifies the set of concepts and skills that the student must.
Educator’s Guide Using Instructables With Your Students.
Unit 5 School of Information Systems & Technology1 School of Information Systems and Technology (IST)
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Katanosh Morovat.   This concept is a formal approach for identifying the rules that encapsulate the structure, constraint, and control of the operation.
CISC6795: Spring Object-Oriented Programming: Polymorphism.
COMP 523 DIANE POZEFSKY 20 August AGENDA Introductions Logistics Software Engineering Overview Selecting a project Working with a client.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Refactoring.
Chapter 1: Introduction to Systems Analysis and Design
Chapter 13: Developing and Implementing Effective Accounting Information Systems
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
SE-308 Software Engineering-II 7th Term SE University of Engineering & Technology Taxila, Pakistan Software Engineering Department.
An analysis of exam results in the Object-Oriented Programming course at „Politehnica” University of Timisoara Ioan Jurca.
1 Object-Oriented Software Engineering CS Interfaces Interfaces are contracts Contracts between software groups Defines how software interacts with.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
21 August Agenda  Introductions  Logistics  Selecting a project  Working with a client.
Reviewed By: Paul Varcholik University of Central Florida EEL 6883 – Software Engineering II Spring 2009 Wojciech James Dzidek, Erik.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Chapter 2 Introducing Interfaces Summary prepared by Kirk Scott.
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
Programming for Beginners Martin Nelson Elizabeth FitzGerald Lecture 5: Software Design & Testing; Revision Session.
Chapter 12 Support for Object oriented Programming.
1 An Aspect-Oriented Implementation Method Sérgio Soares CIn – UFPE Orientador: Paulo Borba.
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 11 Object-Oriented.
 Pearson Education, Inc. All rights reserved Object-Oriented Programming: Polymorphism.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Java Programming, Second Edition Chapter Twelve Advanced Inheritance Concepts.
Chapter 11: Advanced Inheritance Concepts. Objectives Create and use abstract classes Use dynamic method binding Create arrays of subclass objects Use.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
CMSC 2021 Software Development. CMSC 2022 Software Development Life Cycle Five phases: –Analysis –Design –Implementation –Testing –Maintenance.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
CSCE 240 – Intro to Software Engineering Lecture 3.
SFnight SFnight 213 project Overview Special Challenges Heuristic Evaluation Results of the Pilot Study Formal Usability Study Demo of Current Design Last.
These materials are prepared only for the students enrolled in the course Distributed Software Development (DSD) at the Department of Computer.
Software Configuration Management
Software Quality Control and Quality Assurance: Introduction
Chapter 1: Introduction to Systems Analysis and Design
The Movement To Objects
8.4 Management of Postdelivery Maintenance
Chapter 11 Object-Oriented Design
Multi-Dispatch in the Java™ Virtual Machine
Object-Oriented Programming: Polymorphism
Software Design Lecture : 14.
Chapter 1: Introduction to Systems Analysis and Design
CMPE 135 Object-Oriented Analysis and Design March 21 Class Meeting
CS 2530 Intermediate Computing Dr. Schafer
Chapter 1: Introduction to Systems Analysis and Design
UML Design for an Automated Registration System
Presentation transcript:

ACM International Conference on Software Engineering (ICSE) T.H. Ng, S.C. Cheung, W.K. Chan, Y.T. Yu Presented by Jason R. Beck and Enrique G. Ortiz

 Research Questions  Participant Descriptions  Hotel Example  Question Formalization and Null Hypothesis  Target Programs  Required Changes  Experiment / Subjects / Procedure  Results  Pros / Cons

 Will maintainers use design patterns?  How likely are maintainers to perform specific tasks (i.e. T1, T2, and T3)?  Is the maintainer more likely to use specific tasks over others?  Is the code produced of higher quality using the design patterns? Research Questions

 Participant that is subclass of another participant T1 – Concrete Participants

 Participant that is superclass of another participant T2 – Abstract Participants

 Participant that is not a subclass or superclass, but statically binds to abstract participant (superclass) T3 – Client Partcipants

 Focus on Perfective Maintenance (adding new capabilities to program) Hotel Example

 New Local Setting: Hong Kong ◦ Must implement new class that implements locale settings to inherit Locale (abstract) class T1 – Adding new class as a concrete participant

 Display currently selected country in the user interface ◦ Add a new method to the Locale class hierarchy T2 – Modifying the existing interfaces of a participant

 Add support for console-based user interface ◦ Introduce new client codes for Locale inheritance hierarchy T3 – Introducing a new client

 Q1: What proportion of maintainers utilize the relevant design patterns in completing the required anticipated change? ◦ What proportion of them perform T1? ◦ What proportion of them perform T2? ◦ What proportion of them perform T3? ◦ Are the above proportions significantly different? Question Formalization

 Q2: Comparing the codes delivered by maintainers who utilize the relevant design patterns in completing the required anticipated change to those delivered by maintainers who do not utilize patterns, are they equally faulty? ◦ Comparing those who perform T1 with those who do not, are their codes equally faulty? ◦ Comparing those who perform T2 with those who do not, are their codes equally faulty? ◦ Comparing those who perform T3 with those who do not, are their codes equally faulty? Question Formalization

 HA 0 ◦ Maintainers have same tendency to perform each task  HB 0 ◦ Maintainers who perform tasks and those who do not provide same code quality  HC 0 ◦ “No strong correlation between the number of faults in the delivered codes and whether or not a task is performed to complete the anticipated change” Null Hypothesis

 JHotDraw ◦ Open-source drawing editor ◦ Java based ◦ GUI  MCM ◦ Multiple-user calendar manager ◦ Edit individual appointments ◦ Console-based  HMS ◦ Hotel management system prototype ◦ Edit room usage (check-in and check-out) ◦ Console-based Target Programs

 Different applications  Different sizes (few hundred LOC to ten- thousands LOC)  Defined anticipated changes  Created design patterns Target Program Analysis

Required Changes  Perfective changes (most frequent maintenance)

 Must spend at least three hours performing changes (ensures effort) Required Changes

 215 Undergraduate Java course students.  Grouped and individually assigned to tasks ◦ 27 students  Image modification ◦ 28 students  Language modification ◦ 100 students  Group appointments and Undo ◦ 60 students  GUI-based HMS and Search Experiment Subjects

 Briefed the students in a two hour information session.  Covered ◦ Requirements and specification and demo of correctly operating program. ◦ Presented the source code. ◦ Documentation (API and UML) ◦ Also covered general object-oriented concepts  Given a month to work on the assignment Experimental Procedure

 Subjects more likely to perform tasks T1-T3 than not use them at all.  Maintainers were more likely to perform task T1 (adding a concrete participant).  Followed by T3 (introduce a new client) and then T2 (modify existing interface). Results

 Yes, they do use them more often than not. Do maintainers utilize deployed design patterns?

 Functional correctness measured in number of faults on the submitted programs.  Means compared between those that used one of T1 – T3 in each program and those who did not.  Fewer faults for those who used one of T1 – T3; results statistically significant at 5% level. Do maintainers who utilize deployed design patterns deliver better code?

 Internal (Authors opinion) ◦ Plagiarism ◦ Wide variety of student expertise (all approaches feasible even if no design pattern used)  External ◦ Only used a few target applications. ◦ Design patterns used were not exhaustive ◦ Only used finite number of perfective changes Threats to validity

 Others have researched maintenance, but not also how design patterns factor in.  Other experiments had result that conflicted between each other regarding design pattern ease of maintenance.  Experiment to see if additional design patterns in code is beneficial regardless or work experience. (By the authors) Related Work

 When design patterns are initially implemented in anticipation of maintenance work, they are more often used than not by maintainers.  Conclude that T1 is most always recognized and utilized, but work is needed to “raise the maintainers’ awareness to perform” T2 and T3. Conclusion

 Good goals. Maintainers should make use of existing design.  Statistical significance of the fault results helped strengthen the argument.  Good variety of maintenance tasks and applications. Covered a good variety of design pattern tasks. Pros

 Are student representative of maintenance programmers? ◦ Undergraduates in a Java class. (likely very new to programming) ◦ Covered “general object-oriented concepts” when giving them the assignment. ◦ Showed the students how the final results should look, showed them the requirements, and original source code. (probably not the hand holding a real maintainer gets). ◦ A month to complete these tasks. Cons

 Results showed those which used patterns in the tasks had fewer faults.  Students who recognize design patterns are probably more skilled in the language.  The statistical significance is not between using patterns and not using patterns but between students who are skilled to use patterns and those who are not. Cons

 None of this confronted in the threats to validity, instead they thought plagiarism was more of a threat. Cons

 Take out the student factor and perform an experiment on professionals who perform maintenance on a regular basis. ◦ Gain insight on decisions made by professionals. ◦ Creates a less bias fault statistic.  Choosing not to utilize the pattern only makes things worse. ◦ Mismatched documentation ◦ Ruining the designers intent ◦ Likely to cause problems for future maintainers Areas to Improve / Comments

Questions?