Commit 475cf529 authored by Falko Schumann's avatar Falko Schumann

Dokumentation aktualisiert

parent 1e3b9cb6
iav-fuzzylib-build:
image:
openjdk:8-jdk-alpine
script:
- ./gradlew build
image: openjdk:8
build:
stage: build
script: ./gradlew assemble
test:
stage: test
script: ./gradlew check
artifacts:
name: test-reports.zip
paths:
- build/reports
when: on_failure
expire_in: 1 week
Versionsverlauf
=============================================
Änderungsprotkoll
=================
## [Noch nicht veröffentlicht]
## [1.8.2]
### Geändert
- Kleinere Änderungen im Build, Kodierung der Property-Dateien korrigiert, Build durch FTB und Bereitstellung auf NERZ-Repositories
* Branch Version 1.x und 2.x zusammengeführt.
* "Runder" Wertebereich wie Norden bei Windrichtung kann alternativ mit zwei
gleichnamigen Fuzzy-Sets (Rampen) definiert werden.
* API modernisiert (Java 8).
* API auf notwendige Funktionen reduziert. Nicht notwendige Funktionen
entfernt.
### Entfernt
* Abhängigkeit zu Funclib BitCtrl entfernt.
### Behoben
* 0000151: Subsegmentanalyse publiziert unnötig viele Datensätze.
* Fuzzyfizierung und Defuzzyfizierung arbeitet nun mit `double`, statt `int`.
Somit können nun auch Messwerte bearbeitet werden, die Nachkommastellen
haben, wie Niederschlagsintentsität und Windgeschwindigkeit.
## [1.8.1]
## [1.8.2] - 2018-01-18
- NERZ: Umstellung auf Gradle, Build durch FTB und Bereitstellung auf NERZ-Repositories
* Kleinere Änderungen im Build, Kodierung der Property-Dateien korrigiert,
Build durch FTB und Bereitstellung auf NERZ-Repositories.
## 1.8.0
## [1.8.1] - 2017-12-29
- Umstellung auf Java 8 und UTF-8
* NERZ: Umstellung auf Gradle, Build durch FTB und Bereitstellung auf
NERZ-Repositories.
## 1.8.0 - 2017-08-15
* Umstellung auf Java 8 und UTF-8.
## 1.7.0
- Umstellung auf Maven-Build
* Umstellung auf Maven-Build.
## 1.6.2
- Mantis #2352: Meldung bei fehlenden Termen ergänzt, so dass sie jetzt auch
* Mantis #2352: Meldung bei fehlenden Termen ergänzt, so dass sie jetzt auch
die Variable nennen, bei der der Term vermisst wird.
- Verbesserung der Stabilität gegen Fehler beim Parametrieren durch den
* Verbesserung der Stabilität gegen Fehler beim Parametrieren durch den
Nutzer.
## 1.6.1
- Logausgaben beim Unit-Test werden wieder angezeigt.
* Logausgaben beim Unit-Test werden wieder angezeigt.
## 1.6.0
- Betriebsmeldungen um Systemobjekt in ID ergänzen, wenn sinnvoll.
(Mantis #2091)
- Quelltext kompatibler mit Java 6 gemacht.
* Mantis #2091: Betriebsmeldungen um Systemobjekt in ID ergänzen, wenn
sinnvoll.
* Quelltext kompatibler mit Java 6 gemacht.
## 1.5.0
- Betriebsinformation und Prüfprozedur liegen jetzt im Zustand "akzeptiert"
* Betriebsinformation und Prüfprozedur liegen jetzt im Zustand "akzeptiert"
vor.
## 1.4.1
- Betriebsinformation aktualisiert.
* Betriebsinformation aktualisiert.
## 1.4.0
- Prüfprozedur und Prüfprotokoll in Release aufgenommen
- Betriebsinformation in Release aufgenommen
* Prüfprozedur und Prüfprotokoll in Release aufgenommen.
* Betriebsinformation in Release aufgenommen.
## 1.3.0
- Anpassung an überarbeitetet Funktionsbibliothek de.bsvrz.sys.funclib.bitctrl
* Anpassung an überarbeitete Funktionsbibliothek de.bsvrz.sys.funclib.bitctrl.
## 1.2.0
- Anpassung an die neue Paketstruktur de.bsvrz.*
* Anpassung an die neue Paketstruktur de.bsvrz.*.
## 1.1.0
- Noch offene Datenkatalogänderungen durchgeführt.
- Abarbeitung der Wissensbasen überarbeitet
- Modellierung der Systemobjekte abstrahiert. Siehe auch im Paket
de.bsvrz.sys.funclib.bitctrl.modell
* Noch offene Datenkatalogänderungen durchgeführt.
* Abarbeitung der Wissensbasen überarbeitet.
* Modellierung der Systemobjekte abstrahiert. Siehe auch im Paket
de.bsvrz.sys.funclib.bitctrl.modell.
## 1.0.3
- Änderung an Handler-Überprüfung im Interpreter nachvollzogen
* Änderung an Handler-Überprüfung im Interpreter nachvollzogen.
## 1.0.2
- Hilfsfunktionen für Straßensubsegmentanalyse hinzugefügt
* Hilfsfunktionen für Straßensubsegmentanalyse hinzugefügt.
## 1.0.1
- Änderung der Paketstruktur in de.bsvrz.sys.funclib nachvollzogen
- Abhängiges Paket de.bsvrz.sys.funclib(.bitctrl) aus Release ausgegliedert
* Änderung der Paketstruktur in de.bsvrz.sys.funclib nachvollzogen.
* Abhängiges Paket de.bsvrz.sys.funclib(.bitctrl) aus Release ausgegliedert.
## 1.0.0
- Erste Auslieferung
* Erste Auslieferung.
[Noch nicht veröffentlicht]: https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.iav.fuzzylib/compare/v1.8.2...HEAD
[1.8.2]:
https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.iav.fuzzylib/compare/v1.8.1...v1.8.2
[1.8.1]:
https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.iav.fuzzylib/compare/v1.8.0...v1.8.1
[1.8.2]: https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.iav.fuzzylib/compare/v1.8.1...v1.8.2
[1.8.1]: https://gitlab.nerz-ev.de/ERZ/SWE_de.bsvrz.iav.fuzzylib/compare/v1.8.0...v1.8.1
Hinweise zur Bearbeitung / Beteiligung
======================================
Für Änderungen an dem Projekt ist zuerst ein Eintrag (Issue) mit dem Tag "Feature-Wunsch" oder "Bug"
anzulegen, damit die übernommen Änderungen auch einem Problem und einer potentiell erfolgten Diskussion
zugeordnet werden können. Solange das Fehler- und Änderungsmanagement noch über die bisherigen NERZ-Bugtracker
abgewickelt wird, ist zudem eine Referenz auf den dortigen Eintrag vorzunehmen.
Für Änderungen an dem Projekt ist zuerst ein Eintrag (Issue) mit dem Tag
"Feature-Wunsch" oder "Bug" anzulegen, damit die übernommen Änderungen auch
einem Problem und einer potentiell erfolgten Diskussion zugeordnet werden
können. Solange das Fehler- und Änderungsmanagement noch über die bisherigen
NERZ-Bugtracker abgewickelt wird, ist zudem eine Referenz auf den dortigen
Eintrag vorzunehmen.
Vor der Bearbeitung sollte man den entsprechenden Eintrag persönlich übernehmen
und einen Bugfix- oder Feature-Branch anlegen.
und einen Bugfix-Branch oder Feature-Branch anlegen.
Feature-Branches werden benannt als "feature/{name}", Bugfix-Branches als "hotfix/{name}".
Der Name sollte beschreiben, was innerhalb des Branches geändert wird und **nicht den Name des Bearbeiters**.
Feature-Branches werden benannt als "feature/{name}", Bugfix-Branches als
"hotfix/{name}". Der Name sollte beschreiben, was innerhalb des Branches
geändert wird und __nicht den Name des Bearbeiters__.
Feature-Wünsche werden auf Basis des "develop"-Branches umgesetzt und führen letztendlich zu einem Release einer
neuen Version auf dem zweiten Level, d.h. 0.1.0 wird mindestens 0.2.0 oder in der Hauptversion, d. h. aus z. B. 1.x.y wird 2.0.0, wenn **keine** Abwärtskompatibilität besteht.
Feature-Wünsche werden auf Basis des "develop"-Branches umgesetzt und führen
letztendlich zu einem Release einer neuen Version auf dem zweiten Level, d.h.
0.1.0 wird mindestens 0.2.0 oder in der Hauptversion, d.h. aus z.B. 1.x.y wird
2.0.0, wenn __keine__ Abwärtskompatibilität besteht.
Bugfixes sollten auf dem "master"-Branch beruhen und führen zu einer neuen Version auf dem dritten Level, d.h. aus 0.1.0 wird 0.1.1.
Die Änderungen werden dann natürlich auch in den "develop"-Branch gemerged. Damit können Bugfixes kurzfristig erfolgen
ohne den Zwang gleich alle Änderungen, die sich schon im Develop-Zweig befinden mit zu veröffentlichen.
Bugfixes sollten auf dem "master"-Branch beruhen und führen zu einer neuen
Version auf dem dritten Level, d.h. aus 0.1.0 wird 0.1.1. Die Änderungen werden
dann natürlich auch in den "develop"-Branch gemerged. Damit können Bugfixes
kurzfristig erfolgen ohne den Zwang gleich alle Änderungen, die sich schon im
Develop-Zweig befinden mit zu veröffentlichen.
Werden im Rahmen eines Auftrags mehrere Feature-Wünsche oder Bugfixes bearbeitet, kann auch einheitlich vom "develop"-Branch gemerged werden (konkrete Abstimmung im Zweifelsfall mit der NERZ-FTB).
Werden im Rahmen eines Auftrags mehrere Feature-Wünsche oder Bugfixes
bearbeitet, kann auch einheitlich vom "develop"-Branch gemerged werden (konkrete
Abstimmung im Zweifelsfall mit der NERZ-FTB).
Branches sollten nur für einen **einzelnen Eintrag** angelegt werden.
Die Branches können nach dem Merge in den Ursprungs-Branch entfernt werden (Das Löschen erfolgt automatisch,
wenn der entsprechende Haken beim Anlegen des Merge-Request gesetzt wird).
Branches sollten nur für einen __einzelnen Eintrag__ angelegt werden. Die
Branches können nach dem Merge in den Ursprungs-Branch entfernt werden (Das
Löschen erfolgt automatisch, wenn der entsprechende Haken beim Anlegen des
Merge-Request gesetzt wird).
Ein Merge-Request sollte folgende Punkte berücksichtigen:
- die Änderungen, die mit dem Request verbunden sind sollten in kurzer prägnanter Form in das CHANGELOG-File eingetragen werden. Der Eintrag erfolgt dabei im Abschnitt "Noch nicht veröffentlicht". Die Versionsnummer wird dort erst beim Release ergänzt (also letztlich bei der Übernahme durch die NERZ-FTB).
- wenn es notwendig ist, neue Features oder Änderungen zu beschreiben muss das README-File angepasst werden
- Änderungen am Code sollten keinen auskommentierten alten Code enthalten, für den Zugriff auf die Historie ist ja GIT vorgesehen
- die bearbeiteten Einträge sollten im Kommentar für den jeweiligen Commit oder für den Merge-Request mit "Fixes #{Eintragsnummer}" um die Zuordnung zu erhalten und das automatische Schließen zu ermöglichen
**Abgelehnte Merge-Request brauchen nicht gelöscht werden!**
Angemerkte und diskutierte Probleme, die eine Übernahme verhindern, sollten stattdessen bearbeitet werden bis der Merge-Request übernommen werden kann. **Ein neuer Request ist nicht erforderlich!**
\ No newline at end of file
* Die Änderungen, die mit dem Request verbunden sind sollten in kurzer
prägnanter Form in das CHANGELOG-File eingetragen werden. Der Eintrag
erfolgt dabei im Abschnitt "Noch nicht veröffentlicht". Die Versionsnummer
wird dort erst beim Release ergänzt (also letztlich bei der Übernahme durch
die NERZ-FTB).
* Wenn es notwendig ist, neue Features oder Änderungen zu beschreiben muss das
README-File angepasst werden.
* Änderungen am Code sollten keinen auskommentierten alten Code enthalten, für
den Zugriff auf die Historie ist ja Git vorgesehen.
* Die bearbeiteten Einträge sollten im Kommentar für den jeweiligen Commit
oder für den Merge-Request mit "Fixes #{Eintragsnummer}" um die Zuordnung zu
erhalten und das automatische Schließen zu ermöglichen.
__Abgelehnte Merge-Request brauchen nicht gelöscht werden!__ Angemerkte und
diskutierte Probleme, die eine Übernahme verhindern, sollten stattdessen
bearbeitet werden bis der Merge-Request übernommen werden kann. __Ein neuer
Request ist nicht erforderlich!__
Segment Intelligente Analyseverfahren, SWE Funktionen Fuzzy
===========================================================
Die SWE Funktionen Fuzzy stellt allgemeine Funktionen zur Verfügung, die bei der
Ermittlung von fuzzyfizierten Größen im Rahmen der Straßensubsegmentanalyse
verwendet werden. Eine weitere Anwendung dieser Funktionen findet sich in der
SWE Umfassenden Datenanalyse.
Die SWE Funktionen Fuzzy wird als Softwarebibliothek ausgelegt, die von
beliebigen anderen SWE eingebunden und genutzt werden kann. Sie selbst hat keine
externe Schnittstelle, keine Schnittstelle zum Datenverteiler und keine
Benutzerschnittstelle.
Segment Intelligente Analyseverfahren, SW-Einheit Funktionen Fuzzy
==================================================================
Folgende Funktionen werden angeboten:
* Erstellen und Modifizieren von Fuzzy-Sets und linguistischen Variablen
* Fuzzyfizierung von diskreten Zahlenwerten
* Erstellen von Fuzzy-Sets und linguistischen Variablen
* Fuzzyfizierung von scharfen Messwerten
* Defuzzyfizierung von Fuzzy-Werten
* Erstellen und Auswerten von Ausdrücken auf Basis von vordefinierten
booleschen Operatoren und Fuzzy-Operatoren
* Ableiten von Wissen aus einer Regelbasis
* Erstellen von Regeln und zusammenstellen von Regeln zu einer Regelbasis
* Ableiten von neuen Fuzzy-Werten mit Hilfe einer Regelbasis
Bemerkungen
-----------
Installation
------------
Die SWE stellt eine Softwarebibliothek dar. Die JAR-Datei muss zur Benutzung
lediglich im Klassenpfad der Anwendung aufgenommen werden. Die Beschreibung der
Schnittstelle kann in der API-Dokumentation nachgelesen werden.
Die JAR-Datei muss im Klassenpfad aufgenommen werden. Die Bibliothek hat keine
Abhängigkeiten.
Disclaimer
Verwendung
----------
Segment 5 Intelligente Analyseverfahren, SWE 5.4 Funktionen Fuzzy
Copyright (C) 2007 BitCtrl Systems GmbH
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 51
Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Die API ist im JavaDoc dokumentiert.
Kontakt
-------
BitCtrl Systems GmbH
Weißenfelser Straße 67
04229 Leipzig
Phone: +49 341-490670
mailto: info@bitctrl.de
BitCtrl Systems GmbH<br>
Weißenfelser Straße 67<br>
04229 Leipzig<br>
Fon: +49 341-490670<br>
E-Mail: info@bitctrl.de
......@@ -12,8 +12,8 @@ plugins {
//--------------------------------------------------------------------
group = 'de.bsvrz.iav'
version = '1.8.3-SNAPSHOT'
description = 'Segment Intelligente Analyseverfahren, SWE Funktionen Fuzzy'
version = '3.0.0-SNAPSHOT'
description = 'Segment Intelligente Analyseverfahren, SW-Einheit Funktionen Fuzzy'
// Properties des NERZ-SWE-Plugins:
nerzswe {
......@@ -25,7 +25,6 @@ nerzswe {
// Abhängigkeiten
//--------------------------------------------------------------------
String kernsoftware_version = '3.9.7'
dependencies {
testImplementation group: 'junit', name: 'junit', version: '4.12'
}
/*
* Segment 5 Intelligente Analyseverfahren, SWE 5.4 Funktionen Fuzzy
* Copyright (C) 2007-2015 BitCtrl Systems GmbH
* Segment 5 Intelligente Analyseverfahren, SW-Einheit 5.4 Funktionen Fuzzy
* Copyright (C) 2007-2018 BitCtrl Systems GmbH
*
* This library is free software; you can redistribute it and/or modify it under
* the terms of the GNU Lesser General Public License as published by the Free
......
......@@ -55,6 +55,12 @@ public final class FuzzyVariable {
this.terme = Collections.unmodifiableList(new ArrayList<>(terme));
}
/**
* Erzeugt eine neue Fuzzy-Variable als Kopie.
* <p>
* Ist der angegebene Term in der Fuzzy-Variable vorhanden, wird er ersetzt,
* anderfalls hinzugefügt.
*/
public FuzzyVariable mitTerm(Term term) {
Objects.requireNonNull(term, "term");
......
......@@ -65,6 +65,12 @@ public final class LinguistischeVariable {
this.fuzzySets = Collections.unmodifiableList(new ArrayList<>(fuzzySets));
}
/**
* Erzeugt eine neue linguistische Variable als Kopie.
* <p>
* Ist das angegebene Fuzzy-Set in der linguistischen Variable vorhanden,
* wird es ersetzt, anderfalls hinzugefügt.
*/
public LinguistischeVariable mitFuzzySet(FuzzySet fuzzySet) {
Objects.requireNonNull(fuzzySet, "fuzzySet");
......@@ -116,9 +122,15 @@ public final class LinguistischeVariable {
.orElseThrow(() -> new IllegalArgumentException("Die linguistische Variable \"" + this.name + "\" hat kein Fuzzy-Set \"" + name + "\"."));
}
/**
* Erzeugt eine Fuzzy-Variable bei der alle Terme die Zugehörigkeit
* undefiniert haben.
*/
public FuzzyVariable erzeugeFuzzyVariable() {
List<Term> terme = fuzzySets.stream()
.map(fs -> new Term(fs.getName(), Zugehoerigkeit.NULL))
.map(FuzzySet::getName)
.distinct()
.map(name -> new Term(name, Zugehoerigkeit.NULL))
.collect(Collectors.toList());
return new FuzzyVariable(name, terme);
}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment