applying design patterns

اگرچه شناخت الگوها برای یک مهندس نرم افزار امری ضروری است (تا جایی که برخی از بزرگان این اعتقاد دارند شناخت الگوها مرز بین مهندس نرم افزار و برنامه نویس است)، آگاهی از چگونگی به کارگیری آنها در تولید نرم افزار، امری مهم تر و چالش برانگیز تر است. به طور کلی دو رویکرد برای به کارگیری الگوها در تولید نرم افزار وجود دارد :

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

نباید اجازه داده شود که بار منفی موجود در واژه بی نظم بر روش اول سایه بیاندازد. منظور از بی نظمی در این جا، نبود یک فرایند برای به کارگیری الگوها در تولید نرم افزار است. برای پیاده سازی رویکرد نظام مند دو راهکار کلی وجود دارد. راهکار اول استفاده از زبان الگو [1] است. زبان الگو به دنبال معرفی یک مجموعه از الگوهای مرتبط باهم و ارتباطات بین آن‌ها، جهت حل مشکلات موجود در یک دامنه خاص است. این راهکار مصداق مثل "چیزی به عنوان غذای مجانی وجود ندارد" [2] است. چرا که زبان الگو، فرایند ضمنی موجود در خود را مرهون محدود کردن دامنه الگوهای آن به یک حوزه خاص است. برای شناخت دقیق زبان الگو مطالعه کتاب [3] توصیه می شود. راهکار دوم استفاده از یک فرایند به جهت استفاده نظام مند از الگوها در تولید نرم افزار است. متدولوژی های مطرح شده در این حوزه با دو چالش اساسی روبه رو هستند. چالش اول اینکه نمایشی برای الگوها که مورد پذیرش جامعه مهندسین نرم افزار باشد وجود ندارد. چالش دوم که نشات گرفته از چالش اول است، نیاز به روشی جهت ترکیب الگوهاست.

برای ترکیب الگوها دو رویکرد اصلی وجود دارد :

• رویکرد ساختاری : در این رویکرد طراحی نرم‌ افزار از اتصال نمودار کلاس [4] الگوها ایجاد می ‌شود.
• رویکرد رفتاری : در این رویکرد از مدل نقش [5] معرفی شده در متدولوژی OORAM [6] جهت ترکیب الگوها استفاده می شود.

رویکرد ساختاری علاقه مند به ترکیب الگوها در سطح پایین تری از انتزاع [7] است. دو نمونه بارز این رویکرد، روش POT [8] و روش POAD [9] است. در روش POT که در سال 1997 معرفی شد، ابتدا مدل شی رسم می شود و سپس بر اساس تعاملات بین اشیاء، مدل رسم شده به گروه هایی تقسیم می شود و در نهایت در این گروه ها الگوهای طراحی شناسایی می شوند. روش POAD که در سال 2003 در معرفی شد شامل سه مرحله است. در مرحله تحلیل الگوهای قابل کاربرد بر اساس دامنه مساله شناسایی می شوند. سپس در مرحله طراحی این الگوها با استفاده از واسط ترکیب می شوند و در مرحله دقیق سازی طراحی الگوهای ترکیب شده نمونه سازی می شوند. روش POT دید پایین به بالا دارد و در طرف مقابل روش POAD از دید بالا به پایین استفاده می کند. برای جزییات بیشتر در مورد این دو روش مطالعه [10] و [11] توصیه می شود.

رویکرد رفتاری علاقه مند به ترکیب الگوها در سطح بالاتری از انتزاع است. دو نمونه بازر این رویکرد، روش مطرح شده در متدولوژی OORAM و روش مطرح شده توسطDirk Rielhe  است. در متدولوژی OORAM از مدل نقش به عنوان سطح بالاتری از انتزاع نسبت به مدل شی استفاده می شود.  درحالی‌که یک کلاس به‌عنوان یک قالب برای ایجاد اشیا نمود پیدا می‌کند، نقش به مسئولیت این اشیا تأکید دارد. این متدولوژی در دو مرحله انجام می شود. ابتدا مدل های نقش ایجاد و در مرحله بعد این مدل ها با یکدیگر ترکیب می شوند. برای جزییات بیشتر مطالعه کتاب [12] پیشنهاد می شود. Dirk Rielhe با الهام از متدولوژی OORAM، روشی مبتنی بر مدل نقش برای ترکیب الگوها ارایه می دهد. در این روش ابتدا الگوهای موجود بر اساس مدل نقش، مدل می شوند. سپس یک مدل شیء از دامنه مساله ترسیم می شود (Rielhe این مدل را مدل نمونه سازی اولیه می نامد). در مرحله بعد با تحلیل مدل نمونه‌سازی اولیه،الگوهای قابل کاربرد شناسایی و نقش‌های موجود در این الگوها به اشیا موجود در مدل نمونه‌سازی اولیه اختصاص داده می‌شود. درنهایت با بررسی روابط بین نقش ها، ترکیب بین الگوها شکل می گیرد. برای جزییات بیشتر این روش، مطالعه مقاله [13] پیشنهاد می گردد. دو ایراد اساسی به مدل نقش وارد است. اول اینکه زبان UML از این مدل پشتیبانی نمی کند. دوم اینکه این مدل قابلیت نمایش ساختار سلسله مراتبی (که عصاره بسیاری از الگوهاست) را ندارد.

---

[1] - Pattern language

[2] - There is no such thing as a free lunch

[3] - Pattern Oriented Software Architecture Volume 5 : On Patterns And Pattern Languages

[4] - Class diagram

[5] - Role model

[6] - Object oriented role analysis method

[7] - Abstraction

[8] - Pattern Oriented Technique

[9] - Pattern Oriented Analysis And Design

[10] - A pattern oriented technique for software design

[11] - Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems

[12] - Working With Objects:The Ooram Software Engineering Method

[13] - Composite design patterns

software design patterns

الگوها برای اولین بار توسط Christopher Alexander معرفی شدند. او که استاد بازنشته دانشگاه کالیفرنیا در رشته معماری است، در سال 1977 کتاب خود با عنوان [1] مفهوم زبان الگو را اینگونه معرفی می کند : "فرآیند ساخت همه بنا های زیبا یکسان است. برای آشکار کردن آن می بایست دو کار انجام داد. ابتدا باید هر سازه را به کوچکترین جزء سازنده آن تجزیه کرد و سپس فرایندی برای کنار هم گذاشتن این اجزا تعریف کرد." او این اجزاء را الگو و فرایند کنار هم قرار دادن آنها را زبان الگو می نامد. (تاثیر این دیدگاه را به وضوح در کتاب [2] مشاهده کرد.) در نگاه Alexander الگوها منشا زیبایی هستند و زیبایی را نه با ابداع بلکه با ترکیب الگوها به وسیله یک زبان الگو ایجاد کرد که حاصل این ترکیب پدیده ای است که Alexander آن را "کیفیت بدون نام" [3] می نامد. Kent Beck در سال 1987 در مقاله ای به منظور مطرح کردن استفاده از ایده Alexander در نرم افزار، پنج الگو را در زبان Smalltalk پیاده سازی کرد. Eric Gamma در رساله دکترای خود در سال 1991 به کاربرد الگوها در طراحی نرم افزار اشاره کرد. اما نقطه عطف استفاده از الگوها در نرم افزار بدون تردید چاپ کتاب [4] است.

در مهندسی نرم افزار تعاریف مختلفی برای الگوها وجود دارد :

•      Eric Gamma : پاسخی برای یک مشکل تکرار شونده در یک حوزه خاص است.
•      Dirk Riehle : انتزاعی از یک شکل محسوس که در یک زمینه خاص به صورت مکرر اتفاق می افتد.
•      Brad Appleton : قطعه ای از دانش که ماهیت یک خانواده از پاسخ ها به مشکلات تکرار شونده در یک دامنه خاص را در بر می گیرد.

با نگاه مجرد به این تعاریف، می توان یک تعریف ساده و فراگیر برای الگوها ارایه کرد. در این تعریف هر الگو از سه قسمت تشکیل شده است، وضعیت بد [5]، وضعیت خوب [6] و مجموعه ای از الزامات [7]. در واقع الگوها راهکاری برای تبدیل وضعیت بد به وضعیت خوب، تحت الزماتی مشخص است. الگوها در سطوح مختلفی از نظر ریزدانگی [8] وجود دارند.

•      الگوهای فرایند
•      الگوهای مهندسی مجدد
•      الگوهای معماری
•      الگوهای طراحی
•      الگوهای پیاده سازی

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

اما یک سوال مهم. اصولا فایده استفاده از الگوها در مهندسی نرم افزار چیست؟ در مرحله طراحی نرم افزار تصمیمات مهمی راجع به نرم افزار اتخاذ می شود که کیفیت نرم افزار نهایی به شدت به صحت و سقم این تصمیمات وابسته است.  با توجه به اینکه این تصمیم ها در سطح کلان مطرح می شوند، بالطبع اتخاذ تصمیم ها نادرست، هزینه های سنگینی به دنبال خواهد داشت. چرا که نتیجه این تصمیمات زمانی مشخص می شود که نرم افزار تولید شده است. برای اطمینان از صحت تصمیمات اتخاذ شده دو راه کار وجود دارد :

•  آزمودن تصمیم های مطرح شده :  با استفاده از رویکرد تکراری افزایشی [9] و نمونه سازی اولیه [10].
•   اتخاذ تصمیم های آزموده شده : استفاده مجدد [11] روش دیگر جهت رسیدن به این هدف است.

رویکرد اول در واقع همان رویکرد متدولوژی های چابک [12] است که صحبت در مورد آن موضوع کتاب ها مختلف است. اما در مورد رویکرد دوم باید گفت، استفاده مجدد در سطح پایین انتزاع (استفاده از مولفه [13]) مشکلاتی به دنبال خواهد داشت. از طرفی یافتن مولفه ای که تمامی نیازها را برآورده کند به ندرت عملی می شود و از طرف دیگر تغییر دادن مولفه در صورت امکان هم، خطراتی برای جامعیت مولفه به دنبال خواهد داشت. در واقع استفاده از الگوها، استفاده مجدد در سطح طراحی (سطحی مجرد تر از پیاده سازی) را فراهم می کنند. نکته ای که نباید از آن غافل شد اصالت الگوهاست (راه حل جدید الگو نیست) چرا که همانطور که اشاره شد، الگوها راه حل های شناخته شده هستند.

---

[1] - The Timeless Way of Building

[2] - Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages

[3] - Quality without a name

[4] - Design Patterns Elements Of Reusable Software Development

[5] - Bad smell

[6] - Good smell

[7] - Force

[8] - Granularity

[9] - Iterative-incremental

[10] - Prototyping 

[11] - Reuse

[12] - Agile

[13] - Module