الگوی طراحی سیستم های توسعه پذیر

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

توزیع کننده بار (load balancer)

در این مدل، یک توزیع کننده وجود داره که بر اساس سیاست های متفاوت (میزان بار یا هر سیاست دیگه)، درخواست رو بین چند سرور خدمات دهنده تقسیم کنه. همونطور که توی پست قبلی گفته شد، برنامه کاربردی باید به صورت stateless باشه تا بتونه در صورت تغییر مسیر بتونه همچنان کار کنه. این الگو معمولا در تمامی وبسایت های بزرگ استفاده شده.

تقسیم و تجمیع دوباره (scatter and Gather)

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

کش کردن نتایج (result cache)

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

این الگو در کاربردهای بزرگ مورد استفاده قرار میگیرد. یک مثال از سرورهای کش، memcached است (بررسی کامل این محصول بعدا نوشته میشه، چون میخوام استفاده کنم ازش).

فضای اشتراکی

به این الگو "تخته سیاه" هم گفته میشه. در این مدل، تمامی سرورهای کاری (workers)، داده های خودشون رو در فضابی اشتراکی مینویسن. پاسخ نهایی در این سیستم ها به صورت افزایشی تکمیل میشه.

این الگو در JavaSpace و در محصول تجاری GigaSpace استفاده میشه.

مسیر داده و خط داده (Pipe and filter)

این الگو با عنوان "data flow programmin" هم شناخته میشه. تمامی گارگذاران به خطوط لوله داده ای متصل هستند که از طریق اونها داده ها منتقل میشه. این الگو یک الگوی طراحی در نرم افزار هست و برای طراحی سیستم نیز استفاده میشه.

map Reduce

این الگو برای شرایطی که مسیر I/O دیسک به عنوان یک bootleneck مطرح میشه قابل استفاده هست. در این الگو از یک فضای ذخیره سازی توزیع شده استفاده میشه. این الگو در بسیاری از کاربردهای گوگل استفاده میشه. یک پیاده سازی متن باز از این الگو، hadoop هست

Bulk Synchronous Parallel

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

1- هر کارگذار داده را از خط روردی دریافت میکند.

2- هر کارگذار پردازش دستور رودی را بر روی داده های محلی انجام میدهن

3- هر کارگذار نتایج محلی رو از طریق خط ارتباطی مستقیم به سرور میفرستد.

این الگو در سیستم پردازش گرافی گوگل استفاده میشه و همچنین سیستم متن باز hama برای این سیستم موجود هست.

پیچیدگی

«پیچیده (Complexy)» به معنی مطلبی است که فهمیدن آن دشوار است. دلیل این پیچیدگی، نبود یک روند سیستماتیک برای فهم آن است. با تعریف بیان شده باید در نظر داشت که پیچیدگی یک مفهوم ذهنی و نسبی است. بنابراین می‌توان نتیجه گرفت که یک سیستم نسبت به سیستم دیگر پیچیده تر است. برای فهم یک سیستم با توجه به پیچیدگی آن، از یک پزشکی استفاده می‌شود: «استفاده از مجموعه نشانه‌ها، برای تشخیص یک نتیجه پیچیده». در طراحی سیستم نیز باید از عوامل موجود برای تحلیل یک سیستم کلی استفاده کرد.

عوامل پیچیدگی را می‌توان موارد زیر عنوان کرد:

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

تعداد زیاد روابط بین مؤلفه ها: یک سیستم ممکن است تعداد مؤلفه های یک سیستم نسبت به سیستم دیگر زیاد نباشد، اما به علت زیاد بودن روابط بین آن‌ها، تحلیل و فهم آن مشکل‌تر باشد.

عدم قاعده‌مندی زیاد: یک سیستم با تعداد مؤلفه های زیاد و روابط گسترده، باز هم می‌تواند دارای پیچیدگی کمی باشد. اگر یک سیستم دارای مؤلفه های تکرار شده باشد که بر طبق قواعد تعریف نظاممند و ساده با همدیگر ارتباط داشته باشد، می‌توان از آن به عنوان یک سیستم با پیچیدگی مناسب استفاده کرد. نبود قاعده‌مندی با تعداد استثناعات موجود در سیستم یا با تعداد روابط بین غیر تکرار شده، باعث بیشتر شدن پیچیدگی در سیستم می‌شود.

توصیف طولانی: توصیف سیستماتیک توصیف کننده تمامی جنبه های یک سیستم است. یک توصیف از سیستم را در نظر بگیریم که بسیار گسترده و طولانی است. نظریه تئوری موجود برای این مبحث، پیچیدگی کولموگروف است. خود اینکه یک توصیف تا چه اندازه باید گسترده باشد و مفاهیم مؤلفه را تا چه حد از جزئیات باید بیان کد، یک توازن نسبی است. توصیف ریاضی برای بسیاری از مؤلفه های یک سیستم باعث پیچیده تر شدن فهم آن می‌شود، اما در سوی دیگر، توصیف ریاضی برای مؤلفه ها، می‌تواند اثباتی بر درستی کارکرد وظیفه ای آن‌ها باشد.

یک تیم از طراحان، پیاده سازها یا نگهداری کنندگان (maintainers): چندین نفر ممکن است برای فهم، ساخت یا نگه داری یک سیستم مورد نیاز باشند. یک سؤال اصلی در طراحی سیستم این است که آیا یک سیستم به اندازه کافی ساده است که توسط یک نفر شناخته و تحلیل شود؟ اگر به تعداد نفرات بیشتر از یکی نیاز باشد، آنگاه یک سیستم پیچیده است. اگر سیستم به چند نفر برای فهم، ساخت یا نگه داری نیاز داشته باشد، آنگاه علاوه بر کارهای تکنیکی مورد نیاز، به هماهنگ.سازی و ارتباطات بین اعضای تیم نیاز داریم که باعث پیچیدگی بیشتر آن خواهد شد.

یک مثال: تفاوت پیچیدگی یک کتابخانه کوچک شهری با کتابخانه یک دانشگاه بزرگ در چه حد است؟

مورد یک، تفاوت در اندازه، کتابخانه دانشگاه دارای کتاب‌های زیادتری می‌باشد.

مورد دوم، تعداد ارتباطات بیشتر: کتابخانه دانشگاه کتاب‌های بیشتر و همچنین اعضای بیشتری دارد، در نتیجه ارتباطات بین افراد و کتاب‌ها بیشتر خواهد شد.

مورد سود، تعداد استثنائات بیشتر: کتابخانه کوچک شهری، دارای تعداد موضوعات محدودی به را کتاب‌ها است، شاید 5 یا 6 مورد کلی، اما در کتابخانه دانشگاه، مباحث بسیار تخصصی خود نیازمند یک مجموعه بندی از کتاب‌ها باشند.

مورد چهارم، توصیف طولانی: هر کسی در یک کتابخانه بزرگ می‌داند که خود اینکه بتوانیم اطلاعات مورد نیاز خود را از بین اطلاعات گسترده پیدا کنیم نیازمند یک اطلاعات اضافی دیگری می‌باشد. بنابراین نیاز به اطلاعات بیشتری می‌باشد که توصیف کامل‌تری از کتاب را ارائه دهد.

مورد پنجم، نیاز به یک تیم: یک کتابخانه کوچک را می‌تواند یک نفر اداره کند، اما یک کتابخانه دانشگاهی بزرگ نیازمند تیمی از افراد برای اداره است.

یک مسئله مهم در تحلیل مسائل برای یافت پیچیدگی آن‌ها وجود دارد: «پیچیدگی یک سیستم، هر اندازه جزئیات بیشتری را دخالت دهیم، بیشتر خواهد شد» ممکن است یک سیستم (همان سیستم کتابخانه کوچک شهری «آنقدر جزئیات زیاد برای آن مطرح شود که خود یک سیستم پیچیده شود. چه میزان از جزئیات باید در طراحی سیستم در نظر گرفته شود؟»).

میزان در نظر گرفتن جزئیات با تکنیکی به نام تجرید (abstraction) محدود می‌شود «».

در مطلب بعدی به شناخت منابع پیچیدگی خواهیم پرداخت.

سیستم ها، اجزا، رابط ها و محیط

در مطلب قبلی یک تعریف کلی از سیستم ارائه کردیم که عبارت بود از:مجموعه ای پیچیده از اجزای جدا از همدیگر که در مسیر هدفی مشترک یا یک سرویس مشترک با یکدیگر ارتباط دارند. این تعریفی است که در وبستر برای سیستم مطرح شده است. در مهندسی یک تعریف نزدیک‌تر به دنیای واقعی نیاز دارند. بنابراین تعریف فوق به تعریف زیر تغییر میابد:

یک سیستم مجموعه ای است از مؤلفه های (components) متصل به همدیگر که یک رفتار مورد انتظار از طریق رابط‌ها با محیط (environment) دارند.

همیشه تعامل‌ها بین یک سیستم و محیط اطراف آن وجود دارد، که این تعاملات رابط بین سیستم و محیط است. برای مثال رابط در یک فضای بین سیاره‌ها، نیروی جاذبه القایی آن‌ها بین همدیگر و تاثیرات مغناطیسی آن‌ها به همدیگر است. رابط‌های پیش فرض در یک سیستم کامپیوتر شخصی، همان صفحه کلید، صفحه نمایش و امثالهم است. اینکه بتوان رفتار یک سیستم را پیش بینی کرد، وابسته است به شناخت اجزای تشکیل دهنده آن، روابط آن‌ها و رفتار هر کدام از تک اجزا. یافتن اجزا (اجزای تشکیل دهنده سیستم را تشخیص دهیم) نیازمند یک دیدگاه خاص است که به دو سؤال اصلی پاسخ دهد: هدف و ریز دانگی (granularity). نتیجه حاصل از هر کدام از این موارد در تعداد و نوع مؤلفه های تشکیل شده و در نتیجه در طراحی کل سیستم تأثیرگذار خواهد بود.

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

مثالی که ذکر شد، چه تأثیری در طراحی سیستم دارد؟ در همان سیستم هواپیما، یک مهندس طراحی خارجی از فضای درون به عنوان یک فضایی که ارتباط آن با طراحی تنها در حد میزان متر مکعب فضای مورد نیاز و حداکثر وزن است. برای یک مهندس طراح داخلی هواپیما، سیستم رانش، موتور، و بال‌ها و غیره، تنها ارتباطی در حد میزان صدای تولیدی و محل قرارگیری اجزای مختلف دارد (اینکه صندلی مسافران نزدیک بال‌ها چگونه قرار گیرد یا اینکه با موتورها چقدر فاصله داشته باشند).

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

به یک سیستم که در یک مورد خاص، به عنوان مؤلفه ای از سیستم دیگر استفاده می‌شود، زیر سیستم گفته می‌شود.

در مطلب بعدی به بحث پیچیدگی خواهیم پرداخت.