Differenzierung zwichen OOA und OOD
-
Wo liegt die grenze zwischen OOA und OOD anhand des Klassendiagramm. gehört das in OOD und OOA ..irgendwie gehört das in beide.. wie diffrenzeri ich das am besten??
-
Gibt keine klare Abgrenzung zwischen OOA und OOD, der Übergang ist fließend. Muss also jeder individuell selbst entscheiden. Ich würde Klassendiagramme fast immer in den Bereich OOD zählen, weil sie ja mehr oder weniger dann genauso implementiert werden. OOA halt (falls überhaupt nötig) die Anforderungen (z.B. Use Cases) formalisieren durch Sequenz- oder Aktivitätdiagramme, die beispielhaftes Verhalten des Systems beschreiben. Aber wie gesagt: Übergänge sind fließend, denn bevor man z.B. Sequenzdiagramme entwirft, muss man zumindest ja schonmal ansatzweise die spätere Objektstruktur kennen.
PS: In den meisten Fällen beschränkt sich OOA und OOD wohl eh lediglich nur auf den Entwurf von Klassendiagrammen.
-
hmm danke... ist ne super antwort;) so kann ich mir aufwand sparen...!! die sequenzdiagramm werd ich eh weglassen.... das Diplomarbeit sollte ehr Progamm implemtierungs - Fokusiert geschrieben werden.. so muss ich nich so ausführlich auf die planungsphase eingehen...
-
Denke ich auch. Wenn das nicht ausdrücklich gewünscht ist, würde ich die Kapitel über Planung etc. (Anforderungsanalyse, OOA) doch eher kurz halten und mich auf Entwurf und Implementierung konzentrieren. Denn wenn das gut ist, dann weiss der Leser eh, dass offenbar auch sinnvoll im Vorfeld geplant wurde.
Stattdessen ist es häufig sinnvoller, am Ende nochmal umfangreiche Fallbeispiele zu beschreiben, die durchgehen belegen, dass die Anwendung auch das tut, was sie soll.
-
Hm welche Elmente des OOA bzw. OOD würdest du(byto)/ihr auf jedefall beschreiben?
Gibt da ne bestimmte vorgehenweise für die Fallballspiel?
Diese werden dann wohl im Kapitel Testpahse beschrieben?
-
BorisDieKlinge schrieb:
hmm danke... ist ne super antwort;) so kann ich mir aufwand sparen...!! die sequenzdiagramm werd ich eh weglassen.... das Diplomarbeit sollte ehr Progamm implemtierungs - Fokusiert geschrieben werden.. so muss ich nich so ausführlich auf die planungsphase eingehen...
egal. hauptsache deine rächtshreiprüfung funktioniert
-
hmm.. ist doch völlig egal ob die spache syntaktisc oder symantisch oder was auch immer nicht stimmt ist! hauptsache man versteht die beudeutng was da hinter steckt;)
-
BorisDieKlinge schrieb:
hmm.. ist doch völlig egal ob die spache syntaktisc oder symantisch oder was auch immer nicht stimmt ist! hauptsache man versteht die beudeutng was da hinter steckt;)
ich meine ja, nicht dass du in deiner diplomarbeit so viele fehler machst, wie in deinen postings hier. dann schreib' lieber alles klein (wie ich
)
-
hehe ja klar in der Diplomarbeit streng ich mir mehr an...;) da kann ich mir zeit lassen.. hie gehts mir um interaktions/kommunikations geschwindigkeit;)
-
BorisDieKlinge schrieb:
hie gehts mir um interaktions/kommunikations geschwindigkeit;)
mir auch. deshalb alles klein...
-
Dieser Thread ist ge-bookmarkt.
Ihr sind wohl das informationstechnische Pendant von Tünnes und Scheel.
Im Kölle haben wir im Moment für euch gut Verwendung.
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. Selbst in Wikipedia steht nur Müll:
http://de.wikipedia.org/wiki/Objektorientierte_Analyse
http://de.wikipedia.org/wiki/Objektorientiertes_DesignUm sogar einen Lead Architect die Grundzüge des System Engineering und der Konzeption beizubringen brauche ich selbst Monate, weil der Denksterotyp der meisten Menschen in dieser Hinsicht recht wild und opportunistisch gewachsen ist und sich selten mit den Meta-Modellen bzw. Metameta-Modellen des Denkens auseinandersetzen. Dabei wird man ja schwermütig ...
Selbst die Spezifikation der SysML ist für diese Zwecke ungenügend:
www.sysml.orgDer RUP oder OEP kann eine Hilfe sein, ist IMO aber zu High-Level:
http://de.wikipedia.org/wiki/Rational_Unified_Process
http://www.oose.de/oep/Das gibt vielleicht eine Diplomarbeit ...
-
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?
-
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..