گزارش سمینار کارشناسی ارشد
گروه فناوری اطلاعات
چکیده
یکی از نیازمندیها در معماری مدل رانه امکان انتشار تغییرات ایجاد شده در یک مدل به سایر مدل
های مرتبط با آن و سازگار کردن این مدلها با یکدیگر است. همگام سازی فرآورده های مرتبط با یکدیگر
یکی از فعالیتهای کلیدی در نگهداری نرم افزار میباشد که بسیار زمانبر و پرخطاست. با توجه به هزینه
های سنگین نگهداری محصولات نرمافزاری همواره یافتن راهی برای کاهش این هزینهها مورد توجه
بودهاست. از آنجا که مدلها فرآوردههای اصلی در توسعه مدلرانه هستند بنابراین همگامسازی مدلها
یکی از فعالیتهای اصلی در نگهداری آنها تلقی میشود. خودکارسازی روشی برای کاهش هزینههاست
اما همه فعالیتها قابل خوکارسازی نبوده و فعالیتهایی که به صورت سیستماتیک و روشمند قابل انجام
باشند امکان خودکارسازی آنها وجود دارد. از آنجا که نمایش مدلها در معماری مدلرانه بر اساس
استانداردهای مشخص بوده و تبدیلات مدل به صورت خودکار و یا نیمه خودکار قابل انجام است، به نظر
میرسد خودکارسازی همگامی مدلها دور از دسترس نباشد. در این گزارش نتیجه مطالعات انجام شده بر
روی خودکارسازی همگامی مدلها در معماری مدلرانه ارائه شدهاست. هدف این مطالعات بیان یک
مساله باز و اهمیت آن در این حوزه و مشخص کردن کارهای آینده در راستای رسیدن به راهحلی مناسب
برای مساله مورد نظر میباشد.
تا کنون برای همگامسازی مدلهای طراحی با کد منبع کارهایی انجام شده است و برخی از ابزارها
مانند OptimalJ این همگامسازی را تا حدی انجام میدهند. اما همگامسازی مدل با مدل بعد از ارائه
معماری مدلرانه توسط گروه مدیریت شی مطرح شدهاست. بهعلاوه روشهای پیشنهادی متفاوتی برای
همگام سازی مدل ها با یکدیگر بیان شدهاست. در روشهای ابتدایی تر از نوشتن قوانین تبدیل دو طرفه
برای همگام سازی استفاده شدهاست که معایب بسیاری دارد و در سالهای اخیر روشهایی برای همگام
سازی تدریجی مدلها پیشنهاد شده است که بر پایه استاندارد TGG بوده و تمامی عملگرهای تحقیق را
پشتیبانی نمیکنند.
گروه مدیریت شی همواره استانداردهایی را برای پشتیبانی و حل مشکلات معماری مدل رانه ارائه می
کند. در همین راستا استاندارد MOF 2.0 QVT را در سال 2008 ارائه کردهاست که در آن نحوه تبدیل
مدلهای منطبق بر MOF 2.0 را بیان کردهاست. در این استاندارد به هنگام تبدیلات مدل سابقه
تبدیلات و روابط بین اجزا مدلها نگهداری میشود .به نظر میرسد که با استفاده از اطلاعات تبدیلات
بدستآمده از تبدیلات مدل میتوان برای همگامسازی تدریجی مدلها با یکدیگر استفاده نمود. بنابراین
در این تحقیق به دنبال مطالعه دقیق روشهای همگامسازی و نقایص و خلاهای موجود در این روشها
هستیم تا در ادامه بتوانیم در روش پیشنهادی مورد نظرمان این نقایص را برطرف نماییم.
کلمات کلیدی:
همگام سازی مدل، تبدیلات مدل، روابط پیگیری، معماری مدل رانه، توسعه مدل رانه
Model Synchronization, Model Transformation, Traceability Relationship,
Model Driven Architecture, Model Driven Development.
1- مقدمه
از آنجا که بسیاری از فعالیتها در فرآیند نگهداری نرم افزار به صورت غیرساختیافته انجام میشود ،
نگهداری فرآیندی وقتگیر و پرهزینه میباشد. این در حالی است که استفاده از روشهای ساختیافته
برای انجام فعالیتها در راستای خودکار سازی فعالیتهای نگهداری و افزایش کارایی آنها موفق بودهاند.
با توجه به آنکه همگام سازی یکی از فعالیتهای اصلی در تغییر محصولات نرمافزاری است میتوانیم
هزینه نگهداری نرمافزار را با خودکارسازی فعالیتهای همگامسازی کاهش دهیم. از آنجا که مدلها
عناصر اصلی معماری مدلرانه بوده و معماری مدلرانه چارچوبی را برای نمایش ساختیافته این مدلها
فراهم کردهاست، امکان خودکار سازی و افزایش بهرهوری فعالیتهای نگهداری و تکامل نرمافزار در یک
سیستم مدلرانه وجود دارد.
1-1- نگهداری نرمافزار
نگهداری نرمافزار پرهزینهترین فعالیت در چرخه حیات نرمافزار است. طبق گزارشات اعلام شده هزینه
سالیانه نگهداری نرمافزار در امریکا در حدود 07 میلیارد دلار امریکا تخمین زده شدهاست. این آمار زمانی
شگفتانگیزتر است که با هزینه کلی تولید نرمافزار مقایسه شود. تحقیقات اخیر نشان میدهد که حدود 09 درصد هزینهها در چرخه حیات نرمافزار مربوط به مرحله نگهداری آن میباشد. در جدول 1-1 نتیجه
این تحقیقات در سالهای گذشته نشان داده شدهاست. با توجه به این آمار نیازمند روشهایی هستیم که
ما را در کاهش این هزینه کمک کنند[(جداول در فایل اصلی موجود است)
برای کاهش هزینه ابتدا لازم است بدانیم که نگهداری نرمافزار شامل چه فعالیتهایی میشود.
استاندارد ISO/IEC 14764 نگهداری نرمافزار را در 4 دسته مجزا تعریف میکند:
Corrective maintenance: اعمال تغییرات در نرم افزار که بعد از تحویل و برای اصلاح خطاهای
کشف شده انجام می شود.
Adaptive maintenance: اعمال تغییرات در نرم افزار که بعد از تحویل و به منظور قابل استفاده
کردن محصول در مقابل تعییرات محیط انجام می شود.
Perfective maintenance: اعمال تغییرات در نرم افزار که بعد از تحویل و برای ارتقا کارایی یا
قابلیت نگهداری در نرم افزار انجام می شود.
Preventive maintenance: اعمال تغییرات در نرم افزار که بعد از تحویل و برای کشف و اصلاح
خطاهای آن پیش از آن که به خطاهای تاثیر گذار تبدیل شوند انجام می شود.
هرچند تعریف ارائه شده این 4 دسته را مجزا توصیف میکند اما همانطور که از تعاریف مشخص است
اعمال تغییرات فعالیتی است که در همه آنها مشترک بوده و فعالیت اصلی است که باید در مرحله نگهداری نرمافزار انجام شود. بنابراین اگر بتوانیم نرمافزارها را به راحتی تغییر دهیم خواهیم توانست
هزینه نگهداری نرمافزار را کاهش دهیم.
در مقایسه سختافزار با نرمافزار اینگونه به نظر میرسد که نرمافزار باید به راحتی قابل تغییر باشد. اما
زمانیکه همگامیهای پیچیده که باید بعد از تغییر یک فرآورده صورت بگیرد، در نظر گرفته شود، دشواری
تغییرات برای ما موجه خواهد شد. در تولید نرمافزار، توسعهدهندهگان انواع مختلفی از فرآوردهها را در
مراحل مختلف این چرخه تولید میکنند. برای مثال در مرحله نیازمندیها مستندات نیازمندی، مدلهای
مورد کاربری ایجاد میشوند. در مرحله طراحی مدلهای UML, ER را خواهیم داشت و در مرحله پیاده
سازی کد نهایی تولید خواهد شد. این فرآوردهها به یکدیگر مرتبط بوده و روابط سازگاری پیچیدهای به
این فرآوردهها وجود دارد. برای مثال برای هر کلاسی در نمودار کلاس UML باید کلاسی با همان نام در
کد پیادهسازی وجود داشته باشد.
زمانیکه توسعه دهندگان بخشی از یک فرآورده را بهروزرسانی میکنند برخی از روابط سازگاری بین
فرآوردهها از بین میرود که سبب بروز ناسازگاری بین آنها میشود. در شکل1 -1 توسعه دهندگان نام
پیام را از Select به Choose تغییر نام دادهاند و این امر سبب ناسازگاری نمودار ترتیبی و کلاس شده
است. برای سازگار کردن فرآوردهها با یکدیگر باید تغییرات ایجاد شده در هرکدام را به دیگر فرآوردهها
انتقال دهیم. فرآیند برقراری سازگاری بین مجموعهای از فرآوردهها را همگام سازی میگویند.
شکل 1-1: ناسازگاری بین نمودار کلاس و نمودار ترتیبی بعد از اعمال تغییرات. منبع[8]
در فرآیند نگهداری نرمافزار از آنجا که بسیاری از فعالیتها بهصورت غیرساختیافته انجام میشود
سبب میشود که نگهداری فرآیندی وقتگیر و هزینه بر باشد. این در حالی است که استفاده از روشهای
ساختیافته در راستای خودکار سازی فعالیتهای نگهداری و افزایش کارایی آنها موفق بودهاند. از آنجا
که همگامسازی یکی از فعالیتهای اصلی در تغییر محصولات نرمافزاری است میتوانیم هزینه نگهداری
نرمافزار را با خودکارسازی فعالیتهای همگامسازی کاهش دهیم. همانطور که در بخش دوم خواهیم دید
مدلها عناصر اصلی معماری مدلرانه بوده و معماری مدلرانه چارچوبی را برای نمایش ساختیافته این
مدلها فراهم کردهاست. به همین دلیل امکان خودکار سازی و افزایش بهرهوری فعالیتهای نگهداری و
تکامل نرمافزار در یک سیستم مدلرانه وجود دارد.
2-1- پیچیدگی نرمافزار
فرآیند تولید نرمافزار همواره یک فرآیند پیچیده و دشوار بوده و هست. به بیان دیگر این پیچیدگی
یک ویژگی ذاتی سیستمهای نرمافزاری بزرگ است و نمیتوان آنرا از بین برد بلکه باید آنرا کنترل
کنیم. اما چرا پیچیدگی یک ویژگی جدایی ناپذیر برای اینگونه سیستمهاست؟ در واقع این پیچیدگی از
چهار فاکتور ناشی میشود[41]:
1-2 -1- پیچیدگی مسأله
معمولاً سیستم های نرم افزاری بزرگ حاوی عناصری است که پیچیدگی آنها اجتناب ناپذیر بوده، این
پیچیدگی ناشی از:
وجود نیازمندی های گوناگون و حتی متضاد
چنانکه میدانیم نیازمندیها به دو گروه کلی تقسیم میشوند: نیازمندیهای وظیفهای که عبارتست از
عملکرد خام سیستم و نیازمندیهای غیر وظیفهای که معمولاً به صورت ضمنی بیان میشوند مانند کارایی، قابلیت اعتماد و ... . مثلاً یک سیستم هوشمند مانند روبات را در نظر بگیرید: مشخص است که
درک عملکرد چنین سیستمی به اندازه کافی سخت است (نیازمندیهای وظیفهای) حال اگر به این
نیازمندیها ،نیازمندیهای غیروظیفهای نیز اضافه گردد همان پیچیدگی غیرقانونمند بوجود خواهد آمد.
ناتوانی کاربر و مهندس نرم افزار در درک صحیح یکدیگر
معمولاً برای کاربران توصیف نیازهای مورد نظر خود به صورتی قابل فهم برای توسعه دهنده سیستم
خیلی مشکل است. در موارد بسیاری کاربران فقط ایدههای مبهمی از آنچه میخواهند سیستم نرم افزاری
حاوی آن باشد، را دارند. البته بدین معنی نیست که کاربر یا توسعه دهنده سیستم (یا هر دو ) مقصرند،
بلکه -به طور کلی- این مشکل ناشی از عدم وجود آشنائی کافی هر دو از زمینههای کاری یکدیگر است.
در واقع، کاربران و توسعه دهندگان سیستم دارای دو دید مختلف نسبت به مسأله و راه حل آن هستند.
تغییر نیازها در زمان طراحی سیستم و بعد از تولید آن
این فاکتور در افزایش پیچیدگی مسأله سهم بسزایی دارد . در واقع دیدن نمونههای اولیه سیستم و
مستندات طراحی (در زمان طراحی ) سپس استفاده از سیستم بعد از نصب آن، باعث پیبردن و درک
بهتر و واقعیتر کاربر نسبت به نیازهای خود است. از طرف دیگر خبرگی توسعه دهندگان سیستم نسبت
به مسأله و را ه های حل آن بیشتر میشود و میتوانند سوالهای بهتری درباره جنبههای مبهم رفتار
سیستم طرح نمایند و بدین صورت دید کاملتری نسبت به سیستم پیدا خواهند کرد.
2- 2-1- مشکل کنترل فرآیند تولید
سیستم های نرم افزاری روزبهروز پیچیده تر میشوند. امروزه ما شاهد سیستمهای نرمافزاری بزرگی
هستیم که حجم آنها با صد هزار خط یا حتی یک میلیون خط اندازهگیری میشود. درک کامل و دقیق
چنین سیستمهای بزرگی از عهده یک نفر خارج است. حتی اگر سعی کنیم سیستم را به واحدهایی با
معنی تجزیه نماییم، باز با صدها واحد روبرو خواهیم شد .پس ما به یک گروه یا یک تیم از متخصصین نیاز داریم. به صورت ایده آل باید سعی کنیم از یک تیم با حداقل افراد استفاده نماییم ولی صر ف نظر از
اندازه تیم، توسعه مبتنی بر تیمها همیشه با مشکلات مهمی روبرو بوده است، زیرا افراد بیشتر، به معنی
ارتباطات پیچیدهتر و در نتیجه هماهنگی بین افراد تیم مشکلتر میشود .بخصوص اگر تیم از نظر
جغرافیائی پراکنده باشد. در واقع مشکل کلیدی که توسعه تیمی با آن مواجه است همان مدیریت صحیح
افراد تیم به طوری است که یگانگی و یکپارچگی تحلیل و طراحی حفظ گردد.
3- 2-1- استاندارد نبودن نرم افزار
معمولاً یک شرکت ساختمان سازی برای ساختن یک ساختمان از مصالح ساختمانی با مشخصات
استاندارد مانند آجر و آهن که بوسیله شرکتهای دیگر تولید شدهاست، استفاده مینماید یا در صنعت
سخت افزار مثلاً برای ساختن یک برد از IC های استاندارد ساخت شرکتهای دیگر استفاده میشود و
هرگز خود شرکت سازنده اقدام به ساختن همه قطعات مورد نیاز این برد نمیکند ولی متاسفانه چنین
اتفاقی در صنعت نرمافزار به فراوانی رخ می دهد!
به علاوه، در صنعت ساختمانسازی استانداردهایی برای تضمین کیفیت مواد اولیه مورد نیاز وجود
دارد در حالیکه صنعت نرمافزار از این نظر خیلی عقب است! لذا تولید سیستمهای نرمافزاری یک کار
طاقت فرسا به شمار میآید.
4- 2-1- مشکل توصیف رفتار سیستم های پیچیده
از نظر رفتار می توان سیستم ها را -به طور کلی- به دو گروه تقسیم نمود:
سیستم های پیوسته: رفتار این سیستمها بوسیله یک تابع پیوسته توصیف میگردد، که توسط آن
میتوان رفتار سیستم و عکسالعمل آن در مقابل رویدادهای گوناگون را پیشبینی کرد .
سیستمهای گسسته: این سیستمها از تعداد متناهی حالت تشکیل شده اند که این تعداد در
سیستمهای گسسته پیچیده معمولاً عدد بزرگی است. ویژگی بارز این سیستمها این است که نمیتوان
انتقال بین حالتهای مختلف سیستم بوسیله توابع پیوسته را مدل سازی نمود. لذا این امکان بالقوه وجود
دارد که به ازای یک رویداد غیر منتظره خارجی، سیستم از حالت فعلی به حالت جدید و غیر مطلوب
منتقل گردد که این انتقال میتواند غیر قطعی باشد و در بدترین شرایط این رویداد میتواند حالت
سیستم را خراب نماید. با توجه به اینکه کامپیوترهای دیجیتال سیستمهای گسسته هستند و اینکه نرم
افزار روی این دستگاه ها اجرا میگردد، پس ما با یک سیستم گسسته سروکار داریم.
حال به این مثال توجه نمایید: فرض کنید یک هواپیما بوسیله یک کامپیوتر کنترل میشود، چون
با یک سیستم گسسته مواجه هستیم احتمال بروز حالتی مانند اینکه وقتی یک مسافر لامپ بالای سر
خود را روشن کند آنگاه -مثلاً - هواپیما به طور ناگهانی به سمت پایین حرکت نماید، وجود دارد! در یک
سیستم پیوسته ما انتظار بروز چنین رویدادی را نداریم ولی متأسفانه در یک سیستم گسسته به علت
اینکه طراحان سیستم فعل و انفعالهایی که بین تعدادی از رویدادهای ویژه رخ میدهد را در نظر
نگرفتهاند احتمال بروز چنین حالتهایی وجود دارد. با توجه به مثال فوق و اینکه نرمافزار یک سیستم
گسسته است، میبینیم که این خاصیت یکی از عوامل افزایش پیچیدگی سیستمهای نرمافزاری است. پس برای رسیدن به نرمافزار با کیفیت و قابلیت اطمینان بالا چه باید کرد؟ این هدف جز با انجام
آزمایشهای گوناگون و جامع تحقق نمییابد.
1-3- ضرورت توجه به مساله همگامسازی در معماری مدلرانه