Ruby Weblog Archiv 2005-3

Winfried Mueller
www.reintechnisch.de

Wer Skriptsprachen und Objektorientierung mag, findet in Ruby eine ästhetische Ausdrucksmöglichkeit seines Könnens. Plattformübergreifend.


14.09.2005 :: Rails - ich nun auch

Permalink

Jetzt verfolge ich Ruby on Rails schon seit einem Jahr und immer hat es mich in den Fingern gejuckt, damit mal anzufangen. Gleichzeitig habe ich auch auf Nitro geschaut, was ich ebenfalls für sehr interessant halte.

Die Entscheidung für Rails hatte mehrere Gründe:

  • Nitro hat noch lange nicht die große Community, wie Rails
  • Nitro ist mir noch zu stark in den Händen eines Entwicklers. Das ist mir zu riskant, um mich langfristig daran zu binden. Ein Webframework wechselt man nicht mal eben so aus. Deshalb brauche ich Sicherheit, dass das ausgewählte Produkt auch langfristig verfügbar sein wird. Und das es vernünftig weiterentwickelt wird.
  • Rails bekommt durch den Hype, den es in den letzten Monaten erfuhr, eine unglaubliche Kraft oder viel Energie. Viele Menschen beschäftigen sich damit, was dann zu guter Dokumentation, schneller Entwicklung und Erweiterung führt.
  • Web-Provider werden wohl bald Rails unterstützen, mein Hoster (myhosting.de) macht es schon seit geraumer Zeit. Nitro ist wohl noch weit davon entfernt.
  • Der schnelle und komfortable Einstieg in Rails durch das wunderbare Buch "Agile Web Development with Rails"

Von der Technologie dagegen hätte mich schon einiges an Nitro gereizt. Jetzt ist es jedoch entschieden, Rails zu nehmen. Ein Projekt soll in den nächsten Monaten damit umgesetzt werden.

Ein erstes "Hello World" war wirklich schnell unter Windows umgesetzt. Die Installation unter Ubuntu war dann aber problematisch. Der herkömmliche Weg, gem installieren, Rails über gem ziehen funktionierte nicht. Rails warf einen Fehler bei der Erzeugung eines ersten Projektes raus. Im Rails-Wiki stand dann aber, dass man besser Rails per apt-get von den Backports installieren soll. Und das funktionierte dann auch völlig problemlos.

In den nächsten Wochen werde ich dann also das Buch durcharbeiten und bald mit einer ersten Testanwendung durchstarten. Folglich wird hier im Weblog wohl jetzt einiges zu Ruby on Rails folgen.

Weblink:

06.08.2005 :: Start Rubyprogramm bei Windows-Start

Permalink

Anwendungsfall war ein Skript, was bei jedem Boot des Windows-Rechners gestartet werden sollte, um aus einer Access-Datenbank ein paar Werte auszulesen und daraus dann eine HTML-Seite zu generieren.

Nachdem das Skript fertig getestet war, sollte es nun automatisiert gestartet werden. Hierfür gibt man dem Skript die Endung .rbw. Dann wird das Skript nämlich mit rubyw.exe gestartet, eine Version, die kein Shell-Fenster öffnet. So arbeitet es unbemerkt im Hintergrund. Ein Link in die Autostart und die Sache funktioniert.

Das Programm wird jedoch nicht sofort gestartet, weil es total nervig ist, wenn der Rechner beim booten viele Sachen abarbeitet und man selber ausgebremst wird. Hierfür hab ich einfach ein "sleep 120" am Anfang eingebaut. Damit wird nur schnell der Intepreter gestartet und das Programm ruht dann erstmal. Nach 2 Minuten startet es dann, liest die Access-Datenbank aus und generiert die HTML-Seite.

Eigentlich müsste nun noch ein INT-Trap Handler rein, falls der Benutzer innerhalb dieser 2 Minuten den Rechner wieder runterfährt. Dann soll das Programm ja abgebrochen werden.

04.08.2005 :: Module: extend self

Permalink

Im Zusammenhang mit Methoden, die in Module gekapselt sind, sieht man mitunter folgendes:

 
module Foo
  def view
    puts "Ich bin Foo"
  end
  extend self
end

Foo.view #>> "Ich bin Foo"

Was bedeutet dieses extend self ? Mit 'def view' haben wir eine Instanzmethode definiert. Was wir aber in diesem Zusammenhang brauchen, ist eine Klassenmethode. Hierfür müsste man eigentlich schreiben 'def Foo.view' oder auch 'def self.view'. Mit extend self geschieht nun genau das selbe: Das Module holt sich sozusagen seine eigenen Objekt-Instanzmethoden eine Ebene höher und macht sie zu Klassen-Instanzmethoden. Damit sind beide folgenden Formen fast identisch:

 
module Foo
  def view
    puts "Ich bin Foo"
  end
  extend self
end


module Bar
  def self.view
    puts "Ich bin Bar"
  end
end

Foo.view
Bar.view

Die Ausnahme besteht darin, dass im ersten Fall sowohl die Klassen-Instanzmethode self.view wie auch die Objekt-Instanzmethode view vorhanden ist. Im eingesetzten Kontext spielt das aber meist keine Rolle.

Auf http://www.koders.com kann man mal nach ["extend self"] suchen und wird dort einige Beispiele finden.

Interessant ist diese Vorgehensweise auch, um Klassenvariablen inkl. Accessor-Methoden in Modulen anzulegen:

 
module Foo
  attr_accessor :var    
  def view
    puts var
  end
  extend self
end

Foo.var = "Hello"

Foo.view     #>> "Hello"
puts Foo.var #>> "Hello"

Hierüber wird also Foo.var und Foo.var= angelegt, die dann @var manipulieren, welches eine Klassenvariable ist. Das wäre identisch mit

 
module Foo
  def self.var
    @var
  end

  def self.var=(value)
    @var = value 
  end

  def self.view
    puts var
  end
end

Foo.var = "xyz"

Foo.view     #>> "Hello"
puts Foo.var #>> "Hello"

Anmerkung: In self.view wird nicht direkt über @var zugegriffen (was möglich wäre) sondern über die Methode self.var.

30.07.2005 :: Nicht zu kompliziert denken: case auf Klassen

Permalink

Wollte ein case-Switcher auf Klassentypen machen:

 
# So gehts nicht
def Foo( a )
  case a.class
    when Hash
      puts "Ist ein Hash"
    when String
      puts "Ist ein String"
  end
end

So geht das nicht, weil === nicht passend für Class definiert ist. Nächster Versuch war ein a.class.to_s und die Auswertung dann mit when "Hash". Das geht natürlich, ist aber unschön.

Es geht alles viel einfacher, man muss es nur wissen:

 
# Kurz und gut, so geht es
def Foo( a )
  case a
    when Hash
      puts "Ist ein Hash"
    when String
      puts "Ist ein String"
  end
end

Das funktioniert, weil case in der Form auswertet:

 
Hash   === a
String === a

Nicht umgedreht, wie man vielleicht erwartet (a===Hash...). In Hash und String ist === so definiert, dass true bei Klassengleichheit zurückgegeben wird.

30.07.2005 :: YamlCfg Klasse

Permalink

Wenn man Yaml als Konfigurations-Sprache einsetzt, arbeitet es sich angenehmer, wenn man auf Einträge der Konfiguration in einer URL- oder Path-ähnlichen Weise zugreifen kann. Damit macht man nicht so viele Verrenkungen und kann auch komfortable Funktionalität hinzufügen.

Hier ein erster ganz brauchbarer Versuch einer Klasse, die das bewerkstelligt:

 
#!/usr/bin/ruby1.8

#
# Winfried Mueller, www.reintechnisch.de , 2005/07/30
# 

require 'yaml'

class YamlCfg
  def initialize( cfg_file )
    @cfg_file = cfg_file
    cfg_hash = YAML.load_file( @cfg_file)
    @cfg = Hash.new
    convert( cfg_hash )
  end

  def convert( cfg, name="" )
    if cfg.class == Hash
      cfg.each do |key,value|
        curr_name = join( name, key )
        convert( value, curr_name )
      end
    elsif cfg.class == Array
      cfg.each_with_index do |v,i|
        curr_name = join(name, "[#{i}]")
        convert( v, curr_name )
      end
    else
      @cfg[name] = cfg
    end
  end
  private :convert

  def join( a, b )
    return a if b.length == 0
    return b if a.length == 0
    return a + "/" + b
  end
  private :join

  def get
    @cfg
  end

  def []( key )
    @cfg[key]
  end

  def has_key?( key )
    @cfg.has_key?( key )
  end

  def to_s
    r=""
    @cfg.each do |key, value|
      r << "#{key}: #{value}\n"
    end
    r
  end
end


# -- Ein paar Beispiele der Anwendung

cfg_file = ARGV[0]
cfg = YamlCfg.new( cfg_file )

puts cfg.to_s
puts "-----"

puts cfg['Config/FontWeight/H5']
puts cfg['DstPath']

if cfg.has_key?( 'Config/FontSize/H2' )
  puts "H2 Fontsize vorhanden"
else
  puts "H2 Fontsize nicht vorhanden"
end


if cfg.has_key?( 'Config/FontSize/H7' )
  puts "H7 Fontsize vorhanden"
else
  puts "H7 Fontsize nicht vorhanden"
end

Füttern wir dieses Programm mit einer Beispielconfigdatei:

 
#PmWiki 2.0 Config 

---
TmplPath: '/var/www/dvp/pmwiki-2-tmpl/tmpl1'
DstPath:  '../'

TmplPrePattern: '@@-'
TmplPostPattern: '-@@'

FileDefaultProp:
  Owner: 'www-data:www-data'
  Perm:  '644'

DirDefaultProp:
  Owner: 'www-data:www-data'
  Perm:  '755'

Files:
  # Dies ist nur ein Kommentar, der im diff 
  # nicht berücksichtigt wird
  - Name: 'pub/skins/wmnt/default.css'
    Perm: '0644'
  - Name: 'local/config.php'
    Perm: '0640'
  - Name: 'pub/skins/wmnt/default.tmpl'
    Perm: '0640'


Config:  

  FontFamily:
    Body:        'Verdana,Arial,sans-serif'
    Menu:        'Arial,sans-serif'
    Content:     "'Trebuchet MS',Verdana,Arial,sans-serif"
    A:           "'Trebuchet MS',Verdana,Arial,sans-serif"
    Header:      "Arial,sans-serif"
    Footer:      "Arial"

  FontWeight:
    AHover:      'normal'
    AVisited:    'normal'
    MenuA:       'bold'
    H1:          'bold'
    H2:          'normal'
    H3:          'normal'
    H4:          'normal'
    H5:          'normal'

  FontSize:
    Menu:        '1.0em'
    InputField:  '0.8em'
    H1:          '1.6em'
    H2:          '1.25em'
    H3:          '1.15em'
    H4:          '1.06em'
    H5:          '1.0em'
    HeadLeft:    '1.0em'
    FooterLeft:  '0.9em'
    FooterRight: '0.9em'
    PrePrint:    '9pt'

...dann erhalten wir folgende Ausgabe

 
Files/[1]/Name: local/config.php
Config/FontSize/H3: 1.15em
Config/FontWeight/MenuA: bold
Config/FontWeight/AHover: normal
FileDefaultProp/Owner: www-data:www-data
Files/[2]/Name: pub/skins/wmnt/default.tmpl
Config/FontSize/H4: 1.06em
Config/FontSize/FooterLeft: 0.9em
Config/FontSize/InputField: 0.8em
Config/FontSize/H5: 1.0em
Files/[0]/Name: pub/skins/wmnt/default.css
Config/FontSize/HeadLeft: 1.0em
Config/FontFamily/Footer: Arial
Files/[0]/Perm: 0644
Config/FontWeight/AVisited: normal
Config/FontWeight/H1: bold
FileDefaultProp/Perm: 644
TmplPostPattern: -@@
Config/FontWeight/H2: normal
DirDefaultProp/Owner: www-data:www-data
TmplPrePattern: @@-
Config/FontSize/PrePrint: 9pt
Config/FontSize/Menu: 1.0em
Config/FontFamily/Header: Arial,sans-serif
Config/FontWeight/H3: normal
Config/FontFamily/Menu: Arial,sans-serif
Config/FontFamily/A: 'Trebuchet MS',Verdana,Arial,sans-serif
Config/FontWeight/H4: normal
TmplPath: /var/www/dvp/pmwiki-2-tmpl/tmpl1
Config/FontSize/FooterRight: 0.9em
Config/FontWeight/H5: normal
DirDefaultProp/Perm: 755
Files/[1]/Perm: 0640
Config/FontSize/H1: 1.6em
DstPath: ../
Files/[2]/Perm: 0640
Config/FontSize/H2: 1.25em
Config/FontFamily/Content: 'Trebuchet MS',Verdana,Arial,sans-serif
Config/FontFamily/Body: Verdana,Arial,sans-serif
-----
normal
../
H2 Fontsize vorhanden
H7 Fontsize nicht vorhanden


Berücksichtigt werden 2 Containerklassen: Hashes und Arrays. Was anderes sollte in Konfigurationsdateien auch nicht vorkommen, denke ich mal. Arrays werden in die URL mit [n] aufgenommen, wobei n der Index ist.

Mit so einer Klasse kann man nun komfortabel weitere Funktionalität hinzufügen. Ein diff zwischen zwei YamlCfg Objekten ist in ein paar Zeilen erledigt. Ebenso könnten weitere Abfragemöglichkeiten implementiert werden, z.B. "Gib mir alle Konfigurationsparameter unterhalb eines Pfades." Halt all die Sachen, die man auch auf Dateisystem-Ebene kennt.

Eine weitere Idee wäre, dass man eine Art Config-Schablone lädt. Die eigentliche Config-Datei wird dann mit dieser Schablone verglichen und bei Abweichung wird eine Exception ausgeworfen. In der Schablone können sowohl Schlüssel definiert werden, die auf jeden Fall nötig sind, wie auch Datentypfestlegungen oder andere Validierungen für Config-Einträge.

29.07.2005 :: ydiff - YAML diff

Permalink

Ich gehe immer mehr dazu über, Konfigurationsdateien in YAML zu schreiben. Wenn man zwei längere Konfigurationsdateien hat, die sehr ähnlich und doch nicht gleich sind, ist es schwierig, einen schnellen Überblick zu bekommen, wo die Unterschiede liegen.

Ein normales Text-Diff-Werkzeug ist dafür nicht geeignet, weil es die YAML-Struktur nicht parst. Zeilen, die lediglich verschoben sind, werden von einem Text-Diff als Änderung gesehen, obwohl die Konfiguration aus YAML-Sicht komplett identisch sein kann.

So musste ein yaml-diff Programm her. Hier ist das Resultat, ein nicht sonderlich schöner aber funktionaler Quickhack: http://www.rubyforen.de/topic,908.html

19.07.2005 :: Parameterliste für Methoden

Permalink

Methoden, denen man eine feste Anzahl Parameter übergibt, sind problemlos mit herkömmlichen Mitteln machbar. Auch gibt es die Möglichkeit, Parameter wegzulassen, wenn sie mit Vorgabewerten definiert sind.

 
def my_method( a, b=10, c=20 )
  a * b * c
end

puts my_method( 20 )  # >> 4000

Man kann hier jedoch immer nur die hinteren Parameter weglassen, könnte also nicht my_method( 10, , 15 ) schreiben, um nur a und c zu setzen.

Für solche Zwecke, wo ein Reihe von Parametern evtl. übergeben werden, eignet sich ein anderes Vorgehen: Die Übergabe eines Hashes.

 
def my_method( cfg )
  [ :delimiter, :name, :address ].each do |value|
    a = cfg[value]
    if !a
      a = "not set"
    end
    printf( "%-15s: %s\n", value.to_s, a )
  end  
end

my_method( {:delimiter => '\n', :name => "Hello"} )

---- Ausgabe
delimiter      : \n
name           : Hello
address        : not set

Typisch ist so ein Vorgehen, wenn eine Reihe von Konfigurationsparametern übergeben wird, wobei alle irgendwelche Defaultwerte haben. Nur für die Variablen, die man im Hash setzt, soll der Defaultwert überschrieben. Die Methode muss sich natürlich selber drum kümmern, alle Werte zuerst mit Defaults zu belegen.

Weil dieses Vorgehen äußerst praktisch ist, wird es häufig verwendet. Und deshalb gibt es wohl auch die syntaktische Vereinfachung: Die geschweiften Klammern kann man weglassen. Ruby erkennt es automatisch als Hash.

 
my_method( :delimiter => '\n', 
           :name      => "Hello" )

Das geht nur in Methoden so:

 
def my_get( x )
  x
end

a = :delimiter => "\n", :name => "Hello"         # >> Fehler

a = my_get( :delimiter => "\n", :name => "Hello" ) # >> OK
p a

Und es geht auch nur dann, wenn ausschließlich dieser Hash als Parameter übergeben wird. Folgen weitere Parameter, muss der Hash wieder in geschweifte Klammern:

 
def my_get( x, a )
  x
end

a = my_get( {:delimiter => "\n", :name => "Hello"}, 10 )
p a

18.07.2005 :: ruby, rubyw, rb, rbw unter Windows

Permalink

Wenn man im bin-Verzeichnis der Ruby-Installation schaut, findet man sowohl ruby.exe wie auch rubyw.exe. Ersteres ist vom Dateityp mit *.rb Files verbunden, letzteres mit *.rbw. Eine Programm, was also mit rbw endet, wird mit rubyw.exe ausgeführt.

Der Unterschied liegt in der Erzeugung des Shell-Fensters. Bei ruby.exe wird ein normales Kommandozeilenfenster geöffnet und stdout, stdin und stderr werden mit dieser Konsole verbunden.

Bei rubyw.exe wird kein Shell-Fenster erzeugt. Folglich gehen hier stdout und stderr ins Leere. Oft hat man jedoch Programme, die etwas erledigen sollen, ohne das dabei eine Shell-Fenster aufgeht. Gleiches gilt, wenn man eine grafische Benutzeroberfläche hat, dann braucht man ja auch kein Shellfenster.

18.07.2005 :: Ruby populäre Projekte

Permalink

Eine kleine Übersicht, welche auf Rubyforge gehosteten Ruby-Projekte die meisten Downloads verzeichnen. Es sind die gesamten Downloads, was nicht unbedingt ein guter Indikator für die aktuelle Beliebtheit ist.

ProjektDownloads
One-Click Ruby Installer117244
RubyGems58282
Instiki22321
FreeRIDE16415
Win32 Utils15281
Rails13775
FXRuby8073
......
Rake -- Ruby Make5938
Nitro4261
RedCloth:Textile2651
Wee2322
cerise1886
Borges1677
BlueCloth: Markdown1327

Interessant, dass Instiki so weit oben angesiedelt ist. Das liegt aber auch daran, dass es ein Endanwender-Produkt ist, alles andere sind hauptsächlich Entwicklerwerkzeuge.

Weil im Ruby One-Click Installer FreeRIDE, Gems und weiteres enthalten ist, verzerrt das natürlich die Statistik.

Bei den Webframeworks war natürlich zu erwarten, dass Rails ganz oben steht, gefolgt von Nitro, welches aber noch deutlich weniger Bedeutung hat, obwohl es auch sehr interessant ist.

Bei den Markupsprachen scheint Textile interessanter als Markdown zu sein.

16.07.2005 :: Ruby On Rails Handbuch fertig

Permalink

Pragramtic Programmers hat das Buch "Agile Web Development with Rails" so gut wie fertig. Vorgestern hab ich das endgültige PDF-Dokument erhalten. Die gedruckte Version wird wohl in ein paar Tagen in den Buchläden zu kaufen sein.

Damit wird Ruby on Rails nochmal richtig Rückenwind bekommen. Mit einem Buch, wo alle Information gut aufbereitet sind, lässt sich wesentlich komfortabler einsteigen, als mit vielen verstreuten Online-Informationen, die man sich mühsam zusammensuchen muss. Ich finde es genial, dass Ruby On Rails mittlerweile so etabliert ist, dass es sich lohnt, ein erstes Buch zu veröffentlichen. Mit über 500 Seiten ist es zudem recht umfangreich.

Neben Dave Thomas hat David Heinemeier Hansson, der Hauptentwickler von Ruby on Rails, dran geschrieben. Dave Thomas hat ja bereits die zentrale Ruby-Referenz, das PickAxe II Buch verfasst. Die gute Qualität der Bücher kommt vor allem daher, weil hier begeisterte Ruby-Anhänger schreiben.

Die Entstehungsphase des Buches war auch einzigartig. Das pdf-Dokument konnte man schon in einer unfertigen frühen Phase kaufen und erhalten. Viele machten das und schrieben jede Menge Anregungen und Änderungsvorschläge, die dann alle in die endgültige Version mit einflossen. Ich finde, ein gutes Beispiel, wie die freie Software Kultur und kommerzielle Interessen sich ergänzen. Schlußendlich ist ein gutes Buch entstanden, was jedem hilft, mit dem freien Werkzeug zu arbeiten. Und in der Disziplin "Gute Dokumentation" scheitern oft freie Projekte. Da ist es gut, kommerzielle Unterstützung zu haben. Von Menschen, die gleichzeitig Enthusiasten einer Sache sind.

Weblinks:

13.07.2005 :: Gem Installation unter Debian Woody

Permalink

Wer unter Debian Woody unter /usr/bin/ruby den alten 1.6er Intepreter hat und den neuen unter /usr/bin/ruby1.8, der hat Probleme mit gem. Nach der Installation muss die erste Zeile von /usr/bin/gem entsprechend angepasst werden.

13.07.2005 :: Neues Gem braucht das Land

Permalink

Die Welt ist eindeutig zu schnellebig. Im Dezember hatte ich mir Ruby 1.8.2 unter Windows installiert und nun funktionierte das gem-Installationswerkzeug bereits nicht mehr. Ich dachte erst, meine Installation ist irgendwie kaputt. Nachdem ich das aktuelle gem tgz-Paket installiert hatte, funktionierte alles wieder. Bei Ruby on Rails hatte ich auch etwas davon gelesen, dass man eine rechte neue gem-Version braucht. Da scheint sich wohl was geändert zu haben.

08.07.2005 :: Ungepufferte Datenströme

Permalink

Manchmal stört es, wenn STDIN, STDOUT oder STDERR gepuffert sind. Dann kann es nämlich vorkommen, dass ein String, den man ausgegeben hat, nicht auf der Konsole erscheint, solange keine Zeilenschaltung ausgegeben wurde (mit print). Will man auf ungepufferten Modus umschalten, geht das so:

 
STDOUT.sync=true
STDERR.sync=true

07.07.2005 :: grep Ersatz in Ruby geschrieben - glark

Permalink

Grep kennt jeder, der schonmal auf einer Linux-Shell gearbeitet hat. Hiermit lassen sich über reguläre Ausdrücke Textdateien durchsuchen. Leider hat grep nicht die vollen Möglichkeiten der regulären Ausdrücke, wie man sie unter Ruby gewohnt ist.

Hierfür gibt es Abhilfe. Das Programm `glark´ kann alles, was grep kann, ist aber in Ruby geschrieben und kennt damit alle regulären Ausdrücke, wie man es in Ruby gewohnt ist. Dazu gibts natürlich noch viele weitere Erweiterungen gegenüber dem normalen grep.

Nach dem Download passt man kurz noch den Pfad im Makefile an und ruft dann make install auf. Damit sollte sich glark auf dem System installiert haben. Auch wenn nicht für Windows gedacht, läuft es grundsätzlich, wenn man die ersten beiden Zeilen rauswirft, die zuerst eine Linux-Shell starten. Allerdings klappt dort bekannterweise das Highlighting nicht. Man sollte glark dann so aufrufen, dass der Output ohne Highlighting erfolgt (-U).

Weblink:

03.07.2005 :: Buch Objektorientierte Geschäftsprozess-Modellierung

Permalink

Wenn man vor hat, mehr als einen Tausendzeiler zu schreiben, sollte man nicht gleich loslegen und in die Tasten hauen. Ich kenne viele Programmierer, die das letzte mal in der Ausbildung ein Flußdiagramm oder ähnliches gezeichnet haben. Gerne wird gleich drauf losgehackt, nachdem die Ideen im Kopf entstanden sind.

Als ich vor 20 Jahren mit Assemblerprogrammierung anfing, war Rodnay Zaks "Programmierung des Z80" das Kultbuch. Und dort vertrat er die Meinung: >> 90 % der Leute erstellen keine Flußdiagramme, weil sie meinen, sie könnten es auch so überblicken. 10 % meinen, sie bräuchten sie. Die tatsächlichen Verhältnisse sind jedoch genau umgedreht. <<

Spätestens dann, wenn man im Team an Software arbeitet oder in den Austausch mit Menschen treten muss, die die Software mitgestalten, braucht es Mittel, um Architektur und Struktur einer Software darzustellen.

Bei der objektorientierten Softwareentwicklung sind seit ein paar Jahren die zentralen Modellierungsmethoden in der UML (Unified Modelling Language) festgehalten. Man kann es kaum glauben - mehrere Experten auf dem Gebiet der objektorientierten Modellierung taten sich zusammen, gaben ihre eigene Modellierungssprache zugunsten einer neuen Gemeinsamen auf. Das muss man hoch anrechnen, haben wir doch jetzt nicht das Methoden-Chaos, wie auf vielen anderen Gebieten in der Computerbranche.

Ich war die letzten Tage auf der Suche nach einem guten Buch, um Geschäftsprozesse auf der Basis von UML zu modellieren. Manch ein Buch erschlägt einen ja förmlich mit der Masse an Information. Oft sind sie auch wenig praxisorientiert, theoretische Selbstbefriedigung. Ich habe schon Projekte erlebt, wo Leute sehr theoretisch und damit etwas von der Realität abgehoben, Prozesse modellierten. Zum Schluß kam ein hochkomplexes Modell heraus, was aber in dieser Phase viel zu detailiert und starr war. Eine kleine Änderung in den Anforderungen und viel Arbeit war nötig, alles wieder umzuschmeißen. Und diese Projekte kamen irgendwie nie über die Modellierungsphase hinaus.

Will man Modellierung nicht nur zum Selbstzweck betreiben sondern es als Basis für die Implementierung einer Software nutzen, muss man praxisorientierter vorgehen. Man muss die richtige Balance finden, darf nicht zu detailiert und ausdifferenziert im Modell werden, weil der erste Prototyp sowieso wieder soviel neue Information und Einsichten bringt, dass das Modell in vielen Bereichen angepasst werden muss. Das Modell braucht noch keine Antwort auf jede Unklarheit, es reicht, wenn man diese irgendwo dokumentiert, um sie später nochmal zu prüfen.

Ein schönes Buch, was genau in die praxisorientierte Richtung geht, habe ich jetzt entdeckt: "Objektorientierte Geschäftsprozessmodellierung mit UML" von Bernd Oesterreich, Christian Weiss, Claudia Schröder, Tim Weilkiens und Alexander Lenhard, erschienen 2003 im dpunkt.verlag. Alles Wichtige für die Geschäftsprozessmodellierung ist kurz und knapp und praxisorientiert beschrieben. Schöne Übersichtstafeln und eine Referenz befinden sich ebenfalls im Buch. Teile des Buches kann man auch Online lesen, um einen ersten Eindruck zu bekommen.

Das Buch bewahrt einen, zu detailiert zu werden, z.B. mit solchen Aussagen: "Beschreibe die wichtigsten 7 Ziele des Unternehmens..." oder "Beschreibe jeden Geschäftsanwendungsfall kurz mit 1-2 Sätzen..." Ich spüre hier klar einen Geist, der das Buch begleitet: "Wir wollen hier keine theoretische Abhandlung, die für sich sehr schön und genau wäre, sondern wir wollen das Ziel nicht aus dem Auge verlieren: Die Modellierung einer Software, die wir dann implementieren wollen."

Auf der anderen Seite spürt man jedoch das tief fundierte Wissen der Autoren über objektorientiertes Design. Verstandene Theorie, die praxiserprobt vermittelt wird. Und sowas findet man wirklich selten.

Weblinks:


Copyright dieser Seite

Permalink

Copyright (c) 2004 Winfried Mueller, www.reintechnisch.de

Es wird die Erlaubnis gegeben dieses Dokument zu kopieren, zu verteilen und/oder zu verändern unter den Bedingungen der GNU Free Documentation License, Version 1.1 oder einer späteren, von der Free Software Foundation veröffentlichten Version; mit keinen unveränderlichen Abschnitten, mit keinen Vorderseitentexten, und keinen Rückseitentexten.

Eine Kopie dieser Lizenz finden Sie unter GNU Free Documentation License.

Eine inoffizielle Übersetzung finden Sie unter GNU Free Documention License, deutsch.

In diesem Artikel werden evtl. eingetragene Warenzeichen, Handelsnamen und Gebrauchsnamen verwendet. Auch wenn diese nicht als solche gekennzeichnet sind, gelten die entsprechenden Schutzbestimmungen.

Alle Informationen in diesem Artikel wurden mit Sorgfalt erarbeitet. Trotzdem können Inhalte fehlerhaft oder unvollständig sein. Ich übernehme keinerlei Haftung für eventuelle Schäden oder sonstige Nachteile, die sich durch die Nutzung der hier dargebotenen Informationen ergeben.

Sollten Teile dieser Hinweise der geltenden Rechtslage nicht entsprechen, bleiben die übrigen Teile davon unberührt.


<< Archiv 2006 | RubyWeblog | Archiv 2005-2 >>