Mikrokernel-Architektur & Contact First Design

Wer von euch hat bereits damit Erfahrungen gemacht?

Lohnt sich ein Mikrokernel bereits bei kleineren Projekten? Was nehmt ihr, eigene minimalistische, oder grosse fertige Frameworks?
Ist die Schichtenarchitektur noch sinnvoll?

Ist Contract First Design bei grösseren Projekten ein Problem?
Bsp.:
Architektur und der Grossteil des Designs stehen. Mehr als 50% des Projekts sind Codemässig implementiert und erste Integrationstests laufen. Dann kommt jemand daher(Kunde und Verkauf sind die Hauptfeinde des Entwicklers) und meint so war das nicht gemeint bzw. jetzt soll das anders sein. Ergebnis 30% der Verträge(Softwareschnittstellen) sind ungültig. Daraus folgt ein hoher Aufwand im Design und in der Implementation(Säckeweise Interfaces sind ungültig, grosser Aufwand im Refaktoring und Neuerstellung des Codes).
Frage: Ist der grössere Aufwand des Designs in einem solchen Fall mehr hinderlich?.

Also meiner Meinung nach sollte es erst gar nicht so weit kommen, dass großartige Änderungen gemacht werden müssen. Vor dem Deisgn/der Implementierung sollten die Anforderungen an die Sotfware schriftlich (!) festgehalten werden. Damit werden Dinge wie "das war anders gemeint..." von vorn herein ausgeschlossen.
Also aus diesem Grunde würde ich mir da keine Gedanken über Microkernel/Contract First machen.

Allerdings bietet dieses Design weitere Vorteile, die v.a. in Teams sehr wertvoll sein können (unabhänige Entwicklung von Komponenten, etc.).

Naja meine frage nach Mikrokernel betraf kleine Anwendungen.
Und das es nicht soweit kommen sollte ist klar, aber nicht immer(meiner Erfahrung nach selten) stimmen Wunsch und Wirklichkeit überein. Für dich mag es zwar ein Extremfall sein, aber wenns passiert? Mich interessiert die Frage., ob in einem derartigen Fall Contract First Design vielleicht nicht eher ein Hemmschuh ist.

Ist das Schichtenmodell nicht eigentlich obsolet(OSI ist nicht gemeint).

Hallo zusammmen,

ich höre "Contract First Design" heute zum ersten Mal und "Mikrokernel-Architektur" kenn ich nur aus dem Betriebssystembau. Ich habe eine ungefähre Vorstellung, was "Contract First Design" sein könnte, und gar keine rechte, was "Mikrokernel-Architektur" im Zusammenhang mit "normaler" Anwendungsentwicklung sein könnte.

Würde mich freuen, wenn jemand die Begriffe beschreiben und erläutern könnte.

herbivore

@exec: Das klappt aber in der Realität nicht! Der grobe Rahmen kann zwar festgelegt werden, aber die vielen Kleinigkeiten fallen erst auf, wenn die Anwender mit einer fertigen Anwendung arbeiten. Die Entwickler kennen oft die Geschäftsprozesse nur aus der Theorie. Deshalb scheitern viele Software-Projekte. Dieser "build to end" Ansatz klappt nur in einer perfekten Welt. Das haben mittlerweile viele erkannt und ändern ihre Entwicklungsprozesse. Heute entwickelt man "build to change". Das heißt, dass man Änderungen erwartet und gut darauf vorbereitet ist. Unter anderem auch durch eine bessere Organisation (z.B. gut durchdachtes Change Management).

Die Anforderungen ändern sich oft schneller, als man sie überhaupt umsetzen kann. Überhaupt bei größeren Projekten, die Monate oder Jahre dauern. Es gibt so viele Faktoren, die man nicht beeinflussen kann. Die Firmen wollen flexibel sein. Deshalb brauchen sie auch flexible Software, wo sich Geschäftsprozesse und Geschäftsregeln schnell,zuverlässig und kontrollierbar umsetzen lassen.

Contract First Design beschreibt genaue Abgrenzungen. Ein Part wäre: es gibt Interfaces, und jeder Programmierer schreibt gegen die Scnittstellen ohne die dahinter liegende Implementation zu kennen. Stell dir das in einer grossen Anwendung vor(Schnittstellen nach draussen, eine Hand weiss nicht was die andere tut(die einzige Verbindung ist der Vertrag)). Du programmierst und schuftest dir Seele aus dem Leib, dann wird die Schnittstelle geändert(höhere Gewalt) und du merkst der grösste Teil deiner Arbeit ist nichtig).
Mikrokernel kommt von modernen BS(OS) soll angeblich aber sogar bei sehr kleinen Anwendungen sinnvoll sein. Was bedeutet du erzeugt eine .Exe(2)und das wars(der Rest sind Librarys).

Edit 1: gröbste Rechtschreibfehler besetigt.(sz gibt es nicht bei schw. Tastatur, falls darüber gemeckert wird)

Edit2: Nichts gegen Contract First Design, mich interessieren nur die Vorteile bei einer solchen Konstellation(wie gesagt: normal). Alle Theorie ist gut. Nur wenn die Vorrausstzungen nicht stimmen scheint das nicht zu funktionieren.
Die Frage bleibt: Kann man mit dem Hilfsmittel(Werkzeug) solche Situationen besser bewältigen, oder nicht? Ist der Overhead zu gross? Oder wird es noch zu falsch angewandt(das Werkzeug: Contrakt First design)?

Hallo ikaros,

zu "Contract First Design": heute kennt man ohnehin kaum noch die dahinterliegende Implementierung. Heute sind die "Verträge" einfach die Dokumentation, z.B. die SDK-Dokumentation.

Ich sehe gute Chancen, dass man Schnittstellen definieren kann, die Änderungen überleben. Gerade, wenn man die Implementierung nicht kennt und gerade, wenn nur der zur Benutzung notwendige Teil des aus der Implementierung resultierenden Verhaltens beschrieben ist, kann man doch einige Änderungstoleranz erreichen.

Ich dachte "Contract First Design" hätte was mit Web-Services zu tun.

Unter "Mikrokernel-Architektur" im Zusammenhang mit Anwendungsentwicklung kann ich mir leider immer noch nichts vorstellen.

herbivore

PS: Das ß bekommt man mit: ALT drücken, 225 auf dem Zehnerblock eingeben, ALT loslassen. 🙂

Contract-First-Design wird meistens in Verbindung mit Webservices und verteilten Anwendungen erwähnt. Wenn mehrere Parteien (bzw. Anwendungen/Komponenten) miteinander Daten austauschen, müssen sich alle im selben Format unterhalten. Die Definition dieses Formats wird als Vetrag (Contract) bezeichnet. Bei modernen Anwendungen wird dieser in Form eines XSD-Schemas modelliert. Die Kommunikationspartner müssen sich an diese Schnittstelle halten. Da die Daten als XML-Dokumente versendet werden, kann man sie einfach durch das Schema (den Contract) validieren lassen. Dieser Design-Ansatz ist sehr sinnvoll bei der Verknüpfung von einzelnen Anwendungen oder Komponenten. Wenn die Kommunikation firmenübergreifend stattfindet (B2B) ist dieser Ansatz auf jeden Fall zu verwenden.

Einige Leute haben es aber falsch verstanden und bauen für jede Kleinigkeit Berge an XSD-Schemas. Dann ärgern sie sich, wenn sich Anforderungen ändern und die ganzen Veträge hinfällig sind.

In einer der letzten Ausgaben der DOTNETPRO war ein Artikel über Mikrokernel-Architektur drin. Habs nur überflogen. Ich hab das Heft leider in der Firma liegen. Kanns mir aber morgen durchlesen und eine kurze Zusammenfassung posten.

Sorry, ich habe zB zeit vergeudet, für Korrekturen(besser ist wohl geschrieben ist geschrieben))
@Herbivore:
Es geht ja nicht um statische Dinge. Was eine Partei betrifft auch die andere(z.B: SAP sieht's locker).
Der eigentliche Vorteil von Contract First Design besteht ja auch in der Implementation gegen Schnittstellen. Da hat es auch seine Vorteile. Das Problem sehe ich in willkürlichen Änderungen, das ist meine Frage(Ich denke Details sind erläutert).
@Rainbird:
Das ist unabhängig von Technologie((Com+, DCom, Enterpriseservices(Du kennst die feinen Unterschiede), Webservices etc). Es betrfft Änderungen in BL und PL, das ist der Knackpunkt.

Edit: Rechtschreibfehler und so(Auwei, entschuldigt aber die Tastastatur wird nur vom Monitor beleuchtet)

Hallo ikaros,

naja, es geht ja eben darum, das bei aller Veränderung Unveränderliche zu finden. In meinem Beitrag habe ich die Erwartung und Hoffnung zum Ausdruck gebracht, dass es möglich ist, Schnittstellen zu definieren, die auch bei Veränderungen tatsächlich relativ statisch bleiben.

Hallo Rainbird,

das wäre sehr nett.

BTW: Magst du noch was zu TreeView, ImageList und Objektdesign schreiben?

herbivore

@Herbivore: Schon klar, nur darum ging es nicht(hält nicht stand).

Ausserdem, CFD war nicht die nicht die einzige Frage(Ist relativ neu(allgemein)). Wichtig für mich sind Erfahrungen(praktischer Einsatz und Ergebnisse).
Es interessieren mich auch Erfahrungen im Bereich Mikrokernels(bei kleinen Sachen) Overhead oder Segen. Bzw. die Frage: Ist das denken in Schichten noch praktikabel, oder sollte man umschwenken?

Hallo ikaros,

Schon klar, nur darum ging es nicht(hält nicht stand).

damit beantwortetst du deine Eingangsfrage negativ: Es lohnt nicht Aufwand in Verträge zu stecken, weil man sie bei einer Änderung wegwerfen kann.

Ich beantworte aber die Eingangsfrage positiv. Das kommt wohl daher, dass ich zu einer anderen Einschätzung als du komme.

Ohne dass ich das böse meine: Wenn du der festen Meinung bist, dass Schnittstellen (und andere Meinungen 🙂 nicht standhalten, brauchst du uns nicht zu fragen. 🙂

Ich denke das Schichtenmodell behält seine Berechtigung. Siehe dazu u.a. meine Beiträge in: TreeView, ImageList und Objektdesign

herbivore

Ich fürchte du hast meine Frage nicht verstanden( wahrscheinlich meine Schuld)
Meine Frage war negativ gemeint(im Zusammenhang mit prakt. Erfahrungen).
"Nicht Böse gemeint...": es geht mir um Erfahrungen, nicht um Meinungen.
Dein Wunsch hält IMHO der Realität nicht stand.(darum geht auch nicht). Was ich von Schnittstellen im allgemeinen halte, brauche ich nicht nochmals festhhalten, der Wert ist schon klar. Ich vermute einfach, du hast nicht genug gelesen(meine erbärmlichen Postings + das du verstehst was ich ansprechen will), andererseits kann ich nicht deine Mitteilung verstehen.
Ich will dir damit nicht zu nahe treten(ich halte dich für einen guten + hilfsbereiten Programmierer). Doch ich glaube du verstehst nicht ganz, was ich ausdrücken will.

Hallo ikaros,

Doch ich glaube du verstehst nicht ganz, was ich ausdrücken will.

Kein Problem, das Gefühl habe ich umgekehrt auch 🙂

Machen wir es mal konkret:

Ist der grössere Aufwand des Designs in einem solchen Fall mehr hinderlich?

Auch wenn du es nicht glauben oder hören willst: Meiner Erfahrung nach ist größere Aufwand beim Designs in einem solchen Fall nützlich.

herbivore

Du meinst im Fall des zu spät seins?
"Deiner Erfahrung nach" hätte ich gern(ein terffendes) Beispiel.(natürlich halbwegs gelogen). Ich hoffe es bezieht sich auf meine Frage.

Schnittstellen sind ja keine neue Sache. Nur weil sie jetzt jemand mit XML-Technologie gemacht hat, steht überall "Contract-First" in der Fachpresse. Alter Wein in neuen Schläuchen.

Die Schichtenarchitektur ist immer noch gültig. Allerdings für Datenbankgestützte Geschäftsanwendungen. Eine Textverarbeitung passt wohl nicht ganz.

Ich lege eher Wert auf gekapselte Komponenten. Mit einem guten "Komponenten-Lego" und etwas C#-Code zum zusammenkitten baut man momentan die flexibelsten Anwendungen. Egal ob es eine Textverarbeitung, ein Spiel oder ein gigantisches ERP-System ist. Dabei kommt mir der BizTalk Server 2004 ganz gelegen. Bin zwar noch in der Einarbeitungsphase, aber das Tool gefällt mir immer besser. Endlich kann man vernünftig modellieren und grafisch prigrammieren ohne auf herkömmlichen C#-Code und seine bestehenden Komponenten verzichten zu müssen.

Hallo ikaros,

Ergebnis 30% der Verträge(Softwareschnittstellen) sind ungültig.

Es bezieht sich schon auf deine Frage. Nur ist ja in der Vorgeschichte deiner Frage schon eine Vorwegnahme enthalten, eben dass sich 30% der Schnittstellen ändern. Das halte ich bei einem guten Design eben nicht für zwangsläufig.

Zu einer konkreten Erfahrung: In einem Projekt haben wir von Anfang an auf eine Zentrale Instanz (hier ist das mal das richtige Wort) gesetzt, die alle Objekte verwaltet. Als nun die Anforderung kam, die Datenbankzugriffe zu protokollieren, konnten wir das zentral implementieren. Wäre ein ziemlicher Aufwand gewesen, wenn die DB Zugriffe im Code verstreut gewesen wären. Was hat das mit Schnittstellen zu tun? Wir hatten eben eine zentrale Schnittstelle zu Datenbank.

Auch das folgende meine ich nicht böse: Da ich nach wie vor das Gefühl habe, dass wir etwas aneinander vorbeireden, klinke ich mich hier aus der Diskussion aus.

herbivore

herbivore

ikaros
Ist der grössere Aufwand des Designs in einem solchen Fall mehr hinderlich?
Auch wenn du es nicht glauben oder hören willst: Meiner Erfahrung nach ist größere Aufwand beim Designs in einem solchen Fall nützlich.

Es gibt auch den umgekehrten Ansatz - Extreme Programming.* schlichtes Design.

• kein Code auf Vorrat / kein Design für die Zukunft / kein mächtiges Framework.
• Es wird nur umgesetzt was gefordert ist, mit dem minimal möglichen Code.
• Wenn die Anwendung schon mehr kann, wird zurückgebaut.
• Weiterentwicklung in kleinen Schritten. Refaktorierung bestehenden Codes. Tägliche Integration, Nightly Builds. Es muss jederzeit eine aktuelle, lauffähige Version verfügbar sein.
• Der Stand wird in kurzen Zyklen beim Kunden vorgestellt. Es wird entschieden wie es weitergeht und was als nächstes angegangen werden soll. Der Kunde ist immer auf dem laufenden. Es gibt keine Überraschungen durch Missverständnisse. Die Software kann in Teilen schon vor der entgültigen Fertigstellung eingesetzt werden.

Es gibt noch ein paar mehr Punkte, die ich hier aber nicht alle aufzählen will. Es sind viele kleine, einfache Regeln, geboren aus der Erkenntnis heraus, dass zu weite Vorausplanung in vielen Fällen einfach Zeitverschwendung ist. Vieles der Vorplanung/Entwicklung muss wieder umgeworfen werden - neue Erkenntnisse/Einblicke während des Programmierens, Änderungs-/Erweiterungswünsche vom Kunden (der Kunde weiss auch nicht von Anfang an was er haben möchte) usw. Oder noch schlimmer, der Code wird starr und unflexibel und unnötig kompliziert durch ein an der Praxis vorbei designtes Framework.

Hier eine gute Seite zu XP: http://www.frankwestphal.de/ExtremeProgramming.html

Gruss
Pulpapex

Bei kleineren Projekten ist das ok. Wenn ich am Anfang ein Notpad bauen soll und später stellt sich heraus, dass es doch Word sein soll. Für solche Projekte ist das bestimmt gut. Die Definition von klein ist natürlich sehr dehnbar. Besser ist vielleicht das Wort "flach". Man barucht dazu auf jeden Fall erfahrene Entwickler.

Wenn ich aber weiss, dass ich z.B. das ultimative Content Management System bauen will, muss ich eine größere Architektur planen. Die Frage ist, ob ich dann eine Plattform erstelle, die flexibel und offen aber mächtig ist, oder ob ich ein gigantisches perfektes statisches Gebilde erdenke, welches nicht flexibel auf Änderungen reagiert.

Am besten ist, wenn es schon eine Plattform für meine Anwendung gibt. Mit Plattform meine ich eine spezialisierte Softwareumgebung zur Lösung bestimmter Aufgaben. Der MS Commerce Server z.B. ist eine Plattform für eCommerce-Anwendungen.

@pulpapex: danke für den Link, XP funktioniert anscheinend am besten im Spiralmodell mit regelm. Feedback vom Kunden.
@Herbivore: Ich glaube auch irgendwie, das wir irgendwie aneinander vorbeigeredet haben, das war meine Schuld(ich hatte es eilig, musste weg->naja na dann sollte man wohl nicht posten).