mikrocontroller.net

Forum: PC-Programmierung UML Diagramm für C-Projekt?


Autor: Holger K. (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Lars F. (flemmy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marten Morten (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Andreas R. (daybyter)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Holger K. (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holger K. (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andreas R. (daybyter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch C Code Generatoren für UML Diagramme. Es gab auch mal C++ 
=> C Übersetzer. Noch bevor es C++ Compiler gab.

Autor: Eric B. (beric)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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).

Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M.K. B. (mkbit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

: Bearbeitet durch User
Autor: Dr. Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

: Bearbeitet durch User
Autor: Michael B. (laberkopp)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sisyphusarbeit (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: TriHexagon (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.