Association Patterns ( الگوهای پیوندی )
Association Patterns ( الگوهای پیوندی )
منبع :
1. Musser , D.R. and A.Saini . STL Tutorial and Reference Guide Reading , MA: Addison-Wesley , 1996 .
2- Rumbaugh, J. "OMT: The object model ." Journal of Object-Oriented Programming, 7,8 (1995),pp. 21-27
نکته : مطلب زیر برداشتی از بخش های کتابهای فوق الذکر است لازم به ذکر است به دلیل عدم وجود نسخه الکترونیکی امکان ضمیمه کردن تصاویر وجود ندارد.
پیوندها ساختارهای رایجی در آنالیز و طراحی متدها هستند . اغلب یک وضعیت یا موقعیت خاص توسط یک پیوند تکرار می شود . میتوان یک Notation خاص تعریف کرد ، در حالیکه می توان این وضعیت را بدون این Notation مدل سازی کرد . یک راه و روش مفید برای فکر کردن در مورد این موضوع این ست که ، یک موقعیت را به عنوان یک الگو (Pattern) در نظر بگیریم . این الگوی پیوندی (association Pattern)
می تواند در فرم اصلی ارائه شود ، یا برای خلاصه نویسی میتوان یک Notation برای آن تعریف کرد .هر دوی این روشها یک معنا دارند .
این فصل روی سه نوع از این موقعیت ها متمرکز است : یک نوع پیوند دهنده (Associative type) وقتی روی می دهد که شما بخواهید از یک پیوند به عنوان یک نوع (type) استفاده کنید ، که معمولا با دادن یک سری اهدافی به آن صورت می گیرد . یک نگاشت موزون و کلید دار برای ایجاد یک جدول جستجو یا دیکشنری استفاده می شود .
همه این الگوها از متدهای زیادی با Notation های الحاقی استفاده می کنند . فهمیدن و درک کردن الگو در پشت Notation با ارزش است . یک متد ممکن است یک Notation الحاقی را Support نکند ، پس لازم است که بدانیم چگونه بدون آن کار کنیم . اگر شما از یک متد که یک Notation را Support می کند
استفاده کنید و آنرا به یک متد که Notation را Support نمی کند انتقال دهید ، یا اگر شما عملیات بین متدها را انجام می دهید در حالیکه یک متد Notation ها را Support نمی کند ، آنگاه این قاعده اثبات می شود.
حتی اگر متد شما برای یک الگوی پیوندی از یک Notation استفاده می کند ، مهم است که بدانیم این Notation چگونه با ایده های ساده ارتباط برقرار میکند . اگر وضعیت یا موقعیت کمیلب است ، اغلب بهتر است که یک Notation الحاقی برای یادآوری تعریف نکنیم .
سومین الگوی پیوندی نگاشت تاریخی است (Historic Mapping) . ما می توانیم از نگاشت تاریخی برای نگهداری تاریخ دقیق تغییر مقادیر یک نگاشت استفاده کنیم . (مانند تاریخی از حقوقهای یک کارمند ) .
این کار توسط یک Notation خاص ، که در بعضی از متدها وجود دارد و ما از آن آگاه هستیم ، Support
نمی شود . بنابراین این یک الگوی حیاتی برای بسیاری از سیستمهای اطلاعاتی است .
هنگامی که یک نگاشت تاریخی لازم است ، معرفی کردن یک Notation به عنوان یک خلاصه برای الگوی پیوندی با ارزش است .
نه تنها پیچیدگی های خاص با تغییردرجهان رشد می کنند ، بلکه شناخت ما از این پیچیدگی ها نیز به طرق مختلف در حال تغییر است ، که این امر باعث بوجود آمدن یک تاریخ دوبعدی می شود .( مثال 15.3.1) .
فاکتورهای زیادی در انتخاب بین یک Notation و فرم اصلی ، برای استفاده کردن از آن موثرهستند . بطور فرضی یک مقایسه اصلی ، بین خلاصه ای که از یک Notation گرفته می شود و Notation اضافی که لازم است در یاد داشته باشیم ، وجود دارد . در یک مدل مشخص ، یک Notation اشاره ای به چندین واسط
(Interface) مختلف در نرم افزار دارد . احتمالا این Interface ها برای استفاده کردن بسیار ساده تر هستند نسبت به اینکه بخواهیم Interface ها را از فرم اصلی بدست آوریم . بنابراین اپریشن هایی همیشه به یک مدل مشخص اضافه میشوند تا Interface ساده تری را ایجاد کنند . این اپریشن ها وضوح بیشتری را به مدل اضافه می کنند ، ولی از اضافه کردن Notation های اضافی خودداری می کنند . آیا برای استفاده کردن از
یک Notation یا یک فرم اصلی نیاز به انتخاب است ؟
در این فصل من قصد دارم به چیزهایی که ترجیح می دهم ، اشاره کنم ، بطوریکه همیشه باید این نگرانی و استرس را داشته باشم که مکان دومی را برای مطلوبات یک مراجعه کننده در نظر بگیرم . این وظیفه من است که به عنوان یک مشاور، زندگی مراجعه کننده را ساده تر کنم .
الگوهای پیوندی در سطح Metamodel عمل می کنند : آنها الگوهایی هستند که برای توصیف زبان مدلسازی (Modeling Language) بجای خود مدلها مورد استفاده قرار می گیرند . من از گروهی از الگوهای Metamodel برای توصیف یک کلاس کلی از الگوها استفاده می کنم .
مابقی الگوهای Metamodel می توانند برای توصیف مفاهیم Meta-Level در Generalaziation ، State Model یا تکنیکهای مدلسازی دیگر استفاده شوند .
15.1- نمونه های پیوند دهنده (Associative type) :
یک موقعیت رایج در مدلسازی زمانی رخ می دهد که ما بخواهیم یک Attribute را به یک رابطه (Relationship) اضافه کنیم . به عنوان مثال ، مدل زیر نشان میدهد که یک شخص در یک کمپانی یا شرکت استخدام می شود (همانطور که در شکل 15.1 نشان داده شده است) . پس از مدتی که شخص کار کرد ، مشخص می شود که باید روزی را که کارمند شروع به کار کرده است ، ذخیره کنیم ، و این باید در رابطه قرار گیرد . ما می توانیم تاریخ شروع به کار را با استفاده از یک Notation مانند Rumbaugh's[2] که در شکل 15.2 نشان داده شده است ، اضافه کنیم .
اگر یک متد مدلسازی ، افزودن یک Attribute به یک رابطه را به این طریق Support کند ، آنگاه راه چاره ای (َAlternative) وجود دارد . در مثال ما یک راه چاره اظافه کردن تاریخ شروع به شخص است.
ممکن است فکر کنیم که Attribute تاریخ شروع واقعا یک قسمت از رابطه است ، ولی توجیح کردن چیزی بجای مفهوم Nit-picking سخت و دشوار است . یک نمونه ایراد عاقلانه اینست که تاریخ شروع نباید مقدار داشته باشد مگر اینکه یک کارفرما در آنجا وجود داشته باشد .
این مشکل را می توان توسط یک قانون و قاعده (Rule) حل کرد ، اگرچه این یک راه حل ایده آل نیست، بخصوص زمانیکه اغلب متدها اینگونه قوانین و قاعده ها را به خوبی Support نمی کنند . این فرایند نباید در رابطه هایی که هر دو نگاشت میتوانند چند مقداری باشند استفاده شود . (شکل 15.3) .زمانی که یک شخص
دارای تواناییهای مختلفی برای کار است ، غیر ممکن است که روی شخص یک شماره بگذاریم .
در متدهایی که نمونه های پیوندی را به خوبی Support نمی کنند ، ما می توانیم یک نوع احاقی را معرفی کنیم ، همانطور که در شکل 15.4 نشان داده شده است . توجه کنید که چطور Cardinalities از شکل 15.1 منتقل شده است .
اینکار مو قعیت را به خوبی اداره می کند . Type جدید ممکن است به نوعی مصنوعی باشد ، ولی همه مدلها
Type های مصنوعی مشخصی دارند بطوریکه یک موقعیت (Situation) حقیقی را با توافق های بیشتری نسبت به حالت رسمی که در زبان وجود دارد ، ارائه می دهند . یکی از اختلافات مهم بین دو مدل ، در
Implication ها و Interface ها وجود دارد . در شکل 15.2 شخص یک اپریشن GetEmployer دارد که کمپانی و شرکت عضو را بر می گرداند . مدل شکل 15.4 واسط های مختلفی دارد که شی (Object)
Employment را بر می گرداند .
شی Employment برای بدست آوردن کمپانی به یک پیام الحاقی (اضافی) نیاز دارد ، بنابراین نیاز داریم که از پیوند اصلی ، یک پیوند مشتق شده درست کنیم . همانطور که در شکل 15.5 نشان داده شده است.
ما می توانیم با در نظر گرفتن پیوندهای بسیاری که در شکل 15.3 وجود داشت ، به نکات دقیق و ظریفی پی ببریم .
شکل 15.6 از یک روش مشابه برای تعریف Type جدید استفاده کرده است . افزودن نوع (Type) صلاحیت فقط روی اولین بازدید خوب کار می کند ، زیرا اجازه می دهد که یک شخص تواناییهای زیادی داشته باشد ، در نتیجه چندین مهارت مختلف ، هر کدام با یک مقدار توانایی ، بوجود می آید .
مشکلی که وجود دارد این است که این مدل بسیار اجازه دهنده است ، زیرا اجازه تواناییهای مختلف را برای یک مهارت می دهد . برای رفع این مشکل ما به یک قاعده و قانون اضافی نیاز داریم که بیان می کند : هر توانایی باید یک ترکیب یکتایی از شخص و مهارت داشته باشد .
این فرض اغلب توسط مدلسازها ، کسانیکه از Notation های پیوند دهنده استفاده می کنند ، نادیده گرفته می شود . شکل 15.7 یک استفاده معمولی دیگر از این Notation را نشان می دهد که این مفهوم را می رساند که : یک شخص می تواند در کمپانی های بسیاری استخدام شود و بعضی از این استخدامها ممکن است کامل شده باشند ، بنابراین ما یک تاریخ از استخدامها داریم . این کاملا امکان پذیر است که ، یک شخص در دو دوره زمانی برای یک کمپانی یا شرکت کار کند . بنابراین ما محدودیتی را به روشی که در شکل 15.6 نشان داده شده بود اضافه نکرده ایم .
در کل مشکل این است که ما نمی توانیم تفسیر کنیم که ، آیا یک نوع پیوند دهنده (Associative type) دارای محدودیت است یا خیر؟
در تمرین ، مدل سازها از Notation های نوع پیوند دهنده به دو منظور ( با دو تعبیر) استفاده می کنند . این کار به خودی خود اشکالی ندارد ، ولی مدل سازها باید بطور واضح این دو مفهوم را تعریف کنند .
این عاقلانه است که از شکل 15.7 استفاده شود ، ولی در این حالت باید یک قاعده و قانون برای حالت شکل 15.3 درامتداد خطوط نقشهای شکل 15.6 ، تعریف شود . اگر مدل سازها بخواهند از حالت شکل 15.3 به عنوان یک تعبیر معمولی استفاده کنند ، آنگاه نمی توانند از یک مدل از شکل 15.7 استفاده کنند ، آنها باید از یک Type جدید بجای آن استفاده کنند .
بطور کلی من تمایل ندارم که از یک Notation نوع پیوند دهنده استفاده کنم ، مگر اینکه شامل یک قاعده صریح و روشن باشد ، و همچنین دارای یکتایی باشد . پس من فکر نمی کنم که آنها ارزش زیادی را برای اضافه شدن به Notation داشته باشند .
یکتایی می تواند مفید باشد ولی به ندرت استفاده شده است . من ترجیح می دهم که از یک نوع الحاقی (اضافی تر) استفاده کنم و یک قاعده یکتا برای واضح کردن آن ، به آن اضافه کنم .
15.2) نگاشت کلیددار یا مو زون ( Keyed Mapping) :
نگاشت کلیددار یا موزون تکنیکی در آنالیز است ، که شبیه به تکنیک استفاده شده در دیکشنری هاست ، که برای پیاده سازی روابط بکار می رود .
مثالی از استفاده از آن در شکل 15.8 و 15.9 نشان داده شده است . هدف اصلی ما ذخیره کردن تعداد زیادی از تولیدات خاص بر اساس دستورات و سفارشات خاص است . یک مدل دادهای قدیمی و کلاسیک در شکل 15.8 نشان داده شده است . مدلی که در شکل 15.9 نشان داده شده است ، از Notation نگاشت کلیددار استفاده می کند ، که بر روی سوال کردن در مورد میزان موجودی کالا و تغییر دادن مقدار آن متمرکز است .
در شکل 15.8 این موازنه با تولید اشیاعی انجام می شود ، که می توانند پاسخ دهند که چه سفارشاتی شده است و از هر کدام چه مقدار سفارش شده است .
یک بخش مهم برای تفسیر کردن این مدلها این است که چطور آنها روی واسط نوعها تاثیر می گذارند .
شکل 15.8 یک واسط از Getlineitems روی سفارش (Order) و محصول (Product) را نشان می دهد .
شکل 15.9 یک واسط از Getamount(Product) بر روی سفارش ایجاد می کند . در این شکل هیچ واسطی برای محصول نشان داده نشده است . برای دیدن استفاده از یک محصول در سفارشات مختلف ، پرسیدن تمام مشخصات سفارش لازم و ضروری است .
در شکل 15.8 صرفا نیاز به پرسیدن یک سفارش برای Lineitem هایش است، سپس هر Lineitem برای
تولیداتش . در شکل 15.9 نیاز به پرسیدن یک سفارش برای دیکشنری از مقادیر و سپس پرسیدن کلیدهایش است .سفارش (Order) باید یک اپریشن Getamounts برای دسترسی به دیکشنری اش ایجاد کند ، و در
غیر این صورت ما باید تمام مشخصات محصول را که مغایر با سفارش است ، تست کنیم .
شکل 15.8 همراه با قاعده و قانونی است که بیان می کند : فقط یک Lineitem می تواند برای هر محصول به ازای یک سفارش وجود داشته باشد .
ما یک Lineitem برای 30 چیز نمی خواهیم وهمچنین نمی خواهیم که یک Lineitem بین 20 چیز، روی یک در خواست مشابه تقسیم شود .
یک پیشنهاد بهتر این است که یک Lineitem واحد برای 50 چیز داشته باشیم . این کار در شکل 15.8 نیاز به یک قاعده و قانون دارد ولی در شکل 15.9 کاملا واضح است ، بطوریکه یک سفارش می تواند فقط یک مقدار برای سفارش داشته باشد .
لازم است که در نظر داشته باشیم که سفارش چه پاسخی باید بدهد اگر ، چیزهایی که در مورد محصول از او پرسیده شده است ، در سفارش نباشد . در این مثال معقولانه است که مقدار صفر را برگرداند واجبارا یک نگاشت کلیدرار تولید کند . در حالت دیگر ممکن است که بخواهیم مقدار NULL را برگردانیم ، که در این حالت ساختن نگاشت کلیددار اختیاری است .
اگر هر دو روش ارائه شده سودمند هستند ، پس دلیلی مبنی بر اینکه چرا از هر دوی آنها باهم استفاده نمیکنیم ، نداریم . ما می توانیم به زاید بودن و زیادی کار به دلیل استفاده از قواعد و قوانین و مشتق کردن ، پی ببریم.
در شکل 15.10 ، استفاده کردن از هر دو روش این حقیقت را نشان می دهد که فرایند شکل 15.8 در حالت کلی انعطاف پذیر تر شده است . در حالیکه فرایند شکل 15.9 رفتارهای خلاصه شده مفید زیادی را اضافه کرده است .
ما فهمیدیم که Notation نگاشت کلیددار ، ساختار بسیار مفیدی است . جواب این سوال که آیا از آن استفاده کنیم یا از یک نوع اضافی ، به موقعیت و وضعیت چیزی که روی آن تاکید داریم ، وابسته است . اگر چه من معتقدم که بدون آن هم قادر به زندگی هستم ، ولی از آن اغلب به عنوان یک ساختار مفید استفاده می کنم . با این وجود به استفاده مفرط از آن آگاه نیستم .
اغلب نوع های اضافی (Extra types) برای اطلاعات و رفتارهای اضافی (الحاقی) هستند ، به عنوان مثال در شکل 15.8 می توانیم به راحتی یک قیمت (Value) به Lineitem اضافه کنیم ، که استفاده از آن در شکل 15.9 ممکن است ناهنجار باشد .
15.3) نگاشت تاریخی (Historic Mapping) :
کلمه شی (Object) در واقع تنها به مفهوم اشیاعی که در جهان واقعی وجود دارند نیست ، بلکه اغلب یک حافظه ای از اشیاء را ارائه می دهند که به یک باره به وجود آمده اند ، ولی از آن زمان ناپدید شده اند .
استفاده از اشیاء برای ارائه دادن حافظه امری قابل پذیرش است . حافظه های هستی (Memory of Existance ) اغلب از خود هستی برای (Existance) برای مردم حقیقی تر هستند ، ولی مهم است که بتوانیم اختلاف آنها را بیان کنیم . مثالی از ذخیره سازی حقوق یک شهروند (Recording) را در نظر بگیرید . در هر لحظه از زمان ، فرد دارای حقوق خاص و واحدی است ، همانطور که در شکل 15.11 نشان داده شده است . بنابراین هر لحظه از زمان که می گذرد ، ممکن است این حقوق تغییر کند . این به خودی خود شکل 15.11 را به عنوان یک مدل ، باطل نمی کند ، مگر اینکه لازم باشد که تاریخ حقوق را به یاد داشته باشیم .
اگر همه ما مجبور باشیم که حقوقهای گذشته را به یاد آوریم ، آنگاه شکل 15.12 می تواند یک کلک باشد ،
که ما با استفاده از آن ، به معرف حقوق یک توانایی برای افزودن یک حقوق کهنه (Old salary) به لیست حقوقهای کهنه ، اضافه می کنیم . با استفاده از این لیست ما نمی توانیم حقوقهای قبلی را ذخیره کنیم بلکه مرتبه و نظمی را که این حقوقها عملی (پرداخت) شده اند را نگهداری می کنیم .
شکل 15.12 می تواند در بسیاری از شرایط مناسب باشد ، ولی نمی تواند به این سوال که حقوق jan smith
در دوم ژوئن 1997چه مقدار بوده است ، پاسخ دهد . برای پاسخ به این سوال ما به راه کارهای مصنوعی که در شکل 15.13 نشان داده شده است ، نیاز داریم . این مدل این توانایی را به ما می دهد که حقوق ها را همراه با تاریخ کامل آنها ذخیره کنیم . برای اینکه حقوقهای یک شخص دوره های روی هم افتاده نداشته باشد ، ما به یک قاعده اضافی نیاز داریم . این قاعده اغلب به صورت ضمنی فرض شده است و به صراحت نشان داده نشده است و در نتیجه فراموش شده است .
مدل شکل 15.13 توانایی را که ما می خواهیم ایجاد می کند ولی نسبتا نا آزموده و شل و ول است . این نکته مهم که یک شخص در هر زمان باید حقوق واحدی داشته باشد ، در قواعد زیربنایی در نظر گرفته نشده است .
یک پیوند بین دو نوع اکنون به صورت سه پیوند بین چهار نوع در آمده است . این موضوع می تواند پیچیدگی دیاگرام را به طور چشمگیری افزایش دهد . خصوصا اگر تعداد چنین رابطه های تاریخی زیاد باشد . رابطی هم که برای آن پیشنهاد شده است نا آزموده و شل و ول است .
جواب سوالی که در پاراگراف قبلی مطرح شد ، این است که jan smith زمان پرداخت تمام حقوقهایش را سوال کرده و سپس حقوقی را که در دوم ژوئن پرداخت شده است ، انتخاب کند .
من اغلب از مدلی که در شکل 15.14 نشان داده شده است ، استفاده می کنم .این مدل ترکیبی ازانعطافپذیری شکل 15.13 و اقتصاد دیاگرامی (Diagrammatic Economy) شکل 15.11 می باشد . همه جزییات در پشت یک نمونه کوچک ، ولی دارای کلمات کلیدی تاریخی پرمعنی ، پنهان است . من یک Notation جدید را معرفی می کنم که کاملا مجاز است ، به شرط این که آن را درست تعریف کنم . من از ارائه یک تعریف ریاضی برای آن خودداری می کنم و به جای آن رابطه ای را نشان می دهم که با کلمات کلیدی تعریف شده است .
شکل 15.11 یک متد GetSalary() را برای برگرداندن مقدار یک حقوق ویک متد SetSalary() را برای تغییر یک حقوق ، نشان می دهد . شکل 15.14 رابط مختلفی را نشان می دهد : GetSalary() همچنان وجود دارد ولی در هر زمان مقدار جاری را از Salary Mapping باز می گرداند .این کار توسط متد
GetSalary(Date) حمایت می شود ، که بر طبق تاریخ پیشنهاد شده مقدار حقوق را از Salary Mapping
باز می گرداند . GetSalary() معادل باGetSalary(Date:Now) است . Update کردن آن نیز به مقدار ناچیزی پیچیده تر است .
ما می توانیم از SetSalary(Money , Date) برای اضافه کردن یک حقوق جدید به History ، که از زمان خاصی آغاز می شود ، استفاده کنیم . این یک واسط مناسب برای اضافه کردن تغییرات است ، ولی اگر یک رکورد قدیمی بخواهد تغییر کند ، آنگاه این واسط کافی نیست . برای این مسئله می توان اپریشن ها را بدین صورت تعریف کرد : SetSalary(Key:Timeperiod , Value:Money) به همراه اپریشن
GetSalaryHistory() که برای این شرط بهتر است . پس مراجعه کننده می تواند تاریخ حقوق فعلی را به عنوان دیکشنری بگیرد و سپس تمام رکوردها را در یکبار رفتن و مرور کردن اصلاح کند . این کار بهتر از
Update کردن یک رکورد در هر زمان است . طبق این قاعده ، هر کارمند باید یک حقوق واحد در هر زمان داشته باشد .
اگر در هر زمان تغییراتی در یک رکورد داده شود ، آنگاه حفظ قاعده و قانون بصورت درست ، ناهنجار
می باشد . درآوردن یک رکورد بطور کامل ، تغییر دادن آن بدون چک کردن قاعده ، وسپس جایگزین کردن آن در یک زمان ، برای اداره کردن بسیار ساده تر است .
بطور واضح در اینجا یک پیاده سازی لغت نامه ای (Dictionary Implementation) با دوره های زمانی ، که به عنوان کلیدها هستند ، پیشنهاد می شود .این نوع پیاده سازی به آسانی تمام رفتارهایی (Behaviors) را که یک واسط (Interface) نیاز دارد ، پشتیبانی (Support) می کند و در واقع یک استفاده راحت از فرایند است .
ما حتی می توانیم کارهای فراتری انجام دهیم و یک کلاس مخصوص برای دستکاری و اداره کردن مجموعه های تاریخی ، معرفی کنیم .
Notation های تاریخی توسط اکثر روش شناسان ( (Methodologistدر حال حاضر برای شناخت و دانش ما ، پیشنهاد نمی شوند ، در حالی که بسیار با ارزش و مفید هستند ، زیرا موقعیت هایی که رایج و Strick ای (چسب دار) هستند ، را ساده می کند .
یک راه حل ایدآل داشتن یک Object System با توانایی کامل گذر زمان (Time Travel) است. چنین سیستمی خیلی دور از ذهن نیست ، و مزیت وتوانایی هایی را که به همراه خود می آورد ، می تواند نیاز به برخی از دستکاری ها را روی تاریخ ، حذف کند .
این بخش یک حالت خاص از نکته اصلی است . در مدل سازی شما ممکن است به موقعیتی تکراری بر بخورید ، که هم رایج است و هم مدل سازی آن ناهنجار است . برای ساده کردن آن نترسید و یک Notation
جدید تعریف کنید ، ولی باید این Notation را به درستی تعریف کنید . انتخاب کلید ، برای ساده سازی ساختارجدید است ، در حا لیکه دیگر مجبور نیستیم Notation های اضافی را به یاد آوریم . یک Notation
خوب ، یک توافق است .
اساس مدل سازی (Modeling Principle) :
" اگر شما با یک موقعیت تکراری برخورد کردید ، که برای مدل سازی دشوار است ، آنگاه یک Notation
تعریف کنید . بنابراین تنها زمانی یک Notation تعریف کنید که سادگی این Notation ، سختی بیاد آوردن
یک Notation اضافی را ، ساده می کند . "
15.3.1 ) تاریخ دو بعدی (Two-Dimensional History)
بحثی که در بالا داشتیم روی این مسئله بود که ، بتوانیم مقادیر بعضی ازخصیصه(Attribute)های یک شی را که در گذشته وجود داشته است ، بدست آوریم . بسیاری از سیستم ها دارای پیچیدگی و مشکل بیشتری هستند که از این حقیقت ناشی می شود ، که نمی توانند تغییرات بوجود آمده را به موقع شناسایی کنند .
فرض کنید ما یک سیستم لیست حقوقی داریم که نشان می دهد یک کارمند دارای نرخ حقوق 100 دلار در روز است ، که از اولین روز January آغاز می شود . در 25 February ما لیست حقوق را با این نرخ به
راه می اندازیم . در 15 March می فهمیم که نرخ حقوق در 15 February به 110 دلار در روز تغییر کرده است .
حال یک شی کارمند وقتی که از او نرخ حقوقش در 25 February پرسیده می شود ، چه پاسخی باید بدهد ؟
در این جا دو جواب برای این سوال وجود دارد : 1- مقدار حقوقی را که کارمند در آن زمان فکر می کرد و
2- مقدار حقوقی را که اکنون فکر می کند ، که هر دوی این نرخ ها مهم هستند .
اگر لازم باشد که نگاهی به قبل از 25 February بیندازیم ، آنگاه محاسبه کننده حقوق (PayRoll) شروع به کار می کند تا ببند که ارقام چگونه محاسبه شده اند ، که لازم است شکل های قبلی را ببینیم .
اگر لازم باشد حقوق جدید را محاسبه کنیم ، مثلا برای چند ساعت اضافه کاری که دیر گزارش شده است ، لازم است نرخ حقوق کنونی را بدانیم .
حال فرض کنید که در 24 April به ما گفته می شود که نرخ حقوق کارمند دوباره در 21 February به 112 دلار در روز تغییر کرده است . اکنون یک شی کارمند به این سوال که نرخ حقوقش در25 February
چقدر بوده است ، می تواند سه پاسخ بدهد .
بطور کلی برای رفع این نوع مشکل ، ما به یک تاریخ دوبعدی نیاز داریم . ما براساس آگاهی و شناخت قبلی خود ، نرخ حقوق کارمند را در چند نقطه از زمانهای گذشته از او می پرسیم .
بنابراین دو تاریخ مورد نیاز است : 1- تاریخی که نرخ حقوق عملی (Applicable) شده است ، 2- تاریخی که ما اساس شناخت و آگاهی خود را بر آن قرار داده ایم . همانطور که درجدول 15.1 نشان داده شده است .
یک مثال تک بعدی باید رفتار موثر را بین تاریخ عملی شدن حقوق و تاریخی که اساس شناخت و آگاهی ما بر آن قرار گرفته است ، انتخاب کند ، یا همیشه در نظر داشته باشد تاریخ شناخت بر اساس زمان حال باشد .
افزودن توانایی کامل دو بعدی به تاریخ ، مطمئنا پیچیدگی بیشتری را بوجود می آورد ، و این کار همیشه ارزنده نیست . ما باید به این نکته مهم توجه کنیم ، که به چه دلیل نرخ حقوقی تغییر کرده است .
در این مثال تنها دلیل ما برای دانستن چیز هایی به غیر ازآگاهی و شناخت رایج مان ، شرح دادن و فرستادن تنظیمات به لیست حقوقی است .
یک موضوع دیگر برای برخورد با این مشکل اینست که بدانیم چطور یک لیست حقوقی از نتایج محاسبات
لیستهای حقوقی دیگر ، بدست می آید .
اگر این اطلاعات تنها توسط انسان قابل رسیدگی باشد و قبلا پردازش نشده باشد ، این کار می تواند توسط یک خصیصه متنی (Attribute Textual) انجام شود .
محاسبه کردن تنضیمات می تواند با مراجعه به نتایج محاسبات ، انجام شود . نرخ حقوقی که از آن استفاده شد حتما لازم نیست . حتی اگر نرخ حقوقی لازم شود ، می توانیم با ساختن یک کپی از آن ، کار خود را امن تر کنیم . با همه این مسائل در اینجا یک تاریخ یک بعدی لازم است ، بنابراین می توان به استحقاق های قبلی
( مثلا دو ساعت اضافه کاری دیر گزارش شده ) دسترسی داشت .
تاریخ دو بعدی همچنین روی TimePoint هایی که درطول رویدادها (Events) بوجودآمده اند ، تاثیرمی_ گذارد ، مگر اینکه مطمئن باشیم وقتی یک رویداد رخ می دهد ، ما از آن باخبر هستیم .
ما در رویدادها به دو TimePoint نیاز داریم : TimePoint ای که رویداد در آن رخ میدهد وTimePoint
ای که سیستم ما از آن رویداد آگاه می شود .
