Hallo zusammen Ich stehe vor der Aufgabe, ein Software Projekt welches in C geschrieben wird, architekturmässig darzustellen. Leider habe ich bisher noch nicht wirklich erfahrung damit. Das System mit Stift und Papier in Blöcke einzuteilen und die entsprechenden Verbindungen zu machen, ist grundsätzlich kein Problem. Jedoch möchte ich mich beim Darstellen gerne an einen "Standard" halten. Dabei ist mit UML in den Sinn gekommen. Gerne würde ich mit UML das System "zeichnen". Jedoch finde ich oft nur Beispiele bei denen die Boxen den Klassen entsprechen. Beim aktuellen System gibt es jedoch keine Klassen. Statdessen würde ich z.B. gerne einzelne Funktionen als Blöcke darstellen und die dabei zu übergebenden Parameter in Name und Datentyp angeben. Ich weiss jedoch nicht, ob sowas in UML überhaupt vorgesehen ist? Gibt es bei UML auch verschiedene Hierarchien? Also quasi eine "Grobübersicht" und eine bei welcher die einzelnen Boxen der Grobübersicht noch separat detailiert dargestellt sind? Vielleicht kann mir ja jemand ein paar Tipps geben. Danke schonmal.
:
Bearbeitet durch User
Moin Holger, Auf https://www.elektronikpraxis.vogel.de/software-engineering-mit-uml-und-c-im-einsatz-fuer-embedded-systeme-a-418202/ hatte ich mir vor einiger Zeit mal ein Lesezeichen gesetzt. Vielleicht hilfts dir ja weiter.
Holger K. schrieb: > Gerne würde ich mit UML das System "zeichnen". Jedoch finde ich oft nur > Beispiele bei denen die Boxen den Klassen entsprechen. Beim aktuellen > System gibt es jedoch keine Klassen. Statdessen würde ich z.B. gerne > einzelne Funktionen als Blöcke darstellen und die dabei zu übergebenden > Parameter in Name und Datentyp angeben. Ich weiss jedoch nicht, ob sowas > in UML überhaupt vorgesehen ist? Du kannst UML für Sprachen wie C verwenden. Ein paar Diagrammtypen passen nicht 100%ig, beziehungsweise degenerieren, wie Klassendiagramme. Klassendiagramme, wenn man sie denn nehmen will, bieten sich an um eine "Unit of Compilation" (typisch eine C-Datei) zu dokumentieren. Wer's mag ... Sequenzdiagramm finde ich bei Funktionen zum Beispiel viel interessanter als Parameter-Datentypen in degenerierten Klassendiagrammen. Ähnlich die seltener verwendeten Kommunikationsdiagramme. > Gibt es bei UML auch verschiedene Hierarchien? Eigentlich durchgehend für jeden Abstraktionsgrad. Für eine Architektur wären zum Beispiel Strukturdiagramme wie Paketdiagramme, Komponentendiagramme und Kompositionsstrukturdiagramm interessant. > Vielleicht kann mir ja jemand ein paar Tipps geben. Sieh dir zum Anfang die 14, 15 UML-Diagrammtypen nacheinander an und überlege dir was du damit anfangen könntest. Überlege dir, welche Information du zusätzlich vermitteln willst. Z.B. stehen Funktionsparameter und Datentypen schon im Source-Code. Für eine Liste davon brauche ich kein Klassendiagramm. Was könnte ein UML Diagrammtyp zusätzlich vermitteln? Schau dir auch mal doxygen als Dokumentationsgenerator an. Wichtig bei doxygen ist, es ist ein Werkzeug für das ganz klassisch gilt dass wer Müll rein steckt Müll rausbekommt. Du musst deine Code-Dokumentation sorgfältig als Kommentare im Code schreiben. Einfach doxygen über den Code laufen lassen gibt Müll.
Vielen Dank für eure Antworten. Marten Morten schrieb: > Z.B. stehen > Funktionsparameter und Datentypen schon im Source-Code. Ich sollte dazu vielleicht noch erwähnen, dass das Projekt ja noch nicht erstellt wurde. Ich bin derzeit daran, mir gedanken zu machen, wie man das ganze umsetzen könnte. Deshalb auch die Frage zu den Datentypen. Oder definiert man sowas nicht im vornherein?
Holger K. schrieb: > Code. > > Ich sollte dazu vielleicht noch erwähnen, dass das Projekt ja noch nicht > erstellt wurde. Ich bin derzeit daran, mir gedanken zu machen, wie man > das ganze umsetzen könnte. Dann überlege noch einmal genau ob und warum du wirklich auf OOP und Klassen verzichten möchtest. 98% der Programme lassen sich damit lesbarer, wartbarer, übersichtlicher strukturieren, und eben auch besser per UML darstellen. Man kann auch in C objektorientiert programmieren (wie z.B. Gtk+ und Glib vormachen), aber man kann sich bei der Gelegenheit auch überlegen ob und warum man wirklich eine Sprache ohne direkte OOP-Unterstützung verwenden will.
Dr. Sommer schrieb: > Holger K. schrieb: >> Code. >> >> Ich sollte dazu vielleicht noch erwähnen, dass das Projekt ja noch nicht >> erstellt wurde. Ich bin derzeit daran, mir gedanken zu machen, wie man >> das ganze umsetzen könnte. > > Dann überlege noch einmal genau ob und warum du wirklich auf OOP und > Klassen verzichten möchtest. 98% der Programme lassen sich damit > lesbarer, wartbarer, übersichtlicher strukturieren, und eben auch besser > per UML darstellen. Man kann auch in C objektorientiert programmieren > (wie z.B. Gtk+ und Glib vormachen), aber man kann sich bei der > Gelegenheit auch überlegen ob und warum man wirklich eine Sprache ohne > direkte OOP-Unterstützung verwenden will. Ich verstehe deine Einwände. Würde auch lieber C++ verwenden. Jedoch gibt es für den verwendeten Mikrocontroller keinen C++ Compiler. Zudem hat der Controller sehr wenig RAM. Neben all die gibt die Aufgabe auch C als Sprache vor. Studentenprobleme halt...
Holger K. schrieb: > Jedoch gibt es für den verwendeten Mikrocontroller keinen C++ Compiler. > Zudem hat der Controller sehr wenig RAM. Wie groß ist denn die Stückzahl dass der Preis so wichtig ist dass man einen so kleinen Controller wählt? Unter 10000 oder so lohnt sich der Arbeitsaufwand kaum, sich mit solchen Beschränkungen herumzuschlagen. Was für ein Controller ist das denn? Aber ok, wie gesagt geht auch mit C OOP. Man muss halt selbst mehr aufpassen.
Holger K. schrieb: > Ich verstehe deine Einwände. > Würde auch lieber C++ verwenden. > > Jedoch gibt es für den verwendeten Mikrocontroller keinen C++ Compiler. > Zudem hat der Controller sehr wenig RAM. > Neben all die gibt die Aufgabe auch C als Sprache vor. Studentenprobleme > halt... Das alles hat aber nichts mit UML zu tun. Du kannst dein Programm wunderbar mit UML modellieren und es am Ende trotzdem in C ausprogrammieren.
Und ein Zitat von Jack W. Reeves, (z.B. hier: https://staff.fnwi.uva.nl/b.diertens/se-pa/se.html) > Many different software design notations are potentially useful -- as auxiliary documentation and as tools to help facilitate the design process. They are not a software design Damit ist explizit u.a. UML & Co gemeint (solange der Code dazu parallel existiert und nicht automatisiert davon abgeleitet wird).
Eric B. schrieb: > Das alles hat aber nichts mit UML zu tun. Du kannst dein Programm > wunderbar mit UML modellieren und es am Ende trotzdem in C > ausprogrammieren. Klar. Aber wenn das Projekt so komplex ist, dass man sich erst ausführlich über die Architektur Gedanken macht und UML-Diagramme baut, würde man auch von Paradigmen (wie OOP) und Sprachen (wie C++) profitieren, die bessere Möglichkeiten für Abstraktion, Kapselung und Wiederverwendbarkeit bieten. Die Frage ist natürlich auch, wie ein derart komplexes Projekt auf einen derart kleinen Controller passt!
Es gibt auch C Code Generatoren für UML Diagramme. Es gab auch mal C++ => C Übersetzer. Noch bevor es C++ Compiler gab.
Andreas R. schrieb: > Es gibt auch C Code Generatoren für UML Diagramme. Es gab auch mal C++ > => C Übersetzer. Noch bevor es C++ Compiler gab. Da sprichst du dann aber schon von total unterschiedlichen C++ Versionen (Embryonal vs Erwachsen).
Noch ein Punkt, der für UML spricht. Noch niemals wurden Software so implementiert, wie ursprünglich geplant. Man übersieht immer einige Anforderungen. Und einige Lösungsideen funktionieren nicht. Du brauchst einen UML Editor, mit dem du die Diagramme schnell und einfach überarbeiten kannst. Sonst machst du die Änderungen nur im Programmcode und nach 100 kleinen Änderungen blickst du selbst nicht mehr durch.
Holger K. schrieb: > Jedoch gibt es für den verwendeten Mikrocontroller keinen C++ Compiler. > Zudem hat der Controller sehr wenig RAM. > Neben all die gibt die Aufgabe auch C als Sprache vor. Studentenprobleme > halt... Auch wenn die Sprache keine Objekte direkt anbietet wirst du ja den Code trotzdem nach Aufgabe gruppieren. z.B. eine Listenverwaltung mit Funktionen list_add, list_remove, ... Das wäre dann ja eine Klasse in UML mit den entsprechenden Funktionen. Außerdem brauch C++ nicht mehr RAM, als C. Allerdings kann man auch sehr leicht viel RAM benötigen ohne dass man es als Anfänger sieht.
:
Bearbeitet durch User
> Auch wenn die Sprache keine Objekte direkt anbietet
Eigentlich sollte das Thema doch abgehakt sein.
Seit 40 Jahren hat sich bewährt: Die Datenstrukturen in den Mittelpunkt
stellen. In der "Grobübersicht" die Datenstrukturen modellieren und
innerhalb der "Details" die Funktionen an die Daten hängen.
Warum wird heutzutage immer noch die umgekehrte Herangehensweise
gelehrt?
Holger K. schrieb: > architekturmässig darzustellen. Sowas ist immer zielgruppen-abhängig. Wenn Du UML lernen willst, OK. Ansonsten nimm Papier und Bleistift um Dir Klarheit zu verschaffen. Dann finde heraus, was die Zielgruppe kennt, was passt und was hilfreich ist. Einfache Blöcke, pseudocode, C-prototypen, uml, stateflow, nassi shneydermann, Ablaufdiagramme, ... Es ist nur Doku, nur malen,nur Skizze. Es ist nicht Design, wichtig, prüfbar, konsistent, Grundlage. Es ist ein Plan, mehr nicht. Wie Sunzi sagt: vergiss den Plan. Planung ist alles. (Mal ein Beispiel für Blöcke: http://www.w3big.com/de/android/android-architecture.html)
Dr. Sommer schrieb: > Dann überlege noch einmal genau ob und warum du wirklich auf OOP und > Klassen verzichten möchtest. 98% der Programme lassen sich damit > lesbarer, wartbarer, übersichtlicher strukturieren, Das behaupten viele unserer Praktikanten auch immer, und wir machen ihnen klar, was wir von ihrer Engstirnigkeit, Rückständigkeit und Überheblichkeit halten. Was der Bauer nicht kennt, das frisst er nicht. > und eben auch besser per UML darstellen. Nichtstun lässt sich noch besser per UML darstellen. Ein leeres Blatt erklärt die gesamte Tätigkeit. Oder auch deine Kenntnisse über Programmierung. >Man kann auch in C objektorientiert programmieren Ja, indem man in C einen C++-Compiler schreibt. Man kann in C auch funktional programmieren, wenn man einen Lisp-Compiler schreibt. Man kann auch den LHC-Teilchenbeschleuniger mit einem Faustkeil bauen - die Menschheit hat dafür bloß 10000 Jahre gebraucht.
Dr. Winter schrieb: > Das behaupten viele unserer Praktikanten auch immer, Sorry, weiss nicht, auf was Du Dich beziehst: Was behaupten Eure Praktikanten: A) möchten sie auf OOP verzichten? B) Dr. Winter schrieb: > 98% der Programme lassen sich damit [OOP] > lesbarer, wartbarer, übersichtlicher strukturieren,
Holger K. schrieb: > Dabei ist mit UML in den Sinn gekommen. Wenn das Programm klein genug ist. Genau so, wie Flussdiagramme nur bis zu einer bestimmten Programmgrösse Sinn machen, vor allem wenn es klein ist und man es Leuten zeigen will die noch nicht programmieren können, sind UML Diagramme auch nur tauglich für einfachere Programme. Ein UML Diagramm eines kompletten kommerziellen Programms ist einfach unhandlich und unübersichtlich. Holger K. schrieb: > Gibt es bei UML auch verschiedene Hierarchien? Nein, aber wenn das Programm seine KLassen nur stufenweise verwendet, d.h. ein Klasse wird nicht von dort verwendet was du in eine höhere Hierarchie haben möchtest, sondern nur von Klassen einer niederen Hierarchie, dann kannst du das Digramm dort trennen, in dem du die niederen Klassen nicht ausformulierst. UML hat natürlich noch mehr als bloss KLassendiagramme. Man kann durchaus nur Teilbereiche darstellen. Besonders deutlich fallen bei den Diagrammen die wverschlungenen Wege auf, die sich so durch hingehackte Programmierung ergeben.
:
Bearbeitet durch User
Holger K. schrieb: > Hallo zusammen > > Ich stehe vor der Aufgabe, ein Software Projekt welches in C geschrieben > wird, architekturmässig darzustellen. Wie groß ist denn das Projekt? Wenn es im wesentlichen darin besteht, einen Sensorwert einzulesen und einen Aktor anzusteuern, dann kriegt man damit nicht wirklich viel an Doku zusammen. Dazu dann etliche UML-Diagramme von jedem noch so kleinen Popel zu malen wäre ein wenig Overkill. ;-) Immer gut sind Diagramme, die der Übersicht über das Gesamtsystem dienen. Also zum Beispiel ein Blockschaltbild mit den wesentlichen (Sub-)Systemen und ihren Schnittstellen zueinander.
Dr. Winter schrieb: >>Man kann auch in C objektorientiert programmieren > > Ja, indem man in C einen C++-Compiler schreibt. Mein Gott. Man kanns auch ganz pragmatisch direkt in C programmieren UND dabei trotzdem objektorientiert sein UND man muß sich kein bisschen dafür verrenken, im Gegenteil es wird auch in C sauberer und übersichtlicher wenn man dabei auf dem Teppich bleibt.
Bernd K. schrieb: > Dr. Winter schrieb: >>>Man kann auch in C objektorientiert programmieren >> >> Ja, indem man in C einen C++-Compiler schreibt. > > Mein Gott. Man kanns auch ganz pragmatisch direkt in C programmieren > UND dabei trotzdem objektorientiert sein UND man muß sich kein > bisschen dafür verrenken, im Gegenteil es wird auch in C sauberer und > übersichtlicher wenn man dabei auf dem Teppich bleibt. Kann man machen, ja. Aber dann sieht der Code halt so ähnlich aus wie bei GTK. Will man das wirklich? Meiner Meinung nach ist C-Code immer noch dann am besten, wenn man sehr kleine, übersichtliche Funktionen hat die sinnvoll benannt sind. Und man natürlich auch die Datenstrukturen sinnvoll benennt. Allein durch "OOP anstatt imperativ" wird der Code auch nicht besser lesbar/wartbar.
> Aber dann sieht der Code halt so ähnlich aus wie bei GTK
Ein C Programmierer sollte sich eher am stdio.h als am GTK orientieren.
Einen Pointer und ein paar klar definierte Funktionen zur Verfügung
stellen. Die Vererbung für Dateien, Pipes, /dev, /proc usw. komplett
verstecken.
Bin der Meinung, der zentrale Punkt warum OOP besser funktioniert: Im
Mittelpunkt stehen Datenstrukturen und übersichtliche Interfaces. Das
kann man auch in C machen. Vererbung ist zwar nützlich, aber eher
nebensächlich.
Was beim GTK schief gelaufen ist - die haben aus dem OOP die
nebensächlichen Features übernommen, nicht aber die Denkweise, mit der
komplexe. umfangreiche Systeme überschaubar werden.
Sisyphusarbeit schrieb: > Bin der Meinung, der zentrale Punkt warum OOP besser funktioniert: Im > Mittelpunkt stehen Datenstrukturen und übersichtliche Interfaces. Das > kann man auch in C machen. Vererbung ist zwar nützlich, aber eher > nebensächlich. Und was ist mit Polymorphie? Geht natürlich mit Komposition und Typecasts, aber elegant ist was anderes. OOP in C ist zweifelsfrei möglich, aber weder elegant noch sonderlich schön. Mark B. schrieb: > Meiner Meinung nach ist C-Code immer noch dann am besten, wenn man sehr > kleine, übersichtliche Funktionen hat die sinnvoll benannt sind. Und man > natürlich auch die Datenstrukturen sinnvoll benennt. Allein durch "OOP > anstatt imperativ" wird der Code auch nicht besser lesbar/wartbar. Da stimme ich dir zu. Aber sobald man mal ein paar "komplexere" Datenstrukturen hat, wie Dictionaries, Verkettete Listen, Suchbäume etc. wirds wieder eklig. Generische Datenstrukturen in C sind ein Krampf.
>Holger K. schrieb: >Dabei ist mit UML in den Sinn gekommen. >>Autor: Michael B. (laberkopp) >>Wenn das Programm klein genug ist. >>Genau so, wie Flussdiagramme nur bis zu einer bestimmten Programmgrösse >>Sinn machen, vor allem wenn es klein ist und man es Leuten zeigen will >>die noch nicht programmieren können, sind UML Diagramme auch nur >>tauglich für einfachere Programme. Ein UML Diagramm eines kompletten >>kommerziellen Programms ist einfach unhandlich und unübersichtlich. So richtig kennst du dich mit UML aber nicht aus, oder? Bei UML gibt es sehr unterschiedliche Diagrammarten: https://de.wikipedia.org/wiki/Vorlage:UML_Diagrammtypen Das Paketdiagramm ist z.B. zur größeren Systemübersicht geeignet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.