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
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
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
Wenn man damit umgehen kann, ist man mit dem UPN Rechner schneller.
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.
> 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:
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.
Aber warum sollte die Architektur nur die nicht-funktionalen Aspekte
enthalten?
Sehe ich mir Architektur-Zeichungen, z.B. Flow-Diagramme
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.
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.
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.
>> [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
> > 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
> > 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
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
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):
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
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
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".
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...
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