KAOS PRES.ppt [Read-Only]...KAOS Seminar Spezifikationsverfahren WS00/01 Sinan Demokan, 16.01.2001 13 KAOS-Vorgehensmodell Zugrundeliegende Ontologie (3): Agent Ein Agent ist eine

Seminar in Software Engineering: Spezifikationsverfahren

KAOS

Sinan Demokan 16. Januar 2001

Institut für Informatik der Universität Zürich: Prof. Dr. M. Glinz, N. Schett

Seminar Spezifikationsverfahren WS00/01KAOS

Sinan Demokan, 16.01.2001 2

Inha

lt

• Hintergrund / Idee• Das KAOS-Vorgehensmodell• Divergenzen• KAOS in der Praxis• Zusammenfassung• Fazit



Hint

ergr

und

/ Ide

e

Problemstellung:

Das Erkennen bzw. Beheben von Inkonsistenzenverschiedener Art, welche sich bei der Akquisition,Spezifikation und Evolution von Anforderungen und Zielen,denen verschiedene Quellen zugrunde liegen,bezüglich eines Systems ergeben.



Hint

ergr

und

/ Ide

e

Ursachen der existierenden Problematik:

• Die Art und Weise der Inkonsistenz ist nicht klar erkennbar

• Was bedeutet „ein Konflikt zwischen Anforderungen“?

• Keine systematische Unterstützung bei der Erkennung von Inkonsistenzen

• Keine systematische Unterstützung bei der Beseitigung von Inkonsistenzen



Hint

ergr

und

/ Ide

e

Verschiedene Ansätze zur Lösung:

• Beseitigung der Inkonsistenzen auf der Ebene der Zieldefinierung

• Mechanismen zur Strukturierung von Anforderungen in modulare Sichten

à Vorarbeiten für die Entwicklung von KAOS



KAO

S-Vo

rgeh

ensm

odel

l

Knowledge Acquisitionin

autOmated Specification



KAO

S-Vo

rgeh

ensm

odel

l

• Unterstützt den gesamten Spezifikationsprozess

• KAOS setzt sich zusammen aus einer Multiparadigmen-Spezifikationssprache, einer zielorientierten Ausarbeitungsmethode und dem Gebrauch von Wissen der Meta-Ebene zur Unterstützung deren.



KAO

S-Vo

rgeh

ensm

odel

l

Ziele von KAOS (1):

• Formales Modellieren von funktionalen und nicht-funktionalen Anforderungen bezüglich Zielen, Einschränkungen (constraints), Voraussetzungen, Objekten, Ereignissen, Aktionen, Agenten, etc

• Beweis- und Herleitungstechiken zur Zielverfeinerung, Zieloperationalisierung, Konflikterkennung, Konfliktbeseitigung und Agentenzuweisung



KAO

S-Vo

rgeh

ensm

odel

l

Ziele von KAOS (2):

• Anforderungsgewinnung: zielorientierte, szenarienbasierteund sichtenorientierte Strategien

• Requirements Re-engineering

• Der Gebrauch eines Meta-Modells zur Unterstützung der Wiederverwendung von generischen Domänen-Modellierungs-Vorlagen



KAO

S-Vo

rgeh

ensm

odel

l

KAOS-Spezifikationssprache:

Die Spezifikationssprache kombiniert semantische Netze zur konzeptionellen Modellierung von Zielen, Anforderungen, Voraussetzungen, Agenten, Objekten und Operationen; Temporale Logik zur Spezifikation von Zielen, Anforderungen, Voraussetzungen und Objekten; und zustandsbasierte Spezifikationen zur Beschreibung von Operationen.



KAO

S-Vo

rgeh

ensm

odel

l

Zugrundeliegende Ontologie (1):

Object

Ein Objekt ist eine betrachtete Sache im System. Die Instanzen des Objekts können in verschiedene Zustände übergehen. Ein Objekt ist normalerweise detaillierter Spezifiziert als eine Entität, eine Beziehung oder ein Ereignis, abhängig davon, ob das Objekt autonom oder untergeordnet erscheint. Sie werden charakterisiert durch Attribute und Invarianten. Vererbung wird unterstützt.



KAO

S-Vo

rgeh

ensm

odel

l


Operation

Eine Operation ist eine Input-Output-Beziehung bezüglich Objekten. Der Gebrauch von Operationen definiert Zustandsübergänge. Die Operation wird charakterisiert durch Pre-, Post- und Trigger-Bedingungen. Unterschieden wird zwischen Domänen- Pre- und -Post-Bedingungen, welche elementare Zustandsübergänge in der Domäne durch den Gebrauch von Operationen abdecken, und zwischen verlangten (required) Pre- und Post-Bedingungen, mit welchen zusätzliche Einschränkungen zur Zielerreichung angegeben werden können.



KAO

S-Vo

rgeh

ensm

odel

l


Agent

Ein Agent ist eine andere Art von Objekt, welcher als Prozessor für Operationen dient. Ein Agent führt Operationen aus, wenn sie ihm effektiv zugewiesen wurden. Der Agent kann Objekte beobachten, wenn diese dafür vorgesehen werden (observable). Agenten können durch Menschen, Geräte und Programme etc. verkörpert werden.



KAO

S-Vo

rgeh

ensm

odel

l


Goal

Ein Goal ist ein Ziel, welches das System erreichen soll. Durch AND-und OR-Definitionen können Beziehungen zu Subgoals hergestellt werden. Die Goal-Struktur für ein gegebenes System kann durch einen AND/OR-gerichteten azyklischen Graphen dargestellt werden.Ist eine AND-Bedingung vorhanden, so ist das Goal erfüllt, wenn alle Subgoals erreicht werden. Ist eine OR-Bedingung vorhanden, so ist das Goal erfüllt, wenn nur eines der Subgoals erreicht wird.



KAO

S-Vo

rgeh

ensm

odel

l


Requisite, Requirement und Assumption

Requisites sind Goals, welche durch Zustände formuliert werden können. Diese Zustände müssen durch individuelle Agenten kontrollierbar sein. Requirements sind Requisites, welche einem Softwareagenten zugewiesen werden. Assumptions sind Requisites, welche einem Agenten aus der Systemumgebung zugewiesen werden. Im Gegensatz zu Requirements können Assumptionsnormalerweise nicht erheblich beeinflusst werden.



KAO

S-Vo

rgeh

ensm

odel

l


Scenario

Ein Scenario ist eine Komposition von Operationenanwendungen durch Einbezug von Agenteninstanzen. Diese Operationen müssen domänen-konsistent sein, d.h. Die Domänen-Pre-, -Post- und -Invarianten-Bedingungen müssen erfüllt sein.



KAO

S-Vo

rgeh

ensm

odel

l

Das Sprachkonstrukt: „Meeting Scheduler System“Goal Achieve[ParticipantsConstraintsKnown]

Concerns Meeting, Participant, SchedulerRefines MeetingPlannedRefinedTo ConstraintsRequested, ConstraintsProvidedInformalDef A meeting scheduler should know the

constraints of the various participants invitedto the meeting within some deadline d (≤ d) afterinvitation.

FormalDef ∀m: Meeting, p: Participant, s: SchedulerInvited(p, m) ∧ Scheduling(s, m)⇒ ◊ ≤ d Knows(s, p.Constraints)

1: Äussere semantische Ebene2: Innere formale Ebene (optional)

1

2



KAO

S-Vo

rgeh

ensm

odel

l

Operatoren:

Operator Text

∧ and

∨ or

¬ not

→ implies

↔ equivalent

⇒ entails

⇔ congruent

Logische Operatoren

Operator Text

ο in the next state

• in the previous state

◊ some time in the future

t some time in the past

¨ always in the future

n always in the past

W always in the future unless

U always in the future until

Temporale Operatoren



KAO

S-Vo

rgeh

ensm

odel

l

„dot-Notation“:

FormalDef ∀m: Meeting, p: Participant, s: Scheduler

Invited(p, m) ∧ Scheduling(s, m)

⇒ ◊ ≤ d Knows(s, p.Constraints)

Agent ParticipantCapableOf CommunicateConstraints, ...Has Constraints:

Tuple [ExcludedDates: SetOf[TimeInterval],PreferredDates: SetOf[TimeInterval]]



KAO

S-Vo

rgeh

ensm

odel

l

Aufruf von Relationen:

FormalDef ∀m: Meeting, p: Participant, s: Scheduler

Invited(p, m) ∧ Scheduling(s, m)

⇒ ◊ ≤ d Knows(s, p.Constraints)

Relationship InvitedLinks Participant {card 0:N}, Meeting {card 1:N}InformalDef A person is invited to a meeting iff

she appears in the list of expected participantsspecified in the meeting initiator’s request.

DomInvar ∀p: Participant, m: Meeting, i: InitiatorInvited(p, m) ⇔p ∈ Requesting[i,m].ParticipantsList



KAO

S-Vo

rgeh

ensm

odel

l

Die KAOS-Ausarbeitungsmethode:

Zielausarbeitung

Operationenerkennung

Verantwortlichkeiten

Operationalisierung

Objektgewinnung



KAO

S-Vo

rgeh

ensm

odel

l

Gebrauch von Wissen der Meta-Ebene:

• Domänenunabhängiges Wissen soll als lokaler Leitfaden zur Unterstützung der einzelnen Schritte des Ausarbeitungsprozesses verwendet werden

• Eine Mögliche Umsetzung: Kategorisierung der Zielformulierungen



KAO

S-Vo

rgeh

ensm

odel

l

Beispiele für Kategorien der Ziele:

• SatisfactionGoals• InformationGoals• RobustnessGoals• ConsistencyGoals• AvoidGoals• PrivacyGoals• SafetyGoals• ConfidentialityGoals



KAO

S-Vo

rgeh

ensm

odel

l

Beispiel für eine Konfliktquelle:

ConfidentialityGoals

InformationGoals

!



Dive

rgen

zen

• Wo können Inkonsistenzen auftreten?

• Das Konzept der Sichten

• Was sind Divergenzen?

• Wie können Divergenzen erkannt werden?

• Wie können Divergenzen beseitigt werden?



Dive

rgen

zen

Process Level

Product Level

Instance Level

objectives actors operatorsartifacts

elaboration process

produced requirements

running system

goals agents operationsobjects

Wo können Inkonsistenzen auftreten?:

prescribes

InstanceOf



Dive

rgen

zen

Master Concept

View

ActorSeesAs

FacetSeenAs

0:N

1:10:N

Process level

Product level

Das Konzept der Sichten:



Sichten in der KAOS-Spezifikationssprache:

Dive

rgen

zen

Entity MeetingHas Date: Calendar; Location: String

Entity MeetingToBeScheduledFacetOf Meeting SeenBy MeetingOrganizerHas ExcludedDates: SetOf[Calendar]

RequiredEquipment: SetOf[String]DomInvar ∀m: Meeting

m.Date not in m.ExcludedDates



Dive

rgen

zen

Klassifizierung der Inkonsistenzen:

• Abweichung auf der Prozessebene• Abweichung auf der Instanzebene• Terminologiediskrepanz• Bezeichnungsdiskrepanz• Strukturdiskrepanz• Divergenz

- Konflikt- Konkurrenz



Dive

rgen

zen

Eine Divergenz:

Eine Divergenz zwischen Forderungen A1...An innerhalb einer Domäne Dom tritt auf, wenn eine Grenzbedingung B existiert und folgende Bedingungen erfüllt werden:

1. { Dom, B, ∧1≤i≤n Ai } |– false(logical inconsistency)

2. for every i: { Dom, B, ∧j≠i Aj } |– false(minimality)

3. there exists a scenario S and time position i such that(S, i) |= B(feasibility)



Dive

rgen

zen

Grenzbedingung:

Eine Grenzbedingung (boundary condition) bedeuted, dass besondere Kombinationen von Umständen Ziele oder Anforderungen, welche ansonsten miteinander harmonieren, plötzlich konfliktär werden lassen.



Dive

rgen

zen

Divergenzenerkennung:

àZiel: Die Herleitung einer Grenzbedingung

1. Durch Regression der Negierten Forderungen

2. Durch Anwendung von bekannten Divergenzmustern



Dive

rgen

zen

Regression der negierten Forderungen:

Allgemeine Prozedur:

Initial step: take B := ¬ Ai

Inductive step: let A ⇒ C be the rule selected,with C matching some subformula Lin B;

then µ := mgu(L, C);B := B[L/A.µ]

(where mgu(F1,F2) denotes the most general unifierof F1 and F2, F.µ denotes the result of applying thesubstitutions from unifier µ to F, and F[F1/F2] de-notes the result of replacing every occurrence of F1in formula F by F2).



Dive

rgen

zen

Beispiel eines Divergenzmusters:

P ⇒ ◊Q R ⇒ ¨¬S Q ⇒ S

◊(P ∧ R)

!



Dive

rgen

zen

Divergenzenbeseitigung:

1. Durch Anwendung von vorgegebenen Strategien

2. Anwendung von Vorgehensmustern (analog Divergenzenmuster)



Dive

rgen

zen Strategien zur Divergenzenbeseitigung:

o Anforderungstransformation• Vermeidung von Grenzbedingungen• Zielpräzisierung unter Einbezug der Grenzbedingung• Abfangen eines Konflikts bei Erwartung des Eintretens

nach einer bestimmten Zeit• Zielformulierung abschwächen• Alternativziele definieren• Anwendung von heuristischen Methoden

o Objekttransformation• Objektverfeinerung

• Agentenverfeinerung



KAO

S in

der

Pra

xis

Praxis:

• Erfolgreicher Einsatz in fünf industriellen Projekten:

à Notfall-Service-System in einem belgischen Hospital

à System zur Unterstützung des Versands von Gütern



KAO

S in

der

Pra

xis

Werkzeug:

• KAOS / GRAIL als Umgebung für eine effektive Anwendung des zielorientierten Requirements Engineerings in der Praxis

• Verweis auf Literatur:R. Darimont, E. Delor, P. Massonet, and A. van Lamsweerde,GRAIL/KAOS: An Environment for Goal-Driven RequirementsEngineering,” Proc. ICSE’98—20th Int’l Conf. Software Eng., vol. 2,pp. 58-62, Kyoto, Japan, Apr. 1998



Zusa

mm

enfa

ssun

g Hintergrund / Idee:• Problem des Erkennens / Beseitigens von

Inkonsistenzen• Ansätze zur Lösung:

1. Beseitigung auf Ebene der Zieldefinierung2. Strukturierung von Anforderungen in

modulare SichtenKAOS Vorgehensmodell:

• Die KAOS-Spezifikationssprache• Die Ausarbeitungsmethode• Gebrauch von Wissen der Meta-Ebene



Zusa

mm

enfa

ssun

g

Divergenzen:• Scope of Inconsistency Management• Das Konzept der Sichten• Divergenzenerkennung• Divergenzenbeseitigung

Praxis:• Erfolgreicher Einsatz in fünf industriellen Projekten• Werkzeug GRAIL



Fazit Stärken:

• Modellierung von funktionalen & nicht-funktionalen Anforderungen

• Formale & nicht-formale Spezifikation.• Verständlichkeit• Unterstützt gesamten Spezifikationsprozess• Wiederverwendung / Muster• Unterstützt Inconsistency Management



Fazit

Schwächen:

• Formale & nicht-formale Spezifikation• Formale Spezifikation optional• Literatur / Dokumentation• Sehr vieles noch im Ermessen des Requirements

Engineers• Keine offizielle organisationale Institution• Fallunterscheidungen



Fazit

Abschliessend:

Das KAOS-Vorgehensmodell wurde bezüglich der Verbreitungsmassnahmen leider noch nicht ausgereift. Der Ansatz bietet zwar einige von anderen Verfahren nicht unterstützte Methoden im Spezifikationsprozessan, jedoch wird die Anwendung durch mangelnde Dokumentation bezüglich Aufbau, Standards und Erkenntnisse erschwert.



Dank

e

Danke für Ihre

Aufmerksamkeit!

Documents

KAOS PRES.ppt [Read-Only]...KAOS Seminar Spezifikationsverfahren WS00/01 Sinan Demokan, 16.01.2001 13 KAOS-Vorgehensmodell Zugrundeliegende Ontologie (3): Agent Ein Agent ist eine