аЯрЁБс>ўџ =?ўџџџ>џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџьЅСE@ №Пw bjbjƒцƒц ",сŒсŒwџџџџџџˆVVVVVVVj     jo2B B B B B B B B ю№№№№№№$ЁRѓ pVB B B B B VVB B )B тVB VB юB юдк:~,VVОB 6 №^3 bЇТ $ŒЊ т ?0oД c!АLc!ОjjVVVVc!VО$B B B B B B B jjЄ  ќ jj Untouchables Dieses Dokument versucht die wichtigsten Merkmale des Zustandes „Untouchable“ zu beschreiben. „Untouchables“ und „Untouchable Flags“ ist im folgenden gleich zu setzen und beschreibt einen „gesperrten, nicht modifizierbaren“ Zustand einer Baugruppe oder eines Bauteils. Untouchable Flags bekommt man durch Referenzen, die beim Laden verlorengehen. Das Untouchable Flag verhindert durch das Setzen des Schreibschutzes den Datenverlust. Darќberhinaus wird ein Zurќckschreiben in die Datanbank verhindert. Untouchables kіnnen im Zusammenspiel von OneSpace Designer Modeling mit dem ModelManager oder DesignManagement entstehen, nicht aber beim Laden vom Dateisystem. Dort greifen die Untouchable Mechanismen nicht. Welche Referenzen verursachen bei ihrem Aufbrechen das Entstehen von Untouchables ? Man unterscheidet zwischen Referenzen, die Objekte in einem Bauteil referenzieren (z. B. Flфchen) und Referenzen, die Bauteile selbst (= Instanzen der Bauteile) referenzieren. Referenzen, die Objekte in einem Bauteil referenzieren, sind z. B. Systemdefinierte Features: 3D Dokumentationselemente (3D Bemassungen) User Defined Features GDT Features Relations (Beziehungssфtze) Custom Features Selektive Instanzen (referenzieren den Contents der Bauteile) Referenzen, die Bauteile referenzieren, sind Part Groups (seit OSDM 11.50 verstфrkt durch ManageParts verwendet) Komponentenlisten von Annotation Ansichten Bei Referenzen in ein Bauteil kann schon ein partielles Laden oder Nachladen des Bauteiles Untouchables verursachen. Bei Referenzen auf (Instanzen der) Bauteile ist dies noch unproblematisch. Hier kіnnen Untouchables erst durch partielles Laden oder Nachladen der ќbergeordneten Baugruppe (oder eines ќbergeordneten Containers) entstehen. In allen Fфllen muss der Owner der Referenz davor geschќtzt werden, die Daten dauerhaft, d.h durch мberschreiben in der Datenbank, zu verlieren. Wie kіnnen Referenzen verloren gehen? Grundsфtzlich gibt’s dafќr folgende Mіglichkeiten: Durch partielles Laden: Ein referenziertes Bauteil (z.B. referenziert von 3D Bemassung, Relations, Ansicht-Komponentenlisten etc.) ist momentan nicht geladen. Durch (legale) Verфnderungen der Baugruppenstruktur (z. B. Entfernen eines referenzierten Bauteils), ohne dass die Referenz eine Chance hфtte, das mitzubekommen, z.B. weil sie gerade selbst nicht geladen ist.  (Nach-) Laden einer Version der Baugruppe, die das referenzierte Bauteil nicht enthфlt. Nachladen von referenzierten Teilen im allgemeinen Hier ein paar Beispiele aus der Praxis: Aus einer Baugruppe wird eine Unterbaugruppe partiell geladen. Die Baugruppe enthфlt Referenzen in Teile der Unterbaugruppe, z.B. eine Relation, die teileќbergreifend ist. => Die Baugruppe (= Owner der Referenzen) wird untouchable. Eine Bemassung zeigt auf eine Flфche. Wenn die Flфche durch eine Modeling Operation entfernt wurde ohne daп die Referenz geladen war (z. B. weil ausschlieпlich das Teil geladen war, nicht aber die ganze Baugruppe), wird beim nachfolgenden Laden der ganzen Baugruppe diese jetzt ungќltige Referenz durch ein Untouchable markiert. Referenzen in der Komponenten Liste gehen beim Partial Load verloren, wenn der Anwender eine Baugruppe lфdt, die einen Behфlter (Container) beinhaltet und ein Teil innerhalb des Behфlter eine Komponente des Ansichtssatzes (Viewsets) war. Das Mitfќhren von Versionen in der Datenbank fќhrt zu Untouchables, wenn ein Nachladen (Reload) auf eine Unterbaugruppe ausgefќhrt wird, die Teile enthфlt, die von auпen, d. h. von einer Oberbaugruppe, referenziert werden. Zum Beispiel, wenn in der Oberbaugruppe ein Ansichtssatz existiert, dessen Bestandteil mindestens eine Version eines Bauteiles der Unterbaugruppe ist, welches beim Nachladen einer alten oder neuen Version nicht mehr verfќgbar wфre. Diese ungќltige Referenz wird durch das Untouchable Flag markiert. Durch Nachladen (Reload) kann es ebenso zu Untouchables kommen, falls Featurereferenzen (z.B. 3D Bemassungen) an Baugruppen assoziiert sind und ein Nachladen auf Unterbaugruppen durchgefќhrt wird, so daп diese Referenzen ins Leere zeigen wќrden (vergleichbar mit Punkt 1 beim partiellen Laden). Welches Objekt erhфlt das Untouchable Flag ? Die Zuweisung des Untouchable Flags erhфlt immer der Besitzer der Referenz. Je nach Fall kann das so aussehen: a) Untouchable mit Komponenten Liste Das Untouchable Flag wird dem Besitzer des zugehіrigen Ansichtsatzes (dem Contents des Objektes) zugeordnet. b) Selektive Instancen Der Kontext der Definition der Selektiven Instance erhфlt das Untouchable Flag. Die Zuordnung erfolgt zur Instance* des Kontext. c) Untouchable mit Features Das Untouchable Flag wird entsprechend der Definition des Features zugeordnet, also entweder der Instance* oder dem Contents des Features. d) Untouchable mit 3D Dokumentation Die Zuordnung kann nicht immer vohergesagt werden, da die Besitzer von z.B. 3D Bemassungen nicht durch den Anwender erkannt werden kіnnen. Dies ist insbesondere bei teileќbergreifenden Bemassungen der Fall. In der Praxis wird das Untouchable Flag an die Instance* oder den Contents des bemassungsbesitzenden Objektes zugeordnet. * Generell gilt bei Unterbaugruppen, daп die Flags, die einer Instance zugeordnet werden, an den Contents der ќbergeordneten Baugruppe weitergereicht werden. Lіsungen und Empfehlungen In vielen Fфllen reicht das komplette Nachladen des Objektes mit dem Untouchable Flag aus der Datenbank, um die offenen Referenzen zu lіsen. Wenn Untouchable Flags an einer von vornherein vollstфndig geladenen Baugruppe erscheinen (und man eventuelle Versionen dieser Baugruppe ausser acht lassen kann / will), kann man diese Flags mit dem dokumentierten Goody (unlock_obj) abrфumen. In anderen Fфllen hat man das Risiko, spфter noch benіtigte Referenzen dauerhaft zu verlieren und damit Daten (Features, Komponentenlisten, selektive Instanzen etc.) dauerhaft zu zerstіren. Fќr die OneSpace Designer Modeling Version 12.00 ist geplant, eine dedizierte Erkennung und Behandlung von offenen Referenzen zu integrieren, so dass das „Verlorengehen" (fast) aller Referenzen von vornherein vermieden wird - und damit Untouchable Flags erst gar nicht entstehen. Ф к л  > ] ` b ‰  q Ь ] | Њ И К opБВжзќpx`ЪХЩдј()УФcdvŠ‹Элц‡‰”ШдеWX]w јєјєјьјујєјєјєјєоєјєјєјєјејєјєјєјєјЬјЬјЬјЬјєјєјејФРјєјєјєјhg/[hg/[mHsHhЗAH*mHsHhЗA5mHsH hЗA6hЗA6mHsHhЉЅmHsHhЗAhЗAmHsH:   ж з и , - о п " # > B m ‡ ˜ И Э 9 : ~ Љ §ћљѓљљљёљљљљљьљцљљљљьљљљьь„а`„а & FЄЄw §Љ ќŽЕЖщˆZВх ѕ>-7^_`Ž§ў$l—˜Џ§§ћћљљєєєє§яяяяя§ћћљљљљљљљљ & F & FЏё78Tšхц P›т'bcЊЌ]^v w §§ї§§§§§§§§§§§§§ѕ§§§§§§§ЄЄ 1hАа/ Ар=!А"А# $ %Аœ@@ёџ@ NormalCJ_HaJmH sH tH Z@Z Heading 1$Є№Є<@&5CJ KH OJQJ\^JaJ V@V Heading 3$Є№Є<@&5CJOJQJ\^JaJDA@ђџЁD Default Paragraph FontVi@ѓџГV  Table Normal :V і4ж4ж laі (k@єџС(No List B^@ђB Normal (Web)ЄdЄd[$\$*W@Ђ* Strong5\w,џџџџжзи,-оп"#>Bm‡˜ИЭ  9:~ЉќŽЕЖщˆZ В х ѕ > - 7^_`Ž§ў$l—˜Џё78Tšхц P›т'bcЊЌ]^vy0€€˜0€˜0€˜0€˜0€€˜0€˜0€(0€˜0€и˜0€и˜0€и˜0€и˜0€и˜ 0€и˜0€и˜0€и˜0€и˜0€и˜0€и˜0€и˜ 0€и˜0€и˜0€и˜0€и˜ 0€и˜ 0€и˜0€и˜0€и(0€(0€˜0€˜0€˜ 0€˜ 0€˜ 0€˜ 0€˜0€˜ 0В ˜ 0В ˜ 0В ˜ 0В €˜ 0В €˜0€€(0€€(0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€(0€€˜0€€˜0€€˜0€€˜0€€€˜0€€˜0€€˜0€€w Љ Џw w  MO  ФЭЮвгжзклцюїј]^жи,-bc‰ГЗоп #>BmЇЖЭрт  9:]`afgrs|~ЊЌ­ЗЛОПЦЧЫЬбвежрчыьѕњ!",2;<?AIJMSWXgimopt‚†‡Œ—žЂЃЌ­АБВПРЩЫЯаежзфёњќŽЕЖйкxy- / Z [ ` e m n u  … †   • ˜ ™  ž Ѕ Ћ А Б Е К П Р Щ Ь   + - Х Ч Щ д т ч ш ѕ ј ўџ^`Ž§ў$'lp—˜ЏВёє(*78TWšУХхц  PS›žтх'*bevw†ˆŠ‹› ЊДЕЛЭпр…†ЊЌцч‡‰“•ШЫЬабдеклхця№ђѓќ )+45>ENOQRWX[^vy еи+-нп!#=BlЭ  8:}~ЈЉJMžЂќДЖшщ‡ˆY Z Б В ф х є ѕ ~  … > , - л м 67]`ŒŽќў#'ko–˜ЎВ№є68SW™фц  OSšžсх&*acЉЌEN^uy33333]] ўџ‡”vyyџџ Sasa PleskoThomas SchneiderThomas SchneiderThomas SchneiderThomas SchneiderThomas Schneider А?ъAHqџџџџџџџџџК/ЉIчX"џџџџџџџџџh„а„˜ўЦа^„а`„˜ўOJPJQJ^Jo(-h„ „˜ўЦ ^„ `„˜ўOJQJ^Jo(‡hˆHoh„p„˜ўЦp^„p`„˜ўOJQJo(‡hˆHЇ№h„@ „˜ўЦ@ ^„@ `„˜ўOJQJo(‡hˆHЗ№h„„˜ўЦ^„`„˜ўOJQJ^Jo(‡hˆHoh„р„˜ўЦр^„р`„˜ўOJQJo(‡hˆHЇ№h„А„˜ўЦА^„А`„˜ўOJQJo(‡hˆHЗ№h„€„˜ўЦ€^„€`„˜ўOJQJ^Jo(‡hˆHoh„P„˜ўЦP^„P`„˜ўOJQJo(‡hˆHЇ№„а„˜ўЦа^„а`„˜ўOJPJQJ^Jo(-h„ „˜ўЦ ^„ `„˜ўo(.€„p„˜ўЦp^„p`„˜ўOJQJo(‡hˆHЇ№€„@ „˜ўЦ@ ^„@ `„˜ўOJQJo(‡hˆHЗ№€„„˜ўЦ^„`„˜ўOJQJ^Jo(‡hˆHo€„р„˜ўЦр^„р`„˜ўOJQJo(‡hˆHЇ№€„А„˜ўЦА^„А`„˜ўOJQJo(‡hˆHЗ№€„€„˜ўЦ€^„€`„˜ўOJQJ^Jo(‡hˆHo€„P„˜ўЦP^„P`„˜ўOJQJo(‡hˆHЇ№К/ЉI А?џџџџџџџџџџџџхЗAg/[ЉЅyџ@€••Дэлл••w`@џџUnknownџџџџџџџџџџџџG‡z €џTimes New Roman5€Symbol3& ‡z €џArial?5 ‡z €џCourier New;€Wingdings"qˆ№аh—›l†›l† Іб ,Іб ,!№ ДД24kk3ƒ№ппH(№џ?фџџџџџџџџџџџџџџџџџџџџџЉЅџџ Untouchables Sasa Plesko Sasa Plesko  ўџр…ŸђљOhЋ‘+'Гй0|˜АМамшќ  8 D P\dltфUntouchables onto Sasa Pleskoasaasa Normal.dot Sasa Plesko5saMicrosoft Word 10.0@vнA@QРaЇТ@Жф–bЇТІбўџеЭеœ.“—+,љЎDеЭеœ.“—+,љЎL hp˜ Ј АИРШ а ъфCoCreate Holding GmbHle, k­ Untouchables Title8ЃЋГЯѓ_AdHocReviewCycleID_EmailSubject _AuthorEmail_AuthorEmailDisplayNameфЄ>яUntouchables.docayNSasa_Plesko@CoCreate.comko Sasa Plesko ўџџџ !"#$%&'ўџџџ)*+,-./ўџџџ1234567ўџџџ§џџџ:ўџџџўџџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџRoot Entryџџџџџџџџ РFад< bЇТ<€1Tableџџџџџџџџw!WordDocumentџџџџџџџџ",SummaryInformation(џџџџ(DocumentSummaryInformation8џџџџџџџџџџџџ0CompObjџџџџџџџџџџџџjџџџџџџџџџџџџџџџџџџџџџџџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџўџ џџџџ РFMicrosoft Word Document MSWordDocWord.Document.8є9ВqRoot Entryџџџџџџџџ РF \цˆlЇТB€1Tableџџџџџџџџw!WordDocumentџџџџџџџџ",SummaryInformation(џџџџ( ўџџџ !"#$%&'ўџџџ)*+,-./ўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџA§џџџўџџџўџџџўџџџ@џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџўџџџ ўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџXx_AdHocReviewCycleID_EmailSubject _AuthorEmail_AuthorEmailDisplayName_PreviousAdHocReviewCycleIDфЄ>яDokument zu UntouchablesSasa_Plesko@CoCreate.com Sasa PleskoЄ>яDocumentSummaryInformation8џџџџџџџџџџџџЬCompObjџџџџџџџџџџџџjџџџџџџџџџџџџџџџџџџџџџџџџўџ џџџџ РFMicrosoft Word Document MSWordDocWord.Document.8є9ВqўџеЭеœ.“—+,љЎDеЭеœ.“—+,љЎL hp˜ Ј АИРШ а ъфCoCreate Holding GmbHle, k­ Untouchables Title€@аир