Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy

Fakultät für Informatik

Lehrstuhl IV: Software & Systems Engineering 1

Produktlinien für Software- und SystementwicklungHauptseminar Sommersemester 2006, Prof. Broy

Rainer Burgstaller

Garching, 19.06.2006

Product Line Evolution and AOP



Agenda

• AOP in a nutshell: Quo vadis?

Einführung, Grundlagen, Überblick

• PL und AOP

• NAPLES

– Vorgehensweise

– Lifecycle-Abdeckung

– Unterstützung Requirements Engineering

– Einsatzerfahrung, Verbreitung

• Zusammenfassung und Fazit

• Diskussion



AOP

• Gleich mal vorweg …

OO war und ist nach wie vor sehr erfolgreich.

• Aber …

– Die Komplexität der Systeme hat zugenommen (und nimmt

nach wie vor zu).

• These: Jeder Entwickler ist in der Lage große

Software Systeme zu entwickeln …



Software Engineering is a Piece of Cake?



Software Engineering is a Piece of Cake?

PersistenceTransaction

Security

Logging

Distribution

Scalability

Performance

Fault Tolerance



Problem

“I have a small mind and can only comprehend one thing

at a time”.

Edsger Dijkstra



Strategie für große Probleme: Separation of Concerns

“When faced with any large task, it is usually best to put aside some of its aspects for a moment and concentrate on

others“David Gries

“Divide et Impera”

Julius Caesar



Separation of Concerns - Ordnung



Separation of Concerns - Mülltrennung



• Wie sieht das nun im Software Engineering aus??



Ein Beispiel: Tomcat

Gute Trennung der Belange (Concerns): XML parsing




Faire Trennung der Belange (Concerns): URL pattern

matching




Schlechte Trennung der Belange: Logging in Tomcat



Querschneidende Belange (Crosscutting Concerns)

• CCC sind verflochten (tangled) und verteilt (scattered) im

System, und können aufgrund dessen nicht klar lokalisiert

werden.

• Einige Aspekte/Belange sind von Natur aus schwer zu

modularisieren (im Sinne OO Modulen).



Definitionen

• Joinpoint – ein Punkt im Ausführungsfluss eines Programms.

• Pointcut – selektieren von joinpoints; beschreibt eine Menge von joinpoints.

• Advice – erweitern oder einschränken von Belangen bei joinpoints.

• Aspekt – Element zur Modularisierung von sonst querschneidenden Belangen.

• Viewpoint – Blickwinkel aus dem man etwas betrachtet (Betrachtungsweise auf ein Artefakt).



Konsequenzen von schlechtem Separation of Concerns

• Redundanz– ähnliche Code Fragmente an vielen Stellen

• Code ist schwer zu verstehen– schwer das Gesamtbild zu bekommen

• Wartung/Änderungen ist/sind sehr teuer– Code muss lokalisiert werden

– Code muss in vielen Stellen geändert werden

• Wiederverwendung wird erschwert



AOP

• Was können wir tun??



Lösung

• Beide Teile, sprich: Anwendungscode und Aspektcode voneinander unabhängig entwickeln

• Doch: Wie werden die beiden Teile miteinander kombiniert?? …

+



Lösung

• Durch Verwendung eines Aspekt-Webers

Weaver



Überblick

• Gibt verschiedene Zeitpunkte des Webens; zur

– Übersetzungszeit,

– Ladezeit und

– zur Laufzeit.

• Bekannteste Implementierungen

– AspectJ

– AspectWerkz

– JBossAOP

– AspectC++



Agenda



• PL und AOP

• NAPLES

– Vorgehensweise





• Diskussion



PL und AOP

• Software Systeme „leben“

– neue Anforderungen bzw. Funktionalität

– Anpassungen

– Erweiterungen

• 80% der Aufwendungen machen Wartung und

Weiterentwicklung aus.

• Deshalb sollte Wartbarkeit und Erweiterbarkeit

besondere Beachtung geschenkt werden

Speziell für SPL



PL und AOP

• Instanzen einer Produktfamilie unterscheiden sich durch die Features welche sie enthalten.

• Während des SPL Entwicklungs-Prozesses werden Gemeinsamkeiten und Unterschiede herausgearbeitet.

• Funktionalität eines Features umspannt oft mehrere Teile eines Systems.

• Erfahrung hat gezeigt, dass Klassen im Sinne von OO Features nur unzureichend „einfangen“

• Feature entspricht oft einem Crosscutting Concern (AOP)

• Werden Features in Modulen gekapselt, kann man sie leichter „rein“ und „raus“ nehmen.

AO-Ansätze besser geeignet !?



Agenda



• PL und AOP

• NAPLES

– Vorgehensweise





• Diskussion



NAPLES

• Ziel:

automatisieren der zeitaufwendigen Aktivitäten

wie das identifizieren von (querschneidenden)

Belangen, Viewpoints, Gemeinsamkeiten und

Variabilitäten

Dabei kann prinzipiell auf beliebigen Dokumenten

gearbeitet werden, unabhängig von deren Struktur.

Beispiele: unstrukturierte Interviews,

Beschreibungen in PROSA, …



NAPLES

AORE ... Aspect Oriented Requirements Engineering

FODA ... Feature Oriented Domain Analysis



NAPLES – Mining Elements

– Eingabe: Anforderungsdokumente, Benutzerhandbücher,

dokumentierte Interviews, …

– Zweck: wichtige Konzepte identifizieren, diese dem Benutzer

so aufzubereiten, dass davon ein geeignetes strukturiertes

Modell abgeleitet werden kann (AORE und FODA Modell)

– Funktionsweise: EA-Miner verwendet natürliche

Spracherkennungsmechanismen von WMATRIX



NAPLES – WMATRIX (Funktionen)

– WMATRIX stellt Funktionen wie Wortartanalyse,

semantische Analyse, Worthäufigkeitsanalyse usw. zur

Verfügung

– Wortartanalyse zielt auf die Herauslockung von Wortarten

(z.B.: Hauptwörter, Zeitwörtern) ab.

– Semantische Analyse hat sich zum Ziel gesetzt verwandte

oder verschiedene Ausdrücke von Wörtern zu gruppieren

Bsp: driver(s), vehicle(s), traffic „land transport“



NAPLES – Mining Elements (Resultat)

– WMATRIX produziert aus der Eingabedatei eine XML-Datei, welche für jedes Wort die Wortart und die semantische Bedeutung markiert. Dabei ist die XML-Datei in Sätzen strukturiert (<s> … </s>)

Bsp <w pos=„JJ“ sem=„S7.4+“>authorised</w>

JJ …allgemeines Eigenschaftswort

S7.4+ …bedeutet „Zulassung/Erlaubnis“

– Mit diesen Mitteln können Domänen Konzepte mit besonderem Stellenwert erkannt werden (Early Aspects, Viewpoints, Gemeinsamkeiten und Variabilitäten)



NAPLES – Early Aspects Identifizierung

– basiert auf einem domänenspezifischen Lexikon (XML

Datei), welches erstellt wurde unter Berücksichtigung von

nichtfunktionalen Wörtern vorhanden im NFR (Nonfunctional

Requirements) Framework Katalog.

– EA-Miner vergleicht nun jedes Wort, ob es gleichwertig

(„equalTo“) zu einem NFR Konzept ist.

– Die „equalTo“-Operation ist dabei definiert wie folgt:

if a word is lexically equal, ignoring case and suffixes, to the

word in the lexicon AND the word has the same semantic

class as a word in lexicon.



NAPLES – Vorgehensweise



NAPLES – Gemeinsamkeiten und Variabilitäten Analyse

– Basiert auf einem domänenspezifischen Lexikon (XML-Datei)

für z.B. Tempomaten (Bsp.: Fahrzeug, Fahrer,

Geschwindigkeit, …)

– EA-Miner wendet auch hier die „equalTo“-Operation auf

jedes Wort an



NAPLES – Gemeinsamkeiten und Variabilitäten Analyse



NAPLES – Gemeinsamkeiten und Variabilitäten

Cruise Control

ACCSimple Cruise Control ACC Stop & GoACC onsidering environmental

influences

Close-up Range Sensor

Far Field Sensor

NavigationSystem Long Range Radar

LIDAR

InfraredSupersonic

Short Range Radar

Distance Alert

Acoustic Optical

Environmental Influences Detection

Range of Vision

Roadway Situation

Road Geometry

Speed Limit

Distance Sensor

Object Recognition

Activation Unit

<<uses>> <<uses>> <<uses>>

<<requires>>

Distance Regulator

Speed Regulator

<<requires>>

<<uses>>



NAPLES – Zusammenfassung

– Viewpointsidentifizierung wird unterstützt

– Early Aspects spiegeln querschneidende Belange wider,

welche Viewpoints durchkreuzen

– Viewpoints helfen die Implementierung der funktionalen

Anforderungen abzuleiten

– Early Aspects dienen zur Lokalisierung von CCCs welche

mehrere Features betreffen und nicht durch das FODA-

Modell repräsentiert werden



Lifecycle-Abdeckung

NAPLES

NAPLES

NAPLES



Unterstützung im Requirements-Engineering

• NAPLES unterstützt mehr oder weniger alle Phasen des Produktlinien-Lifecycle ein bißchen – vor allem aber das Domain Engineering

• Primärer Fokus war die Unterstützung der RE-Phase

• Unterstützung der RE-Phase

– Elicitation Requirements Engineer fokusiert sich nur auf bestimmte Teile des Dokuments

– Strukturierung Feature-Modell kann als oberstes Strukturierungsschema für Anforderungen dienen. Ea-Miner stellt bestimmte Sichten auf die Anforderungen dar.

– Modellierung Feature Diagramm wird für Requirements benutzt

• Traceability

– für nicht querschneidende als auch für querschneidende Belange gegeben (da sehr früh erkannt).



Einsatzerfahrung, Verbreitung

• Bereits (erfolgreich?) auf einzelne Fallstudien

angewendet.

• Noch nicht sehr verbreitet, da es sich um einen

Prototypen handelt.

• Wurde der Öffentlichkeit noch nicht zugänglich

gemacht



Agenda



• PL und AOP

• NAPLES

– Vorgehensweise





• Diskussion



Zusammenfassung und Fazit

• NAPLES ist ein vielversprechender Ansatz, der die Produktlinienorientierte Entwicklung durch den Lebenszyklus hindurch unterstützt/unterstützen wird.

• Verwendet verschiedene Techniken wie Wortanalyse, und AOSD Techniken um „automatische“ Unterstützung für (querschneidende) Belange zu erreichen.

• Noch nicht alle Phasen werden unterstützt, da sich der Ansatz noch in den frühen Phasen der Entwicklung befindet.

• Primärer Fokus war auf Anforderungsanalyse, inzwischen aber schon auf Design und Implementierung erweitert (siehe Bsp)



Zusammenfassung und Fazit

• unterstützt zeitintensive und fehleranfällige Aktivitäten.

• ermöglicht dem Anforderungs-Entwickler ein schnelles Verständnis über ein System zu erlangen.

• unterstützt Modell-Verfeinerungen und Modell-Erstellungen.

• Ansatz konnte leider nicht kritisch in Aktion bewertet werden (da Werkzeug noch nicht verfügbar).

• Kann gegenwärtig nur in Verbindung mit englischen Texten (Anforderungen) angewendet werden



Ausblick/Aktivitäten

• First Workshop on Aspect-Oriented Product Line Engineering

Part of GPCE 06 and colocated with OOPSLA 06

Sunday October 22, 2006 Portland, Oregon

http://www.softeng.ox.ac.uk/aople

• Siemens: AMPLE-Projekt; Start: Oktober 2006.

Framed Aspects Ansatz wird von Lancaster University im

Rahmen des Projekts weiter verfolgt/erneut aufgegriffen.



Agenda



• PL und AOP

• NAPLES

– Vorgehensweise





• Diskussion



?



Backup Folien



Beispiel: Observer Pattern

+addObserver(in Observer)+removeObserver(in Observer)+notify()

Subject

+update()

Observer

+getState()+setState()

-subjectState

ConcreteSubject

+update(in Subject)

-observerState

ConcreteObserver

for all o in observers { o.update();}

observerState = subject.getState();

subject

observers



Verwendung des Observer Patterns

+addObserver(in Observer)+removeObserver(in Observer)+notify()

Subject

+update()

Observer

+getState()+setState()

-subjectState

ConcreteSubject

+update(in Subject)

-observerState

ConcreteObserver

for all o in observers { o.update();}

observerState = subject.getState();

subject

observers

Observer design pattern

+display()

Screen

+getColor() : Color+setColor(in Color)

FigureElement

+getX() : int+getY() : int+getColor() : Color+setX(in int)+setY(in int)+setColor(in Color)

Point

+getP1() : Point+getP2() : Point+getColor() : Color+setP1(in Point)+setP2(in Point)+setColor(in Color)

Line

A figure element system

Figure

1 *



Verwendung des Observer Design Patterns

• Anwenden des Musters fügt

Code bei allen Beteiligten ein

• Muster verschwindet im

Code

• Implementierung des Muster

kann nicht wiederverwendet

werden.

+display()+update(in Subject)

Screen : Observer

+getColor() : Color+setColor(in Color)+addObserver(in Observer)+removeObserver(in Observer)+notify()

FigureElement : Subject


Point


Line

Figure 1 *

Figure element with Observer



Realisierung des Observer Patterns mit Aspekten

+display()

Screen

+getColor() : Color+setColor(in Color)

FigureElement


Point


Line

Figure1 *

<<aspect>>ColorObserver

Declare parents FigureElementimplements Subject

declare parents Screen implementsObserver

after subjectChange : (calls tosetColor on subtypes ofFigureElement)

updateObserver(){…}

<<aspect>>ObserverProtocol

interface Subject;interface Observer;

WeakHashMap perSubjectObservers

getObservers()addObserver()removeObserver()

pointcut subjectChange()

after subjectChange{}updateObserver()



public abstract aspect ObserverProtocol { protected interface Subject{} protected interface Observer{}

abstract protected pointcut subjectChange(Subject s);

abstract protected void updateObserver(Subject s, Observer o);

private WeakHashMap perSubjectObservers;

protected List getObservers(Subject s) {} public void addObserver(Subject s, Observer o) {} public void removeObserver(Subject s, Observer o){}

after(Subject s): subjectChange(s) { Iterator iter = getObservers(s).iterator(); while( iter.hasNext() ) { updateObserver(s, ((Observer)iter.next())); }}}

ObserverProtocol Aspekt

Rollen

Observer update

konzeptuelle Op

Update Logik

Beteiligte Obj



ColorObserver Aspekt

public aspect ColorObserver {

declare parents: FigureElement implements Subject; declare parents: Screen implements Observer;

pointcut subjectChange(Subject s): call(void FigureElement.setColor(Color) && target(subject);

void updateObserver(Subject s, Observer o) { ((Screen)observer).display(/*...*/); }

}

Rollen Mapping

Mapping der konzeptuellen Op

Update Logik



Vorteile des Aspekt-Ansatzes

• Lokalität

– Pattern Code ist in den abstrakten und konkreten Aspekt-

Klassen, nicht in den „teilnehmenden“ Klassen

– Änderungen sind konsistent

– (leichter zu verstehen, leichter zu debuggen)

• Wiederverwendbarkeit

– Pattern Code ist abstrakt und wiederverwendbar

• Pattern Code ist leichter entfernbar



ObserverProtocol Aspekt

public abstract aspect ObserverProtocol { protected interface Subject{} protected interface Observer{}

abstract protected pointcut subjectChange(Subject s);

abstract protected void updateObserver(Subject s, Observer o);

private WeakHashMap perSubjectObservers;

protected List getObservers(Subject s) { if(perSubjectObservers == null) { perSubjectObservers = new WeakHashmap(); } List observers = (List)perSubjectObservers.get(s); if(observers == null) { observers = new LinkedList(); perSubjectObservers.put(s, observers); } return(observers); } public void addObserver(Subject s, Observer o){ getObservers(s).add(o); } public void removeObserver(Subject s, Observer o){

getObservers(s).remove(o); }

after(Subject s): subjectChange(s) { Iterator iter = getObservers(s).iterator(); while( iter.hasNext() ) { updateObserver(s, ((Observer)iter.next())); }}}

Rollen

Observer update

konzeptuelle Op

Update Logik

Beteiligte Obj



Beispiel: Durchsetzen von Architekturrichtlinien

class Shape { public Line makeLine(Point p1, Point p2) { return(new Line... );} public Point makePoint(int x, int y) { return(new Point... );}}

aspect FactoryEnforcement {

pointcut newShape(): call(Shape+.new(..));

pointcut inFactory(): withincode(* Shape.make*(..));

before(): newShape() && !inFactory() { throw new Error(„Call factory to create shapes.“); }

}

Laufzeitfehler



Beispiel: Durchsetzen von Architekturrichtlinien

class Shape { public Line makeLine(Point p1, Point p2) { return(new Line... );} public Point makePoint(int x, int y) { return(new Point... );}}

aspect FactoryEnforcement {

pointcut newShape(): call(Shape+.new(..));

pointcut inFactory(): withincode(* Shape.make*(..));

declare error: newShape() && !inFactory(): „Call factory to create shapes.“;

}

Übersetzungsfehler



NAPLES – WMATRIX




Cruise Control

ACCSimple Cruise Control ACC Stop & GoACC onsidering environmental

influences

Close-up Range Sensor

Far Field Sensor

NavigationSystem Long Range Radar

LIDAR

InfraredSupersonic

Short Range Radar

Distance Alert

Acoustic Optical


Range of Vision

Roadway Situation

Road Geometry

Speed Limit

Distance Sensor

Object Recognition

Activation Unit

<<uses>> <<uses>> <<uses>>

<<requires>>

Distance Regulator

Speed Regulator <<requires>>

<<uses>>





Mobile Phones

Password protection Games Contact List Web Browser

G1 G2 G3 G4

Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy

Documents

Transcript of Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy