Laden...

SW-Architektur Verständnis Hilfe

Erstellt von patzi vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.890 Views
P
patzi Themenstarter:in
7 Beiträge seit 2006
vor 13 Jahren
SW-Architektur Verständnis Hilfe

Hallo Leute,

Ich möchte beginne meien Programmen eine Architektur zu geben.
Aber irgendwie wie versteh ich das ganze nicht obwohl ich mir schon einiges durchgelsen habe.:guide:

  1. Die SW-Achrichtektur hatt nichts mit einem Strucktogram bzw. Flußdiagram zu tun oder ?(

  2. Ich habe jetzt ein Bild im Anhang so wie ich mir das für ein Programm von mir Vorstelle (nur ein Test Programm) Stimmt das jetzt oder nicht ?

Werden rein nur die Klassen und plus die Methoden wie sie verknüpft sind angezeigt oder auch wie die Funktionen unter einander verbunden sind Bild 2 oder Bild 1?(

  1. Es gibt UML , Layer Darstellung usw. giebt es dafür bestimmte verwendungszwecke ?(

  2. Es doch nur dafür dar damit wenn man das Programm (Projekt weiter giebt) oder nach längere zeit wieder etwas geändert werden musss das man sich dan sich schnell wieder zurechtfindet oder ?

Danke schon mal im Vorraus für die Hilfe !!! 😮

gruß
patzi

H
11 Beiträge seit 2010
vor 13 Jahren

Hallo Patzi,

zu 1) ein Stuktogramm bzw Ablaufdiagramm beschreibt graphisch die Struktur des Codes, hat aber mit den Zusammenhängen zwischen Klassen oder der Gesametstruktur des Projektes nichts (oder nicht viel) zu tun.

zu 2) Deine Bilder zeigen den Ausgangszustand an "Objekten" in einer Standard Windows Forms Anwendung. Dies ist weder ein Ablaufdiagramm noch eine Layerdarstellung oder vergleichbares. Schlicht die Standardstruktur WindowsForms Projektes.

zu 3) UML und Layerdarstellungen dienen hauptsächlich der Dokumentation bzw. sind zum Erklären von (teilweise komplexen) Zusammenhängen einfacher zu verstehen als "Plain Speech"

zu 4) um den Begriff Softwarearchitektur zu verstehen finde ich den Vergleich zur klassischen Architektur (von Gebäuden) am vorteilhaftesten. Diese verleiht dem Gebäude Stabilität, Wart sowie Erweiterbarkeit und Übersicht.

Nebenbei bemerkt denke ich das eine "Archtektur"
a) nur bei "größeren" Projekten sinnvoll sind und
b) grundlegendes schon vor der ersten Zeile Code überlegt werden sollte

Hoffe dir damit geholfen zu haben
Vg Norbert

F
60 Beiträge seit 2010
vor 13 Jahren

Zuallerst: Auf den bildchen erkennt man nicht wirklich was und ich tu mich verdammt schwer deinen text zu lesen - gib dir bitte etwas mühe.

UML wird genutzt, um a) software als blaupause vor der implementierung zu designen oder b) für die dokumentation später, was c), d) und x) auch nicht ausschließt. Es gibt viele arten von UML diagrammen, dabei hilft wiki.
Was du dir da aus VS generieren lässt ist meiner meinung nach kein richtiges UML Diagramm sondern ein Mischung aus Package und Component Diagramm.

Das was du dir da Vorstellst (Struktogramme/Programmablaufpläne in der OOP) werden je nach Bedarf mit Interaction Diagrammen dargestellt:

Interaction diagrams

Interaction diagrams, a subset of behaviour diagrams, emphasize the flow of control and data among the things in the system being modeled:

* Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.  
* Interaction overview diagram: are a type of activity diagram in which the nodes represent interaction diagrams.  
* Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.  
* Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.  

(
>
)

Trotzdem spricht nichts dagegen, einzelne funktionen in ein struktogramm zu quetschen.

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo patzi,

Wenn ich mir deinen Post so anschaue, solltest du eventuell noch mal ganz vorne anfangen (Was Architektur/Design angeht).

Du solltest dir eine kleine Aufgabe suchen (z.B. Adress-Verwaltung oder Medien-Verwlatung) und dort den gesammten Software-Prozess durch arbeiten (oder durchspielen).

UML enthält alle nötigen Diagramme um dich auf dem Weg zu einem vollständigen Design zu begleiten (also alles vor dem Quellcode), jedoch enthält UML keine Anleitung, was man in welcher Reihenfolge tut.
Ich schreib dir hier mal auf, mit welcher Reihenfolge ich zurecht komme:

  1. Anforderungen textuell festhalten.
  2. Use-Cases-Diagramm aufzeichnen (Was macht die Softwar und was nicht?).
    2a. (Optional) Objektdiagramme für Beispiele anlegen.
  3. Klassen- und Komunikationsdiagramme (Jetzt geht's an's Eingemachte, hier weden Klassen, Properties, Methoden, Events und alle Zusammenhänge festgelegt)
  4. Komponentendiagramm (Als letzes verteile ich immer alle Klassen auf (noch zu erstellene) Projekte/Komponenten)

Das muss nicht die für dich richtige Reihenfolge sein, aber du kannst es ja erst mal ausprobieren und dir hier im Forum Hilfe zu deinem Beispiel geben lassen und es beim nächsten mal Größer und Besser machen. 😉

Gruß
Juy Juka

PS: Wenn du die Begriffe in meinem Post nicht kennst, kannst du es auf Wikipedia nachschauen oder dir ein UML-Buch besorgen.

P
patzi Themenstarter:in
7 Beiträge seit 2006
vor 13 Jahren

Danke für eure schnellen antworten !!!

werde mich einfach mal nach einem gutem tutorial bzw. ebook umschauen...

oder kennt einer von euch eventuel eines ?

gruß
patzi

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo patzi,

das ist eine Frage für Buchempfehlungen. Außerdem ist die Frage dort möglicherweise eh schon beantwortet.

herbivore