Der Shopblogger - KROSSE\nIn der Bremer Neustadt kennt fast jeder den SPAR-Markt in der Gastfeldstraße – und seinen Besitzer Björn Harste. Der 39-Jährige ist Einzelhändler mit Leib und Seele. Nur ist er etwas anders als seine Kollegen. Denn Björn Harste ist „Der Shopblogger“! Aus dem Hinterzimmer seines Marktes schreibt er ein Blog über das Leben im Supermarkt…\nAußerhalb seines Marktes ist Björn Harste schwer anzutreffen. So hatte er auch keine Zeit für ein „ordentliches“ Interview. Termine auszumachen, sagte sein Mitarbeiter am Telefon, sei eigentlich sinnlos. Am besten, man kommt einfach im Laden vorbei. Bei der Begrüßung sind Björns erste Worte: „Eigentlich hab ich grad viel zu viel zu tun. Können wir das so nebenbei machen?“ Und dann eilt er in seiner roten Weste durch die Regalreihen davon, dass man kaum hinterher kommt.\nBei Björn ist eben alles etwas unkonventionell. Während er mit seinem Klemmbrett vor der Gemüseabteilung steht und seine Bestellungen notiert, beantwortet er gut gelaunt alle Fragen. Gleichzeitig über Salatköpfe, Karotten und Kartoffeln nachzudenken und Interviews zu geben, ist für ihn eine leichte Übung. Schließlich ist es nicht sein erstes Mal. Nahezu sämtliche regionale Fernsehsender und Tageszeitungen haben bereits über ihn und seinen Laden berichtet. Denn wie erwähnt, ist Björn Harste kein gewöhnlicher Einzelhändler.\nWir gehen zu Björn\nEin Supermarkt ist eigentlich kein Ort, an dem man Kreativität vermuten würde. Menschen hasten durch vollgestopfte Gänge und werfen Lebensmittel in ihre Körbe – Hauptsache, schnell wieder nach Hause! Die Kassierer schieben lustlos ein Teil nach dem anderen über den Scanner, das monotone Piepen der Kasse vermischt sich mit Musik, die ununterbrochen aus dem Radio dudelt… Falsch! Nicht bei Björn. Seit zwölfeinhalb Jahren betreibt er nun bereits seinen Laden in der Gastfeldstraße. Angefangen hat er in diesem Gewerbe 1994 als Auszubildender im Einzelhandel. Eigentlich war nach dem Fachabitur ein Studium als Bauingenieur geplant, doch ein Nebenjob bei „Comet“ neben der Schule machte ihm so viel Spaß, dass er sich für die Karriere im Supermarkt entschied. Heute ist er Besitzer von zwei Läden, dem SPAR und einem „Nah und Gut“-Markt in Findorff. Er ist Chef von 37 Mitarbeitern und versorgt täglich über tausend Kunden mit allem, was das Herz begehrt – und noch ein bisschen mehr.\n„In Studentenkreisen hier in der Neustadt heißt es nicht: ‚Ich geh zum SPAR‘, sondern ‚Ich geh zu Björn‘“, erklärt der Delmenhorster stolz. „Wir sind hier so was wie eine Institution im Stadtteil.“ Das verwundert nicht. Allein beim Betreten des Ladens wird man sofort mit einem freundlichen „Hallo“ begrüßt. Außerdem findet man hier vieles, was es anderswo nicht zu kaufen gibt. „Manchmal suchen Kunden nach bestimmten Artikeln und die bestellen wir dann oder nehmen sie dauerhaft ins Sortiment auf“, sagt Björn und dann: „Warte mal kurz!“\nEin älterer Herr steht vor ihm und hat eine Frage. „Herr Harste, Sie hatten doch sonst immer so schöne Weihnachtskarten…“ Und weg ist Björn und zeigt dem Kunden das Regal, in dem die Karten stehen. Als er gleich darauf zurück kommt, fragt er: „Wo waren wir?“\nBei der Kreativität, Herr Harste. Denn die freundliche Atmosphäre im SPAR ist nicht der Grund, weshalb Björn Harste eine lokale Berühmtheit wurde. Es sind seine außergewöhnlichen Ideen.\nEinkaufen in der Geisterbahn\nIrgendwo im Inneren ist jeder Mensch noch ein Kind. Bei Björn hat dieses Kind einen Supermarkt als Spielwiese, um sich auszutoben. So verdunkelte er kurz vor Halloween seinen ganzen Laden ab 21 Uhr bis auf ein bisschen Schwarzlicht, dekorierte ihn mit Spinnweben und steckte seine Mitarbeiter in Horror-Kostüme. Vor dem Eingang des SPAR bildete sich eine Menschenmenge wie vor einer Diskothek – Glühwein wurde ausgeschenkt und im Inneren, zwischen Konserven und Tiefkühlkost kicherten und kreischten erwachsene Menschen in den Gängen herum.\nAuf dieses „Scary Shopping“ angesprochen, leuchten Björns Augen freudig auf.\n„Ja, da war dieses Jahr wieder Bombenstimmung. Die Idee kam mir vor vier Jahren an Halloween im Heidepark Soltau. Ich dachte: ‚So was müsstest du mal im Laden machen!‘ Das erste Jahr haben wir alles einfach improvisiert und es war gleich ein super Erfolg!“\nWenn auch nicht unbedingt finanziell. Denn eins ist klar: In einem stockfinsteren Laden hat niemand wirklich den Überblick und Ladendiebe haben praktisch freie Hand. Ob er an diesen Tagen mehr oder weniger Umsatz gemacht hat, kann Björn nicht genau sagen. Es ist ihm jedoch auch gleichgültig. Er macht diese Dinge, weil er daran Spaß hat und weil es etwas Besonderes ist. „Vielleicht schütteln die anderen Einzelhändler den Kopf über mich, keine Ahnung.“ Björn zuckt die Achseln. „Aber das sind halt wir!“\nBjörn nimmt kein Blatt vor den Mund – auch nicht in seinem Blog. Das Gespräch kommt nun auf diese vielleicht bemerkenswerteste seiner Ideen. Inzwischen ist Björn von der Gemüsebestellung zur Weinabteilung übergegangen und sortiert die Flaschen aus den Kisten ins Regal ein. „Bremer Supermarkt erobert das Internet“ titelte der Weser-Kurier vor einem Jahr. Tatsächlich bloggt Björn nun schon seit sieben Jahren. Inspiriert vom „law blog“ des Düsseldorfer Rechtsanwalts Udo Vetter, kam ihm eines Tages die Idee, einen Blog über seine Arbeit im Supermarkt zu schreiben. Und weil Björn ein Mann der Tat ist, war „Der Shopblogger“ bereits einen Tag später im Netz. „Ich glaube, ich habe damals die Berufsblog-Welle stark mit beeinflusst“, erzählt er. „Zu der Zeit war das noch völlig neu.“\nSeitdem schreibt er eigentlich täglich seine Gedanken im Blog nieder, direkt von der Arbeit aus – vom Computer im Hinterzimmer. „Andere gehen in der Pause eine rauchen, ich schreibe“, sagt Björn schlicht. Und er dokumentiert: die Marotten seiner Kunden („Da erlebt man die beklopptesten Sachen!“), witzige Preisschilder oder Verpackungen und natürlich seine eigenen Events.\nDass er mit dem Blog so einen großen Erfolg landen würde, damit hat er nicht gerechnet. Inzwischen erreicht er täglich ungefähr 30-35.000 Leser. Die genauen Zahlen interessieren ihn aber nach eigenen Angaben nicht. Viel mehr freut er sich über das positive Feedback seiner Kommentatoren: „Das ist das Salz in der Suppe!“ Leser schicken ihm Fotos von SPAR-Märkten auf der ganzen Welt und kommen in seinen Laden, um ihn mal mit eigenen Augen zu sehen.\nVielleicht ist „Der Shopblogger“ so erfolgreich, weil er unkommerziell und völlig frei Schnauze schreibt. Wenn Björn die Menschen im Laden auf die Nerven gehen, lädt er sich im Blog den Frust von der Seele. Ob er damit Kunden vergrault, wenn sie sich selbst dort wiederfinden? Er zuckt nur die Achseln. „Ich mach das für mich. Das Blog hat sich zu einer Art persönlichem Archiv entwickelt, wo ich selbst oft Dinge nachschlage, um mich zu erinnern. Es hat eher Tagebuch-Charakter.“ Auf die Frage, was sein Ziel mit dem Blog sei, hat er eine klare Antwort: Keines. Wenn überhaupt, möchte er die Menschen unterhalten und als Nebeneffekt ein bisschen informieren, einfach so.\nEin Leben für den Supermarkt\nEs ist schon bemerkenswert, was Björn Harste alles „einfach so“ macht. Er betreibt seine Supermärkte und bietet einen Teil seines Sortiments auch noch in einem Online-Shop an. Darüber hinaus hat er noch zwei Webseiten: Für seinen SPAR-Markt und sein Blog.\nBjörn steht hier absolut im Mittelpunkt. Er ist das Herz, der Kopf und die Beine des Ladens, er steht keine Sekunde still. Auf die Frage nach seinem Privatleben schnauft er kurz auf.\n„Privatleben? Was für ein Privatleben?“ Dann erzählt er davon, wie er am Anfang, nach der Eröffnung des Ladens im April 2000, achtzig bis hundert Stunden die Woche gearbeitet habe.\nEine Zeitlang wagte er das Experiment, rund um die Uhr geöffnet zu haben. Auch damit war er in der Presse. Aber vor drei Jahren kapitulierte Björn dann vor dem Stress. „Das war einfach auf Dauer zu hart!“\nDoch auch so lebt der Mann in seinem Laden, wenn nicht physisch, so doch in Gedanken. Sogar seine Freundin Ines arbeitet mit ihm zusammen dort. Die beiden sehen die Trennung von Arbeit und Beziehung nicht als Problem an. „Nein, wir trennen das eigentlich nicht“, erklärt Ines, während sie Regale einräumt. „Nur nach Feierabend wird nicht mehr über die Arbeit geredet. Da machen wir einen Cut und sind einfach mal wir.“ Die drei gehören vielleicht einfach zusammen, Björn und Ines und der SPAR.\nZukunftspläne und der große Traum\nWenn er noch mal ganz von vorne anfangen könne, sagt Björn nach kurzem Nachdenken, würde er etwas machen, wo er keine Mitarbeiter brauche. „Dann ist man nicht von anderen abhängig. Dritte werden den eigenen Ansprüchen eben selten gerecht.“ Ein Satz, der einen Hang zum Perfektionismus erahnen lässt. Aber alles allein machen kann auch Björn nicht, obwohl er es auf bemerkenswerte Art schafft, all seine Projekte zu managen.\nUnd natürlich muss er sich auch Gedanken machen, wie es in Zukunft mit seinem Laden weitergeht. Nächstes Jahr droht dem SPAR der Umbau zum „Edeka“-Markt. Die große Supermarktkette ist dabei, die SPAR-Märkte „platt zu machen“, wie Björn es ausdrückt. Er hat sich damit abgefunden und wirkt gelassen, obwohl er zugibt, dass es schade ist. Weil sein SPAR eine solche Institution ist. Und man fragt sich natürlich, wie es dann mit dem Blog weitergeht – ob ihm seine Leser auch Fotos von „Edeka“-Märkten zuschicken und ob das dann überhaupt noch Sinn macht.\nFür sich persönlich träumt Björn davon, früh in Rente zu gehen. Ob er mit seinen 39 Jahren schon müde wird? Eigentlich macht er nicht den Eindruck. Aber vielleicht wünscht er sich auch einfach ein bisschen mehr Freizeit. Er fährt gern Fahrrad, hat ein Boot an der Weser und bringt sich selbst das Banjo spielen bei. Einfach so. Ein normaler Mensch ist er eben auch, der Björn, auch wenn er die Dinge etwas anders macht, als die anderen.


Richtig Grillen - Gesund grillen - Meldung - Stiftung Warentest\nEs muss nicht immer fettes Fleisch auf dem Grill landen. Auch magere Fleischsorten, Fisch und Gemüse schmecken gegrillt sehr gut. Und Gepökeltes gehört überhaupt nicht auf den Grill. test.de gibt Tipps für gesunde Grillmahlzeiten.\nHolzkohle oder Elektro\nDie Wahl des Grills ist Geschmackssache: Gas- oder Elektrogrills sind schnell angeheizt und halten die richtige Temperatur so lange es gewünscht wird. Zudem produzieren sie weniger Rauch, da sie keine offene Flamme haben. Allerdings muss bei Elektrogrills eine Steckdose in der Nähe sein. Das macht sie für ein Grillfest auf der Wiese eher ungeeignet. Viele Grillfans schwören auf Holzkohlegeräte. Diese haben aber eine längere Anheizzeit. Je nach Grill kann es fast eine Stunde dauern, bis sich die Holzkohle mit einer feinen weißen Ascheschicht überzogen hat. Erst dann dürfen Fleisch und Gemüse auf den Rost.\nTipp: Mit welchen Grillgeräten Sie bestens ausgerüstet sind zeigt der Test Grillgeräte (test 06/2008).\nWenn Fett, Fleischsaft oder Marinade auf die Glut tropfen und dort verbrennen, entstehen krebserregende Stoffe. Diese so genannten Benzpyrene steigen mit dem Rauch auf und können sich am Grillgut ablagern. Wer dies vermeiden möchte, sollte Fettauffangschalen aus Aluminium benutzen. Besonders fettes Fleisch oder in Öl marinierte Lebensmittel können zuerst in Alufolie garen und nur zum Schluss kurz auf dem offenen Rost nachgegrillt werden. Für viele ein Leckerbissen sind die gebräunten Fettkrusten am Fleisch. Doch Vorsicht: Diese enthalten besonders hohe Benzpyrenmengen. Wer keine Auffangschalen verwendet, sollte mariniertes Fleisch zumindest abtupfen, bevor es auf den Rost kommt. Schwarz verkohlte Stellen – egal ob an gegrilltem Fleisch, Gemüse oder Brot – sollte generell niemand essen.\nNicht auf den Grill gehören gepökelte Fleischwaren wie Kasseler, Räucherspeck und Bockwürste. Sie enthalten Nitritpökelsalz. Dadurch bilden sich bei hohen Temperaturen Nitrosamine, die Krebs erzeugen können.\nGrillmahlzeiten sind meist recht reichhaltig: Eine Portion bringt schnell zu viele Kalorien auf den Tisch. Es muss aber nicht immer fettes Fleisch, Kartoffelsalat mit viel Mayonnaise oder fettreiche Kräuterbutter auf das Grillbuffett kommen. Auch magere Fleischsorten, Fisch und Gemüse schmecken gegrillt sehr gut. Kartoffelsalat lässt sich ebenfalls fettarm zubereiten. test.de gibt Anregungen.\nGrillkäse. Zypriotischer Halloumi aus Kuh-, Schafs- und Ziegenmilch zerfließt nicht. Wenden Sie ihn vor dem Grillen in gewürztem Olivenöl. Sie können ihn mit Salat oder gegrilltem Gemüse servieren. Feta und Mozzarella schmelzen leichter, eignen sich aber auch zum Grillen – zum Beispiel mit Tomatenscheiben in Alufolie gewickelt.\nGemüse. Garen Sie Maiskolben und Kartoffeln vor, dann verkürzt sich die Grillzeit. Bestreichen Sie die Maiskolben nach dem Grillen mit Butter. Zum Würzen reicht Salz. Wenn Sie von beiden Seiten Zahnstocher in den Kolben stecken, ist das Abknabbern einfacher und niemand verbrennt sich die Finger an den heißen Maiskolben. Dünne Zucchini- und Auberginenscheiben schmecken mariniert, Paprika oder Champignons gefüllt.\nTofu. Der Sojaquark sollte mindestens eine Stunde in Marinade liegen, Sojasoße ist dafür gut als Basis geeignet. Grillen Sie ihn mit Gemüse und Pilzen am Spieß. Es gibt auch vegetarische Würstchen und Steaks aus Tofu oder Pflanzeneiweiß.\nObst. Als Grill-Nachtisch bietet sich hervorragend Obst an. Stecken Sie einfach verschiedene feste Fruchtstücke auf Spieße und legen Sie diese auf den Grill. Bestreichen Sie die Spieße danach mit etwas Honig und servieren Sie Eis dazu.\nKartoffelsalat aus der eigenen Küche\nKartoffelsorte. Für den Salat sollten Sie festkochende Kartoffelsorten wie Cilena, Nicola, Selma oder Sieglinde verwenden. Achten Sie darauf, dass die Kartoffeln keine grüne Stellen oder Keime haben.\nKreativ sein. Mit verschiedenem Gemüse lässt sich der Kartoffelsalat aufpeppen. Radieschen, Cocktailtomaten, Lauchzwiebeln, Paprika und Gurken eignen sich besonders gut. Hartgekochte, kleingewürfelte Eier passen ebenfalls. Sie können auch fein gehackte Kräuter wie Petersilie, Dill und Liebstöckel zugeben.\nLeichtes Dressing. Machen Sie den Salat nicht zur Kalorienbombe. Als Dressing eignen sich Essig und Öl, fettarme Majonäsesorten und Joghurts. Sie können auch den Sud von Gewürzgurken nutzen und damit das Dressing verfeinern.\nDurchziehen lassen. Stellen Sie den fertigen Salat über Nacht abgedeckt in den Kühlschrank und lassen ihn gut durchziehen. Die süddeutsche Variante mit Speck, Essig und Öl servieren Sie jedoch lieber lauwarm.\nNachwürzen. Der Kartoffelsalat nimmt beim Durchziehen die meisten Gewürze auf. Mögen Sie den Salat pikant, würzen Sie vor dem Servieren noch einmal nach.


aktuelles aktuelles Suche\n. Sie sind nicht angemeldet.. Anmelden. 4. April 2013\nOliver Bender, 18:14 Uhr in Marketing im Studium, Master Die Einsichtnahme zur Klausur Kundenmanagement findet am Freitag, 03. Mai von 09.00-10.30 Uhr in Raum 5.223 statt. Bitte melden Sie sich bis 30. April unter juergen.kirsch@wiso.uni-erlangen.de für die Einsichtnahme an.\nKommentare deaktiviert 15. März 2013\nEinsichtnahme der Klausur Absatz\nOliver Bender, 10:42 Uhr in Bachelor, Marketing im Studium Die Einsichtnahme der Klausur Absatz findet am 24.04.2013 von 9:00-11:00 Uhr in Raum LG 5.151 statt. Für die Teilnahme an der Einsichtnahme ist eine Anmeldung über StudOn erforderlich. Die Anmeldung startet am 15.03.2013, 12:00 Uhr. Sie können sich bis 23.04.2013, 12:00 Uhr zur Einsichtnahme anmelden.\nKommentare deaktiviert 21. Februar 2013\nStudienführer für Bachelorstudiengänge\nOliver Bender, 14:10 Uhr in Bachelor, Marketing im Studium Den aktuellen Studienführer für das Marketingstudium in Bachelorstudiengängen finden Sie hier.\nKommentare deaktiviert 4. Februar 2013\nOliver Bender, 12:23 Uhr in Marketing im Studium, Master Informationen zu der Klausur „Marketingtheorie“ finden Sie hier.\nKommentare deaktiviert 18. Januar 2013\nOliver Bender, 10:43 Uhr in Marketing im Studium, Master Um an dem Modul „Strategisches Marketing“ und damit am Planspiel teilzunehmen, ist eine verbindliche Anmeldung bis zum 28. März 2013 notwendig. Bitte schicken Sie Ihre Anmeldung per Email an timo.zagel@wiso.uni-erlangen.de. Alle weiteren Informationen finden Sie hier.\nKommentare deaktiviert 7. Dezember 2012\nStellen als wissenschaftliche Mitarbeiter/innen\nOliver Bender, 11:34 Uhr in Marketing im Studium, Master Der Lehrstuhl für Betriebswirtschaftslehre, insbesondere Versicherungmarketing sucht ab sofort wissenschaftliche Mitarbeiter/innen. Nähere Informationen finden Sie hier.\nKommentare deaktiviert 29. Oktober 2012\nAchtung Raumänderung Marketingtheorie\nOliver Bender, 13:14 Uhr in Marketing im Studium Achtung Raumänderung: Die Montagstermine der Veranstaltung Marketingtheorie am 19.11.2012, 10.12.2012, 14.01.2013 und 28.01.2013 finden in Raum 0.424 statt.\nKommentare deaktiviert 15. Oktober 2012\nOliver Bender, 16:00 Uhr in Marketing im Studium Die erste Veranstaltung Service Marketing findet am Donnerstag, den 18.10.2012 von 13.15 -14.45 Uhr im H1 statt.\nKommentare deaktiviert 11. Oktober 2012\nOliver Bender, 18:22 Uhr in Bachelor, Marketing im Studium Die Einsichtnahme zur Klausur Dienstleistungsmarketing findet am Donnerstag, den 25. Oktober 2012, von 16.00-17.00 Uhr im Raum 5.222/a statt. Für die Einsichtnahme ist eine vorherige Anmeldung bei Oliver Bender, bis einschließlich 24. Oktober 2012, notwendig (oliver.bender@wiso.uni-erlangen.de).\nKommentare deaktiviert 9. Oktober 2012\nOliver Bender, 12:11 Uhr in Marketing im Studium, Master Die Vorlesung Marketingtheorie findet noch nicht am Donnerstag, den 18. Oktober 2012 statt. Start der Vorlesung ist Donnerstag, der 25. Oktober 2012.


AGB: Allgemeine Geschäftsbedingungen - HOTHOT HEIZKÖRPER\nStartseite AGB: Allgemeine Geschäftsbedingungen\n1.1 Diese Allgemeinen Geschäftsbedingungen (weiter nur „AGB“) gelten für den Einkauf im Internetgeschäft (weiter nur ""E-Shop"") der Gesellschaft HOTHOT Exclusive s.r.o., ID: 293 10 601, UID: CZ 293 10 601, mit Sitz Brno (Brünn) - Mariánské náměstí 617/1, Komárov, Brno, PLZ: 617 00, eingetragen im Handelsregister beim Kreisgericht in Brünn im Abschnitt C, Einlage 73121, und sind auf der Internetseite der Gesellschaft www.hothotradiators.com veröffentlicht.\n1.2 Die AGB definieren und präzisieren näher die Rechte und Pflichten des Verkäufers und des Käufers (weiter nur „Käufer“ oder „Kunde“). Die Angaben zum Verkäufer sind folgende:\nHOTHOT Exclusive s.r.o. Sitzo: Brno (Brünn) - Mariánské náměstí 617/1, Komárov, Brno, PLZ: 617 00 ID:29310601 UID: CZ29310601\nAnschrift für die Zustellung elektronischer Post: [email protected]\nTelefon: +420 731 192 517\n(weiter nur „Verkäufer“ oder „Gesellschaft HOTHOT Exclusive s.r.o.“)\n1.3 Die durch diese AGB nichtgeregelten rechtlichen Verhältnisse richten sich nach der tschechischen Rechtsordnung, konkret nach dem Gesetz Nr. 89/2012 Slg., Bürgerliches Gesetzbuch (weiter nur „BGB“) und dem Gesetz Nr. 634/1992 Slg., über den Verbraucherschutz, in der Fassung der späteren Vorschriften (weiter nur „Verbraucherschutzgesetz“).\n1.4 Mit dem Abschluss des Vertrages bestätigt der Käufer, sich mit diesen AGB bekanntgemacht zu haben, ihren Inhalt zu kennen und ihnen zuzustimmen. Die AGB sind integrierter Bestandteil des abgeschlossenen Kaufvertrages.\n2. Abgrenzung der Begriffe und Verfahren des Kaufvertragsabschlusses\n2.1 Verkäufer ist die Handelsgesellschaft HOTHOT Exclusive s.r.o., ID: 293 10 601, UID: CZ 293 10 601, mit Sitz Brno (Brünn) - Mariánské náměstí 617/1, Komárov, Brno, PLZ: 617 00, eingetragen im Handelsregister beim Kreisgericht in Brünn im Abschnitt C, Einlage 73121. Der Verkäufer ist eine Handelskorporation, die bei Abschluss und Erfüllung des Vertrages im Rahmen ihrer Geschäfts- oder anderen Unternehmenstätigkeit handelt. Es handelt sich um eine Unternehmensperson, welche dem Käufer direkt oder mittels anderer Unternehmenspersonen Produkte liefert oder Leistungen erbringt.\n2.2 Kunde unseres E-Shops ist der Käufer. Im Hinblick auf die gültige rechtliche Regelung ist zwischen dem Käufer als Verbraucher und dem Käufer als Nichtverbraucher zu unterscheiden.\nDer Käufer als Verbraucher oder nur Verbraucher ist jeder, der außerhalb des Rahmens seiner Unternehmenstätigkeit oder außerhalb des Rahmens der eigenständigen Ausübung seines Berufes mit der Unternehmensperson einen Vertrag abschließt oder mit ihr anderweitig handelt.\nDer Käufer als Nichtverbraucher ist eine Unternehmensperson. Als Unternehmensperson wird ferner jede Person erachtet, die im Zusammenhang mit der eigenen Geschäfts-, Produktions- oder ähnlichen Tätigkeit bzw. bei der eigenständigen Ausübung ihres Berufes Verträge abschließt, ggf. eine Person, die namens oder auf Rechnung einer Unternehmensperson handelt.\n2.3 Kaufgegenstand – Kaufgegenstand ist auf der Grundlage des Kaufvertrages die in der verbindlichen Bestätigung der Bestellung seitens des Verkäufers, mit welcher der Kaufvertrag abgeschlossen wird, angeführte Ware. Die auf der Internetseite www.radiators.shop angeführten Informationen zur Ware entsprechen den aktuell verfügbaren Angaben und Informationen. Maßgeblich sind die Angaben zur Ware, einschließlich des Kaufpreises, zu jenem Zeitpunkt, zu welchem der Käufer dem Verkäufer die Bestellung zustellt. Gegenstand des Kaufes ist zugleich die gemäß dem Wunsch des Verbrauchers oder für seine Person angepasste Ware (Auftragsware). Im Falle der Auftragsfertigung der Ware werden die maßgeblichen Angaben zur Ware anhand der Produktionsskizze bzw. Zeichnung sowie der Preis durch die Vertragsparteien vereinbart.\n2.4 Das Verfahren beim Abschluss des Kaufvertrages ist folgendes:\nDie Bestellung des Käufers ist der Vorschlag (das Angebot) für den Abschluss des Kaufvertrages. Der Kaufvertrag ist mit der Akzeptanz dieses Vorschlages abgeschlossen, und zwar mit der verbindlichen Bestätigung der Bestellung seitens des Verkäufers, die dem Käufer per E-Mail zugestellt wird. Die Bestellung des Käufers und die verbindliche Bestätigung der Bestellung seitens des Verkäufers werden als zugestellt erachtet, sofern sich jene Parteien, für die sie bestimmt waren, mit ihnen bekanntmachen können. Ab diesem Zeitpunkt entstehen zwischen dem Käufer und dem Verkäufer wechselseitige, aus dem Kaufvertragsabschluss resultierende Rechte und Pflichten. Im Falle einer den Wünschen des Verbrauchers gemäß oder für seine Person angepassten Ware (Auftragsware) wird der Vertrag durch die verbindliche Bestätigung des Vorschlages des Verkäufers für die Gestaltung der Ware (in der Regel die Bestätigung der Produktionsskizze bzw. -zeichnung) durch den Käufer abgeschlossen. Der abgeschlossene Vertrag kann in tschechischer, slowakischer oder englischer Sprache erstellt sein und wird beim Verkäufer aufbewahrt, der dem Verbraucher auf Verlangen den Zugang zu diesem ermöglicht.\n3. Rechte und Pflichten der Vertragsparteien\n3.1 Mit dem Abschluss des Kaufvertrages entsteht dem Verkäufer die Pflicht, dem Käufer den Kaufgegenstand zu übergeben, während dem Käufer die Pflicht entsteht, den Kaufgegenstand zu übernehmen und dem Verkäufer hierfür den vereinbarten Kaufpreis zu bezahlen.\nMit dem Abschluss des Kaufvertrages bestätigt der Käufer, sich mit diesen Geschäftsbedingungen, einschließlich der Reklamationsordnung, bekanntgemacht zu haben und diesen zuzustimmen. Auf diese Geschäftsbedingungen und die Reklamationsordnung wird der Käufer in ausreichender Weise vor der eigentlichen Realisierung der Bestellung hingewiesen, indem er die Möglichkeit hat, sich mit ihnen bekanntzumachen.\nDer Verkäufer behält sich unter anderem das Recht vor, die Bestellung oder ihren Teil vor dem Abschluss des Kaufvertrages auf der Grundlage einer Vereinbarung mit dem Käufer in jenen Fällen zu stornieren, wenn die Ware nicht mehr hergestellt oder geliefert wird, oder sich erheblicher Weise der Preis des Lieferanten der Ware geändert hat. Im Falle, dass der Käufer bereits eine Teil oder den gesamten Kaufpreis bezahlt hat, wird ihm dieser Betrag auf sein Konto oder an seine Anschrift zurückerstattet, wobei der Kaufvertragsabschluss nicht zustande kommt.\n3.2 Der Verkäufer verpflichtet sich, dem Käufer eine mangelfreie Ware im Einklang mit der gültigen Rechtsordnung der Tschechischen Republik zu liefern, und zwar an die durch den Käufer angegebene Anschrift (Anschrift eines EU-Mitgliedsstaates). VERSANDKOSTENFREI innerhalb Österreichs, Deutschlands und in die Schweiz. Im Falle des Transports an eine Anschrift außerhalb der EU werden die Transportkosten individuell geregelt.\n3.3 Der Käufer ist verpflichtet, die bestellte und gelieferte Ware im Einklang mit dem Kaufvertrag und den AGB zu übernehmen. Der Käufer hat dem Verkäufer den Kaufpreis fristgerecht im Einklang mit den im Kaufvertrag vereinbarten Bedingungen und den AGB zu bezahlen, die auf der Internetseite www.radiators.shop veröffentlicht sind.\n3.4 Das Eigentumsrecht geht auf den Käufer erst nach vollständiger Bezahlung des Kaufpreises und nach der Übergabe der Ware an den Käufer über. Die Gefahr des zufallsbedingten Verderbs und des zufallsbedingten Schadens geht auf den Käufer mit der Übergabe des Liefergegenstandes an Käufer über.\n3.5 Der Verbraucher hat das Recht, binnen 14 Tagen ab der Übernahme der sog. Standardware, die auf den Webseiten des Verkäufers als „Unsere“ Ware gekennzeichnet ist, vom Kaufvertrag zurückzutreten. In einem solchen Falle hat der Verkäufer das Recht auf Erstattung der Kosten im Zusammenhang mit der Rückgabe der Ware. Der Rücktritt vom Vertrag ist ausgeschlossen, sofern eine gemäß den Wünschen des Verbrauchers oder für seine Person gefertigte Auftragsware geliefert wurde, wobei sie auf den Webseiten des Verkäufers als „Ihre“ Ware gekennzeichnet ist. Der Rücktritt vom Vertrag ist ausgeschlossen auch in dem Fall, dass der Heizkörper in anderer Farbe als RAL 9016 oder RAL 9010 bestellt wurde. Der Vertragsrücktritt, die Bedingungen, die Frist und die Verfahren der Geltendmachung dieses Rechtes sowie das Formular für den Rücktritt vom Vertrag, dessen Attribute durch die Verfügung der Regierung der Tschechischen Republik Nr. 363/2013 Slg. festgelegt sind, sind auf der Internetseiten des Verkäufers unter www.radiators.shop veröffentlicht.\n3.6 Im Falle, dass sich der Verbraucher entschließt, vom Kaufvertrag zurückzutreten, füllt der Käufer das Musterformular für den Vertragsrücktritt unter Anführung der Nummer der Bestellung, des Kaufdatums und der Kontonummer für die Rückerstattung des Geldes aus und sendet dieses per E-Mail an den Verkäufer. Das Geld wird auf die angeführte Kontonummer des Kunden spätestens binnen 14 Tagen überwiesen.\nDer Vertragsrücktritt ist per E-Mail an die E-Mail-Adresse [email protected] zu senden.\n3.7 Im Falle des Rücktritts vom Vertrag sendet der Verbraucher die Ware spätestens binnen 14 Tagen auf eigene Kosten an die Anschrift HOTHOT Exclusive s.r.o., Mariánské náměstí 617/1, Komárov, Brno, PLZ: 617 00.\nDie Kosten im Zusammenhang mit dem Kauf und der Rückgabe der Ware umfassen auch die Kosten der Rückführung der Ware in den ursprünglichen Zustand im Falle, dass die Ware beschädigt wurde oder Anzeichen der Abnutzung aufweist. Im Falle, dass die zurückgegebene beschädigt, funktionslos, unvollständig ist oder Anzeichen der Abnutzung und der Benutzung aufweist, wird dem Käufer der um die durch den Verkäufer für die Rückführung der Ware in den ursprünglichen Zustand aufgewendeten Kosten geminderte Kaufpreis zurückerstattet. Hiervon ist nicht der Ersatz des, dem Verkäufer entstandenen Schadens berührt.\n3.8 Nach Vereinbarung kann die Rückerstattung der bezahlten finanziellen Betrages in Form des Austausches gegen eine andere Ware in entsprechendem Wert erfolgen, die entweder mit der weiteren Bestellung des Kunden oder eigenständig zugesendet wird. Wir die Ware eigenständig geliefert (im Falle des Austausches der Ware), werden die Postgebühren nicht in Rechnung gestellt, jedoch nur dann, wenn es sich um ihren ersten Austausch handelt.\n3.9 Hat der Verkäufer gemäß dem Vertrag oder diesen AGB das Recht, vom Vertrag zurückzutreten, erlöschen mit dem Vertragsrücktritt alle Rechte und Pflichten der Parteien aus dem Vertrag.\n3.10 Nicht berührt sind jedoch die Bestimmungen bzgl. der Vertragsstrafen, der Verzugszinsen, des Informationsschutzes und die Bestimmungen bzgl. jener Rechte und Pflichten, aus deren Charakter resultiert, dass sie auch nach dem Rücktritt andauern sollen (insbesondere handelt es sich um die Pflicht, die finanziellen Leistungen für, vor der Wirksamkeit des Rücktritts gewährte Erfüllungen zu erbringen. Der Rücktritt vom Vertrag berührt jedoch nicht den Anspruch auf Ersatz eines infolge einer Verletzung des Vertrages entstandenen Schadens. Der Rücktritt vom Vertrag hat keinen Einfluss auf die Gewährleistung der Verpflichtungen aus dem Vertrag.\n4. Bezahlung der Ware\n4.1 Die Ware wird dem Käufer erst nach vollständiger Bezahlung des Kaufpreises und der Transportgebühr (VERSANDKOSTENFREI innerhalb Österreichs, Deutschlands für die Bestellung oberhalb 1000,-EUR) Im Falle des Transports an eine Anschrift außerhalb der EU werden die Transportkosten individuell geregelt) übergeben.\na) Der Käufer bezahlt den Kaufpreis auf der Grundlage der ausgestellten Akontorechnung im Voraus in voller Höhe mittels Banküberweisung auf das Konto des Verkäufers oder mittels PayPal oder mittels der Kreditkarte.\nb) Der Käufer bezahlt den Kaufpreis auf der Grundlage der ausgestellten Pro-Forma-Rechnung im Voraus in der Höhe 50% der Preis. Das andere Teil in der Höhe 50% bezahlt der Käufer nach der Übernahme der Ware. Beide Bezahlungen mittels Banküberweisung auf das Konto des Verkäufers oder mittels PayPal oder mittels der Kreditkarte.\nDie ausgestellte Akontorechnung sendet der Verkäufer dem Käufer zur Zahlung auf der Grundlage der Annahme der Bestellung. Die Zahlung des Käufers wird mit der Gutschrift des in Rechnung gestellten Betrages auf dem Konto des Verkäufers als bezahlt erachtet. Anschließend wird die Ware aus dem Lager freigegeben oder es wird im Falle einer Auftragsware die Produktion begonnen.\n5. Liefertermin und Transport\n5.1 Die Transportkosten sind:\nFür Retail-Kunden (Endkunden, Verbraucher) VERSANDKOSTENFREI innerhalb Österreichs, Deutschlands für die Bestellung oberhalb 1000,-EUR\nFür Großhandelskunden in allen EU und Nicht-EU auch (Unternehmen), den Transport wird eine Gebühr unter einem Handelsabkommen oder andere Abkommen geschlossen.\nIm Falle des Transports an eine Anschrift außerhalb der EU werden die Transportkosten individuell geregelt.\nÜber den Termin der Warenlieferung und über den Spediteur wird der Verkäufer den Käufer in ausreichendem Zeitvorlauf in Anknüpfung an den gewünschten Termin der Warenlieferung informieren. Der Käufer ist verpflichtet, dem Verkäufer ausreichende Kontraktangaben für die Durchführung des Transports, wie die Zustelladresse, die E-Mail-Adresse, die Telefonnummer zu gewähren.\n5.2 Der Käufer ist verpflichtet, bei der Übernahme der Sendung diese zu kontrollieren, um festzustellen, ob die Verpackung unverletzt ist und ob die Sendung keine offensichtlichen Anzeichen einer Beschädigung aufweist. Sofern bei der Übernahme der Sendung durch den Käufer offensichtliche Anzeichen einer Beschädigung festgestellt werden, ist er verpflichtet, mit dem Spediteur ein Schadensprotokoll zu erstellen. Der Käufer ist in einem solchen Falle nicht verpflichtet, die Sendung entgegenzunehmen. Die Beschädigung der Sendung beim Transport meldet der Käufer dem Verkäufer ohne unnötigen Aufschub. Sofern der Kunde vom Spediteur eine so beschädigte Sendung übernimmt, ist es unabdingbar, die Beschädigung im Übergabeprotokoll des Spediteurs zu beschreiben. Der Käufer ist verpflichtet, zugleich die Anzahl der Pakete auf dem Versandschein mit der tatsächlichen Anzahl der zugestellten Pakete zu vergleichen, die identisch sein muss. Im Falle, dass die Anzahl der Pakete auf dem Versandschein von der Anzahl der zugestellten Pakete abweicht, übernimmt der Käufer die Sendung unter Vermerk des Vorbehalt auf dem Versandschein und meldet dem Verkäufer schriftlich die Reklamation. Sofern er dies verabsäumt, wird die Reklamation bzgl. des fehlenden Paketes nicht anerkannt.\n6. Mängelhaftung, Garantie und Reklamationsordnung\nFür die Geltendmachung der Rechte aus der Mängelhaftung (Reklamation) im E-Shop der HOTHOT Exclusive s.r.o. gelten insbesondere die Bestimmungen § 1914 bis 1925, § 2099 bis 2117 und § 2161 bis 2174 des Gesetzbuches Nr. 89/2012 Slg. BGB), die Reklamationsordnung, die auf der Internetseite www.radiators.shop, einschließlich des Formulars für die Geltendmachung der Reklamation (Reklamationsblatt) veröffentlicht ist, welches für die Geltendmachung der Reklamation verwendet werden kann.\nDer Verkäufer haftet gegenüber dem Verbraucher dafür, dass der Liefergegenstand bei der Übernahme keine Mängel aufweist. Insbesondere haftet der Verkäufer gegenüber dem Verbraucher dafür, dass der Liefergegenstand zum Zeitpunkt der Übernahme durch den Verbraucher:\njene Eigenschaft besitzt, welche die Parteien vereinbart haben, und falls eine solche Vereinbarung fehlt, solche Eigenschaften, die der Verkäufer oder der Hersteller beschrieben oder die der Käufer im Hinblick auf den Charakter der Ware sowie auf der Grundlage der von ihnen betriebenen Werbung erwartet hat;\nfür jenen Zweck geeignet ist, den der Verkäufer für seine Verwendung anführt, oder zu welchem ein Gegenstand dieser Art üblicherweise verwendet wird;\nvon seiner Qualität oder Ausführung her dem vertraglichen Muster oder der Vorlage entspricht, sofern die Qualität oder die Ausführung anhand eines vertraglichen Musters oder einer Vorlage bestimmt wurde;\nin der entsprechenden Menge, dem entsprechenden Maß oder Gewicht geliefert wird und\nden Anforderungen der rechtlichen Vorschriften entspricht.\nHat der Liefergegenstand nicht die oben angeführten Eigenschaften, kann der Verbraucher auch die Lieferung eines neuen Gegenstandes ohne Mängel verlangen, sofern dies im Hinblick auf den Charakter des Gegenstandes nicht unangemessen ist; sollte dies nicht möglich sein, kann er vom Vertrag zurücktreten.\nTritt der Verbraucher nicht vom Vertrag zurück oder macht er von seinem Recht auf Lieferung eines neuen, mangelfreien Gegenstandes keinen Gebrauch, kann er einen angemessenen Nachlass verlangen.\nDas Recht aus der mangelhaften Erfüllung steht dem Käufer nicht zu, sofern der Käufer vor der Übernahme des Gegenstandes davon Kenntnis hatte, dass der Gegenstand einen Mangel aufweist, oder sofern der Käufer den Mangel selbst verursacht hat.\nDer Verbraucher ist berechtigt, das Recht aus einem Mangel geltend zu machen, welcher bei der Gebrauchsware im Zeitraum von vierundzwanzig Monaten ab der Übernahme auftritt. Tritt der Mangel im Verlaufe von sechs Monaten ab der Übernahme in Erscheinung, wird davon ausgegangen, dass der Gegenstand bereits bei seiner Übernahme mangelhaft war.\nWeitere Rechte und Pflichten im Zusammenhang mit der Verantwortlichkeit des Verkäufers für Mängel regelt die Reklamationsordnung des Verkäufers, die auf der Internetseite unter www.radiators.shop veröffentlicht ist.\n7.1 Der Käufer erteilt mit dem Abschluss des Vertrags seine Zustimmung zur Verarbeitung und Erfassung seiner personenbezogenen Daten in der Datenbank des Verkäufers nach der erfolgreichen Erfüllung des Vertrages. Der Käufer hat das Recht, die Zustimmung mit der Datenverarbeitung in schriftlicher Form zu entziehen. Die personenbezogenen Daten der Kunden sind gegen einen Missbrauch voll gesichert.\n7.2 Die Verarbeitung der personenbezogenen Daten erfolgt in Einklang mit der Verordnung (EG) Nr. 679/ 2016 des Europäischen Parlaments und des Rates vom 27. 4. 2016, zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (weiter als „GDPR“). Der Käufer erteilt mit dem Abschluss des Vertrags seine Zustimmung, dass die Gesellschaft HOTHOT Exclusive s.r.o. in Einklang mit dem GDPR seine Personendaten verarbeitet, besonders seinen Vornamen, Nachnamen, seine Adresse oder seinen Geschäftsort und seine E-Mail-Adresse, zum Zweck auf Basis und nach Maßgabe in der Information für Subjekte zur Verarbeitung der personenbezogenen Daten, verfügbar auf den Internetseiten der Gesellschaft https://radiators.shop/de, damit sich der Kunde vertraut gemacht hat.\n8.1 Maßgebliches Recht\nDie in diesem Vertrag überhaupt nicht oder nur teilweise geregelten Fragen richten sich ausschließlich nach dem tschechischen materiellen Recht. Die Anwendung des UN-Abkommens über den internationalen Warenkauf wird hiermit ausdrücklich ausgeschlossen.\na) Im Falle der Entstehung eines Streites bei der Realisierung dieses Vertrages oder im Zusammenhang hiermit, werden sich die Vertragsparteien bemühen, einen solchen Streit durch wechselseitige Verhandlung beizulegen.\nb) Sollte es nicht gelingen, den Streit in einer solchen Weise zu lösen, ist zu seiner Verhandlung und Entscheidung die Rechtsbefugnis des ständigen Schiedsgerichtes bei der Wirtschaftskammer der Tschechischen Republik und der Agrarkammer der Tschechischen Republik im Einklang mit seiner Geschäftsordnung gegeben.\nc) Der durch das oben angeführte Schiedsgericht ausgegebene Schiedsbefund ist für die Vertragsparteien endgültig und verbindlich.\n8.2 Diese AGB erlangen mit dem Tage ihrer Veröffentlichung Wirksamkeit und sind für alle an diesem Tag und später getätigten Bestellungen maßgeblich. Der Verkäufer behält sich das Recht auf eine Änderung der AGB vor. Mit dem Tage ihrer Veröffentlichung wird die Gültigkeit der vorherigen AGB aufgehoben.\n8.3 Der Käufer ist nicht berechtigt, seine aus dem Kaufvertrag resultierende Forderung gegenüber dem Verkäufer ohne Zustimmung des Verkäufers an einen Dritten abzutreten.\n8.4 Die vertraglichen Vereinbarungen der Parteien im Kaufvertrag haben gegenüber jenen Bestimmungen dieser AGB, die im Widerspruch zu ihnen stehen sollten, Vorrang.\n8.5 Diese AGB sind integrierter Bestandteil des Vertrages und der Käufer ist verpflichtet, sich mit ihnen bekanntzumachen.\n8.6 Sollte eine Bestimmung des Vertrages oder dieser AGB gänzlich oder teilweise ungültig sein, ist hiervon nicht die Gültigkeit der sonstigen Bestimmungen der AGB berührt. Anstelle der ungültigen Bestimmung gilt eine solche Bestimmung als vereinbart, die dem Sinn und Zweck der ungültigen Bestimmung am meisten entspricht.\nDiese Bedingungen erlangen am 1. 1. 2019 Wirksamkeit.\nHOTHOT Exclusive s.r.o


Spora Luxemburg : CS Grevenmacher\nJetzt war es also Samstag 15.00 und man hatte bereits das erste Fussball Spiel hinter sich gelassen, was nun machen auf einem schönen Parkplatz im Wildpark bei Karlsruhe. Hmmm? Dani Rohner und ich diskutierten und diskurtierten, gehen wir nach Sochaux zum Ligauftakt in Frankreich oder doch nach La Chaux de Fonds, nein nicht schon wieder NLB, hatten wir letzte Woche schon. Aber Sochaux, wieso auch nicht, geile Fans schönes Stadion und nicht so weit, also ab nach Frankreich oder\ndoch nicht...es war ja erst drei Uhr in 2 Stunden waren wir in Sochaux, Super und da 3 Std. rumhängen bis zum Spiel? Also doch nach Luxemburg zum Saisonstart, weit war es ja nicht mehr von Karlsruhe aus...nun Ende der Diskussion, wir warfen eine Münze! Sochaux oder Luxemburg?\n2 Minuten später, befanden wir uns auf dem Weg nach Saarbrücken, anfängliche Träumereien, dass wir evtl. noch das Spiel FC Saarbrücken Amas gegen den FC Homburg mitnehmen könnten, mussten wir schnell begraben, da dass Wetter echt beschissen war! Gemäss Radio Durchsagen hatten wir aber noch Glück im Unglück, den Teils fielen in der Pfalz und im Saarland sogar Bäume auf die Strassen und es gab kilometerlange Staus. Nach ca. 3 Stunden hatten wir das "schöne" Luxemburg erreicht. (PS: Dani zum zweiten Mal innerhalb von 2 Monaten...) Die Suche nach dem Stade Josy Barthel (übrigens benannt nach einem ehemaligen luxemburgischen Olympia Sieger) verlief ziemlich schwierig, da überhaupt nichts ausgeschildert war, was solls wir kamen natürlich doch noch früh genug zum Luxemburgischen National Stadion. Das Stade Josy Barthel ist das grösste und wohl auch schönste Stadion von Luxemburg, also wir waren schon positiv überrascht. Noch ein, zwei Bierchen in der Stadionkneipe und hoch gings auf die Tribüne zum National Divison Hit: Spora gegen Grevenmacher, das Niveau war etwa so wie wir es uns erwartet hatten,es pendelte so zwischen schlechten NLB und besserem 1.Liga Niveau. Legendär war der Bob Marley im Tor von Spora, und auch das es mehr Fans von Grevenmacher als von Spora hatte. Es hatte vielleicht ca. 400 Fans vor Ort, davon auch ein paar mit Generation Luzifer Pullis (kamen wohl direkt vom Betzenbersch), die waren aber bitter entäuscht weil sie ihr 1.FC K wieder mal im Stich gelassen hatte....HAHAHA.\nZum Spiel: Die Grevenmacher machten....super diese Wortwahl...kurzen Prozess mit dem entäuschenden Team aus der luxemburgischen Haupstadt. Das wird wohl eine schwere Saison für Spora in der obersten luxemburgischen Liga. Und schon war das Spiel auch schon wieder fertig, ein neuer Länderpunkt und einen geilen Samstag im Gepäck!\nAlso gings wieder heimwärts, um 4 Uhr in der früh waren wir dann auch schon wieder in Gossau. Genau richtig für ein paar Stunden Schlaf, zwei Stunden Joggen (also da spreche ich jetzt nur für mich, also ich weiss nicht, vielleicht war der Rohner ja auch noch am Gübsensee, hab ihn nur nicht gesehen) und ab gings zum Cup Fight am Sonntag Nachmittag, FC Rorschacherberg: FC Winkeln!\n19991 Aachen1 AC Milan1 A Jugend: FCB1 Amateure2 Bello e impossibile1 Borussia1 Borussia Dortmund5 Caen / Sochaux - Bastia1 FC Aarau1 FC St.Gallen1 Halbfinale1 Hertha BSC6 Hertha BSC Berlin1 Jubiläumsfahrt1 Juventus Turin1 Lech Posen1 Mailand1 Olympique Lyon1 SC Austria Lustenau2


Berücksichtigung zukünftiger Anforderungen in der SW-Architektur\n3 Einleitung und Überblick\n3.1 Typische Auslöser für (unerwartete) neue Anforderungen\n3.2 Eigenschaften von Änderungen\n3.3 Vorbereitung und Durchführung von Änderungen an einem bestehenden System\n3.4 Gliederung der nachfolgenden Kapitel\n4 Bewertung von Anforderungen/Änderungen\n4.1 Requirement Trees\n4.2 Kategorisierung von Anforderungen nach dem Kano-Modell\n4.3 Software Architecture Analysis Method (SAAM)\n4.4 Architecture Tradeoff Analysis Method (ATAM)\n4.5 Effort-Impact Grid Analysis\n5 Vorbereitung einer SW-Architektur auf Änderungen\n5.1 Expressive modularization\n5.2 Design by contract (DbC)\n5.3.2 Horizontal Separation\n5.3.3 Vertical Separation\n5.3.4 Aspect Separation - aspektorientierte Programmierung\n5.4 Layering for change\n5.6 Open/Closed Principle\n5.7 Eingebaute Änderungs-Mechanismen\n5.7.2 Stable design centers - built-in changeability\n5.7.3 Generative Ansätze: MDSD, AOSD\n6 Umsetzung von (unerwarteten) Änderungen\n6.1 Sicherung des bisher Erreichten\n6.2 Einbettung in die bestehende Architektur\n6.3 Unterscheidung zwischen Refactoring, Reengineering und Rewriting\n6.4 Testgetriebene Entwicklung (TDD)\nUnerwartete Veränderungen gezielt handhaben,\nVortrag auf der OOP 2011\nKlaus Pohl, Chris Rupp,\nATAM - Architecture Tradeoff Analysis Method (Software Engineering Institute)\nBuilding bug-free O-O software: An introduction to Design by Contract (Eiffel Software)\nDbC - Design by contract (Wikipedia)\nSAAM - Software Architecture Analysis Method (Wikipedia)\nSeparation of concerns (Aspiring Craftsman)\nTAOSAD: The Aspect-Oriented Software Architecture Design Portal\nTDD: Test driven development (Wikipedia)\nTop2 Begriffe und Abkürzungen\n"key performance indicator", Leistungskennzahl\ntest driven development, testgetriebene Entwicklung\n"unique selling proposition", Alleinstellungsmerkmal\nTop3 Einleitung und Überblick\nEine zukunftsfähige SW-Architektur sollte die innerhalb der Lebenszeit der SW zu erwartenden Änderungen und Erweiterungen bereits in ihrem grundlegenden Design konzeptuell berücksichtigen. Bei aller Weitsicht lässt es sich jedoch nicht vermeiden, dass für ein langlebiges SW-Produkt auch unerwartete neue Anforderungen und Teilaspekte hinzukommen, die bei der ursprünglichen Konzeption noch nicht betrachtet wurden.\nUnerwartete und erwartete Änderungen werden prinzipiell gleich behandelt. Der Hauptunterschied liegt darin, dass ein System auf die Umsetzung bereits erwarteter Änderungen (hoffentlich) besser vorbereitet ist als auf die Realisierung völlig unerwarteter Änderungen.\nTop3.1 Typische Auslöser für (unerwartete) neue Anforderungen\ndringender Bedarf beim Kunden\nnotwendiges "Mithalten" mit neuen Features der Wettbewerber\nErschliessen neuer Märkte, die andere Erwartungen an das Produkt stellen\nneue Technologie-Standards, z.B. GUI, cloud computing\nunerwartete Beschränkungen aufgrund der gewählten SW-Architektur, deren Folgen sich erst im Lauf der Entwicklung zeigen\nTop3.2 Eigenschaften von Änderungen\nÄnderungen können immer erforderlich werden:\nwährend der Entwicklung, z.B. ausgelöst durch größeres Detailwissen\nIn der Betriebs- und Wartungsphase durch Änderungen im umgebenden System/Markt\nJe länger ein System in Betrieb ist, desto höher ist die Wahrscheinlichkeit, dass unerwartete Änderungen auftreten. Der Zeitpunkt und der betroffene Aspekt des Systems können mit steigender Lebensdauer des Systems umso schwieriger vorhergesagt werden.\nJe später eine Änderung in einem System berücksichtigt wird, desto sorgfältiger muss darauf geachtet werden, im Änderungsprozess den Wert des bestehenden Systems zu erhalten\nEin Aufschieben notwendiger Änderungen ist nicht empfehlenswert, da die Schwierigkeiten zu einem späteren Zeitpunkt eher zunehmen.\nTop3.3 Vorbereitung und Durchführung von Änderungen an einem bestehenden System\nNotwendig: Kosten/Nutzenanalyse, Abwägung der (wirtschaftlichen und technischen) Vor- und Nachteile einer Änderung, Betrachtung der Kosten für den gesamten Lebenszyklus des Systems, nicht nur die momentan anfallenden Entwicklungskosten, Durchführung von Analysen zur Entscheidungsfindung (z.B. Commonality/Variability Analysis, Feature Models, siehe Software Product Line Engineering with Feature Models)\nReviews der Architektur ("Architekturtests") sollten Teil der regulären Qualitätssicherung sein. Dies ist Aufgabe für SW-Architekten und Modulverantwortliche.\noberstes Ziel ist die Verständlichkeit der Architektur, allzu generische Lösungen sind eher zu meiden\nNicht erwünscht: Zerstörung der erreichten Design- und Code-Qualität\nZiel: möglichst lokale Umsetzung der Änderung, unerwünschte Seiteneffekte sollen vermieden werden\nErhalt der Fähigkeit, zukünftige Änderungen einzubauen\nFreiheitsgrade sinken mit zunehmener Zahl an Veränderungen, deshalb die wichtigsten Änderungen zuerst durchführen\nTop3.4 Gliederung der nachfolgenden Kapitel\nAbschnitt 4 beschreibt eine Auswahl bewährter Verfahren zur Beurteilung anstehender Änderungen. Ziel dabei ist es, eine wohlbegründete Entscheidung für oder gegen die Realisierung einer Anforderung treffen zu können.\nAbschnitt 5 beschreibt Merkmale von SW-Architekturen, die spätere Erweiterungen und Anpassungen erleichtern.\nAbschnitt 6 gibt einen Überblick, wie Änderungen in ein bestehendes System eingebracht werden können.\nTop4 Bewertung von Anforderungen/Änderungen\nAls Vorbereitung für eine Entscheidungsfindung ist eine Bewertung unterschiedlicher Aspekte erforderlich.\nWird in ausreichendem Maße zusätzliches Geschäft generiert durch die geplante Änderung?\nWie hoch ist der geschäftliche Verlust, wenn die Anforderung nicht umgesetzt wird?\nBewertung der Auswirkung auf die bestehende Architektur / das bestehende System\nKann die Anforderung unter Beibehaltung der bestehenden grundlegenden Architektur/Systemstruktur umgesetzt werden?\nBesteht die Gefahr, dass die Qualitäten des bestehenden Kernsystem (= vorhandenes Investment) beeinträchtigt werden, wenn die Anforderung umgesetzt wird?\nAbschätzung der erforderlichen Entwicklungskosten\nEs ist Aufgabe des Projektmanagements Anforderungen zu bewerten, um so eine wohlbegründete, dokumentierte und nachvollziehbare Entscheidungsfindung zu gewährleisten. Es ist aber auch Aufgabe des verantwortlichen SW-Architekten, sich Kenntnis über die Entscheidungsabläufe zu verschaffen und diese ggf. nachzufordern. Nur so ist sichergestellt, dass sich das System in diejenige Richtung entwickelt, die auch von allen Beteiligten getragen wird.\nDie Entscheidung für oder gegen eine Änderung beruht dabei i.d.R. auf der Abwägung der (wirtschaftlich bewerteten) Kosten und Nutzen. Nur in Ausnahmefällen sollte eine "strategische" Entscheidung zu einer Änderung führen, die nicht einen entsprechendem (unmittelbaren) geschäftlichen Vorteil nach sich zieht.\nDie unterschiedlichen Stakeholder verfolgen dabei ihre jeweils eigenen Interessen (Marketing: Flyer, Verkaufsprospekte; SW-Architekt: technische Auswirkungen auf das System). Wichtig für die Abstimmung und Entscheidungsfindung ist es, eine für alle Stakeholder gleichermassen verständliche Darstellung des Systems und der zu diskutierenden Anforderungen zu finden.\nIm nachfolgenden wird eine Reihe von Vorgehensweisen zur Bewertung möglicher Änderungen und umzusetzender Anforderungen vorgestellt.\nTop4.1 Requirement Trees\nÜber das Modell eines Anforderungsbaumes (requirement tree) werden bewertete Anforderungen in hierarchische Beziehung zueinander und zu den zugehörigen Konstrukten in der SW-Architektur gesetzt. Die Bewertung erfolgt im Hinblick darauf, wieviel der Kunde bereit ist, für das jeweils betrachtete Merkmal zu bezahlen.\nEntsprechend den verschiedenen Hierarchieebenen betrachtet man dabei:\nProblemraum mit nach dem Geschäftserfolg bewerteten Anforderungen\nWozu wird das System entwickelt? Was sind die geschäftlichen Hauptziele?\nExplizite Kunden-Anforderungen (user requirements):\nWas fordern die Anwender? Wie wird das System von den Anwendern eingesetzt?\nAbgeleitete System-Merkmale (system requirements):\nWie gut muss die geforderte Funktionalität umgesetzt werden?\nLösungsraum mit Zuordnung zu den Requirements\nEinzelne Teilsysteme der SW-Architektur werden in Beziehung zu den Systemrequirements gesetzt, die sie umsetzen.\nBeurteilung geplanter Änderungen\nÄnderungen, die wichtige Geschäftsfaktoren (business drivers), Leistungskennzahlen (KPIs, key performance indicators) oder Alleinstellungsmerkmale (USPs, unique selling propositions) unterstützen, tragen wesentlich zum Geschäftserfolg bei.\nÄnderungen im Lösungsraum / in der SW-Architektur, die wenig zu den wesentlichen Erfolgsfaktoren (d.h. zu den hoch bewerteten Anforderungen) beitragen, haben dagegen auch keine besondere Auswirkung auf den Geschäftserfolg.\nTop4.2 Kategorisierung von Anforderungen nach dem Kano-Modell\nDas Kano-Modell ist ein Bewertungsmodell zur Einordnung von Kundenwünschen. Es wurde entwickelt von Noriaki Kano, Universität Tokio.\nPrinzip: Durch Interviews oder Fragebögen werden die Kundenanforderungen in mehrere Klassen eingeteilt:\nZur Beurteilung der Relevanz von Änderungen sind insbesondere folgende Klassen interessant:\nBegeisterungs-Merkmale ("delighters", "exciters", nicht bekannte Anforderungen),\neine kleine Leistungssteigerung im Bereich dieser Merkmale führt zu einer großen Steigerung des geschäftlichen Nutzens\nunerwartete Eigenschaften, die das Produkt gegenüber der Konkurrenz auszeichnen und die beim Kunden Begeisterung auslösen\nunterstützen oder schaffen ein Alleinstellungsmerkmal (USP, unique selling proposition) auf dem Markt\nstärken allgemein die Marktposition\nLeistungs-Merkmale ("satisfiers", bewusste Anforderungen)\nwerden vom Kunden explizit gefordert, die Zufriedenheit steigt proportional zum Erfüllungsgrad der Leistungsmerkmale\nBasis-Merkmale ("dissatisfiers", unbewusste Anforderungen)\nimplizite Erwartungen des Kunden, die erst bei Nichtvorhandensein auffallen; um Unzufriedenheit zu vermeiden, müssen diese Merkmale vollständig erfüllt werden. Eine Leistungssteigerung in diesem Bereich führt aber nur zu einer minimalen Erhöhung des geschäftlichen Nutzens.\nEin völliges Fehlen dieser Eigenschaften führt aber zu geschäftlichem Verlust:\nBeeinträchtigung des Produktimages\nKonkurrenz kann durch die Umsetzung dieser Merkmale leicht "davonziehen"\nSchwächung der Markpositionierung\nAchtung: implizite Erwartungen werden oft nicht formuliert, dadurch Gefahr des Vergessens!\nDarüberhinaus gibt es noch folgende Klassen von Anforderungen:\nunerhebliche Merkmale (indifferent):\nDie Kundenzufriedenheit ist unabhängig vom Vorhandensein dieser Merkmale\nführen bei Vorhandensein zu Unzufriedenheit\nDie Kategorisierung der Anforderungen ändert sich mit der Zeit:\nAus Begeisterungsfaktoren werden Leistungsmerkmale und schliesslich Basis-Merkmale. Was den Kunden früher begeistert hat, nimmt er zunehmend als selbstverständlich hin.\nTop4.3 Software Architecture Analysis Method (SAAM)\nUntersuchung der qualitativen Eigenschaften einer SW-Architektur: Modifizierbarkeit, Erweiterbarkeit, Portierbarkeit, Performanz\nBeurteilung des Funktionsumfangs einer SW-Architektur, dabei Aufdeckung problematischer Situationen:\neine Komponente realisiert viele Szenarios\nein Szenario betrifft sehr viele Systemkomponenten\n(1) Erhebung von Szenarios\nalle Projektbeteiligten (Stakeholder) erstellen gemeinsam eine Beschreibung der verschiedenen Tätigkeiten, die das System unterstützen soll bzw. bereits unterstützt.\njedes Szenario beschreibt eine konkrete Interaktion eines Stakeholders (User, Tester, Developer) mit dem System bzw. mit bestimmten Teilkomponenten des Systems\njedes Szenario enthält eine Beschreibung des Stimulus, der Systemumgebung und der erwarteten messbaren Reaktionen des Systems\nfür alle Beteiligten verständliche Beschreibung der Komponenten/Datenelemente, ihrer Beziehungen zueinander und des Systemverhaltens.\nDie Schritte 1 und 2 werden iterativ ausgeführt: Eine Detaillierung der Architekturbeschreibung kann neue Szenarios anregen, neue Szenarios führen zu einer Erweiterung der Architekturbeschreibung.\n(3) Klassifikation und Priorisierung der Szenarios\nUnterscheidung nach direkten Szenarios (Umsetzung mit bestehender Architektur möglich) und indirekten Szenarios (erfordern Änderungen der Architektur)\nVergabe von Prioritäten an die Szenarios entsprechend ihrer geschäftlichen Relevanz, nur die wichtigsten 30% werden im Nachfolgenden näher untersucht\nZuordnung eines Szenarios auf die betroffenen Elemente der Architektur bzw. Identifikation notwendiger SW-Änderungen/Erweiterungen\nSchätzung des zugehörigen Änderungsaufwandes\n(5) Untersuchung von Szenariointeraktionen\nIdentifikation unterschiedlicher Szenarios, die an derselben Komponente Änderungen erfordern. Bei funktional nicht zusammengehörigen Szenarios deutet dies auf eine ungünstige Architekturgliederung hin ggf. auf weiteren Detaillierungsbedarf für die Architekturbeschreibung (Schritt 2)\nGewichtung der bewerteten Szenarios.\nVerbesserung der bestehenden Architekturdokumentation (sofern diese nicht zur Bewertung der Auswirkung geplanter Änderungen bereits ausreicht)\nVerbesserung der Kommunikation zwischen den Projektbeteiligten. Die zugrunde liegende Architekturbeschreibung muss für alle Beteiligten verständlich sein\nWeiterverwendung der erstellten Szenarios als wertvolle Abnahme- und Testkriterien\nTop4.4 Architecture Tradeoff Analysis Method (ATAM)\nErweiterung von SAAM um geschäftsrelevante Aspekte, Betrachtung von Qualitätszielen, frühzeitige Identifikation von Risiken, Abwägen des Schadens/Nutzens einer geplanten Änderung.\nAnalyse von Szenarios und der zugehörigen notwendigen Architektur- Entscheidungen, dabei Klassifikation nach:\nIdentifizierte Schwachpunkte im Design, Umsetzung eines betrachteten Szenarios führt zur Beeinträchtigung erwünschter Architektureigenschaften oder zur Verminderung der Fähigkeit, andere Szenarios zu erfüllen.\nIdentifizierte Schwachpunkte im Design, die bei einem Szenario auftreten.\nRisikolose Aspekte. Die Szenarios und zugehörigen Architekturentscheidungen sind ohne Probleme umsetzbar.\nDie Szenarios und zugehörigen Architekturentscheidungen stellen ein Risiko dar. Zur Verminderung der Risiken sind ggf. Änderungen der geschäftlichen Ziele und damit der Szenario-Anforderungen bzw. Korrekturen an der SW-Architektur erforderlich.\nTop4.5 Effort-Impact Grid Analysis\nGrundforderung: für ein neues Feature / eine anstehende Änderung soll der erwartete geschäftliche Nutzen deutlich größer sein als die aufzuwendenden Kosten. Die zu betrachtenden Kosten müssen dabei den gesamten Lebenszyklus des Systems betrachten: Entwicklung, Wartung, Update im Feld.\nDie Gitterdarstellung setzt Kosten und Nutzen zueinander in Beziehung. Mit der Positionierung einer geplanten Änderung im Gitter erhält man eine erste Entscheidungshilfe für oder gegen die Änderung.\nAls Ergebnis der gesamten Analyse erhält man als Grundlage für die Release-Planung:\nPriorisierte Liste der geplanten Änderungen\nvorrangig Änderungen, die mit kleinem Aufwand großen Nutzen bringen\nÄnderungen mit kleinem Nutzen bei kleinem Aufwand eher zur späteren Umsetzung vorsehen\nÄnderungen mit großem Aufwand und großem Nutzen bedürfen ggf. einer strategischen Entscheidung, wann sie umgesetzt werden\nListe der abgelehnten Änderungen\nÄnderungen, die bei hohem Aufwand nur einen geringen geschäftlichen Nutzen bringen, werden abgelehnt. Nur in Ausnahmefällen (z.B. langfristige strategische Planung und Bezug zu anderen Zielsetzungen) werden sie umgesetzt.\nTop5 Vorbereitung einer SW-Architektur auf Änderungen\nArchitektur = "everything that is costly to change"\nBeispiel aus der klassischen Architektur (Stewart Brand: "How Buildings Learn: What Happens After They're Built")\nnur sehr wenige Gebäude können an veränderte Umgebungsbedingugen und veränderte Nutzungszwecke angepasst werden.\nlanglebige "alte" Architektur (z.B. Klöster) wird bis heute laufend an veränderte Einsatzzwecke (Kloster, Lazarett, Lager, Schulungszentrum) angepasst.\nManch moderne Hochhaus-Architektur ist dagegen sehr kurzlebig und bereits nach wenigen Jahrzehnten nicht mehr zu gebrauchen.\nWas ist das Kennzeichen langlebiger Architektur?\nDie bestehenden Eigenschaften und Qualitätsmerkmale einer Architektur sollen beim Umsetzen neuer Anforderungen erhalten bleiben.\nDas Entwicklungsteam soll während des Änderungsprozesses die Kontrolle behalten. Dazu gehört auch die Entscheidungsfreiheit über Zeitpunkt und Ort der Änderung.\nVermeidung von "rippling effects": eine Änderung an einer Stelle zieht eine Reihe nachfolgender Änderungen nach sich, die Änderungswelle pflanzt sich durch das ganze System fort\nVermeidung von "shotgun surgeries": Um die neue Anforderung umzusetzen, sind Änderungen an vielen Stellen des Systems notwendig.\nhäufiges Prinzip: Begrenzung der Variabilität, dadurch Sicherung des bisher Erreichten\nEine gut gewählte Architektur erhöht die Chance, dass kommende Änderungen gut im bestehenden System umgesetzt werden können. Im Folgenden werden wichtige Architektur-Eigenschaften und Entwurfsmethoden aufgeführt, die die Änderbarkeit unterstützen.\nTop5.1 Expressive modularization\nDie Komponenten der SW-Architektur sollen sowohl die Grundstrukturen als auch die Details des tatsächlichen Systems widerspiegeln.\nKomponenten, Interfaces und ihre Beziehungen sollten ausdrucksstarke Namen aus der Anwendungsdomäne erhalten.\nKomponenten sollten eindeutige Verantwortlichkeiten besitzen.\nJede Komponente sollte nur eine Verantwortung besitzen (jedenfalls nicht mehr als 3).\nTipp: als Entwurfshilfsmittel CRC-Karten verwenden, die nur wenig Platz zum Anhäufen von Verantwortlichkeiten bieten und somit die Definition weiterer Klassen/Komponenten fördern.\nEine Komponente sollte mehr tun als nur zu delegieren, d.h. nur andere Komponenten aufzurufen\nBeziehungen zu anderen Komponenten explizit definieren\nNeue Anforderungen sollten möglichst lokal implementiert werden können\nDie beschriebenen Merkmale erhöhen die Wahrscheinlichkeit, dass Änderungen innerhalb einer Komponente bleiben.\nTop5.2 Design by contract (DbC)\nBei der Spezifikation von Schnittstellen wird nicht nur die statische Struktur (Methodensignatur) festgelegt, sondern es wird auch die Semantik und das Verhalten über formale Verträge (contracts) spezifiziert.\nFür jede Methode wird festgelegt:\nZusicherungen, die der Aufrufer einzuhalten hat\nZusicherungen, die der Aufgerufene sicherstellt\nrelevante Eigenschaften des Systems, die durch den Methodenaufruf nicht verändert werden\nDiese Festlegungen sind Teil der Methodenspezifikation.\nUm das Einhalten des Vertrages im Sinne einer defensiven Programmierung sicherzustellen, ist folgende Vorgehensweise empfehlenswert:\nöffentliche Methoden (Aufruf durch andere Komponenten) überprüfen im regulären Produktivcode das Einhalten der Vorbedingungen und geben bei Nichteinhalten einen Fehler ( z.B. Exception) zurück.\nprivate Methoden sichern mit Assertions das Einhalten der Vorbedingungen ab. Durch geeignete Compilerswitches entfallen diese Überprüfungen in der Release-Version, so dass für den Produktivcode kein Overhead entsteht.\nÜberschreiben von Methoden - "principle of subcontracting"\nWird eine Methode in einer abgeleiteten Klasse überschrieben, so müssen nach dem Liskov'schen Substitutionsprinzip alle wesentlichen Eigenschaften der Basisklasse auch in abgeleiteten Klassen erfüllt werden (Vererbung = "ist-ein"-Relation).\nDie Neuimplementierung der Methode ist somit an den Kontrakt der Methode der Basisklasse gebunden. Das bedeutet:\ndie neue Methode darf die Vorbedingungen nicht verschärfen, d.h. vom aufrufenden Code darf nicht mehr verlangt werden\ndie neue Methode darf die Nachbedingungen nicht aufweichen, d.h. sie muss mindestens soviel garantieren wie die Basismethode\nVertragsbruch - Fehlerbehandlung\nKommt es bei der Ausführung einer Methode zu Problemen (HW-Fehler, Fehlschlagen einer intern aufgerufenen Methode, ...), so sind folgende Reaktionen möglich:\nEs wird versucht auf alternativem Lösungsweg die gewünschte Funktion mit Einhaltung aller Nachbedingungen und Invarianten auszuführen.\nDie Funktion kann nicht ausgeführt werden. Es werden alle Invarianten wiederhergestellt und die rufende Funktion wird über den Fehlschlag benachrichtigt (z.B. Exception, Fehlercode). Die rufende Funktion muss dann ihrerseits versuchen, das Problem zu lösen.\nWeitere Informationen siehe Building bug-free O-O software: An introduction to Design by Contract (Eiffel Software)\nTop5.3 Separation of Concerns\n"intuitive" Aufteilung der Verantwortlichkeiten auf einzelne Teilsysteme/Komponenten\nexclusivity and singularity of purpose\nJedes Systemelement sollte nur einen einzigen (Haupt)zweck erfüllen. Es sollten keine weiteren Systemelemente für diesen Zweck mitverantwortlich sein.\nleichtere Wartbarkeit, höhere Stabilität:\nÄnderung eines Aspektes betrifft mit höherer Wahrscheinlichkeit nur eine einzige Systemkomponente.\nnatürliche Erweiterungspunkte (extensibility points)\nverbesserte Chancen zur Wiederverwendung\nDa jede Komponente sich auf nur einen Aspekt konzentriert, hat sie auch weniger Abhängigkeiten zu den restlichen Systemteilen und kann leichter auch in anderem Kontext eingesetzt werden.\nIdentifikation von Problemfällen und Zuordnung auf verantwortliche Bereiche/Systemteile/verantwortliche Bearbeiter fällt leichter.\nTop5.3.2 Horizontal Separation\nTypische Gliederung in mehrere Schichten:\nBenutzeroberfläche und ggf. erforderliche Controller-Schichten zur Ansteuerung/Versorgung der GUI, die gewährleisten, dass tieferliegende Schichten unabhängig von den Belangen der Benutzeroberfläche sind.\nenthält die zentrale Applikationslogik\nentweder als herkömmliches objektorientiertes Modell der Domäne aus Objekten mit eingebetteten Daten und zugehörigem Verhalten\noder aus speziellen Komponenten, die den Workflow, die Geschäftsprozesse und zugehörige "entities" repräsentieren\nabstrahiert den Zugriff auf externe Informationen und Daten, ist verantwortlich für das genaue Datenformat\nTop5.3.3 Vertical Separation\nAuftrennung nach Features / Themenbereichen\nGliederung nach der Verantwortung durch unterschiedliche evtl. räumlich getrennte Entwicklungsteams\nInnerhalb einer vertikalen Schicht ist zusätzlich eine horizontale Schichtung (presentation/business/ resource access layer) möglich und sinnvoll\nTop5.3.4 Aspect Separation - aspektorientierte Programmierung\nNeben den Kernthemen einer Applikation, die z.B. unterschiedlichen Schichten zugeordnet sind, gibt es oft eine Reihe von Querschnittsthemen ("Aspekten"), die mehrere Systemteile/Schichten/Objekte betreffen. Mit der Separierung dieser Aspekte von den Kernthemen können beide Bereiche unabhängig voneinander geändert werden. Beispiel für einen Aspekt: Logging, Tracing.\nEs gibt verschiedene Vorgehensweisen um die separierten Aspekte mit der Applikationslogik zu "verweben" (weaving): Präprozessor, Compiler, Runtime-Verknüpfung. Es gibt Programmiersprachen und Tools, die aspektorientiertes Programmieren direkt unterstützen.\nWeitere Informationen zu Aspect Separation siehe Taosad: Aspect-Oriented Software Development\nWeitere Informationen zu Separation of Concerns siehe separation of concerns (Aspiring Craftsman)\nAbhängigkeiten sollten stets von spezifischen Komponenten zu generischen Komponenten verlaufen und nicht umgekehrt. Auf diese Weise können die allgemeineren Komponenten leichter wiederverwendet werden.\nEine bestimmte (Teil-)Aufgabe wird an eine untergeordnete Komponente delegiert, die spezifische technische Details berücksichtigt, die von der jeweiligen Anwendungssituation abhängen können (z.B. Datenformat). Mögliche Umsetzung: Strategie-Pattern.\nInverting concerns - Inversion of Control\nEin Teilaspekt einer Funktionalität wird nach "aussen" verlagert.\nBeispiel:Template Method: Verallgemeinertes Verhalten wird in der Basisklasse in einer sogenannten Template-Methode realisiert. Abgeleitete Klassen erlauben Variation des Verhaltens durch Überschreiben der in der Template-Methode aufgerufenen Funktionen.\nUm mögliche Schwachstellen eines Designs hinsichtlich der Skalierbarkeit oder Wiederverwendbarkeit besser erkennen zu können, wird probehalber angenommen, dass die Zahl der angeschlossenen externen Systeme/Nutzer wesentlich größer wird, als momentan gefordert. Aus den resultierenden Auswirkungen auf das bestehende Design zur Umsetzung der hypothetischen Anforderung, können ggf. falsch zugeordnete Verantwortlichkeiten besser erkannt werden.\nAus der Anwendung der Prinzipien der "separation of concerns" resultiert zunächst gegenüber der simplen und direkten Umsetzung der augenblicklichen Domänen-Anforderungen eine gewisse Komplexitätssteigerung. Betrachtet man jedoch einen längeren Zeithorizont, so handelt es sich dabei um "geordnete" Komplexität gegenüber einer eher "ungeordneten" Komplexität, wie sie in unstrukturierteren Systemen durch laufende Änderungen zwangsweise entsteht.\nTop5.4 Layering for change\nNeben der Gliederung nach verschiedenen Abstraktionsebenen kann auch eine Gliederung nach den erwarteten Änderungsraten (rate of change) sinnvoll sein. Beispiele:\nGUI wird ständig modernisiert (WEB, WEB 3.0), die zugrunde liegende Applikationslogik bleibt erhalten.\nTrennung von Geschäftsprozessen und Geschäftsobjekten. Motivation: Prozesse können sich ändern, Daten/Objekte sind oft wesentlich längerlebig als das System, das sie verwendet/erzeugt und müssen vor Veränderung daher mehr geschützt werden.\nDatenbank-Schicht: Das Speicherformat / die verwendete Datenbank kann sich ändern.\nEine Verbindungsschicht zu externen Systemen verkapselt Änderungen in deren spezifischen Schnittstellen.\nEine Schicht zur Verkapselung betriebssystem-spezifischer Ansteuerungen erleichtert die Portierbarkeit.\nOpen-Source-SW kann in einem eigenen Layer vom restlichen System separiert werden\nJede Komponente besitzt eine Konfigurationsschnittstelle\nLebenszyklusmodell für alle Komponenten: Hochfahren, Initialisierung, In-Betrieb-gehen, Ausser-Betrieb-gehen, Herunterfahren, ...\nKonfigurations-Rahmensystem, das die Einbindung geänderter/neuer Komponenten auf generische Weise unterstützt\nvon Bedeutung insbesondere für Produktplattformen und -Linien\nWichtiger Aspekt: Änderung auf die Strasse / zu den Kunden bringen\nzeitlich gestreckte Upgrades: zunächst nur einige Systeme upgraden, dann prüfen ob alles funktioniert, danach weiterer Upgrade, Ziel: Begrenzung eines durch die Änderung ausgelösten wirtschaftlichen Schadens\nhäufiges Requirement: Upgrade im laufenden Betrieb (z.B. zu realisieren durch Herunterfahren der alten Teilkomponente und Hochfahren der neuen Teilkomponente)\nTop5.6 Open/Closed Principle\nDas Design eines SW-Systems muß von Anfang an berücksichtigen, dass über einen längeren Entwicklungs- und Wartungszeitraum hinweg, immer wieder neue Funktionalitäten ergänzt werden müssen. Nach dem open/closed-Prinzip sollte eine SW-Komponente (Klasse, Modul) dabei so konzipiert werden, dass sie offen für Erweiterungen ist und gleichzeitig möglichst abgeschlossen für Modifikationen.\nbestehender Code ist bereits getestet und hat sich im Einsatz bewährt\nÄnderungen/Erweiterungen sollen möglichst geringe Auswirkungen auf bestehenden Code haben, dadurch Begrenzung des Risikos unerwünschter Seiteneffekte, Sicherung der bereits erbrachten Investitionen und erreichten Qualitätseigenschaften des Systems\nneue Funktionalität durch Erstellung neuer Klassen\nAbleiten von einer Basisklasse (Implementierungs-Vererbung), Modifikationen werden dann in der abgeleiteten Klasse umgesetzt, grundlegende Algorithmen sind in der Basisklasse vorgegeben und können nur eingeschränkt variiert werden\nAbleiten von abstrakten Interfaces (Schnittstellenvererbung), neue Implementierungen sind an die Semantik der bestehenden Schnittstelle gebunden\nOpen-Close-Principle (OO Design)\nOpen/closed principle (Wikipedia)\nTop5.7 Eingebaute Änderungs-Mechanismen\nDas Verhalten eines SW-Systems kann zumindest in Teilen durch das Interpretieren von extern änderbaren Scripts (z.B. XML) zur Laufzeit beeinflusst werden.\ngrößte Freiheit hinsichtlich Änderbarkeit: gewünschte Änderungen werden ausserhalb des SW-Systems in Scripts formuliert\nSW muß nicht geändert/angepasst werden\nmöglicher Verlust an Kontrolle und Sicherheit, da Abläufe ohne Einflussnahme durch SW-Architekten variiert/abgeändert werden können\nDie spezifischen Einstellmöglichkeiten für Geräte der Fertigungs- und Prozessautomatisierung können in der EDDL (electronic device description language) formuliert werden. Anstatt für jedes Gerät spezifische SW zu schreiben, kann die steuernde SW allgemeiner gehalten werden, indem sie die spezifischen Gerätebeschreibungen zur Laufzeit interpretiert.\nsiehe auch Wikipedia-EDDL\nTop5.7.2 Stable design centers - built-in changeability\nfeste, nicht änderbare Codierung des SW-Kernsystems\nexplizite Erweiterungspunkte (extension hooks) für die erforderliche Variation des Verhaltens vorsehen\nalle variablen Aspekte als Objekte anlegen, die in das Kernsystem "eingesteckt" werden können\nzusätzlicher Schutz vor den Interna durch Verwendung abstrakter Interfaces für alle Beziehungen zum Kernsystem\ntypischerweise werden bei der Realisierung Patterns verwendet (z.B. Visitor, Iterator, Strategy)\nTop5.7.3 Generative Ansätze: MDSD, AOSD\nLösungen werden in domänenspezifischen Modellen umgesetzt\naus den Modellen wird der Code erst generiert\nggf. ausführbare/validierbare/simulierbare Modelle zur Absicherung durchgeführter Änderungen\ngeeignet für eher größere Änderungsintervalle\nModellgetriebene Softwareentwicklung / model driven sw development (Wikipedia)\nAspect-Oriented Software Development (TAOSAD)\nTop6 Umsetzung von (unerwarteten) Änderungen\nTop6.1 Sicherung des bisher Erreichten\nInsbesondere wenn (unerwartete) Änderungen/Requirements sehr spät im Lebenszyklus eines Produktes umgesetzt werden müssen, sollten folgende Aspekte stets beachtet werden:\nErhalt der positiven Architektur-Eigenschaften\nUnbedingt vermeiden: Einführung beliebiger zusätzlicher Beziehungen, die zwar kurzfristig die gewünschten Änderungen erleichtern aber wesentlichen Architekturprinzipien zuwiderlaufen.\nErhalt der bereits erreichten Funktions/Systemqualitäten\nDie Einführung eines neuen Features oder Änderung eines bestehenden Features sollte möglichst keine negativen Auswirkungen auf andere bereits erreichte und bewährte Funktionsmerkmale und Systemeigenschaften haben.\nAbsicherung durch Planung und Reviews (change-scenario driven)\nÜberprüfung und Anpassung der Teststrategie hinsichtlich der geplanten Änderungen für Unit-, Regressions- und Systemtests\nReviews für Code, Architektur und Test im Hinblick auf die geplanten / bereits durchgeführten Änderungen\nKundensicht: Eine Migration bestehender Systeme auf die neu einzuführende Version sollte unterstützt werden.\nDie Kosten für die Migration dürfen nicht den zusätzlichen Nutzen der neuen Version übertreffen\nRückwärtskompatibilität z.B. für Datenmodelle und Scripting gewährleisten, ggf. automatische Konversion anbieten\nEin schrittweiser Upgrade im laufenden Betrieb muss ggf. unterstützt werden. Dabei sind ggf. Komponenten mit unterschiedlichen Versionen parallel in Betrieb.\nTop6.2 Einbettung in die bestehende Architektur\nArchitektur-Änderungen verursachen Kosten (Umfang der Implementierungsarbeiten, resultierende Aufwände für Anpassung/Durchführung von Tests). Aus wirtschaftlichen Gründen sollte also ein möglichst großer Teil des bestehenden Systems erhalten bleiben.\nRealisierung neuer Features als zusätzliche Komponenten und Services, die entsprechend der vorhandenen Komponenten-Infrastruktur in das Gesamtsystem eingebettet werden. Die bestehende Modularisierung bleibt erhalten.\nÄnderung/Erweiterung bestehender Komponenten, falls die Änderung in natürlicher Weise die Komponente erweitert, ohne die bestehenden Beziehungen zwischen den Komponenten zu beeinträchtigen.\nWichtige Erweiterungen, die nicht mit der bestehenden Architektur realisiert werden können, sollten einen möglichst großen Teil der bestehenden Architektur erhalten und die notwendigen Anpassungen über Refactoring/Reenginering und notfalls Rewriting durchführen (siehe unten).\nTop6.3 Unterscheidung zwischen Refactoring, Reengineering und Rewriting\nHauptziel: Verbesserung der internen Struktur\nVereinfachung, Lesbarkeit, Wartbarkeit, Erweiterbarkeit, Fehlerkorrekturen\nNicht ändern: externe Schnittstellen\nSchnittstellen, Semantik und funktionales Verhalten einer System-Komponente nach aussen bleiben erhalten\nFolge: nach aussen hin nicht sichtbar\nEine Beeinflussung anderer Systemteile ist damit ausgeschlossen\ndient ggf. als Vorbereitung nachfolgender größerer Änderungen\nEmpfehlung: ständig durchführen\nkontinuierliche Maßnahme zur Erhaltung bzw. Steigerung der Code-Qualität\nHilfreich: bestehende (automatisierte) Testfälle\nAbsicherung der Bereinigungsmassnahmen. Es sind keine zusätzlichen Testfälle notwendig, da bei diesem Verfahren keine funktionalen Änderungen zugelassen sind.\nHauptziel: bevorzugte Methode für die Umsetzung neuer Anforderungen\nWichtig: Beibehaltung der Grundstruktur\nAnalyse und Überarbeitung der bestehenden System-Komponenten und ihrer Beziehungen zueinander.\nVerbesserung der internen Struktur (wie bei Refactoring)\nFür funktionale Erweiterungen und zur Verbesserung der Code-Qualität bzw. des allgemeinen Systemverhaltens:\nVeränderung der Semantik, Ergänzung von Neuem, dabei aber Beibehaltung der Grundstruktur\nFolge: ist nach aussen sichtbar\nErforderlich: Zusatzaufwand für Qualitätssicherung\nEigenschaften und Qualität des Alt-Systems sollen erhalten bleiben.\nfür neue Funktionalitäten sind neue Testfälle erforderlich\nbestehende Testfälle müssen ggf. angepasst werden\nbetroffene/relevante Testfälle identifizieren und durchführen\nHauptziel: Verbesserung der Gesamtstruktur\nMethode: vollständige Ersetzung eines Systems oder einer Gruppe von Teilkomponenten durch neues Design und Implementierung\nVerbesserungen für: Design- und Code-Stabilität, innere und äussere Struktur, allgemeines System-Verhalten\nDurchführung funktionaler Erweiterungen\nEinschätzung: sehr risikoreich\nGefahr: Aufwand (Zeit, Kosten) kann wesentlich höher sein als der Nutzen aus dem resultierenden Funktionszuwachs\nhoher Qualitätssicherungsbedarf, neue Teststrategien erforderlich\nkonservatives, abgesichertes Vorgehen notwendig\nEmpfehlung: nur durchführen, wenn Refactoring/Reengineering zur Umsetzung von Anforderungen nicht ausreichen\nIndizien für notwendiges und lohnendes Rewriting:\nBehebung eines Fehlers verursacht häufig mehrere Folgefehler\nIn der Realität wird zur Realisierung von anstehenden Änderungen häufig eine Kombination der drei Vorgehensweisen eingesetzt. Unter Umständen ist es dabei sinnvoller eine geforderte Funktionalität mit Hilfe von Reengineering nur teilweise umzusetzen, wenn dafür das risikoreichere und i.d.R. kostenintensivere Rewriting vermieden werden kann.\nTop6.4 Testgetriebene Entwicklung (TDD)\nIn der testgetriebenen Entwicklung werden automatisierte Tests als Grundlage der SW-Entwicklung eingesetzt. TDD (test driven development) ist aber mehr als eine Anleitung zum Schreiben von Tests. TDD wurde ursprünglich als Teil der agilen Methode "eXtreme Programming" (Kent Beck) konzipiert und stellt eine vollständige Entwicklungs-Methode zur Erstellung von Software dar.\nPrinzipien der Durchführung\n"Write the test first"\nZunächst wird der Testfall für die neue Funktionalität geschrieben. Beabsichtiger Effekt: Entwickler muss sich mit den Requirements und deren Nachweisbarkeit beschäftigen, bevor er die Änderung umsetzt.\n"First fail the test cases"\nWiederholung aller Tests. Der neue Test muss fehlschlagen, falls er die neue, noch fehlende Funktionalität tatsächlich nachweisen kann. Die unveränderten Testfälle müssen erfolgreich durchlaufen werden\nErgänzung von gerade soviel Code, dass der neue/geänderte Testfall klappt\nBerücksichtigung von Fehlerfällen\nErgänzung weiterer Testfälle, die auch die Fehlerfälle der neuen Funktionalität prüfen und Ergänzung des zugehörigen Quellcodes. Ablauf jeweils entsprechend den Schritten (1) - (3)\nÜberarbeitung der betroffenen/geänderten Codestellen (z.B. insbesondere Beseitigung von Duplikaten). Dabei wird stets nach wenigen Änderungen die automatisierte Testsuite wiederholt. Dadurch ist gewährleistet, dass bei gefundenen Fehlern einfach die letzten Änderungen zurückgenommen oder korrigiert werden können, ohne eine zeitraubende Debug-Session starten zu müssen.\nVorteile der Vorgehensweise\nObwohl zusätzlicher Testcode geschrieben werden muss, wird die benötigte Implementierungszeit bis zur (annähernden) Fehlerfreiheit typischerweise verkürzt. Zeitaufwändiges Debugging kann weitgehend entfallen.\nDa nur soviel Code geschrieben wird, wie zur Erfüllung eines neu erstellten Testfalles notwendig ist, wird tendenziell (fast) jeder Code-Zweig im Rahmen der Tests durchlaufen.\nVermeidung ungewollter Seiteneffekte\nDurch die wachsende Zahl automatisierter Tesfälle werden ungewollte Seiteneffekte auf andere Anwendungsfälle schnell aufgedeckt. Die automatisierten Tests bilden eine Voraussetzung für sicheres Refactoring/Reengineering.\nModularisierter, testbarer Code\nDa der Entwickler gezwungen ist, gleich Testfälle zu erstellen (und dazu ggf. auch entsprechende Mockobjekte der Umgebung realisieren muss), besteht die Tendenz, dass kleinere Module/Klassen mit einfachen Schnittstellen entstehen, die eine Ansteuerung oder Simulation im Test vereinfachen.\n„Usage specification better than documentation“\nDie Testfälle geben wertvolle Hinweise für den Anwender, wie der Code benutzt werden kann. Im Unterschied zur Dokumentation ist der Testfall immer aktuell.\nLee Copeland: Extreme Programming\nLast modified: 30.05.2014 12:08:35, © Gerald Fahrnholz


Kapitel 1 - Erste Annäherungen - Seite 3\nThema: Re: Kapitel 1 - Erste Annäherungen So Mai 03, 2009 11:57 pm\nGivaan hate den selben Gedanken und kaum war dieser verscwunden, schoss der schwarze Wolf nach vorn und jagte einem der letzen Rehe nach. Er blieb dicht an der Flanke des zierlichen Rehs, welöches mühsam versuchte, in die MItte zu fliehen. Doch GIvaan ließ es nciht entkommen, trieb es von der HErde weg, dirket auf Lynn, Tessyra und Zanba zu. "He, nicht ausruhen! Hier kommt noch was!" rief er und seien Augen funkelten boshaft. Mit einem mächtigen Satz hatte er den letzen Abstand zwischen sich udnd em Reh überwunden und ließ seine scharfen Krallen ind ie HInterhand des Tieres fahren. Das Reh sprange rschrocken auf,w urde aber duch Givaans GEwicht wieder herunter gezogen. Er zog sich kräftig nach oben und warf dne drei Fähen einen barschen Blick zu. "Wird wohl mal einer vone uch so beherz sein udn dem Tier die KEhle zerbeißen! Ich komm nämlich nicht ran!" knurrete r und fletschzte seien Zähne. Danach riss er das Reh brutal zu Boden und hoffte, einer der Fähen würde nune ndlich kommen.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 6:55 am\nTessyra wartete garnicht erst.Sie landete vor dem Reh und biss ihm,mit ihren spitzen Zähnen die Kehle durch,bis der Kopf in einem merkwürdigen Winkel vom Hals abging.Etwas Blut von dem Tier floss durch Tess' Zähne.Sie schüttelte den Kopf und das Blut kleckste auf den Boden.Rehe schmeken besser,als Frösche,sagte Tess und schüttelte leicht angewidert den Kopf,als sie an die bittere Froschhaut dachte.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 8:49 am\nGivaan ließ vom Reh ab und nickte. Danach riss er sich ein blutiges Stück aus der Flanke heraus und schlang es gierig hinunter. Danach nicktee r den anderen Wölfen zu, sie würden nun ebenfalls fressen können. "Ich werde mal die Umgebung betrachten!" meinte e rspöttisch udn ließ die drei Fähen fürs erste bei der Beute zurück. DA er zuvor bereits gefressen hatte, war sein Hunger mäßig und so konnte er die UMgebung sichern. NAchdem er alles abgewittert hatte und vorsichtshalber noch einigen alten SPuren nachgegangen war, kehrte e rzurück. "Nichts!" sagte er, sichtlich zufrieden udn beteiliogte sich wieder an der Beute.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 10:16 am\nTess fras vom Hals des Rehes,als ihr eine Idee kam.Anfangs zögerte sie...aber dann: Wenn hier nichs ist,könntet ihr doch hier euer Rudel aufmachen...oder?! unsicher schaute sie jeden an.Sie vergrub ihre Nase wieder in dem Fleisch,um den blicken auszuweichen.Ob es eine blöde Idee war?! fragte sie sich.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 10:47 am\nGivaan sah sie mit undurchdringlichem Blick an. Sie ist jung .. vergiss das nicht. mahntee r sich selbst, doch er fletschte bereits die Zähne. "Hör mal zu! Wir sind zu vier, haben hier ein Reh gerissen und nun sollen wir hier unserRudel aufmachen?!" Givaan knirschte mit den Zähnen, was ein leicht metallisches GEräusch entfachte, doch er beherrschte sich. GAnz ruhig, Giv! Du regst dich doch nur auf, weil du nicht selbst drauf kamst! Der schwarze Wolf holte kurz udn tief Luft, sah Tess, Lynn udn Zan der Reihe nach an. "Wir brauchen Winterquartiere, Wommerquartiere udn natürlich müssen diese LAgerplätze möglichst unfindbar sein." Er blickte sich mit finsterem Blick um udn fragte Tess scharfr "Findest du, dass dieser Ort hier wirklich praktisch ist? Keien Höhle, ziemlich leicht aufzufinden! keinerlei Verstecke für Welpen, Beute und Jungwölfe. Kein Fluss in der Nähe .. ich denke, dass wäre geklärt." Givaan sah sie streng an, und fügte etwas milder hinzu, um Tessyra nicht vollkommen zu verä#ngstigen "Trotzdem: es war mjedenfalls einen Vorschlag wert. Und du musst aj auch noch vieles lernen. Nun friss aber schnell!" Er ließ seinen Blick schweifen und passte auf, dass ncihts nUngeplantes dazwiswchenstieß. Der Lagerplatzvorschlag war für ihn bereits erledigt und vergessen. Givanan lächelte grimmig.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 11:00 am\nTess zog eingeschüchtert den Schwanz ein und senkte den Blick um Givaans gruseligen Augen auszuweichen...War doch eine blöde Idee,dachte sie.Das würde si sich merken,soviel war klar.Keine Vorschläge mehr,Tess!!,mahnte sie sich in gedanken und riss noch ein tück des Rehes hinaus.Dann setzte sie sich hin,noch immer den Blick gesengt...sowas nagte lange an ihr...Sie stellte ihre Ohren nach vorne,als würde sie etwas hören...Muss mich geirrt haben...Aber...?!Na ja,was solls!!,dachte sie.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 12:06 pm\nGivaan, beruhig dich, es war nur ein vorschlag. sagte Zan mit sanfter Stimme. Dann wandte sie sich an Tess. Es dauert nur noch höchstens zwei Tage, mit schlafen, bis wir die Grenze erreicht haben. Dort ist ein Fluss, der leicht zu überqueren ist und der den richtigen Wald eingrenzt. Wir befinden uns noch auf menschlichem Gebiet. Ab dem Fluss darf kein Mensch den Wald betreten. Dort werden wir uns ansiedeln. Wenn wir da sind markieren wir sofort alle Grenzen ud hoffen, dass wir die ersten sind, die dn Urwald erreichen. Sie nahm einen großén happen von dem Fleisch und schluckte es herunter.\nThema: Re: Kapitel 1 - Erste Annäherungen Mo Mai 04, 2009 2:09 pm\nLynn achtete nicht was die anderen sagten, sie war nur auf das ESSEN ficksirt! Sie hatte mal wieder einen Wöfeln hunger. Lynn nagte am hinterbein bis das lezte fleisch von Knoch verschwunden war.\nThema: Re: Kapitel 1 - Erste Annäherungen Di Mai 05, 2009 8:55 am\nGivaan nickte ungehalten und bgrummte mürrisch "Ja,ja!" Nachdem er sich einw eiteres Stück herausgerisen hatte, lecktee r sich über die blutige Schnauze und nieste kurz. "Nun? Alle satt?" fragtee r, nach dem er einen Blick auf das vollkommen abgenagte Reh geworfen hatte. Vielleicht eine gute Prüfung! Wenn sie sich trauen, einem mürrischen, vergramten Wolf zu folgen und dabei denkende Indevidien bleiben, sind sie wirklich gute Wölfe!Givaan musste beinahe kichern, als er seine eigene Definition über sich selbst hörte. Es steigerte seine Laune beträchtlich, und er sah schon etwas freundlicher in die Runde.\nThema: Re: Kapitel 1 - Erste Annäherungen Mi Mai 06, 2009 11:18 am\nZanba bemerkte Givaans plötzlichen Stimmungswechsel und musste leise kichern. Doch dann warf sie einen eher verzweifelten Blick in den Himmel. Es ist schon sehr bald ganz dunkel. Entweder wir ziehen weiter und machen später eine Pause, oder wir suchen uns einen verlassenen Fuchs- oder Dachsbau, den wir ein wenig aushhlen und dort drin schlafen, bis es wieder hell ist. Sie schaute zu der kleinen Lynn. Bist du müde? Oder du, Tess? Obwohl Tess sehr viel mehr aushalten sollte als Lynnn. Immerhin ist zwischen ihnen ein großer Altersunterschied. sagte sie in Gedanken zu sich selbst und wandte sich dann Givaan zu. Und was sagst du dazu? fragte sie.\nThema: Re: Kapitel 1 - Erste Annäherungen Mi Mai 06, 2009 12:41 pm\nLynn gähnte und streckt sich. Sie blinzelte ein paar mal und sagte Also ich könnte schon etwas schlarf gebrauchen. Sie gähnte wieder. Lynn lehnte ihren müden Körper gegen Zanba und gähnte wieder.\nThema: Re: Kapitel 1 - Erste Annäherungen Mi Mai 06, 2009 11:16 pm\nGivaan sah zwischen den drei Fäühen umher, dann wies er mit der Schnauze auf Lynn. "Ich denke, etwas Schlaf wird und allen gut tun! Aber wir sollten lieber nach einer geschützen Höhle oder einem Bau suchen, schließlich könnten wir hier einem Überfall direkt in die Arme laufen" Er sah Tessyra fragend an, dann wand er sich wieder seiner Gefährtin zu. "Nach dir!" meinte er mit einer galanten VErbeugung. Er sschnappte kurz neben Lynns Flanke, um sie wieder zu wecken, knurrte Tess noch mal an und drängte zum Aufbruch. Die Dämmerung war bereits eingetreten und würde immer weiter fortschreiten, wenn sie nicht bald aufbrachen. Und ich will hier nicht überwintern! DAs Rudel gewiss auch nicht!\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 5:57 am\nTess erhob sich.Am liebten hätte sie Givaan zurück angeknurrt,aber das wagte sie nicht.Anscheinend kann er mich nicht leiden...,dachte die junge Fähe.Ihre Nackenhaare kribbelten,als würde jemand im Gebüsch sitzen und sie beobachten.Wie bei der ersten begegnug mit Zanba.Sie stellte dieOhren auf und zog die frische Waldluft ein.Sie konnte nichs außergewöhnliches richen.Verwirrt legte sie den Kopf schief und schaute über die Schulter.Aber sie sah auch nichs.Aber hier ist doch irgendwas!!.Leichter Angstgeruch von ihr lag jetzt in der Luft.Sie schüttelte den Kopf...\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 7:11 am\nGivaan roch es und fragte süffiant "Was denn? Hast du Angst?" Er sah sich kurz um, vergaß zu wittern und machte einen entscheidenden Fehler: er lief los, ohne sich nochmal umzusehen. Langsam begann er loszulaufen, wurde schneller und trieb das kleien Rudel an. "Dort hinten ist ein kleiner See!" meinte er, als er das leise Plätschern vernahm. Wenig später waren sie am See, der von einem kleinen Waserfall gespeist wurde. Gut, um sich fürs Erste bedeckt zu halten! Allerdings auch anchteilig, weil man andere nicht hören kann! Nun ja, dafür sidn wir ja im Rudel! Der schwarze Wolf senkte seinen Kopf und trank etwas von dem klaren, sauberen Wasser. Es rann erfrischend seine trockene Kehle hinab und er seufzte zufrieden. "Nun?" Er wand sich an den Rest der gruppe, der auch langsam ankam und sah fragend in die Runde.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 9:38 am\nZanba sah sich bei dem Wasserfall um. Vorsichtig berührte sie das Wasser mit ihrer PfOTE. Es war eiskalt. Wir müssen dadurch. Hnter dem Wasserfall ist eine Höhle. Hört ihr das? Angestrengt lauschte sie. Ihre Ohren filterten das Geräusch des Wasserfalls aus und sie lauschte nur der Stille, aber da, hinter der Stille, da war ein leises Tropfen. Noch einmal schob sie vorsichtig die Pfote in das eiskalte Wasser. Also los Sie packte Lynn am Genick und setzte sie auf ihren Rücken. Beis dich einfach an meinem Nacken fest, Kleine. Und schon lies sie sich in das kalte Wasser plumpsen, das ihr das Blut gefrieren ließ. Sie paddelte so schnell sie konnte mit allen vier Pfoten um so schnell wie möglich auf die andere Site zu kommen. Halt die Luft an! befahl sie Lynn und stießsich unter die Wassermassen. Mit aller Kraft paddelte sie gegen den druck des Wasserfalls an und endlich tauchte sie auf der anderen Site wieder auf.Mit den Pfoten hielt sie sich am Ufer fest und setzte Lynn vorsichtig auf dem festen Boden ab, dann krabbelte sie selbst aus dem Wasser und schüttelte ihr Fell kräftig aus. Ihr könnt kommen! heulte sie den anderen zu und rolte sich dann wärmend um den kleinen Welpen.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 9:48 am\nGivaan sah Zanba und Lynn nach, dann richtete er seinen dunklen Blick auf Tessyra. "Auf gehts!" sagte er und nickte mit dem Kopf Richtung Wasserfall. NAchdem er die Fähe weniger sanft ins eiskalte Wasser gestoßen hatte, lief der schwarze Wolf ebenfalls hinein und watete so lange, bis seine Brust vollkommen von dem kalten Wasser umspült wurde. Die Kälte biss und betäubte seinen Körper, dennoch tauchte der Wolf ab und schwamm mit kräftigen Zügen durch den See. Seine Luft wurde knapp, Givaans Herzschlag beschleunigte sich und ihm dröhnte der Puls in den Ohren. Dann tauchte er wassertretend auf und schnappte gierig die abgestandene, feuchte Luft. Nachdem er Zanba und Lynn gesehen hatte, schüttelte er sein Fell aus, dass es nur so spüritze. Dann schaute er zurück in das dunkle, geheimnissvole Wasser und wartete darauf, dass Tess nachfolgen würde. Ich hätte nach ihr losschwimmen sollen! schoss es ihm durch den Kopf, sodass er kurz von Gewissensbissen gequält wurde. Ach was ... Tess ist zäh! Sonst ist sie kein MoonWolve! dachte er und schnaubte verächtlich.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 10:18 am\nLynn stand auf und schütelte sich, zitternd kuschelte sie sich wieder an Zanba. Vor müdigkeit fiel es der schneeweiße Wölfin schwer die Augen offen zu halten. Aber sie wollte doch sehen ob alle es in die Höle schaften. Lynn`s Augen schlossen sich. Sie war zu schwach um sich noch länger wach zu halten, sie spürte nur Zanba`s warmen Körper. Lynn war schnell eingeschlarfen...Sie träumte...Sie wäre eine Richtige Wölfin...Groß...Anmutig...Schön...Sie rennt und rennt über eine Blumenwiese. Zanba...Givaan...Tessyra...alle rennen mit ihr, der Wind bläst durch ihr Fell...Die Sonne scheint...Keine Wolken am Himmel...Vögel zwitschern...alles ist Perfekt. Alle rennen...Lynn wierd schneller sie rennt vor...Die anderen schreien ihr etwas hinterher das sie nicht versteht...Und?....Oh nein!....KLIPPE!...Sie fällt...Sie sieht den Boden immer näher kommen...Sie ist gleich so platt wie der Frosch den sie tess geschenkt hat...Sie heult vor angst vor den Boden. Lynn sprang auf und stolperte über Zanba`s Beine. Mit großen Augen sah sie die anderen Wölfe an. Der Schreck hatte sich noch nicht abgeregt. Alles nur ein Albtraum, keine Angst. sagte sie zu sich.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 10:25 am\nTess paddelte durchs Wasser.Am anderen Ufer sah sie Zanba,Lynn und Givaan.In kräftigen Zügen schwamm sie.Sie spürte die kälte auf der Haut und in den Beinen.Sie hatte das gefühl,als würden ihre Beine taub werden und sie würde nicht vorwärtskommen.Sie schloss die Augen und nahm sich vor sie erst wieder zu öffnen,wenn sie am anderen Ufer war.Schließlich hatte sie es geschaft und lag keuchend am anderen Ufer.Sie standt auf und schüttelte ihr grau-braunes Fell.Leiser stolz lag in ihren Augen und zufrieden setzte sie sich hin.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 10:31 am\nGivaan sah Tess regungslos dabei zu, wie sie an Land kletterte. Ein leises GEräcuh bei Zanba ließ ihn herumfahren, doch es war nur Lynn, die schlecht geträumt hate. "Alles gut, Lynn! Wir sind bei dir, niemand wird dir etwas tun!" sagte er leise und wartete, bis die kleine, weiße Wölfin sich wieder einigermaßen beruhigt hatte. Als Tess bei ihnen angelangt war, nicke Givaan kaum merklich, es war froh, dass alle es geschaff hatten. Auch wenn er das nciht offen zeigte. Sein Fell war inzwischen getrocknet und er sah sich um. Die Höhle, in der sie gelandet waren, war eigenlich mehr eine Art natürlicher Tunnel. Givaan seufzte leise, was in den hohen Gewölben gespentisch wiederhallte. "Hier können wir die NAcht verbringen! Ein Fluss, Schutz und der Wasserfal." meinte Givan zufrieden, reckte sich kurz und gähnte. NAchdem er sich erneut ausgeschütelt hatte, legte er sich neben Zanba, den Kopf auf dne großen Pfoten und schloss die Augen Seine Sinne waren geschärft, dennoch döste er leicht ein.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 10:37 am\nTess gähnte.Sie sah sich nochmals um.Ihrte Nackenhaare lagen ruhig.Nichs verdächtiges,dachte die junge Fähe zufrieden.Dann war sie unschlüssig,wo sie sich hinlegen sollte...dann blieb sie einfach da,wo sie war und legte sie auf den Bauch.Ihr Fell war noch nass.Es würde lange dauern,bis es wieder trocken war.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 11:00 am\nZanba kuschelte sich an Givaan und schaute entlang des Ganges. Wohin der wohl führt? murmelte sie und malte sich aus, was am ende des Tunnels alles lauern könnte, und dann erinnerte sie sich. Damals hatten ihr ihre Eltern von diesem Tunnel erzählt. Es war eine Abkürzung. Er führt direkt in den Urwald hinein, dort, wo wir hinwollen! rief sie und zuckte dann vor ihrem eigenen Echo zusmmen. aber ruht euch jetzterste einmal aus, morgen werden wir unser Ziel erreichen, schätze ich. sagte sie wieder etwas ruhiger und legte den Kopf auf ihre Vorderpfoten.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 11:10 am\n( @ all: ich hab jetzt meinen Charabogen noch mal bearbeitet und ein reales Bild genommen. Nur als Hinweis)\nGivaan schlummerte immer tiefer, bis er schließlich in die Welt der träume eintauchte. Unruhig wälzte er sich umher, auf der Flucht vor den Bildern und Erinnerungen. Eine wunderschöne, graue Wölfin, die langsam den Weg zur Höhle einschlägt, nichs ahnend, was sie vorfinden wird. Als sie den Geruch von frischem Blut richt, bekommt sie ein ungutes Gefühl udn wird schneller, bis sie in ihre Höhle hineinrennt. "NEIN!" schreit sie und der schwarze, blutige Welpe dreht ihr den Kopf zu. Givaan ist keine drei Monate alt und hat bereits seine ersten sechs Morde hinter sich. Er hat seine schwächlichen Geschwister getötet. Die graue Wölfin steht erstarrt am EIngang der Höhle und wispert immer nur das gleiche "Was hast du nur getan, Givaan? Sie waren deine Gechwister!" Wenig später taucht ein dunkelbrauner Wolf in der Höhle auf und seien Augen weiten sich ebenfalls. All das Blut, was sich langsam einen Weg aus der Höhle bahnt, die sechs Welpenkörper, regungslos und kalt. Givaans Mutter läuft mit einem lauten, klagenden Heulen aus der Höhle, stolpert mehr, als das sie rennt. Givaan duckt sich ängstlich, er weiß, dass er etwas falsches getan hat, in den Augens einer Eltern, doch für seine GEschwister wäre es sowieso zu spät gewesen. Einige Tage später, der dunkelbraune Wolf meidet Givaan udn die Höhle, kommt ein Botschafter von einem anderen rudel. "Wir haben deine Gefährtin bei den Menschen gesehen." Givaans Vater prescht los und der junge, schwarze Wolf laucht angespann in die NAch. Dann zerreißt ein einzelner Schuss die Stille. Wenig später ertönt das Klagelied seiner Mutter. Givaans Vater wurde erschossen. KNurrend fuhr Givaan auf und blinzelte mehrmals. Die Höhle war stockdunkel, seien Augen leuchteten bedrohlich auf. Er witerte kurz, sein rasendes Herz beruhige sich wieder einigermaßen. Lynn, Zanba udn Tessyr waren noch da, kein blutgeruch oder der eines anderen Tieres. Doch an Schlaf war für ihn nicht merh zu denken. Nervös streift der schwarze Wolf vor dem tunnelrartigen Höhlensystem auf udn ab, denkt erneut über die längst vergessene Geschihte nach. Seufzend setzte er sich auf seien Hinterläufe, starrte zum wolkenverdeckten Mond und heulte ihn leise an.\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 11:31 am\nLynn wurde von dem geheule wach, sie blinzelte um sich. Alle schliefen...oder? Sie preste die Augen zusammen...Ist das nicht Givaan? Oh! Er ist wach! Vosichtig rapelte sie sich auf und schlich zu Givaan. Er hat wohl nicht gut geschlarfen?! Die kleine Wölfin setzte sich neben Givaan und heulte auch den Mond an. Lynn lehnte sich gegen Givaan. Langsam wurde sie wieder müder, sie schloss die Augen und gab schließlich ein Schnarchendes Geräusch von sich...\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 11:44 am\nGivaan hatte ihre kleinen, tapsigen Pfoten gehört und es hingenommen, dass sie mit ihm heulte. Sie teilte unbewusst seine Trauer. Dann schlief sie plötzlch und er blickte erstaut auf die kleine Wölfin. Lass sie schlafen, Giv! Es war ein harter Tag! Givaan sah nachdenklich auf Lynn hinab, die leise und zufrieden schnorchelte. Dann betrachtete er erneut dne Mond und stieß ein dunkles, langgezogenes Heulen aus, was am Ende langsam abebbte. Sie sieht aus wie meien kleine Schwester! Givaan schütelte den Kopf und sah Lynn lächelnd dabei zu, wie sie den Schlaf der gerechten schlief. Wenigstens einer soll es tun könen! Einer sol wenigstens einen friedlichen Schlaf haben!\nThema: Re: Kapitel 1 - Erste Annäherungen Do Mai 07, 2009 12:02 pm\nZan bemerkte das Heulen und schrak auf. Langsam kam sie auf ihren gefährten zu und kuschelte sich an seine Flanke. Da bemerkte sie den schlafenden wollknäuel von lynn, der neben giv laut schnarchte. Ist alles in Ordnung? fragte sie besorgt.