Differenzierung zwichen OOA und OOD
-
Jester schrieb:
Prof84 schrieb:
Zu eurer Entschuldigung: Es verstehen nur Wenige die genauen Zusammenhänge zwischen Analyse und Design und können eine klare Trennung vornehmen oder auch nicht vornehmen.
Na dann lass doch mal hören. Oder war das nur wieder ne Blase mit heißer Luft?
ach nö
jetzt surft er ein bischen rum und schreibt einen ellenlangen aufsatz hier rein...
-
Prof84 schrieb:
Es verstehen nur Wenige die genauen Zusammenhänge zwischen Analyse und Design und können eine klare Trennung vornehmen (...)
Prof84 schrieb:
(...) weil der Denksterotyp der meisten Menschen in dieser Hinsicht recht wild und opportunistisch gewachsen ist (...)
Hast Du vor die Menschen an die Software anzupassen ?
-
Keine Ahnung ob ich schon mal OOAgemacht hab, aber OOD glaub schon.
OOD ist wohl seine Software object orientiert zu designen, oder? Sonst wäre der begriff etwas komisch gewählt. Also denk ich mal, das Programm so zu planen, das ich das ich z.B. Patterns verwende. Nicht nur ein Programm schreiben, bei dem alles in Klassen steht, sondern richtig object orientiert halt.
OOA - keine Ahnung. Macht man die schon mit dem Kunden? Der wird wohl kaum was von Strategie Patterns hören wollen. Ist das ne Vorgehensweise um die Anforderungen vom Kunden (die doch nie vollständig sind
) nach OO Elementen zu durchsuchen? Wäre irgendwie komisch. Dann endet es doch nur im OOD.Vielleicht kann mich unser Prof mal erleuchten.
-
sosieht biser mein ablauf aus
Grob Ziel/Zweck definition, Grop Anforderungen, Fein anforderungen und Ramenbedingungn, Stakeholder/ Use-Cases! ---- IER FEHLT MIR NE ÜBERGANGSPASE ZU OOD --- Projekt darstellung im 3 Schcihtenmodel, definiton der Progammierumgebung, Grob defintion der Komponentnen, bschreibung der Komponenten , Module der Komponenten, ER-Diagrmm der einzelen Module, GEsamt konzept, bischen bla lbal bla .. dann OOP umsetzung...
Das problem ist das ich direkt nach Use-casse der OOA mit dem Projekt Design mit der destellung als Drei-Schichten-Modell.. dazwiscen will ic noch biscén nen überagnen .. was felt hier noch..
-
BorisDieKlinge schrieb:
sosieht biser mein ablauf aus
Grob Ziel/Zweck definition, Grop Anforderungen, Fein anforderungen und Ramenbedingungn, Stakeholder/ Use-Cases! ---- IER FEHLT MIR NE ÜBERGANGSPASE ZU OOD --- Projekt darstellung im 3 Schcihtenmodel, definiton der Progammierumgebung, Grob defintion der Komponentnen, bschreibung der Komponenten , Module der Komponenten, ER-Diagrmm der einzelen Module, GEsamt konzept, bischen bla lbal bla .. dann OOP umsetzung...
Das problem ist das ich direkt nach Use-casse der OOA mit dem Projekt Design mit der destellung als Drei-Schichten-Modell.. dazwiscen will ic noch biscén nen überagnen .. was felt hier noch..
ich finde, dass in OOA neben use-cases ein fachklassendiagramm sehr wichtig ist. das fachklassendiagramm soll die beziehungen der fachbegriffe, die man in der analyse vewendet und (hoffentlicht auch) in einem glossar deffiniert hat, formalisieren, jedoch (möglichst) technologieunabhängig!
ein solches fachklassendiagramm stellt IMHO eine sehr gute brücke zum entwurf dar!Gruß
mathik
-
hmmm... ein Fachklassendiagramm sind quasi die klassen ohne attribute, eigenschaften und funktionen??
wäre es sindvoll diese fachklassendiagramm im verbindung mit einem aktivitätdiagramm zu kombinieren??
-
BorisDieKlinge schrieb:
hmmm... ein Fachklassendiagramm sind quasi die klassen ohne attribute, eigenschaften und funktionen??
keineswegs. natürlich können bzw. sollten dort auch attribute und operationen enthalten sein. jedoch sollte das ganze technologieunabhängig sein!
es ist dort somit (in der regel) völlig irrelevant ob dein system z.b. auf verschiedenen systemen läuft oder wie deine persistenz funktioniert oder wie deine gui aufgebaut ist.ein fachklassendiagramm beschreibt lediglich formal und grafisch deine begriffe aus der analyse. wenn du z.b. schreibst "ein x ist ein a und besteht aus y", dann malst du halt "x erbt von a und eine ?:n assoziation zwischen x und y".
für mich haben fachklassendiagramme meistens einen höheren wert, als die klassendiagramme im (fein)entwurf. dort ist nämlich die problemdomäne ohne "technischen ballast und einschränkungen" vereinfacht und dennoch formal dargestellt.
wenn das fachklassendiagramm sauber ist, dann kann es meistens einfach in einen (technischen) entwurf transformiert werden.BorisDieKlinge schrieb:
wäre es sindvoll diese fachklassendiagramm im verbindung mit einem aktivitätdiagramm zu kombinieren??
wenn es dann besser verständlich ist, warum nicht
-
ok gut und was unterscheidet dann die Fachklassen Diagramm mit der nacher wirklich implementeire Klassen im Code.. es ist ja sehr unwahrscheinlich das alles bedacht werden kann wenn es ein komplexes prgaomm ist...
d.h. es kann vorkommen das die Fachklassen diagramm nicht mehr ganz an die Richtigen ER-Diagramm die umgesetzt werden bzw. programmiert werdne nicht mehr ran kommen, da beim progammieren ja immer wieder änderungen und umdenkereien vorkommen..
-
BorisDieKlinge schrieb:
ok gut und was unterscheidet dann die Fachklassen Diagramm mit der nacher wirklich implementeire Klassen im Code.. es ist ja sehr unwahrscheinlich das alles bedacht werden kann wenn es ein komplexes prgaomm ist...
je komplexer das programm, desto mehr wert haben fachklassendiagramme gewöhnlich. es ist ja das ziel von fachklassendiagrammen, die ganze komplexität aus der implementierung zu abstrahieren und möglichst nicht darzustellen.
und es ist natürlich auch richtig, dass am anfang nicht alles verstanden worden ist. deshalb haben wir ja iterative agile entwicklungsprozesse...ganz simples bsp.:
zwischen Person und Rolle existiert gewöhlich eine n:n beziehung. im fachklassendiagramm würdest du eine n:n assoziation malen. in datenbanken oder in gewöhnlichen Programmiersprachen kannst du sowas jedoch nicht direkt realisieren! in datenbanken würde man dies z.b. über eine zwischen-tabelle "rollenzuweisung" realisieren. aus 2 klassen im fachklassenmodell sind nun plötzlich 3 im entwurf geworden...
-
mathik schrieb:
ein fachklassendiagramm beschreibt lediglich formal und grafisch deine begriffe aus der analyse. ...jedoch sollte das ganze technologieunabhängig sein! ...
Auf den Unterschied bin ich auch erst vor Kurzem durch einen (IMO sehr guten) Seminarleiter gestoßen (worden): Fachklassen entsprechen eher der Anschauung von der Fachlichkeit.
Und nur in den allerseltensten (simpelsten) Fällen werden diese Klassen so implementiert. Stattdessen erarbeitet man ein "technisches" Klassenmodell, in dem man dann auch so Dinge wie Designpatterns, technische Beschränkungen etc. berücksichtigt ... und manchmal muß man auch da noch mal verfeinern, wenn man wirklich noch alle Hilfsklassen modellieren will/muß => 2-3 "Klassenmodelle" kommen bei größeren Projekten schnell zusammen.Erstaunlich, dass so wenig darüber geredet wird und meistens nur von dem Klassenmodell gesprochen wird.
Gruß,
Simon2.
-
jepp das is die problematik... die wenigsten die für sich progammieren machen das ´direkt ausm kopf und ohne groß zu planen;)
naja verständlich ist ja auch anstrengt so ne komplexe planung, und nacher wird doch alles anderes als man gedacht hat;)
d.h. Ich modeliere ein Fachklassendiagramm was ganz simpel aufgebaut ist.. später dann wenn ich dann das reale Klassendiagramm habe kann sich extrem unterscheiden .. wobei extrem relativ ist!??