فصل اول   مقدمه‌ای بر تفکر شئ‌گرا   1.      1اهداف فصل هدف اصلی این فصل ارائه یک دیدگاه مناسب درباره ماهیت و چیستی تفکر شئ‌گرا می‌باشد. تا با دیدگاهی مناسب از شئ‌گرایی، در فصل بعد وارد مباحث اصلی شئ‌گرایی و اجزاء داخلی آن شویم. ü      آشنایی با مفاهیم بنیادی برای ورود به مبحث شئ‌گرایی ü      تعریف دقیق مفاهیمی از تئوری سیستمیِ مورد نیاز برای تفکر شئ‌گرایی ü      درک مفهوم پیچیدگیِ سیستمهای نرم‌افزاری و تاثیر آن در تفکر شئ‌گرا ü      ارائه دلیل پیدایش تفکر شئ‌گرا و تاریخچه مربوط به آن ü      درک روح تفکر شئ‌گرا ü      تعریف دقیق تفکر شئ‌گرا و اصول بنیادی آن ü      ارائه نگرشهای مختلف در مورد تفکر شئ‌گرا در این فصل وارد بحث شئ‌گرایی و اجزاء داخلی آن نخواهیم شد و هدف، ارائه یک دیدگاه کلی درباره تفکر شئ‌گرا می‌باشد. 1.1              مقدمه برای شروعِ بحث، درباره شئ‌گرایی، روشهای زیادی وجود دارد. با توجه به اینکه شئ‌گرایی نوعی تفکر جدید در مورد سیستمها و نحوه توسعه آنها می‌باشد، می‌خواهیم ابتدا مفاهیم شئ‌گرایی را به نوعی مستقل از سیستمهای نرم‌افزاری بحث کنیم و در یک بازه بزرگتر و سطحی بالاتر از سیستمهای نرم‌افزاری به بررسی موضوع بپردازیم. تا بعد از بدست آوردن درکی مناسب از دیدگاه و ماهیت اصلی شئ‌گرایی، در حوزه سیستمهای نرم‌افزاری آنرا مطالعه کنیم. برای شروع به شناخت یک موضوع باید بتوان با موضوع مربوطه ارتباط برقرار نمود. برای برقراری ارتباط با یک موضوع، ابتدا باید زبان مورد استفاده در حوزۀ آن موضوع و استانداردها و قوانین آنرا را آموخت. به همین دلیل برای شروع بحث در مورد تفکر شئ‌گرایی لازم است، برخی مفاهیم و تعاریف بنیادی آورده شود که در قسمتهای اول این فصل به تعریف مفاهیم پایه پرداخته شده است. برای شناخت یک موضوع، ابتدا باید یک دیدگاه دقیق نسبت به موضوع داشته باشیم و جایگاه دقیق موضوع مربوطه را بشناسیم. در حقیقت باید مزر موضوع مربوطه را به درستی تشخیص دهیم. در غیر این صورت ممکن است دچار انحراف و عدم فهم دقیق موضوع شویم. برای چنین کاری باید از جزئیات آن موضوع فاصله بگیریم و دلیل آن اینست که جزئیات مانعی برای درک جایگاه و چیستی واقعی موضوع خواهد شد. در حقیقت برای بدست آوردن دیدگاهی مناسب، باید یک پله بالاتر از موضوع مربوطه قدم گذاشت و در یک سطح بالاتری از خود موضوع، موضوع را بررسی نمود. به همین دلیل در ادامه این فصل به بررسی ماهیت و چیستی تفکر شئ‌گرایی پرداخته‌ایم. در این قسمت نیازی به بحث در مورد خود موضوع و عناصر داخلی آن نیست. زیرا هدف، بدست آوردن دیدگاه مناسب از موضوع است. بنابراین در این فصل وارد بحث عناصر داخلی شئ‌گرایی نخواهیم شد و هدف بدست آوردن پیش‌نیازهای درست و مناسب برای ورود به دنیای شئ‌گرایی است. 2.1              تعریف مفاهیم پایه برای شروع بحث در مورد تفکر شئ‌گرایی و ارائه تعاریف و مفاهیم این حوزه، لازم است یک سری مفاهیم اولیه که در تعاریف دیگر به کررات از آنها استفاده خواهند شد، تعریف شده و به عنوان استانداردی برای لغتهای مورد استفاده در این کتاب قرار گیرند. برای همین منظور از تعاریف موجود در تئوری سیستمی استفاده می‌کنیم و تعاریفی با استفاده از [Klir 86] و [Pressman 00] می‌آوریم. 1.2.1         تعریف سیستم ابتدا از تعریف سیستم شروع می‌کنیم. برای سیستم تعاریف مختلفی در منابع گوناگون آورده شده است، ولی ساده‌ترین و در عین حال جامع‌ترین تعریف توسط آقای Klir، به صورت یک مجموعه دوتایی S=(E,R) ارائه شده و مجموعه[1]‌ای از اجزاء[2] و رابطه[3]‌های بین آنها تعریف شده است. در این تعریف به هدف سیستم و اینکه سیستم باید هدفمند باشد، اشاره نشده است. به عنوان مثال، بر اساس این تعریف یک سنگ که از مجموعه‌ای از اجزاء (مولکولها یا اتمها) و رابطه‌های بین آنها (رابطه کششی بین مولکولها یا اتمها) تشکیل شده، یک سیستم می‌یاشد، در حالی که هیچ هدفی ندارد. نکته اول اینجاست که هدف به نوعی در برخی از سیستمها وجود دارد و در بحث تعریف ناظر به این موضوع خواهیم پرداخت. دوم اینکه وجود هدف در تعریف سیستم، یک شرط در تعریف خواهد بود که درصد شمول تعریف را محدودتر خواهد کرد. تحلیل سیستم، در حالت کلی، شکستن یک سیستم به اجزاء و رابطه‌های تشکیل دهنده آن می‌باشد. به عنوان مثال در ادامه، به تحلیل تعریف سیستم می‌پردازیم. یعنی تعریف سیستم را به عنوان یک سیستم، به اجزاء و رابطه‌های تشکیل دهنده می‌شکنیم. 2.2.1         تعریف مجموعه مجموعه یک مفهوم ریاضی می‌باشد و تعریف ندارد. اگر چندین چیز[4] دور هم قرار بگیرند، یک مجموعه تشکیل می‌دهند. در مورد لغت "چیز" هیچ شرط دیگری وجود ندارد. یعنی هر نوعی از چیزها دور هم، می‌توانند تشکیل یک مجموعه را بدهند. با لغت "دور هم قرار گرفتن"، نوعی رابطه فیزیکی یا منطقی بین چیزها برقرار می‌کنیم. به عنوان مثال چندین دانشجو می‌توانند یک مجموعه تشکیل دهند یا یک صندلی با یک کتاب می‌توانند یک مجموعه باشند. 3.2.1         تعریف جزء جزء هر چیزی می‌تواند باشد. بخش، قسمت، موئلفه[5]، عامل[6]، شئ[7] و... همگی می‌توانند یک جزء باشند. بر اساس نوع سیستم و حوزه مسئله، لغتهای مختلفی را بجای جزء استفاده می‌کنند. در حقیقت جرء یک واژه عمومی است. برای مثال یک کامپیوتر به عنوان  یک سیستم، از مجموعۀ Case و Mother Board و CPU و... تشکیل شده است که بین آنها انواع رابطه‌ها وجود دارد. در سیستمهای کامپیوتری نیز اینگونه است. برای مثال یک سیستم عامل‌گرا[8] از مجموعه‌ای از عاملها و رابطه‌های بین آنها است. یا در یک سیستم سرویس‌گرا[9] از سرویس‌ها و در یک سیستم شئ‌گرا، از مجموعه‌ای از اشیاء و رابطه‌های بین آنها بحث می‌شود. 4.2.1         تعریف رابطه، ارتباط[10] ، تعامل[11] در اکثر منابع، رابطه با مفاهیم دیگری مانند ارتباط، عمل[12]، تعامل و... اشتباه گرفته می‌شود و به جای همدیگر مورد استفاده قرار می‌گیرند. در نتیجه به بررسی این مفاهیم می‌پردازیم. براي دو مجموعه A,B، حاصل ضرب دکارتي اينگونه تعريف مي‌شود: رابطه R از A به B، هر زيرمجموعه از خواهد بود ( ). اگر يک رابطه از A به B باشد و يک رابطه از B به A نيز داشته باشيم، آنگاه A با B (يا B با A) ارتباط دارد. ارتباط IR بين A و B را مي‌توان به صورت رياضي نیز تعريف کرد: . اگر در رابطه R از A به B، چيزي از A به B فرستاده شود، رابطه را تعامل يک طرفه يا عمل گويند. اگر در يک ارتباط چيزي بين دو طرف رد و بدل شود، تعامل گفته می‌شود. رابطه يک واژه کلي است. عباراتInteraction, Coupling, Cohesion, Constraint, Function, Organization, Structure, … همگي نوعي رابطه مي‌باشند[Klir 86] . در مجموع، رابطه وجود یک اتصال یا مسیر از یک جزء به جزء دیگر است و ارتباط وجود دو اتصال از جزء اول به دوم و بالعکس، (یا یک اتصال دوطرفه  بین دو جزء) می‌باشد و اگر چیزی بین دو جزء رد و بدل شود، دو جزء باهم در تعامل هستند. 1.   تمرین برای هر یک از عبارات ذکر شده، تعریفی در منبع ارائه شده یا منابع دیگر پیدا کنید. 1.   تحقیق با بررسی همه لغات مورد نظر و لغات دیگر مربوط به یک موضوع، چارچوبی برای همه این تعاریف ارائه کنید تا به عنوان منبعی برای تعاریف موجود در حوزه سیستمهای کامپیوتری باشد و کاربران بر اساس نوع نیاز خود بتوانند تعریف مناسب را انتخاب کنند. به عنوان یک نمونه ساده‌تر می‌توانید از ]ایرانی 85[ استفاده نمایید. 5.2.1         تعریف ناظر[13] ، منظر[14] بر اساس مفاهیم ارائه شده، دو گوی فلزی که با یک میله به هم وصل شده‌اند، یک سیستم می‌باشد. حال سوال اینست که چه چیزی سیستم نیست. هر دو چیز موجود در دنیای واقعی را می‌توان یک جزء در نظرگرفت و حدقل یک رابطه بین آنها پیدا کرد. مثلاً بین هر دو انسان می‌توان هزاران رابطه پیدا کرد و آنها را سیستم در نظر گرفت. بر همین اساس مفهوم ناظر تعریف می‌شود. ناظر کسی یا چیزی است که سیستم برای او اهمیت دارد. در نتیجه بین اجزاء و رابطه‌های موجود، آن دسته از اجزاء و رابطه‌هایی را که برای ناظر اهمیت دارد، در سیستم مورد نظرِ آن ناظر قرار می‌دهیم. هر ناظر از منظر یا دیدگاه خود به سیستم نگاه می‌کند. در حقیقت با تعریف ناظر و منظر، اجزاء و رابطه‌های سیستم را از دیدگاه ناظر و منظرِ آن ناظر، محدودتر می‌کنیم و فقط برخی از اجزاء و رابطه‌ها برای ناظر اهمیت پیدا می‌کند. شکل 1.1  هر ناظر از منظر خود به سیستم نگاه می‌کند. [Booch 07] درنتیجه اگر یک سیستم را با کلیه اجزاء و رابطه‌هایش در نظر بگیریم، با تعریف ناظر و منظر، قسمتهای خاصی از اجزاء و رابطه‌های سیستم برای هر ناظر برجسته شده و مورد توجه قرار می‌گیرد. این برجسته شدن و مورد توجه قرار گرفتن برخی از اجزاء و رابطه‌های خاص، همان مفهوم هدفمند بودن یک سیستم را می‌رساند. یعنی با تعریف ناظر و منظر، سیستم از دیدگاه یک ناظر خاص هدفمند می‌شود. یعنی ممکن است یک سیستم از منظرِ ناظران مختلف اهداف مختلفی داشته باشد. 6.2.1         تعریف تحلیل[15]، ساختار[16]، چارچوب[17] شکستن یک سیستم به اجزاء و رابطه‌های تشکیل دهنده آن را با هدف شناخت آن سیستم، تحلیل گویند. چیدمان منطقی اجزاء و رابطه‌های یک سیستم در حین تحلیل، تشکیل یک ساختار برای آن سیستم خواهد داد. منطق چیدمان می‌تواند سلسله مراتب[18] یا همان سطح‌مندی، شبکه‌ای و... باشد. اگر ساختار به نوعی ارائه شود که تمامی اجزاء و رابطه‌های موجود در سیستم، در آن ساختار جای گیرند، به آن ساختار یک چارچوب برای آن سیستم گفته می‌شود. به عنوان مثال چارچوب مندلیف برای کلیه عناصر موجود در طبیعت ارائه شده است و تمامی عناصر موجود در طبیعت در آن جای می‌گیرند. یعنی چارچوب مندلیف برای عناصر، بر اساس منطقی ساخته شده که تمامی عناصر موجود در طبیعت را می‌توان در آن قرار داد. در سیستمهای نرم‌افزاری نیز مفهوم چارچوب به صورت گسترده مورد استفاده قرار می‌گیرد. به عنوان مثال چارچوب زکمن[19] برای سیستمهای سازمانی[20] که به صورت یک جدول ارائه شده و معروف‌ترین چارچوب در آن حوزه می‌باشد و تمامی اجزاء و رابطه‌های موجود در یک سازمان در آن چارچوب قرار می‌گیرند. شکل 2.1  یک ساختار سطح‌مند برای اجزاء و رابطه‌های سیستم A 2.   تمرین چارچوبهای معروف دیگری در حوزه سیستمهای نرم‌افزار جستجو نمایید. 2.   تحقیق امروزه مفهوم چارچوب در مقالات علمی به گونه‌ای دیگر می‌باشد. یعنی علاوه بر شرطی که در تعریف ارائه شده، چندین شرط دیگر نیز باید وجود داشته باشد تا به یک ساختار، چارچوب گفته شود. به عنوان مثال برای یک چارچوب، الگوریتم انتخاب جزء در ارائه چارچوب باید وجود داشته باشد. چندین مقاله با عنوان "A Framework for …" پیدا کرده و شرایط دیگر چارچوب را پیدا کنید و مستندی تحت عنوان "شرایط ارائه چارچوب" ارائه دهید. 7.2.1         تعریف پیچیدگی[21] یک سیستم از اجزاء و رابطه‌های بین آنها تشکیل می‌شود. تعداد یا تنوع اجزاء یا رابطه‌های یک سیستم را پیچیدگی آن سیستم گویند. هر چه تعداد یا تنوع اجزاء یا رابطه‌های یک سیستم زیاد باشد، سیستم پیچیده‌تر خواهد بود. پیچیدگی سیستمها یک مسئله ذاتی نیست. یعنی اینکه یک سیستم برای همیشه و از دیدگاه هر ناظری پیچیده نیست. پیچیدگی یک مسئله اعتباری می‌باشد. یعنی بر اساس زمان، ناظر و منظر، درصد پیچیدگی‌های مختلفی برای یک سیستم ممکن است ارائه شود. به عنوان مثال محاسبه حاصلضرب دو عدد 1000 رقمی را در نظر بگیرید. از دیدگاه یک ریاضیدان، پیدا کردن جواب این مسئله به زمان زیادی نیاز دارد و پیچیدگی آن فقط بخاطر تعداد زیاد محاسبات می‌باشد. اگر این مسئله را از دیدگاه یک برنامه‌نویس بررسی کنیم، ممکن است یک سیستم پیچیده محسوب نشود. یعنی پیچیدگی سیستمها از دیدگاه انواع ناظران، متفاوت خواهد بود. یک سیستم نرم‌افزاری مثل یک سیستم عامل را در نظر بگیرید، توسعه یک سیستم عامل در 50 سال پیش یک مسئله کاملاً پیچیده محسوب می‌شد، ولی امروزه، یک شرکت برنامه‌نویسی معمولی نیز می‌تواند یک سیستم عامل ساده توسعه دهد. شکل 3.1  تعداد یا تنوع اجزاء یا رابطه‌ها را پیچیدگی آن سیستم گویند. [Booch 07] برای اطلاعات بیشتر درباره تئوری سیستم و مباحث و تعاریف دیگر می‌توانید به [Klir 86] مراجعه کنید. 8.2.1         تعریف اجزاء نرم‌افزاری، موئلفه[22]، زيرسيستم[23] برای تحلیل یک سیستم نرم‌افزاری باید آنرا به بخشهای کوچکتر بشکنیم. این بخشهای کوچکتر، اجزاء نرم‌افزاری گفته می‌شوند. در سيستمهاي نرم‌افزاري، جزء نرم‌افزاري مي‌تواند با نام ماژول، کلاس، موئلفه، زيرسيستم و... آورده شود. تفاوتي که بين يک موئلفه و زيرسيستم وجود دارد اينست که يک موئلفه در یک حوزه عمومی تعریف می‌شود، به طوری که در سیستمهای دیگر نیز مورد استفاده قرار بگیرد. در حالي که يک زيرسيستم در حوزه سيستم تعريف مي‌شود. يعني موئلفه‌ها مي‌توانند به صورت مستقل توسعه داده شوند و مستقل از یک سيستم خاص وجود داشته باشند. در [Souza 99] موئلفه اينگونه تعريف مي‌شود، يک بخش قابل استفاده مجدد[24] از نرم‌افزار که به صورت مستقل توسعه داده مي‌شود و براي ساختن بخشهاي بزرگتر با موئلفه‌هاي ديگر قابل ترکيب است. هر موئلفه بايد اولاً شامل مجموعه‌اي از واسط‌ها براي تعامل با موئلفه‌هاي ديگر باشد و دوماً کد قابل اجرا باشد. با اين تعريف بسياري از اجزاء ديگر همانند کلاس‌هاي کامپايل شده، توابع کتابخانه‌اي و... را که داراي واسط باشند، مي‌توان به عنوان موئلفه نام برد. درنتیجه موئلفه و زیرسیستم تفاوت خاصی باهم ندارند و فقط از لحاظ مفهوم، نام‌گذاری می‌شوند. بدین صورت که زیرسیستم وابسته به یک سیستم یا یک دسته از سیستمهای خاص می‌باشد، درحالی که موئلفه به صورت مستقل توسعه داده می‌شود. 9.2.1         تعریف تحلیل، طراحی[25] و توسعه[26] سیستم یکی از اهداف اصلی علوم مختلف ایجاد سیستم‌هایی جهت رفاه حال بشریت می‌باشد. به عنوان مثال ساخت یک ماشین، ساخت یک خانه یا دوخت یک لباس. برای ایجاد یک سیستم جدید چه مراحلی وجود دارد. چگونه و با چه فرایندی می‌توان یک سیستم ایجاد کرد. برای ایجاد سیستم‌ها روشهای زیادی وجود دارد که امروزه تحت عنوان فرایند توسعه[27] یا مدل فرایند[28] مطرح می‌باشند. البته مفهوم دقیق هر یک از این مفاهیم باهم متفاوت است. برای اطلاعات بیشتر به کتاب [Pressman 00] مراجعه کنید. ولی یک روند کلی برای همه آنها وجود دارد که در این قسمت به تشریح آن می‌پردازیم. برای ایجاد یک سیستم، دو حالت وجود دارد. اول اینکه نمونه‌ای از یک سیستم موجود است و می‌خواهیم از سیستم موجود، یک سیستم جدید، با تغییراتی خاص در آن ایجاد نماییم. حالت دوم اینکه هیچ نمونه‌ای از سیستم وجود ندارد و می‌خواهیم یک سیستم پیشنهاد داده و آنرا ایجاد نماییم. در هر دو حالت یک سیستمِ موجود داریم که این سیستم، یا به صورت فیزیکی وجود دارد و یا اینکه به صورت پیشنهادی ارائه شده است، که به آن سیستم جاری[29] می‌گوییم. هدف ایجاد یک سیستم جدید می‌باشد که به آن سیستم آتی[30] گفته می‌شود. برای شروع باید سیستم موجود را بشناسیم. برای شناخت سیستم موجود، باید آنرا به اجزاء و رابطه‌های تشکیل دهنده بشکنیم. که به آن تحلیل سیستم گفته می‌شود[31]. البته روشهای زیادی برای تحلیل وجود دارد که در کل هدف همه آنها شناخت سیستم بوده و اینکار را با شکستن سیستم به اجزاء و رابطه‌های بین آنها انجام می‌دهند. بعد از تحلیل سیستم، به منظور ساخت سیستم جدید، اجزاء و رابطه‌های بدست آمده از تحلیل را ترکیب کرده و به سیستم جدید می‌رسیم. به ترکیب اجزاء بدست آمده از تحلیل، به منظور ساخت سیستم جدید، طراحی سیستم گفته می‌شود. در حقیقت طراحی، نحوه چیدمان اجزاء و رابطه‌های موجود جهت ساخت سیستم جدید می‌باشد. بعد از طراحی، سیستم را در حوزه مربوطه پیاده‌سازی و تست می‌کنند. به کلیه مراحل ایجاد یک سیستم، شامل شناخت، تحلیل، طراحی و پیاده‌سازی و تست، توسعه سیستم گفته می‌شود. شکل 4.1  مراحل توسعه سیستم‌ها در حالت کلی به عنوان مثال برای ساخت یک ماشین پیشرفته از روی یک ماشین معمولی، ابتدا جهت شناخت ماشین موجود، آنرا تحلیل می‌کنند. یعنی آنرا به اجزاء و روابط تشکیل دهنده می‌شکنند. سپس بعد شناخت کامل اجزاء آن و رابطه‌های بین آنها، طرح ماشین جدید بر اساس اجزاء موجود ارائه کرده، سپس ماشین جدید را بر اساس طراحی جدید می‌سازند. مثال دیگر دوخت یک لباس می‌باشد. برای دوخت یک لباس، با طرحی خاص که کاربر درخواست نموده است، ابتدا درخواست کاربر را مورد تحلیل قرار می‌دهند. سپس طرحی قابل پیاده‌سازی برای آن ارائه کرده و لباس را بر اساس آن طرح می‌دوزند. 3.   تمرین به بررسی مفهوم SDLC[32] پرداخته و آنرا با مفاهیم این قسمت مقایسه کنید.   4.   تمرین روشهای تحلیل و طراحی موجود را جمع آوری کنید. 5.   تمرین مفهوم Reverse Engineering را بررسی کرده و با مفاهیم این بخش مقایسه کنید. 10.2.1     انواع سیستمها، سیستمهای کامپیوتری همانطور که در تعریف جزء نیز اشاره کردیم، مفاهیم و تعاریف ارائه شده در حالت کلی و برای تمام سیستمها صادق است. سیستمهای نرم‌افزاری نوع خاصی از سیستمها محسوب می‌شوند. در منابع مختلف، دسته‌بندی‌های گوناگونی برای انواع سیستمها ارائه شده است و در این قسمت نیازی به ارائه این دسته‌بندی‌ها نیست. یکی از انواع سیستمها، سیستمهای کامپیوتری می‌باشد. سیستمهای کامپیوتری، سیستمهایی هستند که در آنها کامپیوتر و تکنولوژی‌های مربوط به آن اجزاء و رابطه‌های اصلی سیستم را تشکیل می‌دهند. 3.1              کاربرد تعاریف ارائه شده فهم دقیق و کامل تعاریف ارائه شده، شما را در تعاریف و مفاهیم دیگری که در ادامه کتاب آورده می‌شود، کمک فراوانی خواهد کرد. به عنوان مثال در تعریف "ارث‌بری" از کلمه رابطه و یا در تعریف "تناظر" از کلمه ارتباط استفاده خواهد شد و یا در تعریف "الگوهای طراحی" از کلمه ساختارهایی برای... استفاده خواهیم کرد. درنتیجه درک دقیق و کامل این تعاریف و مفاهیم برای درک تعاریف و مفاهیم دیگر کتاب، ضروری می‌باشد. در ضمن این تعاریف به عنوان استانداردی برای لغتهای مورد استفاده در این کتاب خواهد بود. 4.1              پیچیدگی سیستمهای نرم‌افزاری دلیل اصلی بوجود آمدن تفکر و تئوری شئ‌گرایی، پیچیدگی سیستمهای نرم‌افزاری و عدم غلبۀ روشهای قبل، بر این پیچیدگی می‌باشد. برای اینکه بتوانیم تفکر شئ‌گرایی را بهتر درک کنیم، باید ابتدا پیچیدگی سیستمهای نرم‌افزاری، عوامل و مشخصه‌های آن را مورد بررسی قرار دهیم. 1.4.1         بحران سیستم‌های نرم‌افزاری از نيمه دوم قرن بيستم به بعد، سیستمهای نرم‌افزاری با تغييرات و چالشهای بسیار زیادی نسبت به سیستمهای دیگر مواجه بودند. این چالشها اکثرا به خاطر پيشرفت علوم دیگر بوده که بر سیستمهای نرم‌افزاری نیز تاثیر گذاشتند. پیشرفت شگرف سخت‌افزار، تغييرات اساسي و بنیادی در معماري سيستمهاي كامپيوتري و افزايش شگفت‌انگيز ظرفيت حافظه‌هاي اصلي و جانبي و ارزان شدن آنها، عواملي بوده‌اند كه باعث افزايش تقاضا براي سيستمهاي نرم‌افزاری گرديده‌اند. اين عوامل در كنار ضعف روشهاي توليد نرم افزار و ناتواني اين روشها در كنترل پيچيدگي سیستمهای نرم‌افزار باعث بوجود آمدن معضلاتي در توليد آنها شده است، كه به آنها اصطلاح بحران نرم‌افزار[33] اطلاق مي‌شود. ]شمس 83[ علايم و نشانه‌هاي اين بحران را می‌‌توان به صورت زیر بیان نمود. -         ناتواني نرم‌افزار در بهره‌گيري كامل از پيشرفت سريع و قدرت و اطمينان‌پذيري رو به افزايش سخت‌افزار. -         ناتواني روشهاي توليد نرم‌افزار در پاسخگويي به افزايش تقاضا روي سيستمهاي كامپيوتري پيچيده. -         هزينه‌هاي هنگفتي كه براي توليد نرم‌افزار پرداخته مي‌شد. -         تأخيرهایی كه در توليد نرم افزار رخ مي‌داد. -         عدم تامين مشخصات و نيازمنديهاي مورد نظر كاربر. -         كيفيت پايين و نامطمئن و ناكارا بودن نرم‌افزار. نکته قابل ذکر اینست که در بحث سیستمهای نرم‌افزاری و مسئله بحران آنها، منظور از سیستمهای نرم‌افزاری، سیستمهای خیلی ساده نمی‌باشد که توسط یک یا دو نفر در طول چند روز قابل توسعه باشد. بلکه منظور سیستمهای نرم‌افزاری بزرگ و پیچیده می‌باشند که فقط توسط تیم‌های مختلف و متخصص‌ قابل توسعه می‌باشد و در آنها مسائلی چون زمان تحویل پروژه، هزینه‌ها، منابع و... اهمیت داشته باشد. 2.4.1         دلایل پیچیدگی سیستمهای نرم‌افزاری بحران‌های موجود در حوزه سیستمهای نرم‌افزاری دلیلی قاطع بر پیچیدگی سیستمهای نرم‌افزاری می‌باشد. حال چگونه می‌توان بر پیچیدگی سیستمهای نرم‌افزاری غلبه نمود. ابتدا به بررسی عوامل پیچیدگی در سیستمهای نرم‌افزاری می‌پردازیم، تا با بررسی و تلاش برای رفع این عوامل بتوانیم بر پیچیدگی موجود غلبه کنیم. در [Booch 07]، چهار عامل اصلی برای پیچیدگی سیستمهای نرم‌افزاری معرفی شده است که به شرح آنها می‌پردازیم. 1.2.4.1   پیچیدگی موجود در خود سیستمهای نرم‌افزار در توسعه سیستمهای نرم‌افزاری بزرگ، همیشه عناصری وجود دارند که پیچیدگی آنها اجتناب ناپذیر است. وجود انواع مختلف خواسته‌ها و نیازمندی‌های مختلف یکی از عناصر اجتناب ناپذیر پیچیدگی می‌باشد. در برخی موارد، مجموعه خواسته‌ها، متضاد نیز می‌باشند که باید تعادلی بین آنها برقرار نمود. به عنوان مثال درخواست سرعت و امنیت خیلی زیاد. دومین عنصر، عدم درک متقابل ذی‌نفعان[34] موجود در سیستمها از همدیگر می‌باشد. داشتن نوع تفکرات و برداشتهای مختلف از سیستم، باعث بوجود آمدن چندگانگی تفکر در مورد سیستم خواهد شد. شکل 5.1  چندگانگی تفکر در مورد سیستم، عاملی اجتناب ناپذبر در توسعه سیستمهای نرم‌افزاری می‌باشد. عنصر بعدی اجتناب ناپذیر پیچیدگی در سیستمهای نرم‌افزاری، تغییرات نیازمندیها در طول توسعه پروژه و حتی بعد از توسعه کامل آن می‌باشد. اکثر تغییرات از دیدگاه کاربر ساده به نظر می‌رسد، ولی ممکن است باعث دوباره کاریهای زیادی شود. 2.2.4.1   مشکل مدیریت فرایند توسعه عامل بعدی پیچیدگی سیستمهای نرم‌افزاری عدم مدیریت مناسب فرایند توسعه سیستمهای نرم‌افزاری است. سیستمهای نرم‌افزاری روز‌به‌روز پیچیده‌تر می‌شوند. درك كامل و دقيق چنين سيستمهاي بزرگي از عهده يك نفر خارج است. حتي اگر سعي كنيم سيستم را به قسمتهایی با‌معني تجزيه نماييم، باز با صدها قسمت روبرو خواهيم شد. پس ما به يك گروه يا يك تيم از متخصصين نياز داريم. به صورت ايده‌آل بايد سعي كنيم از يك تيم با حداقل افراد و حداکثر تخصص‌ها استفاده نماييم. ولي صرف نظر از اندازه تيم، توسعه مبتني بر تيم، هميشه با مشكلات مهمي روبرو بوده است، زيرا افراد بيشتر، به معني ارتباطات پيچيده‌تر و در نتيجه هماهنگي بين افراد تيم مشكل‌تر مي‌شود بخصوص اگر تيم از نظر جغرافيائي پراكنده باشد. در واقع مشكل كليدي كه توسعه تيمي با آن مواجه است همان مديريت صحيح افراد تيم است، به طوري كه يگانگي و يكپارچگي تحليل و طراحي حفظ گردد. 3.2.4.1   انعطاف‌پذیری نرم‌افزار و عدم وجود استانداردهای کافی توسعه سیستمهای نرم‌افزاری با توسعه سیستمهای دیگر مثل ساخت ساختمان، شباهتهای زیادی دارد. ولی تفاوتهای عمده‌ای نیز در توسعه آنها وجود دارد. ساخت سیستمهای نرم‌افزاری با توجه به اینکه اجزاء تشکیل دهنده آن از کدهای برنامه‌نویسی تشکیل شده است، از انعطاف‌پزیری خیلی بالایی برخودار است. تغییر در کدها، ایجاد کدهای جدید، کپی‌سازی از کدها و... با زحمت بسیار کمتری نسبت به توسعه سیستمهای دیگر، مانند ساخت ساختمان، انجام می‌شود. این انعطاف‌پذیری در نگاه اول خیلی مفید است. ولی زمانی که سیستمها خیلی بزرگ و پیچیده می‌شود، به ضرر تیم توسعه‌دهنده نرم‌افزار است. به عنوان مثال، يك شركت ساختمان‌سازی براي ساختن يك ساختمان از مصالح ساختماني با مشخصات استاندارد مانند آجر و آهن كه بوسيله شركتهاي ديگر توليد شده است، استفاده مي‌نمايد يا در صنعت سخت‌افزار، مثلاً براي ساخت یک Board از ICهاي استاندارد ساخت شركتهاي ديگر استفاده مي‌شود و هرگز خود شركت سازنده اقدام به ساختن همه قطعات مورد نياز نمي‌كند ولي متاسفانه چنين اتفاقي در صنعت نرم‌افزار به فراواني رخ نمي‌دهد. اينها مثالهايي از استفاده مجدد می‌باشد، که صنعت نرم‌افزار شديداً به آن نيازمند است. البته در اين راستا گامهاي خوبي برداشته شده است. به علاوه، در صنعت ساختمان‌سازي استانداردهايي براي تضمين كيفيت مواد اوليه مورد نياز وجود دارد در حاليكه صنعت نرم افزار از اين نظر خيلي عقب مانده است. لذا توليد سيستمهاي نرم‌افزاري يك كار طاقت فرسا به شمار مي‌آيد و عدم وجود استانداردهای کافی باعث پیچیده‌تر شدن توسعه سیستم‌های نرم‌افزاری بزرگ شده است. 3.   تحقیق به بررسی تکنولوژی، فرایند، استانداردها و نحوه توسعه سیستمهای بزرگ دیگر، مانند ساخت ساختمانهای بزرگ یا تولید خودرو پرداخته، سپس کاربردهایی را که می‌توان از آنها در توسعه سیستمهای نرم‌افزاری بکار برد، جمع‌آوری کرده و به عنوان ایده جدید در حوزه سیستمهای نرم‌افزاری مطرح کنید. 4.2.4.1   مشکل توصیف رفتار سیستمهای گسسته از نظر رفتار مي‌توان سيستمها را به طور كلي به دو گروه تقسيم نمود. سيستمهاي پيوسته[35] که رفتار اين سيستمها بوسيله يك تابع پيوسته توصيف مي‌گردد و توسط آن مي‌توان رفتار سيستم و عكس‌العمل آن در مقابل رويدادهاي گوناگون را پيش‌بيني كرد. گروه دوم، سيستمهاي گسسته[36] که اين سيستمها از تعدادی حالت متناهي تشكيل شده است و اين تعداد در سيستمهاي گسسته و پيچيده معمولا عدد بزرگي است. ويژگي بارز اين سيستمها اين است كه نمي‌توان انتقال بين حالتهاي مختلف سيستم را بوسيله توابع پيوسته مدل‌سازي نمود. لذا اين امكان بالقوه وجود دارد كه به ازاي يك رويداد غير منتظره خارجي، سيستم از حالت فعلي به حالت جديد و یا غير مطلوب منتقل گردد كه اين انتقال مي‌تواند غيرقطعي[37] باشد و در بدترين شرايط اين رويداد مي‌تواند حالت سيستم را خراب نماید. با توجه به اينكه كامپيوترهاي ديجيتال سيستمهاي گسسته هستند و اينكه نرم‌افزار روي اين دستگاه‌ها اجرا مي‌گردد، پس ما با يك سيستم گسسته سروكار داريم. در نتیجه توصیف رفتار آنها بسادگی انجام نمی‌شود و نمی‌توان تمامی حالات آنرا پیش‌بینی کرد.   فرض كنيد يك هواپيما بوسيله يك كامپيوتر كنترل مي‌شود، چون با يك سيستم گسسته مواجه هستيم احتمال بروز حالتي مانند اينكه وقتي يك مسافر لامپ بالاي سر خود را روشن كند. سپس به عنوان مثال، هواپيما به طور ناگهاني به سمت پايين حركت نمايد، وجود دارد! در يك سيستم پيوسته ما انتظار بروز چنين رويدادي را نداريم ولي متأسفانه در يك سيستم گسسته به علت اينكه طراحان سيستم، فعل و انفعالهايي كه بين تعدادي از رويدادهاي ويژه رخ مي‌دهد را در نظر نگرفته‌اند، احتمال بروز چنين حالتهايي وجود دارد. با توجه به مثال فوق و اينكه نرم‌افزار يك سيستم گسسته است، مي‌بينيم كه اين خاصيت يكي از عوامل افزايش پيچيدگي سيستمهاي نرم‌افزاري است. تمرین: چه عوامل دیگری می‌توانند دلیل پیچیدگی سیستمهای نرم‌افزاری باشند. 3.4.1         ویژگیهای سیستمهای پیچیده مشكل اصلي توسعه سیستمهای نرم‌افزاری پيچيدگي‌های موجود در نرم‌افزار است. براي پيدا نمودن راه مقابله با آن، خصوصيات كلي سيستمهاي پيچيده را بررسي نماييم. در [Booch 07] پنج ویژگی اصلی برای سیستمهای پیچیده ارائه شده است. 1-     در اغلب سيستمهاي پيچيده، پيچيدگي به صورت سلسله مراتب[38] ظاهر مي‌شود. به عبارت ديگر، يك سيستم پيچيده از چند زيرسيستم مرتبط به هم تشكيل شده كه هر كدام به نوبه خود از چند زيرسيستم كوچكتر تشكيل مي‌شود. اين روند تجزيه تا پايين‌ترين سطح از اجزاء اوليه سیستم ادامه مي‌يابد. 2-     انتخاب اينكه چه اجزائی در سلسله مراتب مذکور اولویت بالاتری دارد، نسبتا دلخواه و تا حدود زيادي بستگي به دیدگاه طراح سيستم دارد. 3-     در سيستمي كه از چند زيرسيستم تشكيل مي‌شود، ارتباط بين اجزاي هر یک از اين زيرسیستمها قویتر از ارتباط بين خود زير سيستمها است. 4-     سيستم‌هاي سلسله مراتبي معمولا از تعداد كمي از زيرسيستمهاي مشخص و متفاوت تشكيل مي‌شوند كه اين زيرسيستمها به صورتهاي گوناگون و ترتيب‌هاي مختلف ظاهر مي‌شوند. 5-     معمولا سيستمهاي پيچيده كه به صورت محكم و استوار عمل مي‌كنند، حاصل تكامل سيستمهاي ساده‌اي هستند كه به درستي عمل مي‌كردند. سيستمهاي پيچيده كه از ابتدا به صورت پيچيده طراحي مي‌شوند، هرگز كار نخواهند كرد. برای اطلاعات کاملتر در مورد پیچیدگی و مفاهیم مربوطه به [Booch 07] مراجعه کنید. 5.1              نقش تجزیه[39] برای غلبه بر پیچیدگی براي غلبه بر پیچیدگی سیستمهای بزرگ و پیچیده، سيستم را به اجزاي كوچكتر تقسيم مي‌كنيم. سپس هر كدام از آنها را به تنهايي حل مي‌كنيم. ولي يك عامل مهم وجود دارد و كه همان قدرت محدود ذهن انسان در پردازش پيچيدگي است. به عبارت ديگر ذهن انسان قادرست مقدار محدودي از اطلاعات همزمان را پردازش يا درك نمايد. زمانيكه تجزيه و تحليل يك سيستم نرم‌افزاري پيچيده را شروع مي‌كنيم، با اجزاي خيلي زياد و روابط پيچيده‌اي كه بر آنها حاكم است روبرو مي‌شويم، كه مشتركات كمي دارند. از طرفي پيچيدگي سيستم‌هاي نرم‌افزاري روز به روز در حال افزايش است، و از طرف ديگر قدرت پردازش همزمان مغز انسان محدود است. چگونه مي‌توان اين معضل را حل نمود؟ دو روش عمومی برای تجزیه و در ادامه، طراحی و توسعه سیستمهای پیچیده وجود دارد. روش اول تجزیه الگوریتمی، که به روشهای ساخت‌یافته[40]، تابعی[41] یا فرایند‌محور[42] نیز معروف است و روش دوم تجزیه شئ‌گرا می‌باشد که به تشریح آنها می‌پردازیم. 6.   تمرین روشهای دیگری مانند Rule Oriented, Logic Oriented و... مورد بررسی قرار گیرد. 1.5.1         روش تجزیه الگوریتمی اولین راه‌حلهایی که به صورت سنتی برای اکثر ما آموزش داده می‌شود، تفکر بالا به پایین[43] می‌باشد. بدین صورت که برای تحلیل و طراحی مسائل مختلف، ابتدا یک فرایند یا روند کلی برای مسئله در نظر می‌گیریم. در ادامه، فرایند کلی را به قدمهای کوچکتر با مراحل کمتر می‌شکنیم. سپس با ترکیب قدمهای کوچکترِ بوجود آمده، روند کلی را ساخته و در نهایت مسئله حل می‌شود. به عنوان مثال برای نوشتن یک سیستم نرم‌افزاری کتابخانه ساده، ابتدا به مجموعه عملیات موجود در این سیستم پرداخته می‌شود. به عنوان مثال، عملیات ثبت عضو جدید، ثبت کتاب، امانت کتاب و... وجود دارد. سپس هر یک از این عملیات به نوبه خود به عملیات کوچکتر شکسته می‌شوند. 7.   تمرین مثالهای دیگری برای تفکر بالا به پایین بیاورید. 2.5.1         روش تجزیه شئ‌گرا در روش تجزیه شئ‌گرا، سیستم به مجموعۀ عملیات، فرایندها یا مجموعه‌ای از فعالیتها شکسته نمی‌شود، بلکه ابتدا سیستم را به مجموعه‌ای از عناصر بنام اشیاء تجزیه می‌کنیم و در ادامه عملیات سیستم را به هر یک از اشیاء، در تقابل با اشیاء دیگر نسبت می‌دهیم. شئ‌گرایی یک روش پایین به بالا[44] محسوب می‌شود یعنی ابتدا اجزاء سیستم تعین شده سپس رابطه‌های بین آنها پیدا می‌شود تا سیستم اصلی ایجاد شود. در مورد اشیاء در فصل بعد مفصل بحث خواهد شد. به عنوان مثال برای سیستم نرم‌افزاری کتابخانه، ابتدا اشیاء سیستم، شامل کتابها، اعضاء و... را مشخص کرده و عملیات مختلف سیستم را به هر یک از آنها نسبت می‌دهیم. به عنوان مثال اعضاء می‌توانند در سیستم کتابخانه عملیات ثبت نام انجام دهند. سوال اینست که کدامیک از این روشهای تجزیه مناسب می‌‌باشد. نکته مهم اینست که هر یک از این روشها به عنوان یک راه‌حل مطرح می‌باشند و موارد کاربرد خود را دارند. روش تجزیه الگوریتمی، سیستم را به مجموعه‌ای از فعالیتهای مرتب شکسته ولی در تجزیه شئ‌گرا، سیستم به مجموعۀ اشیاء می‌شکند. 4.   تحقیق آیا می‌توان یک چارچوب کلی برای سیستمهای نرم‌افزاری مشخص نمود که چه سیستمهایی با تجزیه الگوریتمی و چه سیستمهایی با تجزیه شئ‌گرا بهتر به جواب می‌رسند؟ چه پارامترهایی برای سیستمها باید د نظر گرفت که بر اساس آن پارامترها، یک روش برای یک سیستم خاص انتخاب شود. 6.1              پیدایش تفکر شئ‌گرایی جهت شناخت هر چه بهتر تفکر شئ‌گرایی و جایگاه و ماهیت اصلی بوجود آمدن آن، به بررسی تاریخچه توسعه سیستمهای نرم‌افزاری و در ادامه به بررسی تاریخچه شئ‌گرایی می‌پردازیم. 1.6.1         تاریخچه توسعه سیستم‌های نرم‌افزاری با توجه به پيچيدگي روز افزون سيستمهاي نرم‌افزاري، روش‌هاي مقابله با آن نيز به نوبه خود تكامل يافته‌اند. در روزهاي اوليه عصر كامپيوتر نقش نرم‌افزار در يك سيستم كامپيوتري نقش ثانويه تلقي شده و هزينه اساسي طراحي يك سيستم كامپيوتري براي سخت افزار پرداخت مي‌شد. چون در آن روزها قابليت سخت‌افزار بسيار محدود بوده، برنامه‌ها ساده و كوچك بوده و زبان رايج همان زبان ماشين بود. سپس براي تسهيل در نوشتن برنامه‌هاي بزرگتر زبان اسمبلي ابداع شد. با اينكه در آن زمان سخت‌افزار همه منظوره وجود داشت، اما نرم‌افزارها تك منظوره بودند. بدين معني كه براي كاربرد بخصوصي طراحي می‌شدند. بيشتر نرم‌افزارها بوسيله يك نفر طراحي، پياده‌سازي، تست ، نگهداري و حتي اجرا مي‌شد و با توجه به طبيعت شخصي اين محيط، فرآيند تحلیل و طراحي به صورت ضمني در ذهن برنامه‌نويس صورت مي‌گرفت، بدون اينكه طرح خود را روي وسيله‌اي در خارج از ذهن خود مانند كاغذ نمايش دهد. ولي در اوايل دهه ٧٠ ميلادي اين وضعيت شروع به دگرگوني نمود. سخت‌افزار سريعتر، قابل اطمينان‌تر و ارزانتر شده است و اين پيشرفت شگفت‌انگيز سخت‌افزار باعث اقتصادي شدن فرآيند خودكار‌سازي بسياري از كاربردهاي صنعتي و تجاري شد و اين به معني افزايش تقاضا براي سيستمهاي نرم‌افزاي پيچيده‌تر بود. در مقابل اين فشار، زبانهاي سطح بالا[45] بعنوان ابزارهاي مهم توليد سيستم‌هاي نرم‌افزاري وارد صحنه شدند. در واقع اين سيستمها بازدهي برنامه‌نويسان منفرد و تيمهاي نرم‌افزاري را افزايش داده بودند. در دهه ٦٠ و ٧٠ ميلادي توجه پيشگامان رشته نرم‌افزار به تحلیل و طراحي، بعنوان ابزار مهم مقابله با پيچيدگي سيستمهاي نرم‌افزاري معطوف گشته بود. لذا در اين دو دهه و بعد از آن روشهاي زيادي ابداع شده است كه مهمترين آنها طراحي ساخت‌يافته است. 2.6.1         تاریخچه شئ‌گرایی مفهوم اشیاء، اولین بار در سال 1960 در کامپیوتر PDP-1 در دانشگاه MIT برای محاسبات استفاده شد و در سال 1963، Ivan Sutherland در پروژه Sketchpad از آن استفاده نمود. ولی این دو، نمونه‌های کاربردی بودند. اولین گزارش استفاده از شئ‌گرایی در محیط برنامه‌نویسی در سال 1965 توسط Ole-Johan Dahl و Kristen Nygaard ارائه شد. در واقع تفکر شئ‌گرایی برای اولین بار در زبان برنامه‌نویسی Simula 1 در سالهای 1961 تا 1965 توسط Ole-Johan Dahl و Kristen Nygaard در دانشگاه Oslo ارائه شد و در سال 1967 در زبانSimula 67  توسط همین گروه تکمیل گردید. زبان Simula 1 برای شبیه‌سازی سیستمهای پیچیده طراحی شده بود، به همین دلیل Simula 67، برای برنامه‌نویسی عمومی طراحی شد. در اوایل سال 1970 گروه آقای Alan Kay، زبان برنامه‌نویسی Smalltalk را بر مبنای Simula 67 توسعه دادند و در Smalltalk 76، مفاهیم شئ‌گرا را به آن اضافه نمودند. در دهه 70، همزمان با Smalltalk، زبانهای C و Pascal نیز به صورت غیرشئ‌گرا و با الهام از زبان برنامه‌نویسی مبتنی بر الگوریتمِ ALGOL توسعه یافتند. در دهه 80 با بزرگ شدن و پیچیده‌تر شدن سیستمهای نرم‌افزاری نیاز به روشی جدید در کلیه مراحل توسعه سیستمهای نرم‌افزاری[46] احساس می‌شد و کم‌کم توسعه دهندگان سیستمهای به روش شئ‌گرایی روی آوردند. به همین دلیل زبانهای شئ‌گرای زیادی بوجود آمده و شئ‌گرایی مورد توجه زیادی قرار گرفت. زبانهای C++، Object Pascal و Eiffel به عنوان زبانهای شئ‌گرای پیشرفته‌تر ارائه شده و مورد استفاده برنامه‌نویسان زیادی قرار گرفت و سیستمهای جدید با برنامه‌نویسی شئ‌گرا توسعه داده می‌شدند. دهه 90 انقلاب رویکرد[47] شئ‌گرایی است. سیستمهای نرم‌افزاری بزرگتر و پیچیده‌تر شدند. در این دهه، شئ‌گرایی به عنوان یک Paradigm مطرح شد و در کلیه مراحل توسعه سیستمهای نرم‌افزاری، اعم از برنامه‌ریزی، تحلیل، طراحی، پیاده‌سازی و حتی تست سیستم، از تفکر شئ‌گرایی استفاده کردند. آقای Booch و Rumbaugh در 1991، Jacobson در 1992 از تفکر شئ‌گرایی در تحلیل و طراحی سیستمهای نرم‌افزاری استفاده نمودند. در سال 1995 زبان برنامه‌نویسی Java به عنوان یک استاندارد برنامه‌نویسی شئ‌گرا ارائه شد. که خیلی از نواقص و مشکلات زبانهای شئ‌گرای قبلی را نداشت و به سرعت مورد توجه برنامه‌نویسان و شرکتهای بزرگ قرار گرفت و در سال 2000 نیز زبان C# ارائه شد که در اکثر موارد شبیه Java بود. تا سال 1998 بیش از 173 زبان برنامه‌نویسی شئ‌گرا ارائه شده بود. برای اطلاعات کاملتر می‌توانید به [Hostetter 98] مراجعه کنید. در شکل زیر تاریخچه مختصری از تکامل برخی زبانهای شئ‌گرا و غیر شئ‌گرا ارائه شده است.   شکل 6.1  تاریخچه تکامل برخی زبانهای برنامه‌نویسی در گذر زمان   نکته قابل توجه در تاریخچه شئ‌گرایی اینست که تفکر شئ‌گرا در سال 1960 بوجود آمده ولی در سال 1990 به صورت جدی بکار برده شده است. یعنی با اینکه از سال 1960، زبانهای شئ‌گرا در حال توسعه بودند، اما توجه خاصی به آنها نمی‌شد. دلیل این بی‌توجهی، عدم نیاز به برنامه‌نویسی شئ‌گرا بود و روشهای دیگر پاسخگوی مسائل آن زمان بودند. ولی در دهه 90 روشهای معمول نمی‌توانستند بر پیچیدگی سیستمهای جدید غلبه کنند. در نتیجه با کاربرد تفکر شئ‌گرا، انقلابی در توسعه سیستمهای نرم‌افزاری بوجود آمد. چه بسا با عدم استفاده از تفکر شئ‌گرا، هنوز در خواب دهه 70 و 80 بودیم و چنین توسعه‌ای میسر نمی‌شد. این اتفاق در مورد تفکرهای دیگر نیز در تاریخ اتفاق افتاده است. به عنوان مثال تئوری فازی[48] دهها سال ارائه شده بود و هیچ کاربردی برای آن پیدا نمی‌شد و بدون استفاده مانده بود. که بعدها با ارائه کاربردهایی برای آن، انقلابی در حل مسائل بوجود آمد. امروزه تئوری‌هایی نیز وجود دارند که ممکن است در آینده کاربرد آنها مشخص گردد و باعث انقلابی در عرصه‌های مختلف علوم گردد. در اصل علوم نظری مانند ریاضیات همیشه حداقل 50 سال از دیگر علوم جلوتر هستند. از سال 2000 به بعد، تفکرهای دیگری نیز ارائه شدند. به عنوان مثال تفکر Aspect Oriented در حوزه برنامه‌نویسی ارائه شده و حتی در تحلیل و طراحی سیستمها نیز وارد شده است. یا تفکرهای Pattern Oriented, Agent Oriented, Service Oriented و... که همه این روشها بر پایه تفکر شئ‌گرایی می‌باشد. 7.1              روح تفکر شئ‌گرا یکی از روشهای ساده‌سازی مسائل، استفاده از واقعی‌سازی[49] یا نزدیک کردن مسئله به دنیای واقعی است و در ادامه، استفاده از تکنینکهای موجود در دنیای واقعی برای حل مسئله مورد نظر می‌باشد. تفکر شئ‌گرايي يك روشي براي تفكر در مورد يك مسأله با استفاده از مفاهيم موجود در دنياي واقعي به جاي مفاهيم موجود در دنياي كامپيوتر است. روح تفکر شئ‌گرایی از دنیای واقعی سرچشمه می‌گیرد. در تفکر شئ‌گرا برای توسعه یک سیستم، از اجزاء و رابطه‌های موجود در دنیای واقعی استفاده می‌کنیم. کلیه انسانها، کلیه ابزار، رخدادها، اتفاقات و انواع رابطه‌های موجود بین هر یک از آنها، مبنای تفکر شئ‌گرایی می‌باشد. این روش، یعنی الهام گرفتن از دنیای واقعی جهت توسعه سیستمها، در اغلب علوم دیگر نیز اتفاق افتاده و باعث پیشرفتهای زیادی در حوزه‌های مختلف علوم شده است. سالها تفکر شئ‌گرا ارائه شده بود ولی کاربرد چندانی در حوزه برنامه‌نویسی برای آن ارائه نمی‌شد. تا اینکه سیستمها بزرگتر و پیچیده‌تر شدند. یعنی مهمترین دلیل روی آوردن به تفکر شئ‌گرا، پیچیده‌تر شدن سیستمهای نرم‌افزاری و عدم پاسخگویی روشهای موجود در مقابل این پیچیدگی می‌باشد. دنیای واقعی پیچیده‌ترین سیستمها را دارد. به عنوان مثال هنوز علم امروز نتوانسته یک حشره معمولی مثل زنبور را شبیه‌سازی کند. هدف اصلی از علوم، بخصوص علم کامپیوتر و هوش مصنوعی ایجاد سیستمهایی شبیه سیستمها موجود در دنیای واقعی است. بر همین اساس برای غلبه بر پیچیدگی سیستمهای کامپیوتری، از تئوری موجود در دنیای واقعی استفاده شده است. به عنوان مثال یک جامعه بشری با تعداد زیادی انسان و تعداد و تنوع بیشمارِ انواع رابطه‌ها، تشکیل شده و پایدار می‌ماند. در نتیجه می‌توانیم از نحوه شکل‌گیری، توسعه، پایداری و ماندگاری دنیای واقعی در سیستمهای کامپیوتری نیز استفاده کنیم. درحقیقت، اگر بخواهیم روح تفکر شئ‌گرایی را در یک جمله بیان کنیم، به صورت زیر خواهد بود. تفکر شئ‌گرایی استفاده از تکنولوژیهای موجود در سیستمهای دنیای واقعی برای غلبه بر پیچیدگی و توسعه سیستمهای نرم‌افزاری می‌باشد. حال سوال اینست که چه تکنولوژیهایی در دنیای واقعی وجود دارد. در قسمت بعد، بر پایه تفکر استفاده از دنیای واقعی، اصول شئ گرایی را شرح داده و نحوه غلبه هر یک از اصول بر پیچیدگی توسعه سیستمها را شرح خواهیم داد. 8.1              تعریف تفکر شئ‌گرایی دلیل بوجود آمدن تفکر شئ‌گرا، غلبه بر پیچیدگی سیستمهای نرم‌افزاری می‌باشد. برای چنین تفکری باید یک سری اصول وجود داشته باشد تا در قالب آن اصول و رعایت آنها بتوان بر پیچیدگی سیستمها غلبه کرد. برای تفکر شئ‌‌گرا در [Booch 07] چهار اصل بنیادی و اساسی معرفی شده است. یک سیستم شئ‌گرا است اگر کلیه اصول اساسی چهارگانه زیر در آن رعایت شده باشد. در ادامه اصول شئ‌گرایی را به صورت مختصر شرح می‌دهیم. در فصل بعد به تشریح کامل این اصول خواهیم پرداخت. 1.8.1         اصل تجرید[50] در نظر گرفتن برخی از اجزاء و روابط یک سیستم از منظر یک ناظر خاص را تجرید گویند. یک سیستم از مجموعۀ اجزاء و رابطه‌ها تشکیل شده است و از منظر یک ناظر خاص و بر اساس منطق آن ناظر، برخی از اجزاء و رابطه‌های یک سیستم را انتخاب کنیم. در حقیقت با دوری از جزئیات غیر ضروری می‌توان از پیچیدگی سیستم مورد نظر کاست. با دوری از جزئیات می‌توان به راه‌حل‌های بهتری برای یک مسئله رسید. به عنوان مثال معماری برای یک ساختمان، قبل از ساخت آن، نوعی دوری از جزئیات برای غلبه بر پیچیدگی ساخت ساختمان می‌باشد. 2.8.1         اصل پنهان‌سازی یا محصورسازی[51] پنهان کردن برخی از اجزاء و روابط یک سیستم با هدف عدم پذیرش تاثیرات ناخواسته و کنترل نشده می‌باشد. بر اساس این اصل در یک سیستم برخی از اجزاء یا رابطه‌های یک سیستم از دیدگاه سیستمهای دیگر مخفی و محدود نگه داشته می‌شود. در این حالت یک واسط[52] برای سیستم تعریف می‌شود که ارتباط بین اجزاء خارج سیستم با اجزاء داخلی سیستم تنها از طریق این واسط خواهد بود و بر نحوه ارتباط‌های موجود کنترل خواهد داشت. به عنوان مثال در ساخت یک ساعت از یک باطری استفاده می‌شود، در حالی که سازندگان ساعت به اجزاء داخلی باطریها اهمیتی نمی‌دهند و تنها از طریق ورودی و خروجی آن باطری است که با آن در ارتباط هستند. بر اساس این اصل می‌توان سیستم را به زیرسیستمهایی با کمترین وابستگی به همدیگر تجزیه کرد. 3.8.1         اصل پیمانه‌بندی[53] اصل پیمانه‌بندی یعنی اینکه در تجزیه یک سیستم به اجزاء کوچکتر، سیستم به اجزائی با کمترین وابستگی[54] بین اجزاء و بیشترین پیوستگی[55] داخل اجزاء تجزیه شود. هنگامی که یک سیستم با چنین منطقی به اجزاء کوچکتر شکسته می‌شود، مجموع میزان تلاشی که باید برای حل چنین اجزاء کوچکتری صرف کنیم، کمتر از زمانی است که باید برای حل کل سیستم به یکباره صرف کنیم. 4.8.1         اصل سلسله‌مراتب[56] برای غلبه بر پیچیدگی یک سیستم باید آنرا به اجزاء کوچکتر تجزیه کنیم. در تجزیه یک سیستم به اجزاء و رابطه‌های تشکیل دهنده، باید از اصل تجرید استفاده نماییم. در این حالت اجزاء و رابطه‌ها در سطوح مختلف جزئیات قرار می‌گیرند و سلسله مراتبی از اجزاء و رابطه‌ها تشکیل می‌شود. در حقیقت در تجزیه یک سیستم، با رعایت تجرید، سیستم به اجزائی سطح‌مند شکسته شده و تشکیل سلسله مراتب برای سیستم می‌دهند. به عنوان مثال در تجزیه یک ماشین به اجزاء کوچکتر، ابتدا در سطح اول ماشین را به بدنه، موتور، شاسی و... می‌شکنیم. سپس هر یک از اجزاء کوچکتر به اجزاء کوچکتر دیگر در سطح دوم شکسته می‌شوند. بر اساس این اصل یک ساختار با منطق سلسله مراتب برای سیستم بوجود می‌آید. 8.   تمرین بر اساس روح تفکر شئ‌گرا، برای اصول شئ‌گرای تعریف شده، مثالهایی از دنیای واقعی بیاورید. 9.   تمرین اصل سلسله مراتب را با تعریف ساختار مقایسه کنید. 10.             تمرین در قسمت ویژگی سیستمهای پیچیده، پنج ویژگی اساسی برای سیستمهای پیچیده ارائه شد. طی یک بررسی، نشان دهید اصول شئ‌گرایی چگونه بر سیستمهای پیچیده غلبه می‌کنند. به غیر از اصول چهارگانه اصلی، سه اصل دیگر نیز برای تفکر شئ‌گرایی معرفی می‌شود که در درجه اهمیت کمتری نسبت به اصول اساسی چهارگانه قرار دارند. بدین معنی که وجود این سه اصل ضروری نیست، ولی استفاده از آنها کمک فراوانی برای غلبه هر چه بهتر بر پیچیدگی سیستمها خواهد داشت. 1-     Typing 2-     Concurrency 3-     Persistence در فصل بعدی به تشریح کامل هر یک از اصول شئ‌گرایی خواهیم پرداخت. 9.1              دیدگاه تکاملی[57] و انقلابی[58] دو روش کلی برای توصیف و بیان تئوری تفکر شئ‌گرایی وجود دارد. روش اول، معروف به دیدگاه تکاملی درباره شئ‌گرایی است. بر اساس این روش، شئ‌گرایی به عنوان یک روش جدید، در ادامه روشهای قبلی بیان می‌شود و نوعی تکامل روشهای پیشین، جهت غلبه بر پیچیدگی سیستمهای موجود می‌باشد. در این روش، برای بیان تفکر شئ‌گرا، ابتدا روشهای قبلی مانند تفکر برنامه‌نویسی ساخت‌یافته[59] یا رویه‌ای[60]، شرح داده شده و در ادامه به بیان مشکلات موجود در روشهای قبلی می‌پردازند. سپس برای حل مشکلات موجود، روش و تفکر شئ‌گرایی به عنوان راهکار بیان می‌گردد. درنتیجه برای بیان مفاهیم شئ‌گرایی، سعی در برقراری ارتباط بین مفاهیم قبلی با مفاهیم جدید شئ‌گرایی را دارند.  مشکل این روشِ توصیف تفکر شئ‌گرایی، اینست که کسانی که قصد یادگیری مستقیم مفهوم شئ‌گرایی را دارند، نمی‌توانند از این منابع استفاده کنند و باید تفکرات قبلی مانند تفکر ساخت‌یافته را قبلاً آموخته و تخصص داشته باشند. روش دوم، معروف به دیدگاه انقلابی درباره شئ‌گرایی است. این دیدگاه، شئ‌گرایی را به عنوان یک روش کاملاً جدید و مجزا از روشهای قبل می‌داند. بر اساس این روش، برقراری ارتباط بین مفاهیم شئ‌گرایی و مفاهیم قبلی، مانع درک کامل شئ‌گرا و تفکر شئ‌گرایی می‌شود. در این روش به بیان مستقیم تئوری شئ‌گرایی و مفاهیم مربوط به آن می‌پردازند، بدون اینکه مفاهیم و مشکلات تفکرات قبل بیان گردد. ما در این کتاب بر اساس روش دوم، مفهوم شئ‌گرایی را شرح می‌دهیم و در یک بخش خاص، خصوصیات روش شئ‌گرایی را با روشهای قبلی مقایسه خواهیم کرد. برای اطلاعات کاملتر به [Riel 96] مراجعه کنید. 10.1         شئ‌گرایی به عنوان یک روش جدید انسانها از زمانی که بوجود آمدند، در تلاش برای حل مسائل مختلف روزمره خود بودند. در طول گذر زمان، همراه با خواسته جدید که برای بشر بوجود می‌آید، مسائل مختلفی نیز مطرح شده و این مسائل در حال توسعه و پیجیده شدن می‌باشند. در راستای پیجیده‌تر شدن مسائل، روشهای حل مسائل نیز تغییر پیدا کرده و روشهای جدیدی ارائه می‌شوند. به عنوان مثال برای ساخت یک خانه یک طبقه، روش و ابزارهای خاصی وجود دارد. حال برای ساخت یک خانه 10 طبقه، روش و ابزار ساخت خانۀ 1 طبقه کافی نیست. همین روال برای ساخت خانه‌هایی با طبقات بیشتر نیز صادق است. در حقیقت با پیچیده‌تر شدن صورت مسئله، روشها و ابزار جدید و پیشرفته‌ای ارائه می‌شود. در توسعه سیستمهای نرم‌افزاری نیز چنین می‌باشد. از دهه 50 که ایدۀ سیستمهای نرم‌افزاری ارائه شد، روشهایی مختلفی برای توسعه آنها نیز ارائه می‌شود. با بزرگتر و پیچیده‌تر شدن سیستمهای نرم‌افزاری، روشها و ابزار جدیدتری نیز ارائه می‌شود. به عنوان مثال، سیستمهای زیر را در نظر بگیرید: 1-     نرم‌افزاری برای جمع دو عدد 2-     نرم‌افزاری برای بدست آوردن اعداد اول کمتر از 10000 3-     نرم‌افزاری برای محاسبه کوتاهترین مسیر بین شهرهای مختلف 4-     نرم‌افزاری برای نگهداری اطلاعات یک کتابخانه 5-     نرم‌افزاری برای ذخیره و بازیابی کلیه اطلاعات و عملیات موجود در یک بانک 6-     نرم‌افزاری برای ذخیره و بازیابی کلیه اطلاعات و عملیات موجود در چندین بانک 7-     نرم‌افزاری برای ذخیره و بازیابی کلیه اطلاعات و عملیات موجود در چندین سازمان 8-     و... با بزرگتر و پیچیده‌تر شدن سیستمهای نرم‌افزاری، روشهای مختلفی برای توسعه آنها بوجود می‌آید. برخی از این روشها عبارتند از: 1-     روش Code & Fix 2-     روش مبتنی بر داده[61] 3-     روش ساخت‌یافته[62] یا تابعی[63] یا مبتنی بر فرایند[64] 4-     روش شئ‌گرایی 5-     و... همانطور که قبلاً نیز اشاره شد، روشهای دیگری نیز بعد از شئ‌گرایی ارائه شده‌اند ولی در اکثر موارد، شئ‌گرایی پایه اصلی تفکرهای جدید ارائه شده می‌باشد. در ادامه این روشهای قبل از روش شئ‌گرایی را به صورت خلاصه شرح می‌دهیم. 1.10.1     روش Code & fix در این روش، توسعه دهنده یا برنامه‌نویس، برای رسیدن به سیستم مورد نظر، بر اساس تفکراتی قبلی که از مسئله دارد، شروع به کد‌نویسی می‌کند. در هر قسمت از کدنویسی که دچار مشکلی می‌شود، با تصحیح کد مورد نظر، همچنان به کدنویسی سیستم ادامه می‌دهد تا در نهایت سیستم به صورت کامل توسعه داده شود. این روش برای مسائل کوچک و ساده جوابگو خواهد بود. ولی برای مسائل بزرگ و پیچیده، به هیچ وجه جوابگو نبوده و توسعه‌دهندگان سیستم، مجبورند قبل از شروع به کدنویسی، کارهای دیگری نیز جهت شناخت بهتر سیستم انجام دهند، که باعث بوجود آمدن روشهای دیگر گردید. 2.10.1     روش مبتنی بر داده این روش مخصوص سیستمهای نرم‌افزاری می‌باشد که وظیفه اصلی سیستم، ذخیره و بازیابی اطلاعات مختلف و داده‌های سیستم می‌باشد. به عنوان مثال سیستم نرم افزاری یک کتابخانه یا یک بانک. در این ابتدا برای شناخت داده‌های مختلف ذخیره شده، تحلیلی روی آنها انجام داده، سپس کدنویسی سیستم شروع می‌شود. آقای James Martin (زمانی) اعتقاد داشتند، بعد از ارائه مدلی برای داده‌های هر سیستمی می‌توان آنرا با روش Code & Fix توسعه داد. 3.10.1     روشهای ساخت‌یافته با پیچیده‌تر شدن عملیاتهای مختلفی که در یک سیستم وجود دارد، روشهای ساخت‌یافته بوجود آمدند. در این روشها، برای شناخت عملیات سیستم، تحلیلی روی عملیات سیستم انجام داده و بعد از تحلیل داده‌های ذخیره شده، سیستم را توسعه می‌دادند. روش ساخت‌یافته چندین سال توسط توسعه‌دهندگان سیستم مورد استفاده قرار گرفت و امروزه نیز موزد استفاده قرار می‌گیرد. 4.10.1     روش شئ‌گرا با پیچیده‌تر شدن سیستمها، توسعه دهندگان سیستمهای در توسعه سیستمهای نرم‌افزاری با مشکل مواجه شدند و از روش شئ‌گرا استفاده شد. در نتیجه شئ‌گرایی به عنوان یک روش جدید توسعه سیستمهای نرم‌افزاری ارائه می‌شود. یعنی شئ‌گرایی می‌تواند بر پیچیدگی سیستمهای نرم‌افزاری جدید غلبه کند و با این روش می‌توان این سیستمها را توسعه داد، در حای که روشهای قبلی نتوانسته‌اند بر این پیچیدگی غلبه کنند. نکته قابل توجه اینست که هیچ کدام از این روشها، از بین نخواهد رفت و هر کدام در حوزه نوع سیستم خود قابل استفاده می‌باشد. به عنوان یک مثال ساده، کسی که قصد ساخت یک خانه یک طبقه ساده را دارد از روشها و ابزار موجود برای ساخت یک خانه یک طبقه استفاده می‌کند، مثلاً هیچ وقت یک تیم معماری ساختمان استخدام نمی‌کند، بلکه از روشها و ابزار ساخت خانه یک طبقه استفاده می‌کند. مقایسه مستقیم این روشها نیز، کاملاً اشتباده می‌باشد. زمانی می‌توانیم این روشها را باهم مقایسه کنیم، که سیستم را fix کنیم. یعنی یک سیستم خاص انتخاب کرده و نحوه توسعه این سیستم خاص را توسط روشهای مختلف موجود مورد بررسی قرار دهیم. روشهای موجود را می‌توان همانند جعبه ابزاری در نظر گرفت که هر کسی بر اساس نوع نیاز خود از این ابزار استفاده می‌کند و هر کدام از این ابزار برای استفاده‌های خاصی مفید می‌باشند. 11.1         شئ‌گرایی به عنوان یک Paradigm ابتدا از مفهوم Paradigm شروع می‌کنیم. لغت Paradigm از ریشه یونانی Paradeigma، به معنای لغویِ نمونه، سرمشق، مدل یا الگو[65] می‌باشد و در فلسفه و علوم بدین صورت تعریف می‌شود. یک تئوری بنیادی برای یک حوزه خاص، که از تمامی مفاهیم و واژه‌های موجود در آن حوزه استنتاج شده باشد. درنتیجه یک Paradigm برای یک حوزه خاص ارائه می‌شود و می‌توان آنرا در کلیه قسمتهای مختلف آن حوزه بکار برد. اگر چیزی به عنوان یک Paradigm در یک حوزه پذیرفته شده باشد، بدین معنی است که این Paradigm، در مورد کلیه مسائل و راه‌حلهای آن حوزه قابل استفاده است. درنتیجه می‌توان تمام مسائل موجود در آن حوزه را نیز با استفاده از این Paradigm به جواب رساند. یک Paradigm، فقط امکان حل کلیه مسائل را با استفاده از این Paradigm تضمین می‌کند و ممکن است این راه‌حل، بهینه و بهترین نباشد. شئ‌گرایی به عنوان یک Paradigm در حوزه سیستهای کامپیوتری مطرح است. درنتیجه می‌توان از شئ‌گرایی برای حل کلیه مسائل موجود در حوزه سیستمهای کامپیوتری استفاده کرد. شئ‌گرایی اولین بار در حوزه برنامه‌نویسی مطرح شد. ولی در دهه 90، روشهای تحلیل شئ‌گرا و طراحی شئ‌گرای سیستمها ارائه شدند. در همین دهه مبحث پایگاه داده‌های شئ‌گرا مطرح شده و هنوز به عنوان یک مبحث جدید در حال توسعه است. امروزه حتی برای مدل کردن سیستم‌های اطلاعاتی یا همان مدل کردن کسب‌وکار[66]، از روشهای شئ‌گرا نیز استفاده می‌کنند. در مورد مسائل دیگرِ سیستمهای کامپیوتری نیز می‌توان از روش شئ‌گرا استفاده کرد. به عنوان مثال ایده مدیریت پروژۀ شئ‌گرا مطرح شده و کارهای پژوهشی زیادی می‌توان روی آن انجام داد. در حوزه معماری سازمان[67] نیز، معماری سازمان شئ‌گرا مطرح است. برای استفاده کردن از شئ‌گرایی به عنوان یک Paradigm در یک مسئله خاص (مانند پایگاه داده) در حوزه سیستمهای کامپیوتری، چهار فاز اصلی وجود دارد. فاز اول، شناخت‌شناسی[68] یا معرفت‌شناسی مسئله می‌باشد. در این فاز به شرح کامل مسئله می‌پردازیم. سپس اثبات مفید بودنِ این کاربرد و دلایل توجیهی و ضرورت آن باید انجام شود. به عبارتی باید یک زمین حاصلخیز برای رشد تفکر جدید مهیا شود. فاز دوم، ریاضیات[69] می‌باشد. در این فاز بر اساس علم ریاضی، تئوری‌های ارائه شده در فاز شناخت‌شناسی را به صورت دقیق و کامل اثبات کنیم و دلایل قابل اثبات و سازگار برای تئوری‌های خود ارائه دهیم. برای اثبات ریاضی تئوری‌های ارائه شده، باید تئوری شئ‌گرا را به صورت یک دستگاه ریاضی تبدیل کنیم تا بتوانیم به صورت دقیق مفاهیم و تئوری‌های خود را ثابت کنیم. فاز سوم، مهندسی نرم‌افزار است. در این فاز باید دستگاه ریاضی ساخته شده برای تئوری شئ‌گرا را برای ساخت و توسعه سیستمهای پیجیده بکار بگیریم. این کار با تغییراتی در دستگاه ریاضی ساخته شده انجام می‌شود، بطوری که بتواند برای ساخت سیستمهای پیچیده بکار برده شود. فاز چهارم، تکنینکهای برنامه‌نویسی است. در این فاز بر اساس خروجی فاز قبل، اصول بنیادی و اساسی برای بدست آوردن تکنینکهای برنامه‌نویسی شئ‌گرای لازم جهت توسعه سیستم پیچیدۀ مورد نظر، تهیه می‌شود.     به عنوان مثال تئوری پایگاه داده‌های شئ‌گرا را در نظر بگیرید. برای تئوریهای قبلی مانند پایگاه داده رابطه‌ای از پایه قوی نظریه مجموعه‌های ریاضیات استفاده شده ولی برای پایگاه داده شئ‌گرا چنین چیزی نداریم. درنتیجه باید یک دستگاه ریاضی جدید برای آن تعریف شود. در اکثر دانشگاههای معروف در حال ایجاد یک پایه ریاضیات قوی برای پایگاه داده شئ‌گرا می‌باشند. برای اطلاعات کاملتر به [Edsger 00] مراجعه نمایید.   شکل 7.1  پایه‌های اصلی استفاده از شئ‌گرایی به عنوان یک Paradigm 5.   تحقیق برای استفاده از تفکر شئ‌گرایی در حوزه‌های غیر از سیستم‌های نرم‌افزاری فرایندی پیشنهاد دهید. به عنوان یک مثال ساده برای استفاده از تفکر شئ‌گرایی در حوزه مدیریت پروژه، می‌توان جدولی ارائه کرد که در ستونهای آن اصول مدیریت پروژه و در سطرهای آن اصول تفکر شئ‌گرا قرار دارند. سپس تاثیر هر یک از اصول تفکر شئ‌گرا بر اصول مدیریت پروژه بررسی شده و نتایج ثبت شود و در نهایت ایده‌ای جدید برای مدیریت پروژه شئ‌گرا ارائه شود.  12.1         خلاصه فصل  ü      سیستم مجموعه‌ای از اجزاء و رابطه‌های بین آنها می‌باشد. جزء هر چیزی می‌تواند باشد و با توجه به نوع سیستم، اسامی مختلف بجای جزء استفاده می‌شود. رابطه، وجود یک اتصال یک طرفه از یک جزء به یک جزء دیگر است. ü      تنها قسمتی از اجزاء و رابطه‌های کل یک سیستم، از منظر یک ناظر خاص اهمیت دارد. ü      پیچیدگی، تعداد یا تنوع اجزاء یا رابطه‌های یک سیستم می‌باشد. ü      شکستن یک سیستم به اجزاء و رابطه‌های تشکیل دهنده، با هدف شناخت آن را تحلیل سیستم می‌گویند. به ترکیب اجزاء و رابطه‌های بدست آمده از تحلیل و ارائه طرحی جدید برای ساخت یک سیستم جدید را طراحی آن سیستم گویند. ü      پیچیدگی توسعه سیستمهای نرم‌افزاری، مهمترین عامل بوجود آمدن تفکر شئ‌گرایی می‌باشد. ü      روح تفکر شئ‌گرایی، استفاده از تکنیکها و روشهای موجود در دنیای واقعی در توسعه سیستمهای نرم‌افزاری می‌باشد. ü      شئ‌گرایی جهت غلبه بر پیچیدگی توسعه سیستمهای نرم‌افزاری، چهار اصل اساسی تجرید، محصورسازی، پیمانه‌بندی و سلسله مراتب را معرفی می‌کند. یک سیستم شئ‌گرا است اگر هر چهار اصل موجود را رعایت کرده باشد. ü      شئ‌گرایی امروزه به عنوان یک Paradigm مطرح است. بدین معنی که در کلیه حوزه‌های توسعه سیستمهای نرم‌افزاری به عنوان یک راه‌حل مطرح شده است. به عنوان مثال، در پایگاه داده‌های شئ‌گرا سعی می‌شود از کلیه مفاهیم موجود در شئ‌گرایی استفاده شود. یا در حوزه مدیریت، سعی می‌شود بیشترین استفاده را از مفاهیم شئ‌گرایی داشته باشند. 13.1         تمرینات فصل 1-     از حوزه‌های مختلف علوم، چندین مثال برای سیستم آورده، سپس اجزاء و رابطه‌های آنها را نام ببرید.   2-     برای یک سیستم بزرگ، مثل سیستم یک کشور، چندین ناظر و منظر هر یک را نام برده و سعی کنید اجزاء و رابطه‌هایی را که از دیدگاه آنها اهمیت زیادی دارند، نام ببرید. 3-     بر اساس تعریف پیچیدگی، سیستمهایی مثال بزنید که §         فقط بر اساس نوع اجزاء زیاد پیچیده باشند. §         فقط بر اساس تعداد اجزاء زیاد پیچیده باشند. §         فقط به خاطر تعداد رابطه‌های زیاد پیچیده باشند. §         فقط به خاطر تعداد نوع رابطه‌های زیاد پیچیده باشند. 4-     چندین مسئله از حوزه‌های مختلف علوم مثال زده، سپس سعی کنید راه‌حلهای الگوریتمی و شئ‌گرا برای آنها ارائه کرده و آنها را مقایسه کنید. 5-     چه روشهای دیگری علاوه بر تجزیه الگوریتمی و تجزیه شئ‌گرا وجود دارد. این مسئله را در حوزه‌های مختلف علوم مطرح کرده، سپس اگر راه‌حل خاصی در یک حوزه وجود داشت، تاثیر آنرا در حوزه سیستمهای نرم‌افزاری بررسی کنید. 6-     آیا می‌توان یک روش جدید با ترکیب تجزیه الگوریتمی و شئ‌گرا برای نوعی از سیستمهای خاص ارائه نمود. 7-     روش تفکر بالا به پایین[70] و پایین به بالا[71] را بررسی کرده و برای چندین مسئله آنها را باهم مقایسه نمایید. 8-     چه Paradigmهای دیگری در حوزه‌های مختلف علوم مطرح است. با بررسی آنها، سعی کنید کاربردی برای هر یک از آنها در حوزه سیستمهای نرم‌افزاری پیدا کنید. 9-     مثالهای برای اصول چهارگانه شئ‌گرایی در دنیای واقعی بیاورید. 10- مثالهایی برای اصول چهارگانه در کدنویسی ساده سیستمهای نرم‌افزاری بیاورید. 11- روشهای جدید ارائه شده بعد از تفکر شئ‌گرایی را بررسی نمایید. در روشهای جدید چه اصولی معرفی می‌شود. چگونه می‌توان روشهای جدید را با روش شئ‌گرایی مقایسه نمود. سعی کنید چارچوبی برای مقایسه روشهای جدید با روش شئ‌گرایی ارائه دهید و آنها را مقایسه نمایید.