طی چند سال اخیر، سازمانهای بسیاری، به عنوان خط مشیای در طراحی و ساخت برنامههای كاربردی، به معماری مدلگرا (MDA - Model Driven Architecture) روی آوردهاند.
در فرآیند ساخت نرمافزار، از دیدگاه جایگاه و اهمیت مدلسازی، دو رویكرد مدلسازیِ صرف، و برنامهنویسیِ محض نقطهی مقابل یکدیگرند و در بین آنها دیدگاههای كاربردیتر قرار میگیرند. معماری مدلگرا رویكرد به نسبت جدیدی است كه سازندهی دنیای شیگرا اوامجی (OMG - Object Management Group) آن را عرضه نموده است. سازمانها میتوانند از این رویكرد به عنوان چارچوبی برای ترسیم معماری فناوری اطلاعات خود بهره بگیرند.
مقدمه
چند سالی است كه اوامجی رویكرد جدیدی در طراحی و ساخت نرمافزار ارایه كرده است. این رویكرد «معماری مدلگرا یا MDA» نام دارد كه دلایل زیادی ثابت میکنند روش مثبتی در فرآیند ساخت نرمافزار است. معماری مدلگرا استفادهی موثر از مدلها را در فرآیند ساخت نرمافزار ترغیب و از استفادهی مجدد تکنیکهای برتر در ساخت سیستمهای مشابه پشتیبانی میکند. طبق تعریف اوامجی معماری مدلگرا راهی برای سازماندهی و مدیریت معماری نرمافزارهای ابرسازمانی است. که این کار را از طریق به كارگیری ابزار و خدمات خودكار، هم برای تعریف مدلها و هم به منظور تسهیل تبدیل یك مدل به مدلی دیگر انجام میدهد
با سازماندهی یك سیستم، به عنوان مجموعهای از خدمات كپسوله شده كه سرویسهای دیگر را از طریق رابطهایشان فرا میخوانند، میتوان انعطاف معماری سیستم را افزایش داد.
گرچه استانداردها و اصطلاحاتی كه در معماری مدلگرا به كار رفته، مدتهاست كه توسط صنایع مورد ارجاع قرار میگیرند، ولی اوامجی و اعضای آن (از جمله IBM Rational) اخیرا موفق به ارایهی تعریف روشنی از این معماری شدهاند. در این تعاریف میفهمیم كه در حال حاضر تكامل این معماری در چه مرحلهای است، چه جنبههایی از آن با فناوری روز قابل استفاده بوده و چگونه میتوان در عمل از آن بهره گرفت.
در این مقاله، به نحوهی استفاده از مدلسازی در دنیای كنونی صنعت نرمافزار و تناسب معماری مدلگرا با سیستمهای روز میپردازیم. همچنین، اهمیت مدل و مدلسازی را بیان نموده و چهار اصل اساسی معماری مدلگرا را ارایه خواهیم كرد. در انتها نگاهی اجمالی به پشتیبانی IBM Rational از این معماری خواهیم داشت.
امروزه ساخت نرمافزارهای ابرسازمانی نیازمند استفاده از معماریای است كه امكان تكامل نرمافزار را به گونهای کاملا انعطافپذیر فراهم كند. چنین دیدی باید امكان استفادهی مجدد از نرمافزارهای ساخته شده را حتی اگر زیرساخت نیز در حال تغییر و گسترش باشد؛ در ساخت قابلیتهای جدیدی برای كسب و كار فراهم نماید. در این راستا، دو تفكر محوری چنین رویكردی عبارتاند از:
- معماری سرویسگرا (Service Oriented Architecture - SOA)- نرمافزار ابرسازمانی را میتوان به عنوان گروه سرویسهایی تعریف كرد كه از طریق قراردادهای خوشتعریفی كه رابط سرویسها را مشخص میكنند، به هم متصل هستند. طراحی چنین سیستمهایی غالبا معماری سرویسگرا خوانده میشود. با سازماندهی یك سیستم، به عنوان مجموعهای از خدمات كپسوله شده كه سرویسهای دیگر را از طریق رابطهایشان فرا میخوانند، میتوان انعطاف معماری سیستم را افزایش داد. در حال حاضر، بسیاری از سازمانها نرمافزارهای خود را در قالب سرویسها و ارتباط متقابل آنها، تعریف میكنند.
- خط تولید نرمافزار (Software Product Line) – معمولا بین سیستمهایی كه یك سازمان میسازد و نگهداری میكند، وجوه مشترك بسیاری وجود دارد. رهیافتهای تكراری را در تمام سطوح یك پروژهی ساخت نرمافزار میتوان مشاهده كرد: از ترسیم یك مدل حوزهی استاندارد برای نمایش حیطهی كاری اصلی سازمان گرفته تا روشهای خاصی كه برنامهنویسان برای تبدیل طرح به كد استفاده میكنند. در صورتی كه چنین الگوهایی توسط اهل فن شناسایی و تعریف شده و در بدنهی فناوری اطلاعات به كار گرفته شود، كارآیی سازمان به میزان قابل توجهی افزایش خواهد یافت. این رویکردی «خط تولید گونه» در ساخت نرمافزار، با استفاده مجدد از داراییها و بهكارگیری بیشتر خودكارسازی (automation) است.
دو ایدهی مطرح شده تاثیر بسیاری بر شیوهی تفكر اوامجی، به عنوان كنسرسیومی از شركتهایی كه بر ارایهی استانداردهای لازم برای ساخت نرمافزار نظارت دارند، داشته است. اوامجی چارچوبی مفهومی ایجاد كرده كه تصمیمات مبتنی بر كسب و كار را از تصمیمات مبتنی بر بستره جدا میكند. این چارچوب همراه با استانداردی كه به تحقق آن كمك میكند، معماری مدلگرا نامیده شده است. معماران سیستم از معماری مدلگرا برای تعیین جزییات معماری نرمافزار ابرسازمانی استفاده میكنند و استاندارد بازِ ذاتی آن را برای استقلال آتی از تولید كنندهی نرمافزار و فناوری استفاده شده، به كار میگیرند. مفهوم معماری مدلگرا، در ساخت سیستمهای مرتبط، رویكردی آزاد و مستقل از تولید كنندهی نرمافزار اتخاذ میكند و این امر را با استفاده از ابزارهایی چون UML،( Meta-Object Facility) MOF ، (XML Metadata Interchange) XMI و (CWM (Common Warehouse Meta-modelبه انجام میرساند. خدمات یك سازمان را میتوان با استفاده از این استانداردها توصیف و نهایتا آنها را به بسترههای تجاری یا آزادی مانند CORBA ،J2EE ،.NET و دیگر بسترههای وبمحور تبدیل نمود.
پیش از این كه بیشتر در جزییات معماری مدلگرا وارد شویم، بهتر است اندكی به مزایای مدلسازی در تولید نرمافزار بپردازیم.
دلیل عقلی مدلسازی
هر مدل، یك انتزاع از یك سیستم فیزیكی را ارایه میكند تا مهندسین بتوانند به دور از جزییات فرعی، به بررسی منطق سیستم بپردازند. تمام رشتههای مهندسی برای درك پیچیدگی سیستمهای جهان واقع، به مدلها اتكا میكنند. مدلها به روشهای گوناگونی استفاده میشوند: پیشبینی كیفیت سیستم؛ بحث در مورد خصوصیاتی معین، ارایه و تبادل نظر در مورد ویژگیهای كلیدی سیستم با ذینفعان آن زمانی كه مشخصات سیستم تغییر میكند و الخ. مدلها ممكن است به عنوان پیشنیاز تولید سیستم فیزیكی ساخته شوند و یا به منظور درك بهتری از رفتار سیستم از سازکاری موجود یا حتی در حال ساخت، نشات بگیرند.
دیدگاهها و تبدیل مدلها
از آن جایی كه در مدلسازی ممكن است جنبههای مختلفی از سیستم مد نظر باشد، برای روشن ساختن یك نقطهی خاص، یا یك دیدگاه، امكان دارد بسته به نیاز از مدلهای متعددی استفاده شود. به علاوه، ممكن است كه از توضیحات و قواعدی برای آسانتر كردن تبدیل مدلها به یكدیگر نیز بهره گرفته شود. غالبا، لازم میشود كه دیدگاههای مختلف در یك سطح انتزاع به یكدیگر تبدیل شوند، مانند تبدیل «دیدگاه ساختاری» به «دیدگاه رفتاری». ابزار تبدیل دیدگاهها، چنین تبدیلی را امكانپذیر میسازد. در دیگر موارد، چنین تبدیلی در انتقال از یك سطح انتزاعی به سطحی جزییتر یا كمتر انتزاعی، كه معمولا با افزودن جزییات همراه است، میسر میباشد.
مدل، مدلسازی و معماری مدلگرا
مدلها و ساخت نرمافزار بر اساس مدلسازی در قلب رویكرد معماری مدلگرا قرار گرفته است. بنابراین، بد نیست ابتدا به مزایای مدلسازی برای معماران و برنامهنویسان نرمافزارهای ابرسازمانی بپردازیم.
در دنیای مهندسی نرمافزار، مدلسازی پیشینهای غنی دارد، كه به اولین روزهای برنامهنویسی بازمیگردد. ابداعات اخیر بر نمادسازیها و ابزارهایی تمركز داشته كه به كاربران كمك میكند وجوهی از سیستم را كه ارزش نرمافزار شدن را دارد، برای معماران نرمافزار بیان كنند و به برنامهنویسان نیز در تبدیل خودكار مشخصات به كدی كه روی بستره و سیستم عامل خاصی كار كند، یاری میرساند. در حال حاضر، زبان نموداریِ UML به عنوان یك مجموعه نمادهای غالب در مدلسازی شناخته میشود. این زبان به گروه تولید نرمافزار اجازه میدهد كه جنبههای مختلف سیستم را با مدلهای متناسب نمایش دهند. با این حال، تبدیل این مدلها هنوز بیشتر دستی انجام میشود. یكی از راههای مفید در توصیفِ وضعیت كنونیِ تولید و مدلسازی این است كه میزان هماهنگی (synchronization) كد برنامه و مدلهایی كه بر اساس آنها تولید میشود، بررسی شود. این امر در شكل (1) نشان داده شده است. این شكل طیفی از رویكردهایی از تولید نرمافزار را كه در صنعت نرمافزار به كار گرفته میشود، نشان میدهد. هر دسته، نشانگر نحوهی استفاده از مدلسازی در ایجاد كد اجرایی برنامه و ارتباط این دو است.
شكل 1 - طیف مدلسازی
تجسم كد (code visualizations) روشی كمی پیشرفتهتر است. در این روش، برنامهنویس هر جا كه لازم باشد، همگام با كدنویسی، به نمایش بصری كد برنامه نیز میپردازد، تا بتواند ساختار یا رفتار كد نوشته شده را بهتر درك كند. با كمی تغییر در نمادها میتوان مدلی به دست آورد كه نمایانگر كد باشد. این گونه مدلها، كه درون محیط برنامهنویسی قابل تهیه هستند، به «مدل كد» یا «مدل پیادهسازی» موسوماند. به عنوان مثال، در IBM WebSphere Studio و Borland Together/J دیدن همزمان كد و نمایش تصویری آن امکانپذیر است. در این روش، مدل و كد به شدت به هم بستگی دارند.
در این جا مزیت مدلسازی در روش دیگری كه به نام نظام مهندسی سیستم رفت و برگشتی (Round-Trip Engineering RTE) معروف است را بررسی میكنیم. در این روش تبادل دوسویهای بین مدل انتزاعی و كد وجود دارد. بدین ترتیب كه ابتدا مدلی انتزاعی از سیستم با جزییاتی كه برای برنامهنویسی كفایت كند ساخته میشود و سپس بر اساس آن برنامهنویسی انجام میگیرد. نكته این است كه تبدیل مدل به كد غالبا دستی انجام میشود. انتقال مدل از تیم طراحی به تیم برنامهنویسی عموما به صورت چاپ نمودار یا ارسال فایل انجام میشود. در صورتی كه خطایی در طراحی (مدلسازی) یا برنامهنویسی پیش بیاید، دور دیگری از رفت و برگشت آغاز میشود. در این روش، در صورتی كه قواعد معینی به كار بسته نشوند، مدلها به سرعت از اعتبار ساقط میشوند و همگامی با كد را از دست میدهند.
البته، با استفاده از ابزار، میتوان تبدیل مدل به كد را به صورت خودكار انجام داد و همگامی آنها را نیز تضمین نمود. معمولا این گونه ابزار كد اولیهای را میسازند كه برنامهنویس باید بعدتر آن را پالایش كند. كد پالایش شده میبایست با مدل اولیه مقابله و مغایرتهای آن رفع شود. به همین دلیل است كه این روش را «مهندسی رفت و برگشتی» مینامند. برای رسیدن به این هدف، میبایست بتوان بین كد خودكار ایجاد شده و كد برنامهنویسی شده تمایز قایل شد. یك روش استفاده از «نشانهگذاری» است. ابزاری مانند IBM Rational Rose چندین گونه تبدیل خودكار مدل به كد و برعكس را پوشش میدهد.
در یك روش مدلمحور (model-centric)، مدلها از چنان جزییاتی برخوردارند كه میتوان با استفاده از آنها كل سیستم را ساخت. این امر، مستلزم این است كه مدلها شامل جزییات كافی از دادههای پایا (persistent) و گذرا (transient)، منطق كسب و كار (business logic) و عناصر نمایشی باشند. اگر بنا باشد سیستم با سیستمهای موجود نیز مرتبط شود، نحوهی ارتباط نیز باید مدل گردد. فرآیند ایجاد كد میتواند از الگوهایی نیز تبعیت كند كه دست برنامهنویس را در نحوهی تبدیل مدل به كد، بسته به نیاز یا بستره، باز بگذارد. چنین روشی، عموما در بسترههای معینی كه سبك یا چارچوب برنامهنویسی خاصی را دنبال و از اجزای اجرایی مشخصی استفاده میكنند، محتملتر است. بنابراین، ابزار مناسب برای چنین روشی، معمولا توسط شركتی عرضه میشود كه ارایه كننده چارچوب یا بستره نیز میباشد.
در یك روش مدلمحور مدلها از چنان جزییاتی برخوردارند كه میتوان با استفاده از آنها كل سیستم را ساخت.
معماری مدلگرا : اتفاق آرای رو به رشد
مدلسازی بر مهندسی نرمافزار تاثیر عمدهای داشته است و برای موفقیت هر پروژهی تولید نرمافزار ابرسازمانی حیاتی است. با این وجود، در آن چه كه مدلها مینمایند و همچنین نحوهی استفاده آنها گوناگونیِ بسیاری به چشم میخورد. پرسش این است: «كدامیك از این رویكردها را میتوان مدلگرا نامید؟» آیا به تصویر كشیدنِ تنها بخشی از سیستم، به معنی «مدلگرا» بودن فرآیند است؟ متاسفانه، پاسخی قطعی وجود ندارد. با این حال، كمكم اتفاق آرا بر این قرار میگیرد كه معماری مدلگرا ارتباط نزدیكتری با رویكردی دارد كه در آن كد نرمافزار به صورت كاملا خودكار یا نیمهخودكار از مدلهای انتزاعیتر ایجاد میشود و از زبان مشخصات استانداردی برای توصیف مدلها استفاده میكند.
| < قبلی | بعدی > |
|---|