2 Objektorientierte Analyse
Werbung
OAA Projekt MERP BBZW Sursee Fachbereich Informatik EFZ Modul 306 Projekt-MERP Mini-ERP Objektorientierte Analyse Autor: Version: Status: Datum: Hbs,kch 1.1 review 10.01.2012 Projektmitarbeiter Name Vorname Email-Adresse Kurzzeichen Huber Chen Kaufmann Simon Kevin Elia [email protected] [email protected] [email protected] Hbs Kch Kfe Änderungskontrolle Version Datum Ausführende Stelle 1.0 10.01.2012 hbs ,kch Bemerkung/ Art der Änderung draft Prüfung Version 1.0 Datum Ausführende Stelle gas Bemerkung/ Erreichter Status Visum OAA Projekt MERP Inhaltsverzeichnis 1 Einleitung ................................................................................................................. 4 1.1 Zweck des Dokumentes ................................................................................ 4 1.2 Referenzierte Dokumente ................................................................................. 4 2 Objektorientierte Analyse......................................................................................... 4 2.1 Problembeschreibung ....................................................................................... 4 2.2 Klassendiagramm ............................................................................................. 5 2.2.1 Serverseitig – 3 Tier Layer ......................................................................... 5 2.2.2 Clientseitig – MVVM Architecture: .............................................................. 7 2.3 Aktivitätsdiagramm ............................................................................................ 9 2.4 Analyse der Persistenzmachung ....................................................................... 9 3 Glossar .................................................................................................................. 11 Objektorientierte Analyse (OOA) 3/ 11 OAA Projekt MERP 1 Einleitung 1.1 Zweck des Dokumentes In diesem vorliegendem Dokument handelt es sich um die objektorientierte Analyse (OAA) für das Projekt MERP. Dieses Dokument basiert auf der Anforderungsspezifikation[2], hauptsächlich den Use Cases und den Muss Zielen und dem Projektantrag[1]. 1.2 Referenzierte Dokumente [1] Projektantrag vom 13.12.2011 [2] Anforderungsspezifikation vom 18.10.2011 2 Objektorientierte Analyse Ziel dieser Analyse ist es ein System von Klassen zu definieren welche den Zusammenhang zwischen ihnen verständlich aufzeigt. 2.1 Problembeschreibung Verkaufsprozess: Rolle Verkäufer: Er kann einen Auftrag im System erfassen. Sobald er alles nötige erfasst hat überführt er ihn in den Rüstauftrag. Rolle Lagerist: Zu bestimmten Zeiten ruft der Lagerist im System alle Rüstaufträge ab die aktuell anstehen. Sobald er sie verpackt hat und sie bereit zum Versenden sind überführt er sie im System in den Warenausgang, wo sie bereitstehen um vom Lieferanten abgeholt zu werden. Sobald der Lieferant die „Pakete“ abgeholt hat überführt der Lieferant sie im System in die Rechnung. Rolle Verkäufer / Buchhalter: Der Buchhalter druckt die Rechnungen aus und versendet diese. Sobald sie versendet sind schließt er sie im System ab. Einkaufsprozess: Rolle Einkäufer: Der Einkäufer kann Bestellungen im System erfassen und sobald er alles Nötige erfasst hat in den Wareneingang überführen. Objektorientierte Analyse (OOA) 4/ 11 OAA Projekt MERP Rolle Lagerist: Er kontrolliert jeden Morgen alle anstehende Wareneingänge. Ist ein Wareneingang eingetroffen bestätigt er dies im System und führt ihn in die Lagerverwaltung über. Ist die Ware korrekt eingelagert macht er eine Lagerbuchung auf das entsprechende Lager und führt die Lagerverwaltung in die Lieferantenrechung über. Rolle Buchhalter / Einkäufer: Ist alles korrekt, bezahlt er die Rechnung verbucht und schließt diese im System ab. 2.2 Klassendiagramm Das Klassendiagramm ist in aufgeteilt in 2 Seite. Die 1. Seite zeigt die Serverseite. Sie ist abgeleitet vom 3 – Tier Modell (Data Layer, Data Access Layer, Business Logic Layer). Beschreibung der einzelnen Layer: 2.2.1 Serverseitig – 3 Tier Layer Data – Layer (Datenbank): In dieser Schicht wurde die physische Datenbank durch einen ObjectRelationMapper in eine Objektrelationale Abbildung gemappt und man kann nun bequem durch Objekte auf die DB zugreifen. Data – Access – Layer: Er stellt Factorys(siehe Factory – Pattern) mit den einzelnen Selektionen (Vordefinierte „SQL – Querys“) zur DB – Abfrage zur Verfügung. So wird sichergestellt, dass nicht irgendwelche SQL – Abfragen auf die DB abgesetzt werden. Business – Logic: Enthält Logik die nicht auf dem Client gemacht werden kann. Wie beispielsweise Authentifizierung oder teilweise Asynchrone – DB – Abfragen. Kapselt Methoden die auf die Data – Access Factorys zugreifen und ist zuständig für die Serialisierung der Objekte die nachher über die Leitung geschickt werden. Objektorientierte Analyse (OOA) 5/ 11 OAA Projekt MERP Serverseitig Business Logic Data Access Layer (Selektionen für DB – Zugriff) Datenbank Objektorientierte Analyse (OOA) 6/ 11 OAA Projekt MERP 2.2.2 Clientseitig – MVVM Architecture: Model: Das Model stellt eine Connection – Factory zur Verfügung die eine Connection auf die einzelne Interfaces aufbaut, welche die Business Logic kapselt. Ebenfalls stellt es sogenannte „Repositorys“ zur Verfügung, diese instanzieren diese Verbindung Laden die Daten, deserialisieren sie und stellen sie zur Verfügung. ViewModel Es ist zuständig für die Logik auf dem Client. Hauptsächlich also GUI – Logik, wie aufbereiten von Daten, Abfangen von falschen Dateneingaben und Rechnen mit Daten(Summen, MwSt, usw.). View Bindet sich durch „Bindings“ an die Daten die das ViewModel aufbereitet und zeigt diese an. Objektorientierte Analyse (OOA) 7/ 11 OAA Projekt MERP Client – Seitig (MVVM - Pattern) Model ViewModel Guis / Views Objektorientierte Analyse (OOA) 8/ 11 OAA Projekt MERP 2.3 Aktivitätsdiagramm Das Aktivitäten – Diagramm wurde ausführlich in der Anforderungsspezifikation[2] erstellt. 2.4 Analyse der Persistenzmachung Erklärungen des untenstehenden ORM(Object Relation Modell). Das ist bis jetzt nur eine theoretische Aufführung da bis jetzt noch keine DB erstellt wurde – da ja noch nicht mit dem Projekt produktiv begonnen wurde. Daher können noch weitere Sachen dazu kommen oder auch entfernt werden. Der Aufbau des Namens wurde in 3 Buchstaben gehalten um die Übersicht zu gewährleisten und Abhängigkeiten schon im Namen darstellen zu können. Als Beispiel: Prd -> Produkt, Hauptentität. Prdcat -> Produktkategorie, Unterentität. Einige Namenserklärungen: Puh -> Purchase Header Pui -> Purchase Item Sah -> Sales Header Sai -> Sales Item Objektorientierte Analyse (OOA) 9/ 11 OAA Projekt MERP tbl_Usr PK Usr# UsrNumber UsrIdent UsrName UsrIsEmployer UsrPassword UsrLogedin tbl_Cus PK FK1 Cus# CusNumber CusFirstname CusLastname CusContactname CusUsr# CusIscompany tbl_Sup PK FK1 tbl_Sah Sup# SupNumber SupFirstname SupLastname SupContactname SupUsr# SupIscompany tbl_Prdcat PK Prdcat# PrdcatNumber PrdcatName tbl_Puh tbl_Prd PK Sah# PK Puh# FK1 SahNumber SahCus# SahCreatedate FK1 PuhNumber PuhSup# PuhCreatedate PK Prd# FK1 FK2 PrdNumber PrdName PrdEAN PrdPricePurchase PrdPriceSale PrdPrdcat# PrdSup# tbl_Sai PK FK2 FK1 Sai# SaiNumber SaiSah# SaiPrd# Saivat Saidiscount tbl_Pui PK FK2 FK1 Objektorientierte Analyse (OOA) Pui# PuiNumber PuiPuh# PuiPrd# Puivat Puidiscount 10/ 11 OAA Projekt MERP 3 Glossar Persistenz Persistenz ist die Fähigkeit eines Objektes, über die Ausführungszeit eines Programms zu leben. Objektorientierte Analyse (OOA) 11/ 11
