October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Intentional annotations for evolving object-oriented software Kim Mens Programming Technology Lab.

Slides:



Advertisements
Similar presentations
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
Advertisements

Object-Oriented Analysis and Design
CSCE 121, Sec 200, 507, 508 Software Engineering Fall 2010 Prof. Jennifer L. Welch.
By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental.
By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental.
Domain-Specific Software Engineering (DSSE). Software Engineering Concerns  There are many of them  “Classical” software architecture research has focused.
By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Software Requirements
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Article by: Farshad Hakimpour, Andreas Geppert Article Summary by Mark Vickers.
© Copyright Eliyahu Brutman Programming Techniques Course.
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
Software Engineer Report What should contains the report?!
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
S/W Project Management
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
CSI315 Web Applications and Technology Overview of Systems Development (342)
Chapter 2 The process Process, Methods, and Tools
Object-oriented Software Engineering with Reuse Contracts Koen De Hondt, Carine Lucas, Kim Mens, Tom Mens, Patrick Steyaert, Roel Wuyts Programming Technology.
A Development Process Lecture Oo13 Objectory based method.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
ITEC224 Database Programming
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
A Novel Approach to Architectural Recovery in Evolving Object- Oriented Systems PhD thesis Koen De Hondt December 11, 1998.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
CoFM: An Environment for Collaborative Feature Modeling Li Yi Institute of Software, School of EECS, Peking University Key Laboratory of High Confidence.
Lecture 7: Requirements Engineering
Abstract We present two Model Driven Engineering (MDE) tools, namely the Eclipse Modeling Framework (EMF) and Umple. We identify the structure and characteristic.
IS Methodologies. Systems Development Life Cycle - SDLC Planning Planning define the system to be developed define the system to be developed Set the.
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.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Software Safety Case Why, what and how… Jon Arvid Børretzen.
1 Knowledge Acquisition and Learning by Experience – The Role of Case-Specific Knowledge Knowledge modeling and acquisition Learning by experience Framework.
Requirements Validation
A Formal Model for Object-Oriented Software Reuse Kim Mens Programming Technology Lab Vrije Universiteit Brussel FNRS MeetingMay 6th, 1997.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Java Software Solutions Lewis and Loftus Chapter 15 Copyright 1997 by John Lewis and William Loftus. All rights reserved. 1 Software Development Process.
Requirements Engineering Process
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Reuse Contracts A Historic Overview Dr. Tom Mens Programming Technology Lab Vrije Universiteit Brussel Course OOSE.RC EMOOSE
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Course: Software Engineering – Design I IntroductionSlide Number 1 What is a specification Description of a (computer) system, which:  is precise;  defines.
1 Declaratively Codifying Software Architectures Using Virtual Software Classifications Kim Mens Kim Mens, Roel Wuyts, Theo D’Hondt Programming Technology.
2000 Research Overview Dr. Kim Mens Programming Technology Lab Vrije Universiteit Brussel.
4 June 1998, Mulhouse, France > ‘98 International Workshop Tom Mens Carine Lucas & Patrick Steyaert Programming Technology.
Documenting Evolving Software Systems through Reuse Contracts Kim Mens Patrick SteyaertCarine Lucas Programming Technology Lab, Vrije Universiteit Brussel.
WonderWeb. Ontology Infrastructure for the Semantic Web. IST WP4: Ontology Engineering Heiner Stuckenschmidt, Michel Klein Vrije Universiteit.
International Workshop 28 Jan – 2 Feb 2011 Phoenix, AZ, USA Ontology in Model-Based Systems Engineering Henson Graves 29 January 2011.
Knowledge Engineering. Sources of Knowledge - Books - Journals - Manuals - Reports - Films - Databases - Pictures - Audio and Video Tapes - Flow Diagram.
1 Software Requirements Descriptions and specifications of a system.
Design Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Unified Modeling Language
Arab Open University 2nd Semester, M301 Unit 5
A Declarative Evolution Framework for Object-Oriented Design Patterns
Intentional source-code views
Reuse Contracts: Managing the Evolution of Reusable Assets
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
ONTOMERGE Ontology translations by merging ontologies Paper: Ontology Translation on the Semantic Web by Dejing Dou, Drew McDermott and Peishen Qi 2003.
Presentation transcript:

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Intentional annotations for evolving object-oriented software Kim Mens Programming Technology Lab Vrije Universiteit Brussel Thesis advisor:Theo D’Hondt 00

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens 00 Towards an Explicit Intentional Semantics for Evolving Software Kim Mens Programming Technology Lab Vrije Universiteit Brussel Thesis advisor:Theo D’Hondt

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Ï Conflict detection l with reuse contracts l with intentions Ð Towards an intentional semantics Ñ Approach Ò Contribution Overview Ê Thesis Ë Motivating example Ì Thesis (rephrased) Í Software classifications Î Intentions (in terms of classifications) 01

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens (Tentative) thesis “Automated reasoning about explicit information on the intentions of software engineers allows to build more powerful tools for software evolution.” we will focus on (tools for) detecting evolution conflicts = can draw stronger conclusions (= can detect extra or more precise conflicts) 02

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivating example: 3-tiered architecture User interface Domain Database Updating Changing 03

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivating example: 3-tiered architecture User Interface Domain Database Updating Changing u To express this example we need: l software classifications l relationships between these classifications l formal reasoning about classifications and relations u Some examples: l Model.change isClassified ‘Changing’ l uses(‘User Interface’,‘Domain’) l architecturalBreach()if uses(without(‘Domain’,‘Changing’),‘User Interface’)) 03

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivation Software evolution is not easy because of the many hidden assumptions in the software u difficult to understand the purpose of software (and its evolution) u difficult to assess impact of making changes to software u difficult to detect evolution conflicts that arise by breaking undocumented assumptions 04

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Motivation u Software... l only reveals how and what is done l but not why it is done u Software evolution lacks... l information on how the software is modified l information on why things are modified 05 traceability research software comprehension research reuse contracts our contribution

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Research Idea u More information needed on software engineers’ intentions when modifying software artifacts u Rephrased thesis: “Automated reasoning about intentional software annotations (formally describing the intentions of software engineers) allows to build powerful tools for detecting evolution conflicts.” 06

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Some Definitions Intention [Webster’s]= l that upon which the mind is set or which it wishes to express or achieve l purpose conceived Software intention = l that which the software engineer wishes to express l purpose conceived by a software engineer when constructing or modifying a software artifact l reason why something was constructed or modified 07

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Some Definitions Annotation [Webster’s] = l a critical or explanatory note Intentional software annotation = l an annotation of a software artifact describing a software intention l describes why some software artifact was constructed or modified For now, we will focus on intentional annotations that can be expressed using software classifications... 08

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens User Interface Domain Database Updating Changing Software Classifications u A software classification is a collection of software artifacts that belong together because they share some common characteristics. u A classification expresses the intention that all artifacts it contains have something in common. u Classifications may be overlapping. u Some examples: ‘User interface’‘Domain’ ‘Database’ ‘Changing’‘Updating’ 09

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens User Interface Domain Database Updating Changing Definition of Software Classifications Intentions can be expressed in terms of l simple classifications For example: ‘Domain’, ‘Changing’,... l combinations of classifications  both(C 1,C 2 ) “both C 1 and C 2 ”  C 1  C 2  either(C 1,C 2 ) “either C 1 or C 2 ”  C 1  C 2  without(C 1,C 2 ) “C 1 without C 2 ”  C 1 \ C 2 u … (these are the building blocks) 10

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens User Interface Domain Database Updating Changing Definition of Intentional Annotations l Intentional annotations are defined in terms of dependencies between software classifications... u isClassified(A,C) =artifact A belongs to classification C u uses(C 1,C 2 ) =some artifact in C 1 uses one in C 2 u requires(C 1,C 2 ) =each artifact in C 1 uses one in C 2 u isa(C 1,C 2 ) = C 1 is a special case of C 2 l … and combinations of such intentions using logical operators u and(I 1,I 2 )both I 1 and I 2 hold u or(I 1,I 2 )either I 1 or I 2 holds, or both u xor(I 1,I 2 )either I 1 or I 2 holds, but not both 11

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Example: Intentions in terms of Software Classifications add addall {add} isClassified ‘Element addition’ isClassified ‘Set union’ Set Intention: requires(‘Set union’,‘Element addition’) Intentional rule: requires(C 1,C 2 )if  m 1 where isClassified(m 1,C 1 ) :  m 2 where isClassified(m 2,C 2 ) such that invokes(m 1,m 2 ) 12

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection u “Reuse contracts” l formally describe how software artifacts can be, and are actually modified, during software evolution l allow automated conflict detection by reasoning about this information u Our approach l extends the information provided by reuse contracts with more intentional information l allows more precise detection of evolution conflicts 13

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Reuse Contracts (RC) add addall {add} add addall {} count add {count} addall {add} Evolution A coarsening addall { - add} refinement add { + count} + count SetSet’ Set” formal software annotations expressing how the software is modified. Evol. B 14

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with RC’s add addall {add} Evolution A coarsening addall { - add} refinement add { + count} + count SetSet’ Set” Evol. B refinement add { + count} + count Set” Evol. B addall {add,count} Inconsistent method conflict addall {} 15

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with intentions add addall {add} coarsening addall { - add} Set Set’ Evol. A isClassified‘Element addition’ isClassified‘Set union’ Intention is invalidated... requires( ‘Set union’,‘Element addition’) Solution: assert hidden assumptions explicitly. speed optimization isClassified ‘Element addition’ 16

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with intentions add addall {add} refinement add { + count} + count Set Set” Evol. B isClassified ‘Element addition’ isClassified ‘Set union’ isClassified ‘Element counting’ Derived intentions: requires(‘Set union’,‘Element addition’) requires(‘Element addition’, ‘Element counting’) requires(‘Set union’,‘Element counting’) 17

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Conflict detection with intentions add addall {add} Evolution A coarsening addall { - add} refinement add { + count} + count SetSet’ Set” Evol. B refinement add { + count} + count Set” Evol. B Intention invalidated... requires(‘Element addition’, ‘Element counting’) 18

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Towards an intentional semantics (semantics of classifications) Semantic domain: [ ] Classification : Classification  2 Artifacts [ C ] Classification = { A  Artifacts | isClassified(A,C) } [ both(C 1,C 2 ) ] Classification = [ C 1 ] Classification  [ C 2 ] Classification [ either(C 1,C 2 ) ] Classification = [ C 1 ] Classification  [ C 2 ] Classification [ without(C 1,C 2 ) ] Classification = [ C 1 ] Classification \ [ C 2 ] Classification 19

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Towards an intentional semantics (semantics of intentions) Semantic domain: [ ] Intention : Intention  {true,false} [ requires(C 1,C 2 ) ] Intention =  m 1  [ C 1 ] Classification :  m 2  [ C 2 ] Classification : invokes(m 1,m 2 ) [ uses(C 1,C 2 ) ] Intention =  m 1  [ C 1 ] Classification :  m 2  [ C 2 ] Classification : invokes(m 1,m 2 ) [ isa(C 1,C 2 ) ] Intention = [ C 1 ] Classification  [ C 2 ] Classification [ and(I 1,I 2 ) ] Intention = [ I 1 ] Intention  [ I 2 ] Intention 20

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Approach u Find out what interesting software intentions are u Bottom-up approach - limit scope at first l object-oriented software l evolution conflict detection tools l evolution at implementation level l intentions in terms of software classifications and the dependencies between them u Develop formal model for conflict detection by reasoning about intentional annotations 21

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Approach u Build prototype conflict detection tool u Merge model and tool with reuse contract approach u Validate tool on industrial case (and show that tool indeed provides extra power) u Broaden scope again: l study other kinds of evolutionary intentions l other kinds of software evolution tool support l artifacts at other phases in software life cycle 22

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens Our Contribution u Develop formalism to describe intentions by means of formal software annotations. u Particular focus on use of software classifications to express software intentions. u (Semi-) automatic detection of evolution conflicts by reasoning about these intentional annotations. 23

October 19, 1998Doctoral Symposium OOPSLA’98 Kim Mens “By relieving the mind of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.” Alfred North Whitehead the end... 24