سادگی زیباست...

بررسی انواع معماری های سیستم عامل و برنامه های سیستمی و روشهای توسعه آنها

سادگی زیباست...

بررسی انواع معماری های سیستم عامل و برنامه های سیستمی و روشهای توسعه آنها

سادگی زیباست...

۸ مطلب با موضوع «طراحی سیستمی» ثبت شده است

البته اصلی این عنوان رو روزنامه (فکر کنم) واشنگتن پست برای انفجار آریان 5 استفاده شده بود.

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

در شب 25 ماه فوریه سال 1991، یه سیستم پاتریوت تو عربسات سعودی نتونست یه موشک اسکات رو ردیابی بکنه و موشک بعد از اصابت باعث کشته شدن 28 نظامی آمریکایی و زخمی شدن 98 نفر شد.

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

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

توی عملیات حفاظ صحرا، چند تا از این سکوهای پرتاپ پاتریوت توی نقاط حساس عربستان و اسرائیل کار کذاشته شده بود تا در مقابل موشک های اسکات عراق بتونه مقابله بکنه.

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

سیستم کنترلر مرکزی مجموعه کارهایی برای دنبال کردن اهداف و کنترل موشک ها انجام میده.

مشکل نرم افزاری

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

الگوریتم محاسبه مکان فرود موشک نیازمند سرعت موشک و زمان ها به صورت اعداد حقیقی هست. کامپیوتر سیستم پاتریوت به صورت رجیسترهای 24 بیتی بود. تو این سیستم زمان به صورت یک دهم ثانیه حساب میشه (deci=1/10). تو باینری 1/10 یه عدد اعشاری نامتناهی هست. برای حالت دابل عدد زیر میشه


0x3FB999999999999A = 00111111 10111001 10011001 10011001
10011001 10011001 10011001 10011010

این عدد بالا برای حالت دابل هست، برای 24 بیت تعداد این ارقام اعشار کمتر هم میشه. این میزان خطا با ادامه کار سیستم تو مدت زمان جمع شده و بیشتر میشه. این خطا تاثیر مستقیم تو نتیجه نهایی داره.

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

کشف مشکل

اولین بار نیروهای اسراءیلی مشکل رو پیدا کرن و گزارش دادن. بر اساس گزارش اونها سیستم پاتریوت بعد از 8 ساعت کار، تقریبا 20 درصد خطا تو محاسبه پیدا میکنه (که البته تدریجی اضافه میشه).

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

بروز مشکل

تو 25 فوریه 1991 سیستم پاتریوت موشک اسکاتی که عراق شلیک کرده بود رو ردیابی کرد اما محاسبه کرد که به خارج از نواحی حساس برخورد میکنه و به همین خاطر برای مقابله موشکی رو شلیک نکرد. اما موشک اسکات به داخل شهر ظهران برخورد کرد.

سایت اصلی تو زمان حادثه 100 ساعت بود که کار میکرد و میزان خطای زمانی محاسبه 0.34 ثانیه شده بود. این اختلاف زمانی باعث میشد تا محاسبه سرعت موشک با اشتباه 1.7 کیلومتر بر ثانیه انجام بشه. همین اشتباه محاسباتی باعث میشه نقطه برخورد هم اشتباه محاسبه بشه.


بعدا در مورد مشکلات مشابه و نتیجه که میخوام بگیرم بیشتر صحبت میکنیم

۰ موافقین ۱ مخالفین ۰ ۳۰ بهمن ۹۳ ، ۰۱:۰۳
حامد شیخلو

همواره در طراحی یک سیستم، سعی میشود که از الگوهای طراحی آزموده شده استفاده شود. در این الگوها برای حل مشکلات خاصی، راه حل مشخصی را ارائه میدهد که میتوان آن را استفاده کرد. با ترکیب این الگوها میتوان به قالب کلی سیستم دست یافت. مشابه مبحث طراحی شی گرایی، که در اون 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 برای این سیستم موجود هست.

۱ موافقین ۰ مخالفین ۰ ۰۷ شهریور ۹۳ ، ۱۹:۲۱
حامد شیخلو

یک پست خیلی خوب برای بررسی الگوهای طراحی سیستم‌های مقیاس‌پذیر (scalable system design pattern) جدیداً خوندم که خیلی از سؤالاتم رو در مورد طراحی این سیستم‌ها جواب داد. اما اونطور که خود نویسنده تو اول مقاله گفته، یه مقاله چند سال قبل اون نوشته و به طراحی سیستم‌های توسعه‌پذیر اشاره‌کرده و گفته که اول بهتره اون رو بخونین. من هم اول مقاله قدیمی رو براتون خلاصش رو مینویسم و بعدش هم مقاله جدید رو باید بررسی کنیم. البته مقاله جدیده خیلی خلاصه نوشته‌شده و باید خیلی گسترش پیدا بکنه.

مفاهیم اصلی

"توسعه‌پذیری" به معنای "قدرت پردازشی خالص" نیست

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

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

درک کامل از بارکاری و شرایط محیطی که سیستم برای آن طراحی می‌شود

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

نحوه اندازه‌گیری و هدف نهایی کارایی، مانند: میزان زمان پاسخ و همچنین میزان گذردهی سیستم

شناخت اینکه چه کسی مشتری نهایی شما خواهد بود.

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

توسعه عرضی به‌جای توسعه طولی

بهتر است به‌جای سرمایه‌گذاری و قویی‌تر کردن یک سیستم، از تعداد بیشتری سیستم سخت‌افزاری معمولی استفاده کنید، 

کد خود را به‌صورت ساده و ماژولار نگه‌دارید

قابلیت اینکه شما قسمتی از کد خود را بدون نگرانی از تغییر در کارایی در قسمت‌های دیگر تغییر دهید، شمارا قادر می‌سازد تا به‌صورت مؤثر نسبت به بهینه‌سازی قسمت‌های مختلف سیستم خود آزمایش‌ها متفاوتی انجام دهید.

هیچ‌وقت برای منظور خاصی ماژولار بودن کد خود را به خطر نیاندازید.

هیچ‌گاه نقطه bottleneck سرعت سیستم خود را حدس نزنید، آن را با آزمایش پیدا کنید

نقاط bottleneck نقاطی از سیستم هستند که کد آن‌ها سرعت کمی دارد و به تعداد زیاد هم اجرا می‌شود. هیچ‌گاه کدی که سرعت کمی دارد، اما به‌ندرت اجرا می‌شود را بهینه نکنید.

یک واحد برای اندازه‌گیری و تهیه آمار کارایی برای سیستم خود تهیه کنید و از روی آن برای بهینه‌سازی کد اقدام کنید.

نقشه‌ای برای توسعه داشته باشید

آمار استفاده از سیستم خود را همیشه داشته باشید و نرخ پیشرفت را سعی کنید حدس برنید.


روش‌های اصلی

راه‌اندازی server farm (سرعت دستیابی بلادرنگ)

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

خود کاربردی که در حال اجرا بر روی چند سیستم است، باید به‌صورت stateless باشد تا بتواند به‌صورت کامل به سرورهای دیگر در هرلحظه منتقل شود.

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

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

این استراتژی درصورتی‌که از پردازش ابری استفاده کنیم بسیار مؤثرتر خواهد بود و می‌توان با افزایش تعداد ماشین‌های مجازی کارایی سیستم را افزایش داد.

قسمت‌بندی داده‌ها

داده‌های خود را بین چندین پایگاه داده پخش‌کنید و بنابراین هزینه دستیابی به داده‌ها بین چندین سرور پخش خواهد شد.

اصالتاً داده یک عنصر دارای وضعیت است. بنابراین پخش داده‌ها بین چندین سرور باید به صورتی باشد که وضعیت داده‌های نگه‌داری شده در آن سرور در نظر گرفته شود.

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

استفاده از مدل پردازشی همزمان دسته‌ای map/reduce

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

روش map/reduce که از طرف شرکت گوگل ارائه‌شده است، یک روش بسیار خوب برای انجام پردازش موازی است. فریم وورک متن‌باز Hadoop برای java می‌توان به‌عنوان یک راه حل نیز استفاده شود.

استفاده از شبکه تحویل محتوا CDN (حافظه میانی ایستا)

استفاده از این فنّاوری برای محتوای ایستا بسیار متداول است. ایده اصلی قرار دادن چندین کپی از یک داده ایستا در نقاط جغرافیایی مختلف است.

درخواست‌های کاربران به نزدیک‌ترین نقطه که داری داده درخواستی باشد انتقال پیدا می‌کند.

استفاده از cache engine (محتوای پویا)

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

این ویژگی معمولاً با استفاده از lookup cache پیاده‌سازی می‌شود.

اکثراً از memcached و EHCached برای این منظور استفاده می‌شود.

استفاده از resource pool

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

محاسبه نتایج به‌صورت تقریبی

به‌جای محاسبه نتایج دقیق برای یک درخواست، در صورت امکان یک نتیجه تقریبی را با سرعت بالاتر ارائه دهید.

در جهان حقیقی، میزانی از عدم دقت قابل‌پذیرش است.

فیلتر کردن در منبع

سعی کنید بیشتر پردازش را در محلی که داده تولید و ارسال می‌شود انجام دهید، با استفاده از این روش، می‌توان تا حدی داده انتقالی را کاهش داد.

پردازش ناهمگام (asynchronous)

شما درخواست انجام پردازشی را ارسال می‌کنید، اما نتایج این پردازش تا چند مرحله بعد موردنیاز است و می‌توانید تا آن زمان بدون نیاز به این نتایج کار خود را ادامه دهید. بنابراین نیاز به منتظر ماندن تا آماده شدن نتایج نیست.

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

فراخوانی سرویس در این مثال، بهتر است که از طریق پردازش‌های غیر همگام انجام شود. این نوع پردازش معمولاً در دو مرحله انجام می‌شود: callback و polling

 

۰ موافقین ۰ مخالفین ۰ ۰۵ شهریور ۹۳ ، ۱۲:۳۸
حامد شیخلو

توسعه یک سیستم در نهایت چه تاثیری بر جنبه های متفاوت آن خواهد داشت؟ تعداد سرورها مشخصا با تعداد کاربران بیشتر خواهد شد، این یک مساله مشخص است. یکی مثال بسیار  خوب در این زمینه سیستم whatsApp هست. در ادامه یک مساله جالب در توسعه این سیستم را بررسی میکنیم.

Obviously much bigger in every dimension, except the number of engineers. More boxes, more datacenters, more memory, more users, and more scale problems. Handling this level of growth with so few engineers is what Rick is most proud of: 40 million users per engineer. This is part of the win of the cloud. Their engineers work on their software. The network, hardware, and datacenter is handled by someone else.

یک آماری هم از وضعیت این سرویس

  • 465 میلیون کاربر به صورت ماهانه
  • 19 میلیارد پیغام ورودی/40 میلیارد پیغام خروجی به صورت روزانه
  • تعداد 147 میلیون اتصال همزمان

اما سوال اصلی: چطور توسعه سیستم به اندازه چندین برابر اما بدون تغییر در تعداد مهندسان؟

اما جواب: واقعا مهندس هستن( جواب اصلی )

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

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

۰ موافقین ۰ مخالفین ۰ ۲۱ تیر ۹۳ ، ۲۳:۱۰
حامد شیخلو
این عنوان یک سخنرانی در سال 1996 در کنفرانس تکنیکال سالانه usenix هستش که توسط آقای John Osterhout از شرکت SUN ارائه شد.
شاید بشه این کنفرانس رو در همین یک عکس خلاصه کرد:
همگام سازی بین نخ های پردازشی بسیار سخت هستش، و بیشتر زمانها خودش یک مشکل اساسی میشه. اما توسعه دهندگان در مدت چاپ این مقاله تا زمان حاضر، بسیاری از این مشکلات رو حل کردن و کار کردن با نخ ها (ساختن و محول کردن کار) بسیار راحت تر شده. اما اگر دیدمون رو شبیه به نویسنده این مقاله بکنیم، میبینیم که وضعیت زیاد هم خوب نشده.
در کارهای سنگین، شما یاسد حساب کلاک ساعت ها رو بکنین، مثلا اینکه یک برنامه محاسباتی سنگین رو با یک زبان سطح پایین با حداکثر بهینه سازی بنویسین تا کمترین کلاک ساعت از بین بره. یا مثلا، تعداد فراخوانی سیستم رو پایین بیارین تا سربار context switch حداقل بشه. ترند تکنولوژی هم به این سمت بوده، اما با انجام بررسی ها مشخص میشه که هنوز یک برنامه نویس خوب، خیلی خیلی بهتر از یه نرم افزار میتونه بهینه سازی انجام بده (البته منظورم کارایی مثل باز کردن حلقه و این جور چیزا که کامپایلرها انجام میدن نستش).
یک برنامه نوبس سیستمی، هیچ وقت کاری که نمیدونه چطوری انجام میشه رو قبول نمیکنه
۱ موافقین ۰ مخالفین ۰ ۱۵ فروردين ۹۳ ، ۲۰:۳۵
حامد شیخلو
«پیچیده (Complexy)» به معنی مطلبی است که فهمیدن آن دشوار است. دلیل این پیچیدگی، نبود یک روند سیستماتیک برای فهم آن است. با تعریف بیان شده باید در نظر داشت که پیچیدگی یک مفهوم ذهنی و نسبی است. بنابراین می‌توان نتیجه گرفت که یک سیستم نسبت به سیستم دیگر پیچیده تر است. برای فهم یک سیستم با توجه به پیچیدگی آن، از یک پزشکی استفاده می‌شود: «استفاده از مجموعه نشانه‌ها، برای تشخیص یک نتیجه پیچیده». در طراحی سیستم نیز باید از عوامل موجود برای تحلیل یک سیستم کلی استفاده کرد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

در مطلب بعدی به شناخت منابع پیچیدگی خواهیم پرداخت.
۰ موافقین ۰ مخالفین ۰ ۰۸ مرداد ۹۲ ، ۱۷:۵۷
حامد شیخلو
در مطلب قبلی یک تعریف کلی از سیستم ارائه کردیم که عبارت بود از:مجموعه ای پیچیده از اجزای جدا از همدیگر که در مسیر هدفی مشترک یا یک سرویس مشترک با یکدیگر ارتباط دارند. این تعریفی است که در وبستر برای سیستم مطرح شده است. در مهندسی یک تعریف نزدیک‌تر به دنیای واقعی نیاز دارند. بنابراین تعریف فوق به تعریف زیر تغییر میابد:

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

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

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

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

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

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

در مطلب بعدی به بحث پیچیدگی خواهیم پرداخت.
۰ موافقین ۰ مخالفین ۰ ۰۸ مرداد ۹۲ ، ۱۴:۵۰
حامد شیخلو
مسائل و مشکلاتی که در یک طراحی سیستم ممکن است بوجود آید را می‌توان در چهار فیلد اصلی تقسیم بندی کرد:

  •     ویژگی‌های اورژانسی (emergent properties).
  •     پخش شدن تأثیر‌ها (propagation of effects).
  •     گسترش غیر متناسب (incommensurate scaling).
  •     توازن (trade-offs).

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

  • ویژگی های اورژانسی
این ویژگی‌ها شامل ویژگی‌هایی می‌باشند که در تحلیل اولیه اجزای سیستم به صورت تک به تک خودشان را نشان نداده‌اند و بعداً هنگامی که در صدد اتصال اجرا به همدیگر هستیم، خودشان را نشان می‌دهند. می‌توان این اجزا را به عنوان سورپرایز در نظر گرفت. این ویژگی‌ها معمولاً در سیستم‌ها در نظر گرفته نمی‌شوند، هرچند روش‌هایی در طراحی برای پیش‌بینی این موارد وجود دارد. «بعضی موارد تنها زمانی خود را نشان می‌دهند که یک سیستم ساخته شد».
یک مثال جالب: مهندسان پل هزاره که بر روی رودخانه توماس در انگلیس تنها چند روز بعد از افتتاح پل، آن را بستند تا تغییراتی بر روی آن انجام دهند. دلیلی آن یک موضوع جالب بود، مردمی که از روی پل عبور می‌کردند، قدم‌های خود را با نوسانات پل تنظیم می‌کردند، در نتیجه نوسانات بیشتر می‌شد و ممکن بود آسیب جدی به ساختار آن وارد کند.
یک مثال دیگر: وجود چندین تولید کننده برق و اتصال آنها به همدیگر، باعث پخش شدن بار بر روی تولید کنندگان مختلف است. مشکل زمانی به وجود میابد که یکی از تولید کنندگان از مدار خارج شود که ممکن است به دلیل اضافه بار بر روی تولید کنندگان دیگر، تمامی شبکه دچار مشکل شود.
به قول استاد خوبم، جبان آقای دکتر محمدی:"تجزیه شون خوبه، اما مرده شور ترکیب شون رو ببره"
  • پخش شدن تاثیرات
در همان مثال مربوط به شبکه برق، یک سقوط درخت در یک منطقه و قطع شدن سیم‌های برق، ممکن است چندین کیلومتر دورتر باعث قطعی برق هزاران نفر شود. یک مسئله که در ابتدا کوچک به نظر می‌رسد و تأثیرات آن محلی تصور می‌شود، می‌تواند باعث تأثیر بر روی اجزای بسیار دورتر سیستم شود. یک نیازمندی اصلی در طراحی سیستم، محدود کردن تاثیرات خطا در سیستم است.
یک مثال دیگر که شاید برای درک تاثیر تغییرات خوب باشد، در طراحی خودرو است. فرض کنید یک مهندس طراح خودرو برای افزایش سرعت، قطر چرخ ها را از 13 به 15 افزایش دهد، در این افزایش، تاثیراتی که باید در سیستم فرمان گیری، ترمز و حتی ظاهر خودرو به وجود میاید را باید در نظر داشت.
  • گسترش غیر متناسب
زمانی که یک سیستم برای هدف خاصی در ابعاد گسترش پیدا می‌کند، تمامی اجزا از این قوانین افزایش بعد پیروی نمی‌کنند. برای مثال، در ساخت ساختمان‌هایی با طبقات زیاد، تعداد طبقات، وابسته است به میزان ظرفیت دسترسی به طبقات بالایی از طریق طبقات پایین‌تر. برای مثال میزان فضای لازم برای آسانسورها که در طبقات پایین‌تر مورد نیاز است.
این مسئله در طراحی سیستم معمولاً خود را نشان می‌دهد و اندازه و سرعت قابل مدیریت برای سیستم واحد را محدود می‌کند.
  • توازن

بسیاری از محدودیت‌ها خود را به صورت یک توازن بین اجزا یا عوامل موثر نشان می‌دهند. یک مدل عام از این توازن عبارت است از اینکه یک عامل خوب در فضای مسئله است و چالش‌های مسئله عبارت است از حداکثر سازی این عوامل خوب و در مرحله دوم جلوگیری از هدر رفتن آن‌ها و در مرحله سوم، تخصیص این عوامل به محل‌هایی که بیشترین سود را داشته باشد. این مفهوم تا حدی در این تعریف مشکل است. این مفهوم را معمولاً با عنوان «اثر تخت خواب آبی (waterbed effect)» مطرح می‌شود. اگر یک مسئله را در محلی فشار دهیم، ممکن است در محل دیگر یک مسئله دیگر به وجود آید یا خود را نشان دهد.
مثال بارز این مسئله در طراحی مدارات سخت افزار و توازن برقرار کردن بین سرعت پردازش، انرژی مصرفی و حرارت تولیدی است.

سؤال مهم این است که با وجود این مسائل و مشکلات، چگونه یک سیستم کامپیوتری را طراحی کنیم. در بهترین حالت، می‌خواهیم یک روش کامل طراحی داشته باشیم که بتوان در آن به صورت کامل همه اجزا را تحلیل کرد و نتیجه نهایی را به بهترین شکل بر اساس تجربیات گذشته بدست آورد. اما متأسفانه در بحث تحلیل و طراحی سیستم کامپیوتری نسبت به علوم مهندسی دیگر بسیار جوان تر هستیم.
۰ موافقین ۰ مخالفین ۰ ۰۴ مرداد ۹۲ ، ۲۰:۳۱
حامد شیخلو