Methoden zur Absicherung des softlang/160610- ¢  java.math java.lang.ref...

download Methoden zur Absicherung des softlang/160610- ¢  java.math java.lang.ref java.util.concurrent

of 20

  • date post

    24-Sep-2020
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of Methoden zur Absicherung des softlang/160610- ¢  java.math java.lang.ref...

  • © 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

    http://www.softlang.org/

  • © 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

    XLST Saxon

    Hibernate

    Awk

    Json

    Yacc

    JAXP

    Rest OWL

    RDF

    ATOM

    SparQL XSLT

    DTD

    BNF

    XSD

    OCL

    Prolog

    grep

    MOF

    OMG

    QVT

    jDOM Rose

    Protegé

    XQuery

    ODM

    XMLSpy

    JPA

    JAXB

    JDBC

    ODBC

    MySQL ArgoUML

    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

    saxon sax

    sed

    XSD

    JMI JMF

    SBVR Wa s t

    un ?

    2

    http://www.softlang.org/

  • © 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/

    Welche Sprachen …

    3

    … verwenden Sie in Ihrem Unternehmen?

    und Technologien …

    http://www.softlang.org/

  • © 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/

    Interessantere Fragen 1.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

    http://www.softlang.org/

  • © 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

    http://www.softlang.org/

  • © 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/

    Lehrorientierte, semantisch reiche Beispielsammlungen

    im Projekt 101

    6

    http://www.softlang.org/

  • © 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

    http://www.softlang.org/

  • © 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

    http://www.softlang.org/

  • © 2016, Software Languages Team Ralf Lämmel, http://www.softlang.org/

    Modelle von Technologien (“Megamodelle”)

    9

    http://www.softlang.org/

  • © 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

    http://www.softlang.org/

  • © 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

    http://www.softlang.org/

  • © 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

    http://www.softlang.org/

  • © 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, except that it is narrowed down to a sub-API of interest. Illustration – Fig. 7 illustrates ‘Non-trivial API’ usage for JDOM’s core package. The selection is concerned with a project type which extends the API type DefaultJDOMFactory to introduce a project-specific factory for XML elements. Basic IDE functionality could be used from here on to check where the API-derived type is used. Intelligence – In the example, we explored non-trivial API usage, such as type derivation at the boundary of project and API—knowing that it challenges API evolution and migra- tion [7]. More generally, developers are interested in specific sub-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, capture them, as part of the exploration. (This is what we did during this research.) Such sub-API tagging, which is supported by the Sub-API Footprint insight may ultimately improve API documentation in ways that are complementary to existing approaches [4], [5].

    F. The API Cocktail Insight

    Intent – Understand what APIs are used together in larger project scopes. Stakeholder – Project developer. API Usage – All APIs. View – The listing of all APIs exercised in the project or a project package with API-usage metrics applied to the APIs. Illustration – Remember the tree-based representation of the API cocktail for JHotDraw as shown in Fig. 1 in §II. The same 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 in the corresponding project scope. Thus, the cocktail proxies as a measurement for system complexity, required developer skills, and foreseeable design and implementation challenges. API usage is part of the software architecture, in the sense of “what makes it hard to change the software” and chances are that API usage may cause some “software or API asbestos” [29]. While a large cocktail may be acceptable and unavoidable for a complex project, the cocktail should be smaller for individual packages in the interest of a modularized, evolvable system.

    G. APIs Versus Domains

    We can always use API domains in place of APIs to raise the level of abstraction. Thus, any insight that compares APIs may as well be applied to API domains. APIs are concrete technologies while API domains