DE10150391A1 - Objektmodell und Verfahren zum Erfassen von Informationen - Google Patents

Objektmodell und Verfahren zum Erfassen von Informationen

Info

Publication number
DE10150391A1
DE10150391A1 DE10150391A DE10150391A DE10150391A1 DE 10150391 A1 DE10150391 A1 DE 10150391A1 DE 10150391 A DE10150391 A DE 10150391A DE 10150391 A DE10150391 A DE 10150391A DE 10150391 A1 DE10150391 A1 DE 10150391A1
Authority
DE
Germany
Prior art keywords
product
design
idea
interface
requirement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE10150391A
Other languages
English (en)
Inventor
Dan Matheson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CoCreate Software GmbH and Co KG
Original Assignee
CoCreate Software GmbH and Co KG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CoCreate Software GmbH and Co KG filed Critical CoCreate Software GmbH and Co KG
Publication of DE10150391A1 publication Critical patent/DE10150391A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]

Abstract

Objektmodell zum Erfassen von Informationen, die produktinnovationsbezogene Daten betreffen, mit einer Produktideeschnittstelle zum Erfassen einer Idee für ein Produkt in einem Produktideeobjekt und einer Gestaltungsalternativenschnittstelle zum Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von jeweiligen Gestaltungsalternative-Objekten.

Description

Die vorliegende Erfindung betrifft allgemein die Informati­ onsverwaltung und im besonderen ein System bzw. Objektmo­ dell und ein Verfahren zum Erfassen und Speichern von und Zugreifen auf Informationen, die während der Innovation ei­ nes Produktes in einer beständigen und werkzeugneutralen Form verwendet werden.
Produktentwicklung wird heutzutage von computerbasierten Anwendungen unterstützt, u. a. durch Textverarbeitungs- und Grafikwerkzeuge, Abwicklungswerkzeuge (Terminkoordinierung/­ Ablaufsteuerung) und Produktdatenverwaltungswerkzeuge. Der typische Produktentwicklungszyklus beginnt mit einer Idee für ein Produkt oder einer Verbesserung für ein Produkt, das ein Bedürfnis in der Industrie betrifft oder eine Lö­ sung für ein Problem darstellt. Ausgehend von der Produkt­ idee können unterschiedliche Entwürfe (Alternativgestaltun­ gen) untersucht werden und schließlich wird ein Entwurf bzw. eine Gestaltung ausgewählt, entwickelt/umgesetzt und implementiert. Während der Anfangsphasen des Produktent­ wicklungszyklus werden Textverarbeitungs-, Grafik- und Ab­ laufwerkzeuge oft verwendet, um Informationen wie Marketin­ ganalysen, projektierte Entwicklungsabläufe und Beschrei­ bungen und Begründungen, die bestimmten ausgewählten Ent­ würfen zugrunde liegen, zu erfassen. Während der Entwurfs- bzw. Gestaltungsphase werden die Gestaltung betreffende In­ formationen, wie die Gestaltungsspezifikationen und 3-D- Modelldaten, üblicherweise unter Verwendung eines CAD- Werkzeugs erfaßt. Während der Herstellung des Produkts wer­ den Informationen zur Teileverfolgung üblicherweise unter Verwendung eines PDM-Werkzeugs (PDM: Product Data Manage­ ment, Produktdatenverwaltung) erfaßt. Zur Veranschaulichung soll davon ausgegangen werden, daß ein Entwickler/Gestalter eine Idee für ein neues Produkt hat. Der Entwickler ist sich dabei mehrerer Anforderungen bewußt, die das Produkt erfüllen muß und hat einige Lösungsideen. Der Entwickler muß mehrere unterschiedliche Werkzeuge benutzen, um Dar­ stellungen unterschiedlicher Teile der Lösung zu erzeugen. Beispielsweise benutzt der Entwickler Microsoft Excel zum Erzeugen einer Kostenanalyse, Corel zur graphischen Dar­ stellung, SolidDesigner für ein erstes Raumbudget und Work- Manager von CoCreate zur Erzeugung einer ersten Funktion­ sorganisation.
Während es klar ist, daß unterschiedliche computerbasierte Werkzeuge die Erfassung von Informationen und das Verfolgen des Fortschritts eines Produktes unterstützen, weist der Stand der Technik einige Nachteile auf. Erstens existiert derzeit kein Werkzeug, das konkret zur Erfassung und Ver­ folgung von Ideen und Entscheidungen zu diesen Ideen wäh­ rend der Anfangsphasen der Produktentwicklung dient. Die Untersuchung von Ideen ist häufig eine Situation, in der viel Empirie bzw. Regula falsi (trial and error) betrieben wird. Um eine derartige Untersuchung erfolgreich verfolgen zu können, ist es notwendig, viele nur teilweise vollstän­ digen Informationsstrukturen, die Entscheidungen, einen Un­ tersuchungsweg weiterzuverfolgen oder aufzugeben, und die Erklärungen/Begründungen hinter diesen Entscheidungen zu erfassen. Es ist auch nützlich, die Absicht bzw. den Zweck einer bestimmten Lösungsalternative zu erfassen. Im Stand der Technik existiert kein einzelnes Werkzeug zum Erfassen und Verfolgen derartiger wichtiger Informationen ein­ schließlich der Beweggründe und Ziele eines Entwurfs, Fra­ gen, Ideen und Antworten, die während der Untersuchung des Entwurfs gestellt werden, und der gleichen Informationen bezüglich ebenfalls untersuchter Gestaltungsalternativen. Selbst wenn einige der Informationen unter Verwendung eines oder mehrerer unterschiedlicher Werkzeuge erfaßt wird, weil die Informationen nicht integriert oder einfach zugänglich sind, außer das bestimmte Werkzeug, das zur Erfassung der Informationen benutzt wurde, wird verwendet, werden des weiteren viele der anfänglichen Gestaltungsabsichten und Erklärungen/Beweggründe von Gestaltungsentscheidungen sowie die untersuchten Gestaltungsalternativen üblicherweise nicht effektiv erfaßt oder gehen mit Fortschreiten des Ent­ wicklungszyklus des Produkts verloren.
Zusätzlich werden im Stand der Technik alle entwurfsbezoge­ nen Informationen, die unter Verwendung eines bestimmten computerbasierten Werkzeugs erfaßt werden, üblicherweise nur über das zur Erzeugung der Daten verwendete Werkzeug gespeichert, verwaltet und abgerufen. Es gibt mehrere Grün­ de, warum die Möglichkeit, auf Daten, die von einem Werk­ zeug erzeugt wurden, unter Verwendung anderer Werkzeuge zu­ greifen zu können, vorteilhaft wäre. Insbesondere können die Informationen, die unter Verwendung eines Werkzeugs er­ faßt wurden, für unterschiedliche Menschen von unterschied­ lichen Einheiten, die unterschiedliche Aufgaben wahrnehmen, interessant sein. So können beispielsweise Informationen, die während des Entwurfs bzw. der Gestaltung eines Produkts erfaßt wurden, nicht nur für die Gestaltungsingenieure, sondern auch für die Herstellungs- und Testingenieure, Füh­ rungskräfte im Produktentwicklungsprozeß, Wartungstechni­ ker, Marketing- und Verkaufspersonal, Disponenten, Personal in der Auftragsverarbeitung, Website-Entwickler und -ver­ walter, Kunden, Zulieferer usw. nützlich sein.
Es existiert demnach ein Bedürfnis, Informationen zur Pro­ duktentwicklung, nachfolgend als "Innovationsinformationen" bezeichnet, einschließlich Produktideen, Gestaltungsalter­ nativen, Fragen und Antworten, die während des Innovations­ prozesses untersucht wurden, Entwurfsentscheidungen usw. zu erfassen, zu speichern und abzurufen. Es besteht auch ein Bedürfnis, die Innovationsinformation in einer werkzeugneu­ tralen Form zu erfassen, die jedem Werkzeug einen Zugriff auf die (und ggf. auch eine Modifikation der) Innovati­ onsinformationen gestattet. Ein derartiges Werkzeug würde die Verfolgung der graduellen Entwicklung vom Entwurf und Entscheidungen über den Entwurf über die Evolution des Pro­ dukts gestatten und dabei die funktionalen entwurfsbezoge­ nen Aspekte eines Produkts (anstatt wie im Stand der Tech­ nik lediglich die realisierten Konfigurationen des endgül­ tigen Produkts) erfassen und ein Verfolgen und Nachvollzie­ hen deren Entwicklung gestatten.
Demgegenüber wird erfindungsgemäß ein Objektmodell zum Er­ fassen von Informationen mit den Merkmalen des Anspruchs 1, ein Verfahren zum Erfassen von Informationen mit den Merk­ malen des Anspruchs 10 sowie ein Computerprogramm mit den Merkmalen des Anspruchs 18 vorgeschlagen.
Die vorliegende Erfindung besteht demnach aus einem System und einem Verfahren zum Erfassen und Speichern von und Zu­ greifen auf Innovationsinformationsdaten in einer beständi­ gen und werkzeugneutralen Form, die einen Datenzugriff durch jedes Werkzeug über eine öffentlich definierte Schnittstelle gestattet. Die Erfindung erfaßt den klaren inkrementalen Aufbau von Innovationsinformationen ein­ schließlich Produktideen, Gestaltungs- bzw. Entwurfsalter­ nativen, Fragen und Antworten, die während des Innovations­ prozesses untersucht wurden, Entwurfsentscheidungen usw. Die Innovationsinformationen sind in einer Form darge­ stellt, die unter Verwendung unterschiedlicher computerba­ sierter Anwendungen abgefragt und auf verschiedene Weisen wiedergegeben werden kann.
Die Erfindung erfaßt den evolutionären Aufbau von Informa­ tionen, die die Ausgangsidee und die Untersuchung eines Produkts über die Zeit betreffen. Während der Untersuchung eines Produkts werden viele Alternativen vorgeschlagen und erforscht. Es werden Entscheidungen gefällt, die Möglich­ keiten ausschließen. Mit Fortschreiten der Gestaltung und der Entwicklung ändern sich die gestellten Fragen und zuge­ hörigen Antworten unter dem Einfluß von umfassenden Ent­ scheidungen und dem Aufkommen von mehr ins Detail gehenden Fragestellungen. Teile der Produktdefinition bewegen sich mit unterschiedlicher Geschwindigkeit von der Idee zur vollständigen Definition. Das Innovationsinformationen- Objektmodell der Erfindung unterstützt das Verfolgen bzw. Nachvollziehen der funktionalen gestaltungsorientierten Aspekte des Produkts. Das gestaltungsorientierte Verfolgen stellt somit ein Zeitspektrum vom Untersuchen von Produkti­ deen bis zur vollständigen und für die Produktion freigege­ benen Produktdefinition bereit. Die Informationen entwic­ keln und gestalten sich graduell und werden mit fortschrei­ tendem Gestaltungsprozeß immer detaillierter. Die Möglich­ keit für Innovation ist gegeben, solange Fragen offen sind, die kreative Antworten erfordern. Die Auswirkung von Inno­ vation bewegt sich von global zu lokal, wenn Entscheidungen gefällt und Detailfragen angegangen werden.
Die vorliegende Erfindung umfaßt vorzugsweise ein Objektmo­ dell zur Verwaltung von Innovationsinformationen (nachfol­ gend kurz als IIM-Objektmodell bezeichnet), das unter­ schiedliche Objektmodelle erfaßt und speichert, die Infor­ mationsartikel und deren zugehörige Beziehungen in einer Objektmodelldatenbank umfassen. Jedes Objektmodell beinhal­ tet Informationen und Beziehungen, die über eine öffentlich definierte Schnittstelle zugänglich sind. In einer Ausfüh­ rungsform werden beim Speichern eines Objektmodells in die Objektmodelldatenbank unterschiedliche Typen von Informati­ onsartikeln bzw. Einzelinformationen, die in dem Objektmo­ dell zusammen mit ihren Beziehungen zu anderen Informati­ onsartikeln bzw. Einzelinformationen enthalten sind, in un­ terschiedlichen relationalen Datenbankdateien, die mit den Informationsartikeln verknüpft sind, gespeichert. Anwendun­ gen, die auf die Objektmodelldatenbank zugreifen, verwenden lediglich die definierte Objektmodellschnittstelle, was zu einer automatischen Trennung und Speicherung von Datenty­ pobjekten in einer beständigen werkzeugneutralen Form führt.
Die Erfindung erleichtert den Zugriff auf Informationen mittels jeglicher Anwendung über die definierten Objektmo­ dellschnittstellen, unabhängig davon, durch welche Anwen­ dung die Objekte erzeugt wurden. Dadurch entsteht kein "Be­ sitz" an den Daten durch eine Anwendung oder durch das Werkzeug, das die Daten erzeugt hat.
Die Erfindung erleichtert auch anspruchsvolle Suchen in den Objektmodellen, um interessierende Informationen aus der Gesamtheit der gespeicherten Informationen herauszuziehen. Die Erfindung ist in vielerlei Hinsicht vorteilhaft, ein­ schließlich der Möglichkeit für eine Mehrzahl von Menschen mit unterschiedlichen Aufgaben und Posten, auf die Informa­ tionen zuzugreifen und diejenigen Informationen herauszu­ ziehen, die ihrer Aufgabe bzw. ihrer Position entsprechen.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, daß die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im folgenden un­ ter Bezugnahme auf die Zeichnung ausführlich beschrieben.
Fig. 1 zeigt ein konzeptionelles Objektmodelldia­ gramm, das die Trennung von Informationsar­ tikeln und ihrer zugeordneten Beziehungen zu anderen Informationsartikeln darstellt.
Fig. 2 zeigt ein Blockdiagramm eines erfindungsge­ mäßen Objektmodells zur Verwaltung von Inno­ vationsinformationen.
Fig. 3 zeigt ein UML-Schnittstellendiagramm (UML: Unified Modelling Language), das eine bevor­ zugte Ausführungsform der Schnittstelle für das Objektmodell zur Verwaltung von Innova­ tionsinformationen (IIM-Objektmodell) für das in Fig. 2 gezeigte IIM-Objektmodell darstellt.
Fig. 4 zeigt ein Blockdiagramm der von dem IIM- Objektmodell der Fig. 2 unter Verwendung der in Fig. 3 definierten Schnittstellen erzeugten und unterhaltenen beständigen Speichereinheiten bzw. -entitäten.
Fig. 5 zeigt ein Anschauungsbeispiel einer relatio­ nalen Datenbankdatei, mit der eine erfin­ dungsgemäße Produktidee-Tabelle umgesetzt wird.
Fig. 6 zeigt ein Anschauungsbeispiel einer relatio­ nalen Datenbankdatei, mit der eine erfin­ dungsgemäße Produktanforderungen-Tabelle um­ gesetzt wird.
Fig. 7 zeigt ein Anschauungsbeispiel einer relatio­ nalen Datenbankdatei, mit der eine erfin­ dungsgemäße Gestaltungsalternativen-Tabelle umgesetzt wird.
Fig. 8 zeigt ein Anschauungsbeispiel einer relatio­ nalen Datenbankdatei, mit der eine erfin­ dungsgemäße Produktfunktion-Tabelle umge­ setzt wird.
Fig. 9 zeigt ein Anschauungsbeispiel einer relatio­ nalen Datenbankdatei, mit der eine erfin­ dungsgemäße Anforderungserfüllung-Tabelle umgesetzt wird.
Fig. 10 zeigt einen Produktidee-Dialog für eine er­ findungsgemäß umgesetzte grafische Benutzer­ schnittstelle.
Fig. 11 zeigt einen Produktanforderung-Dialog für eine erfindungsgemäß umgesetzte grafische Benutzerschnittstelle.
Fig. 12 zeigt einen Produktfunktion-Dialog für eine erfindungsgemäß umgesetzte grafische Benut­ zerschnittstelle.
Fig. 13 zeigt einen Gestaltungsalternativen-Dialog für eine erfindungsgemäß umgesetzte grafi­ sche Benutzerschnittstelle.
Fig. 1 zeigt ein konzeptionelles Blockdiagramm, das die Trennung von Informationsartikeln bzw. Informationsgegen­ ständen bzw. Einzelinformationen und deren zugehörigen Be­ ziehungen zu anderen Informationsartikeln sowie die Zu­ greifbarkeit auf die Informationen mittels unterschiedli­ cher Werkzeuge darstellt. Insbesondere sind eine Ansammlung von Objektmodellen 10a, 10b, 10c, 10d, 10e und 10f, die In­ formationen und von einer Anzahl unterschiedlicher Werkzeu­ ge 20a, 20b, 20c, . . ., 20n während der Entwicklung eines Produktes erzeugte Objektbeziehungen beschreiben, in werk­ zeugneutraler Form in einem beständigen Speicher 30 gespei­ chert. Dabei ist es wichtig, daß die Objektmodelle 10a, 10b, 10c, 10d, 10e und 10f nicht einem bestimmten Werkzeug "gehören", insbesondere nicht den Werkzeugen 20a, 20b, 20c, 20n, von denen sie erzeugt wurden. Jedes Objektmodell 10a, 10b, 10c, 10d, 10e und 10f enthält Objekte, die höchst abhängige Objektbeziehungen aufweisen.
Die Objektmodelle 10a, 10b, 10c, 10d, 10e und 10f verfügen jeweils über eine definierte öffentliche Schnittstelle, die es einem jeden die Schnittstellendefinition verstehenden Werkzeug 20a, 20b, 20c, . . ., 20n gestattet, zulässige Daten in den entsprechenden Satz von Objekten zu schreiben und herauszulesen. Auch wenn die Situation eintreten kann, daß lediglich ein Anwendungswerkzeug ein einzelnes Attribut vollständig versteht (wie ein CAD-Werkzeug, das eine 3D- Geometrie und -topologie versteht), gestattet es die öf­ fentliche Schnittstellendefinition im Grunde genommen jedem Werkzeug, auf Teile des Objekts, das es versteht, ein­ schließlich dessen Beziehungen zu anderen Objekten, zuzu­ greifen. Beispielsweise erzeugt das CAD-Werkzeug (CAD TOOL) 20a (bspw. SolidDesigner von CoCreate) Daten, die teilweise in dem Objektmodell "CAD-Modell" (CAD MODEL) 10a und teil­ weise in dem Objektmodell "Produktstruktur" (PRODUCT STRUCTURE) 10b gespeichert werden. Es ist wichtig festzu­ halten, daß das CAD-Werkzeug 20a seine interne Datenstruk­ tur oder seine Benutzerschnittstelle nicht ändern muß. Vielmehr muß das CAD-Werkzeug 20a lediglich die Fähigkeit besitzen, nur diejenigen Objekte und Strukturen zu verste­ hen, die es schreibt und liest, was durch Verwenden einer Erweiterung erreicht werden kann, die eine Im­ port/Exportfähigkeit gestattet; derartige Techniken sind im Stand der Technik gut bekannt. In dem vorliegenden Beispiel greift ein PDM-Werkzeug (PDM TOOL) 20b (PDM: Product Data Management; bspw. WorkManager von CoCreate) auf das Modell "Produktstruktur" 10b und das Modell "Gestaltungsalternati­ ve" (DESIGN ALTERNATIVE) 10c zu. Entsprechend muß das PDM- Werkzeug 20b die Fähigkeit besitzen, an dem Modell "Pro­ duktstruktur" 10b von dem CAD-Werkzeug 20a vorgenommenen Änderungen handhaben zu können, und entsprechend muß das CAD-Werkzeug 20a die Fähigkeit besitzen, von dem PDM- Werkzeug 20b an dem Modell "Produktstruktur" 10b vorgenom­ menen Änderungen handhaben zu können. Das gemeinsame Ob­ jektmodell (d. h. das Modell "Produktstruktur" 10b), das beide verstehen, unterstützt und verbessert dabei die Kol­ laboration zwischen dem CAD-Werkzeug 20a und dem PDM- Werkzeug 20b.
Es ist auch wichtig festzuhalten, daß anderen Werkzeuge (bspw. 20n) auch jederzeit auf die Objektmodelle 10a, 10b, 10c, 10d, 10e und 10f zugreifen können und die Anzahl von Objektmodellen 10a, 10b, 10c, 10d, 10e und 10f jederzeit erweitert werden kann. So erweitert und entwickelt sich die Sammlung von Informationen und Beziehungen mit anderen Ob­ jekten entsprechend während des Fortgangs des Produktzy­ klus, wobei die Entwicklungs- und Gestaltungsaspekte des Produkts festgehalten werden. Zudem gestattet die werkzeug­ neutrale beständige Form der Objektmodelle sowohl synchrone als auch asynchrone Kollaboration bei der Produktentwick­ lung, indem vielen unterschiedlichen Benutzern (bspw. Inge­ nieure, Entscheidungsebene, Verwaltungspersonal und sogar Kunden) mit entsprechender Berechtigung zum Zugriff auf die in den Objektmodellen enthaltenen Daten, die den derzeiti­ gen Stand des Produkts darstellen, gestattet ist.
Unter den Objektmodellen in der Objektmodelldatenbank 30 befindet sich ein Objektmodell "Verwaltung von Innovati­ onsinformationen" (INNOVATION INFORMATION MANAGEMENT) 10e (kurz: IIM-Objektmodell), das all diejenigen Innovationsin­ formationen einschließt bzw. zusammenfaßt, die mit der Ent­ wicklung und Gestaltung eines Produkts, einschließlich Pro­ duktideen, Gestaltungsalternativen, Fragen und Antworten, die während des Innovationsprozesses untersucht wurden, Ge­ staltungsentscheidungen usw., verbunden sind sowie ihre Be­ ziehungen zu anderen Objekten in dem IIM-Objektmodell 10e und zu Objekten in anderen Objektmodellen 10a, 10b, 10c, 10c, 10d und 10f.
Objekte in dem IIM-Objektmodell 10e können automatisch von einem oder mehreren der Werkzeuge 20a, 20b, 20c, ..., 20n erzeugt werden, oder sie können konkret von Nutzern über spezifische IIM-Dialoge (IIM: Innovationsinformationen- Management/Innovation Information Management) erzeugt wer­ den, auf den über die Benutzerschnittstelle der Werkzeuge zugegriffen wird. Zusätzlich kann ein IIM-Werkzeug (TOOL) 20c zur konkreten Eingabe von Innovationsinformationsdaten entwickelt werden. Wie jedoch schon vorstehend angemerkt wurde, "gehören" keinem Werkzeug die Daten in dem IIM- Objektmodell 10e und jedes Werkzeug kann auf die Daten in dem IIM-Objektmodell 10e über öffentlich definierte Schnittstellen, die mit dem IIM-Objektmodell 10e in Verbin­ dung stehen, zugreifen. Diese öffentlich definierten Schnittstellen werden nachfolgend noch ausführlich erläu­ tert.
Fig. 2 zeigt ein Blockdiagramm, das eine bevorzugte Aus­ führungsform 100 des IIM-Objektmodells der Fig. 1 dar­ stellt, durch das ein Objektmodell zum Erfassen und Spei­ chern der einzelnen Informationen und deren Struktur, wie sie während der Untersuchungsphase der Entwicklung und Ge­ staltung eines Produkts in einer werkzeugneutralen bestän­ digen Form entwickelt wurden, bereitstellt.
Wie in Fig. 2 dargestellt umfassen die hauptsächlichen In­ formationsgegenstände in dem IIM-Objektmodell 100 die fol­ genden Objekte: Produktidee (PRODUCT IDEA) 110, Produktan­ forderung (PRODUCT REQUIREMENT) 120, Gestaltungsalternative (DESIGN ALTERNATIVE) 130, Gestaltungsdarstellung (DESIGN REPRESENTATION) 140, Produktfunktion (PRODUCT FUNCTION) 150, Durchführungsbeschränkung (REGULATORY CONSTRAINT) 160, Gestaltungsabsicht (DESIGN INTENT) 170, Gestaltungsmerkmal bzw. Gestaltungsbedeutung bzw. Gestaltungsanmerkung (DESIGN NOTE) 180, Gestaltungsproblem (DESIGN ISSUE) 190 und Ge­ staltungsbeschränkung (DESIGN CONSTRAINT) 195.
Ein Informationsgegenstand (oder Informationsobjekt) "Pro­ duktidee" 110 schließt eine Idee betreffend ein Produkt ein. Eine Produktidee kann eine Idee für ein neues Produkt, eine Steigerung oder Verbesserung eines bestehenden Pro­ dukts oder die Lösung eines bekannten Problems (wie eine technische Änderung) für ein bestehendes Produkt sein.
Ein Objekt "Produktanforderung" 120 beinhaltet eine Anfor­ derung, die das Produkt erfüllen muß, soll oder kann. Für ein gegebenes Produkt gibt es üblicherweise viele Anforde­ rungen von vielen verschiedenen Quellen (bspw. Marketing, Kunden, Entwicklung, Herstellung).
Ein Objekt "Gestaltungsalternative" 130 faßt Informationen zusammen, die eine mögliche Lösung oder Gestaltung für eine Idee darstellen, die in einem Objekt "Produktidee" 110 zu­ sammengefaßt ist. Ein Objekt "Gestaltungsdarstellung" 140 beinhaltet eine Möglichkeit, die in einem Objekt "Gestal­ tungsalternative" 130 dargestellte vorgeschlagene Lösung oder Gestaltung umsetzen bzw. herstellen.
Ein Objekt "Produktfunktion" 150 beinhaltet eine Funktion zum Lösen einer Produktanforderung.
Ein Objekt "Durchführungsbeschränkung" 160 beinhaltet eine Beschränkung, die dem Produkt auferlegt ist und sich außer­ halb der Kontrolle der Entwickler/Gestalter befindet. Als Beispiel seien hier gesetzlich festgelegte Kommunikations­ frequenzen im Funkbereich genannt.
Ein Objekt "Gestaltungsabsicht" 170 beinhaltet eine konkrete Absicht oder Zielsetzung der Gestaltung.
Ein Objekt "Gestaltungsmerkmal" 180 beinhaltet ein die Ge­ staltung betreffendes Merkmal.
Ein Objekt "Gestaltungsproblem" 190 ist mit einer Gestal­ tungsdarstellung verbunden. Das in einem Gestaltungspro­ blem-Objekt enthaltene bzw. zusammengefaßte Problem be­ trifft Bedenken oder eine offene Frage, die nach Betrachten der Darstellung der Gestaltungsalternative aufgekommen sind.
Ein Objekt "Gestaltungsbeschränkung" 195 faßt eine Be­ schränkung zusammen, die der Gestaltungsalternative aufer­ legt ist und über die Kontrolle besteht.
Innerhalb des IIM-Objektmodells 100 existieren Beziehungen zwischen den Datenobjekten, wie dies durch die Verbindungs­ linien zwischen den Objekten dargestellt ist. Z. B. kann je­ de Produktidee 110 mit verschiedene Produktanforderungen 120 (wie sie von den Entwicklern und anderen die Gestaltung beeinflussenden Personen definiert werden) verbunden sein, die wiederum keine oder mehrere zugeordnete Produktfunkti­ onsobjekte 150 aufweisen können, die vollständig oder teil­ weise die in ihrem zugeordneten Produktanforderungsobjekt 120 niedergelegten bzw. zusammengefaßten Anforderungen er­ füllen. Jede Produktidee 110 kann auch mit einigen Durch­ führungsbeschränkungen 160 (wie sie bspw. durch die Indu­ strie oder den Gesetzgeber definiert sein können) verbunden sein, die wiederum durch eine Produktanforderung 120 wie vorstehend beschrieben dargestellt sein können. Jede Pro­ duktidee 110 kann auch mit mehreren Gestaltungsalternativ­ objekten 130 verbunden sein, die wiederum mit Gestaltungs­ absichtsobjekten 170 und zugeordneten Produktfunktionsob­ jekten 150 verbunden sein können. Außerdem kann jede Ge­ staltungsalternative zugeordnete Gestaltungsbeschränkungen 195 und/oder zugeordnete Gestaltungsdarstellungen 140 auf­ weisen. Jede Gestaltungsdarstellung 140 kann zugeordnete Gestaltungsbemerkungen 180 und/oder Gestaltungsprobleme 190 aufweisen.
Fig. 3 zeigt ein UML-Schnittstellendiagramm, das eine be­ vorzugte Ausführungsform der IIM-Objektmodellschnittstelle für das IIM-Objektmodell 100 der Fig. 2 darstellt. Wie in Fig. 3 dargestellt umfassen die für das IIM-Objektmodell 200 der Fig. 2 definierten öffentlichen Schnittstellen folgendes: Produktidee (ProductIdea) 210, Produktanforde­ rung (ProductRequirement) 220, Gestaltungsalternative (De­ signAlternative) 230, Gestaltungsdarstellung (DesignRepre­ sentation) 240, Produktfunktion (ProductFunction) 250, Durchführungsbeschränkung (Regulatoryconstraint) 260, Ge­ staltungsabsicht (DesignIntent) 270, Gestaltungsbemerkung (DesignNote) 280, Gestaltungsproblem (DesignIssue) 290, Ge­ staltungsbeschränkung (DesignConstraint) 295 und Pro­ duktspezifikation (ProductSpecification) 225. Die Attribute für jede Schnittstelle sind wie in Fig. 3 dargestellt. In der IIM-Schnittstellendefinition werden Informationen über jede Produktidee in einem Objekt "Produktidee" 110 (Fig. 2) zusammengefaßt, auf das von der Schnittstelle ProductI­ dea 210 zugegriffen wird. In dieser Ausgestaltung hat die Schnittstelle ProductIdea 210 keine oder mehrere Schnitt­ stellen RegulatoryConstraint 260, von denen jede mit keiner oder mehreren Schnittstellen ProductRequirement 220 verbun­ den sein kann. Die Schnittstelle ProductIdea 210 kann auch eine Zuordnung zu keiner oder mehreren Schnittstellen Pro­ ductRequirement 220 aufweisen, die aus verschiedenen Quel­ len stammen können und eine angehängte Beziehung, die über die Schnittstelle RequirementRelationship 222 definiert ist, aufweisen können. Eine Schnittstelle ProductSpecifica­ tion 225 ist eine Erweiterung der Schnittstelle ProductRequirement 220 und wird dazu verwendet, Spezifikationen für die Anforderungen genauer zu definieren. Jede Schnitt­ stelle ProductRequirement 220 kann auch keiner oder mehre­ ren Schnittstellen ProductFunction 250 zugeordnet sein, die eine Lösung zum teilweisen oder vollständigen Erfüllen ei­ ner Produktanforderung bereitstellen. Die Schnittstelle ProductFunction 250 ist in der standardisierten Schnitt­ stelle PDMConfigurationManagement der "Object Management Group (OMG) PDM Enablers" definiert, die aus dem Stand der Technik bekannt und in "PDM Enablers: Joint Proposal to the OMG in Response to OMG Manufacturing Domain Task Force RFP 1", Paper mfg/98-02-02 of der Object Management Group (OMG), ausführlich beschrieben ist. Die Schnittstelle PDMConfigurationManagement erweitert den Produktstruktur- Enabler zur Unterstützung von Unternehmen, in denen ein Produkt zum Verkauf in vielen unterschiedlichen Komponen­ tenkonfigurationen angeboten werden kann. Das Konfiguratio­ nenverwaltungsmodul erlaubt eine Spezifikation von Produkt­ klassen und unterscheidenden Produktkonfigurationen. Ent­ sprechend ist das IIM-Objektmodell der Erfindung kompatibel mit den standardisierten PDM-Enabler-Schnittstellen.
Wie ebenfalls dargestellt kann die Schnittstelle Product­ Idea 210 keiner oder mehreren Schnittstellen DesignAlterna­ tive 230 zugeordnet sein, die einen Zugriff auf keine oder mehrere Objekte "Gestaltungsalternative" 130, die einem be­ stimmten Objekt "Produktidee" 110 zugeordnet sind, gestat­ ten. Jede Schnittstelle DesignAlternative 230 hat keine oder mehrere Schnittstellen DesignConstraint 295 und keine oder mehrere Schnittstellen DesignRepresentation 240, die jeweils Zugriff auf ein verbundenes Objekt "Gestaltungsein­ schränkung" 195 und/oder ein zugehöriges Objekt "Gestal­ tungsdarstellung" 140 gestatten. Jede Schnittstelle De­ signRepresentation 240 ist keiner oder mehreren Schnitt­ stellen DesignNote 280 zugeordnet, die Zugriff auf ein Ob­ jekt "Gestaltungsbemerkung" 180 gestatten, und mit keiner oder mehreren Schnittstellen DesignIssue 290, die Zugriff auf ein Objekt "Gestaltungsproblem" 190 gestatten.
Eine Schnittstelle RequirementFulfillment 255 gestattet, auf den Grad der Erfüllung der Produktanforderungen, die die Produktfunktion erfüllt, zuzugreifen. Dies gestattet einem Benutzer, das IIM-Objektmodell später im Hinblick auf diejenigen Gestaltungsalternativen, die bestimmte ggf. prioritätsgewichtete Anforderungen erfüllen, zu untersu­ chen, um zu ermitteln, welche Gestaltungsalternative einer Erfüllung der Anforderungen mit den höchsten Prioritäten am nächsten kommt.
Diese Fähigkeit, das System abzufragen, indem wichtige Fra­ gen gestellt werden, und eine automatische Antwort von dem IIM-Objektmodell zu erhalten, ist ein äußerst wichtiger Aspekt, der durch die Erfindung bereitgestellt wird.
Ein Satz von Entscheidungsschnittstellen gestatten einem Benutzer, unterschiedliche Entscheidungen, die während der Untersuchungsphase des Produkts getroffen wurden, zu erfas­ sen und aufzufinden. Bspw. gestattet eine Schnittstelle ProductRequirementDecision 215 das Auffinden von Fragen, Antworten und daraus resultierenden Entscheidungen, die mit Produktanforderungen verbunden sind. Eine Schnittstelle ProductFunctionDecision 235 gestattet das Auffinden von Fragen, Antworten und daraus resultierenden Entscheidungen, die mit der Verwendung von vorgeschlagenen Produktfunkti­ onslösungen in einer bestimmten Gestaltungsalternative ver­ bunden sind. Eine Schnittstelle DesignAlternativeDecision 275 gestattet das Auffinden von Fragen, Antworten und dar­ aus resultierenden Entscheidungen, die mit der Auswahl von Gestaltungsalternativen verbunden sind. Eine Schnittstelle DesignRepresentationDecision 245 gestattet das Auffinden von Fragen, Antworten und daraus resultierenden Entschei­ dungen, die mit der Auswahl in der Implementierung einer bestimmten Gestaltungsalternative verbunden sind.
Die in dem UML-Diagramm der Fig. 3 definierten Schnitt­ stellen sind vorzugsweise in einer objektorientierten Spra­ che wie C++ oder Java2 implementiert. Die tatsächliche Klassenimplementierung kann von System zu System variieren, da es häufig sinnvoll sein wird, einige der Schnittstellen aus Gründen einer effizienten Implementierung und/oder Lei­ stung (Performance) in einer einzelnen Klasse zusammenzu­ fassen.
Fig. 4 zeigt ein Blockdiagramm, das eine Ausführungsform der beständigen Speicherentitäten darstellt, die von dem IIM-Objektmodell 100 der Fig. 2 unter Verwendung der in Fig. 3 definierten Schnittstellen erzeugt und unterhalten werden. In dieser Ausführungsform ist mit jeder Schnitt­ stelle eine beständige Speicherdatei, vorzugsweise in Form einer relationalen Datenbank, verbunden. Die von der jewei­ ligen Schnittstelle eingeschlossenen Daten sind in der je­ weiligen zugehörigen relationalen Datenbankdatei gespei­ chert. Entsprechend gibt es eine separate relationale Da­ tenbankdatei für jede definierte Schnittstelle. In dem dar­ gestellten Ausführungsbeispiel speichert eine Tabelle "Pro­ duktidee" (PRODUCT IDEA TABLE) 310 alle verfügbaren Daten, die die Schnittstelle Productldea 210 verwenden, eine Ta­ belle "Produktanforderung" (PRODUCT REQUIREMENT TABLE) 320 speichert alle zugegriffenen Daten, die die Schnittstelle ProductRequirement 220 verwenden, eine Tabelle "Gestal­ tungsalternativen" (DESIGN ALTERNATIVE TABLE) 330 speichert alle zugegriffenen Daten, die die Schnittstelle DesignAl­ ternative 230 verwenden, eine Tabelle "Gestaltungsdarstel­ lung" (DESIGN REPRESENTATION TABLE) 340 speichert alle zu­ gegriffenen Daten, die die Schnittstelle DesignRepresenta­ tion 240 verwenden, eine Tabelle "Produktfunktion" (PRODUCT FUNCTION TABLE) 350 speichert alle zugegriffenen Daten, die die Schnittstelle ProductFunction 250 benutzen, eine Tabel­ le "Durchführungsbeschränkung" (REGULATORY CONSTRAINT TABLE) 360 speichert alle zugegriffenen Daten, die die Schnittstelle RegulatoryConstraint 260 verwenden, eine Ta­ belle "Gestaltungsabsicht" (DESIGN INTENT TABLE) 370 spei­ chert alle zugegriffenen Daten, die die Schnittstelle Desi­ gnIntent 270 benutzen, eine Tabelle "Gestaltungsbemerkung" (DESING NOTE TABLE) 380 speichert alle zugegriffenen Daten, die die Schnittstelle DesignNote 280 benutzen, eine Tabelle "Gestaltungsproblem" (DESIGN ISSUE TABLE) 390 speichert al­ le zugegriffenen Daten, die die Schnittstelle DesignIssue 290 verwenden. Zusätzlich speichern die Entscheidungstabel­ len "Produktanforderungsentscheidung" (PRODUCT REQUIREMENT DECISION TABLE) 315, "Produktfunktionsentscheidung" (PRODUCT FUNCTION DECISION TABLE) 335, "Gestaltungsdarstel­ lungsentscheidung" (DESIGN REPRESENTATION DECISION TABLE) 345, "Gestaltungsalternativenentscheidung" (DESIGN ALTER­ NATIVE DECISION TABLE) 375 jeweils die zugegriffenen Daten, die die Schnittstellen ProductRequirementDecision 215, Pro­ ductFunctionDecision 235, DesignRepresentationDecision 245 und DesignAlternativeDecision 275 benutzen. Eine Tabelle "Anforderungserfüllung" (REQUIREMENT FULFILLMENT TABLE) 355 speichert die zugegriffenen Daten, die die Schnittstelle RequirementFulfillment 255 benutzen. Die gestrichelten Li­ nien, die die unterschiedlichen Tabellen miteinander ver­ binden, stellen einen fremden Schlüssel (foreign key) dar (d. h. eine gemeinsame Spalte in jeder verbundenen relatio­ nalen Datenbank), der zur Darstellung der Beziehungen in den Tabellen gespeicherten Daten verwendet wird.
Fig. 5 ist ein Anschauungsbeispiel einer relationalen Da­ tenbankdatei 410, die eine Tabelle "Produktidee" 310 dar­ stellt. Wie dargestellt, bildet jede Spalte "Beschreibung" (Description) 501 und "Name" 502 auf ein in der Schnitt­ stelle ProductIdea 210 eingeschlossenes bzw. enthaltenes Attribut ab bzw. verweist auf dieses, und jede Reihe bildet auf ein unterschiedliches Objekt "Produktidee" 110 ab.
Fig. 6 zeigt ein Anschauungsbeispiel einer relationalen Datenbankdatei 420, die eine Tabelle "Produktanforderung" 320 umsetzt. Wiederum bildet jede Spalte "Produktideenname" (Product Idea Name) 601, "Beschreibung" (Description) 602, "Name" 603, "Kennung" (ID) 604, "Priorität" (Priority) 605 und "Gewichtung" (Weight) 606 jeweils auf ein in der Schnittstelle ProductRequirement 220 eingeschlossenes bzw. enthaltenes Attribut ab bzw. verweist auf dieses, und jede Reihe bildet ein unterschiedliches Objekt "Produktanforde­ rung" 120 ab. In diesem Beispiel ist der Primärschlüssel (d. h. ein einziges Schlüsselfeld (Identifier) für die ge­ samte Datei) für jedes Objekt "Produktanforderung" 320 des­ sen Produktanforderungserkennung (in dieser Ausführungsform in Spalte 603 gespeichert). Das Attribut "Produktideename" des Objekts "Produktidee", mit dem das Objekt "Produktanfor­ derung" 120 verbunden ist, wird als fremder Schlüssel bzw. Kennbegriff verwendet. Entsprechend wird eine Spalte "Frem­ der Schlüssel" 601 bereitgestellt, um jeweilige Objekte "Produktanforderung" auf die zugeordneten Objekte "Produk­ tidee" abzubilden.
Fig. 7 zeigt ein Anschauungsbeispiel einer relationalen Datenbankdatei 430, die eine Tabelle "Gestaltungsalternati­ ve" 330 umsetzt. Die Tabelle umfaßt die Spalten ("Produkt­ ideenname" (Product Idea Name) 701, "Beschreibung" (Descrip­ tion) 702, "Name" 703, "Status" 704, "Statusgrund" (Status Reason) 705 und "Geschichte" (History) 706. In diesem Bei­ spiel wird das Attribut "Produktideenname" des Objekts "Pro­ duktidee", dem das Objekt "Gestaltungsalternative" 130 zu­ geordnet ist, als fremder Schlüssel verwendet. Entsprechend wird eine Spalte "Fremder Schlüssel" 701 bereitgestellt, um jeweilige Objekte "Gestaltungsalternative" auf die zugeord­ neten Objekte "Produktidee" abzubilden.
Fig. 8 ist ein Anschauungsbeispiel einer relationalen Da­ tenbankdatei 450, die eine Tabelle "Produktfunktion" 350 umsetzt. Die Tabelle umfaßt die Spalten "Produktanforde­ rungskennung" (Product Requirement ID) 801, "Gestaltungsal­ ternativenname" (Design Alternative Name) 802, "Beschrei­ bung" (Description) 803, "Name" 804, "Relevanz" (is_relevant_for) 805. In diesem Beispiel wird das Attribut "Produktanforderungskennung" des Objekts "Produktanforde­ rung", dem das Objekt "Produktfunktion" 150 zugeordnet ist, als ein fremder Schlüssel und das Attribut "Gestaltungsal­ ternativenname" des Objekts "Gestaltungsalternative", dem das Objekt "Produktfunktion" 150 zugeordnet ist, als ande­ rer fremder Schlüssel verwendet. Entsprechend werden jewei­ lige Spalten "Fremder Schlüssel" 801 und 802 bereitge­ stellt, um Objekte "Produktfunktion" 150 auf ihre jeweili­ gen zugeordneten Objekte "Produktanforderung" 120 und "Ge­ staltungsalternative" 130 abzubilden.
Fig. 9 ist ein Anschauungsbeispiel einer relationalen Da­ tenbankdatei 455, die eine Tabelle "Anforderungserfüllung" 355 umsetzt. Die Tabelle umfaßt die Spalten "Produktfunkti­ onsname" (Product Function Name) 901 und "Prozent" (Per­ cent) 902. Wie dargestellt, bildet die Spalte 902 auf das Attribut "Prozent" ab, das über die Schnittstelle Require­ mentFulfillment" 255 eingeschlossen ist, und jede Reihe bildet auf ein anderes Objekt "Produktfunktion" ab. In die­ sem Beispiel wird das Attribut "Produktfunktionsname" des Objekts "Produktfunktion" 150 als fremder Schlüssel verwen­ det, entsprechend wird eine Spalte "Fremder Schlüssel" 901 bereitgestellt, um ein Objekt "Anforderungserfüllung" auf sein zugeordnetes Objekt "Produktfunktion" 150 abzubilden.
Die anderen in Fig. 4 dargestellten Tabellen sind in rela­ tionalen Datenbankdateien umgesetzt, die den in den Fig. 5 bis 9 dargestellten ähnlich sind.
Die Abläufe, durch die bestimmte IIM-Daten erfaßt werden, unterscheiden sich und sind abhängig davon, welcher Typ von Daten erfaßt wird. Daten können erfaßt werden, wenn ein Be­ nutzer Daten über eine Dialogschnittstelle manuell eingibt (bspw. wenn ein Benutzer eine Produktidee und zugeordnete vorgeschlagene Gestaltungsalternativen, Produktanforderun­ gen und/oder Produktfunktionen unter Verwendung eines Pro­ duktideedialogs in der Benutzerschnittstelle der Anwendung eingibt), oder können von einer Anwendung automatisch er­ zeugt werden (bspw. können Attribute wie Objektkennzeichner (Identifiers), Erzeugungszeit oder Datum der letzen Ände­ rung von der Anwendung zu dem Zeitpunkt, an dem eine Infor­ mation erfaßt oder geändert wird, automatisch erzeugt oder erfaßt werden). Fig. 10 zeigt beispielhaft einen Produkt­ ideedialog "Product Idea" 1000 einer grafischen Benutzer­ schnittstelle für eine allgemeine Anwendung, die die Fähig­ keit hat, auf ein erfindungsgemäßes IIM-Objektmodell 10e zuzugreifen und ein solches zu erzeugen. Wie dargestellt umfaßt der Produktideedialog 1000 Benutzermöglichkeiten zum Eingeben einer Beschreibung "Description" 1002 einer Pro­ duktidee und eines Namens "Name" 1004 für die Produktidee. Der Produktideedialog 1000 umfaßt auch Benutzermöglichkei­ ten (bspw. Knöpfe 1006 und 1008) zum Eingeben vorgeschlage­ ner Produktanforderungen ("Requirement" 1006) und Gestal­ tungsalternativen ("Design Alternative" 1008) für die Pro­ duktidee. Insbesondere wird ein in Fig. 11 dargestellter Produktanforderung-Dialog 1010 geöffnet bzw. eingeblendet, wenn der Benutzer auf den Knopf "Requirement" 1006 klickt. Wie in Fig. 11 dargestellt gestattet der Produktanforde­ rungdialog "ProductRequirement" 1010 dem Benutzer, eine Be­ schreibung ("Description") 1012 der Produktanforderung, ei­ nen Namen 1014 für die Produktanforderung und eine der Pro­ duktanforderung zugewiesene Priorität ("Priority Level") 1016 einzugeben.
Auf die Benutzermöglichkeit zum Eingeben einer oder mehre­ rer vorgeschlagener Produktfunktionen zum teilweisen oder vollständigen Erfüllen der Produktanforderung kann durch Klicken eines Knopfes "Function" 1018 zugegriffen werden, wodurch ein in Fig. 12 dargestellter Dialog "Product Func­ tion" 1020 geöffnet bzw. eingeblendet wird. Wie in Fig. 12 dargestellt, kann der Benutzer die Felder "Description" 1022 und "Name" 1024 der Funktion ausfüllen und wahlweise an das Funktionsobjekt einen definierten Abschnitt (der dem System bekannt ist) anhängen, der der Anwendung gestattet, automatisch ein Objekt "Anforderungserfüllung" 255 zu er­ zeugen, das angibt, wie gut die Produktfunktion die Produk­ tanforderung erfüllt. Unter "Function Definition" 1026 kann eine Funktionsdefinition eingegeben werden.
Fig. 13 zeigt beispielhaft einen Gestaltungsalternative- Dialog "Design Alternative" 1030, der von dem Dialog "Pro­ ductIdea" 1000 durch Klicken auf den Knopf "Gestaltungsal­ ternative" (Design Alternative) 1008 erreicht werden kann. Wie dargestellt, gestattet der Dialog "Design Alternative" 1030 einem Benutzer, eine Beschreibung ("Description") 1032 einen Namen 1034, einen Status 1036 und einen Grund ("Reason") 1038 für den Status 1036 einzugeben. Der Dialog "Design Alternative" 1030 kann auch einen Knopf "Produkt­ funktion" (Funktion) 1040 umfassen, der den Benutzer zu dem Produktfunktions-Dialog 1020 der Fig. 12 führt, sowie ei­ nen Knopf "Produktfunktionsentscheidung" (FunktionDecision) 1042, der einen (nicht dargestellten) Dialog öffnet bzw. einblendet, der dem Benutzer gestattet, eine Entscheidung über jede den Gestaltungsentwurf zugeordnete Produktfunkti­ on einzugeben.
Wie vorstehend ausführlich beschrieben wurde, stellt die Erfindung einen neuen Weg des Erfassens und Speicherns von sowie des Zugriffs auf Daten im Zusammenhang mit der Ver­ waltung von Innovationsinformationen dar, einschließlich dem inkrementalen Aufbau von Innovationsinformationen ein­ schließlich Produktideen, Gestaltungsalternativen, Fragen und Antworten, die während des Innovationsprozesses unter­ sucht wurden, Gestaltungsentscheidungen usw. Die Innovati­ onsinformationen werden in einer Form dargestellt, auf die in unterschiedlicher Weise zugegriffen werden kann und die auf unterschiedliche Weise darstellbar ist, unter Verwen­ dung von computerbasierten Anwendungen.
Die Erfindung erfaßt den evulotionären Aufbau von Informa­ tionen, die die ursprüngliche Idee (Ausgangsidee) und die Untersuchung eines Produkts über die Zeit betreffen. Wäh­ rend der Untersuchung eines Produkts werden viele Alterna­ tiven vorgeschlagen und erforscht. Entscheidungen werden gefällt, die Möglichkeiten ausräumen bzw. ausschließen. Mit fortschreitender Gestaltung ändern sich die gestellten Fra­ gen und zugehörigen Antworten, da umfassende Entscheidungen gefällt werden und detailliertere Fragestellungen auftre­ ten. Teile der Produktdefinition bewegen sich von dem Sta­ tus der Idee zu der fertigen Definition mit unterschiedli­ cher Geschwindigkeit. Das erfindungsgemäße Objektmodell zur Verwaltung von Innovationsinformationen unterstützt dabei das Auffinden bzw. Nachvollziehen der funktionalen Wie- Ausgeführt-Aspekte des Produkts. Dieses Auffinden stellt somit ein Zeitspektrum von der Untersuchung von Produktide­ en zu der vollständigen und für die Produktion freigegebe­ nen Produktdefinition bereit. Die Informationen entwickeln sich dabei graduell und werden mit fortschreitendem Gestal­ tungsprozeß detaillierter. Die Möglichkeit für Innovation ist so lang gegeben, so lange Fragen offen bleiben, die kreative Antworten benötigen. Die Auswirkung von Innovation bewegt sich von der umfassenden Ebene auf detailliertere Ebenen, wenn Entscheidungen gefällt werden und Details be­ rücksichtigt werden.
Die Erfindung vereinfacht den Zugriff auf Informationen durch jede Anwendung über die definierten Objektmodell­ schnittstellen, unabhängig davon, welche Anwendung die Ob­ jekte erzeugt hat. Somit "gehören" die Daten keiner Anwen­ dung und auch keinem Werkzeug, das die Daten erzeugt hat.
Die Erfindung vereinfacht auch anspruchsvolle Suchen in den Objektmodellen, um interessierende Informationen aus der Gesamtheit der gespeicherten Informationen herausfinden. Die Erfindung ist aus vielen Gründen vorteilhaft, ein­ schließlich der Tatsache, daß viele Benutzer mit unter­ schiedlichen Aufgaben auf eine Art und Weise, die ihrer je­ weiligen Aufgabe bzw. Bedeutung gerecht wird, auf die In­ formationen zuzugreifen und Informationen herauszuziehen.
Wie nach der Lektüre der vorstehenden ausführliche Be­ schreibung offensichtlich wird, verfügt die Erfindung über einige Vorteile gegenüber dem Stand der Technik. Das erfin­ dungsgemäße IIM-Objektmodell erhöht die Effizienz beim Nachvollziehen und Verstehen, wie und warum eine Produktge­ staltung eine derzeitige Konfiguration aufweist. Das erfin­ dungsgemäße IIM-Objektmodell gestattet das Erfassen und Nachvollziehen von funktionalen Wie-Gestaltet-Aspekten des Produkts anstelle der Wie-Ausgeführt-Konfiguration des end­ gültigen Produkts und stellt dadurch ein Zeitspektrum von der anfänglichen Untersuchung von Produktideen bis zu der vollständigen und zur Produktion freigegebenen Produktdefi­ nition bereit. Die Informationen entwickeln sich graduell und werden mit fortschreitendem Gestaltungsprozeß immer de­ taillierter.

Claims (20)

1. Objektmodell zum Erfassen von Informationen, die pro­ duktinnovationsbezogene Daten betreffen, mit einer Produkt­ ideeschnittstelle zum Erfassen einer Idee für ein Produkt in einem Produktideeobjekt und einer Gestaltungsalternati­ venschnittstelle zum Erfassen einer Vielzahl von Gestal­ tungsalternativen für das Produkt in einer Vielzahl von je­ weiligen Gestaltungsalternative-Objekten.
2. Objektmodell nach Anspruch 1, mit einer Produktanfor­ derungsschnittstelle zum Erfassen einer Anforderung für die Produktidee in einem Produktanforderungsobjekt.
3. Objektmodell nach Anspruch 2, mit einer Produktfunkti­ onsschnittstelle zum Erfassen einer Funktion zum Erfüllen der Produktanforderung in einem Produktfunktionsobjekt.
4. Objektmodell nach Anspruch 3, mit einer Produkterfül­ lungsschnittstelle, die erfaßt, wie gut die Produktfunktion die Produktanforderung erfüllt.
5. Objektmodell nach Anspruch 1, mit einer Gestaltungs­ darstellungsschnittstelle zum Erfassen einer Darstellung der Gestaltungsalternative in einem Gestaltungsdarstel­ lungsobjekt.
6. Objektmodell nach Anspruch 1, mit einer Entscheidungs­ schnittstelle zum Erfassen einer Entscheidung in einem Pro­ duktanforderungsobjekt, wobei diese Entscheidung entweder die Produktidee oder die Gestaltungsalternative betrifft.
7. Objektmodell nach Anspruch 1, bei dem Produktideeob­ jekt und jedes Gestaltungsalternative-Objekt in einer werk­ zeugneutralen beständigen Form gespeichert werden.
8. Objektmodell nach Anspruch 2, bei dem Produktideeob­ jekt, jedes Gestaltungsalternative-Objekt und jedes Produk­ tanforderungsobjekt in einer werkzeugneutralen beständigen Form gespeichert werden.
9. Objektmodell nach Anspruch 5, bei dem Produktideeob­ jekt, jedes Gestaltungsalternative-Objekt und jedes Gestal­ tungsdarstellungsobjekt in einer werkzeugneutralen bestän­ digen Form gespeichert werden.
10. Verfahren zum Erfassen von Informationen, die produkt­ innovationsbezogene Daten betreffen, mit den folgenden Schritten:
Erfassen einer Idee für ein Produkt in einem Produktideeob­ jekt, und
Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von entsprechenden Gestaltungsal­ ternative-Objekten.
11. Verfahren nach Anspruch 10, mit dem Schritt des Erfas­ sens einer Anforderung für die Produktidee in einem Pro­ duktanforderungsobjekt.
12. Verfahren nach Anspruch 11, mit dem Schritt des Erfas­ sens eine Funktion zum Erfüllen der Produktanforderung in einem Produktfunktionsobjekt.
13. Verfahren nach Anspruch 10, mit dem Schritt des Erfas­ sens einer Darstellung der Gestaltungsalternative in einem Gestaltungsdarstellungsobjekt.
14. Verfahren nach Anspruch 10, mit dem Schritt des Erfas­ sens einer Entscheidung in einem Entscheidungsobjekt, wobei die Entscheidung entweder die Produktidee oder die Gestal­ tungsalternative betrifft.
15. Verfahren nach Anspruch 1, mit dem Schritt des Spei­ cherns des Produktideeobjekts und jedes Gestaltungsalterna­ tive-Objekts in einer werkzeugneutralen beständigen Form.
16. Verfahren nach Anspruch 10, mit dem Schritt des Spei­ cherns des Produktideeobjekts, jedes Gestaltungsalternati­ ve-Objekts und des Produktanforderungsobjekts in einer werkzeugneutralen beständigen Form.
17. Verfahren nach Anspruch 13, mit dem Schritt des Spei­ cherns des Produktideeobjekts, jedes Gestaltungsalternati­ ve-Objekts und jedes Gestaltungsdarstellungsobjekts in ei­ ner werkzeugneutralen beständigen Form.
18. Computerprogramm mit Programmanweisungen, die ein Ver­ fahren zum Erfassen von Informationen, die produktinnovati­ onsbezogene Daten betreffen, umsetzen, wobei das Verfahren die folgenden Schritte umfaßt:
Erfassen einer Idee für ein Produkt in einem Produktideeob­ jekt, und
Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von jeweiligen Gestaltungsalter­ native-Objekten.
19. Computerprogramm nach Anspruch 18, bei dem das Verfah­ ren den Schritt des Speicherns des Produktideeobjekts und jedes Gestaltungsalternative-Objekts in einer werkzeugneu­ tralen beständigen Form umfaßt.
20. Computerprogramm nach Anspruch 18, wobei das Verfahren die folgenden Schritte umfaßt:
Erfassen einer Anforderung für die Produktidee in einem Produktanforderungsobjekt,
Erfassen einer Darstellung der Gestaltungsalternative in einem Gestaltungsdarstellungsobjekt, und
Speichern des Produktideeobjekts, jedes Gestaltungsalterna­ tive-Objekts, des Produktanforderungsobjekts und jedes Ge­ staltungsdarstellungsobjekts in einer separaten relationa­ len Datenbank, wobei Verknüpfungen zwischen den einzelnen Objekten unter Verwendung fremder Schlüssel erfaßt werden.
DE10150391A 2000-10-06 2001-10-08 Objektmodell und Verfahren zum Erfassen von Informationen Ceased DE10150391A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/680,751 US6944514B1 (en) 2000-10-06 2000-10-06 Innovation information management model

Publications (1)

Publication Number Publication Date
DE10150391A1 true DE10150391A1 (de) 2002-05-08

Family

ID=24732367

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10150391A Ceased DE10150391A1 (de) 2000-10-06 2001-10-08 Objektmodell und Verfahren zum Erfassen von Informationen

Country Status (2)

Country Link
US (2) US6944514B1 (de)
DE (1) DE10150391A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1609080A2 (de) * 2003-03-24 2005-12-28 Siebel Systems, Inc. Gemeinsames objekt für produkte
US7711680B2 (en) 2003-03-24 2010-05-04 Siebel Systems, Inc. Common common object
US7865390B2 (en) 2004-05-21 2011-01-04 Siebel Systems, Inc. Modeling of employee performance result data
US7912932B2 (en) 2003-03-24 2011-03-22 Siebel Systems, Inc. Service request common object
US8489470B2 (en) 2003-03-24 2013-07-16 Siebel Systems, Inc. Inventory location common object
US9704120B2 (en) 2003-03-24 2017-07-11 Oracle International Corporation Inventory balance common object

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004529406A (ja) 2000-11-10 2004-09-24 アフィノバ, インコーポレイテッド 動的なリアルタイムマーケットセグメンテーションのための方法および装置
US7925513B2 (en) * 2001-03-15 2011-04-12 Versata Development Group, Inc. Framework for processing sales transaction data
US7958024B2 (en) 2001-03-15 2011-06-07 Versata Development Group, Inc. Method and apparatus for processing sales transaction data
US7908304B2 (en) * 2001-03-15 2011-03-15 Versata Development Group, Inc. Method and system for managing distributor information
US7043481B2 (en) * 2001-06-01 2006-05-09 Thought, Inc. System, method and software for creating, maintaining, navigating or manipulating complex data objects and their data relationships
US7904326B2 (en) * 2001-06-29 2011-03-08 Versata Development Group, Inc. Method and apparatus for performing collective validation of credential information
US8538840B2 (en) * 2002-12-20 2013-09-17 Siebel Systems, Inc. Financial services data model
US7856454B2 (en) 2002-12-20 2010-12-21 Siebel Systems, Inc. Data model for business relationships
US8392298B2 (en) * 2003-03-04 2013-03-05 Siebel Systems, Inc. Invoice adjustment data object for a common data object format
US8473399B2 (en) * 2003-03-04 2013-06-25 Siebel Systems, Inc. Invoice data object for a common data object format
US20070208577A1 (en) * 2003-03-24 2007-09-06 Leon Maria T B Position common object
US8510179B2 (en) 2003-03-24 2013-08-13 Siebel Systems, Inc. Inventory transaction common object
US20070226037A1 (en) * 2003-03-25 2007-09-27 Shailendra Garg Modeling of opportunity data
US20040250236A1 (en) * 2003-04-30 2004-12-09 O'malley Austin Establishing and maintaining a relationship between a three-dimensional model and related data
US20050022156A1 (en) * 2003-07-22 2005-01-27 Joerg Schwan Management of changes to objects
US8112296B2 (en) * 2004-05-21 2012-02-07 Siebel Systems, Inc. Modeling of job profile data
US20060178928A1 (en) * 2005-02-10 2006-08-10 International Business Machines Corporation Innovation capture system
US20060200386A1 (en) * 2005-03-07 2006-09-07 Hartman Dorothy M Accessing accessibility process
US20060225047A1 (en) * 2005-04-05 2006-10-05 William Brothers Generic software requirements analyzer
US20070006130A1 (en) * 2005-06-02 2007-01-04 Arnold Stamler Model oriented method of automatically detecting alterations in the design of a software system
WO2007038770A1 (en) * 2005-09-28 2007-04-05 Michael Ira Markowitz Inventive process documentation, management, and stimulation system
US9235909B2 (en) 2008-05-06 2016-01-12 International Business Machines Corporation Simplifying the presentation of a visually complex semantic model within a graphical modeling application
US20090319239A1 (en) * 2008-06-18 2009-12-24 International Business Machines Corporation Topology modeling application that handles abstract entities through the realization of conceptual objects
US8849987B2 (en) * 2008-07-29 2014-09-30 International Business Machines Corporation Automated discovery of a topology of a distributed computing environment
US8291378B2 (en) 2008-07-29 2012-10-16 International Business Machines Corporation Simplified deployment modeling
US8302093B2 (en) * 2008-08-28 2012-10-30 International Business Machines Corporation Automated deployment of defined topology in distributed computing environment
US9280335B2 (en) 2010-09-30 2016-03-08 International Business Machines Corporation Semantically rich composable software image bundles
US8417658B2 (en) 2008-09-12 2013-04-09 International Business Machines Corporation Deployment pattern realization with models of computing environments
US8793652B2 (en) 2012-06-07 2014-07-29 International Business Machines Corporation Designing and cross-configuring software
DE102008047578A1 (de) * 2008-09-17 2010-04-15 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Nachverfolgen von Anforderungen in einer Anzahl von Modellen eines Systems
US8402381B2 (en) * 2008-09-23 2013-03-19 International Business Machines Corporation Automatically arranging widgets of a model within a canvas using iterative region based widget relative adjustments
US9015593B2 (en) 2008-12-01 2015-04-21 International Business Machines Corporation Managing advisories for complex model nodes in a graphical modeling application
US9047575B2 (en) * 2009-05-04 2015-06-02 Oracle International Corporation Creative process modeling and tracking system
US8799203B2 (en) * 2009-07-16 2014-08-05 International Business Machines Corporation Method and system for encapsulation and re-use of models
US8868446B2 (en) 2011-03-08 2014-10-21 Affinnova, Inc. System and method for concept development
US9208132B2 (en) 2011-03-08 2015-12-08 The Nielsen Company (Us), Llc System and method for concept development with content aware text editor
US20120259676A1 (en) 2011-04-07 2012-10-11 Wagner John G Methods and apparatus to model consumer choice sourcing
US9311383B1 (en) 2012-01-13 2016-04-12 The Nielsen Company (Us), Llc Optimal solution identification system and method
WO2014143729A1 (en) 2013-03-15 2014-09-18 Affinnova, Inc. Method and apparatus for interactive evolutionary optimization of concepts
WO2014152010A1 (en) 2013-03-15 2014-09-25 Affinnova, Inc. Method and apparatus for interactive evolutionary algorithms with respondent directed breeding
US10147108B2 (en) 2015-04-02 2018-12-04 The Nielsen Company (Us), Llc Methods and apparatus to identify affinity between segment attributes and product characteristics
EP3928269A1 (de) 2019-02-23 2021-12-29 Mezher, Maher G. Innovationsverfahren

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5109337A (en) 1987-10-28 1992-04-28 Ibm Corporation Conceptual design tool
US5355317A (en) 1991-02-26 1994-10-11 Texas Instruments Incorporated Method and apparatus for system design
US5552995A (en) * 1993-11-24 1996-09-03 The Trustees Of The Stevens Institute Of Technology Concurrent engineering design tool and method
US5646862A (en) * 1994-09-29 1997-07-08 Ford Motor Company Vendor-neutral integrated vehicle electrical design and analysis system and method
US5754738A (en) 1996-06-07 1998-05-19 Camc Corporation Computerized prototyping system employing virtual system design enviroment
US6445974B1 (en) * 1998-12-30 2002-09-03 Intergraph Corporation CAD-neutral application programming interface

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1609080A2 (de) * 2003-03-24 2005-12-28 Siebel Systems, Inc. Gemeinsames objekt für produkte
EP1609080A4 (de) * 2003-03-24 2006-11-08 Siebel Systems Inc Gemeinsames objekt für produkte
US7711680B2 (en) 2003-03-24 2010-05-04 Siebel Systems, Inc. Common common object
US7904340B2 (en) 2003-03-24 2011-03-08 Siebel Systems, Inc. Methods and computer-readable medium for defining a product model
US7912932B2 (en) 2003-03-24 2011-03-22 Siebel Systems, Inc. Service request common object
US7962372B2 (en) 2003-03-24 2011-06-14 Siebel Systems, Inc. Product common object
US8200539B2 (en) 2003-03-24 2012-06-12 Siebel Systems, Inc. Product common object
US8489470B2 (en) 2003-03-24 2013-07-16 Siebel Systems, Inc. Inventory location common object
US9704120B2 (en) 2003-03-24 2017-07-11 Oracle International Corporation Inventory balance common object
US7865390B2 (en) 2004-05-21 2011-01-04 Siebel Systems, Inc. Modeling of employee performance result data

Also Published As

Publication number Publication date
US20050228522A1 (en) 2005-10-13
US7050872B2 (en) 2006-05-23
US6944514B1 (en) 2005-09-13

Similar Documents

Publication Publication Date Title
DE10150391A1 (de) Objektmodell und Verfahren zum Erfassen von Informationen
DE60311805T2 (de) Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Merkmalen von Architekturen
von der Maßen et al. Requiline: A requirements engineering tool for software product lines
DE602004003361T2 (de) System und verfahren zur erzeugung von verfeinerungskategorien für eine gruppe von suchergebnissen
DE60002876T2 (de) Darstellung, verwaltung und synthese von technischen inhalten
DE10150387A1 (de) CAD-Datenmodell mit Entwurfsnotizen
DE10150388A1 (de) Kollaborationssitzungs-Aufnahmemodell
EP2425331A1 (de) Verfahren zur erzeugung mindestens einer anwendungsbeschreibung
DE19712946A1 (de) Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells
DE19955718A1 (de) Paralleler Datenbank-Support für Workflow-Management-Systeme
DE10120869A1 (de) Verwendung eines Index für den Zugriff auf eine mehrdimensionale Subjektdatenbank
DE10348337A1 (de) Inhaltsverwaltungsportal und Verfahren zum Kommunizieren von Informationen
DE19538240A1 (de) Informationssystem und Verfahren zur Speicherung von Daten in einem Informationssystem
DE112005003157T5 (de) Domainspezifisches Datenelement-Mappingverfahren- und System
DE10149693A1 (de) Objekte in einem Computersystem
DE60310881T2 (de) Methode und Benutzerschnittstelle für das Bilden einer Darstellung von Daten mit Meta-morphing
DE112020001874T5 (de) Datenextraktionssystem
DE102004043788A1 (de) Programm Generator
DE19947892C2 (de) Verfahren zur Umsetzung von Schnittstellendefinitionen und Zwischenformattabelle dafür
WO2007025557A1 (de) Migration und transformation von datenstrukturen
DE102019220056A1 (de) Domänenwissensinjektion in halb-schwarmausgelagerte unstrukturierte datenzusammenfassung für diagnose und reparatur
DE19962787A1 (de) Verfahren zur Behandlung von Datenobjekten
DE602005002846T2 (de) Verfahren zur Datenverarbeitung und assoziiertes Softwareprogramm
WO2021104608A1 (de) Verfahren zum erzeugen eines engineering-vorschlags für eine vorrichtung oder anlage
US7574329B1 (en) Object model for decision and issue tracking

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection