Klaus Turowski (Hrsg.) Modellierung und Spezifikation von Fachkomponenten Workshop im Rahmen der MobIS 2000
Modellierung betrieblicher Informationssysteme Siegen, Deutschland, 12. Oktober 2000 Tagungsband
Veranstalter
Gesellschaft für Informatik
Arbeitskreis 5.10.3
Komponentenorientierte betriebliche Anwendungssysteme
Universit?t Siegen
Wirtschaftsinformatik
Klaus Turowski (Hrsg.) Modellierung und Spezifikation von Fachkomponenten Workshop im Rahmen der MobIS 2000
Modellierung betrieblicher Informationssysteme Siegen, Deutschland, 12. Oktober 2000 Tagungsband
Veranstalter
Gesellschaft für Informatik
Arbeitskreis 5.10.3
Komponentenorientierte betriebliche Anwendungssysteme
Universit?t Siegen
Wirtschaftsinformatik
Tagungsleitung
Dr. Klaus Turowski
Otto-von-Guericke-Universit?t Magdeburg
Institut für Technische und Betriebliche Informationssysteme Arbeitsgruppe Wirtschaftsinformatik
Postfach 4120, 39016 Magdeburg, Deutschland
Tel.:+49 (391) 67 1-83 86E-Mail:turowski@iti.cs.uni-magdeburg.de Fax:+49 (391) 67 1-12 16URL:http://www-wi.cs.uni-magdeburg.de
Programmkomitee
Prof. Dr. S. Conrad
Ludwig-Maximilians-Universit?t München
Prof. Dr. R. Flatscher
Wirtschaftsuniversit?t Wien
Prof. Dr. U. Frank
Universit?t Koblenz-Landau
Prof. Dr. E. Ortner
Universit?t Darmstadt
Prof. Dr. C. Rautenstrauch
Otto-von-Guericke-Universit?t Magdeburg
Prof. Dr. E. Sinz
Universit?t Bamberg
Dr. K. Turowski (Vorsitz)
Otto-von-Guericke-Universit?t Magdeburg
Vorwort
Traditionelle Ingenieurdisziplinen zeichnen sich insbesondere dadurch aus, dass in der Regel verbindliche Standards (bzgl. Notation, Benennung, Bema?ung usw.) zur Spezifikation der jeweiligen Konstruktionsergebnisse vorgegeben sind, die deren (Wieder-)Verwendung verein-fachen. Für wiederverwendbare (Software-)Komponenten ist dies jedoch nur sehr bedingt der Fall. Ausgehend von dieser Problemstellung wurde zur Einreichung von Beitr?gen für den Workshop Modellierung und Spezifikation von Fachkomponenten aufgerufen, die insbesonde-re die folgenden Themen und Fragestellungen aufgreifen:
Wie sind Fachkomponenten zu spezifizieren (Techniken, Methoden, Abstraktions-ebenen usw.)?
Auf welche Standards kann man dazu zurückgreifen?
Ist die formale einer …verbalen“ Spezifikation vorzuziehen?
Vorgehensmodelle/Methodiken.
Werden neue Methoden und Vorgehensmodelle ben?tigt oder k?nnen bereits vor-handene weiter verwendet werden?
(Referenz-)Modellierung von Fachkomponenten.
Erfahrungen mit wiederverwendbaren Komponenten und Architekturen.
Dieser Tagungsband enth?lt die schriftliche Fassung der zu Vortrag und Ver?ffentlichung angenommen Workshopbeitr?ge.
Der Workshop wurde vom Arbeitskreis 5.10.3 Komponentenorientierte betriebliche Anwen-dungssysteme der Gesellschaft für Informatik (GI) im Rahmen der Fachtagung Modellierung betrieblicher Informationssysteme (MobIS) 2000 am 12. Oktober 2000 an der Universit?t Sie-gen veranstaltet.
Aus den Einreichungen wurden fünf Beitr?ge ausgew?hlt, die aktuelle Forschungsergebnisse aus dem Bereich der Wirtschaftsinformatik darstellen oder Erfahrungen aus der betrieblichen Praxis dokumentieren. Jeder der eingereichten Beitr?ge wurde in einem anonymen Begutach-tungsverfahren (double blind) von mindestens zwei Mitgliedern des Programmkomitees be-gutachtet.
Abschlie?end sei allen gedankt, die durch die Einreichung eines Beitrags zum Gelingen des Workshops beigetragen haben. Besonderer Dank gebührt den Mitgliedern des Programmko-mitees für die Begutachtung der eingegangenen Beitr?ge und die Mitwirkung bei der Organi-sation des Workshops. Gedankt sei auch den Mitarbeitern der Arbeitsgruppe Wirtschaftsin-formatik der Otto-von-Guericke-Universit?t Magdeburg, davon insbesondere Herrn Mag. Klement Fellner, für die organisatorische Unterstützung.
Magdeburg, im September 2000
Klaus Turowski
Inhaltsverzeichnis
J?rg Ackermann
Das SAP-Paketkonzept – Erfahrungen bei der Modularisierung bestehender Anwendungssysteme (1)
Stephan Sahm
Organisationsmodelle zur komponentenorientierten Anwendungsentwicklung/ terminologiebasierte Spezifikation von Fachkomponenten (17)
Andreas Schmietendorf, André Scholz
Spezifikation der Performance-Eigenschaften von Softwarekomponenten (41)
Peter Fettke, Peter Loos
Komponentendokumentationen - Eine systematische Bewertung von Ordnungssystemen
aus formaler Sicht (51)
Elke Glistau, Heike Mrech, Dietrich Ziems
Methodenbanken verbinden Wissensmanagement und Componentware (71)
Das SAP-Paketkonzept – Erfahrungen bei der Modularisierung bestehender
Anwendungssysteme
J?rg Ackermann
SAP AG, Neurottstr. 16, 69190 Walldorf/Baden, Tel. +49 (6227) 747474, E-mail: joerg.ackermann@https://www.doczj.com/doc/c03468258.html, , URL: https://www.doczj.com/doc/c03468258.html,
Zusammenfassung. Neben der Kombination und Integration von Komponenten im Rahmen von
https://www.doczj.com/doc/c03468258.html,? gibt es bei SAP Bestrebungen zur weiteren Modularisierung innerhalb einzelner
Anwendungssysteme. In diesem Zusammenhang steht das SAP-Paketkonzept, welches eine st?rke-
re Entkopplung einzelner Anwendungsteile erlaubt. Erste Erfahrungen dazu stellen wir in diesem
Beitrag vor. Dabei konzentrieren wir uns vor allem auf die Modellierung betriebswirtschaftlich ge-
eigneter Pakete (Modularisierungseinheiten).
Schlüsselworte: Anwendungssysteme, Modularisierung, Modellierung, Vorgehensmodell
1Einleitung
Mit https://www.doczj.com/doc/c03468258.html,? stellt SAP seinen Kunden eine Komplettl?sung zur Verfügung, die die Umsetzung einer Vielzahl betrieblicher Anwendungsf?lle unterstützt. Das Spektrum reicht dabei von innerbetrieblichen Planungsabl?ufen bis zu kollaborativen e-Business-Szenarien zwischen verschiedenen Unternehmen. Komponenten gewinnen im verteilten Umfeld von Anwendungen, die über das Internet integriert werden, immer mehr an Bedeutung und sind auch für SAP von Interesse. (Zum Komponentenparadigma allgemein siehe z.B. Szyperski 1997). https://www.doczj.com/doc/c03468258.html,? besteht aus verschiedenen Komponenten wie Financials, Human Re-sources, Customer Relationship Management oder Advanced Planner and Organizer. Die se-mantische Integration erfolgt über Business-Objekte und zugeh?rige BAPI-Schnittstellen. Das Internet Business Framework bietet eine Architektur, die die technische Integration auf der Grundlage von XML-Schnittstellen über das Internet erm?glicht.
Neben diesen Komponenten im Gro?en gibt es bei SAP weitere Bestrebungen zur verst?rkten Modularisierung im Kleinen. Ziel ist eine st?rkere technische Entkopplung von Anwen-dungsteilen unter Beibehaltung der hohen betriebswirtschaftlichen Integration. Wir verspre-chen uns davon eine h?here technische Verst?ndlichkeit der Systeme, geringere Wartung und einfachere Weiterentwicklung. Dafür wurde das sogenannte Paketkonzept entwickelt, welches sich derzeit in der Pilotphase befindet. Dieser Beitrag diskutiert unser Vorgehen bei der Pa-ketbildung und die gesammelten Erfahrungen.
Grundidee des Paketkonzepts ist, eine Anwendung (z.B. SAP R/3 oder SAP CRM) vollst?n-dig in Pakete zu zerlegen. Pakete k?nnen Schnittstellen definieren und den Zugriff durch an-dere Paketen auf ausgew?hlte Entwicklungsobjekte einschr?nken. Dadurch werden bestehende
Abh?ngigkeiten noch transparenter und nicht gewünschte Abh?ngigkeiten k?nnen (toolunter-stützt) abgebaut werden. Der Grundgedanke von SAP-Paketen ist vergleichbar mit UML-Paketen plus einer UML-Abh?ngigkeitsbeziehung (zu UML siehe OMG 2000). über die Mo-dellierung hinaus werden die Pakete bei SAP auch in der Entwicklungsumgebung verankert, wodurch eine Toolunterstützung erm?glicht wird. Die technischen Aspekte des Paketkonzepts werden im Kapitel 2 n?her erl?utert.
Die richtige Definition der konkreten Pakete (Zerlegung des Systems) ist von entscheidender Bedeutung. Die Pakete sollen die betriebswirtschaftliche Struktur des Systems widerspiegeln, m?glichst wenige Abh?ngigkeiten untereinander aufweisen und langfristig stabil sein. In den Kapiteln 3 und 4 werden unser Vorgehensmodell, die Modellierung der Pakete und die Do-kumentation der Ergebnisse ausführlich vorgestellt.
Das Ziel des Paketkonzepts liegt in der SAP-internen Softwarestrukturierung. Es gibt derzeit keine Planungen, aus den Paketen (technisch echte) Komponenten zu machen. Allerdings sind aus unserer Sicht die betriebswirtschaftlich gew?hlten Pakete gerade (semantisch) geeignete Kandidaten für Fachkomponenten. Der Ansatz gibt damit Erfahrungen wieder, die für eine Komponentisierung bestehender Anwendungen sowie allgemein für Fachkomponenten inte-ressant sind.
2Das SAP-Paketkonzept
Die weiteren Ausführungen beziehen sich auf SAP R/3, gelten aber analog für SAP CRM, SAP APO etc.
2.1Funktionsweise
SAP R/3 ist eine 3-Tier-Client-Server-L?sung (Datenbank, Applikationsserver, Frontend). Die betriebswirtschaftlichen Anwendungen werden mit Hilfe einer SAP-eigenen Entwicklungs-umgebung und Programmiersprache (ABAP Objects) erstellt.
Das System R/3 setzt sich aus einer Vielzahl von eigenst?ndigen Entwicklungsobjekten zu-sammen. Dabei kann es sich um Programme, Funktionsbausteine, Tabellen, Screens, Datenty-pen u.a. handeln. Die Entwicklungsobjekte sind heute in sogenannten Entwicklungsklassen gruppiert. Diese Container enthalten au?er der Gruppierung keine weitere Semantik. (Der bei SAP verwendete Begriff …Entwicklungsklasse“ für eine Gruppierung von Entwicklungsob-jekten ist sicher nicht so ganz glücklich. Er wird im folgenden immer dann verwendet, wenn zwischen dem bisherigen und dem geplanten Zustand unterschieden werden soll.) Das System R/3 besteht aus über 800.000 Entwicklungsobjekten in etwa 3.000 Entwicklungsklassen. Pakete sind eine Weiterentwicklung der heutigen Entwicklungsklassen mit neuer zus?tzlicher Semantik. Sie dienen zur besseren Modularisierung und Kapselung.
Ein Paket ist ein Container, der einzelne Entwicklungsobjekte (Paket-Elemente) und/oder andere Pakete enth?lt. Jedes Entwicklungsobjekt liegt in genau einem Paket. Ein Paket kann in (h?chstens) einem anderen Paket enthalten sein.
Ein Hauptpaket ist ein Paket, das in keinem anderen Paket enthalten ist (d.h. ein Paket ohne Vater).
Bild 1: Grundidee eines Pakets
Pakete zeichnen sich gegenüber den bisherigen Entwicklungsklassen durch zus?tzliche se-mantische Eigenschaften aus: Schachtelbarkeit, Schnittstellen und Sichtbarkeit, Verwen-dungserkl?rungen.
? Schachtelbarkeit : ist die F?higkeit von Paketen, andere Pakete in sich einzubetten.
? Sichtbarkeit : ist eine Eigenschaft von Paket-Elementen. Ein Element kann au?erhalb sei-nes Pakets sichtbar sein. Es ist immer innerhalb seines Pakets sichtbar. Es ist nie in einge-
betteten Paketen sichtbar. Ein Element kann nur nach au?en sichtbar sein, wenn es in mindestens einer Paket-Schnittstelle liegt. Eine Schnittstelle ist eine Menge von Entwick-lungsobjekten (des Pakets), die au?erhalb des Pakets sichtbar (verwendbar) sein sollen.? Verwendungserkl?rung : dokumentiert das einseitige Recht eines Paketes, die Elemente einer Schnittstelle eines anderen Pakets zu verwenden.
Erlaubnis
Schachtelbarkeit Verwendungserlaubnis Schnittstellen und Sichtbarkeit Schnittstellen
P1
P2(Legende: P1, P2 = Pakete; SS1, SS2 = Schnittstellen; FBS1 – FBS4 = Funktionsbausteine; Tab1, Tab2 = Ta-
bellen)
Bild 2: Die 3 Grundkonzepte von Paketen
Mittels Schnittstellen und Sichtbarkeit kann ein Paket sein Angebot an Dienstleistungen deut-lich machen ("Was dürfen andere nutzen"). Was sichtbar ist, k?nnen andere Pakete potentiell nutzen. Was nicht sichtbar ist, k?nnen andere Pakete auch nicht nutzen. Damit kann ein Paket seine Elemente vor beliebiger Fremdverwendung schützen ("Was sollen andere nicht nutzen")und sein Inneres kapseln.
Verwendungserkl?rungen schr?nken die Nutzung von sichtbaren Elementen fremder Schnitt-stellen ein ("Nicht jeder darf alles nutzen"). Nur bei Vorliegen einer Verwendungserkl?rung auf eine Schnittstelle eines fremden Paketes kann ein Paket die sichtbaren Elemente in dieser Schnittstelle nutzen. Verwendungserkl?rungen werden im Einvernehmen zwischen beiden beteiligten Paketen vergeben.
Schachtelbarkeit erlaubt das technische,hierarchische Zergliedern von gr??eren Einheiten. Damit ist das System einfacher zu verstehen. Im Zusammenspiel mit Schnittstellen und Ver-wendungserkl?rungen lassen sich zus?tzlich sehr viele Paketelemente auf einfache Weise "verstecken" und vor Nutzung schützen.
Jedes Paket kann sowohl in der Rolle des Anbieters (=Server) als auch der des Nutzers (=Client) von Services auftreten.
Mit diesen drei F?higkeiten von Paketen besteht die M?glichkeit, R/3 in technische Einheiten (in Pakete) zu zerlegen und zu kapseln, die hohen Abh?ngigkeiten zu verringern und die Ver-st?ndlichkeit des Systems zu erh?hen.
Sind Sichtbarkeiten und Verwendungserkl?rungen festgelegt, so kann deren Einhaltung so-wohl zur Bauzeit als auch zur Laufzeit überprüft werden. Beispiele dafür sind: Darf beim …?... Anlegen eines komplexen Datentyps ein bestimmter einfacher Datentyp verwendet
werden?
?... Kompilieren eines Programms eine bestimmte Tabelle genutzt werden?
?... dynamischen Aufruf eines Funktionsbausteins dieser wirklich aufgerufen werden?
Die Prüfungen und die Reaktionen auf Verst??e (Ignorieren, Warnung, Abbruch) sind in Stu-fen einstellbar. Je nach Bedarf (z.B. aus Performance-Gründen oder in produktiven Kunden-systemen) k?nnen auch alle Prüfungen abgeschaltet werden.
2.2Ziele und Nutzen
Zweck der Einführung von Paketen ist, die Voraussetzungen für eine h?here technische Mo-dularisierung bei Erhalt der logischen Integration zu schaffen. Im einzelnen werden die fol-genden Ziele für die (Weiter-) Entwicklung, Wartung, Administration und Nutzung von R/3 angestrebt:
?Festlegen des Angebots und Schutz vor Verwendung
Ein Paket kann seine Dienstleistungen über die Paket-Schnittstelle deutlich machen ("was soll verwendet werden") und gleichzeitig verhindern, dass jedes seiner Elemente zug?nglich ist ("was darf nicht verwendet werden"). Pakete sind damit gekapselt.
?Reduzieren und Verdeutlichen von Abh?ngigkeiten
Durch geeignete Zerlegung der Pakete l?sst sich die Lokalit?t innerhalb der Pakete erh?hen. Pakete werden weniger fremde Elemente verwenden. Anhand der Verwendungserkl?rungen sind die Abh?ngigkeiten zwischen Paketen jederzeit ersichtlich. Mittels Schachtelung oder gerichteten Verwendungserkl?rungen lassen sich Pakete leicht in Schichten anordnen.?Erkennen inkompatibler ?nderungen; leichteres Reorganisieren
Es besteht die M?glichkeit, die Schnittstellen von Paketen einzufrieren bzw. nur noch kompa-tibel zu erweitern. Syntaktische ?nderungen an Schnittstellen k?nnen so verhindert oder zu-mindest maschinell erkannt werden. Au?erdem k?nnen bei konstanten Schnittstellen die Pa-kete ohne Schaden für ihre Verwender beliebig reorganisiert werden.
?Verringern der technischen Komplexit?t; h?here technische Verst?ndlichkeit
Aufgrund der reduzierten und ersichtlichen Abh?ngigkeiten und aufgrund der Schnittstellen
verringert sich aus technischer Sicht die Komplexit?t von R/3. Das System wird technisch einfacher zu verstehen sein.
?Schnellere und kostengünstigere ?nderbarkeit
Direkte Folge der verringerten Komplexit?t sind einfachere, schnellere und weniger aufwen-dige (Weiter-) Entwicklung, Wartung und Implementierung. Auslieferung, Releasewechsel und interne Transporte werden ebenfalls einfacher und schneller.
?H?here Unabh?ngigkeit von Entwicklungsbereichen innerhalb und au?erhalb der SAP Die organisatorische Entkopplung der Entwicklungsbereiche (bis hin zu Partner- oder Kun-denentwicklungen) kann durch die technische Entkopplung und das Erkennen von Abh?ngig-keiten unterstützt werden. Die einzelnen Bereiche sind weniger aufeinander angewiesen und k?nnen mit geringerem Aufwand ihre (Teil-) Produkte erstellen.
2.3Aktueller Status und geplantes Vorgehen
Um die genannten Ziele zu erreichen, sind ein geeignetes Vorgehen und die richtige Definiti-on der Pakete (Zerlegung des Systems) von entscheidender Bedeutung. Das geplante Vorge-hen setzt sich aus den folgenden Schritten zusammen:
1.Analyse der aufzubauenden Paketlandschaft
In der Analysephase werden die Hauptpakete und deren Aufgaben bestimmt. Für jedes Haupt-paket werden als Soll-Beschreibung seine inhaltlichen Aufgaben, anzubietende Services, Be-teiligung an Prozessen und seine Abgrenzung zu anderen Hauptpaketen festgelegt. Bei der Ist-Beschreibung wird ermittelt, welche heutigen Entwicklungsklassen dem Hauptpaket zuzuord-nen sind und welche Defizite noch zum Soll-Zustand bestehen. Au?erdem sollte schon eine Vorstellung entstehen, in welcher Form das Hauptpaket seine Services anbieten wird und wel-che Teilpaketkandidaten existieren.
Das Vorgehen und die Erkenntnisse aus der Analysephase werden ausführlich im Kapitel 3 diskutiert.
Status des Projektes: Für SAP R/3 wurde ein erster, fl?chendeckender Paketvorschlag er-stellt. Darüber hinaus wurde in ausgew?hlten Bereichen auch die Analyse durchgeführt. Die folgenden Punkte wurden noch nicht durchgeführt und spiegeln nur unsere derzeitigen Pla-nungen wider.
2.Definition der Pakete im System
Die Pakete werden zu einem Stichtag fl?chendeckend eingeführt. Dazu werden die in der A-nalysephase bestimmten Hauptpakete definiert. Jede heutige Entwicklungsklasse wird genau einem Hauptpaket zugeordnet und wird zu einem Teilpaket.
Es werden vom System alle bestehenden Verwendungen zwischen Paketen errechnet. Alle verwendeten Entwicklungsobjekte eines Pakets werden in eine Altschnittstelle aufgenommen. Dadurch wird ein vorl?ufiger Bestandsschutz gew?hrleistet. Die Altschnittstelle darf jedoch nicht mehr erweitert werden und muss schrittweise abgebaut werden.
Es ist nicht immer m?glich, eine heutige Entwicklungsklasse vollst?ndig einem Hauptpaket zuzuordnen. Deshalb müssen die Entwicklungsklassen vorher bereinigt werden. Dazu werden einzelne Entwicklungsobjekte anderen Entwicklungsklassen zugewiesen oder ganze Ent-
wicklungsklassen zerlegt. Schwieriger ist der Fall, wenn einzelne Entwicklungsobjekte (z.B. Programme) zerlegt werden müssen. Ein solches Redesign der Anwendung wird nicht immer im Vorfeld m?glich sein.
3.Anbieten von Services über Schnittstellen
Jedes Hauptpaket legt fest, welche Services es in welcher Form anbietet. Diese werden dann in neu zu definierende Schnittstellen aufgenommen und ersetzen mittelfristig die Altverwen-dungen. Ein Paket-Architekturteam legt fest, welche Arten von Verwendung m?glich sind (in Abstufung erwünscht, erlaubt, vorl?ufig geduldet). So k?nnte beispielsweise der direkte Zugriff auf Tabellen und Daten eines anderen Paketes ausgeschlossen werden.
4.Umstellen der Verwender auf die neuen Schnittstellen
Die Nutzer von Services müssen sich dann (mit übergangsfristen) auf die neuen Schnittstellen umstellen und die Verwendungserkl?rungen mit dem …Server“-Paket absprechen.
Geplant ist, dass ein Paket-Architekturteam pro Release Vorgaben zur Umsetzung des Pakets-konzept gibt. Solche Vorgaben k?nnen erlaubte Typen von Verwendungen (z.B. Funktions-bausteinsverwendung vs. Tabellenzugriff), Auslauffrist der Altschnittstelle oder eine Schich-tung von bestimmten Paketen sein. Gesteuert werden solche zentralen Vorgaben durch Tools und die geeignete Wahl der Fehlerschwere (Warnung vs. Abbruch) bei Verst??en.
3Modellierung geeigneter Pakete
In diesem Kapitel besch?ftigen wir uns mit der Modellierung von Hauptpaketen. Durch das Paketkonzept soll eine bessere Kapselung der einzelnen Anwendungsteile erreicht und die bestehenden Abh?ngigkeiten expliziter erkennbar werden. Dafür ist vor allem die richtige Definition der Hauptpakete von entscheidender Bedeutung, da diese die oberste Paketschicht bilden und im wesentlichen die Zerlegung des Systems darstellen. Innerhalb von Hauptpake-ten k?nnen Anwendungsbereiche durch Teilpakete weiter strukturiert werden. Dies ist zumeist nur von lokaler Bedeutung und hat wenig Einfluss auf die übergreifende Paketlandschaft. Deswegen liegt der prim?re Fokus zun?chst auf dem Bestimmen geeigneter Hauptpakete. Alle Ausführungen in diesem Kapitel beziehen sich auf Hauptpakete, auch wenn der Kürze halber oft nur von Paketen gesprochen wird.
3.1Kriterien bei der Modellierung
In diesem Abschnitt erl?utern wir unsere Kriterien bei der Modellierung von Hauptpaketen. Die Reihenfolge spiegelt in etwa ihre Wichtigkeit wider. Es ist klar, dass im Einzelfall nicht alle Kriterien gleichzeitig erfüllt werden k?nnen, da diese sich teilweise widersprechen k?n-nen. Im jeweils konkreten Fall muss ein m?glichst guter Kompromiss gefunden werden.?Stabilit?t
Für die Reduktion der technischen Komplexit?t und den Abbau von Abh?ngigkeiten ist es notwendig, dass die Pakete langfristig stabil bleiben. ?nderungen an der Paketlandschaft müs-sen zwar m?glich sein, sollen aber minimiert werden.
?Abbilden der betriebswirtschaftlichen Struktur
Als prim?res Kriterium für das Bilden der Pakete dient die betriebswirtschaftliche Struktur
des Anwendungssystems. Die heutige technische Struktur oder organisatorische Struktur spielen nur eine untergeordnete Rolle. Nur so kann die langfristige Stabilit?t gew?hrleistet werden.
?Richtige Zuordnung von Services
Die Services, welche ein Paket für andere erbringt, konstituiert einen Hauptteil der Definition eines Pakets. Deshalb ist die richtige Zuordnung der Services von entscheidender Bedeutung. Auch hier ist das prim?re Kriterium die betriebswirtschaftlich sinnvolle Zuordnung und weni-ger die heutigen technischen und organisatorischen Gegebenheiten.
?Eindeutige personelle Verantwortlichkeit
Die erfolgreiche Umsetzung des Konzepts verlangt organisatorische Ma?nahmen im Ent-wicklungsprozess. Deshalb muss es für jedes Paket einen eindeutigen Verantwortlichen ge-ben.
Im Einzelfall sind Konflikte zwischen der betriebswirtschaftlichen Struktur und der personel-len Verantwortung zu erwarten. Dann muss ein m?glichst guter Ausgleich zwischen diesen Kriterien erreicht werden.
?Minimierung der Abh?ngigkeiten / Schnittstellen
Haben zwei Pakete viele, detaillierte Abh?ngigkeiten untereinander, so ist dies oft ein Zeichen dafür, dass die Pakete falsch geschnitten wurden. Es kann aber auch sein, dass die heutige technische Struktur nicht der betriebswirtschaftlichen Struktur entspricht und ein Redesign sinnvoll w?re. Auch hier muss im Einzelfall ein geeigneter Ausgleich zwischen den Kriterien gefunden werden.
?Ausgewogene Granularit?t
Die Pakete müssen eine ausgewogene Granularit?t (…nicht zu grob und nicht zu fein“) besit-zen. Bei …zu gro?en“ Paketen wird die angestrebte Entkopplung kaum unterstützt und es k?n-nen keine klaren Verantwortlichen gefunden werden. Bei …zu kleinen“ Paketen wird das Ge-samtsystem zu unübersichtlich und es entstehen zu viele und potentiell unn?tige Abh?ngig-keiten.
?Gleichm??ige Granularit?t
Die Gr??e der Pakete sollte über die verschiedenen Anwendungen hinweg vergleichbar sein. Dies muss durch zentrale Vorgaben und organisatorische Begleitung des Prozesses sicherge-stellt werden. Es wird aber natürlich in allen Anwendungsbereichen eher kleinere (z.B. Tools) und eher gr??ere Pakete geben.
Der Vollst?ndigkeit halber ist hier noch ein technisches Kriterium angegeben, welches auf-grund des Paketkonzepts an sich in jedem Fall erfüllt sein muss:
?Vollst?ndigkeit und Disjunktheit
Alle Entwicklungsobjekte werden genau einem Paket zugeordnet. Damit wird eine Anwen-dung vollst?ndig in Pakete zerlegt und es gibt keine überschneidungen zwischen den Paketen. Entwicklungsobjekte k?nnen nicht mehreren Paketen geh?ren, aber natürlich von anderen Paketen verwendet werden.
Darüber hinaus wurde vor Beginn des Projektes die Grundannahme getroffen, dass sich das R/3-System aus 150-250 Hauptpakten zusammensetzen sollte. Damit war eine grobe Ent-scheidung über die Granularit?t der Pakete gegeben. Diese Vorgabe schien uns am Besten den sinnvollen Kompromiss in Bezug auf die Granularit?t darzustellen. Dies bedeutet insbesonde-re, dass Entwicklungsgruppen von bis zu 20 Entwicklern ein Hauptpaket betreuen werden. 3.2Vorgehensweise
Die Analyse der m?glichen Hauptpakete erfolgt in den einzelnen Entwicklungsbereichen. Unterstützt werden diese von einer zentralen Paketgruppe, die aus modellierungserfahrenen Kollegen besteht. Die Aufgaben der Paketgruppe sind:
?Erstellung eines ersten Vorschlags der Hauptpaketlandschaft
?Festlegen einer geeigneten Vorgehensweise und der Modellierungskriterien ?intensive Betreuung von Pilotkandidaten (und Rückführung der Erfahrungen in den Pro-
zess)
?Unterstützung der Bereiche bei der Analyse der Pakete (insbesondere bei kritischen As-pekten)
Im folgenden stellen wir das Vorgehen in der Analysephase vor. Den Projektgruppen wurden die zu durchlaufenden Schritte, die jeweils zu erfassenden Informationen und die Modellie-rungskriterien zur Verfügung gestellt. Auf dieser Grundlage konnten dann die notwendigen Entscheidungen über die geeigneten Pakete gef?llt werden.
Erl?utert werden die diskutierten Fragestellungen am Beispiel des Bereichs Bestandsführung. Dieser Bereich geh?rte zu den Pilotbereichen, in denen die gesamte Analysephase schon ab-geschlossen wurde. Er ist auch deshalb von Interesse, da sich in diesem gleich mehrere kriti-sche Fragestellungen ergaben. Die angegebenen Beispiele dienen prim?r zur Erl?uterung der einzelnen Punkte des Vorgehens. Sie spiegeln deshalb nur wenige ausgew?hlte Aspekte der Bestandsführung wider. Eine vollst?ndige Diskussion dieses Beispiels würde über den Rah-men dieses Beitrags hinausgehen.
3.2.1Grobvorschlag einer Hauptpaketlandschaft
Die zentrale Paketgruppe erstellte zun?chst einen ersten, fl?chendeckenden Vorschlag für die m?glichen Hauptpakete. Grundlage dafür waren frühere Modellierungsergebnisse und Kurz-interviews in den einzelnen Entwicklungsbereichen. Dabei wurde bestimmt (jeweils undetail-liert):
?Hauptpaket, Funktionsumfang und wichtigste Aufgaben,
?Abh?ngigkeiten zu anderen Paketen
?auftretende Probleme und offene Fragen,
?Liste der beteiligten (heutigen) Entwicklungsklassen.
Geh?rt eine der Entwicklungsklassen nicht eindeutig zu einem Paket, wurde sie (mit einem Vermerk) dem geeignetsten Paketkandidaten zugeordnet.
Der so entstandene Vorschlag ist vollst?ndig und disjunkt. ?nderungen an diesem Vorschlag
sind natürlich m?glich. Er dient aber als Rahmen für die weitergehende Analyse in den ein-zelnen Entwicklungsbereichen. Aus unserer Sicht ist es wichtig, dass dieser fl?chendeckende Grobvorschlag vorliegt, bevor mit der eigentlichen Analyse begonnen wird. Dieser garantiert eine gleichm??ige Granularit?t über die verschiedenen Bereiche hinweg und sichert, dass ein-zelne Anwendungsteile nicht vergessen oder stillschweigend von mehreren Gruppen für sich reklamiert werden.
3.2.2Anforderungsanalyse und Zielkonsens
Für alle weiteren Schritte wird pro Hauptpaketkandidat eine Arbeitsgruppe gebildet. Diese besteht aus Kollegen aus den entsprechenden Entwicklungsbereichen und kann im Einzelfall durch einen Vertreter der zentralen Paketgruppe erg?nzt werden. Die weiteren Schritte wurden in ausgew?hlten Pilotbereichen durchgeführt, aber noch nicht fl?chendeckend umgesetzt. Diese Phase dient zur Ist-Beschreibung und zur groben Abgrenzung des Hauptpakets. Au?er-dem soll ein Konsens über die grunds?tzlichen Ziele der beteiligten Entwicklungsabteilungen beim Paketkonzept gefunden werden. Im einzelnen sind folgende Fragen zu beantworten:
1.Ausgangslage / Ist-Situation
?Beschreibung des zu bildenden Pakets erstellen: vorhandene Dokumente zusammenstellen Beispiel: Paket Bestandsführung; vorhandene Kurzbeschreibung beschreibt das Ge-biet hinreichend
?Liste der beteiligten Entwicklungsklassen (inklusive teilweiser beteiligter); Abgleich mit Grobvorschlag
?bekannte Defizite der existierenden Entwicklungsklassen
?Kandidaten für Paketverantwortlichen
2.Zentrale betriebswirtschaftliche Begriffe (Inhalt des Pakets)
?Liste der Begriffe zur betriebswirtschaftlichen Beschreibung des Pakets
Beispiel:
Begriff Definition
Wareneingang (WE) zur Bestellung WE eines bestellten Materials in des Lager oder in den Verbrauch
Warenausgang Warenausgang aus dem Lager
Umbuchung Zustands?nderung eines Materials
...
3.Einflüsse / Abh?ngigkeiten / Umfeld
?Liste der Pakete/Gebiete, die verwendet werden (m?glichst vollst?ndig)
?Liste der Pakete/Gebiete, die mich verwenden (einige typische)
Beispiel: Bestellung, Fertigungsauftrag (beide Richtungen), Materialstamm, Material-
Ledger (wird verwendet), Vertrieb (verwendet), ...
4.Anforderung und Ziele an das Paketkonzept (aus Sicht der Entwicklungsabteilung)?Liste der Anforderungen und deren Gewichtung
Beispiel:
Erhoffter Nutzen Erl?uterung Priori-
t?t
(A/B/C)
B Arbeitserleichterung Weniger Seiteneffekte bei ?nderungen, leichtere Wart-
barkeit
Bessere Kapselung z.B. direkte Zugriffe durch Funktionsbausteine erset-
B
zen
...
Für einige der Punkte k?nnen die Ergebnisse bei der Erstellung des Grobvorschlags wieder-verwendet werden. Diese Phase sollte nach einer Gruppensitzung abgeschlossen sein.
3.2.3Feinanalyse des Hauptpakets
In dieser Phase soll das Paket in seinen wesentlichen Zügen festgelegt werden. Dazu sollten ein bis drei Gruppensitzungen verwendet werden. Es müssen die folgenden Fragen beantwor-tet werden:
1.Abgrenzung des Pakets
?zukünftige Kapselung (Soll-Zustand), Vergleich mit Ist-Zustand
?Validierung der Festlegungen des Grobvorschlags, gegebenenfalls ver?ndern
?überprüfung der personellen Verantwortlichkeit für das Paket
Beispiel: Aufgabe der Bestandsführung ist die Fortschreibung von Warenzug?ngen o-der –abg?ngen inklusive ihrer Bewertung. Damit geh?rt insbesondere die wertm??ige Bestandsführung mit zum Paket. Die Bilanzbewertungsverfahren geh?ren nicht zur Bestandsführung. Fortschreibung von Preis?nderung ist die Aufgabe eines Pakets Material-Ledger.
Wem sollen die Materialbest?nde (Verwaltung und Fortschreibung) zugeordnet wer-den: der Bestandsführung oder dem Materialstamm? Da die Materialbest?nde eine sehr enge Kopplung mit ihren Fortschreibungsregeln und eine eher lose Kopplung mit Materialbearbeitungsservices (z.B. Anlegen eines Materials) haben, geh?ren sie se-mantisch zur Bestandsführung. Allerdings liegen die Materialbest?nde technisch und organisatorisch in Verantwortung des Materialstamms. Ein Redesign bedeutet einen gr??eren Aufwand.
L?sung: Die Bestandsservices (…Best?nde fortschreiben“ bzw. …Best?nde holen“) ge-h?ren technisch dem Materialstamm. Die Fortschreibung erfolgt jedoch durch die Be-standsführung und wird von ihr in Form von …Services zu Warenbewegungen“ ande-ren Paketen angeboten. Dazu werden die Services in der Bestandsführung (entspre-chend …verpackt“) in Form von …Warenbewegungen anlegen/stornieren“ bzw. …Be-st?nde holen“ angeboten. Die Services bei der Bestandsführung sind allgemein ver-fügbar, die am Materialstamm nur für das Paket Bestandsführung.
2.Gesch?ftsvorf?lle
?Liste aller Gesch?ftsvorf?lle, an denen das Paket beteiligt ist
Beispiel: Wareneingang zur Bestellung, Wareneingang zum Fertigungsauftrag, Wa-renausgang, Umbuchungen, Umlagerungen, Materialreservierung, Mengenm??ige In-ventur
3.Pakete im Umfeld
?Ermittlung aller vorausgesetzten und aller abh?ngigen Pakete (dies soll aus den Ge-sch?ftsprozessen abgeleitet werden)
Beispiel:
Fremdes Paket/Gebiet Gesch?ftsvorfall Rolle des fremden Pakets
Bestellung WE zu Bestellung verwendet / wird verwendet
Fertigungsauftrag WE zu Fertigungsauftrag verwendet / wird verwendet
verwendet
Vertrieb Wareausgang zu Liefe-
rung
Materialstamm Lesen der Best?nde wird verwendet
...
4.Beteiligte Business-Objekte
?Liste aller anzubietenden Dienste (unabh?ngig von heutiger Realisierung)
?Liste aller ben?tigten Business-Objekte (vorhandene plus zus?tzliche) und deren Bezie-hungen
Beispiel:Business-Objekt GoodsMovement
anzubietender Dienst heute realisiert in Form von Bemerkung
Create (Anlegen)BAPI & lokaler Funktionsbaustein beides weiterhin sinnvoll
Cancel (Stornieren)BAPI & lokaler Funktionsbaustein beides weiterhin sinnvoll
...
5.Teilpakete identifizieren (falls zutreffend)
Beispiel: m?gliche Teilpakete sind Warenbewegung, Materialreservierung, Inventur und Services Bestandsführung; vollst?ndige Kapselung der Teilpakete hat vorl?ufig eine geringere Priorit?t
3.2.4Technische Detailanalyse
Diese Phase dient der objektweisen Festlegung des Paketinhalts. Es wird im Detail entschie-den, welchem Paket jedes einzelne Entwicklungsobjekt zuzuordnen ist. Diese Phase muss in mehreren Gruppensitzungen behandelt werden und bedarf einer umfangreicheren Vor- und Nachbereitung. Dazu wird untersucht:
1.Objektweise Analyse der (bisherigen) Entwicklungsklassen
?überprüfen der Zuordnung jeder Entwicklungsklasse zu einem Paket; überprüfung aller Entwicklungsobjekte auf die richtige Zuordnung; Bereinigung der Entwicklungsklassen 2.Technische Validierung des Pakets
?testweise Definition des Pakets; überprüfung aller Abh?ngigkeiten; Validierung der in der Analyse getroffenen Annahmen zu Abh?ngigkeiten; ggf. zur Feinanalyse zurückgehen ?überprüfung, ob der Schnitt des Pakets rundum abgesichert ist
3.Festlegen geeigneter Schnittstellen pro Gesch?ftsvorfall
Bei der technischen Detailanalyse handelt es nicht mehr um die Modellierung der Pakete an sich. Deshalb soll darauf an dieser Stelle nicht n?her eingegangen werden.
3.3Aufgetretene Modellierungsprobleme
Mit den vorgegebenen Modellierungskriterien und vorhandenem Dom?nenwissen war es im allgemeinen relativ einfach, geeignete Pakete zu definieren. In einigen F?llen jedoch führten die unterschiedlichen Kriterien zu st?rkeren Widersprüchen. Dann wurden verschiedene Al-ternativen formuliert und im Einzelfall eine der Alternativen ausgew?hlt. Bei diesen Problem-f?llen wiederholten sich bestimmte Fragestellungen. Einige dieser typischen Konflikte bei der Modellierung und m?gliche L?sungen wollen wir in diesem Abschnitt diskutieren.?Betriebswirtschaftliche versus organisatorische Strukturierung
Bei der Bildung der Hauptpakete soll nicht die heutige organisatorische Struktur abgebildet werden. Andererseits sollte jedes Paket einen eindeutigen Verantwortlichen haben. Findet sich zu einem semantischen Paketkandidaten kein Verantwortlicher, dann sind kompakte Teilbe-reiche mit jeweils klarer Verantwortung zu identifizieren. Dies ist in den meisten F?llen m?g-lich. Sollte eine Ver?nderung der Organisation nicht sinnvoll sein, sollte geprüft werden, ob die Teilbereiche stattdessen die Hauptpakete werden. Dies ist ein sinnvoller Kompromiss zwi-schen der betriebswirtschaftlichen und einer rein organisatorischen Strukturierung. Es ist denkbar, die Pakete zu einem sp?teren Zeitpunkt wieder zusammenzufassen. Dies w?re weder für die Paketbesitzer noch für die Verwender mit einem gr??eren Aufwand verbunden.?Abgeschlossenheit versus Disjunktheit
Beim Bilden von Softwarekomponenten ergibt sich oft ein Widerspruch bei der Forderung
nach in sich abgeschlossenen, aber disjunkten Komponenten (siehe z.B. Fellner/Rauten-strauch/Turowski 1999). Bei unserem Paketkonzept tritt das Problem in dieser Form nicht auf: Jedes Entwicklungsobjekt muss genau einem Paket zugeordnet werden. Damit ist die (techni-sche) Disjunktheit automatisch gegeben. Eine vollst?ndige Abgeschlossenheit der Pakete kann damit nicht immer garantiert werden. Dies ist aber auch gar nicht das Ziel. Unsere Pakete müssen nicht einzeln lauff?hig sein und dürfen von anderen Paketen abh?ngen. Muss z.B. ein Paket A einen Service X von Paket B nutzen, um seine Aufgaben erfüllen zu k?nnen, dann ist die Abh?ngigkeit des Pakets A von Paket B gewollt und sinnvoll. Handelt es sich jedoch um eine Abh?ngigkeit rein technischer Natur (Paket A nutzt aus historischen Gründen ein be-stimmtes Entwicklungsobjekt von Paket B), dann sollte die Abh?ngigkeit im Idealfall abge-baut werden.
?Richtige Zuordnung von Services
Das Problem der semantischen Abgeschlossenheit kann allerdings bei der betriebswirtschaft-lich richtigen Zuordnung der Services auftreten. Hierbei kann es zu einem Konflikt zwischen der betriebswirtschaftlichen und einer eher technischen Zuordnung kommen. So k?nnte zum Beispiel ein Service X semantisch zu einem Paket A geh?ren, ist aber heute technisch und organisatorisch eng mit dem Paket B verwoben. Eine m?gliche L?sung ist: Der Service X wird vom Paket A seinen Verwendern zur Verfügung gestellt. Ist ein Redesign (vorl?ufig) nicht m?glich, verbleibt die eigentliche Realisierung des Services beim Paket B. Paket A nutzt seinerseits den Service X beim Paket B, den letzteres in einer …privaten“ Schnittstelle Paket A anbietet. Ein eventuelles sp?teres Redesign betrifft dann nur die Pakete A und B und nicht die Verwender des Services X.
?Mehrfach genutzte Tabellen
In einigen F?llen wird eine Datenbanktabelle von mehreren Paketen genutzt. Eine Aufteilung in mehrere Tabellen ist oft nicht sinnvoll, da dies für die Kunden im allgemeinen einen erheb-lichen Umstellungsaufwand bedeutet. Welchem Paket soll die Tabelle zugeordnet werden? M?gliche L?sung: Die Tabelle wird einem der Pakete zugeordnet. Dieses Paket bietet eher technische Services zum Zugriff auf diese Tabelle an, die nur von den anderen …Tabellenbe-sitzern“ verwendet werden dürfen. Jeder der Tabellenbesitzer bietet seinerseits allgemeine Services an, über die die betriebswirtschaftliche Funktionalit?t durch alle andere Pakete ge-nutzt werden kann.
4Spezifikation und Dokumentation der Pakete
Damit die Pakete sinnvoll verwendet werden k?nnen, müssen sie ausreichend dokumentiert und ihre Eigenschaften spezifiziert sein. Dazu werden für jedes Paket einige Attribute, seine Bestandteile und Dokumentation erfasst.
Attribute und Bestandteile sind die eher formal spezifizierten Eigenschaften eines Pakets. Diese werden im System selbst abgelegt und sind maschinell auswertbar.
Darüber hinaus wird Dokumentation in Prosaform erfasst, die Semantik und Inhalt eines Pa-ketes beschreiben. Um eine einheitliche Darstellung zu erreichen, wurden Richtlinien und Templates erstellt. Die Dokumentation ist integraler Bestandteil des Pakets und wird im Sys-tem selbst erfasst und verwaltet. Bei der Dokumentation wird unterschieden zwischen ?Dokumentation des Pakets an sich,
?Dokumentation aller seiner Schnittstellen,
?Dokumentation der Entwicklungsobjekte in den Schnittstellen.
Die einzelnen Entwicklungsobjekte (Funktionsbausteine, Datentypen etc.) werden unabh?ngig vom Paketkonzept nach entsprechenden Richtlinien dokumentiert. Wir gehen in den Ab-schnitten 4.2 und 4.3 n?her auf die Dokumentation von Paketen und ihren Schnittstellen ein.
4.1Attribute und Bestandteile von Paketen
Für jedes Paket werden die folgenden Attribute im System definiert:
?Allgemeine Daten zum Paket (Name, Kurzbeschreibung, gegebenenfalls Vaterpaket),?Verwaltungsdaten (angelegt von, Anlegerelease, Transportschicht,...),
?Zuordnung eines Pakets zur betriebswirtschaftlichen Komponentenhierarchie (FI, CO etc.).
Die Bestandteile eines Pakets ergeben sich aus
?zugeordneten Entwicklungselementen und Teilpaketen,
?Schnittstellen eines Pakets, Entwicklungselemente in Schnittstellen,?Verwendungserkl?rungen (von anderen Paketen, zu anderen Paketen),?Freigabestatus einzelner Schnittstellenelemente (es kann unterschieden werden zwischen (nur) verwendbar und (langfristig) garantiert).
Alle diese Informationen werden in der Entwicklungsumgebung verwaltet und stehen damit sowohl zur Entwicklungs- als auch zur Laufzeit maschinell auswertbar zur Verfügung.
4.2Dokumentation der Pakete
Die Dokumentation von Paketen ist für Entwickler (SAP, Partner, Kunden) bestimmt. Sie soll Aufschluss geben, wie sich die betriebswirtschaftlichen Inhalte technisch im R/3-System ver-teilen. Aus der Dokumentation geht hervor, welches Paket welche Services anbietet bzw. an-bieten sollte. In der Dokumentation inhaltlich zusammengeh?riger Pakete sollte gegenseitig aufeinander verwiesen werden. Die Dokumentation eines Hauptpakets sollte insgesamt 2 Sei-ten nicht überschreiten. Sie sollte nicht auf technische Namen oder Details eingehen und ins-besondere nicht die Funktionsweise einzelner Paket-Elemente erl?utern.
Im folgenden findet sich eine Aufstellung, aus welchen Themenbl?cken eine Paketdokumen-tation besteht und welchen Inhalt diese haben. Auf die Veranschaulichung anhand unseres Beispiels Bestandsführung wird an dieser Stelle verzichtet, da dies über den Rahmen dieses Beitrags hinausgehen würde.
1.Verantwortlichkeiten des Paketes
?Welchen abgegrenzten Teilbereich umfasst das Paket ?
?Welches sind die betriebswirtschaftlichen Inhalte des Paketes ?
?Welche Aufgaben und Verantwortlichkeiten nimmt das Paket konkret wahr ??(Grob: ) An welchen Gesch?ftsprozessen ist das Paket beteiligt (z.B. Kundenauftrags-
abwicklung, Beschaffung, Planungsprozesse in Produktion und Kostenrechnung, ...) ??Welcher Teilprozess wird gegebenenfalls realisiert (z.B. Lieferung, Bezugsquellen-
findung,...) ?
2.Zentrale Services des Paketes
?Welche prozessorientierten Services bietet das Paket an ?
?Welche weiteren Services werden angeboten? (Stammdatenpflege, Reporting, Customiz-ing,...)
Bemerkung: Standardservices wie Anlegen, Anzeigen, ?ndern müssen nicht dokumen-tiert werden.
?Welche Business-Objekte realisieren diese Services?
3.Zentrale Abh?ngigkeiten des Paketes
?Welche zentralen Services anderer Pakete werden verwendet ?
?Welche Services werden vorausgesetzt ?
4.Verweise auf inhaltlich zugeh?rige Pakete
?Welche Pakete enthalten verwandte oder weiterführende Funktionalit?t ?
4.3Dokumentation der Paketschnittstellen
Ein Paket kann mehrere Schnittstellen zu seiner Funktionalit?t anbieten. Dies er?ffnet die M?glichkeit, Verwendungserkl?rungen differenzierter zu verteilen. Bietet z.B. ein Paket X die Services A und B an, dann kann einem Paket Y Zugriff auf A und einem Paket Z Zugriff auf A und B gestattet werden. Entsprechend k?nnen Entwicklungsobjekte auch mehreren Schnittstellen ihres Pakets zugeordnet sein.
Das Design der einzelnen Schnittstellen sollte sich an den Services ausrichten, die das Paket anbietet. Im allgemeinen wird es pro Gesch?ftsvorfall eine Schnittstelle geben, die alle ben?-tigten Elemente enth?lt, um den Service in Anspruch nehmen zu k?nnen. Genau daran orien-tieren sich auch die Richtlinien, wie Paketschnittstellen zu dokumentieren sind:
1.Kurzbeschreibung der Paketschnittstelle
?Welchen Hauptverwendungszweck hat die Schnittstelle ?
?Welchen Funktionalit?tsbereich umfasst sie ?
2.Zentrale Services der Schnittstelle
?Welche Services bietet diese Schnittstelle an ?
?Welches Business-Objekt steht dahinter ?
5Zusammenfassung
Das SAP-Paketkonzept erlaubt eine bessere technische Strukturierung unserer bestehenden Anwendungen. Mit den Konstrukten Kapselung, Schnittstellen und Verwendungserkl?rung
《栏目包装设计》课程标准 课程编码：0301792课程类别：专业核心课 适用专业：电视节目制作授课单位：数字媒体学院 学分：5学时：80 编写执笔人及编写日期：朱晓春2014年3月 审定负责人及审定日期： 1．课程定位和课程设计 1.1课程性质与作用 《栏目包装设计》课程是电视节目制作专业的一门专业核心课程，综合应用AfterEffects、Photoshop、3DMax、Illustrator等软件，实现任务式教学。 1.1.1课程性质 《栏目包装设计》课程是一门操作性和实践性很强的课程，它主要通过综合性的实践模拟训练，让学生学习电视栏目包装设计制作的内容。通过本课程使学生充分认识掌握实践技能的重要性，提高学生的实践设计操作能力，使学生能够适应现代社会对栏目包装设计人才的要求，满足就业的需要以及可利用前沿技术进行栏目包装设计。 1.1.2课程作用 本课程主要介绍运用AE这个影视特效合成软件以及3DMAX三维动画制作软件等进行电视栏目包装的知识与技术，使学生通过本课程的学习，不仅可以了解电视台栏目整体包装的制作流程和方法，还能根据需要制作出形式多样、效果丰富的片花、导视及宣传片来。为学生今后能成为栏目包装设计师这个岗位打下良好的基础。此外，还能使学生通过本课程的学习，培养学生正确的设计理念与设计方法，培养学生的实践运用能力及创新精神，提高学生的审美能力，引导学生掌握各类栏目包装设计的同时促进学生设计个性的发展。 本课程相关的先修课及后续课： 《栏目包装设计》这门课程和《影视图像处理》、《影视特效合成》、《三维动画制作》等课程联系密切，如经过PS图像处理过的图像以及使用3DMAX软件制作的三维动画可以导入AE中进行特效合成，并制作出具有创意的片花、导视等。 先修课程：《影视图像处理》、《影视特效合成》 平行课程：《数字视频编辑》、《三维动画制作》 后续课程：《电视节目创作与制作》 1.2课程设计理念 《栏目包装设计》课程设计注重职业核心能力打造，基于工作过程化的课程开发设计，实施“教、学、做”一体化的教学。以职业能力培养为重点，以岗位工作任务为依据，采用企业真实项目与校园电视台虚拟项目，整合序化教学内容。以校个合作为平台，创新教学方法与手段。实现教学与工作、理论与实践深度融合，提高学生的职业能力。
流媒体技术简介 流媒体技术（Streaming Media Technology）是为解决以Internet为代表的中低带宽网络上多媒体信息（以视音频信息为重点）传输问题而产生、发展起来的一种网络新技术。采用流媒体技术，能够有效地突破低比特率接入Internet方式下的带宽瓶颈，克服文件下载传输方式的不足，实现多媒体信息在Internet上的流式传输。Microsoft、Intel、apple、RealNetworks等公司在流媒体技术的发展、应用等方面都具有很强的实力。 一、流媒体技术原理 1．流媒体 "流媒体"的概念包括以下两个层面。其一，流媒体是计算机网络（尤其是中低带Internet／Intranet）上需要实时传输的多媒体文件，比如声音、视频文件。在传输前需要压缩处理成多个压缩包，并附加上与其传输有关的信息（比如，控制用户端播放器正确播放的必要的辅助信息），形成实时数据流。数据流最大的特点是允许播放器及时反应而不用等待整个文件的下载。其二，流媒体是对多媒体信息进行"流化"处理，是一种解决问题的方式，可以使视频等对实时性要求严格的多媒体文件在Internet／Intranet上在既无下载等待需求又不占用客户端硬盘空间的情况下保证实时播放。 目前Internet上比较流行的流媒体有RealNetworks的Realmedia、Microsoft的WindowsMedia以及Apple公司的Quicktime，它们包括不同的媒体内容，具有不同的流格式（StreamingFormat），都有专用的播放器。以目前网上最常见的RealMedia为例，其中包括RealVideo、RealAudio、RealFlash（RealNetworks公司与Macromedia公司新近合作推出的一种高压缩比动画格式），专用播放器是RealPlayer。传输过程中通过MIME （MultiPurposeInternetMailExtensions，多用途邮件扩展）识别流媒体类型。 2.流媒体技术体系的关键技术--压缩编码技术 压缩编码技术是流媒体技术体系中的关键技术。压缩编码的基本原理是采用一定的编码方式，将文件的数据结构进行重组，一方面，去掉一些重复或占而不用的空间，以达到减小文件尺寸的目的；另一方面，将文件分成压缩包，形成数据流，将原有的多媒体文件转化为具有流格式的流媒体。 例如，Microsoft采用MPEG4（最新版本为版本3）视频压缩编码算法，能够基于视频内容编码，生成ASF格式流媒体，同时支持多带宽、高带宽视频压缩编码，可以针对不同的网络环境生成包含几种不同传输速率数据流的视频流，为高级流技术的运用提供了可能性。 3．流式传输 以视频文件为例，压缩处理后的视频文件被分成一些小片段（CliP），当用户端发出请求后，由服务器向用户端连续、实时传送这些小片段，用户端利用解压设备（播放器）对压缩过的视频片段解压后进行播放和观看。在用户端播放小片段之前，这些小片段已经存入用户机的内存，而在播放前一片段的同时，后续片段继续在后台从服务端以
麦冬包装设计说明书 产品名称：麦冬饮片 产品属性：保健饮品 产品介绍： 滋阴润肺，生津止咳，清心除烦, 又有促进胰岛细胞功能恢复、增加肝糖原、降低血糖的作用。由于麦冬还有补心之作用，对糖尿病合并心脏病者也是有益的。 【功能与主治】麦冬养阴生津，润肺清心。用于肺燥干咳，虚痨咳嗽，津伤口渴，心烦失眠，内热消渴，肠燥便秘，咽白喉。 麦冬泡茶用于天气过干燥是很合适的。 麦冬又名沿阶草、书带草，为百合科沿阶草属多年生常绿草本植物。须根较粗壮，根的顶端或中部常膨大成为纺锤状肉质小块。叶丛生于基部，狭线形，长10—30厘米，宽因品种不同粗细有异。花茎常低于叶丛，稍弯垂，花淡紫色总状花序，花期5—9月。果蓝色。本品为百合科植物麦冬. 的干燥块根。 【性状】本品呈纺锤形，两端略尖，长1.5～3cm，直径0.3～0.6cm。表面黄白色或淡黄白，有细纵纹。质柔韧，断面黄白色，半透明，中柱细小。气微香，味甘、微苦。 【性味与归经】甘、微苦，微寒。归心、肺、胃经。 【功能与主治】养阴生津，润肺清心。用于肺燥干咳，虚痨咳嗽，津伤口渴，心烦失眠、内热消渴，肠燥便秘，咽白喉。 【贮藏】置阴凉干燥处，防潮。
目标消费人群：大众消费 销售渠道：各大药店，超市，专卖店 品牌形象：海报设计 产品包装分类：大包装，分包装 创意由来：涪城麦冬，又名川麦冬、绵麦冬，产于四川省三台县，产区主要集中在三台县涪江流域以花园镇为中心的九个镇（乡）。涪城麦冬是中国名贵传统中药材之一，已有500多年的种植历史。它具有养阴润肺，清热除烦，益胃生津，凉血止血等功效。2006年，国家质检总局批准对涪城麦冬实施地理标志产品保护。 涪城麦冬含氨基酸、三种以上寡糖和一种以上中性多糖、九种以上高异黄酮类化合物及葡萄糖甙、七种以上甾体皂甙和维生素A、B、C、D等30余种对人体有益的化合物。具有润肺养阴、益胃生津、清心除烦、凉血止血、美颜益肤、强身健体等功效。入药可治病，入茶可防疾和产、美颜益肤。还可深度加工配伍针剂、饮片、饮品以满足人们多方面生活的需要，是纯天然保健、滋补珍品。 医学权威专家和国家特级品茶大师吴登方曾赞誉“涪城麦冬”称：其主要成份、药用价值绝不亚于“长白山参”。今有“涪城麦冬千金宝，本草遗株万国珍”之说。古今中外人士均以“名贵中药材”相称，其块根、须、茎叶均有巨大的开发利用潜力，市场前景非常广阔。
产品包装设计》课程教学大纲 （适用对象：平面设计专业大专学生学分：3.5 学时：70） 一、课程简介 《产品包装设计》课程是电脑艺术设计专业的专业课。通过对本课程的教学，要求学生了解国内外包装发展趋势。掌握包装设计的表现技法和工艺方法。掌握包装设计的分类法，能从形态、材料、技法等方面进行分析。 了解当前包装设计的解决方案，了解包装历史、包装技术、包装材料、包装设备及运输的相关知识，掌握包装功能、包装设计的基本原则和包装装潢艺术等方面的知识。了解国家制定的相关法律法规，如《包装法》、《商标法》、《知识产权法》等。掌握包装结构设计、容器设计、商标及品牌、帖签的设计以及包装盒的装潢设计、系列化设计、组合设计等基本规律和技能。 二、课程的教学目的 通过结合典型实例来讲述的包装理论与技术，及大量实例练习，使学生在了解诸如包装造型、容器造型、装潢设计以及印刷工序、印刷成本核算等相关知识的同时把握当前包装装潢及相关行业发展的最新方向。同时，使学生对包装流程中的市场调研、包装材料、包装技术、印刷流程以及运输、销售和计算机制作过程有系统了解。使学生的作业创作和市场相结合，创作出实用、富有个性、具有审美价值的包装设计作品。 三、课程的教学要求 1、包装的基本概念及发展 了解包装的起始及历史发展（结合图片资料讲述）；了解包装概念及包装概念的扩展；了解包装功能的转移。 2、包装与时代 了解包装设计的发展和所发挥的作用；了解产品包装在不同的时代所具备的不同特点（结合大量实例讲述） 3、现代包装形式特点与规律
掌握现代包装形式特点与规律。通过做造型练习来了解包装设计中的色彩、外观造型、材质等不同所产生的不同效果。 4、设计市场与工艺 了解产品包装设计的基本程序并做市场调研。对相关的资料进行分析及设计定位（包括比稿、定稿、包装材料特征、印刷工序及成本核算）。掌握包装的材质及各种功能性。 四、课程的重点和难点 1、包装的基本概念及发展 重点：了解产品包装的起始及历史发展；了解包装概念及包装概念的扩展；了解包装功能的转移。 难点：解释包装功能的转移是在何种条件和原因作用下所产生的。 2、包装与时代 重点：了解包装设计与时代发展变化并掌握包装时代性的特点。 难点：把包装时代性的特点与产品包装设计实践相结合。 3、现代包装形式特点与规律 重点：培养包装设计中设计表达的初步技能。 难点：如何培养和提高审美能力。 4、设计市场与工艺 重点：通过市场调研、理论分析、设计构思，最后完成讲评。 难点：在实践中培养自学能力、分析问题和解决问题的能力以及独立思考和独立工作的能力、创造性思维的能力以及动手制作的能力。 五、课程的教学方法 坚持理论与实践结合的实训教学方法，重在实际能力的培养。
互联网中的流媒体技术 概述 随着经济的进展和科学技术的进步，人类社会已进入了信息化的新时代。internet网的飞速进展，使人们对信息时代的网络经济有了全新的认识；每一次的创新，就有一次的飞跃；每一种业务的应用，确实是一次想象力的考查。 internet网的种种应用，都阻碍着人们的工作和生活，推动社会经济的进展，从而形成一个和能源、材料一样成为当今社会的三大支柱产业之一。而流媒体技术（streaming media）作为internet网的应用之一，自产生以来，就注定要被广泛应用。 什么是流媒体 互联网的普及和多媒体技术在互联网上的应用，迫切要求能解决实时传送视频、音频、运算机动画等媒体文件的技术，在这种背景下，因此产生了流式传输技术及流媒体。通俗的讲，在互联网上的视音频服务器将声音、图像或动画等媒体文件从服务器向客户端实时连续传输时，用户不必等待全部媒体文件下载完毕，而只需延迟几秒或十几秒，就能够在用户的运算机上播放，而文件的其余部分则由用户运算机在后台连续接收，直至播放完毕或用户中止操作。这种技术使用户在播放视音频或动画等媒体的等待时刻成百倍的减少，而且不需要太多的缓存。 流媒体指在internet/intranet中使用流式传输技术的连续时基媒体，如：音频、视频或多媒体文件，它在播放前并不下载整个文件，只将开始部分内容存入内存，其他的数据流随时传送随时播放，只是在开始时有一些延迟，其关键技术确实是流式传输。 与传统的单纯的下载相比较，流媒体具有明显的优点: 由于不需要将全部数据下载，因此等待时刻能够大大缩短； 由于流文件往往小于原始文件的数据量，同时用户也不需要将全部流文件下载到硬盘，从而节约了大量的磁盘空间； 由于采纳了rstp等实时传输协议，更加适合动画、视音频在网上的实时传输。
现居:广东-深圳 电话:邮箱 ? 曾担任系学生会外联部干部、系团总支组织部副部长、班级生活委员等，在学生工 作和外出拉赞助与商家联系的过程中，进一步大大提高了自己的办事和处事能力； ? 此外，还积极参加课外文体活动，各种社会实践活动和兼职工作等，以增加自己的 阅历，提高自己的能力，在工作中体会办事方式，锻炼口才和人际交往能力，以及 201309-201706 XXX 大学 艺术设计专业（本科） 专业课程：计算机应用基础，中国美术史，外国美术史，艺术设计史，设计素描，装饰色彩，传统纹样(图案)设计，图形设计(创意)，公共环境视觉设计，网页设计制作， 计算机辅助设计 ，室内设计，环境艺术设计 2015.11-2016.05 佳能珠海有限公司 包装设计 ? 产品文档制作管理：产品预算单;采购分解单;客户调查表;包装工艺指示单;稿件封样 ? 跟踪供应商相关产品生产，保证产品顺利生产 2015.04-2015.10 珠海一统科技有限公司 包装设计 ? 负责公司bom 表，ERP 材料录入； ? 负责公司OEM 客户需求包装更改或设计及内外箱制作； 【大学生英语四级】 【电子商务大赛一等奖】 【校三等奖学金】 【国家计算机二级】 【市场营销大赛二等奖】 【机动车驾驶证】 ? 熟练使用Microsoft office 办公软件，精通word 、Excel 、PPT 的各项操作，通过自 己设计出来的作品，上传到数字作品平台网站售卖，并获得年度优秀设计师称号； ? 熟悉电商平台的运营操作流程，擅长新媒体运营及营销策略的制定，具有运营过官方 微博和微信公众号的工作经历，另外熟悉SPSS 、绘声绘影的操作； 教育背景 工作经历 技能&证书 自我评价 R E S U M E
包装设计课程标准 课程编码：165209 课程类别：专业核心课 适用专业：广告设计与制作授课单位：艺术设计系 学时：72 编写执笔人及编写日期：陈新 2012|12|24 学分：4 审定负责人及审定日期：孙永明 开设时间：第4学期系主任及审定日期：年月 一、课程定位 1.课程性质与作用 课程的性质：课程是广告设计与制作专业的专业核心课程，是学科整合课程。本课程为产品造型设计专业的一门实践性、综合性较强的专业核心课程之一，通过对产品包装设计与制作的训练，掌握产品包装的调研、创意、设计、制作的相关知识，培养学生使用不同创意与表现方法完成包装设计的能力，通过具体制作实施完成包装设计的制作。 课程的作用：通过包装设计实训的教学，使学生了解包装设计在整个设计领域的地位与作用，能用科学的方法把复杂的包装设计现象还原为基本要素。利用包装在空间上的量与质的可变性，按一定的包装设计和构成各要素之间的互相关系，结合现代包装设计所追求的节约和绿色的环保理念，创造出新的艺术造型空间--理想的包装设计效果。从而使学生即能扎实的掌握包装设计理论知识，又能让学生通过本课程的实践教学环节的学习掌握商品包装的基本方法、设计创意和制作技术，从而适应岗位需求。实训教学以具体任务为驱动，工作项目为引领展开课程设计，结合企业生产流程设计教学情景，使课程达到以下作用。 （1）理论和实践结合紧密。课程教学一方面通过"讲授和练习"解决学生应知部分，另一方面通过"实习和实训"解决学生应会部分。 （2）紧跟包装技术的发展。特别是近几年国家在包装材料上更多的提倡节能环保的材料和不过度包装的整体趋势下，除教材建设应跟随技术的发展外，教师要随时掌握包装设计与制作技术的发展动态，及时更新教学内容，将最新生产技术和最先进的生产设备教给学生。 （3）完成学业和职业技能鉴定相结合。要求学生参与与之相关专业的考试，如：平面设计师、装饰美工技能鉴定等专业考试，装潢专业和广告专业学生100% 参加职业技能鉴定。 本课程前导课程是包装形式和设计制作流程的学习、后续课程是把平面设计原理运用到设计中。
摘要：Internet的迅猛发展和普及为流媒体业务发展提供了强大的市场动力，流媒体业务正日益普及，流媒体技术广泛应用于互联网信息服务的方方面面。首先介绍了流媒体技术的基础、基本原理以及流式传输的基本过程，接着重点介绍了流媒体技术在视频点播、远程教育、视频会议和Internet直播方面的应用，最后介绍了流媒体技术的发展现状和展望。 关键词：多媒体通信，多媒体业务，流媒体，流式传输，原理，应用，发展 随着现代网络技术的发展，网络开始带给人们形式多样的信息。从在网络上出现第一张图片到现在各种形式的网络视频、三维动画，人们的视听觉在网络上得到了很大的满足。但人们又面临着另外一种不可避免的尴尬：在网络上看到生动清晰的媒体演示的同时，不得不为等待传输文件而花费大量时间。为了解决这个矛盾，一种新的媒体技术应运而生，这就是流媒体技术。 流媒体是指在网络中使用流式传输技术的连续时基媒体，如音频、视频或多媒体文件。而流式传输技术就是把连续的声音和图像信息经过压缩处理后放到网站服务器上，让用户一边下载一边收听观看，而不需要等待整个文件下载到自己的机器后才可以观看的网络传输技术。 目前，在网络上传输音视频（A/V）等多媒体信息主要有下载和流式传输两种方案。一方面，由于音视频文件一般都较大，所以需要的存储容量也较大；同时由于受网络带宽的限制，下载这样的文件常常需要几分钟甚至几小时，所以采用下载方法的时延也就很大。而采用流式传输时，声音、图像或动画等时基媒体由音视频服务器向用户计算机连续、实时传送，用户只需经过几秒或数十秒的启动时延而不必等到整个文件全部下载完毕即可观看。当声音、图像等时基媒体在客户机上播放时，文件的剩余部分将在后台从服务器上继续下载。流式传输不仅使启动时延大大缩短，而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部下载完毕之后才能观看的缺点。一、流媒体技术基础 实现流式传输有两种方法：实时流式传输（Real-time streaming transport）和顺序流式传输（progressive streaming transport）。一般来说，如为实时广播，或使用流式传输媒体服务器，或应用实时流协议（RTSP）等，即为实时流式传输。如使用超文本传输协议（HTTP）服务器，文件即通过顺序流发送。采用哪种传输方法可以根据需要进行选择。当然，流式文件也支持在播放前完全下载到硬盘。 1.实时流式传输 实时流式传输总是实时传送，特别适合现场广播，也支持随机访问，用户可快进或后退以观看后面或前面的内容。但实时流式传输必须保证媒体信号带宽与网络连接匹配，以便传输的内容可被实时观看。这意味着在以调制解调器速度连接网络时图像质量较差。而且，如果因为网络拥塞或出现问题而导致出错和丢失的信息都被忽略掉，那么图像质量将很差。实时流式传输需要专用的流媒体服务器与传输协议。 2.顺序流式传输 顺序流式传输是顺序下载，在下载文件的同时用户可观看在线内容，在给定时刻，用户只能观看已下载的部分，而不能跳到还未下载的部分。由于标准的HTTP服务器可发送顺序流式传输的文件，也不需要其他特殊协议，所以顺序流式传输经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段，如片头、片尾和广告，由于这种传输方式观看的部分是无损下载的，所以能够保证播放的最终质量。但这也意味着用户在观看前必须经历时延。顺序流式传输不适合长片段和有随机访问要求的情况，如讲座、演说与演示；也不支持现场广播，严格说来，它是一种点播技术。
X X X 求职意向：包装设计 现居:广东-深圳 电话:17059645230 邮箱:1705964@https://www.doczj.com/doc/c03468258.html, ? 曾担任系学生会外联部干部、系团总支组织部副部长、班级生活委员等，在学生工作和外出拉赞助与商家联系的过程中，进一步大大提高了自己的办事和处事能力； ? 此外，还积极参加课外文体活动，各种社会实践活动和兼职工作等，以增加自己的阅历，提高自己的能力，在工作中体会办事方式，锻炼口才和人际交往能力，以及能够灵活处理突发事件； 201309-201706 XXX 大学 艺术设计专业（本科） 专业课程：计算机应用基础，中国美术史，外国美术史，艺术设计史，设计素描，装饰色彩，传统纹样(图案)设计，图形设计(创意)，公共环境视觉设计，网页设计制作，计算机辅助设计 ，室内设计，环境艺术设计 2015.11-2016.05 佳能珠海有限公司 包装设计 ? 产品文档制作管理：产品预算单;采购分解单;客户调查表;包装工艺指示单;稿件封样 ? 跟踪供应商相关产品生产，保证产品顺利生产 2015.04-2015.10 珠海一统科技有限公司 包装设计 ? 负责公司bom 表，ERP 材料录入； ? 负责公司OEM 客户需求包装更改或设计及内外箱制作； ? 协助完成电商详情及海报； ? 协助完成市场部名片设计及展会画册设计。 【大学生英语四级】 【电子商务大赛一等奖】 【校三等奖学金】 【国家计算机二级】 【市场营销大赛二等奖】 【机动车驾驶证】 ? 熟练使用Microsoft office 办公软件，精通word 、Excel 、PPT 的各项操作，通过自己设计出来的作品，上传到数字作品平台网站售卖，并获得年度优秀设计师称号； ? 熟悉电商平台的运营操作流程，擅长新媒体运营及营销策略的制定，具有运营过官方微博和微信公众号的工作经历，另外熟悉SPSS 、绘声绘影的操作； 教育背景 工作经历 技能&证书 自我评价 R E S U M E
包装设计技术培训
包装设计技术 时间地点：2010年10月20-21日上海 课程价格：2850元/人 培训对象： 课程详细： 【课程目标】 伴随着现代物流技术及供应链的发展，现代包装设计技术已经突破了传统包装设计技术的概念，除了保护产品在运输途中不受损坏外，还与物流及供应链成本管理及产品设计紧密联系起来。同时伴随着对外出口品种及出口量的快速增长及向发达国家出口产品的需要，对产品包装提出了越来越高的要求。此外随着我国及世界各国对环境保护要求的提高，包装在向着绿色环保、节能降耗的方向发展。你是否在为产品在运输过程中出现破损率高而导致的客户投诉而烦恼? 你是否在为降低包装成本而惮精竭虑? 你是否曾为运输过程中外包装完好无损而产品却出现了损坏而百思不得其解? 通过本课程的培训，可以帮助你解决在工作中遇到的这些困惑或你目前正关注的问题。本课程将包装设计与物流环境紧密联系，通过分析产品运输所经历的环境来设计包装，从而避免包装不足而造成产品损坏或包装过度而导致包装成本的升高。本课程详细讲解了包装设计从客户的产品包装需求开始到产品包装通过验证的全流程。包装设
计的六步法。包装设计的测试项目、测试方法及测试标准。新的包装设计理论及方法。并且介绍部分主要包装材料的性能及成本对比，以提高产品保护性能、降低包装成本、保护环境等。并且介绍包装成本分析及优化，包装破损案例分析，相关包装的国家行业标准及国际法规。一些特殊的包装需求: 如机械件的防锈要求、电子产品的ESD及电磁屏蔽要求、危险品包装及标识等。希望通过本课程的培训，可以为企业在降低产品运输破损率，降低包装成本，降低包装对环境的影响等方面有较大帮助。同时提高企业产品设计，包装设计能力，并使设计出的包装方案符合国家及国际的要求。 参加人员:包装设计工程师，产品设计工程师，工艺制造工程师，包装或物料管理主管，仓储经理，物流经理，工程经理等。 【课程大纲】 第一单元：运输包装概述 1.包装的基本功能 --保护、容装、搬运、交接&说明 2.包装类型 --销售包装、集合包装、运输包装 3.包装在供应链中的位置 --生产过程的终点，物流过程的起点 4.现代供应链环境下物流运输包装面临的挑战
设计说明书 一.产品调查：糕点（糕点类：绿豆糕.红豆糕.桂花糕香芋糕等等） 1.糕点介绍：糕点是指以米、面、豆类等为主要原料，并配以各种辅料、馅料和调味料，加工成一定形状后，再用烘、烤、蒸、炸等方法制熟的食品成品。糕点含有人们日常生活中所说的“点心”的意思，故它与餐饮行业中的面点小吃有些区别。糕点既可作为早点，又可作为茶点，还可以作为席间的小吃。糕点和餐饮行业中的面点可以说是同宗不同业。糕点在我国制作历史悠久，工艺精湛，加之各地所用的原料不同，口味各异，故而形成了众多的流派，其中主要有京式、苏式、广式、闽式、潮式、扬式、宁绍式、川式等等 2.糕点功效; 大多绿豆有清热，解毒，祛暑止渴、利水消肿、明目退翳、美肤养颜之功交。具有很高的营养价值，热量不大，多食不易发胖，其中有包含有镁、钙、维生素E、胡萝卜素、锰等微量元素，含有碳水化合物，食之易有饱腹感，有助于保持理想体重，保持人体健康，同时供给人体大量能量 3.产品分析：糕点是指以米、面、豆类等为主要原料，有时并配有各种辅料、馅料和调味料和脂质等，经烘烤而得，产品口感松软细腻，香醇可口，由于脂肪，含水量，淀粉等的含量较高，包装产品时，包装产品需密封，无菌，以防糕点发生细菌污染.氧化腐败产生难闻气味和有害物质危害人体健康。同时也要考虑产品包装的外观
及重量，方便消费者携带，要有环保意识，做到经济环保。共同推进社会进步。 二．包装盒的相关介绍： 1.包装盒名称及用途：糕点盒，用作绿豆糕，桂花糕，红豆 糕，灯芯糕之类糕点的包装 2.制作纸盒的材料与器材：彩色硬纸板（外包装）彩带剪 刀铂金纸或锡纸（内包装）直尺等 3．设计理念与设计思路 从上述产品分析中可以看出要做糕点包装需要满足以下主要两点： 1)密封保湿 2)便携美观环保经济 遵循以上两点我设计了这种糕点盒，采用传统的四边形，采用中空设计，给予产品相对较大的存放空间，包装产品是先用锡纸或箔纸将糕点包裹紧密，既可以防止氧化，又可防止水分的散失；外包装两层防护，内外两层共同作用，增强了包装的密封性；能最外层设计里一个抓耳，在其上钻孔系上彩带，方便消费者携带，提高了产品的美观度，增加了产品消费亮点，盒子主体为纸板，质轻，为消费者带来了方便。减少购物的负担。 纸盒结构简单大方，便于机械生产，降低生产成本。整体以绿色为主色调，色彩清新明丽，透出一种高贵、淡雅、清香的感觉，引起人们购买欲望，促进消费，同时，再生产的时候可以根
最新英语专业全英原创毕业论文，都是近期写作 1 广告的翻译 2 初中生英语听力理解的障碍因素及对策 3 粤菜翻译之“信达雅” 4 从西方讽刺剧看品特的威胁喜剧 5 试探吸血鬼文化的起源 6 从女性主义角度分析美国女性－－《律政俏佳人》 7 浅析科技英语的文体特点 8 小学英语语法任务式教学 9 论中国古典诗歌意象和意境英译——基于萨皮尔-沃夫假说 10 从电影《碟中谍》系列探讨美国式个人英雄主义 11 从中西文化差异的角度浅析商宴之道 12 浅析《黛西米勒》中男女主人公矛盾情感背后的文化冲突 13 汉英招呼语的对比研究 14 《野性的呼唤》的社会达尔文主义 15 文档所公布均英语专业全英原创毕业论文。原创Q 175 567 12 48 16 内向型与外向型性格对英语学习的影响 17 跨文化交际下的中英文禁忌语的对比研究 18 美国体育运动词语对美国英语的影响及语用分析 19 Jane Austen’s Opinion towards Marriage in Pride and Prejudice 20 “中式英语”和“中国英语”两个概念的区别研究：以公示语为例 21 A Comparison of the English Color Terms 22 从《暴风雨》看凯特?肖班的自由派女性主义思想 23 浅谈简奥斯丁《劝导》的反讽艺术 24 论英语广告中隐喻的翻译 25 英语运用中的歧义分析 26 比较《简爱》中女性“陈规形象”与《飘》中女性“新形象” 27 对于高中生英语学习感知风格的调查研究 28 英汉颜色词语义对比研究 29 《麦田里的守望者》主人公的性格分析 30 中西商务谈判中的跨文化因素研究 31 科技英语中名物化的功能 32 跨文化交际在英文电影赏析的应用 33 从奥巴马访华报道看中美媒体报道差异 34 英文姓名的起源和文化内涵 35 On Advertising Translation from the Perspective of Skopostheorie 36 Vocabulary Teaching Based on Pragmatic Approach 37 The Loneliness in Far From the Madding Crowd 38 《新成长的烦恼》影视字幕中文化负载词的英汉翻译策略 39 汉语外来词翻译的文化解析 40 The Comparison Between Chinese Numerical Idioms and English Numerical Idioms 41 英汉动物习语的对比研究
《吸血鬼日记》之我最喜爱的男角色 整整四季，我喜欢的角色不是英俊不凡的斯蒂芬、不是放浪不羁的达蒙、也不是那个混血小狼人taylor，我承认艾琳娜的弟弟杰米很帅，可是我不喜欢。 我爱尼克劳斯，爱他的孤独。上千年的寂寞，因为混血儿是吸血鬼和狼人的诅咒，他的兄弟姐妹都不喜欢他，就连父母亲也在千年之后复活想要杀死他。尽管他是个杀人不眨眼的恶魔，可是在万不得已要对自己的亲人下手时，他的内心还是万分挣扎。在他脸上你基本上不会看到恐惧和害怕（只有看到他父亲的时候，看过的人都知道），所有的事情都是他在抗，可他从来不表现出来，这就注定了他的孤独。 我爱尼克劳斯，爱他的坚定。他的双手沾满鲜血：普通人的、狼人的、吸血鬼的、女巫的...可是他依然坚定。为了创造自己的王国，为了自己的混血儿，对艾琳娜一干人等威逼利诱，即便是艾琳娜变成了吸血鬼无法给他提供血液来制造混血儿的时候他也没有放弃，他和斯蒂文一起努力寻找治愈艾琳娜的方法，他自愿牺牲自己的混血儿手下，尽管他只是为了自己，所有的一切都是他的坚定，包括杀了12个狼人和taylor妈咪的那场血腥之夜。 我爱尼克劳斯，爱他的情趣。尼克是个画家，他管自己的画叫做艺术品，可能是因为本人也是学过画画的，所以对他的这一爱好翘起来大拇指，尽管电视里的他和现实中的我都画的不怎么样，可我们依旧爱这这门艺术。 ... ... 尼克从出场就奠定了他得不到的爱情，他一直被视为反面角色，叙述者让代表“正义”的艾琳娜一派来反抗他，无可厚非，艾琳娜的死党卡罗琳是永远不会爱上他的，尽管在有几集中卡罗琳还是对他产生了怦然心动的感觉...尼克可以为了卡罗琳而放taylor一条生路，尼克可以用自己的血来救卡罗琳的狼人咬伤（不过那是他自己咬的），每次在卡罗琳面前他总是那么多优雅，即使他知道卡罗琳在欺骗他、敷衍他、甚至有目的性的托住他时，他也装作不知道来邀请她跳舞...尼克的爱是整个电视剧中最真实的，而斯蒂文、达蒙对艾琳娜的爱总让人感觉不真实，对艾琳娜的爱只是一个童话故事。 他从来都是为了自己而不是他人，作为一个吸血鬼始祖，漫长的生命让他阅历不凡，故事往往在尼克的回忆中才得以进行下去，尼克像一杯佳酿，越品越香...... 期待尼克劳斯能有一个好点的结局。
流媒体技术的原理、应用及发展 一．流媒体 流媒体又叫流式媒体，它是指商家用一个视频传送服务器把节目当成数据包发出，传 送到网络上。用户通过解压设备对这些数据进行解压后，节目就会像发送前那样显示出来。这个过程的一系列相关的包称为“流”。流媒体实际指的是一种新的媒体传送方式，而非一种新的媒体。所谓流媒体是指采用流式传输的方式在Internet播放的媒体格式。流式传 输方式则是将整个A/V及3D等多媒体文件经过特殊的压缩方式分成一个个压缩包，由视 频服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中，用户不必等到整个文件全部下载完毕，而是只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备(硬件或软件)对压缩的A/V、3D等多媒体文件解压后进行播放和观看。此时多媒 体文件的剩余部分将在后台的服务器内继续下载。 与单纯的下载方式相比，这种对多媒体文件边下载边播放的流式传输方式不仅使启动 延时大幅度地缩短，而且对系统缓存容量的需求也大大降低。在网络上传输音／视频等多媒体信息目前主要有下载和流式传输两种方案。实现流式传输有两种方法： ?实时流式传输（Real-time streaming transport） ?顺序流式传输（progressive streaming transport）。 一般来说，如为实时广播，或使用流式传输媒体服务器，或应用实时流协议（RTSP）等，即为实时流式传输。如使用超文本传输协议（HTTP）服务器，文件即通过顺序流发送。采用哪种传输方法可以根据需要进行选择。当然，流式文件也支持在播放前完全下载到硬盘。 （1）实时流式传输 实时流式传输总是实时传送，特别适合现场广播，也支持随机访问，用户可快进或后退以观看后面或前面的内容。但实时流式传输必须保证媒体信号带宽与网络连接匹配，以便传输的内容可被实时观看。实时流式传输需要专用的流媒体服务器与传输协议。 （2）顺序流式传输 顺序流式传输是顺序下载，在下载文件的同时用户可观看在线内容，在给定时刻，用户只能观看已下载的部分，而不能跳到还未下载的部分。由于标准的HTTP服务器可发送 顺序流式传输的文件，也不需要其他特殊协议，所以顺序流式传输经常被称作HTTP流式 传输。 顺序流式传输比较适合高质量的短片段，如片头、片尾和广告，由于这种传输方式观看的部分是无损下载的，所以能够保证播放的最终质量。但这也意味着用户在观看前必须经历时延。顺序流式传输不适合长片段和有随机访问要求的情况，如讲座、演说与演示；也不支持现场广播，严格说来，它是一种点播技术。 二、流媒体技术原理 流式传输的实现需要合适的传输协议。由于TCP需要较多的开销，故不太适合传输实时数据。在流式传输的实现方案中，一般采用HTTP／TCP来传输控制信息，而用实时传 输协议／用户数据报协议（RTP／UDP）来传输实时数据。 流式传输的实现需要缓存。因为一个实时音视频源或存储的音视频文件在传输中被分解为许多数据包，而网络又是动态变化的，各个包选择的路由可能不相同，故到达客户端的时延也就不同，甚至先发的数据包有可能后到。为此，需要使用缓存系统来消除时延和抖动的影响，以保证数据包顺序正确，从而使媒体数据能够连续输出。
简美包装设计简历 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】
工 作 经 验 XXX 包装设计 现 今 XXX 科技有限公司 | 包装设计 负责公司OEM 客户需求包装更改或设计及内外箱制作 2012- 2015 XXX 有限公司| 包装设计 产品文档制作管理：产品预算单;采购分解单;客户调查表;包装工艺指示单;稿件封样存档 跟踪供应商相关产品生产，保证产品顺利生产 完成前期与客户设计沟通工作，以便完成项目整体风格设计工作。 产品方案策划设计：产品文案搜集整理;产品瓶型包材选择;产品包装联 系 方 式 电话 : Email : 地址 : 武汉市、 个 人 简 介 教 育 经 历 2003 - 2005 XXX 大学 艺术设计 主修课程： 计算机应用基础，中国美术史，外国美术史，艺术设计史，设计素描，装饰色彩，传统纹样(图案)设计 专 业 技 能 成 果 证 书 其 他 说 明 兴 趣 爱 好 其他值得说明的和自己的职业有关系或者和自己学历有关系的说明 可以填写任何希望填写的内容 / 2013年获得会计师资格证 / 大三通过计算机八级考试 / 英语已过七级 / 十年驾龄 / 获得高级技工执业资格证书 会计证书 计算机八级 英语七级 驾驶证 技工执业 + 能够熟练使用 Adobe Illustrator 编辑矢量图 + 有多年Adobe Photoshop 的操作经验 + 对Adobe inDesign 有一定程度的了解 + 使用Adobe Flash 编辑动画超过10年经验 本人勤奋努力，思想积极向上； 专业基础知识扎实，爱好艺术； 爱好广泛，合作意识强； 看电影 听音乐 骑行 足球 / 喜爱各国大制作电影作品 / 热爱古典音乐 / 三次骑行西藏 / 会在周末参加业余足球比赛
今年英美剧里死了不少关键人物，这里是 IMDB 评选的前 11 名 我们痛恨悲剧，但不得不承认，有时候死亡永远比 happy ending 来的更震撼、感动、令人难忘。 这就是为什么 IMDB 年底专门做了一次电视剧最佳死亡场景的评选，一共 11 个角色之死，每个都可以用一个“最”来形容，最冷酷，最感动，最反转剧情……有些是国内观众熟悉的，《实习医生格蕾》中男神 Derek 之死，还有《权力的游戏》中的 Jon Snow。也有相对冷门的剧集，《复仇》、《为人父母》。但没看过也没关系，我们对“每次死亡”都给了尽可能详细的描述，相信你能感受到它们得以入选的原因。 最冷酷的死亡 剧集：《实习医生格雷》 Grey's Anatomy 人物：Derek Shepherd 《实习医生格雷》是中国观众最熟悉的老牌美剧之一。很多人都很爱 Derek Shepherd 这个角色，世界上最帅的脑外科医生，和女主上演童话般的爱情，公认的 Mr. Mcdreamy（男神）。 第 11 季中，他的死亡让剧迷们痛心。 他在路边拯救了几个车祸受伤的人，结果被卡车撞成重伤，送到医院之后，遇到差劲同行，没有帮他做 CT 就送进手术室，而值班医生又因为晚饭让他在手术室等了一个多小时。
这太讽刺了。因为他本人最会做这种手术，然而却无力拯救自己。过程中，Derek Shepherd 的意识是清醒的，医生到了，他的旁白：“你来迟了。” 有传闻说是因为制片人和演员帕特里克·德姆西有矛盾。但是他其实刚与剧组续了两年的约。或许这就是本剧送给观众的意外吧。 最令人震惊的死亡 剧集：《权力的游戏》 Game of Thrones 人物：Jon Snow 当第五季结束， Jon Snow 流着鲜血躺在雪中，我们不敢相信所看到的。虽然本剧令人痛苦的死亡太多，第一季的 Ned Stark，第三季的血色婚礼……但大家对KitHarington 饰演的这个善良、温暖、带着悲剧色彩的男人怀有特别的感情。如果他都不在了，似乎也真正会缺少点什么。 好在这方面，看来 George R.R. Martin 和 HBO 也同意。 第六季的预告和海报都透露，Jon Snow 还会“活”下去，即使不再以人类的身份。 主角光环还是存在的。即使是《权力的游戏》。
《包装设计》课程教学大纲 一、本课程在专业教学中的地位 《包装设计》是电脑美术设计、装潢艺术设计专业必修专业设计课程，是结合了各种专业设计课程内容，同时综合性很强的艺术设计学科。它既有视觉传达语言中的造型结构、图形、色彩、文字、编排等内容，又涉及到材料、印刷、工艺等技术环节还要结合消费心理学、市场营销学、技术美学等内容学科。该课程旨在使学生具备有效传达信息的艺术手段，使他们掌握如何按照美的形式、规律和法则，来提高审美意识和表现能力，从而开拓思路，增强创新意识，提高创新能力。这对最终实现产品销售起着至关重要的作用。 二、本课程教学目标和基本要求： 教学目标： 通过该课程的学习，培养学生对包装流程中的市场调研，包装材料，包装技术，印刷流程，以及运输、销售和计算机制作过程有系统了解。学生能从艺术设计的角度出发，根据商品的特点，销售方式，结合市场学、消费心理学，以及包装材料和生产方式，独立进行包装结构和容器造型、包装装潢的统一设计，并掌握系列化、礼品化商品的包装设计创意方法和表现技法。为其将来参加设计工作打下良好的基础。教学中应注意对学生高级技能培养，注重应用型人才的塑造。 本课程前续课程：平面构成、色彩构成、立体构成、图案、商标设计、字体与版式设计、装饰基础、摄影、书法等。 本课程后续课程：CIS、毕业实习、毕业设计 基本要求： 1、知识要求：全面了解包装历史、包装技术、包装材料、包装设备及运输的相关知识，掌握包装功能、包装设计的基本原则和包装装潢艺术等方面的知识。了解国家制定的相关法律法规，如《包装法》、《商标法》、《知识产权法》等。 2、技能要求：掌握包装结构设计、容器设计、商标及品牌、帖签的设计以及包装盒的装潢设计、系列化设计、组合设计等基本规律和技能。 三、本课程教学的基本内容和教学要求 教学时间：开设于第四学期，共6周，每周16课时，共计96课时。
流媒体练习题 一、选择题 1.不属于流媒体特点的是：（ D） A 启动延时大幅度缩短 B 对系统缓存容量的需求大大降低 C 流式传输的实现有特定的实时传输协议 D 一种新的媒体 2.流媒体的核心技术是： B A 流媒体的网络传输 B 数据压缩/解压缩技术 C 媒体文件在流式传输中的版权保护问题 D 视音频技术 3.不属于流媒体传输的网络协议的是： B A RTP B HTTP C RTSP D RTCP 4.下列描述中正确的是： A A 视频数据由RTP传输，视频质量由RTCP控制，视频控制由RTSP提供。 B 视频数据由RTCP传输，视频质量由RTP控制，视频控制由RTSP提供。 C 视频数据由RTP传输，视频质量由RTSP控制，视频控制由RTCP提供。 D 视频数据由RTSP传输，视频质量由RTCP控制，视频控制由RTP提供。 5.不属于数字音频格式的是： D A MIDI格式 B CD格式 C WAVE格式 D AVI格式 6.不属于流式传输方式与传统下载方式相比的优点的是： A A 成本低廉 B 启动延时短 C 对系统缓存容量的需求大大降低 D 流式传输的实现有特定的实时传输协议 7.下面四个选项中哪一个不是常见的流媒体应用：（ D ） A电视上网 B在线电台 (C）视频会议 D文件传输 8.流媒体的特点不包括：（ B） A 缩短启动延时 B只需占用很小带宽 C 对系统缓存要求低 D流式传输有特定的实时传输协议 9.windows media的组件不包括以下四个中的哪一个:（ C ） A windows media 工具 B windows media服务器 C windows media编码器 D windows media播放器 10.IPTV关键技术不包括（D ）
包装设计项目课程设计方案 (总课时144学时 项目一食品包装设计(24学时 一. 教学目标 最终目标:能对商品的类别分析和准确定位,并能确定设计目标; 了解商品包装知识和市场背景; 会对包装结构设计定位; 能根据客户需求进行包装艺术设计. 促成目标: 1、具有分析与判断产品分类的能力 2、熟悉前期市场调研与策略 3、熟悉包装设计的特征、材质、结构 4、具有包装设计创意、设计、制作和工艺能力 5、能根据客户需求进行包装艺术设计 二、工作任务 1、能对商品进行分析判断分类和比较 2、商品信息类别进行比较 3、选择商品进行市场调查分析并撰写报告 4、根据客户需求对食品进行包装艺术设计 三、活动设计 对食品进行包装设计
四、相关实践知识 1、掌握商品分类的方法 2、收集商品信息能力及图文归纳综合能力 3、商品包装材料的分类及选用 4、根据客户需求对包装设计的表现 五、拓展性知识 1、对商品分类收集整理 2、商品类别特征的分析判断 3、掌握包装设计基础知识与方法 4、应用文写作能力 5、对商品的表现能力 六、思考与练习(主要是围绕工作任务的练习 练习:制作食品包装设计平面展开图和效果图 模块1 认识食品包装的类别与定位(8学时 一、教学目标 最终目标:了解食品的各种类别和主要特性;熟悉包装设计基础和相关知识; 能根据商品包装的类别确定商品属性 促成目标: 1、熟悉食品包装的分类
2、熟悉食品包装的各类特性 3、能速写食品包装的图形资料 4、能编写制定检索商品类别的计划 5、熟悉包装设计要素与商品关系 6、熟悉食品包装设计的档次 7、熟悉商品与包装设计的工作程序 8、能选用有效的商品包装资料 9、能做好商品包装设计准备工作 二、工作任务 1、检索食品种类信息资料 2、编写食品商品包装设计的程序计划 3、整理食品包装设计类别资料 4、能对食品包装设计作出正确判断 5、寻找同品种同价值的商品包装定位 6、提出食品包装设计基本素材的申请计划 三、活动设计 1、参观学院包装工作室和相关商品网站 2、列出一份检索食品种类资料的清单和分析方法 3、到图书馆和相关商品网络了解商品信息