Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering1 Produktlinien für...

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

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

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

• 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

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

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)

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

A figure element system

Figure

Verwendung des Observer Design Patterns

• Anwenden des Musters fügt

Code bei allen Beteiligten ein

• Muster verschwindet im

• 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

Figure 1 *

Figure element with Observer

Realisierung des Observer Patterns mit Aspekten

+display()

Screen

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

FigureElement

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

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

Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering1 Produktlinien für...

Documents

Modulhandbuch - hs-pforzheim.de · modulhandbuch – master mechatronische systementwicklung (m.sc.) - 2019 seite 3 . abbkÜrzungsverzeichnis cr credit gemäß ects – system

Hamburg 9. – 11. November 2011 - Buch.de · Modellbasierte Systementwicklung 1 Werkzeuge für den Schmied funktionaler Architekturen 3 Andreas Korff, Jesko G. Lamm, Tim Weilkiens

MECHATRONISCHE SYSTEMENTWICKLUNG · So werden White-Paper-Arti-kel und Simulationsmodelle zum kostenfreien Gebrauch online gestellt. Inhalte Vorlesung Höhere Mathematik: Differenzialgleichungen

Lösungen für Software- & Systementwicklung / agosense - Case … · 2020-02-18 · Engineering, Solution Architecture, Software Engineering, Test Engineering und das ... so ist

B.Sc. Informatik - Philipps-Universität Marburg · B.Sc. Informatik Das erwartet dich Studium Systementwicklung, Simulation, Modellierung Neue Entwicklungen aufgreifen & mitgestalten

Informatica Feminale - KWB · 2020. 1. 20. · Engineering1 Integriertes1Design1 Internaonale1 Medieninformak1(2) Komplexe1 SoRwaresysteme Linguisk Literaturwissenschaen Maschinenbau1(4)1

Software-Entwicklung Software-Ergonomie und Design

Software Philosophischer Ansatz: Ist Software sichtbar?

344mpfer neu 22 12 11.ppt) - Gerätetechnik von apetito Technische Date… · Rheine, den 22.12.2011 Systementwicklung Mini - Combidämpfer Inbetriebnahme Mini-Combidämpfer an Steckdose

Freitag, 24. März 2006 Lehrstuhl für Systementwicklung und IT-Management (Wirtschaftsinformatik III) Friedrich-Alexander-Universität Erlangen-Nürnberg

Tonfunk Systementwicklung und Service GmbH · 2018. 2. 20. · Radio LAN-Adapter Bedienteil TETRA-Funkgerät LTE MiMO WLAN/BT Breitbandzugang exklusiv Telekom GPS Sicherung Status

Projekt Schweisskon- struktion - Brand Engineering1).pdf · Projekt Schweisskonstruktion 5 1. Ausgangslage Im Rahmen eines Ausbildungspraktikums bei der Firma CADFEM Schweiz AG in

Deutschland.University · Professur für Wirtschaftsinformatik, insbe-sondere Systementwicklung (WISE), an der Technischen Universität Dresden. Prof. Dr. Hede Helfrich war Lehrstuhlinha-berin

Ihr erfahrener Partner für Systementwicklung und Engineering · 2014. 3. 28. · Die atech-Mitarbeiter zeichnen sich durch ein hohes Maß an Kreativität, Einsatzbereitschaft und

名称未設定-2 - DX Engineering1 GS-232A Computer Control Interface for Yaesu Antenna Rotators The GS-232A provide digital control of most models of Yaesu antenna rotatorsł from

Dr. WithalmWien, 18. Mai 2001 116. STEV-Österreich-Fachtagung Dr. Josef Withalm Siemens Österreich Programm- und Systementwicklung Neue Geschäfts-Strategien

SysML (Systems Modeling Language) und UML (Unified ... · Inhalt SysML und UML: Übersicht, Zusammenhang, Diagramme Modellbasierte Entwicklung: Systementwicklung, Softwareentwicklung

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

Software engineering Husain Aljazzar, Software Engineering, Universität Konstanz Software-Testen Husain Aljazzar

Institutsbericht 2002 - iva.ing.tu-bs.de · schaft in Wolfsburg und Braunschweig durch drei Experten für Test und Systementwicklung, um die wissenschaftlich begründe-ten Beschreibungsmittel,