2 Objektorientierte Analyse

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