F
frager
Gast
hallo, ich hab mal eine frage dazu, was sa eigentlich genau ist und was der architekt während des entwurfs macht. ich versteh da das folgende drunter, was aber falsch zu sein schein (laut prüfungsergebniss :-():
sa=softwarearchitektur ;-)
eine sa beschreibt doch die wesentlichen komponenten eines softwaresytems und wie diese hierarchisch aufgebaut sind und zusammenarbeiten (über schnittstellen bzw. konnektoren etc). es geht also um schnittstellen und wann, wie warum durch wen etc diese schnittstellen genutzt werden. das ganze auf einen hohen abstraktionslevel. weiterhin werden doch die verschiedenen strukturen des softwaresystems (prozesstruktur etc) durch die sichten beleuchtet, so dass jeder stakeholder alle nötigen sichten für seinen teil der architektur hat. deswegen ist es auch wichtig, die sichten nicht voneinander entkoppelt zu sehen bzw. zu verstehen. natürlich gibt es dan eben wieder viele sichten und sichtenmodelle (4+1, zachmann, clements, siemens, rm-odp etc), die jeweils unterschiedliche aspekte der sa beleuchten. manche sind hierarchisch und manche nicht etc. seh ich das richtig, oder gibts da noch was zu ergänzen? die sichten kann man dann mittels eine adl wie uml, rapid, acme, wright etc notieren und mit schaubildern oder szenen und so weiter ergänzen. diese dokumentierten sichten dienen dann doch zum beispiel diesen punkten:
- allgemeine kummunikationsgrundlage aller stakeholder
- planung von teams, projektgruppen, arbeitsweise
- minderung der komplexität, da jeder nur das sieht, was er braucht
- einordnung des eigenen teils in das gesamtpojekt
und so weiter (für ergänzungen bin ich dankbar ;-))
später hängen doch von diesem entwurf der sa dinge wie performance, wartbarkeit, wiederverwendung etc ab, oder was? weiterhin hängt doch der entwurf einer sa nicht von der funktionalität ab, richtig? das heisst also, es geht um das beachten der nicht funktionalen anforderungen an das system, welche mir unter den namen organisatorische und technische einflussfaktoren (portiebarkeit, zeitrahmen, finanzrahmen etc) bekannt sind. man extrahiert aus denen die risiken und entwickelt eine architektur, welche genau diese risiken beachtet und dementsrepchend aufgebaut ist, korrekt? das wird ja oftmals vernachlässigt und unternehmen betrachten im projekt nur die funktionalen und wundern sich dann, warums 10x soviel kostet und 3 mal so lang gedauert hat.
vergleicht man also z.b. 2 systeme gleicher funktionalität, aber mit jeweils anderen nicht funktionalen anforderungen, so sollten sie eigentlich NICHT die selbe sa haben, da ja der entwurf der sa nicht durch die funktionalität (welche ja unterschieldich ist) bestimmt wird...stimmt das?
dann verwendet der architekt doch gewisse dinge aus seiner toolbox, wie zum beispiel heuristiken (illusion der einfachheit, prototypen wegwerfen, dokumentieren, entscheidungen dokumentieren etc) und muster (architekturmuster oder entwurfsmuster) und zwar aus dem grund, da viele architekturmuster wie zum beispiel layering eben gesetze des software engineering unterstützen, also bei layering zum beispiel kapselung oder sep. of concerns. das soll eine gute architektur ja unter anderem machen, oder?
dann noch was zur arbeit des architekten: die anforderungsanalyse gehört meines erachtens nicht mit zum entwurf der sa, trotzdem sollte der architekt wegen dem verständniss schon dabei sein, ok? dann beginnt seine arbeit. aus den anforderungsdokumenten ermittelt er die einflussfaktoren, anhand derer dann die sa entworfen wird. er orientiert sich NICHT an der funktionalität der zu erstellenden software, richtig? es gibt doch dann 3 arten von einflussfaktoren, die man trenne kann:
1. organisatorische influssfaktoren
2. technische einflussfaktoren
3. produktspezifische einflussfaktoren
wobei 1. und 2. wohl die nicht funktionalen sind (portierbarkeit etc) und dann 3. eben die funktionalen (laufzeit, sicherheit, aussehen).
so, dann spezifiziert er die einflussfaktoren und macht den ersten architekturentwurf, richtig? danach wird er immer bewertungen durchführen und die ergebnisse in einen neuen entwurf bzw. eine überarbeitung stecken, richtig? irgendwann bei der 3 oder 4 iteration sollte dann ein tragfähiger entwurf bereit stehen, welcher technisch umgesetzt werden kann, oder wie jetzt? natürlich gibt es für jede iteration geeignete bewertungmechanismen (ATAM, SAAM, ad hoc etc, discovery review).
dann während der implementierung des projekts überwacht der architekt die von ihm in der sa angelegten schnittstellen und steht bei fragen zur verfügung...seh ich das richtig?
so, was genau hab ich jetzt nicht kapiert? ich raffs nämlich nicht...
VIELEN DANK FÜRS LESEN UND DIE ANTWORTEN!
andreas
sa=softwarearchitektur ;-)
eine sa beschreibt doch die wesentlichen komponenten eines softwaresytems und wie diese hierarchisch aufgebaut sind und zusammenarbeiten (über schnittstellen bzw. konnektoren etc). es geht also um schnittstellen und wann, wie warum durch wen etc diese schnittstellen genutzt werden. das ganze auf einen hohen abstraktionslevel. weiterhin werden doch die verschiedenen strukturen des softwaresystems (prozesstruktur etc) durch die sichten beleuchtet, so dass jeder stakeholder alle nötigen sichten für seinen teil der architektur hat. deswegen ist es auch wichtig, die sichten nicht voneinander entkoppelt zu sehen bzw. zu verstehen. natürlich gibt es dan eben wieder viele sichten und sichtenmodelle (4+1, zachmann, clements, siemens, rm-odp etc), die jeweils unterschiedliche aspekte der sa beleuchten. manche sind hierarchisch und manche nicht etc. seh ich das richtig, oder gibts da noch was zu ergänzen? die sichten kann man dann mittels eine adl wie uml, rapid, acme, wright etc notieren und mit schaubildern oder szenen und so weiter ergänzen. diese dokumentierten sichten dienen dann doch zum beispiel diesen punkten:
- allgemeine kummunikationsgrundlage aller stakeholder
- planung von teams, projektgruppen, arbeitsweise
- minderung der komplexität, da jeder nur das sieht, was er braucht
- einordnung des eigenen teils in das gesamtpojekt
und so weiter (für ergänzungen bin ich dankbar ;-))
später hängen doch von diesem entwurf der sa dinge wie performance, wartbarkeit, wiederverwendung etc ab, oder was? weiterhin hängt doch der entwurf einer sa nicht von der funktionalität ab, richtig? das heisst also, es geht um das beachten der nicht funktionalen anforderungen an das system, welche mir unter den namen organisatorische und technische einflussfaktoren (portiebarkeit, zeitrahmen, finanzrahmen etc) bekannt sind. man extrahiert aus denen die risiken und entwickelt eine architektur, welche genau diese risiken beachtet und dementsrepchend aufgebaut ist, korrekt? das wird ja oftmals vernachlässigt und unternehmen betrachten im projekt nur die funktionalen und wundern sich dann, warums 10x soviel kostet und 3 mal so lang gedauert hat.
vergleicht man also z.b. 2 systeme gleicher funktionalität, aber mit jeweils anderen nicht funktionalen anforderungen, so sollten sie eigentlich NICHT die selbe sa haben, da ja der entwurf der sa nicht durch die funktionalität (welche ja unterschieldich ist) bestimmt wird...stimmt das?
dann verwendet der architekt doch gewisse dinge aus seiner toolbox, wie zum beispiel heuristiken (illusion der einfachheit, prototypen wegwerfen, dokumentieren, entscheidungen dokumentieren etc) und muster (architekturmuster oder entwurfsmuster) und zwar aus dem grund, da viele architekturmuster wie zum beispiel layering eben gesetze des software engineering unterstützen, also bei layering zum beispiel kapselung oder sep. of concerns. das soll eine gute architektur ja unter anderem machen, oder?
dann noch was zur arbeit des architekten: die anforderungsanalyse gehört meines erachtens nicht mit zum entwurf der sa, trotzdem sollte der architekt wegen dem verständniss schon dabei sein, ok? dann beginnt seine arbeit. aus den anforderungsdokumenten ermittelt er die einflussfaktoren, anhand derer dann die sa entworfen wird. er orientiert sich NICHT an der funktionalität der zu erstellenden software, richtig? es gibt doch dann 3 arten von einflussfaktoren, die man trenne kann:
1. organisatorische influssfaktoren
2. technische einflussfaktoren
3. produktspezifische einflussfaktoren
wobei 1. und 2. wohl die nicht funktionalen sind (portierbarkeit etc) und dann 3. eben die funktionalen (laufzeit, sicherheit, aussehen).
so, dann spezifiziert er die einflussfaktoren und macht den ersten architekturentwurf, richtig? danach wird er immer bewertungen durchführen und die ergebnisse in einen neuen entwurf bzw. eine überarbeitung stecken, richtig? irgendwann bei der 3 oder 4 iteration sollte dann ein tragfähiger entwurf bereit stehen, welcher technisch umgesetzt werden kann, oder wie jetzt? natürlich gibt es für jede iteration geeignete bewertungmechanismen (ATAM, SAAM, ad hoc etc, discovery review).
dann während der implementierung des projekts überwacht der architekt die von ihm in der sa angelegten schnittstellen und steht bei fragen zur verfügung...seh ich das richtig?
so, was genau hab ich jetzt nicht kapiert? ich raffs nämlich nicht...
VIELEN DANK FÜRS LESEN UND DIE ANTWORTEN!
andreas
