Hilfestellungen zum Übergang auf neue Releases

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

Andreas Goser

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 20.09.2011, 12:48 Titel: Hilfestellungen zum Übergang auf neue Releases

Liebe (go)MATLAB Gemeinde,

ich stosse sehr häufig auf Aussagen, wonach MATLAB Nutzer auf ein bestimmtes, z.T. stark veraltetes Release, angewiesen sind. Ich möchte diesen Thread nutzen um Tipps zu diesem Themengebiet von Ihnen und Euch zu sammeln und eigene Tipps weiterzugeben.

Ich kenne 3 Familien von Problemen.

1. Technische Probleme. Das sind i. A. Fehlermeldungen aller Art, aber auch Probleme mit unterschiedlichen Ergebnissen.

2. Organisatorische Probleme. In der Regel wird zum Start eines Projektes ein Softwarestand definiert und eingefroren. Es gilt in solchen Fällen eine gute Entscheidung zu treffen. Nicht immer ist das der Fall, bzw. es gibt eine Zufallsentscheidung. Bei längeren Projekten kann man auch Aufwand für Upgrades einplanen.

3. Wirtschaftliche Probleme. Ein Wartungsvertrag ist ausgelaufen und es gibt kein Budget.

Ich möchte mich hier mit den Familien 1 und 2 beschäftigen und Detailartikel schreiben.

Andreas

Und für die Suchmaschinen:
release migration, upgrade, compatibility, budget, service pack, upwards, backwards, project, Kompatibilität, Aufwärts, abwärts, Simulink, code generation,

Zuletzt bearbeitet von Andreas Goser am 20.09.2011, 13:10, insgesamt einmal bearbeitet

Andreas Goser

Themenstarter

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 20.09.2011, 13:10 Titel:

Zu "2. Organisatorische Probleme"

Tipps für Studenten:

Wenn ein Ihnen zur Verfügung gestelltes Release, bzw. das festgelegte Release älter als 2 Jahre ist, sollten Sie Ihren Professor / Betreuer fragen, ob Sie ein neueres Release nutzen können. Falls das verneint wird, sollten Sie das hinterfragen. Folgende Informationen sollten dabei hilfreich sein:

Die weitaus überwiegende Zahl der deutschsprachigen Hochschulen verfügt über grosse, zentrale Lizenzen mit aktiven Wartungsverträgen -> aktuelle Release sind somit verfügbar, man muss nur wissen wo. MathWorks hilft dabei.

Die Verfügbarkeit von Releases wird nicht immer erfolgreich zu den Professoren kommuniziert. D.h. "man nimmt was da ist". Typischerweise ist das mit einem Anruf beim Rechenzentrum erledigt.

Kompatibilität mit Projektpartnern oder Drittanbieterprodukten. Dies können relevante Gründe sein, auf einem alten Release zu bleiben. Von Seiten der Hochschule ist es eher unwahrscheinlich einen Industriepartner zum Upgrade zu bewegen. Ich kenne mehrere Beispiele, wo die Studierenden aufwändige Downgrades am Ende einer Arbeit vornehmen mussten Sad

. Aber auch hier gilt es zumindest einmal die Entscheidung zu hinterfragen. Bei Drittanbieterprodukten, bitte MathWorks kontaktieren, da offizielle Drittanbieter schon regelmässig updaten sollten.

Andreas

Andreas Goser

Themenstarter

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 20.09.2011, 13:42 Titel:

Zu "2. Organisatorische Probleme"

Tipps für Entwickler in der Industrie:

Stellen Sie sicher, dass im Falle einer Festlegung auf ein Release, das Projektteam die Festlegung im Vorfeld mit MathWorks bespricht. Dies ist ein sehr wichtiger Punkt um Ärger während des Projektes zu reduzieren.

Hinterfragen Sie die Anforderungen von externen Projektpartnern nach älteren Releases.

Arbeiten Sie mit MathWorks zusammen und erstellen auch hauseigene Entwicklungs- und Modellierungsrichtlinien ("best practices"), so dass zukünftige Upgrades problemlos(er) verlaufen.

Planen Sie bei Meilensteinen in längeren Projekten (> 2 Jahre) den Test eines neuen Releases, bzw. des Pre-Releases ein. Oftmals gibt es eine "Migrationsangst", faktische Probleme treten aber gar nicht auf. Wobei aber die Komplexität von Migrationen von der Applikation abhängt, siehe "Technische Probleme".

IT-Abteilungen geben oftmals Standardreleases vor. Diese basieren aber nicht immer auf den Bedüfrnissen der Anwender, sondern basieren auf Effizienzbedürfnissen der IT.

Andreas

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 20.09.2011, 17:20 Titel:

Hallo,

Zu 1) Technische Probleme:

A) Version-History:
Das Arbeiten mit verschiedenen Matlab Versionen wäre deutlich einfacher, wenn jede Änderung der Funktionen im Hilfetext oder einer anderen sehr leicht zugänglichen Datenbank dokumentiert wäre.
Es gab z.B. große Probleme in der Zusammenarbeit mit einem anderen Labor, das Binäre Files im VaxD-Format benutzte. FOPEN hat aber leider in Version 2008b die Unterstützung für dieses Format verloren, was leider noch nicht einmal in den Releasenotes vermerkt wurde.
Wenn nun ein Kooperationspartner nachfragt, ob eine als M-Files vorliegendes Programm mit der Matlab Version XYZ kompatibel ist, muss ich erstmal die Liste aller zwischenzeitlich erschienen Releasenotes durchgehen, was sehr aufwändig und damit fehleranfällig ist. Eine kurze Versions-Übersicht unterhalb des Help-Textes im M-File wäre hier extrem hilfreich - und würde eigentlich üblichen Standards bei wissenschaftlich genutzer Software entsprechen.

Manche Details lassen sich aber auch mit den Releasenotes nicht finden, z.B. welche Versionen der BLAS/Lapack bzw. ATLAS, MKL Bibliotheken benutzt werden.

B) Begrenzte Kompatibilität:
Ein anderes ernstes Problem ist die eingeschränkte Kompatibilität mit alten Releases. Z.B. werden TEXTREAD, STRMATCH und FINDSTR (in Zukunft) nicht mehr unterstützt. Obwohl ich weiß, dass STRMATCH sehr behäbig ist und FINDSTR eine Quelle unerwerteter Fehler ist, und obwohl ich deshalb diese funktionen nach Möglichkeit vermeide, ist es eine ausgesprochen schlechte Idee, diese Funktionen zu entfernen.

Ich verwende STRMATCH und FINDSTR nur in einer einzigen Funktion, die beim Start des Programms prüft, ob die von mir erstellten Toolboxen zur aufrufenden Matlab-Version kompatibel ist. Dabei ist eine Umwandlung der PATH Strings in einen Cell String hilfreich. Eigentlich ist das eine Standard-Aufgabe, aber es gibt keine Funktion dafür, die seit Matlab 5.3 bit 2011b durchgängig unterstützt wird: REGEXP('split'), STRREAD, TEXTSCAN.
Hier tritt nun wieder das erste Problem auf: Es ist komplex herauszufinden, in welchen Releases diese Funktionen jeweils unterstützt werden...

Natürlich kann ich eine entsprechende Funktion aus elementaren Matlab Funktionen zusammenbasteln. Aber das ist ja nicht der Sinn einer Toolbox basierten High-Level-Sprache. Und ich kann nicht jetzt schon wissen, welche Funktionen in Zukunft auf Matlab entfernt werden!

Deshalb wäre es ausgesprochen praktisch, alle über Bord geworfenen Funktionen in einer "Deprecated"-Toolbox zu sammeln und den User bei Bedarf den Ordner temporär in den Pfad einbinden zu lassen. Natürlich gäbe es auch mit dieser Method neue Probleme, aber die könnte der User wenigstens beeinflussen.

C) Long-Term-Support
Ich möchte ein weiteres mal darauf hinweisen, dass ich ein Long-Term-Support-Release ausgesprochen nützlich fände. Dies würde bedeutet, dass über z.B. 5 Jahre Bugs gefixt würden und nur sehr elementare neue Features eingefügt werden. Ich verwende z.B. teils eigene teils in der FEX veröffentlichte Funktionen um in Matlab 6.5 folgende Befehle nutzen zu können: TYPECAST, CAST, SWAPBYTES, ANCESTOR, COMMANDWINDOW, BSXFUN, INT64- und SINGLE-Arithmetik sowie UIGETFILE('MultiSelect', 'on').

Die Methode bestehende Bugs mit neuen Releases zu bereinigen, ist in der Praxis nicht unbedingt sinnvoll, da ein neues Release natürlich immer auch neue Bugs enthält. Andererseits wäre es ziemlich sinnlos eine alter Matlab-Version zu unterstützen, die z.B. auf Windows98 angewiesen ist. Man kann das zwar in einer Virtuellen Maschine zum Laufen bringen, aber dies schränkt bereits die 100%ige Kompatibilität ein.

D) Qualiät
Trotz meiner Schwierigkeiten mit der begrenzten Kompatibilität und der wachsende Liste mit bekannten Bugs, kann ich nach umfangreichen Tests und Vergleichen zwischen verschiedenen Matlab Releases feststellen, dass die Stabilität, Kontinuität und Zuverlässigkeit von Matlab extrem hoch ist. So kann man Matlab 6.5.1 aus dem Jahr 2002 heute noch sehr gut unter WindowsXP SP3 in einer VirtualBox laufen lassen - ein Versuch mit einem ungepatchten(!) Windows, MacOS oder C-Compiler aus dem Jahr 2002 würde dagegen in einem Desaster enden. Eine Migration zu neueren Matlab Releases ist nicht trivial, aber auch für größere Projekte (in meinem Fall sind das 350.000 Zeilen Matlab-Code) mit einschätzbarem Aufwand möglich. Allerdings ist dafür natürlich eine Qualitätskontrolle mit automatischen Unit- und Integration-Tests von vornherein im Software-Design zu berücksichtigen.

Andreas Goser

Themenstarter

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 21.09.2011, 11:10 Titel:

Zu "1. Technische Probleme"

Generelle Tipps:

Der Aufwand einer Release-Migration kann sehr stark variieren. Es hängt von der Applikation ab. Ein paar Hundert Zeilen Standard MATLAB Code laufen zumeist einfach so. Wenn man allerdings ein großes Simulinkmodell mit S-Functions und Codegenerierung hat, ist Aufwand zu erwarten.

Grundsätzlich wird die Kompatibilität von der Entwicklung und der Quality Engineering Abteilungen geprüft. Ein Teil sind Testcases, und da gibt es sehr viele. SEHR viele. Trotzdem besteht natürlich ein Übergewicht von Testcases für Dinge die Anwender häufig tun, im Vergleich zu seltenen Anwendungen. Nur kann der Anwender selber schwer einschätzen was selten ist und da kann die Kommunikation mit MathWorks hilfreich sein. Produkte und Teile von Produkten die sehr dynamisch entwickelt werden, haben statistisch auch mehr Migrationsprobleme.

Fast alle relevanten Änderungen sind für alle Produkte in den compatibility considerations aufgelistet: http://www.mathworks.com/help/techdoc/rn/bqsrae0.html. Diese Informationen sind hilfreich wenn man große Projekte oder ganze Abteilungen migrieren will.

Ich möchte auch ermuntern es einfach zu probieren und sich von Fehlermeldungen nicht abschrecken zu lassen. Ich habe im MATLAB Umfeld schon mehrfach gesehen, dass ein Anwender von den Fehlermeldungen schockiert war, dann aber live mit einem MathWorks Mitarbeiter die Fehlermeldungen durchgelesen hat und überrascht war wir schnell man zum Ziel kommt. Z.B. gibt es Fehlermeldungen dieser Art: Syntax xy is obsolete, check the release notes <link>. Wenn man dann dem Link folgt, gibt es oftmals eine 1:1 Anweisung: Wenn Sie diese Option nutzen, nehmen Sie diesen neuen Befehl und machen Suchen & Ersetzen, andernfalls tun Sie dieses.

Nutzen Sie Prereleases und Service Pack Releases. Wenn Sie ein Prerelease testen und während der Zeit einen Bug berichten, wird dieser Bug mit einer sehr hohen Wahrscheinlichkeit bis zum Release gefixt. Falls er erst später entdeckt wird, gibt es immer noch die Möglichkeit des Service Packs für signifikante Fehler. Wenn Sie ein Release aber erst ein halbes Jahr nach Releasezeitpunkt testen, ist dieses Window of Opportunity vergangen.

Dieser Thread ist generell nur für das Thema Aufwärtskompatibilität gedacht. Mir ist klar, dass es Anwendungsfälle für das portieren in ältere Releases gibt, oder auch Bedarf eine Applikation für mehrere Releasestände zu warten. Aber letztendlich ist dieses Bedürfnis ja auch nur eine Antwort auf Schwierigkeiten anderer neuere Releases einzusetzen und ist damit das Wurzelproblem.

Andreas

Marco H.

Forum-Guru


	Beiträge: 404

	Anmeldedatum: 12.11.10

	Wohnort: Dortmund

	Version: 2010a/2012b

Verfasst am: 23.09.2011, 02:04 Titel:

Ersteinmal muss ich sagen, dass ich diesen Thread sehr interessant finde. So sehe ich mal schwarz auf weiß, dass ich nicht der einzige bin, der ab und an "Migrationsangst" hat...

Ich arbeite schon seit einiger Zeit an unserem Programm, was bestimmt auch noch einige Zeit zur Vollendung benötigt, da ich der alleinige Programmierer bin. Bis dato bin ich mit der 2010a Version am besten gefahren. Das Problem ist bei einem neuen Release, dass durch meine Verwendung von vielen undocumented Sachen (besonders GUIs, weil Matlab oft nicht genügend hergibt) keine Zeit bleibt und vll auch ein bisl die Muße fehlt alle halbe Jahr:

1. die Anwendung wird als standalone Application an ca. 15-20 Kollegen weitergeben die dann auch die neue MCR haben müssen. Weil nicht alle Leute bei mir im Büro sind sondern über Deutschland verteilt, ist es nicht immer so einfach es allen recht zu machen. Zudem sind die Serververbindungen zu Kollegen in anderen Büros nicht immer optimal was zusätzlich Zeit und Nerven kostet.

2. mich um die Warnmeldungen zu kümmern, die wegen Änderungen von Propertie-Eigenschaften und -Namen bei Javaklassen z.B. 'on' zu true herrühren. Oder das durch Änderungen meine komplett mit Javaobjekten erstellte Maingui nicht mehr so flüssig läuft wie in der 2010a Version. Natürlich bin ich mit den undocumented Sachen ein Risiko eingegangen, aber wenn man keine andere Möglichkeit hat, nimmt man es in kauf.

Ich gehe davon aus, dass ich beim nächsten Masterrelease den Schritt wagen würde, da ich dann sicherlich mehr Möglichkeiten im GUI Bereich haben werde und entsprechend meine ca. 40 GUis (vll bis dahin auch noch deutlich mehr, wer weiß schon wann es kommt?!) anpassen könnte/müsste um den Usern das Leben einfacher zu machen. Glücklicherweise ist in der 2010a Version die neue OOP enthalten.
Sicherlich freud man sich, wenn die Initialisierungszeit von der MCR im 2011a oder b gesenkt wurde, da diese besonders auf älteren Rechnern anfangs zum Gähnen war. Nur war es mir persönlich nicht wert 6-10 sec. beim Erststart und ca. 2-4 sec. bei erneuten Startvorgängen gegen viel Arbeit meinerseits einzutauschen. Da gibt es dann doch Wichtigeres. Zudem werden die Rechner ja auch immer schneller...

Zusammenfassend kann ich sagen, dass in meinem Fall der Zeit- Nutzen Faktor ausschlaggebend ist. Denn das Programm LÄUFT und ist jetzt schon so Umfangreich geworden, dass sich ein Update und der damit verbundene Aufwand, langfristig richtig lohnen sollte. Zudem bin auch nicht "Dauerprogrammierer" sondern muss mich noch um andere Aufgabenfelder kümmern (Laborbetreuung, Messungen, ...), sodass ich da auf jeden Fall Kompromisse eingehen muss.

Greetings

Marco

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 23.09.2011, 08:49 Titel:

Hallo Marco H,

Tja, undocumented Features...
Da kann ich TMW ein ausgesprochen großen Lob aussprechen: Das, was undokumentiert ist, verhält sich so, als ob es am besten undokumentiert wäre. Man kann also das Risiko sehr gut einschätzen - aber eben leider nicht vermeiden. Zur Zeit ist nicht mal "get(handle(gcf), 'JavaFrame')" dokumentiert!

Ich trenne deshalb die Berechnungen und die GUIs vollständig voneinander und programmiere die GUIs doppelt: Einmal mit Java-Tricks und einmal ohne. Dann kann ich im Falle von Inkompatibilitäten einfach auf das Fallback-GUI zurückgreifen. Das hat natürlich 4 Nachteile:

Aber der eine Vorteil wiegt dies wieder auf, vor allem wenn man den Code als M-files ausliefert:

In einer nicht-kompatibelen oder nicht-getestete Matlab Version wird der Nutzer nicht mit Bugs konfrontiert und kann weiterarbeiten.

Das gleiche gilt für das Mex-API: mxCreateSharedDataCopy ist sehr schnell und sehr sicher, ein Fallback auf das dokumentierte mxDuplicateArray ist aber leider nötig.
Ich kann mir übrigens beim besten Willen nicht erklären, wieso mxCreateStringFromNChars und mxGetNChars sei Matlab 5.3 undokumentiert sind. Die Funktionen sind trivial und berühren keinerlei kritische Internas, sparen aber viel Zeit und Tippaufwand.

Gruß, Jan

Marco H.

Forum-Guru


	Beiträge: 404

	Anmeldedatum: 12.11.10

	Wohnort: Dortmund

	Version: 2010a/2012b

Verfasst am: 23.09.2011, 09:31 Titel:

Hey Jan,

Zitat:

Ich trenne deshalb die Berechnungen und die GUIs vollständig voneinander und programmiere die GUIs doppelt:

Das ist prinzipiell keine schlechte Idee, dennoch würde ich in meinem Fall besonders bei der Maingui auf erhebliche Schwierigkeiten beim Platzbedarf und der Performance stoßen, wenn ich diese in reiner Matlab Manier programmieren würde. Das fängt bei der Masse der Objekte an und hört bei Splitpanes auf. Denn ständig an Resizefcn zu arbeiten finde ich eigentlich überflüssig, wenn es mit Javatricks erheblich ansprechender und schneller ist. Es ist ja auch nicht Sinn der Sache, dass der Rechner mehr rechenpower für GUI-Updates benötigt als für die tatsächlichen Berechnungen. Zudem muss ich mich auch an einen Zeitplan halten, der bei doppelt geführter GUI garnicht machbar wäre.

Zitat:

Da kann ich TMW ein ausgesprochen großen Lob aussprechen: Das, was undokumentiert ist, verhält sich so, als ob es am besten undokumentiert wäre.

Ja da gebe ich dir recht. Darum verwende ich dies eigentlich auch nur dann, wenn es wirklich notwendig ist. Sehr schnell merkt man, dass z.B. der UITREE erhebliche Mängel aufweist. Dies war auch ein Grund warum ich mich dann mehr auf Swing Sachen konzentriert habe. Nur an einem javacomponent komme ich trotzdem nicht vorbei.

Greetings

Marco

Andreas Goser

Themenstarter

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 23.09.2011, 09:44 Titel:

An Marco H. und alle die der beliebte "never change a running system" Philosophie anhängen: Ich persönlich kann das sehr gut verstehen, aber ich sehe eben auch, dass die Probleme nicht kleiner werden, in dem man sie aussitzt (allgemein gesagt, nicht persönlich gemeint). Ich sehe Anwender, die Angst vor 1-2 Stunden Aufwand haben. Allerdings nimmt der Aufwand ja mit der Zeit zu, und das noch nicht einmal linear.

Andreas

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 23.09.2011, 10:55 Titel:

Hallo Andreas,

Zitat:

Ich sehe Anwender, die Angst vor 1-2 Stunden Aufwand haben.

Und darum wäre eine List-Of-Changes Datenbank so hilfreich.
Per DEPFUN bekommt man eine Liste der benutzten Funktionen, diese gibt man weiter an die Datenbank (und sei sie auch nur eine Non-SQL-DB in Form von Text-Blöcken in jedem M-File) und man bekommt eine Liste der kritischen Änderungen. Diese müsste ja nicht einmal den Anspruch auf Vollständigkeit erheben, aber 90% der Änderungen betreffen ja auch nur 10% der Funktionen.

Der nötige Aufwand die die Developper wäre sehr überschaubar (ich hoffe, die dokumentieren ihre Änderungen bereits irgendwo!) und es würde sowohl die User als auch TMW bei den Migrationen sehr helfen. Also verbesserte Usability + mehr Umsatz.

Gruß, Jan


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2024 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.