Begriffsbildung "Software-Design"

[Denis]

Ralf hatte in seinem Blog unter http://ralfw.blogspot.com/2011/07/design-zur-diskussion-gestellt.html
eine Diskussion zu diesem Thema angeregt, die dort leider zu keinem
Ergebnis gekommen ist. Deswegen möchte ich es hier noch mal aufgreifen
und versuchen meinen Beitrag zur Begriffsbildung beizutragen.

Zunächst habe ich, auf der Suche nach einer Definition für den Begriff
Software-Design, versucht zu verstehen, warum jemand irgendwann einmal
den Begriff "Design" im Zusammenhang mit Software verwendet haben
könnte. Es ist naheliegend, dass der Begriff "Design" zum damaligen
Zeitpunkt schon eine feste Bedeutung hatte und der Begriff "Software"
daran gemessen eher neu war. Scheinbar war jemand auf der Suche nach
einer Analogie.

Ich bin geneigt diesem Analogie-Gedanken zu folgen. Deswegen sollte
man sich die Begriffsdefinition von Design genauer ansehen. Ein guter
Ausgangspunkt wäre http://de.wikipedia.org/wiki/Design. Dieser Artikel
geht sehr viel weiter und betrachet Design im Allgemeinen (ohne
natürlich Software-Design zu erklären). Aber ich denke, die Analogie
wurde vom Begriff des Designs für konkrete Objekte abgeleitet, die in
der industriellen Massenproduktion entstanden sind (Ralf hatte das in
einem seiner Kommentare im Blog schon angesprochen). Ähnliche
Industrieprodukte verschiedener Hersteller waren in ihrer
Hauptfunktion ja festgelegt. Unterscheiden konnten sie sich nur noch
durch nicht-funktionale, die Hauptfunktion unterstreichende oder
unterstützenden Merkmale.

Vielleicht ist hier auch die Analogie zur Software-Entwicklung zu
finden: Software-Design wäre dann dazu da, die funktionalen
Anforderungen an eine System durch nicht-funktionale Merkmale zu
unterstützen oder herauszustreichen.

Wenn einen Applikation z.B. die funktionale Anforderung hat, Daten zu
persistieren, wäre es erst mal funktional egal, wie das realsiert wird
- durch eine relationale Datenbank oder eine NoSQL-Datenbank. Es ist
eine Design-Entwscheidung sich für das eine oder das andere zu
entscheiden. Die Entscheidung wird natürlich anhand nicht-funktionaler
Anfoderungen gefällt und kann auch falsch oder unpassend sein. Das
wäre dann Design und es kann gut oder schlecht sein.

Software-Design wäre damit der Entwurf eines Software-Systems durch
systematische Auswahl und Kombination von Lösungsmöglichkeiten anhand
von nicht-funktionalen Anforderungen für dieses Software-System.
Damit liesse sich dann auch Design von Architektur abgrenzen – es ist
das Herausarbeiten einer konkreten Lösungsvorschlags - einer
Architektur - aus einem Lösungsraum, durch Gewichtung der
Lösungsmöglichkeiten anhand von Anforderungen. In diesem Sinne würde
ein Design immer eine Architektur umfassen, jedoch zusätzlich zur
konkreten Architektur-Darstellung auch noch die Anforderung und
möglicherweise daraus resultierende Schlussfolgerungen aufzeigen, die
zu dieser konkreten Architektur geführt haben - also die zugehörigen
Entscheidungen.

Ich denke auch, Design muss es auf jeder Abstraktionsebene von
Architektur (im Sinne von Ralfs Blog-Artikel
http://ralfw.blogspot.com/2010/12/was-ist-softwarearchitektur-teil-2.html)
geben, das geht bis runter zu Concerns und deren Umsetzung in
funktionalen Code. Wie ich zum Beispiel die Sortierung einer Liste
umsetze ist Design, es hängt von den Anforderungen und dem Kontext ab.
Wenn z.B. gewährleistet ist, dass die Listen prinzipiell weniger als 5
Elemente haben, wäre es übertrieben, dafür einen Heap-Sort- oder Merge-
Sort-Algorithmus zu implementieren (vom Implementierungsaufwand und
auch vom Laufzeitverhalten her), dann reicht auch Bubble-Sort.

Denis

[Ralf Westphal]

Tja… was ist "Design"? Ich denke, das lässt sich nur klären, wenn wir vom Englischen ausgehen, denn von dort kommt er ja für unsere Branche:

"umfasst der angelsächsische Begriffdesign auch technische Anteile der „Gestaltung“."

Es geht also um Technisches, keine Äußerlichkeiten. Wir sind keine Designer im Sinne von Alessi oder Colani.

Ganz allgemein stimme ich dieser Definition bei Wikipedia zu: "Bezeichnung für den Prozess des bewussten Gestaltens".

Die Frage ist nun allerdings: Was ist Gestaltung?

Dazu sagt Wikipedia, http://de.wikipedia.org/wiki/Gestaltung:

dass "eine Sache (ein materielles Objekt, eine Struktur, ein Prozess, ein Gedankengut etc.) verändert wird, d. h. erstellt, modifiziert oder entwickelt wird und dadurch eine bestimmte Form" erhält.

Nun ist die Frage: Was ist "bestimmte Form"? Wikipedia hilft nun nicht mehr weiter, finde ich. Wir drehen uns im Kreis mit den Definitionen. Design verweist auf Gestalt, die auf Form verweist, die auf Gestalt verweist usw.

Ich trete deshalb mal heraus und definiere salopp: Gestalten und formen bedeutet, etwas eine Struktur geben. Und eine Struktur ist eine Anordnung von Elementen, d.h. Elemente sind ausgewählt bzw. definiert und in Bezug gesetzt worden.

Daraus leitet sich für mich ab: "to design" bzw. entwerfen bedeutet, dass wir Software strukturieren, damit sie einen Zweck erfüllt. Der Begriff Struktur enthält noch keinen Zweck; der kommt erst mit dem Begriff Entwurf zur Struktur dazu. Eine entworfene Struktur ist eine zweckdienliche Struktur. An einen Entwurf kann ich daher einen Qualitätsmaßstab anlegen.

Aus meiner Sicht ist deshalb Entwurf/Design ein Oberbegriff für verschiedene Tätigkeiten, deren Ergebnis Strukturen sind.

Abzugrenzen ist Entwurf auf der anderen Seite vom Bauen. Wer baut, stellt auch Strukturen her, aber er entwirft dabei nicht. Entwerfen stellt Strukturen also in ganz bestimmter Weise her.

Ich würde dazu sagen, Entwerfen plant Strukturen. Ein Entwurf ist mithin abstrakt, ein Bau ist konkret. Ein elektronischer Schaltplan wurde entworfen, die elektronische Schaltung, die dann im Fernseher steckt, wurde nach diesem Entwurf dann gebaut.

Entwerfen ist also eine hauptsächlich kreative Tätigkeit, Bauen ist eine hauptsächlich unkreative Tätigkeit. Beim Bauen wird ja "nur noch" umgesetzt.

Bauen kann man einen Entwurf dann auch ganz oft. Bauen ist Vervielfältigung.

Und erst der Bau erfüllt den Zweck, der den vorhergegangenen Entwurf initiiert hat.

Nun zur Softwareentwicklung:

Was erfüllt einen Zweck? Ausführbarer Code, also z.B. der Output eines Compilers. Der Compiler baut ausführbaren Code nach einem Entwurf, dem Quellcode. Diese Sichtweise ist ja aber nun schon alt, http://www.developerdotstar.com/mag/articles/reeves_design_main.html

Quellcode ist mithin das Ergebnis eines Entwurfsprozesses. Softwareentwickler sind Entwerfen, Designer. Wenn sie Quellcode schreiben, definieren sie Strukturen, die vom Compiler gebaut werden (bzw. zur Laufzeit aufgebaut werden).

Diese Strukturen dienen Zwecken, den Anforderungen des Kunden. Die zerfallen in zwei Kategorien: funktionale und nicht-funktionale Anforderungen. Und dazu kommen noch Anforderungen an die Evolvierbarkeit. Das sind nicht-funktionale Anforderungen, die der Kunde gewöhnlich allerdings nicht explizit benennt.

Mir scheint es sinnvoll, den Entwurf von Software ebenfalls zu kategorisieren. Wenn wir Strukturen für nicht-funktionale Anforderungen entwerfen, dann "architekturieren" wir sie, dann sind wir Architekten. Und wenn wir Strukturen für funktionale Anforderungen entwerfen, dann modellieren wir sie, dann sind wir Modellierer. (Ob "modellieren" der beste Begriff für diese Seite des Entwurfs ist, weiß ich nicht. Aber ich finde ich im Augenblick gut genug.)

Während des Architekturierens treffen wir Entscheidungen hinsichtlich Strukturelementen und ihren Beziehungen, damit nicht-funktionale Zwecke erfüllt werden, z.B. Performance, Sicherheit usw. Dazu gehört z.B. die Aufteilung des Codes auf verschiedene Prozesse oder Threads, der Einsatz eines Cache, die Auswahl einer Persistenztechnologie, die (De)Normalisierung von relationalen Datenstrukturen, der Einsatz eines Plug-In-Frameworks.

Während des Modellierens treffen wir Entscheidungen hinsichtlich Strukturelementen und ihren Beziehungen, damit funktionale Zwecke erfüllt werden. Wir überlegen uns, aus welchen Schritten eine Problemlösung bestehen sollte, um von gegebenen Eingaben zu gewünschten Ausgaben zu kommen.

Beim Modellieren entscheiden wir z.B., ob Daten sortiert werden sollten. Und beim Architekturieren entscheiden wir z.B., ob eine Sortierung mit Quicksort oder Bubblesort durchgeführt werden soll.

Architekturieren und modellieren sind also ziemlich verschiedene Tätigkeiten, würde ich sagen. Im Quellcode fließen ihre Entwürfe dann aber notwendig zusammen. Wer umgekehrt auf Code schaut, hat daher Mühe, beide Sichtweisen daraus zu re-generieren.

Deshalb plädiere ich dafür, zumindest Teile von Architektur und Modell in anderer Form zu notieren als Quellcode bzw. in einer dem Codieren vorgelagerten Phase anders zu beschreiben.

Entwurf und Modell gibt es für mich in mindestens zwei Körnungen: grob und fein. Feinkörnig findet sich Architekturieren und Modellieren beim Codieren statt. Das ist nicht zu vermeiden. Es gibt keinen Zeitpunkt, da Architektur komplett abgeschlossen ist und nur noch stumpf in Codezeilen übersetzt wird. Und wenn das so wäre, dann müsste das wohl kein Mensch mehr tun. Selbst die Entscheidung zwischen:

var y = (c+d) * x ^ 2 + (c+d) * x;

und

var a = c+d;

var y = a * x ^ 2 + a * x;

ist ja eine Architekturentscheidung z.B. im Hinblick auf Performance oder Lesbarkeit oder Evolvierbarkeit.

Dass Architektur und Modellierung während der Codierung überhaupt stattfinden, lässt sich also nicht vermeiden.

Aber ich glaube, die Menge der Architektur- und Modellierungsentscheidugen während der Codierung sollte reduziert werden. Erstens ist der Codieret damit schnell überfordert. Zweitens vermischen sich diese beiden Aspekte sehr schnell. Anschließend lassen sich Architektur und Modell nur schwer aus dem Code ablesen.

Grobkörnige Architektur und Modellierung sollten deshalb im Rahmen einer expliziten Entwurfsphase dem Codieren vorangehen:

1. Entwurf

1.1. Grob (Skizzieren)

1.2. Fein (Codieren)

2. Bauen (Kompilieren)

(Für den Grobentwurf weiß ich eigentl noch keinen Namen. Aber vielleicht ist "Skizzieren" nicht ganz schlecht. Darin würde stecken "grober Strich", "keine Details", "zügig", "Visualität".)

Nun wäre noch zu klären, was denn eigentlich die Strukturelemente und Beziehungen in grob/fein Architektur/Modell sind. Aber das vielleicht ein andermal :-)

--

One Man Think Tank

Ralf Westphal

Hans-Henny-Jahnn-Weg 44

22085 Hamburg

Germany

+49 170-3200458

@ralfw

gplus.to/ralfwestphal

ralfw.blogspot.com

Gesendet mit Sparrow

[chrkon]

Hallo Dennis, Hallo Ralf,
das sind interessante Ansätze.

Denis, Du schreibst :

"Software-Design wäre damit der Entwurf eines Software-Systems durch
systematische Auswahl und Kombination von Lösungsmöglichkeiten anhand
von nicht-funktionalen Anforderungen für dieses Software-System."

"Vielleicht ist hier auch die Analogie zur Software-Entwicklung zu

finden: Software-Design wäre dann dazu da, die funktionalen

Anforderungen an ein System durch nicht-funktionale Merkmale zu
unterstützen oder herauszustreichen."

Ralf, du definiert es so:

"Wenn wir Strukturen für nicht-funktionale Anforderungen entwerfen,
dann "architekturieren" wir sie, dann sind wir Architekten. Und wenn
wir Strukturen für funktionale Anforderungen entwerfen, dann
modellieren wir sie, dann sind wir Modellierer."

Wenn ich nun diese beiden Aussagen gegenüberstelle, habe ich das
Gefühl, dass sich beide widersprechen.

Ich selber tendiere eher dazu, das Design als funktionale Anforderung
zu sehen. Ich stelle mir vor, dass der Workflow und die dazugehöhrige
GUI anhand der erforderlichen Funktionalität gestaltet wird. Das ist
die wirklich kreative Tätigkeit, weil in diesem Bereich etwas neues
entsteht. Das würde ich daher auch "Design" nennen. "Modellieren" geht
auch, weil darin der Anteil der Kreativität auch gut raus kommt.
Allerdings empfinde ich den Begriff "modellieren" als zu künstlich.
"Design" passt besser.

Die nicht-funktionalen Anforderungen (Sicherheit,
Geschwindigkeit, ...) sind Elemente, die eher aus einer "Best
Practice" Erfahrung kommen und kaum oder keine erneute Kreativität
erfordern. Diese Elemente müssen "nur" noch in das Gesammtsystem
integriert werden. Das würde ich, wie Ralf, auch als "Architektur"
bezeichnen.

Die Frage ist nun, ob wir alle unter den funktionalen Anforderungen
das gleiche verstehen? Ich glaube nein!

Ich verstehe Denis so, dass er die Oberfläche (die Gestalt) von der
Funktion trennt. Das heißt die funktionalen Anforderungen sind nicht
im Bereich der GUI oder des Workflows. Vereinfacht gesagt, die
Software muss richtig rechnen. Die Oberfläche ist nicht funktional,
sondern wird als unterstützendes Element gesehen. Verstehe ich Dich so
richtig?

Wie oben beschrieben, gehört für mich aber auch die GUI und der
Workflow zu den funktionalen Anforderungen. Es geht eben nicht nur
darum, dass die Software richtig rechnet, sondern auch darum, dass dem
Benutzer die Bedienung leicht gemacht wird. In so fern unterscheidet
sich Software deutlich von z.B. Uhren, bei denen das Design nicht zur
Funktionalität beiträgt.

Als Beispiel möchte ich die Taschenrechner anführen. Es gibt Geräte,
in die man einfach die Formel "(2+3)*6" eintippen kann und wenn man
auf "=" drückt erhällt man das Ergebnis (30). Diese Geräte kennt
jeder. Weniger bekannt sind die Rechner, die mit der UPN (umgekehrt
polnische Notation) arbeiten. Diese berechnen die Formel stackbasiert.
Dazu muss der Benutzer die Daten folgendermaßen eingeben:
6<Enter>
3<Enter>
2<Enter>
+<Enter>
*<Enter>
Wenn man damit umgehen kann, ist man mit dem UPN Rechner schneller.

Beide Wege sind also möglich und beide Systeme rechnen richtig. Sogar
die Gestalt beider Rechner unterscheidet sich kaum. Dennoch würde ich
bei beiden Systemen von unterschiedlichen funktionalen Anforderungen
sprechen. Das Design muss also die Bedienweise berücksichtigen.

An einer anderen Stelle schreibst Du (Denis):
"Wenn eine Applikation z.B. die funktionale Anforderung hat, Daten zu

persistieren, wäre es erst mal funktional egal, wie das realsiert wird
- durch eine relationale Datenbank oder eine NoSQL-Datenbank.
Es ist eine Design-Entwscheidung sich für das eine oder das andere zu
entscheiden. Die Entscheidung wird natürlich anhand nicht-funktionaler
Anfoderungen gefällt und kann auch falsch oder unpassend sein. Das
wäre dann Design und es kann gut oder schlecht sein. "

Jain! Es ist zwar eine Design-Entscheidung, aber wenn die Anforderung
"Daten persistieren" existiert, dann ist es die Aufgabe des Designers
die Daten zu definieren, die persistiert werden müssen. Die
Entscheidung "Datenbank, nein, ja, welche" gehört zu den den nicht
funktionalen Anforderungen und sollte daher vom Architekten getroffen
werden. Denn erst wenn ich einen Überblick über das Gesamtsystem habe,
kann ich eventuell Aufgaben mit Standardbausteinen zusammenfassen.

Ich würde den Entwicklungsablauf also so sehen :

1) Umsetzung der Funktionalen Anforderungen
= kreative Phase = Design = Entwurf/Skizze?

2) Einbau von nicht funktionalen Anforderungen
(auf Basis der Ergebisse aus 1)
= Architektur Phase = Konstruktion = Modell

3) Erstellen der Software
= Quelltext Phase = Codierung

Und damit sehe ich das Design oberhalb der Architektur. Die
Architektur bzw. Konstruktion setzt die Design Ideen um. Das Design
stellt das kreative, die Architektur das handwerkliche /
ingenieurmäßige Arbeiten in den Vordergrund.

Viele Grüße,
Christof

[Ralf Westphal]

Am 13. Dezember 2011 11:15 schrieb chrkon <konstant...@glm-laser.com>:

Wenn ich nun diese beiden Aussagen gegenüberstelle, habe ich das
Gefühl, dass sich beide widersprechen.

Ja, tun sie :-)

 

Ich selber tendiere eher dazu, das Design als funktionale Anforderung
zu sehen. Ich stelle mir vor, dass der Workflow und die dazugehöhrige
GUI anhand der erforderlichen Funktionalität gestaltet wird.

Wovon wir uns verabschieden sollten ist die Assoziation von "Oberfläche" und "Design" in dieser Diskussion.

Auch Oberflächen müssen entworfen werden. Klar. Dabei sind Usabiltiy oder "Schönheit" aber nur einzelne Aspekte von vielen.

"Design als funktionale Anforderung"? Puh... damit kann ich grad nix anfangen.

Vielleicht sollten wir deshalb den deutschen Begriff nehmen: Entwurf. "Entwurf als funktionale Anforderung"? Ne, das haut gar nicht hin.

Entwerfen ist eine Tätigkeit des Entwicklers. Daran ist der Kunde nicht interessiert. Und schon gar nicht hat der Entwurf mit Funktionalität zu tun.

Auch verstehe ich nicht, warum wir einen so allgemeinen Begriff wie Entwurf/entwerfen (design/to design) gleich so mit Konkretem beschweren sollten.

 

Das ist
die wirklich kreative Tätigkeit, weil in diesem Bereich etwas neues
entsteht. Das würde ich daher auch "Design" nennen.

Genau: alles zweckorientierte Strukturieren ist kreativ. Wir nennen es deshalb am besten Entwerfen.

Das hat erstmal nichts mit UI oder Funktionalität oder Nicht-Funktionalität zu tun.

Es ist ganz allgemein.

 

"Modellieren" geht
auch, weil darin der Anteil der Kreativität auch gut raus kommt.
Allerdings empfinde ich den Begriff  "modellieren" als zu künstlich.
"Design" passt besser.

Wenn wir zwei Begriffe haben, dann sollten die am besten nicht dasselbe bedeuten (Synonym).

Deshalb schlage ich eben vor, den allgemeinen Begriff Entwurf zu unterteilen:

Entwurf zerfällt in nicht-funktionalen Entwurf (Architektur) und funktionalen Entwurf (Modell).

Die Begriff Architektur und Modell sind im Grunde beliebig. Wir könnten auch Frump und Schlunz sagen.

Architektur ist für Nicht-Funktionalität aber durchaus eingeführt.

Und Modell ist noch relativ unbesetzt außerhalb der formaleren Informatik.

Ich finde Architektur und Modell besser als "Nicht-funktionaler Entwurf" und "Funktionaler Entwurf".

Dass wir beide Arten von Entwurf haben, sollte unzweifelhaft sein.

Wie gesagt: Ob wir sortieren oder nicht ist eine andere Entscheidung als die, welcher Algorithmus dafür verwendet werden sollte.

Wir sollten Namen haben für beide Entscheidungskategorien.

 

Die nicht-funktionalen Anforderungen (Sicherheit,
Geschwindigkeit, ...) sind Elemente, die eher aus einer "Best
Practice" Erfahrung kommen

Warum sollten vor allem Architekturentscheidungen aus Best Practices stammen?

Und Architektur ist nicht kreativ? Puh... wenn du dich da mal nicht verschätzt ;-)

 

Wenn man damit umgehen kann, ist man mit dem UPN Rechner schneller.

UPN oder Infix: ja, das hat mit Funktionalität zu tun.

Wie die Berechnung auf die eine oder andere Weise geleistet werden kann, muss modelliert werden.

Ob dabei aber ein Cache zum Einsatz kommt oder die besser im Hintergrund stattfindet oder ob die Eingabe in ein Textfeld stattfinden sollte... das hat mit Architektur zu tun.

Die Anordnung von Oberflächenelementen in Bezug auf Usability ist mithin ein architektonischer Aspekt von Software. Bei jedem Gebäude würden wir das auch so sehen. Warum nicht bei Software?

 

Jain! Es ist zwar eine Design-Entscheidung, aber wenn die Anforderung
"Daten persistieren" existiert, dann ist es die Aufgabe des Designers
die Daten zu definieren, die persistiert werden müssen.

Die Lösungsfindung ist - nach meiner Definition ;-) - immer eine Aufgabe für einen Designer/Entwerfer.

Aber die Auswahl der zu persistierenden Daten obliegt wohl eher dem Kunden. Der will ja, dass das eine gespeichert wird und das andere nicht.

Was hilft es aber, vom Designer zu sprechen? Alles ist ja Design.

Wenn ich aber sage: "Mit der Persistenz beschäftigt sich erstmal der Architekt." dann ist viel mehr klar. Nämlich, dass es sich um einen nicht-funktionalen Aspekt handelt. Das schränkt die Heuristiken ein, die wir benutzen, um das Problem anzugehen.

 

Die
Entscheidung "Datenbank, nein, ja, welche" gehört zu den den nicht
funktionalen Anforderungen und sollte daher vom Architekten getroffen
werden. Denn erst wenn ich einen Überblick über das Gesamtsystem habe,
kann ich eventuell Aufgaben mit Standardbausteinen zusammenfassen.

Es geht nicht um Überblick oder nicht, sondern um die Art von Anforderung, die erfüllt werden muss.

[Denis]

Hallo Christof, Ralf,

> Wovon wir uns verabschieden sollten ist die Assoziation von "Oberfläche"
> und "Design" in dieser Diskussion.

Da folge ich Ralf voll! Bei mir ist das Gestalten von Oberflächen im
Sinne von Applikations-GUI-Design ganz außen vor. Im Umfeld von
Bibliotheksentwicklung beschäftige ich mich gar nicht damit (und ich
denke auch, man sollte dies "echten" Designern und nicht Software-
Entwicklern überlassen).

Deine Unterscheidung, Ralf, des Entwurfs in funktionalen und nicht-
funktionalen Entwurf kann ich sehr gut folgen. Was mir aber auch schon
beim Lesen Deines Blog-Artikels aufgestoßen ist, ist die Beschränkung
der Architektur auf die Abbildung nicht-funktionaler Anforderungen.
Zumal Du bei Belangen/Concerns auf der untersten Abstraktionsebene
Deiner Architektur-Zerlegung durchaus auch funktionale Aspekte siehst.
Das legt auch Deine Unterteilung nahe:

> Entwurf zerfällt in nicht-funktionalen Entwurf (Architektur) und funktionalen Entwurf (Modell).

Wobei ich aber nicht Deinen Artikel im ganzen in Frage stellen möchte
- ich finde die verschiedenen Abstraktionsebenen einer Architektur
exzellent (wie immer :-)) herausgearbeitet. Nur die Beschränkung des
Begriffs "Architektur" auf nicht-funktionale Aspekte stelle ich zur
Diskussion.

Aber warum sollte die Architektur nur die nicht-funktionalen Aspekte
enthalten? Sehe ich mir Architektur-Zeichungen, z.B. Flow-Diagramme
an, entdecke ich darin immer funktionale und nicht-funktionale
Aspekte. Ich denke in solchen Diagrammen kann man sie nicht
voneinander trennen.
Deshalb schlage ich vor Architektur anders zu definiere (auch in
Abweichung meiner anfänglichen These in meinem ersten Post):

Die Archtiketur eines Software-Systems, also dessen Struktur, ergibt
sich durch Modellieren aus den funktionalen Anforderungen und aufgrund
von Design-Entscheidungen aus den nicht-funktionalen Anforderungen.
Software-Architektur ist die Synthese aus Software-Modell und Software-
Design.

Damit liese sich sowohl mein Versuch der Definition von Design, als
Auswahl einer Lösung für nicht-funktionale Anforderungen aus einem
Lösungsraum, in Übereinstimmung bringen, als auch das Modellieren als
Umsetzung der funktionalen Anforderungen integrieren.

Für mich passt jetzt auch der Begriff "Architekt" in meine
Denklandschaft und erfüllt auch das intuitive Verständnis einer
solchen Rolle in einem Team:
Er entwirft das Strukturmodell des Software-Systems anhand
funktionaler Anforderung und trifft Entscheidungen bzgl. des Struktur
des Software-Systems anhand nicht-funktionaler Anforderungen. Die
Architektur des Software-System ist seine Synthese aus Modell und
Design und Ergebnis seiner Arbeit.

Ein Modell kann aus meiner Sicht immer nur adäquat oder inadäquat
bzgl. der gestellten funktionalen Anforderungen sein. Ein Design kann
jedoch gut oder schlecht sein, gemessen an den nicht-funktionalen
Anforderungen. Dementsprechend ist ein Architekt gut, wenn er die
funktionalen Anforderungen adäquat umsetzt, d.h. alle funktionalen
Belange berücksichtigt (z.B.: die Applikation muss Daten persistieren
können oder, eine Sortierun von Einträgen wir benötigt) und nicht-
funktionalen Anforderungen möglichst optimal berücksichtig (z.B.
schnelle Verfügbarkeit ist wichtiger als Konsistenz - es wird mit
NoSQL persistiert oder, eine Implementierung mit Quick-Sort reicht
aus, da nie mehr als 5 Eiträge sortiert werden müssen).

Damit hätten wir eine "Dreifaltigkeit": Architektur ist die Synthese
aus Modell und Design.
Ich denke, intuitiv ist dies auch das was die meistens unserer
Kollegen unter Architektur verstehen würden - eine umfassende
Beschreibung der Struktur eines Systems, dass alle Anforderungen
reflektiert, funktionale und nicht-funktionale.

Damit wäre wir auch dem allgemeinen Architektur-Begriff aus dem
Häuserbau sehr nah gekommen. Wenn ich über die Architektur eines
philharmonischen Gebäudes sprechen, betrachte ich sowohl wie die
funktionalen Anforderungen an das Gebäude (Platz für's Orchster,
Sitzplätze für die Zuhörer, ausreichend Ein- und Ausgänge für alle)
umgesetzt und ob die nicht-funktionalen Anforderungen berücksichtigt
wurden (akustische Qualität des Baus, Stil des Gebäudes, Anzahl der
Ein- und Ausgang relativ zu ihrer Größe usw.). Erst alles zusammen
ergibt die Architektur der Philharmonie.

Denis

On 13 Dez., 11:59, Ralf Westphal <ra...@ralfw.de> wrote:

[Ralf Westphal]

Am 14. Dezember 2011 09:54 schrieb Denis <kun...@grammarcraft.de>:

Deine Unterscheidung, Ralf, des Entwurfs in funktionalen und nicht-
funktionalen Entwurf kann ich sehr gut folgen.

Na, das ist doch etwas Festhaltenswertes :-)

 

Was mir aber auch schon
beim Lesen Deines Blog-Artikels aufgestoßen ist, ist die Beschränkung
der Architektur auf die Abbildung nicht-funktionaler Anforderungen.

Warum nicht? Das ist halt meine Definition, bei der ich - so mein Eindruck - durchaus dem "Mainstream" folge.

Anders als beim Mainstream unterscheide ich dann aber ausdrücklich zwischen Entwurf und Architektur.

Entwurf ist für mich der Oberbegriff. Im Mainstream ist Entwurf (Design) hingegen unspezifisch in Gebrauch.

Entwurf/Design

  Architektur

  Modell

Ich finde das sehr nützlich. Nun kann ich an einen Entwickler herantreten und fragen: "Was machst du?"

Und er kann antworten:

"Ich codiere." - dann weiß ich, dass er einen Entwurf "runterprogrammiert". Er trifft dabei höchstens Architektur/Modell-Entscheidungen auf Mikroebene. Im Wesentlichen geht es aber darum, einen schon existierenden Entwurf eben in Code zu gießen.

"Ich entwerfe." - dann weiß ich dass er nicht codiert, sondern Vorüberlegungen anstellt in Bezug auf die Programmstruktur. Er kann sich mit der Architektur oder dem Modell beschäftigen.

"Ich sitze an der Architektur" - dann weiß ich, dass er sich (auf Makro- oder Mikroebene) mit nicht-funktionalen Anforderungen auseinandersetzt und dafür eine Struktur finden will.

"Ich modelliere"- dann weiß ich, dass er (auf Makro- oder Mikroebene) für funktionale Anforderungen eine Struktur finden will.

Wir könnten uns nun darüber unterhalten, ob die Hierarchie so

Entwurf

  Architektur

  Modell

aussieht oder so

Architektur

  Entwurf

  Modell

Warum ist für die erste Version bin, habe ich erklärt: Sie scheint mir erstens mehr in Linie mit dem üblichen Sprachgebrauch. Und zweitens ist für mich der Begriff "Entwurf" allgemeiner als der Begriff "Architektur". Deshalb gehört er auf die höhere Ebene.

 

Zumal Du bei Belangen/Concerns auf der untersten Abstraktionsebene
Deiner Architektur-Zerlegung durchaus auch funktionale Aspekte siehst.

Ja, welche?

 

Aber warum sollte die Architektur nur die nicht-funktionalen Aspekte
enthalten?

Ganz einfach: für eine saubere Definition :-)

 

Sehe ich mir Architektur-Zeichungen, z.B. Flow-Diagramme

Na, na, das ist aber eine Erschleichung des eigentlich erst zu Beweisenden :-)

Du setzt schon voraus, dass ein Flow-Diagramm eine Architekturzeichnung ist.

Anders herum wird aber ein Schuh draus: Erst die Definition, dann die Attribution.

Meine Definition für Architektur ist: beschäftigt sich mit nicht-funktionalen Anforderungen.

Nun der Blick auf ein Flow-Diagramm. Was für eins? Ein Flow-Chart oder ein Flow-Design Diagramm?

Einerlei. In beiden geht es darum, wie die Software funktioniert. Was passiert zuerst, was dann usw.

Es geht also ganz klar um Funktionalität. Aus einem Flow-Diagramm kannst du ablesen, was zu tun ist, um einen Effekt zu erzielen.

Dem tut kein Abbruch, dass im selben Diagramm "Speichere Daten" und "Berechne Ergebnisse" zu finden ist. "Speichern" hat irgendwie mit Architektur zu tun, "Berechnen" mit der Domäne/Funktionalität. Aus einem Flow-Diagramm wird deshalb nicht ein Architektur-Diagramm; es bleibt ein Modell. Es zeigt weiterhin, wie dat Janze eben funktioniert.

Allerdings gehören dazu architekturelle Aspekte. Hier ein Cache im Flow, dort ein Asychronizer... Der Architekt hat eben entschieden, dass (!) sowas nötig ist. Sein Strukturbild enthält nicht weiter detaillierte Flüsse, die in einen Cache laufen. Sein Strukturbild enthält nicht weiter detaillierte "Worker", die auf einem eigenen Thread laufen. Sein Bild enthält Betriebssystemprozesse und Maschinen.

Es geht eben um den Fokus. Was ist der Fokus eines Diagramms? Und der eines Flow-Design Diagramms sind die funktionalen Anforderungen im Rahmen (!) eines nicht-funktionalen Rahmens.

Oder genauer: Ein Flow-Design Diagramm ist ein Modell, wenn darin vor allem domänenbezogene Funktionalität zu finden ist. Wenn ich in Flow-Design Notation hingegen Softwarezellen verbinde, dann ist das ein Architekturdiagramm. Nicht die Notation ist also entscheidend, sondern der Inhalt.

 

Die Archtiketur eines Software-Systems, also dessen Struktur, ergibt
sich durch Modellieren aus den funktionalen Anforderungen und aufgrund
von Design-Entscheidungen aus den nicht-funktionalen Anforderungen.
Software-Architektur ist die Synthese aus Software-Modell und Software-
Design.

Damit verschiebst du die Bedeutung ja nur gegenüber meiner Definition.

Für dich gilt Entwurf/Design=nicht-funktional, Modell=funktional, Architektur=Entwurf+Modell.

Aus genannten Gründen finde ich den Gebrauch der Begriffe in dieser Weise suboptimal.

 

Er entwirft das Strukturmodell des Software-Systems anhand
funktionaler Anforderung und trifft Entscheidungen bzgl. des Struktur

Das widerspricht meiner Erfahrung des Anspruchs, den Architekten an sich haben.

Sie interessieren sich eben nicht (!) für funktionale Anforderungen.

Architekten wollen über Technologien reden, sie wollen ein big picture malen ("Ha, wir brauchen ein Plug-In Framework!" oder "Die Persistenz muss mit einer NoSql DB gemacht werden!" oder "Für die Kommunikation müssen wir SQS einsetzen!").

 

des Software-Systems anhand nicht-funktionaler Anforderungen. Die
Architektur des Software-System ist seine Synthese aus Modell und
Design und Ergebnis seiner Arbeit.

Ein Architektur entwirft eine Struktur für funktionale Anforderungen aufgrund von nicht-funktionalen Anforderungen? Hm... Ja, klar. Nichts anderes habe ich behauptet. Der Architekt definiert den groben Rahmen. Selbstverständlich. Ausgangspunkt sind aber eben die nicht-funktionalen (!) Anforderungen. Die sind sein Fokus. Er stellt Performance, Skalierbarkeit, Sicherheit, Usability, Ausfalltoleranz usw. her. Und das hat alles nichts mit einzelner Funktionalität zu tun, sondern ist deren Bett.

Ein Modell kann aus meiner Sicht immer nur adäquat oder inadäquat
bzgl. der gestellten funktionalen Anforderungen sein.

Ein Design kann
jedoch gut oder schlecht sein, gemessen an den nicht-funktionalen
Anforderungen.

Diesen Unterschied sehe ich nicht.

Die Struktur für die nicht-funktionalen wie eine für die funktionalen Anforderungen hat eine Qualität.

Anforderungen können mehr oder weniger erfüllt sein.

Wenn eine Antwortzeit von 1 sec gefordert ist, dann sind 1,5 sec besser als 3 sec - auch wenn die Anforderung noch nicht komplett erfüllt ist.

Wenn ein Rechtschreibkontrolle gefordert ist, dann ist eine Erkennung von Fehlern bei Substantiven und Adjektiven besser als eine Erkennung von Fehlern nur bei Adjektiven - auch wenn die Anforderungen noch nicht komplett erfüllt sind.

Das binäre "funktioniert oder funktioniert nicht" kannst du ansonsten auch auf nicht-funktionale Anforderungen anwenden: "Entweder die Antwortzeit ist 1 sec oder nicht."

Aber das ist wenig sinnvoll. Damit wird nämlich die Tür versperrt, Anforderungen unvollständig zu realisieren, weil schon 50% oder 80% gut genug sind. Es befördert eine Denke, die sich nur komplette Realisierungen vorstellen kann.

 

Ich denke, intuitiv ist dies auch das was die meistens unserer
Kollegen unter Architektur verstehen würden - eine umfassende
Beschreibung der Struktur eines Systems, dass alle Anforderungen
reflektiert, funktionale und nicht-funktionale.

Ich glaube nicht, dass es solche eine Sichtweise breit gibt, dass Architektur irgendwie "alles" ist.

Bei Architektur werden die meisten ein Schichtenmodell aus der Schublade ziehen oder vielleicht noch das M*-Pattern ihrer Wahl - und sonst kaum mehr. Das würdest aber auch du nicht als "umfassende Beschreibung" verstehen, oder?

Von Modell haben die meisten keine Vorstellung. Also käme auf die Frage "Was ist denn dein Modell für das Feature X?" keine Antwort. Oder ein Klassendiagramm, das irgendwie alles enthält und also nix bringt.

 

Damit wäre wir auch dem allgemeinen Architektur-Begriff aus dem
Häuserbau sehr nah gekommen. Wenn ich über die Architektur eines
philharmonischen Gebäudes sprechen, betrachte ich sowohl wie die
funktionalen Anforderungen an das Gebäude (Platz für's Orchster,
Sitzplätze für die Zuhörer, ausreichend Ein- und Ausgänge für alle)
umgesetzt und ob die nicht-funktionalen Anforderungen berücksichtigt
wurden (akustische Qualität des Baus, Stil des Gebäudes, Anzahl der
Ein- und Ausgang relativ zu ihrer Größe usw.). Erst alles zusammen
ergibt die Architektur der Philharmonie.

Interessante Frage: Was sind die funktionalen Anforderungen an ein Konzerthaus?

Im Kern steht sicherlich: Menschen zu einer Musikerfahrung verhelfen. Musiker und Zuhörer müssen zusammengebracht werden. Die Musik muss vom Orchester zum Publikum fließen :-)

Darüber hinaus müssen Musiker sich vorbereiten können.

Und das Publikum will in der Pause eine Erfrischung.

All das findet im Rahmen einer Architektur statt. Klar. Aber es ist eben getrennt zu sehen.

Die Analogie ist allerdings nicht so gut, weil die Funktionalität etwas sehr Statisches in diesem Fall ist.

Bei Software geht es um Domänenprozesse. Da gibt es also eine viel deutlichere Unterscheidung zw Architektur und Modell.

 

[Denis]

Ralf, Du schriebst

>> [Der Architekt] entwirft das Strukturmodell des Software-Systems anhand

>> funktionaler Anforderung und trifft Entscheidungen bzgl. des Struktur
> Das widerspricht meiner Erfahrung des Anspruchs, den Architekten an sich haben.
> Sie interessieren sich eben nicht (!) für funktionale Anforderungen.
> Architekten wollen über Technologien reden, sie wollen ein big picture
> malen ("Ha, wir brauchen ein Plug-In Framework!" oder "Die Persistenz muss
> mit einer NoSql DB gemacht werden!" oder "Für die Kommunikation müssen wir SQS einsetzen!").

Ich denke, deswegen werden wir bzgl. der Architektur-Definition nicht
zusammenkommen. Meine Erfahrung ist genau die, dass Leute in der Rolle
des Architekten eben nicht nur die nicht-funktionalen Anforderungen in
einer Architektur verarbeiten, sondern auch die funktionalen. In
meiner Erfahrung modellieren sie auch! Wie soll man denn nicht-
funktionale Anforderungen bewerten und umsetzen, ohne das Modell zu
beachten und zu kennen? Meine Erfahrung ist, dass die Umsetzung der
funktionalen und nicht-funktionalen Anforderungen auf jeweils einer
Abstraktionsebene der Architektur durch eine Person erfolgt.
Ich will nicht Abrede stellen, dass mein Erfahrungshorizont hier
möglicherweise beschränkt ist, den ich gehe davon aus, dass Du als
Berater viel mehr (in unterschiedlichsten Organisationen) herum
kommst. Aber ich kann natürlich meine eigene Erfahrung nicht negieren.

Frage ans mitlesende Auditorium: Was sagen die Erfahrungen der
anderen? Gibt es bei Euch Architekten(-rollen), die nur die nicht-
funktionalen Anforderungen bewerten und in Architektur umsetzen.
Passiert das vor oder nach der Modellierung des Systems aufgrund der
funktionalen Anforderungen? Falls es so was bei Euch gibt, welche
Rolle modelliert dann das System aufgrund der funktionalen
Anforderungen? Wie und wer integriert dann Architektur (nicht-
funktionale Struktur) und Modell (funktionale Struktur)?

>> Zumal Du bei Belangen/Concerns auf der untersten Abstraktionsebene
>> Deiner Architektur-Zerlegung durchaus auch funktionale Aspekte siehst.
>
> Ja, welche?

Aus Deinem Blog-Artikel (http://ralfw.blogspot.com/2010/12/was-ist-
softwarearchitektur-teil-2.html):
[[
Concerns

Die Zerlegung des Anwendungssystems bis in Prozesse führt zu autonomen
Funktionseinheiten. Die arbeiten jede für sich vor sich hin. Jede
läuft auf mindestens einem eigenen Thread. Die Kommunikation ist
mithin ganz fundamental nur asynchron zwischen ihnen möglich.

Diese autonomen Funktionseinheiten zu identifizieren, ist die
vornehmste Aufgabe des Architekten.
]]

Wenn der Architekt Funktionseinheiten identifizieren soll, kann er
dies doch nur aufgrund der funktionalen Anforderungen. Also spielen
die funktionalen Anforderungen doch eine Rollen bei der Architektur.
Ich denke Funktionalität spielt eben auf jeder Ebene der Architektur
(im Sinne Deiner Zerlegung) eine Rolle. Sie ist immanenter Bestandteil
der Architektur.
Weiter aus Deinem Blog:

[[
Anwendungssystem

[..]. Wenn implementiert, erfüllt das Anwendungssystem alle
Anforderungen.
]]
... doch auch die die funktionalen, oder?

[[
Bounded Contexts
Das Gesamtsystem zerlegt der Architekt in Bounded Contexts, d.h.
_funktionale_ Untermengen, die unterschiedliche Datenmodelle haben.
[...]
Apps
Innerhalb eines Bounded Context kann die _Funktionalität_ weiter
aufgeteilt werden auf Partitionen [...]
]]

Erst auf der Architektur-Ebene der Maschinen und Prozesse ist dort
nicht mehr die Rede von Funktionalität.

>> Sehe ich mir Architektur-Zeichungen, z.B. Flow-Diagramme
>
> Na, na, das ist aber eine Erschleichung des eigentlich erst zu Beweisenden
> :-)

... ertappt. ;-) OK. Sehe ich ein.

> Nun der Blick auf ein Flow-Diagramm. Was für eins? Ein Flow-Chart oder ein
> Flow-Design Diagramm?

Was ist ein Flow-Chart? Ich dachte, ich hätte Dein Blog zu FD recht
gut verfolgt. Der Begriff ist mir jedoch nicht gegenwärtig. Hättest Du
einen Link, für ein Beispiel oder eine Erläuterung? Danke im voraus!

>> Ein Modell kann aus meiner Sicht immer nur adäquat oder inadäquat
>> bzgl. der gestellten funktionalen Anforderungen sein.

> [...]

> Aber das ist wenig sinnvoll. Damit wird nämlich die Tür versperrt,
> Anforderungen unvollständig zu realisieren, weil schon 50% oder 80% gut
> genug sind. Es befördert eine Denke, die sich nur komplette Realisierungen
> vorstellen kann.

Natürlich können Anforderungen auch partiell realisiert werden (auch
im Sinne der Realsierung eines System in Features-Scheiben). Aber
partielle Anforderung ist nicht gleichbedeutend mit "partiellem
Modell". Ich bleibe dabei, ein Modell ist meiner Meinung nach entweder
adäquat oder inadäquat bzgl. des für einen Realisierung ausgewählten
Teils der funktionalen Anforderungen. Ein für ein Teil der
funktionalen Anforderungen adäquates Modell kann durch Hinzunahme von
anderen vorher noch nicht berücksichtigter funktionaler Anforderung
inadäquat werden.
Ähnliches sehe ich auch in Deiner aktuellen Artikel-Serie in der
dotnetpro über eine SimpleNote-Applikation für's IPhone. Als erstes
Feature hattest Du das einfache Auslesen, Ändern und Zurückschreiben
der Einkaufszettel in die Cloud realisiert. Dein Modell der
Darstellung von Einkaufszetteln war adäquat bzgl. der funktionalen
Anforderungen aus Feature 1. Sollen jedoch alle eingangs im Artikel
genannten funktionalen Anforderungen beachtet werden, wie z.B. Abhaken
eines Einkaufpunktes mit einer Hand durch drauftippen, wäre Deine für
das für Feature 1 gewähltes Modell der Darstellung nicht mehr adäquat.
Das hast Du ja auch extra betont, dass Feature 1 nur dazu diente zu
prüfen, ob die SimpleNote-Implementierung überhaupt mit MonoTouch
zusammenarbeiten und das ganze überhaupt von der Infrastruktur her
geht.

Denis

[chrkon]

Ich möchte noch mal auf den Punkt "Benutzeroberfläche" zurück kommen,
das ich glaube, dass ich da falsch verstanden worden bin. In meinem
Beispiel mit dem Taschenrechner ging es mir nicht um das Aussehen der
graphischen Oberfläche!

> > Wovon wir uns verabschieden sollten ist die Assoziation von "Oberfläche"
> > und "Design" in dieser Diskussion.
>
> Da folge ich Ralf voll! Bei mir ist das Gestalten von Oberflächen im
> Sinne von Applikations-GUI-Design ganz außen vor. Im Umfeld von
> Bibliotheksentwicklung beschäftige ich mich gar nicht damit (und ich
> denke auch, man sollte dies "echten" Designern und nicht Software-
> Entwicklern überlassen).

Bezogen auf das Aussehen der GUI gebe ich euch beiden Recht!
Das ist ein eigener Bereich, der in dieser Diskussion außen vor
bleiben kann.

Aber die Funktionalität die dem Benutzer bzw. Anwender zur Verfügung
gestellt wird, ist sehr wohl ein Thema. Auch bei der
Bibliotheksentwicklung gibt es eine "Benutzeroberfläche"! Nennen wir
sie in dem Zusammenhang besser "Anwenderschnittstelle", dann wir
klarer, was ich meine. Der Anwender der Softwarebibliothek muss die
Schnittstelle verstehen und nutzen können. Diese Schnittstelle, also
die vom Anwender aufrufbaren Methoden und Funktionen, müssen designed
werden. Das Benutzerkonzept für die Bibliothek muss entworfen werden.
Das sind meiner Meinung nach ganz klar funktionale Aspekte!

Viele Grüße
Christof

[Michael Hoennig]

Hallo Denis,

> > Das widerspricht meiner Erfahrung des Anspruchs, den Architekten an
> > sich haben. Sie interessieren sich eben nicht (!) für funktionale
> > Anforderungen.
>

> Ich denke, deswegen werden wir bzgl. der Architektur-Definition nicht
> zusammenkommen. Meine Erfahrung ist genau die, dass Leute in der Rolle
> des Architekten eben nicht nur die nicht-funktionalen Anforderungen in
> einer Architektur verarbeiten, sondern auch die funktionalen.

dann übernehmen die Architekten auch Modellierung, das kann in der
Praxis gerade in kleineren Projekten auch vorkommen. Dennoch sind
die Aufgaben zu unterscheiden (vor allem auch dann, wenn es gar keine
dedizierten "Architekten" gibt, gibt es dennoch diese Aufgaben):

- Architektur: für _nicht_ funktionale Eigenschaften
- Modellierung: für funktionale Eigenschaften

Selbstverständlich muss die Architektur in der Lage sein, die
funktionalen Eigenschaften in ihrer Umsetzung zu unterstützen. Das ist
aber etwas anderes, als sie selbst umzusetzen.

Häufig ist es daher auch Aufgabe der Architekten, die Modellierung auf
Architektur-Kompatiblität hin zu überwachen, das läuft aber auf einer
Meta-Ebene ab, und nicht auf der fachlichen (also der, die da modelliert
wird).

Interessant aber, dass ich weder bei Balzert (Lehrbuch der SW Technik)
noch bei Starke (Effekture Software-Architekturen) bei reiner Index-Suche
dazu eine Abgrenzung finden konnte.

Grüße
Michael

--
Michael Hönnig|Gerichtstr. 39|D-22765 Hamburg|http://michael.hoennig.de
sip:1528...@sipgate.de | fon:040-22815360-0 | fax:040-22815360-9
Business Networking: http://www.xing.com/profile/Michael_Hoennig
GPG KeyID EC5C271A --- 9DC0 53EC 1549 DA84 A939 15CC C0B7 8FBF EC5C 271A

[Ralf Westphal]

Dass es eine Funktionalität gibt, ist folge einer funktionalen Anforderung, z.B.

interface IRepository {
void Open(string filename);
void Write(string data);
void Close();
}

Mit dem API kann man Daten in eine Textdatei schreiben: funkt Anforderung.

Mit diesem API aber auch:

interface IRepository : IDisposable {
void Open(string filename);
void Write(string data);
}

und mit diesem:

interface IRepository {
void Write(string filename, string data);
}

Bei gleicher Funktionalität sehen die APIs anders aus. Die Form, die Oberfläche von Funktionalität hat also nur bedingt mit ihr zu tun. Da gibt es eine ganze Bandbreite. Welche Form sollte nun gewählt werden?

Diese Frage bezieht sich offensichtlich auf einen nicht-funktionalen Aspekt. Also ist sie eine architektonische Frage.

--
Ralf Westphal
www.ralfw.de

[Ralf Westphal]

Am 15. Dezember 2011 07:28 schrieb Michael Hoennig <mic...@hoennig.de>:

dann übernehmen die Architekten auch Modellierung, das kann in der
Praxis gerade in kleineren Projekten auch vorkommen. Dennoch sind
die Aufgaben zu unterscheiden (vor allem auch dann, wenn es gar keine
dedizierten "Architekten" gibt, gibt es dennoch diese Aufgaben):

Genau. Mir geht es nicht um Personen, sondern um Tätigkeiten, Brillen, Sichtweisen, Modi.

Wenn ich einen Weihnachtsbaum schmücke, dann gestalte ich und "arbeite" ich. Beim "Arbeiten" sehe ich zu, dass die Kerzen gerade in den Haltern stehen, Äste tragfähig sind, schneide den Stamm zu, damit er in den Ständer passt usw. Und beim Gestalten, da entscheide ich, wo welcher Baumschmuck hinkommt. Ich trete dann auch mal zurück, um das big picture zu sehen.

1 Person, zwei Modi.

Selbstverständlich muss die Architektur in der Lage sein, die

funktionalen Eigenschaften in ihrer Umsetzung zu unterstützen. Das ist
aber etwas anderes, als sie selbst umzusetzen.

Genau.

 

Häufig ist es daher auch Aufgabe der Architekten, die Modellierung auf
Architektur-Kompatiblität hin zu überwachen, das läuft aber auf einer
Meta-Ebene ab, und nicht auf der fachlichen (also der, die da modelliert
wird).

Natürlich hat der Architekt auch etwas mit Funktionalität zu tun - aber die ist nicht sein Fokus.

Als Weihnachtsbaumgestalter kann ich mich ja auch nicht über physischen Gegebenheiten des Baums hinwegsetzen. "Ach, wenn der Baum doch da und dort keine Lüche im Gäst hätte..."

Und natürlich hat der Modellierer etwas mit nicht-funktionalen Anforderungen zu tun - aber die sind nicht sein Fokus.

Als Weihnachtsbaumarbeiter sehe ich zwar die lokalen Gegebenheiten, kann deshalb ja aber nicht Äste beliebig stutzen.

Architektur dient der Funktionalität, Funktionalität bewegt sich im Rahmen der Architektur.

 

Interessant aber, dass ich weder bei Balzert (Lehrbuch der SW Technik)
noch bei Starke (Effekture Software-Architekturen) bei reiner Index-Suche
dazu eine Abgrenzung finden konnte.

Ich sag ja... :-) Wir haben in der Branche noch ein paar Unterspezifikationen.

Deshalb ist mir daran gelegen, über diese Begriffe Klarheit zu gewinnen.

Letztlich geht es auch hier um das Single Responsibility Prinzip.

Architektur und Modell sind zwei Responsibilities. Ihre Entwürfe können sich unabhängig von einander verändern.

Aber nochmal: das bedeutet nicht, dass Architektur und Modell von verschiedenen Personen stammen müssen. Im Gegenteil. Das Ideal ist, dass ein Team für sich die Architektur definiert und dann in deren Rahmen modelliert. Alle zusammen.

 

Grüße
       Michael

--
Michael Hönnig|Gerichtstr. 39|D-22765 Hamburg|http://michael.hoennig.de
sip:1528...@sipgate.de | fon:040-22815360-0 | fax:040-22815360-9
Business Networking: http://www.xing.com/profile/Michael_Hoennig
GPG KeyID EC5C271A --- 9DC0 53EC 1549 DA84 A939  15CC C0B7 8FBF EC5C 271A

--
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de

[Denis]

Ralf:

>>Bei gleicher Funktionalität sehen die APIs anders aus. Die Form, die Oberfläche von Funktionalität hat also nur bedingt mit ihr zu tun. Da gibt es eine ganze Bandbreite. Welche Form sollte nun gewählt werden? Diese Frage bezieht sich offensichtlich auf einen nicht-funktionalen Aspekt. Also ist sie eine architektonische Frage. <<

Ich würde eben lieber sagen, dies ist eine "Design"-Frage, eben wie
ich die API entwerfe. Welche von den drei Variante ich nehme, hängt
von nicht-funktionalen Anforderungen ab. -

Wir sind gar nicht so weit von einander entfernt! Ich würde mir eben
gern den Begriff "Architektur" freihalten, um damit das zu bezeichnen,
was aufgrund der funktionalen und nicht-funktionalen Anforderung
entsteht.
Die Gleichung "Architektur=Modell+Design" scheint mir näher an der
ausserhalb der Software-Entwicklung verwendeten Semantik der Begriffe
zu sein, als die Gleichung "Design=Modell+Architektur".

Aber wie gesagt, ich stelle das durchaus zur Diskussion und bin
bereit, mein "Weltbild" :-) zu korrigieren.
Deshalb noch mal die Aufforderung an die anderen, sich zu äussern. Bis
jetzt hat es ja nur Michael getan und Ralf's Version unterstützt.

@chrkon: Jetzt ist es klar! Und ich stimme Dir zu,
Bibliotheksschnittstellen sind eine Art Benutzeroberfläche, nur sind
die Benutzer eben Programmierer, also Kollegen. Aber würde man nicht
gerade da von gut oder schlecht designten Schnittstellen sprechen?
Niemand würde von der Architektur der Schnittstelle sprechen, oder?
Gerade hier spielen doch nicht-funktionale Anforderungen rein -- ob
ich z.B. eine Fluent-Interface entwerfe oder ein konventionelles
verbales oder Proprty-zentriertes Interface vorsehe, ist doch eher
_keine_ Frage der funktionalen Anforderungen.

Na denn, viel Spass beim Weihnachtsbaum schmücken!
Denis

On Dec 15, 9:28 am, Ralf Westphal <ra...@ralfw.de> wrote:

> > sip:152857...@sipgate.de | fon:040-22815360-0 | fax:040-22815360-9

> > Business Networking:http://www.xing.com/profile/Michael_Hoennig
> > GPG KeyID EC5C271A --- 9DC0 53EC 1549 DA84 A939  15CC C0B7 8FBF EC5C 271A
>
> --
> Ralf Westphal - One Man Think Tank
> Hans-Henny-Jahnn-Weg 44
> D-22085 Hamburg
> Germany
> Tel 0170-3200458

> Email i...@ralfw.de

[Ralf Westphal]

Am 17. Dezember 2011 18:29 schrieb Denis <kun...@grammarcraft.de>:

Die Gleichung "Architektur=Modell+Design" scheint mir näher an der
ausserhalb der Software-Entwicklung verwendeten Semantik der Begriffe
zu sein, als die Gleichung "Design=Modell+Architektur".

es geht um die frage, was ist allgemeingültiger.

wenn ich mir einen elektronischen schaltplan ansehe, dann kann ich dazu "entwurf" sagen.

beispiel: http://www.semibyte.de/dokuwiki/_media/nat/physik/schaltplan_durchgangspruefer.jpg

wenn ich mir einen bauplan für ein haus ansehen, dann kann ich dazu "entwurf" sagen.

beispiel: http://www.holz-solar-haus.de/hauseg.jpg

wenn ich mir eine skizze wie die nächste ansehen (ich bezeichne sie extra nicht näher :-), dann kann ich dazu "entwurf" sagen.

beispiel: http://www.holz-solar-haus.de/Vision2004.php

wenn ich mir das folgende beispiel ansehen, kann ich dazu "entwurf" sagen.

beispiel: http://www.cae-sim-sol.at/files/styles/large/public/konstruktion2.jpg

wenn ich mir das folgende beispiel ansehe, kann ich dazu "entwurf" sagen.

beispiel: http://images.zeno.org/Kunstwerke/I/big/76q018a.jpg

wenn ich mir das folgende beispiel ansehe, kann ich dazu "entwurf" sagen.

beispiel: http://www.nationalpark-eifel.de/data/aktuelles/Landschaftsarchitekturbuero_Hoff_1251464684.jpg

zu welchem dieser beispiele würde jmd auf der straße "architektur" sagen?

ich vermute: eher nur zu 2 von 6.

der begriff "entwurf" ist daher für mich der allgemeinere und gehört in die wurzel der begriffshierarchie.

die "architektur" ist eine spezielle art des "entwurfs" (in der softwareentwicklung). genauso das "modell".

dass architektur spezieller ist als entwurf, sollte nun ohne zweifel sein.

was architektur dann als spezieller entwurf ist, ist eine definitionssache. dito das modell.

dass die frage "wie ist die architektur deines API?" sich merkwürdig anhört, ist klar.

aber das liegt wohl eher daran, dass wir bisher impräzise mit dem begriff architektur umgegangen sind.

[Denis]

Ralf, in Deiner Benutzung des Wortes "Entwurf" folge ich Dir. Alle
Deine Beispiele zeigen Entwürfe. Aber zeigen sie auch Design?   
Irgendwie passt Design darauf nicht. Und gerade beim software-
relevanten Beispiel, den unterschiedlichen Schnittstellen passt
Architektur nicht, aber Design...

Ich glaube wir sollten Entwurf nicht mit Design gleichsetzen und beide
Begriffe nicht synonym verwenden. Entwurf ist eher die Darstellung
etwas abstrakten, was vielleicht auch noch nicht konkret vorhanden ist
oder noch nicht realsiert wurde, oder anders anders realisiert wurde
als ursprünglich gedacht. Design dagegen ist konkreter, bezeichnet
Eigenschaften eines Artefakts in seiner Anwendung.   Irgendwie
erscheint mir jetzt meine "Freihaltung" des Begriffes Architektur
gekünstelt. Die Gleichung "Entwurf=Modell+Architektur" ist passender
-- Architektur jetzt weitgehend nach Ralfs Definition. "Weitgehend"
deshalb, weil wir Design damit immer noch nicht verortet haben und ich
denke, dass es irgendwie noch in diese Gleichung mit hinein muss.

Was haltet ihr davon dem Hinweis von chrkon zu folgen und Sofware-
Design in Relation zu stellen zur Benutzung im Allgemeinen. Bei
Bibliotheksschnittstellen beträffe das unter anderem die Art der
Schnittstellengestaltung, formal - also ob fluent oder konventinell
z.B. - aber auch operativ - also wie z.B. der Lebenzyklus eines
Bibliotheksobjektes ist. Bei Applikationen liesse sich bei der
Benutzeroberfläche von Design sprechen (klar, das ist naheliegen),
aber z.B. auch bei der Art und Weise der Persistierung von Daten: Ob
eine Applikation Daten in de Cloud ablegen kann, oder nur lokal, ist
für den Benutzer durchaus von Bedeutung und er würde davon sprechen,
die Applikation sei dafür designt in der Cloud bentzt zu werden oder
eben nur lokal.   Damit wäre dann folgende Gleichung denkbar:
Entwurf=Modell+Architektur+Design. Wobei Modell für die Umsetzung der
funktionalen Anforderungen stehen würde. Architektur und Design für
die nicht-funktionalen.

Aber was unterscheidet dann Architektur von Design?
Architektur ist die strukturelle Umsetzung nicht-funktionaler
Anforderungen. Design wäre die benutzungsbezogene Umsetzung nicht-
funktionaler Anforderungen ergänzt um die benutzungsbezogenen Optionen
des Entwurfs. Letzteres würde es z.B. auch erlauben davon zu sprechen,
dass ein Entwurf einer Applikation für eine spezielle Plattform im
Design die Verwendung in der Cloud beinhaltet, auch wenn die konkrete
Architektur die Realisierung einer komplemetären Applikation auf einer
anderen Plattform nicht direkt addressiert und nur als Option
berücktsichtig. Ich denke da konkret an Ralfs Beispiel der SimpleNote-
Applikation in der dotnetpro: Ziel des Entwurfs ist die Realsierung
einer iPhone ab. Als Design-Entscheidung hat Ralf aber die Speicherung
in der Cloud über unbedingt notwendig, man könnte auch lokal
persistieren, aber es ist eine Design-Entscheidung als Option - die
Option später einmal eine Einkaufzettel App für den Desktop zu
entwickeln; oder es findet sich jemand anders, der es tut.

  Auf manchen Gebieten, wo die Struktur des Systems die Benutzung
tangiert überschneiden sich beide Aspekte auch. Ich denke hier bei
Bibliotheken z.B. an die Strukturierung des API (ein Interface als
Facade, oder viele kleine adjektivierte [im Sinne von Coparable]). Bei
Applikationen überschneiden sich Architektur und Design z.B. in der
Benutzeroberfläche (man denke an Gruppen von Ajax-Controls auf
Webseiten, an die Funktionalität gebunden ist - Struktur und Design
stehen dialektisch in Beziehung...)

  Meine Begriffsbildung für Design liesse sich auch auf (innere)
Schnittstellen in Applikationen anwenden, die gar nicht nach aussen
sichbar werden (dem Endanwender). Nachdem der Architekt die autonomen
Funktionseinheiten identifiziert und strukturiert hat, gestaltet er
sie z.B. in durch Defintion von Schnittstellen-Signaturen
(Interfaces). Wie diese gestaltet sind, als z.B. als fluent oder
konventionelles Interface, wäre doch Design! Die Benutzungsrelation
wäre hier: Der Architekt designt, die umsetzenden Programmierer
benutzen. Das Design kann jetzt verschiedene Aspekte der Benutzung
besser oder schlechter unterstützen. Ein fluentes Interface würde
Lesbarkeit und damit langfristig die Evolvierbarkeit der Software
besser unterstützen. Ein konventionelles Interface würde kurzfristig
vielleicht die Umsetzung beschleunigen, da die Programmierer
vielleicht noch nie was von fluenten Interfaces gehört haben und jetzt
gerade eine schnellstmögliche Realsierung notwendig ist, um die
Existenz der Organsiation zu sichern, anstelle in Weiterbildung für
fluente Intetfaces zu investieren. Alles eine Frage des Design...

Nicht der Architektur. Also Design als Umsetzung nicht-funktionaler
Anforderung im Rahmen von Anwendungs- und Benutzungsrelationen.
Architektur als Umsetzung nicht-funktionaler Anforderung bezüglich
einer Strukturierung eines Software-Systems.

  Denis

On Dec 17, 6:48 pm, Ralf Westphal <ra...@ralfw.de> wrote:
> Am 17. Dezember 2011 18:29 schrieb Denis <kun...@grammarcraft.de>:
>
> > Die Gleichung "Architektur=Modell+Design" scheint mir näher an der
> > ausserhalb der Software-Entwicklung verwendeten Semantik der Begriffe
> > zu sein, als die Gleichung "Design=Modell+Architektur".
>
> es geht um die frage, was ist allgemeingültiger.
>
> wenn ich mir einen elektronischen schaltplan ansehe, dann kann ich dazu
> "entwurf" sagen.

> beispiel:http://www.semibyte.de/dokuwiki/_media/nat/physik/schaltplan_durchgan...

>
> wenn ich mir einen bauplan für ein haus ansehen, dann kann ich dazu
> "entwurf" sagen.
> beispiel:http://www.holz-solar-haus.de/hauseg.jpg
>
> wenn ich mir eine skizze wie die nächste ansehen (ich bezeichne sie extra
> nicht näher :-), dann kann ich dazu "entwurf" sagen.
> beispiel:http://www.holz-solar-haus.de/Vision2004.php
>
> wenn ich mir das folgende beispiel ansehen, kann ich dazu "entwurf" sagen.
> beispiel:http://www.cae-sim-sol.at/files/styles/large/public/konstruktion2.jpg
>
> wenn ich mir das folgende beispiel ansehe, kann ich dazu "entwurf" sagen.
> beispiel:http://images.zeno.org/Kunstwerke/I/big/76q018a.jpg
>
> wenn ich mir das folgende beispiel ansehe, kann ich dazu "entwurf" sagen.

> beispiel:http://www.nationalpark-eifel.de/data/aktuelles/Landschaftsarchitektu...

[Ralf Westphal]

tut mir leid, der unterscheidung zwischen entwurf und design kann ich grad gar nicht folgen.

der grund ist ganz simpel: erkläre die doch bitte einem engländer.

"to design" ist "entwerfen". so steht es im wörterbuch.

so steht es auch bei wikipedia: http://de.wikipedia.org/wiki/Design

dass dann daraus im deutschen in unterschiedlichen kontexten etwas spezielleres geworden ist, ist misslich. den fehler sollten wir einfach nicht wieder begehen.

wenn wir von design bei kaffeekannen, autos oder auch UIs sprechen, dann ist das ja nett. wir meinen damit aber immer einen ausschnitt aus dem, was man entwerfen kann. und dieser ausschnitt bezieht sich auf "äußerlichkeiten". hohe qualität beim design ist für uns, wenn schönheit mit nützlichkeit zusammenkommt.

das ist ne tolle sache. wunderbar. lässt sich sogar auf software übertragen, sowohl beim GUI wie bei APIs.

nur gibt mir das nichts, wenn ich den softwareentwicklungsprozess beschreiben soll.

oder es gibt mir etwas - aber dann wieder nur auf der obersten ebene.

design auch im herkömmlichen sinn (schönheit+nützlichkeit) umfasst ja nicht-funktionales wie funktionales.

damit steht es auf einer stufe mit dem, was ich entwurf nenne. und dem, was auch ich design nennem weil entwerfen=to design.

ich finde es wenig hilfreich im sprachgebrauch sowas zu sagen wie "ziel des entwurfs von software ist ein gutes design." das scheint mir tautologisch. auch und gerade im landläufigen sinne von design.

wir müssen uns einfach von vielen jahren ungenauer verwendung des begriffs design befreien. der begriff ist ja ok - nur die bisherige schwammige bedeutung nicht. TDD kann weiterhin test-driven design heißen. nun wissen wir aber: mit TDD werden softwarestrukturen "ermittelt" in funktionalen und (!) nicht-funktionaler hinsicht. das hängt einfach davon ab, was man als test anlegt. TDD ist modellierung und (!) architektur im kleinen.

--
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458

Email in...@ralfw.de

[Denis]

Ja, an Deinen Argumenten ist was dran! Design im deutschen Sinne
unterscheidet sich vom Sinn im Englischen. Ich habe Design eigentlich
immer im deutschen Sinne benutzt, nie im englischen Sinne.

Aber ich denke von der Mehrdeutigkeit des Begriffs im Deutschen und
Englischen kommt wohl auch Unschärfe des Begriffs und amit auch die
teilweise unscharfe Verwendung.

Jetzt komme ich immer mehr zur Überzeugung -- Software-Design sollte
man nur im englischen Sinne benutzen, nicht im deutschen Sinne.
Wahrscheinlich sollte man im Deutschen lieber generell den Term
Software-Entwurf verwenden, um dies eindeutiger vom deutschen Begriff
im Sinne von "Äußerlichkeiten" abzugrenzen und Verwirrung aufgrund der
Mehrdeutikeit des Begriffs vorzubeugen.

Design im deutschen Sinne behält für mich seine Gültigkeit im Bezug
auf Äusserlichkeiten des Entwurfs wie API-Gestaltung und
Benutzeroberfläche. Aber für das Wesen des Software-Entwurfs und den
dahinter stehenden Prozess ist das wohl eher nicht ausschlaggebend.

Ralf und den anderen erst mal vielen Dank für den Diskurs! Zumindest
mir hat er doch Klarheit bezüglich des Wortes "Design" im Kontext der
Software-Entwicklung gebracht.

Denis

On Dec 18, 12:36 pm, Ralf Westphal <ra...@ralfw.de> wrote:
> tut mir leid, der unterscheidung zwischen entwurf und design kann ich grad

> gar nicht folgen,

> Email i...@ralfw.de