produktlinien für software- und systementwicklung hauptseminar sommersemester 2006, prof. broy
DESCRIPTION
Produktlinien für Software- und Systementwicklung Hauptseminar Sommersemester 2006, Prof. Broy. Product Line Evolution and AOP. Rainer Burgstaller Garching, 19.06.2006. Agenda. AOP in a nutshell: Quo vadis? Einführung, Grundlagen, Überblick PL und AOP NAPLES Vorgehensweise - PowerPoint PPT PresentationTRANSCRIPT
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 2
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 3
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 …
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 4
Software Engineering is a Piece of Cake?
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 5
Software Engineering is a Piece of Cake?
PersistenceTransaction
Security
Logging
Distribution
Scalability
Performance
Fault Tolerance
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 6
Problem
“I have a small mind and can only comprehend one thing
at a time”.
Edsger Dijkstra
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 7
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 8
Separation of Concerns - Ordnung
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 9
Separation of Concerns - Mülltrennung
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 10
• Wie sieht das nun im Software Engineering aus??
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 11
Ein Beispiel: Tomcat
Gute Trennung der Belange (Concerns): XML parsing
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 12
Ein Beispiel: Tomcat
Faire Trennung der Belange (Concerns): URL pattern
matching
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 13
Ein Beispiel: Tomcat
Schlechte Trennung der Belange: Logging in Tomcat
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 14
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).
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 15
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).
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 16
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 17
AOP
• Was können wir tun??
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 18
Lösung
• Beide Teile, sprich: Anwendungscode und Aspektcode voneinander unabhängig entwickeln
• Doch: Wie werden die beiden Teile miteinander kombiniert?? …
+
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 19
Lösung
• Durch Verwendung eines Aspekt-Webers
Weaver
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 20
Überblick
• Gibt verschiedene Zeitpunkte des Webens; zur
– Übersetzungszeit,
– Ladezeit und
– zur Laufzeit.
• Bekannteste Implementierungen
– AspectJ
– AspectWerkz
– JBossAOP
– AspectC++
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 21
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 22
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 23
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 !?
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 24
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 25
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, …
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 26
NAPLES
AORE ... Aspect Oriented Requirements Engineering
FODA ... Feature Oriented Domain Analysis
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 27
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 28
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“
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 29
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)
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 30
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.
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 31
NAPLES – Vorgehensweise
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 32
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 33
NAPLES – Gemeinsamkeiten und Variabilitäten Analyse
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 34
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>>
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 35
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 36
NAPLES – Vorgehensweise
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 37
Lifecycle-Abdeckung
NAPLES
NAPLES
NAPLES
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 38
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).
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 39
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 40
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 41
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)
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 42
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 43
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.
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 44
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 45
?
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 46
Backup Folien
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 47
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 48
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 *
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 49
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
+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
Figure 1 *
Figure element with Observer
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 50
Realisierung des Observer Patterns mit Aspekten
+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
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()
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 51
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 52
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 53
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 54
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 55
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 56
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
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 57
NAPLES – WMATRIX
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 58
NAPLES – WMATRIX
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 59
NAPLES – WMATRIX
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 60
NAPLES – Vorgehensweise
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>>
Environmental Influences Detection
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 61
NAPLES – Vorgehensweise
Mobile Phones
Password protection Games Contact List Web Browser
G1 G2 G3 G4
Fakultät für Informatik
Lehrstuhl IV: Software & Systems Engineering 62
NAPLES – Vorgehensweise