© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Methoden zur Absicherung des IT-Know-How im Unternehmen
Ralf Lämmel Arbeitsgruppe Softwaresprachen
Fachbereich 4: Informatik Universität Koblenz-Landau
1
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Das Problem der „Technologienfülle“
EMF
SQL
TENEO
Java
XSD
DOM
Antlr
OWL
UML
XMI
Ecore
SQL DDL
XLSTSaxon
Hibernate
Awk
Json
Yacc
JAXP
RestOWL
RDF
ATOM
SparQLXSLT
DTD
BNF
XSD
OCL
Prolog
grep
MOF
OMG
QVT
jDOMRose
Protegé
XQuery
ODM
XMLSpy
JPA
JAXB
JDBC
ODBC
MySQLArgoUML
Jean
Jena
Jena
Ralf
Dragan
TXL
VLDB
EMF.gen
ORACLE
TCS
XText
Teneo
Jersey
GWT
Sesame
Stratego
XPATH
JeanBeans
UTF8
ASCII
RDFa
RDF(S)
RDFS
CFG
LALR
ER
xerces
xalan
saxonsax
sed
XSD
JMI JMF
SBVR Was tun?
2
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Welche Sprachen …
3
… verwenden Sie in Ihrem Unternehmen?
und Technologien …
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Interessantere Fragen1.Wer spricht welche Sprachen im Unternehmen?
2.Wer meistert welche Technologien im Unternehmen?
3.Was sind die Sprachdialekte, welche in Projekten vorkommen?
4.Was sind die Technologiemuster, welche in Projekten vorkommen?
5.Hat das Projekt genug Expertise in …?
6.Wem weist man einen Bug oder ein Feature in der Entwicklung zu?
7.Wie bereiten wir die Belegschaft auf einen Umstieg von … nach … vor?
8.Wie kann das Team eine Technologieauswahl erörtern?
9.Wie kartiert man das Projekt technologisch für Einsteiger?
10.Wie analysiert man Repositories systematisch?
11.Wie oder woraus bereitet man Inhalte für eine Schulung vor?
12.…
4
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Techniken der AG Softwaresprachen• Lehrorientierte, semantisch reiche Beispielsammlungen
• Ausführbare, semantisch reiche Modelle von Technologien (“Megamodelle”)
• Software-Ontologien
• Mining Software Data
• Analyse der API-Verwendung
• Erfahrungskartierung von Entwicklern
• Verwendung von Programmierdomänen oder konkreten APIs
• Verschiedene Aspekte von Frameworks etwa für Web App Development
• Allgemeinere Softwaretechnikaspekte (wie Testen versus Migration)
• Qualitätsaspekte (etwa Verursachung bzw. Abstellung von Fehlern)
5
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Lehrorientierte, semantisch reiche Beispielsammlungen
im Projekt 101
6
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Was ist 101?Company X:
Swing + JDBC
Company Y: SWT + Hibernate
Company Z: GWT + MongoDB
...
Ein Gemeinschaftsprojekt zur Schaffung
einer Wissensbasis über
Softwaretechnologien und -sprachen
sowie -konzepten auf der Basis (u.a.)
der wiederkehrenden Implementation
eines Systems für das Personalwesen.
7
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Wie benutzen wir 101?Moderne und praxisrelevante Kurskonzepte an der Universität:
• Fortgeschrittene Programmierung
• Einführung in die Funktionale Programmierung
Material für IT-Schulungen • Einführung in die Objektorientierte Programmierung
• Einführung in relationale Datenbanken
• NoSQL-Technologien
• Web-Programmierung
Wissensbasis und Korpus für wissenschaftliche Untersuchungen
8
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Modelle von Technologien (“Megamodelle”)
9
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
• db_sqlite3 : File ∈ SL3IMG (a language we made up) • mysite : Folder
• __init__.py : File ∈ Python • manage.py : File ∈ Python • media : Folder • polls : Folder
• __init__.py : File ∈ Python • admin.py : File ∈ Python • models.py : File ∈ Python • tests.py : File ∈ Python • views.py : File ∈ Python
• settings.py : File ∈ Python • templates : Folder
• admin : Folder • polls : Folder
• detail.html : File ∈ HTML • index.html : File ∈ HTML • results.html : File ∈ HTML
• urls.py : File ∈ Python
Das ist doch noch nicht sehr interessant!?
Ist das wirklich HTML?
10
Eine Python/Django-basierte Web App
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Ein erster Teil eines Technologiemodells:Entitäten und Relationen
• Web application < System • Web application framework < Technology • Interpreter < Technology • webapp : Web application • Django : Web application framework • Python : Language • Python interpreter : Interpreter • webapp uses Python • webapp uses Django • Django uses Python
11
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Mining Software Data
Mining Software Data
Information Retrieval (IR)
Machine Learning
Mining Software Repositories
Natural Language Processing
12
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
API-Cocktail in einem Open-Source-Projekt (JHotDraw)
Swing!!java.lang!!JavaBeans!!java.io!!AWT!!java.util
Package org.jhotdraw.undo
AWT!!Swing!!java.io java.lang java.util
JavaBeans java.text java.lang.reflect!!DOM!!java.net java.util.regex!!Java Print Service!!java.util.zip!!java.lang.annotation java.math java.lang.ref java.util.concurrent Java security!!javax.imageio!!SAX
JHotDraw’s API Cocktail
Fig. 8. The API Cocktail of JHotDraw (cloud of API tags).
View – A list as in the case of the API Footprint insight, exceptthat it is narrowed down to a sub-API of interest.Illustration – Fig. 7 illustrates ‘Non-trivial API’ usage forJDOM’s core package. The selection is concerned with aproject type which extends the API type DefaultJDOMFactoryto introduce a project-specific factory for XML elements.Basic IDE functionality could be used from here on to checkwhere the API-derived type is used.Intelligence – In the example, we explored non-trivial APIusage, such as type derivation at the boundary of project andAPI—knowing that it challenges API evolution and migra-tion [7]. More generally, developers are interested in specificsub-APIs, when they require detailed analysis for understand-ing. API developers (more likely than project developers)may be more aware of sub-APIs; they may, in fact, capturethem, as part of the exploration. (This is what we did duringthis research.) Such sub-API tagging, which is supported bythe Sub-API Footprint insight may ultimately improve APIdocumentation in ways that are complementary to existingapproaches [4], [5].
F. The API Cocktail Insight
Intent – Understand what APIs are used together in largerproject scopes.Stakeholder – Project developer.API Usage – All APIs.View – The listing of all APIs exercised in the project or aproject package with API-usage metrics applied to the APIs.Illustration – Remember the tree-based representation of theAPI cocktail for JHotDraw as shown in Fig. 1 in §II. Thesame cocktail of 20 APIs is shown as a tag cloud in Fig. 8.Scaling is based on the #ref metric.Intelligence – The cocktail lists and ranks APIs that are used inthe corresponding project scope. Thus, the cocktail proxies as ameasurement for system complexity, required developer skills,and foreseeable design and implementation challenges. APIusage is part of the software architecture, in the sense of “whatmakes it hard to change the software” and chances are thatAPI usage may cause some “software or API asbestos” [29].While a large cocktail may be acceptable and unavoidable fora complex project, the cocktail should be smaller for individualpackages in the interest of a modularized, evolvable system.
G. APIs Versus Domains
We can always use API domains in place of APIs toraise the level of abstraction. Thus, any insight that comparesAPIs may as well be applied to API domains. APIs areconcrete technologies while API domains are more abstract
GUI!!Data!!Basics!!IO!!Format!!Component!!Meta!!XML!!Distribution!!Parsing!!Control!!Math!!Output!!Security!!Concurrency
JHotDraw’s API Domain Cocktail
GUI!!Basics!!Component!!IO Package org.jhotdraw.undo
Project jhotdraw
Fig. 9. Cocktail of domains for JHotDraw.
Basics!!Distribution!!GUI!!IO!!Component
java.lang!!java.net!!Swing!!JavaBeans!!java.io!!
APIs
API domains
Coupling in JHotDrawfor the interface org.jhotdraw.app.View
Fig. 10. API Coupling for JHotDraw’s interface org.jhotdraw.app.View.
software concepts. Consider Fig. 9 for illustration. It showsAPI domains for all of JHotDraw and also for its undopackage. Thus, it presents the API cocktails of Fig. 8 in amore abstract manner.
H. The API Coupling InsightIntent – Understand what APIs or API domains are usedtogether in smaller project scopes.Stakeholder – Project developer.API Usage – All APIs.View – See §VI-F except APIs or domains are listed for smallerproject scopes.Illustration – Fig. 10 shows API Coupling for the interfaceorg.jhotdraw.app.View from the JHotDraw’s app package4.According to the documentation, the package “defines aframework for document-oriented applications and providesdefault implementations”. The View type “paints a documenton a JComponent within an Application”. (Application is themain type from the package which “handles the lifecycle ofviews and provides windows to present them on screen”.) Thecoupled use of APIs can be dissected in terms of the involvedtypes as follows:java.lang: trivial usage of strings.java.net: types for the location to save the view.JavaBeans: de-/registration of PropertyChangeListeners.java.io: exception handling for reading/writing views.Swing: usage of JComponent on which to paint a document; usageof ActionMap for actions on the GUI component.
Intelligence – Simultaneous presence of several domains orAPIs in a relatively small project scope may indicate acciden-tal complexity and poor separation of concerns. Thus, suchexploration may reveal a code smell [30], [31] that is worthaddressing. Alternatively, a dissection, as performed for theillustrative example, may help in understanding the design andreasonable API dependencies.
I. The API Profile InsightIntent – Understand what API facets are used in varyingproject scopes.Stakeholder – Project developer and, possibly, API developer.
4The lifecycle of the interface as explained by its documentation: http://www.randelshofer.ch/oop/jhotdraw/JavaDoc/org/jhotdraw/app/View.html
Umso größer umso mehr Verwendung der API.
13
Analyse der Verwendung von APIs
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
API-Domänen in einem Projekt und in einem Paket
Swing!!java.lang!!JavaBeans!!java.io!!AWT!!java.util
Package org.jhotdraw.undo
AWT!!Swing!!java.io java.lang java.util
JavaBeans java.text java.lang.reflect!!DOM!!java.net java.util.regex!!Java Print Service!!java.util.zip!!java.lang.annotation java.math java.lang.ref java.util.concurrent Java security!!javax.imageio!!SAX
JHotDraw’s API Cocktail
Fig. 8. The API Cocktail of JHotDraw (cloud of API tags).
View – A list as in the case of the API Footprint insight, exceptthat it is narrowed down to a sub-API of interest.Illustration – Fig. 7 illustrates ‘Non-trivial API’ usage forJDOM’s core package. The selection is concerned with aproject type which extends the API type DefaultJDOMFactoryto introduce a project-specific factory for XML elements.Basic IDE functionality could be used from here on to checkwhere the API-derived type is used.Intelligence – In the example, we explored non-trivial APIusage, such as type derivation at the boundary of project andAPI—knowing that it challenges API evolution and migra-tion [7]. More generally, developers are interested in specificsub-APIs, when they require detailed analysis for understand-ing. API developers (more likely than project developers)may be more aware of sub-APIs; they may, in fact, capturethem, as part of the exploration. (This is what we did duringthis research.) Such sub-API tagging, which is supported bythe Sub-API Footprint insight may ultimately improve APIdocumentation in ways that are complementary to existingapproaches [4], [5].
F. The API Cocktail Insight
Intent – Understand what APIs are used together in largerproject scopes.Stakeholder – Project developer.API Usage – All APIs.View – The listing of all APIs exercised in the project or aproject package with API-usage metrics applied to the APIs.Illustration – Remember the tree-based representation of theAPI cocktail for JHotDraw as shown in Fig. 1 in §II. Thesame cocktail of 20 APIs is shown as a tag cloud in Fig. 8.Scaling is based on the #ref metric.Intelligence – The cocktail lists and ranks APIs that are used inthe corresponding project scope. Thus, the cocktail proxies as ameasurement for system complexity, required developer skills,and foreseeable design and implementation challenges. APIusage is part of the software architecture, in the sense of “whatmakes it hard to change the software” and chances are thatAPI usage may cause some “software or API asbestos” [29].While a large cocktail may be acceptable and unavoidable fora complex project, the cocktail should be smaller for individualpackages in the interest of a modularized, evolvable system.
G. APIs Versus Domains
We can always use API domains in place of APIs toraise the level of abstraction. Thus, any insight that comparesAPIs may as well be applied to API domains. APIs areconcrete technologies while API domains are more abstract
GUI!!Data!!Basics!!IO!!Format!!Component!!Meta!!XML!!Distribution!!Parsing!!Control!!Math!!Output!!Security!!Concurrency
JHotDraw’s API Domain Cocktail
GUI!!Basics!!Component!!IO Package org.jhotdraw.undo
Project jhotdraw
Fig. 9. Cocktail of domains for JHotDraw.
Basics!!Distribution!!GUI!!IO!!Component
java.lang!!java.net!!Swing!!JavaBeans!!java.io!!
APIs
API domains
Coupling in JHotDrawfor the interface org.jhotdraw.app.View
Fig. 10. API Coupling for JHotDraw’s interface org.jhotdraw.app.View.
software concepts. Consider Fig. 9 for illustration. It showsAPI domains for all of JHotDraw and also for its undopackage. Thus, it presents the API cocktails of Fig. 8 in amore abstract manner.
H. The API Coupling InsightIntent – Understand what APIs or API domains are usedtogether in smaller project scopes.Stakeholder – Project developer.API Usage – All APIs.View – See §VI-F except APIs or domains are listed for smallerproject scopes.Illustration – Fig. 10 shows API Coupling for the interfaceorg.jhotdraw.app.View from the JHotDraw’s app package4.According to the documentation, the package “defines aframework for document-oriented applications and providesdefault implementations”. The View type “paints a documenton a JComponent within an Application”. (Application is themain type from the package which “handles the lifecycle ofviews and provides windows to present them on screen”.) Thecoupled use of APIs can be dissected in terms of the involvedtypes as follows:java.lang: trivial usage of strings.java.net: types for the location to save the view.JavaBeans: de-/registration of PropertyChangeListeners.java.io: exception handling for reading/writing views.Swing: usage of JComponent on which to paint a document; usageof ActionMap for actions on the GUI component.
Intelligence – Simultaneous presence of several domains orAPIs in a relatively small project scope may indicate acciden-tal complexity and poor separation of concerns. Thus, suchexploration may reveal a code smell [30], [31] that is worthaddressing. Alternatively, a dissection, as performed for theillustrative example, may help in understanding the design andreasonable API dependencies.
I. The API Profile InsightIntent – Understand what API facets are used in varyingproject scopes.Stakeholder – Project developer and, possibly, API developer.
4The lifecycle of the interface as explained by its documentation: http://www.randelshofer.ch/oop/jhotdraw/JavaDoc/org/jhotdraw/app/View.html
Abstraktion von den konkreten APIs. Betrachtung verschiedener Projektausschnitte.
14
APIs versus Domänen
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Erfahrungskartierung von Entwicklern
hinsichtlich der Verwendung von Programmierdomänen oder konkreten APIs
15
Die Entwickler über die Zeit (Commits in einem Projekt)
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Die Domänen und APIs und Entwickler hinsichtlich der Beiträge
16
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Vergleich #API-Referenzen
17
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Erfahrungskartierung hinsichtlich von Frameworkaspekten für
Django (Web App-Entwicklung)
18
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Erfahrungen eines bestimmten Entwicklers in einem Projekt
19
© 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/
Die AG Softwaresprachen• Ralf Lämmel
• Hakan Aksu — Mining Software Repositories
• Marcel Heinz — Megamodelle und Ontologien
• Martin Leinberger — Semantische Daten
• Kevin Klein — Client/Server development und Cloud Deployment
• Lukas & Johannes Härtel — Megamodellierung
• Frederik Ruether — Web App Frameworks
• Wojciech Kwasnik — Visualisierung und Projektmanagement
• Andreas Schmidt — Linked Data and Restful Web APIs
• Simon Schauß — Technologien für die Sprachentwicklung
• Michael Monschau / Maximilian Meffert — 101 u.v.a.
• Thomas Bernau — Mining Software Repositories
• …
20