1 / 20

A Formal Model for Object-Oriented Software Reuse

A Formal Model for Object-Oriented Software Reuse. Kim Mens Programming Technology Lab Vrije Universiteit Brussel. FNRS Meeting. May 6th, 1997. Contents. Object-Oriented Programming OO Software Reuse and Evolution Our Approach: Reuse Contracts

maddy
Télécharger la présentation

A Formal Model for Object-Oriented Software Reuse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Formal Model forObject-Oriented Software Reuse Kim Mens Programming Technology Lab Vrije Universiteit Brussel FNRS Meeting May 6th, 1997

  2. Contents • Object-Oriented Programming • OO Software Reuse and Evolution • Our Approach: Reuse Contracts • Software Engineering Tools based on Reuse Contracts

  3. Object-Oriented Programming • Objects contain both data (instance variables) and operations (methods). • Operations can be invoked and variables retrieved by means of message sending. • Classes are “templates” for objects. • Objects of the same class (instances) have the same implementation, but different internal state. • The implementation of existing classes can be reused (specialised) by means of inheritance.

  4. class DesktopFolder(name:String) instance variables xpos, ypos : Number contents : Set(DesktopItem) methods move(dx,dy:Number) = xpos.plus(dx); ypos.plus(dy) add(item:DesktopItem) = contents.include(item) addMany(group:Set(DesktopItem)) foreach item in group doself.add(item) DesktopFolder(HardDisk) xpos:600, ypos: 10, contents: ... DesktopFolder(TrashCan) xpos:580, ypos: 640, contents: ... message send self send Classes and Objects instances

  5. parent class (super) class DesktopFolder(name:String) instance variables xpos, ypos : Number contents : Set(DesktopItem) methods move(dx,dy:Number) = ... add(item:DesktopItem) = ... addMany(group:Set(DesktopItem)) inheritance class SizedFolderinherits from DesktopFolder instance variables size : Number methods add(item:DesktopItem) = super.add(item); size.plus(item.getsize()) child class super send Inheritance

  6. Software Reuse and Evolution Software Reuse = Reusing existing software parts in new systems. Software Evolution = Updating system parts by more recent versions. Both evolution and reuse give rise to similar problems.

  7. What can go wrong ... • Ariane 4 • well-tested software • proven correctly • Ariane 5 • reuse of pieces of Ariane 4 software • result: trivial error (floating point error), large consequences • What happened ? • changed flight specifications

  8. OO Software Reuse and Evolution • Current notations/methodologies/tools insufficiently support software reuse • support code reuse rather than design reuse • insufficiently document important dependencies • are too informal • Need for contract betweensoftware providers and reusers. • how can a software component be reused? • how is it actually reused?

  9. class DesktopFolder(name:String) instance variables xpos, ypos : Number contents : Set(DesktopItem) methods move(dx,dy:Number) = xpos.plus(dx); ypos.plus(dy) add(item:DesktopItem) = contents.include(item) addMany(group:Set(DesktopItem)) foreach item in group doself.add(item) DesktopFolder xpos, ypos contents move add addMany class SizedFolder inherits from DesktopFolder instance variables size : Number methods add(item:DesktopItem) = super.add; size.plus(item.getsize()) SizedFolder size add Object Modelling Technique (OMT)

  10. Our Approach: Reuse Contracts Software Provider Software Reuser • declares how a com-ponent can be reused; • declares what assumptions can be made about the software; • formally, non-coercively • declares how a com-ponent is reused • declares what assumptions are made about the component • formally, disciplined • rules for change propagation (conflict detection)

  11. Case Study: Reuse of Classes through Inheritance Class A Class A’ parent class exchange ? SubClass B SubClass B’ SubClass C SubClass C’

  12. DesktopFolder xpos, ypos contents move add addMany DesktopFolder xpos, ypos contents move add addMany {add} invokes add Step 1: Documenting the Design documenting (part of) the specialisation interface Specialisation interface The specialisation interface declares theassumptionsthat can be made about a class and how it can be reused.

  13. DesktopFolder xpos, ypos, contents move add addMany {add} • Refinement • add{+theSize} SizedFolder SizedFolder size size add {size} add {size} Step 2: Declaring How a Class is Reused DesktopFolder documenting different kinds of reuse xpos, ypos, contents move add addMany {add} The reuse operators declare theassumptionsthat are made about a class and how it is reused.

  14. Different Kinds of Reuse • Design “specialising” • Concretisation: replacing dummy or default method implementations by more specific ones • Extension: adding new behaviour • Refinement: refining the overall design by adding method dependencies • Design “generalising” • Abstraction: opposite of concretisation • Cancellation: removing existing behaviour • Coarsening: removing method dependencies

  15. OMT notation DesktopFolder DesktopFolder xpos, ypos contents move add addMany xpos, ypos contents move add addMany size + item.getSize() size + item.getSize() SizedFolder SizedFolder size size add add Inconsistent Methods evolution size is not updated when adding many items

  16. RC notation SizedFolder SizedFolder size size add {size} add {size} Evolution Conflict Detection • Coarsening • addMany {-add} DesktopFolder DesktopFolder xpos, ypos, contents move add addMany {add} xpos, ypos, contents move add addMany {add} • Refinement • add{+size} • Refinement • add{+size} Inconsistent Methods addMany needs to be overridden too

  17. Step 3: Formal Model & Rules for Conflict Detection • Formal model of … reuse contracts, reuse operators, and applicability • Formal rules for ... detecting conflicts on parent class exchange automated conflict checking possible !

  18. Reuse contracts for inheritance Software Provider Software Reuser DesktopFolder xpos, ypos, contents move add addMany {add} • Refinement • add{+size} • Reuse contract between provider and reuser • declares how a component can be reused and is reused • formal rules for change propagation

  19. Software Engineering Tools based on Reuse Contracts • Impact Analysis & Conflict Detection • Documenting Structure & Design of Software • Extracting Reuse Contracts (from source code) • Reverse Engineering • Verifying Compliance (of code) to Reuse Contracts • Enforcing Design • Generating Code • Quality Assessment of Software Design

  20. More Information http://progwww.vub.ac.be/prog/pools/rcs/ my email: kimmens@vub.ac.be

More Related