+ All Categories
Home > Documents > Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent...

Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent...

Date post: 07-Jul-2020
Category:
Upload: others
View: 0 times
Download: 0 times
Share this document with a friend
30
12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.de Institut für Informatik III Universität Bonn
Transcript
Page 1: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

12. Workshop Software-Reengineering

Consistent Consideration of Naming ConsistencyNaming Consistency

Daniel Speicher, Jan Nonnen{dsp,nonnen}@iai.uni-bonn.de{ p, }@

Institut für Informatik IIIUniversität Bonn

Page 2: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Terms in a Program0. Programs as Texts

Terms in a Program

http://www.flickr.com/photos/pcalcado/3485582094/ created by Phillip Calçado

http://fragmental.tw/2009/04/29/tag‐clouds‐see‐how‐noisy‐your‐code‐is/http://www.flickr.com/photos/pcalcado/3485581970/ created by Phillip Calçado using http://www.wordle.net/

To access the URLs, you need to replace

https://sewiki.iai.uni‐bonn.de/research/cultivate/tutorial_exploring_concepts

you need to replace %e2%80%90 with a normal hyphen.

Page 3: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Fontsize ~ tf‐idf0. Programs as Texts

term frequency – inverse document frequency

• tf(term, doc) = #occurrences(term, doc)/#occurrences(*, doc)( )

• idf(term)= log2(#documents‐with(*)/#documents with(term))#documents‐with(term))

• If a term is in 2 of 16 documents, it needs log2(16/2)=3 bit information to find it.

• tf‐idf(term doc) = tf(term doc) * idf(term)• tf‐idf(term, doc) = tf(term, doc)   idf(term)

• Idea: Salton, Buckley 1988

Page 4: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

„Ich hätt´ da mal gern `ne Frage…“Regional phrase to introduce a question: „I‘d like to have a question…”

„Ja, also im Augenblick … habe ich leider keine dabei “habe ich leider keine dabei.

Konrad Beikircher

Ironic answer, ignoring the intention of the phrase: , g g p„Unfortunately  I have none at the moment.“

What are the right research questions to ask? There are some answers and even questions, but they look rather unrelated to us.

Page 5: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Goal: Quality criteria for namingGoal: Quality criteria for naming

• Example analysis: Naming Dependencies– Detecting where a term is introducedg

– Detecting naming dependencies

• Preliminary Simple Unified Meta Model of Naming• Preliminary Simple Unified Meta Model of Naming

– Derivation of the PreSUMMoN1)

– Semi‐automatically produces hypotheses

– Compatibility with current approachesp y pp

• Ihr Kommentar zum Thema und PreSUMMoN

1) Ken Beck on twitter, 26.03.10: „If you can[’t] find a really good name for something, pick a really terrible name (I like "fred"). Then you are motivated to fix it.” [Minor typos fixed.]

Page 6: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Refactoring goal: Reuse Planner1. Example analysis: Naming Dependencies ‐Motivation

Refactoring goal: Reuse PlannerPlanner

Page 7: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Refactoring Strategy: Extract Interface

1. Example analysis: Naming Dependencies ‐Motivation

Refactoring Strategy: Extract InterfacePlanner

Planner Library

Page 8: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Names reveal low Design Quality1. Example analysis: Naming Dependencies ‐Motivation

Names reveal low Design QualityPlanner IExhibition

Planner Library

void schedule(IExhibition[] exhibitions) CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates)

ExhibitionExhibition

CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates)

Show

CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates) L tsetAssignedCoordinates(Coordinates)CoordinatesList getPreferredTimes()setAssignedTime(Time)

Lecture

CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates)List <Room> getPreferredRooms()List <Room> getPreferredRooms()setAssignedRoom (Room)

Page 9: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

What does “Exhibition” mean?1. Example analysis: Naming Dependencies ‐Motivation

What does  Exhibition  mean?Planner IExhibition

Planner Library

void schedule(IExhibition[] exhibitions) CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates)

Exhibition IExhibitionExhibition

CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates)

IExhibition

Show

CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates) L t

IExhibition

IExhibitionsetAssignedCoordinates(Coordinates)TimesList getPreferredTimes()setAssignedTime(Time)

Lecture

CoordinatesList getPreferredCoordinates()setAssignedCoordinates(Coordinates)List <Room> getPreferredRooms()

IExhibition

List <Room> getPreferredRooms()setAssignedRoom (Room)

Page 10: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Term Visualisation (plain)1. Example analysis: Naming Dependencies ‐Motivation

Term Visualisation (plain)

assigned coordinate  Show

Planner Library

exhibition get i list planner preferred schedule set

assigned coordinate exhibition get i list preferred set show timeschedule set preferred set show time

assigned coordinate  assigned coordinate

ExhibitionLecture

exhibition get i list preferred set

assigned coordinate exhibition get i lecturelist preferred room set

Page 11: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Term Visualisation (tf)1. Example analysis: Naming Dependencies ‐Motivation

Term Visualisation (tf)

assigned coordinate Show

Planner Library

ass g ed coordinateexhibition get i list planner

preferred schedule set

assigned coordinateexhibition get i list preferred set show

time

assigned coordinate

ExhibitionLecture

coordinateexhibition

assigned coordinateexhibition get i lecture list preferred

room texhibition get i list preferred set room set

Page 12: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Term Visualisation (tf idf)1. Example analysis: Naming Dependencies ‐Motivation

Term Visualisation (tf‐idf)

assigned coordinate exhibition get i listShow

Planner Library

planner preferred

schedule t

assigned coordinate exhibition get i list preferred set

show timeschedule set show time

assigned coordinate exhibition get i list preferred seti d di t hibiti t i lecture

ExhibitionLecture

assigned coordinate exhibition get i lecture

list preferred room set

Page 13: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Detecting Naming Dependencies1. Example analysis: Naming Dependencies – The Detection Rules

Detecting Naming Dependencies

• A type p named n introduces a non compound lexical item l: – if n=l, or 

if l is contained in n and all other lexical items in n– if l is contained in n and all other lexical items in nare already introduced.

[ l h ld b d d][Rule should be extended]

• A program element p1 is naming dependentp g p1 g pon a program element p2, if p2 introduces a lexical item that is part of the name of plexical item that is part of the name of p1.

Page 14: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

=> Consistency Criteria1. Example analysis: Naming Dependencies – Consistency Criteria

=> Consistency Criteria

i d h ld b bi• introduces should be unambiguous:We demand that for each introduced lexical item there is exactly one program element, that introduces it.

• naming dependencies should be compatible with the static dependencies: A naming p gdependency from p1 to p2 is compatible withthe static dependencies, if there exists a paththe static dependencies, if there exists a path of static dependencies from p1 to p2.

Page 15: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Screenshot“„Screenshot

Page 16: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Good Code and Concepts 1/32. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

Good Code and Concepts 1/3

R J ff i K B k ff d h f ll i " l "Ron Jeffries: Kent Beck offered the following "rules" for simple design. In priority order, the code must:

1 R ll h1. Run all the tests 2. Contain no duplicate code 3. Express all the ideas the author wants to express 4. Minimize classes and methods 

few 1

(Ron Jeffries: http://www.xprogramming.com/xpmag/expEmergentDesign.htm)

Page 17: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Good Code and Concepts 2/32. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

Good Code and Concepts 2/3

Don Wells: Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to under‐stand, modify, and extend. Make sure everything is expressed once and only once. In the end it takes less time to produce a system that is well groomed. 

1 1

(Don Wells, http://www.extremeprogramming.org/rules/refactor.html)

Page 18: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Good Code and Concepts 3/32. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

Good Code and Concepts 3/3

Ad i C l Wh i i i f fAdrian Colyer: When you are writing a piece of software it's generally a good idea if you can design the program in such a way that each unique idea concept requirementsuch a way that each unique idea, concept, requirement, etc. addressed by the program has a direct and clear representation in the source code. … Design elements p gthat have a 1‐to‐1 mapping to an implementation are easy to add, remove, and maintain.

1 1

http://www.aspectprogrammer.org/blogs/adrian/2004/05/the_ted_neward.html

Page 19: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

2. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

Elements AND RelationsElements AND Relations

name

1 1

name

name'

Page 20: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

PreSUMMoN2. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

LexicalStatic

PreSUMMoNLexicalRelation

StaticRelation* * * *

Program El

Lexical I0 1

*  {ordered}

*

1

name1 1 1

Element Item0..1

*

*

*

Concept **

C l*

1

*

1

ConceptualRelation

Page 21: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Program Space2. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

g pElements and relations describing static code dependencies

• Elements:– packages, types, fields, methods, 

StaticRelationp g , yp , , ,

statements, expressions, …

• Relations:

*

1

*

1• Relations:

– calls, uses, extends, implements, d d l fl d

Program Element

depends on, control flow, data flow, …

Page 22: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Lexical space:2. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

pProgram element names and parts of these names

• Elements:– nouns, verbs, adverbs, 

LexicalRelation, , ,

adjectives, abbreviations.

• Relations: i l

*

1

*

1

• Relations:– Rules for building 

d f f

Lexical Item

*  {ordered}

compounds, fragments of sentences, sentences, bb i i d i iabbreviations, derivations, and textual length.

Page 23: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Concept space2. Preliminary Simple Unified Meta Model of Naming ‐ Derivation of the PreSUMMoN

p pModel of the programmer's mental concepts

• Elements:– domain, domain entities, design 

Concept

11, , g

pattern, roles in design pattern, architectural pattern, roles in  Conceptual

*

1

*

1

p ,architectural pattern, functional and non‐functional requirements, 

ConceptualRelation

q ,metaphors…

• Relations:• Relations: – is a, is part of, is antonym of, is similar 

b l d ito, belongs to domain…

Page 24: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Generic Consistency 1/3Generic Consistency 1/3

Page 25: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Generic Consistency 2/3Generic Consistency 2/3

Page 26: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Generic Consistency 3/3Generic Consistency 3/3

Page 27: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Semi‐automatically hypotheses production

• Hard: Find candidates for the mappingsHard: Find candidates for the mappings

• Easy: Take our generic consistency criteria as a template and create a specific criterion. p p

• Considering the amount of element and relation types this should yield many hypotheses.

Page 28: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

ExamplesExamples

• K. Beck: Same Level of Abstraction Principle

• R.C.Martin: Conciseness corresponding toR.C.Martin: Conciseness corresponding toscope

J Si C Ki kh T fi• J. Singer, C. Kirkham: Type postfixes ‐Correlation between type name and micropatterns.

• Correlation between information“ in method• Correlation between „information  in methodnames and method bodies.

Page 29: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

ExamplesExamples

• Florian Deißenböck, Daniel Ratiu. How programs represent reality (and how they p g p y ( ydon’t). WCRE’06: Proceedings of the 13th Working Conference on Reverse EngineeringWorking Conference on Reverse Engineering 2006Uses graph matching to map concepts in anUses graph matching to map concepts in an ontology to program elements.

Page 30: Consistent Consideration of Naming Consistency · 12. Workshop Software-Reengineering Consistent Consideration of Naming Consistency Daniel Speicher, Jan Nonnen {dsp,nonnen}@iai.uni-bonn.deInstitut

Ihr Kommentar zum Thema und PreSUMMoN?

• Typische Verstehensprobleme beimTypische Verstehensprobleme beim Reengineering?

U h C d b ?• Untersuchenswerte Codebasen?

• Kriterien für gute Benennung?g g

• Anregungen durch unseren Ansatz?


Recommended