درود بسیار بر یکایک دوستان
توی این مقاله دست و پا زدم تا مفهوم سیستم رو با یه زبون ساده بیان کنم.
سیستم
برای فراگیری مهندسی نرمافزار لازم است با مفاهیمی که شالوده کار ما را میسازند آشنا شویم. یکی از این مفاهیم «سیستم» و دیگری «مدل» است. فراگیری UML و RUP و … تا زمانی که به این مفاهیم مسلط نباشم ما را یاری نمیکند. کسی که درک مبهمی از سیستم و مدل دارد نمیتواند آنگونه که سزاوار است از زبان مدلسازی UML استفاده کند یا فرایندهای نرمافزاری را بکار ببندد. از سوی دیگر سر و کله زدن با اینگونه نکات «فلسفی» در کار نرمافزار، دهن ما را هوشیارتر میکند و باعث میشود تا کار خود را هوشمندانه انجام دهیم.
سیستم دقیقا چست؟ خوشبختانه پاسخش بسیار ساده است: سیستم(System) مجوعه ای از اجزاء (Components) است که با هم در ارتباطند (Relation) و هدف مشخصی را دنبال میکنند (Objective). هر ترکیبی از چیزها (یا همان موجودیت ها – Entities) که برای رسیدن به یک هدف همکاری (Colaboration) کنند، یک سیستم میسازند. این اجزاء میتوانند هر چیزی باشند. از انسانها گرفته تا قطعاتی چون پیچ و مهره. هدف سیستم میتواند از اجرای یک نمایشنامه تا تولید نیروی محرکه در اتوموبیل تغییر کند. سیستم میتواند فیزیکی (اجزای قابل لمس) یا منطقی (اجزای منطقی) یا ترکیبی از هر دو باشد.برخی سیستم ها ساده (Simple) و برخی نیز پیچیده (Complex) هستند. برخی کوچک (Small) (اجزاء اندک) و برخی بزرگ (Large) (اجزاء بسیار) هستند. سیستم ساده سیستمی است که درک آن ساده و ارتباط اجزایش زیاد پیچیده نباشد. سیستمهای ساده معولا کوچک اند و اهداف ساده ای را دنبال میکنند. نقطه مقابل آنها سیستمهای یچیده هستند که چندین هدف را دنبال میکنند و اغلب اجزای بسیار با روابط دشوار دارند.
زیر سیستم
گاهی جزئی از سیستم خودش از اجزایی کوچک تر ساخته شده که از دید سیستم بزرگتر کار واحدی را انجام میدهند. برخی اوقات هم سادهتر (و درست تر) است که یک زیر مجموعه از اجزاء را از بقیه سیستم جدا کنیم و به آنها به چشم یک سیستم کوچکتر در دل سستم بزرگتر نگاه کنیم. یک چنین زیر مجوعهای از سیستم را یک «زیرسیستم» (Sub-system) میگویند. یک زیر سیستم خودش یک سیستم کامل است ومیتواند مستقل از سیستم بزرگتر بررسی شود. از دید سیستم بزرگتر، زیر سیستم یک جزء است که کار خاصی را در ارتباط با بقیه سیستم انجام میدهد. برای نمونه اگر خودرو را یک سیستم در نظر بگیریم، موتور یک جزء آن است که نیروی محرکه تولید میکند و در ارتباط با اجزای دیگر همچون دلکو، کویل، میللنگ، بدنه و … هدفی واحد را دنبال میکند و آن حرکت دادن کل خودرو است. از سوی دیگر موتور قطعهای بسیار پیچیده است و میتواند مستقل از خودرو بررسی شود بنابراین موتور (نسیبت به خودرو) یک زیرسیستم هم هست زیرا تمام ویژگیهای یک سیستم را دارد و خودش جزئی از یک سیستم بزرگتر است. در واقع اتوموبیل را میتوان از دیدگاههای گوناگون به تعداد بسیاری زیرسیتم تجزیه کرد. آیا موتور و صندلی راننده با هم یک زیر سیستم میسازند؟ به نظر نمیاد که ارتباطی با هم داشته باشند یا از ترکیب آنها هدف خاصی که در خدمت سیستم بزرگتر باشد (یا کار ما را در بررسی سیستم سادهتر کند) حاصل شود، بنابراین آنها تنها یک مجموعه میسازند نه یک زیرسیستم. برخی اوقات تعدادی از اجزاء بقدری به همپیوسته و تنگاتنگ کار میکنند که به طور طبیعی آنها را زیرسیستم در نظر میگیریم؛ همچون سیستم گردش خون در بدن انسان یا سیستم انتقال قدرت در اتوموبیل. چنین زیر سیستمهایی هدفی آشکار را دنبال میکنند و ارتباط اجزای آنها با هم چنان است که اگر کل مجموعه را یک واحد منطقی (زیر سیستم) در نظر بگیریم، کار درستی کردهایم. دلایل بسیار دیگری هست که زیرمجموعهای خاص از اجزاء یک سیستم را یک زیرسیستم در نظر بگیریم. یک جزء میتواند همزمان در چندین زیرسیستم باشد و یا اینکه در هیچکدام نباشد؛ بستگی به این دارد که آیا این تقسیمبندی به ما کمکی میکند یا خیر.
سیستمهای نرمافزاری
آیا متوان نرمافزار را سیستم دانست؟ بیایید آنرا بررسی کنیم! یک نرمافزار هر چقدر هم که ساده باشد (در حد یک برنامه Hello World) هنوز از اجزاء سادهتری ساخته شده (تابع هاُ، بلوکهاُ و …). این اجزاء با هم ارتباط ویژهای دارند (منطق برنامه) که در مجموع کاری را انجام میدهند (خروجی). در واقع نرمافزار چیزی نیست جز ترکیبی منطقی از اجزای نرمافزاری کوچکتر؛ بنابراین نرمافزار حقیقتا یک سیستم است. برخی محصولات نرمافزاری سیستمهای بسیار پیچیدهای هستند که خود از چندین زیر سیستم دیگر (که خودشان پیچیدگی بسیار دارند) ساخته شدهاند. برای نمونه نرمافزار اتوکد محصول شرکت اتودسک یا سیستم عامل ویندوز محصول مایکروسافت را در نظر بگیرید. یک بررسی ساده نشان میدهد که هر یک از این محصولات براستی یک سیستم پیچیده است. یک چنین سیستمی را که اجزایش نرمافزاری هستند یک «سیستم نرمافزاری» (Software System) میخوانند. سیستم نرمافزاری همه ویژگیهای سیستم های دیگر را دارد با این تفاوت که اجزایش نرمافزاری هستند و جسم فیزیکی ندارند؛ به همین خاطر نرمافزار در واقع یک سیستم «منطقی» است. در مقابل آن سیستمهای سختافزاری هستند که اجزایش فیزیکی هستند و یک سیستم «الکترونیکی – مکانیکی» را میسازند. آنگاه که یک سیستم نرمافزاری یک سیستم سختافزاری را تحت کنترل دارد، مجموعه آنها را «سیستم کامپیوتری» مینامند. شناخت و درک ماهیت سیستمی نرمافزار و زیر سیستمهای سازنده آنها و منطق ارتباط آنها با یکدیگر بخش اساسی و جدانشدنی مهندسی نرمافزار است. در حقیقت مهندسی نرمافزار با مهندسی سیستم آغاز میشود و هدف از آن بررسی نرمافزار از دید سیستمی است.
برای اینکه مقاله کامل شده باشد، برخی مفاهیم و مهارتهای سیستمی را در ارتباط با نرمافزار مرور میکنیم:
تحلیل سیستم (System analysis) یا همان تحلیل (Analysis): هدف از تحلیل نرمافزار (سیستم) شناخت و درک سیستم و اجزای آن و روابط بین آنهاست. «تحلیل گر سیستم» (System Analyst) میکوشد تا سیستم را بشناسد؛ به معنی که اهدافش را درک کند و مشخصاتش را تشخیص دهد، زیر سیستمهای مهم را بیابد و دید درستی از منطق سیستم (ارتباط اجزا و زیر سیستمها با یکدیگر) بدست بیاورد. برای این منظور او برخی اوقات سیستم را میشکند و اجزایش را میشکافد (تجزیه و تحلیل – Analysis) وبرخی اوقات اجزا را ترکیب میکند و زیر سیستم میسازد (ترکیب – Synthesis). هر کاری که به شناخت بهتر سیستم بیانجامد به نوعی تحلیل شمرده میشود. واژگانی همچون «تحلیلگر سیستم»، «تحلیلگر نرمافزار» و «تحلیلگر» همه همان معنی را دارند. برخی اوقات اصولا هنوز سیستمی ساخته نشده است که بخواهد تحلیل شود و در واقع هدف این است که سیستمی نو ساخته شود. در این صورت کار تحلیل گر بسیار مهم و تا اندازهای متفاوت است. او باید سیستم آینده را بشناسد و در حقیقت او خواهد گفت که این سیستم چه خواهد بود. نتیجه کار تحلیل، مشخصات و ویژگیهای سیستمی است که باید ساخته شود (System Specifications) . اهداف سیستم و محدودیتهای آن به همراه قالب ورودی و خروجی سیستم ار بخشهای مهم مشخصات سیستم هستند. تحلیلگر به جزپیات کار طراحی و ساخت سیستم کاری ندارد. او میگوید که «چه چیزی» قرار است ساخته و این «چه» همان «مشخصات سیستم» است.
طراحی سیستم (System Design) یا همان طراحی (Design): طراح سیستم (System Designer) میکوشد تا سیستمی را طراحی کند که «مشخصات» خواسته شده را داشته باشد. طراح باید درک درستی از اهداف و ویژگیهای سیستم داشته باشد تا بتواند کار خود را آغاز کند بنابراین تحلیل پیش از طراحی آغاز میشود. طراح میگوید که سیستم چه اجزایی داشته باشد و این اجزا چگونه با هم کار کنند (منطق سیستم) تا سیستم بتواند به هدف خود برسد. طراح زیر سیستمهای لازم برای برپایی سیستم را شناسایی کرده و انها را به هم متصل میکند و به این ترتیب نقشه سیستم نهایی را میسازد. نتیجه فرایند طراحی، نقشه سیستمی است که قرار است ساخته شود؛ این نقشه را «طرح سیستم» میگویند. توجه کنید که طراح، سیستم را نمیسازد بلکه نقشه سیستم را میکشد. افرادی دیگر با در دست داشتن این نقشه، شروع به ساخت سیستم میکنند. طراح میگوید که «چطور» سیستم را بسازیم تا مشخصات خواسته شده را دارا باشد. این «چطور» همان نقشه یا طرح سیستم است.
تحلیل کافی و طراحی درست نکات کلیدی موفقیت سیستمی هستند که قرار است ساخته شود. اگر سیستم به اندازه کافی تحلیل نشود، ممکن است جنبههای مهمی از سیستم از دید طراح پوشیده بمانند و درنتیجه طرح سیستم دچار کاستی شود. این کاستیها بعدها خود را به صورت اشکالات ریز و درشت در سیستم نشان میدهند. تحلیل سیستم مقدم بر همه فرآیندهای دیگر است و تا زمانی که مشخص نشود به دنبال «چه» هستیم، نمیتوانیم آنرا بسازیم. «مشخصات» درست و کامل به طراح کمک میکند تا انچه را که باید ساخته شود طراحی کند. اگر طراح کار خود را بدرستی انجام ندهد، سیستم نمیتواند آنگونه که شایسته است اهداف خود را برآورده کند و مشخصات خواسته شده را دارا نخواهد بود و در نتیجه موفقیت آن کوتاه است. بیشتر اوقات کار تحلیل و طراحی با یکدیگر همپوشانی میکنند و همزمان کار طراحی و هم تحلیل پیش میروند. تمامی آنچه گفتیم بدون تغییر و بطور مستقمیم در سیستمهای نرمافزاری کاربرد دارد. مهندس نرمافزار خوب هم به تحلیل و هم به طراحی سیستم مسلط است. او باید بتواند سیستم را درک کرده و آنرا طراحی کند.« ساخت» سیستمی که طراحی شده خود کار دیگری است که البته جزو مهارتهای مهندسی نرمافزار است و به آن خواهیم پرداخت.