در مقاله قبلی در مورد استفاده از ابزار فلسفه در نرم افزار صحبت کردیم و امروز میخام در مورد اساس های طراحی نرم افزار صحبت کنم. هدف ساخت یک بیس تئوری در طراحی پترن های معماری نرم افزار هست.
پیچیدگی و تغییر
نمیدونم مقاله No Silver Bullet آقای فردی بروک رو خوندین یا خیر، یکی از مقالاتی که از طبیعت نرم افزار بحث میکنه همینه . در دانشگاهای تراز اول نرم افزار در جهان مطلقا این مقاله رو میگن بخونید! ایشون از پدرهای دنیای نرم افزار هستند و خیلی ها به مقاله ایشون رفرنس میدن و بنده هم امروز به ایشون یکسری چیزی هارو رفرنس خواهم داد.
این پدر میگه نرم افزار دارای چهار صفت اصلی هست، وقتی از کلمه اصل استفاده میکنه یعنی صفات غیر اصلی هم دارد و ما قبلا بحث کردیم در مقاله قبلی . آنچیزی که تعیین موجودیت میکنه یه صفت اصلی هست مثل تفکر کردن انسان که منحصر به فرد به انسان هست ولی داشتن دست و پا منحصر به انسان نیست چون حیوانات هم دست و پا دارند، از دید فلسفی (ارسطو) هم همینه چیزی یا رفتاری یا صفتی که فقط مربوط به اون چیز هست در حقیقت تعریف اون چیز میشه در غیر این صورت اون صفت فرعی هست. البته اسلام هم همین مفهموم رو تعریف میکنه نفس آن چیزی است که تعیین موجودیت می کند در ظاهر و باطن و نشانه اش این است که خواسته دارد(آیه 53 یوسف). در کل اگر از اون چیز موجودیت های اصلی رو بگیریم اون چیز دیگه خودش نیست مثل گرفتن قدرت تحلیل و تفکر از انسان.
نرم افزار نسبت به دیگر مهندسی ها خیلی پیچیده هست چون درای حالت های خیلی زیادی هست و قابل تحلیل از هر بعد نیست حتی قابل تست هم از هر بعد نیست، نرم افزار خیلی زیاد تغییر میکنه اینو میتونید تو نرم افزارها یا سایت ها ببینید که هر ماه یا هر هفته یکسری چیزها تغییر میکنه یا یه آپشن جدیدی به نرم افزار اضافه میشه یا ورژن جدیدی ازش میاد، نرم افزار قابل دیدن نیست چون انتزاعی هست و مورد آخر نرم افزار نسبت به شرایط موجود سازگار هست و قابلیت سازگاری بالایی دارد.
نرم افزار قابل دیدن نیست چون انتزاعی هست مثل هنر، من وقتی میگم باید کلاس شما قابل استفاده مجدد باشه دارم از یه مفهوم صحبت میکنم که قابل دیدن نیست و فکری هست و چیزهای فکری معمولا قابل دیدن نیستن . وقتی از دید فلسفی این 4 مورد رو نگاه میکنی قابل دیده نبودن و سازاگاری بالا داشتن رو کنار بگذاریم چیز زیادی نمی مونه ازش چون قابل دیده نبودنش مربوط به پیچیده بودنش هست، یعنی نرم افزار یه چیز فیزیکی نیست و چیزی که فیزیکی نباشد درکش سخت هست و قابل دیدن نیست. سازگاری هم باز از دل قابل تغییر بودن میاد بیرون و توی دستمون دوتا صفت اصلی میمونه: پیچیدگی و تغییر
پیچیدگی و زیاد قابل تغییر بودن نرم افزار
شاید تا الان متوجه شده باشید چرا دارم از این موراد بحث میکنم، چون پترن های معماری یا دیزاین پترن ها یه هدف دارن : پیچیدگی رو بیارن پایین و تغییر پذیر بودنش رو ارضا کنند.
پیچیدگی
چون نرم افزار یه چیز انتزاعی هست و قابل دیدن نیست و فکری هست پیچیده هست، هر چیزی که چنین صفاتی رو داشته باشه پیچیده هست و تنها نرم افزار نیست . وقتی میگیم انتزاعی هست یعنی محدودیت های فیزیکی ندارد و این کارو سخت میکنه . در یک سیستم 64 بیتی 2 به توان 64 حالت وجود دارد. توی یک کانتکست یه متغیر عدد هست توی کانتکست دیگه یه رشته هست و نسبت به اون باید رفتارهایی رو توسعه بدی، وقتی داخل یک رشته نام محصول رو مینویسی باید کنترل کنی، چون رشته محدودیت نداره میتونه داخلش میلیاردها کلمه دیگه بیاد و نام محصول با عدد یکی نیست پس باید کنترل بشه و این میخاد بگه نرم افزار پیچیده هست، مثل ماشین نیست که بری لاستیک تریلر رو بیاری و بخای بندازی روی پراید، اصلا اجازه نمیده ولی توی مهندسی نرم افزار محدودیت وجود نداره و چنین اجازه ای برا اثر طراحی اشتباه ممکن هست، حین اجرا شدن میبینی اشتباه کردی چون قابل دیدن نیست... در چرخه حیات نرم افزار راحترین قسمتش کد نویسی و توسعه هست، چون تنها جایی که نرم افزار قابل لمس هست قسمت توسعه هست، کد نویس با کامپایلر سروکار داره و کامپایلر قوانین سفت سختی رو میگذاره، یا وقتی آنالیست یه قسمتی رو میگه بنویس برنامه نویس حین نوشتن متوجه میشه else شرط آنالیز نشده و همون لحظه میتونه ببینه چیزی که آنالیست ندیده، آنالیست با انسان ها سروکار داره و کاربر هر چیزی رو میتونه بخاد و قسمت آنالیز چرخه نرم افزار خیلی خیلی سختر هم هست. وقتی میگیم نرم افزار رو باید بزرگ کنیم چون جواب درخواست های مارو نمیده مثل لپ تاپ نیست که بری رمش رو زیادی کنی یا هاردش رو زیاد کنی تا بزرگ بشه!!! نرم افزار این مدلی بزرگ نمیشه نمیتونی بیای داخل یک کلاس دو سه تا ایف دیگه بنویسی و بگی بزرگش کردم یا بیای از اون کلاس چنتا کپی کنی بگی بزرگش کردم، توی نرم افزر کلا جاهایی که مشابه هستن رو ما یکیش میکنیم، اگر بخایم نرم افزار رو بزرگ کنیم، یا یه سرویس جدید خلق میکنیم، یا یه کامپوننت جدیدی که در سیستم نیست رو خلق میکنیم ....
نکته :وقتی از پیچیدگی صحبت میکنیم منظور پیچیدگی الگوریتمی نیست، منظور پیچیدگی ساختاری و رفتاری هست، هزاران آبجکت داریم و اینا باید باهم در ارتباط باشند ما باید طوری این ارتباط رو بچینیم که حالت بهینه داشته باشه نه که هر آبجکتی در ارتباط با دیگر آبجکت ها باشه, باید راه حلی پیدا کنیم که با کمترین ارتباط آبجکت ها بتونن کار کنند.
Robert E. Wood, 1986 "Task Complexity: Definition of The Construct"
آقای وود مهندس صنعت هستند، در یه مقاله در مورد پیچیدگی کارها نوشته که خیلی از رشته های مهندسی مختلف بهش رفرنس میدن و بنده هم در این مقاله بهش رفرنس میدم. در دنیای مهندسی مدل ایشون میگیرن و بر اساس این مدل تعریف شده پیچیدگی یک کارو در میارن، ما هم میخاییم از روی تعریف آقای وود پیچیدگی نرم افزار رو ببینیم.
این پدر میگه که پیچیدگی کار رو میشه به سه قسمت تقسیم کرد.
پیچیدگی تسک ها هر چقدر زیاد باشد به همان اندازه هم محصول نهایی پیچیده هست، پیچیدگی مراحل ساخت یه کفش با بمب اتم یکی نیست چون محصول نهایی که بشه کفش خیلی چیز ساده ای نسبت به بمب اتم هست.
پیچیدگی قسمت های مجزای یک سیستم مثلا توی مثال کفش پیچیدگی قسمت قالب گیری و یا دوختن در پیچیدگی محصول نهایی تاثیر مستقیم دارد.
ورودی های مورد نیاز برای به اتمام رسیدن این کارها و رفتارهای اتمیک، هر چقدر ورودی های قسمت های اتمیک مراحل ساخت زیاد باشد به همان اندازه خود اون زیر مجموعه های اتمیک پیچیده هست. مثلا برای دوختن کفش ورودی نخ هست حالا این ورودی ها هر چقدر پیچیده باشند خود اون قسمت مجزا هم پیچیده تر میشه و هر چقدر هم این قسمت های مجزا پیچیده تر باشند محصول نهایی پیچیده تر میشه.
حالا در دنیای نرم افزار اگر بخاییم این مدل رو بررسی کنیم میتونیم در یه سیستم فروشگاه اینترنتی بگیم که کل سیستم اعم از قسمت (کیف پول، سبد خرید، جستجوها) محصول نهایی هست که بهش میگیم سیستم فروشگاه آنلاین و اجزای اتمیک این میشه قسمت جستجو که باز خودش میتونه داخلش اجزای اتمیک داشته باشه مثل گرفتن دیتا و گرفتن دیتا نیاز به ورودی داره که همون فیلترها هستن.
محصول : فروشگاه اینترنتی
اجزای اتمیک این محصول: کیف پول - جستجوی محصول
ورودی ها: دادن پارامترهای فیلتر مثل محصولاتی که قیمتش اینقدر باشه.
حالا وقتی بتونیم پیچیدگی تمام وظایف در پیچیدگی اجزای اتمیک ها در ورودی هاش حساب کنیم میشه پیچیدگی محصول نهایی . وقتی به این مدل فروشگاه آنلاین نگاه میکنیم تنها قسمت ورودی های جستجو دارای چند صد پارامتر هست مثل جستجو بر اساس نام، قیمت و... این مدل هم اثبات میکنه ذات نرم افزار پیچیده هست.
Static Complexity and Coordinative Complexity
پیچیدگی جداول و پیچیدگی توابع و پیچیدگی کلاس ها در پیچیدگی ورودی های تک تک این اجزا رو میگیم پیچیدگی کامپوننت. تازه این قسمت استاتیک موضوع هست، یه پیچیدگی هم نحوه ارتباط این اجزا باهم هست که سختی کار این هست که بهش میگیم پیچیدگی هماهنگی یا کوردیناتیو
در مقاله بعدی کوهیژن یا همان انسجام رو به دست میگیرم و بحث پیچیدگی و انسجام چه ربطی به هم دارند رو بررسی میکنیم تا ببینیم چوری میتونیم این پیچیدگی رو بیاریم پایین تا قابل تغییر به راحتی باشد.
