Hallo zusammen, für ein anstehendes Projekt hätte ich ein paar grundsätzliche Fragen zu euren Erfahrungen im Systemdesign. Ich möchte gerne eine Art Dokumentationstool entwickeln. Prinzipiell sieht das so aus, dass es eine zentrale Datenbank (mySQL) gibt, sowie Clients, die darauf zugreifen und die Pflege der Daten sowie diverse Visualisierungen und Auswertungen ermöglichen. Die Clients (von denen es beliebig viele geben wird) laufen in einem internen Netzwerk auf verschiedenen Rechnern. Grundsätzlich würde ich gerne C# verwenden - Forms oder eigentlich vorzugsweise WPF (mit WPF habe ich allerdings erst ein wenig begonnen - bei den Forms habe ich schon einiges an Erfahrung; allerdings wäre ersteres wohl zeitgemäßer) Nun bin ich mir bezüglich der Architektur nicht ganz sicher. 1) Clients als *.exe mit implementierter Logik wäre eine Option. Allerdings wird das Projekt stetig wachsen und somit muss sich jeder immer die neue Version drüberziehen - das ist doch etwas mühsam. Solche Applikationen habe ich schon entwickelt und das zieht einfach Wartungsintensität mit sich. 2) Clients webbasiert. (Das würde ich irgendwie als sinnvoller erachten) D.h. also, dass z.B. ein "Serverprogramm" läuft und ein Webinterface für alle Rechner im Netz bereitstellt. Hätte die Vorteile, dass das mit den Updates wegfällt und auch eine Lauffähigkeit auf mobilen Geräten (Tablets) wohl keine allzu große Erweiterung bedeuten würde. Nur bin ich, was das webbasierte angeht, Neuling. Habt ihr hier Erfahrungen mit Asp.Net bzw. WPF? Ist es da so, dass es eine zentrale Applikation gibt, auf die jeder mittels Browser zugreifen kann? Wie aufwendig ist es da, die UserInterfaces wie zb. in Forms zu erstellen? Ich weiß, das sind viele Fragen - ich hoffe, ich habe mich halbwegs klar ausgedrückt. Danke im Voraus für konstruktive Vorschläge. PS: würde mich auch über Literaturtipps freuen.
:
Bearbeitet durch User
so ganz blicke ich nicht, was es genau werden soll bzw. neues bringen soll, denn solche APPs gibt es ja bereits. Allerdings haben die alle ihre Schwächen auf die einzugehen, jetzt aber etwas zeitraubend wäre. Was mir aber immer wieder auffällt, ist die mangelnde Übersicht in den Systemen. Gfs bekommst Du es hin, z.B. solche Dinge wie Verzweigungsbäume / branches übersichtlicher darzustellen. Was ich auch vermisse ist eine tabellarische Listung der Code Module, die in SW verwendet wird. Wan z.B. ein Modul in die Entwicklungslinie eintritt und wann es wieder ausgetreten ist. Dann lässt sich einfacher tracken, wann man wo was updaten muss. Wenn ich mehr Zeit habe, schreibe ich nochetwas dazu. Das Thema ist aber abboniert!
@ Frank Petelka wer sagt dass er Software dokumentieren will? @Daniel V Bist du dir sicher dass dir nicht die "Grundlagen" fehlen, ..?
:
Bearbeitet durch User
Es soll als Dokumentation von Tätigkeiten in einem Betrieb dienen und den Benutzern eine einfache Möglichkeit bieten, bereits erledigte Tätigkeiten abzurufen bzw. Abläufe so zu dokumentieren, dass sie für den nächsten abrufbar sind. z.B. für Mechaniker, die Fehlerbilder bei Autos haben, die Abarbeitung und Behebung dieser dokumentieren. Anderer Kollegen können dann auf diese Dokumentation zugreifen und bekommen schnell die Information, welche Schritte sie tätigen müssen. Wichtig ist mir dabei, ein ergonomisches Userinterface zu schaffen, das es dem Benutzer schnell & einfach ermöglicht, die benötige Information zu erhalten bzw. einzupflegen. Also keine Softwaredokumentation. Weshalb sollen "Grundlagen" fehlen?
:
Bearbeitet durch User
Daniel V. schrieb: > Weshalb sollen "Grundlagen" fehlen? Du willst ein Web-Basiertes DMS (ähnliches) System schreiben, und stellst solche Fragen: >Ist es da so, dass es eine zentrale Applikation gibt, auf die jeder >mittels Browser zugreifen kann?
Robert L. schrieb: > Du willst ein Web-Basiertes DMS (ähnliches) System schreiben, und > stellst solche Fragen: > >>Ist es da so, dass es eine zentrale Applikation gibt, auf die jeder >>mittels Browser zugreifen kann? Naja, wie ich in einigen Beispielen beim Googeln gesehen habe, bieten ja Asp.net und WPF einige Möglichkeiten, sowas als halbwegs erfahrener .Net Entwickler "recht einfach" zu realisieren. Bzw. bin ich mir nicht sicher, ob das so ist und darum wollte ich hier fragen, was Leute dazu meinen, die schon Erfahrung damit haben. Weiteres bieten ja solche Umsetzungsprojekte meiner Meinung nach eine tolle Möglichkeit, sich 1) mit den Grundlagen zu beschäftigen und 2) dieses Wissen gleich in einer Applikation umzusetzen. Das habe ich auch in anderen Bereichen (z.B. Objective C lernen und eine iPhone App entwickeln) schon so gemacht und war mit dem Ergebnis wie Lernerfolg sehr zufrieden.
:
Bearbeitet durch User
Klopp den MS Schrott wie ASP.Net und dergleichen in die Tonne. Sowas macht man mit php, Javascript & HTML. Ja, eine gewisse Lernkurve muss durchlaufen werden. Ist aber machbar.
Ich könnte mir vorstellen, dass man für diesen Anwendungsfall ein CRM-System einsetzen (oder missbrauchen) könnte. Hier gibt es einige brauchbare und kostenfreie Lösungen am Markt. Als Beispiel würde mir „XRMS“ (http://de.wikipedia.org/wiki/Xrms) einfallen. Eine eigene Lösung könntest du natürlich auch entwickeln. Aus deiner Beschreibung wird aber recht schnell klar, dass du noch nicht recht weist, was du eigentlich willst (brauchst). Definiere erst einmal dein Problem (Pflichtenheft) und mache dir danach Gedanken über die Umsetzung (C#, ASP.Net, ...). Für ASP.net/PHP brauchst zu einen WebServer. Auf dem WebServer würdest du dann deine Anwendung Hosten. Die Benutzer der Anwendung würden dann auf den WebServer zugreifen. Das Problem, das du unter Punkt 1 beschreibst, könntest du mit einer ClickOnce-Anwendung (http://de.wikipedia.org/wiki/ClickOnce) umgehen. Hier wird bei jedem Aufruf der Anwendung die neueste (veröffentlichte) Version gestartet. Du brauchst dafür aber auch einen WebServer. MfG Sven
Daniel V. schrieb: > Prinzipiell sieht das so aus, dass es eine zentrale Datenbank (mySQL) Du planst eh schon MySQL als Backend-DB ein, warum willst du dich dann mit ASP.NET herumschlagen und das ganze nur fuer Windows-Clients zugaenglich machen ? Wie schon gesagt, JavaScript oder Java waeren eine Moeglichkeit. Das letztere liesse sich dann noch in einen Application-Server (jBoss,Tomcat,..) in ein Linux/Unix-Environment packen.
SvenW schrieb: > Das Problem, das du unter Punkt 1 beschreibst, könntest du mit einer > ClickOnce-Anwendung (http://de.wikipedia.org/wiki/ClickOnce) umgehen. > Hier wird bei jedem Aufruf der Anwendung die neueste (veröffentlichte) > Version gestartet. Du brauchst dafür aber auch einen WebServer. Bei einer Web-Applikation à la ASP.NET wird keine SW an Clients verteilt. Die wird einzig und alleine auf dem Server aktualisiert, also auf genau einem Rechner. olibert schrieb: > Du planst eh schon MySQL als Backend-DB ein, warum willst du dich dann > mit ASP.NET herumschlagen und das ganze nur fuer Windows-Clients > zugaenglich machen ? Tut mir leid, aber das ist Unsinn. Unter welchem BS der Web-Server läuft ist für die Clients ziemlich irrelevant. Die greifen nämlich ausschließlich über den Browser auf den (WEB-)Server zu. Und unter welchem BS der Browser läuft, ist dem Server erstmal einigermaßen egal. @TO: Wenn Du mit C# klar kommst, dann schaue Dir durchaus mal ASP.NET und ADO.NET für den DB-Zugriff an. Du solltest Dir allerdings im klaren darüber sein, das das Problem nicht die Oberfläche und das Speichern der Daten ist. Das Hauptproblem bei DMS ist nämlich, die passende (vorhandene), weitestgehed unstrukturierte Information wieder zu finden. Grüße Markus
olibert schrieb: > Du planst eh schon MySQL als Backend-DB ein, warum willst du dich dann > mit ASP.NET herumschlagen und das ganze nur fuer Windows-Clients > zugaenglich machen ? warum sollte ein asp.net nur für Windows-Client funktionieren? Sogar auf dem Server kann man Linux mit mono einsetzen. > Wie schon gesagt, JavaScript oder Java waeren eine Moeglichkeit. Das > letztere liesse sich dann noch in einen Application-Server > (jBoss,Tomcat,..) in ein Linux/Unix-Environment packen. es gibt halt Leute die wollen kein Java. Und wo soll jetzt der Vorteil von Java sein?
@Markus Punkt 1 bezieht sich auf eine Rich Client-Anwendung (*.exe). Deswegen ist das Deployment mit ClickOnce ganz richtig an dieser Stelle. MfG Sven
Erstmal danke an alle für die Kommentare und Tipps. Nun, die Frage, weshalb ich gerne .Net verwenden möchte: Ich arbeite eben schon lange auf .net, bin sehr zufrieden damit und natürlich ist es eine gewisse Trägheit, die mich dort verweilen lassen will. Gleichfalls möchte ich mir aber gerne Alternativen anschauen und bin nicht abgeneigt, was anderes zu probieren. Markus schrieb: > Wenn Du mit C# klar kommst, dann schaue Dir durchaus mal ASP.NET und > ADO.NET für den DB-Zugriff an. Du solltest Dir allerdings im klaren > darüber sein, das das Problem nicht die Oberfläche und das Speichern der > Daten ist. Das Hauptproblem bei DMS ist nämlich, die passende > (vorhandene), weitestgehed unstrukturierte Information wieder zu finden. Das habe ich mir jetzt mal angesehen - also ich muss sagen, dass Asp.net mir grundsätzlich gefällt; werde mal ein par Beispiele programmieren. ADO.net ist, wie ich das verstehe, gleich wie eine OLEDB Connection bzw. eine SQL-Connection, soweit also recht einfach zu verwenden. Wie ist es mit den Browsern, die diese Asp.net Applikation verwenden bzw. muss der Zielrechner da auch z.B. über .Net FW verfügen oder ist das egal, da das nur am Rechner relevant ist, auf dem die Applikation läuft?
Daniel V. schrieb: > Wie ist es mit den Browsern, die diese Asp.net Applikation verwenden > bzw. muss der Zielrechner da auch z.B. über .Net FW verfügen oder ist > das egal, da das nur am Rechner relevant ist, auf dem die Applikation > läuft? es wird eine normale Webseite erzeugt. Der Browser weiß nicht das dort .net am werkt ist. Mann braucht auch kein PHP auf dem PC wenn man eine Webseite aufruft die mit PHP erzeugt wurden ist.
Robert L. schrieb: > @ Frank Petelka > > wer sagt dass er Software dokumentieren will? Wie würdest du das Beschreiben eines komplexen Systems sonst nennen, wenn nicht Dokumentieren? Und ist es nicht automatisch "Software" eine solche Systemmodellierung zu verwenden?
man kann auch das Melken einer Kuh dokumentieren. und nein, auch wenn die Zitzen angenehm weich sind, ich würde das dann nicht als Software bezeichnen...
wobei hier die Methode , also der Melkvorgang (dessen Beschreibung) die Software wäre, die Kuh und ihre Extremitäten sind und bleiben HW :-)
Daniel V. schrieb: > z.B. für Mechaniker, die Fehlerbilder bei Autos haben, die Abarbeitung > und Behebung dieser dokumentieren. > Anderer Kollegen können dann auf diese Dokumentation zugreifen und > bekommen schnell die Information, welche Schritte sie tätigen müssen. Dieser Traum ist einer der bisher unerfüllten, und er wird es ewig bleiben. Das scheitert nicht an der Software, das scheitert an den Anwendern. Oliver
Oliver S. schrieb: > Dieser Traum ist einer der bisher unerfüllten, und er wird es ewig > bleiben. Das scheitert nicht an der Software, das scheitert an den > Anwendern. Ja, gerade darum ist mir ein ergonomisches und ansprechendes Design vom UserInterface i.d.R. sehr wichtig - sonst scheitert das sowieso von vorn herein. Nichts desto trotz hat sich, trotz einiger hilfreicher Inputs hier, das Projekt in Luft aufgelöst. Aber wer weiß, vielleicht ist es bald mal wieder von Interesse :)
Daniel V. schrieb: > Ja, gerade darum ist mir ein ergonomisches und ansprechendes Design vom > UserInterface i.d.R. sehr wichtig - sonst scheitert das sowieso von vorn > herein. absolut, aber das würde ich nicht zum "Systemdesign" rechnen. Jedenfalls nicht zu dem Part den man "Modellieren" müsste.
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.