Refine
Year of publication
Document Type
- Master's Thesis (94) (remove)
Has Fulltext
- yes (94)
Keywords
- Data-Warehouse-Konzept (5)
- Datenbank (5)
- Internet (5)
- XML (5)
- Electronic Commerce (4)
- Softwareentwicklung (4)
- Data Ware House (3)
- Framework <Informatik> (3)
- ORACLE <Datenbanksystem> (3)
- Portal <Internet> (3)
Faculty
- Fakultät 10 / Institut für Informatik (94) (remove)
Keine Software kommt heute ohne eine ausgebaute IT–Infrastruktur, mit der Anbindung an Datenbanken, aus. Die konsequente Ausrichtung der Software, aufgrund von technologischen Entwicklungen, ist ein wichtiger Einflussfaktor auf die Softwareentwicklung. Die Software soll sich durch Innovation, Flexibilität und Dynamik auszeichnen. Diese Diplomarbeit entstand aus der Motivation heraus, hier Abhilfe zu schaffen. Mit dieser Diplomarbeit soll bewiesen werden, das es möglich ist, die zugrundeliegende Datenbasis von herkömmlicher Dateiorganisation auf relationale Datenbanksysteme umzustellen, ohne dabei die komplette Software neu zu schreiben.
Die nachfolgende Masterarbeit untersucht die Nutzung von DeepFake-Anwendungen bei Personen mit einer Fazialisparese. Dabei handelt es sich um eine Lähmung des Gesichtnervs, wodurch die betroffenden Menschen keine bzw. keine vollständige Mimik im Gesicht haben. Es wird hierbei getestet, ob mithilfe von DeepFake eine möglichst realistische Mimik generiert werden kann. Für die Untersuchung werden zunächst sowohl die theoretischen Grundlagen als auch verschiedene potenzielle Anwendungen vorgestellt. Mithilfe der vorgestellten Anwendungen wird anschließend ein Versuch durchgeführt, in dem die künstliche Intelligenz mit Bildmaterial von Proband:innen trainiert und anschließend manipuliert wird. Die aus dem Versuch resultierenden Ergebnisse werden danach durch eine Umfrage mit Bildern, welche eine originale Mimik zeigen, verglichen. Dadurch soll überprüft werden, wie realistisch die manipulierten Bild- und Videomaterialien sind oder ob die künstliche Intelligenz an eine mögliche Grenze stößt. Abschließend werden weitere Forschungsansätze und Anwendungsmöglichkeiten vorgestellt, in welchem die betrachtete künstliche Intelligenz genutzt werden kann.
More and more often, spoken information must and should be available in written form. For this purpose, various transcription programs try to support the user with various conveniences when transcribing the source material. A variety of online services go one step further and provide a ready-to-use, automatically generated transcription for a fee. Since the fees can be very expensive for the individual user and the online services may not always be used for privacy reasons, the goal of this work is to implement an open offline alternative. This alternative should be an open source editor based on the open speech-to-text-engine DeepSpeech and should on one hand provide the user with an offline transcription and on the other hand support him in correcting it. To achieve this goal, first the traditional speech recognition and eventually DeepSpeech will be described. This is followed by the conception and implementation of the editor. Since this project is explicitly intended to be an open source project, the last part will take a closer look at the release.
Im Mai 2001 wurde JavaServer Faces (JSF) von Sun als Java Specification Request (JSR) 127 vorgestellt. Außer Sun sind an der Entwicklung der JSF Spezifikation unter anderem die Apache Software Foundation, BEA Systems, Borland Software Corporation, IBM, Oracle und Macromedia beteiligt. Seit Dezember 2003 steht die Referenzimplementierung (RI) von Sun als Version 1.0 Beta zur Verfügung. Obwohl die Spezifikation noch nicht ganz abgeschlossen ist und die RI bis zum Final Release noch große Änderungen erfahren wird, zeichnet sich bereits ab, dass hier ein "großer Wurf" gelungen ist. Tool-Hersteller wie auch Anwendungsentwickler bringen JSF großes Interesse entgegen; eine OpenSource-Implementierung der JavaServer Faces ist mit MyFaces1 von SourceForge auch schon zu haben. Dabei gab es JavaServer Faces eigentlich schon, bevor die Entwicklung der Spezifikation begann. Das inzwischen in der Version 2.1.7 vorliegende Framework UIX (User Interface XML) von Oracle versucht schon seit einigen Jahren, eine große Lücke zu füllen. Es ist, genau wie JSF, ein UserInterface-Framework fürs Web. Im Gegensatz zu JSF ist es jedoch schon so ausgereift, dass es in realen Projekten eingesetzt werden kann.
Immer kürzer werdende Technologielebenszyklen, sich schnell ändernde gesetzliche Anforderungen und der ständig wachsende Wettbewerb führen dazu, dass Unternehmen dem Zwang unterliegen sich schnell auf diese veränderten äußeren Bedingungen anzupassen. Die Optimierung der eigenen Geschäftsprozesse ist diesbezüglich eine wesentliche Aufgabe, da diese so gestaltet werden müssen, dass Anpassungen möglichst schnell und minimal invasiv erfolgen können. Eine Optimierungsmöglichkeit ist Geschäftsprozesse mit Hilfe von Prozessbeschreibungssprachen wie BPEL (Business Process Execution Language) oder BPMN (Business Process Modelling Notation) automatisiert ablauffähig zu machen. Diese Automatisierung trägt zum einen dazu bei, dass Fach- und IT-Abteilung über das Gleiche nämlich über Geschäftsprozesse reden. Zum anderen hilft die Automatisierung dabei, klassische Probleme wie beispielweise Medienbrüche zu vermeiden. Eine Vollautomatisierung ist dabei jedoch meist nicht möglich und auch nicht sinnvoll, da es in Geschäftsprozessen Entscheidungen beziehungsweise Aufgaben gibt, welche das Eingreifen eines menschlichen Akteurs erfordern. Diesen Sachverhalt haben auch die Plattform-Hersteller erkannt und Möglichkeiten bereitgestellt, welche die Integration menschlicher Interaktion in einen automatisiert ablaufenden Prozess ermöglichen. Die Integration mit Hilfe so genannter Tasks, welche von einer Task-Engine erzeugt und Akteuren oder Gruppen von Akteuren zugeordnet werden. Diese Tasks können über eine Tasklist-oder Inbox-Applikation durch entsprechend berechtigte Benutzer bearbeitet werden. Solche Applikationen werden in der Regel von den Plattformherstellern zur Verfügung gestellt (z.B. Oracle Worklist Application oder Activiti Explorer), oder können über ein mitgeliefertes API (Application Programming Interface) individuell programmiert werden. Die APIs sind allerdings häufig proprietär und unterscheiden sich von Hersteller zu Hersteller. Für die Anwenderunternehmen heißt dies, dass entweder die mitgelieferte Anwendung verwendet oder eine eigene erstellt werden muss. Die erste Variante bringt das Problem mit sich, dass die mitgelieferten Anwendungen meist nicht ins Corporate Design passen und sich nicht ohne weiteres in bestehende Unternehmensportale, oder ähnliches einfügen lassen. Die zweite Variante ist aufwendig, da in der Regel nicht zu unterschätzende zeitliche und damit auch monetäre Aufwände anfallen. Zudem machen sich Anwenderunternehmen abhängig vom Hersteller der Workflow-Engine, weil ein Wechsel der verwendeten Plattform auch die Re-Implementierung der Inbox-Anwendung bedeutet. Zusammenfassend betrachtet bestehen im Bereich der menschlichen Interaktion also Probleme in den Bereichen Portabilität und Interoperabilität. Zudem entsteht eine enge Kopplung zwischen Task-Engine und den Inbox-Applikationen. Im Bereich der menschlichen Interaktion liegt bei der OASIS (Organization for the Advancement of Structured Information Standards) seit einigen Jahren die WS-HT Spezifikation vor, welche eine standardisierte Integration menschlicher Interaktion in Service-orientierten Architekturen gewährleisten soll. Hierüber könnten die angesprochenen Probleme beseitigt werden. Problem dabei ist, dass die WS-HT Spezifikation von aktuellen Task-Engine Implementierungen nicht berücksichtigt wird. Um dennoch die bestehenden Probleme adressieren zu können, soll ein Adapterframework, basierend auf den Vorgaben der WS-HT Spezifikation definiert werden, konzipiert und implementiert werden, das die Funktionalitäten verschiedener Task-Engines über eine standardisierte Schnittstelle anbietet. Mit Hilfe diese Frameworks soll die enge Kopplung zwischen einer spezifischen Task-Engine und den Inbox-Applikationen aufgehoben werden.
Immer mehr Teilbereiche des Semantic Web sind in den letzten Jahren erfolgreich umgesetzt geworden. Ebenso wird bei der Bearbeitung von komplexen Problemräumen mittlerweile oft auf semantische Modelle zurückgegriffen, um eine flexible Beschreibung der Domäne zu erstellen. Werkzeuge, welche die Entwicklung von Anwendungen, die auf semantischen Modellen basieren, unterstützen, sind bislang jedoch nur in begrenztem Maße verfügbar. Insbesondere die Verarbeitung von verteilten und dynamischen Modellen ist mit keinem der derzeit verfügbaren Produkte vollständig zu realisieren. Diese Arbeit untersucht die Möglichkeiten zur Integration von semantischen Modellen in objektorientierte Programmiersprachen. Es werden bestehende Ansätze analysiert und ein formales Modell der Integration erstellt. Das formale Modell wird in Form eines prototypischen Rahmenwerks in der Programmiersprache Ruby implementiert und validiert.
Die Grundlage für das Datenmodell einer Arztpraxis sind alle relevanten Daten, die zum Betrieb einer Arztpraxis notwendig sind. Aktuell werden die Daten mittels einer Praxisverwaltungssoftware (PVS) erfasst, in einem proprietären Datenformat gespeichert und im Weiteren für die Abrechnung aufbereitet. Dabei ist es seit Mai 1989 möglich, dass die Abrechnung per Diskette erstellt wird. Für die Aufbereitung der Daten wurde zuerst der Abrechnungsdatenträger (ADT) und seit dem 1. Juli 1999 ist es Pflicht die Abrechnung über den KV – Datenträger (KVDT) zu verwenden. Damals wurde kein einheitliches Datenmodell eingeführt, welches über den Abrechnungsdatenaustausch hinaus geht. Dadurch ist es nur sehr beschränkt möglich, Daten zwischen den einzelnen Systemen auszutauschen. So ist es für einen Arzt äußerst schwierig auf ein neues PVS – System umzusteigen. Um einen Eindruck über die Vielfalt und Menge der verschiedenen PVS – Systeme zu vermitteln, werden im Folgenden die Anzahl der KVDT – Zulassungen und der Labordatenträger – Zulassungen (LDT–Zulassungen) beschrieben. Zum dritten Quartal 2005 sind 2541 PVS – Systeme von der Kassenärztlichen Bundesvereinigung (KBV) für den gesamten oder Teile des KVDT zugelassen. Des Weiteren sind 742 PVS – System – Hersteller für die Datenübertragung mittels des gesamten oder Teile des Labordatenträgers zugelassen. Seit dem 1. Januar 2004 sind die Ärzte, mit wenigen Ausnahmen, gesetzlich dazu verpflichtet, die Abrechnung elektronisch durchzuführen. Deswegen haben einige Ärzte aus Kostengründen eine Individuallösung konzipiert, die ausschließlich in ihrer Arztpraxis verwendet wird. Aber auch diese Lösungen müssen von der KBV zertifiziert werden. Diese Lösungen werden zu den zugelassenen PVS – Systemen gezählt. Zum dritten Quartal 2005 sind 373 Individuallösungen zugelassen. Die in einer Arztpraxis anfallenden Daten müssen für den geregelten Praxisbetrieb vom PVS – System verwaltet, gespeichert und zum Teil auch zum Datenaustausch nach außen kommuniziert werden. Dabei werden die Daten von jedem Hersteller unterschiedlich erfasst und weiterverarbeitet. Des Weiteren ist die Repräsentation dieser Daten nicht einheitlich und beinhaltet verschiedene Arten von Daten. Diese Daten sind unter anderem Verwaltungsdaten, Abrechnungsinformationen und medizinische Informationen. Die von den Herstellern der Praxisverwaltungssoftware zu Grunde gelegten Datenmodelle sind unabhängig voneinander und nicht standardisiert. Dabei extrahiert jede Praxisverwaltungssoftware die Daten, die es für wichtig hält und repräsentiert diese in einem eigenen Format. Dadurch ergibt sich die Schwierigkeit, dass die Interoperabilität der Systeme sowohl in funktioneller als auch in semantischer Sicht eingeschränkt ist. Die Lösung dieser Probleme ist ein einheitliches Datenmodell mit entsprechender Schnittstelle, die das Ergebnis der vorliegenden Arbeit darstellt.