من اطلاعات این پیوند را این طور می‌خوانم:

A) "Veshnavah" (E48 Place Name) 466 -> P87 is identified by [B] -> E44 Place Appellation

B) "Veshnavah" (E48 Place Name) 466 -> P3 has note [F] -> E1 CRM Entity

 (اینجا به جای E1 از E62 استفاده کردم چون فکر کردم می‌توانم موجودیت درست‌تر را بگذارم)

من نمی‌خواهم بگویم که دو موجودیت متفاوت داریم یکی Place Name و دیگری  Place Appellation  ولی نمی‌توانم نشان دهم که چطور Place Name مشخصه‌هایی را از رده بالاتر خود یعنی Place Appellationبه ارث برده است. 

البته فکر کنم اگر برای نشان دادن رابطه subclass بودن یک رده با رده بالاتر خود، آن موجودیت را در قسمت پایین موجودیت اصلی بدون ذکر عبارتی برای مشخصه بیاورم، درست باشد.

-------------------------------------------------------------

پاسخ جناب مهندس حجتی:

"نمایش تخصصی وب تمام مشخصه‎های یک موجودیت را بازنمایی می‎کند. اما سطحی که مشخصه‎ در آن ظاهر شده است را نیز در سمت چپ پر رنگ نمایش می‎دهد. بنابراین در مثال شما PlaceAppellation و CRMEntity سطح ظهور مشخصه‎های مرتبط هستند نه، آنطور که من از نوشته شما برداشت می‎کنم، نوع مقدار آن مشخصه‎ها. یعنی مثلا مقدار P87 از نوع PlaceAppellation نیست. برای اینکه بدانید نوع مقدار P87 چیست تنها باید روی آن کلیک کنید. نوع موجودیت در صفحه جدید ظاهر می‎شود (در این مورد Place). نوع Place مورد تایید مدل هم هست (به معکوس بودن رابطه هم توجه داشته باشید)."

سلام،

خیلی ممنون از پاسخ شما. منظور من مقدار موجودیت نیست. برای نشان دادن مقادیر موجودیت‌های دیگری در ققنوس بر حسب الگو تعریف شده است. صرفا خواستم بگویم من اطلاعات آن پیوند را اینطور خواندم و رسم کردم. 

با احترام

پس در یک شکل دو استفاده ناسازگار از یک نماد کرده‎اید (دو مستطیل که نام رده موجودیت را دارند و از طریق پیوندی که نام مشخصه را دارد به هم متصل شده‎اند). اگر هر مستطیل به معنای یک موجودیت و پیوند به معنای مشخصه مرتبط کننده آنهاست، که ظاهرا همه جای دیگر چنین است، اتصال دادن E44 و E48 توسط رابطه P87B نمی‎تواند درست باشد. زابطه‎ای که شما رسم کرده‎اید بنا به این قاعده اینطور خوانده می‎شود که دو موجودیت از این دو نوع وجود دارد.

پیشنهاد استفاده از یک نوع رابطه دیگر (خط چین بدون اشاره به نام مشخصه) این ناسازگاری را رفع می‎کند. این رابطه اشتقاق (derivation یا همان subclassing) میان دو کلاس را بازنمایی می‎کند. اما گنجاندن این رابطه سوال دیگری را برای مخاطب ایجاد می‎کند. آن اینکه چرا به این یک مورد چنین توجه ویژه‎ای در این نمودار شده است. مثلا چرا  همین رابطه برای E53 در همان شکل نیامده است.

این نمادها همانها هستند که توسط برنامه‎نویسان در نمودارهای توصیف کننده برنامه‎هایشان مورد استفاده قرار می‎گیرند (به طور مشخص class diagram)

موفق باشید.

سلام،

بله حق با شماست. خطا کرده بودم با استفاده از رابطه خط چین می‌توانیم generalization و specialization یکی از مفاهیم class diagram را نشان دهیم.

در مورد پاسخ پرسش دیگر شما یعنی "چرا  همین رابطه برای E53 در همان شکل نیامده است." هنوز ایده‌ای ندارم. می‌خواهم نمودار را دوباره رسم کنم.

ممنونم از راهنمائی شما

لطفا برگۀ جدید NewExcavation(Activity) را ملاحظه فرمائید. امیدوارم این بار نمای تخصصی را درست خوانده باشم. نمودار جزئی‌تری از  E52 و E53 به صورت جداگانه رسم خواهم کرد.

با احترام و سپاس فراوان

NewExcavation (Activity)_13031398.rar

باز هم خیر.

مقدار مشخصه خاص P3F از جنس موجودیت نیست و به رشته حرفی ختم می‎شود و باید به شکل متفاوتی نمایش داده شود. اما اگر اصرار به نمایش آن به همین شکل داشته باشید همان استفاده از String صحیحتر است. چه نمای تخصصی این موجودیت و بقیه Primitive Value ها را به صورت موجودیت بازتاب نمی‎دهد بازتاب نمی‎دهد. پیشنهاد من آنست که در یک نمودار در مورد خانواده شناسه و با کمک همان String آنرا توضیح دهید و سپس به اتکاء آن در دیگر نمودارها روابط را تا همان شناسه ادامه دهید. به هر صورت ارجاع برگشتی P3F به شناسه نادرست است.

اینکه من اشاره کردم چرا رابطه generalization را در مورد Place و دیگران به کار نبردید منظورم این نبود که برای آن هم به کار ببرید. برعکس منظورم این بود که نیازی نیست در هر نموداری تمام سلسله مراتب رده‎بندی را بیاورید. اگر چه صحیح است اما مخاطب را از اصل مطلبی که در حال روایتش هستید دور می‎کند.

اشاره به روابط برگشتی میان E55 ها هم می‌تواند گیج‎کننده باشد. باز هم اشاره کنم که نمی‎توان تمام دانستنی‌ها را در یک نمودار گنجاند.

باز هم فکر می‎کنم بد نباشد نمودارها را برای مصادیق هم بکشید (Instance diagram در مقابل class diagram).

موفق باشید

سلام،

ممنونم از لطف شما برای توضیحات مفصل.

به این ترتیب:

1. در یک نمودار به موجودیت‎های اصلی در هر رده می‎پردازم. (نمودارهای کوچک‎تر) و در نمودار  هم‏‎ارز آن به مصداق می‎پردازم.

2. به شناسه‌ها در یک نمودار مجزا می‌پردازم.

3. در روابط برگشتی تجدید نظر می‎کنم.

با احترام و سپاس فراوان از لطف شما.

سلام،

لطفا نمودار E4 (دوره زمانی)، نمودار E52 (بازه زمانی)، نمودار E53 (مکان) و نمودار Discovery را در فایل پیوست ملاحظه فرمائید.

1. در دو نمودار اول E4 شکل گسترده‌تری از موجودیت و مشخصه‌های آن را نشان دادم و دو نمودار دوم ساده‌تر و خلاصه‌تر هستند.

2. نمودار E52 نمایش ساده این موجودیت و مشخصه‌هایش است.

3. نمودار E53 نمایش ساده این موجودیت و مشخصه‌هایش است.

4. نمودار Discovery نمایش ساده این موجودیت و مشخصه‌هایش است.

با احترام و سپاس فراوان

Period.rar

Time-Span.rar

Place.rar

در مورد class diagram مورد E53 فکر کنم بهتر باشد که فقط یک E53 را در نمودار بگنجانید. اگر چنین کنید بعضی از روابط میان E53 با خودش برقرار می‎شود که اگر ابزارتان با کشیدن آن مشکلی نداشته باشد درست هم هست. لازم نیست class diagram را منطبق مورد به مورد با instance diagram نگه دارید.

موفق باشید

سلام،

خیلی ممنونم از راهنمائی شما. نمودار را ویرایش کردم.

اطمینان ندارم که نمودار E4 را درست رسم کرده باشم.

با احترام و سپاس فراوان

2nd_Place.rar

به دومین E53 نیازی نیست و قابل حذف است. رابطه P88 قبلا پوشش داده شده است.

E4 به نظر درست می‎رسد.

موفق باشید

خسته نباشید،

نمودار ویرایش شد.

ممنونم از راهنمایی شما.

با سپاس و احترام فراوان

3rd_Place.rar