Use- Cases bei Funktionen??
-
Man kann auch für jede Zweizeilerfunktion eine Rolle Klopapier mit Dokumentation darüber vollkriegen...
Dann ist auch schonmal dort wo sie später gebraucht wird.Neben "ist es möglich" sollte vielleicht auch "macht es Sinn" zum Tragen kommen, wenn man eine Funktion nicht versteht indem man sie durchliest(schlimmstenfalls 2-3 Kommentare dazu), muss man entweder noch üben oder der Programmierer gehört erschlagen.
-
ja das stimmt.. ich werde natürlich nur unit tests machen bei funktionen die nen wichtigen askpet im projekt haben, und bei dnen man natürlich nich ausm code herraus unbedingt erahnt was genau passsert:)
-
Unit Tests sind nicht dafür da dass man versteht was in der Funktion abgeht, sondern dass man einen automatisierten Test hat der überprüft obs auf funktioniert.
Es gibt ja viele Funktionen die dann weitere Funktionen aufrufen, ... . Wenn man bis ganz nach unten durchgeht können das schnell ein paar hundert oder tausend Zeilen werden. Das macht schon Sinn das zu testen, denn eine Änderung irgendwo innerhalb dieser hunderten oder tausenden Zeilen kann im Endeffekt die Funktion "brechen".
Im Prinzip sollte man Tests schreiben die die gesamte Funktion der Software abdecken, von der einfachsten Utility-Funktion bis zu den ganz grossen mächtigen Modulen.
----
Und: use Cases schreibt man nicht als Doku, sondern als Vorgabe bevor man mit dem Design beginnt. Genauso kann man das mit Unit Tests auch machen, nämlich dass man zuerst die Tests schreibt, und dann erst den Code dazu (also den "zu testenden Code") entwickelt.
Hat z.B. den Vorteil dass man gezwungen ist die Implementierung von der Interface Seite her anzugehen. Also erstmal gucken muss wie man das als Anwender der Funktion/Klasse haben möchte -- bevor man noch anfängt wirklich Code dafür zu schreiben.
-
Normalerweise gilt "eine Funktion erfuellt GENAU EINE Aufgabe", somit sind Use-Cases nicht sinnvoll, weil jede Funktion nur genau einen Use-Case haben soll. Und dieser sollte aus Namen (oder wenigstens Kommentaren oder Doku) hervorgehen. Und ganz Allgemein halte ich Use Case Diagramme, wie hustbaer schon gesagt hat, als Dokumentation fuer nicht brauchbar. Das ist nicht deren Aufgabe.
ok cool wie wird das im allgeimen gemacht solche unit tests?? gibts da vorgaben?
Zu umfangreich fuer eine kurze Antwort, aber fuetter Google mal mit folgenden Schlagwörtern: Unit Tests, Test driven development, XP, extreme Programming, defensive programming
-
... sowie Agile Development.
-
BorisDieKlinge schrieb:
Hallo jungs,
Use-Cases sind ja in der Regel Anwendungsfälle welche druch Bedienung von Users mit Der Software enstehen....
Nun frage ich ob ich Use -cases auch ganz programmietechnisch für funktionen anwenden kann, also quasie das ich verschiedede Übergabe parameter eienr Funktion als use- cases der funktion sehe.... wird das so typisch bei der software entwicklun gemacht??
wie du schon selber erwähnt hast, sind use-cases zur dokumentation von anwendungsfällen gedacht. das ziel eines anwendungsfall ist ein bestimmter fachlicher mehrwert für den anwender.
da eine einzelne einfache funktion keinen mehrwert für den anwender darstellt, ist die dokumentation von funktionen mit use-cases nicht geeignet und wird auch in der praxis nicht gemacht.Gruß
mathik
-
ich steh da nämlich bischen aufm schlauch...
ich weis nich genau welche use-cases ich habe... das programm ist sehr simple von ausen her gesehen...
1. Mann definiert Profile in einer Datenbanke
2. Wählt eines diese Profile aus in der C++- Angwendung
3. Klickt auf "Berechnen" es werden daten in bezug auf das Profil berechnent
4. Mann kann das ergebniss visule Darstellen
Das wars auch schon.. was für use- casese hab ich da denn groß???
-
Naja wo ist dein Problem ? Use Cases sind nun mal, wie schon gesagt, nur dazu da die Anwendungsfälle zu beschreiben, also das wie der Anwender dein System benutzen kann. Nicht mehr und nicht weniger.
Wenn du Use Cases entwirfst, solltest erst gar nicht an Funktionen oder Klassen oder sonstiges denken, sondern dir nur Gedanken machen, wie dein System sich nach außen verhält, und darauf aufbauend dann deine Use Cases entwerfen. Ein wesentlicher Bestandteil davon ist es, den richtigen Detaillierungsgrad zu finden, sprich was ist ein Use Case und was nicht (bzw. was für Use Cases lassen sich in welche Unter-Use Cases aufteilen). Mal als Beispiel: Die pure Eingabe eines Passwortes ist sicherlich kein Use Case, wohl aber vielleicht ein ganze Authentifizierung (je nach Kontext).Ach ja und ich nehme an, dass du unter Use Cases einfach nur diese hübschen Bildchen verstehst ? (Also so Strichmännchen als Akteuer und dann die Use-Cases in so Ellipsen drin). Das ist aber nur ein Teil der Use-Case Geschichte, denn das sind lediglich die Use-Case Diagramme. Zu einem Use Case gehört allerdings auch eine Beschreibung, und die ist IMHO viel wichtiger als so ein Diagramm. Denn in dieser Beschreibung zählt man dann normalerweise alle einzelnen Anwendungs-Schritte die zu einem Use Case gehören haarklein auf (dazu kommen aber auch noch weitere Dinge). Dafür gibts auch schon vorgefertitge Templates die man benutzen kann.
Und genau das macht eigentlich den Wert von Use Cases aus: Durch diese genaue Beschreibung bekommst du erste Hinweise darauf wie z.B. die GUI zu deinem Programm aussehen sollte. Genauso kriegst du auch erste Hinweise wie du dann z.B. dein Programm programmieren kannst. Und du siehst halt auch, ob das, so wie du dir es gedacht hast, auch wirklich funktioniert, oder ob da evtl. Widersprüche drinnen sind.
Naja bisschen viel geschrieben, aber egal. Ich wollte sowieso vor längerem mal einen Artikel zu UML im Magazin schreiben, ist aber mangels Zeit irgendwie hängen geblieben
Naja und um mal auf dein Programm zu kommen. Das kann man so natürlich nicht beurteilen, weil man da viel zu wenige Infos drüber hat. Aber du sagst ja selbst schon, dass es ein kleines Programm ist, und wenn dein Programm eben nicht viel bietet, dann wird es eben auch nicht viele Use Cases haben. Wenn du z.B. ein kleines Tool schreibst, dass irgendwelche Abläufe automatisiert, dann wirst du da naturgemäß auch wenig Use Cases haben, da der Benutzer ja nicht so viele Anwendungsfälle hat.
-
BorisDieKlinge schrieb:
ich steh da nämlich bischen aufm schlauch...
ich weis nich genau welche use-cases ich habe... das programm ist sehr simple von ausen her gesehen...
1. Mann definiert Profile in einer Datenbanke
2. Wählt eines diese Profile aus in der C++- Angwendung
3. Klickt auf "Berechnen" es werden daten in bezug auf das Profil berechnent
4. Mann kann das ergebniss visule Darstellen
Das wars auch schon.. was für use- casese hab ich da denn groß???
naja, mir würden an diese stelle zwei use cases einfallen:
1. profil erstellen
2. profil lesen oder auswerten.diese musst du dann detaillierter beschreiben, jedoch immer aus anwendersicht.
-
Ok danke für euere Hilfe.. werd mich mal dran machen... und mich evtl. wieder dummen fragen melden;)
