ساسان نیکوکار امروزه یک سازمان نرم‏افزارى موفق سازمانى است که بتواند
بسادگى نرم‏افزارهایى را تولید کند که نیازهاى کاربران در آن دیده شده
باشد.
چنین سازمانى که بتواند چنین نرم‏افزارى را با روشها و ابزار
مؤثر و در زمان مناسب پیاده‏سازى کند، مى‏تواند در امر تجارت موفق باشد.
محصول اولیه یک تیم تولید نرم‏افزار، بهینه نمى‏باشد و شعار نمى‏دهد بلکه
مهم است که نرم‏افزارى را پیاده‏سازى کرده باشد که نیازهاى کاربران و
تجارت را برآورده سازد.
بقیه موارد حالت ثانویه به حساب مى‏آیند.
نکته مهمى در این شعار وجود دارد.
متأسفانه بسیارى از سازمانهاى نرم‏افزارى درگیر حالت ثانویه مى‏باشند.
براى پیاده‏سازى نرم‏افزارى که اهداف موردنظر را برآورده سازد، شما باید
کاربران را ملاقات کنید تا نیازهاى واقعى سیستم شما بدست آید.
مى‏توان
گفت براى اینکه شما در نهایت بتوانید نرم‏افزارى با کیفیت بالا به وجود
آورید، باید داراى افراد و ابزارى مناسب به همراه هدف مشخص و واضحى باشید.
مدل کردن، قسمت مرکزى تمامى فعالیتهایى است که پیاده‏سازان نرم‏افزارى را به سمت تولید یک محصول مناسب راهنمایى مى‏کند.
()
ما سیستم‏ها را مدل مى‏کنیم براى اینکه رفتارها و ساختارهایى را که در
سیستم خود مى‏خواهیم بصورت کتبى داشته باشیم، ما مدل مى‏کنیم تا بتوانیم
معمارى سیستم خود را کنترل کنیم و بتوانیم سیستمى را که در حال ساختن آن
مى‏باشیم بهتر درک کنیم، امکان Reuse را در سیستم داشته باشیم و همچنین
ریسکهاى پروژه را مدیریت کنیم. بسیارى از سازمانهاى نرم‏افزارى شروع به
انجام کارهاى بزرگ مى‏کنند، ولى مشکل اصلى این است که آنها همانند ساختن
لانه براى پرنده‏ها عمل مى‏کنند (براى ساختن لانه پرنده مى‏توان با تعدادى
تخته و میخ و بدون نیاز به نقشه اقدام به ساخت لانه کرد). اگر شما واقعاً
مى‏خواهید که نرم‏افزارى را بدون هدف و در کمترین زمان ممکن تولید کنید
مشکلات این کار فقط نوشتن خود برنامه مى‏باشد، ولى در واقع هدف اصلى ایجاد
یک نرم‏افزار صحیح مى‏باشد و پیاده‏سازى یک نرم‏افزار کارا وابسته است بر
ابزار، فعالیتها و معمارى که آن نرم‏افزارى استفاده مى‏کند.
بسیارى
مواقع پروژه‏ها بصورت کوچک شروع مى‏شوند ولى پس از مدتى به پروژه‏هاى بزرگ
تبدیل مى‏شوند، بخاطر آنکه آنها موفقیت کارى خودشان را در این راه قربانى
مى‏کنند.
در پروژه‏هاى کوچک (ساختن لانه پرنده) صدمات وارده کم است
ولى در پروژه‏هاى بزرگ (ساختن خانه مسکونى) نتیجه‏اش بسیار زیانبار خواهد
بود.
عناصر زیادى در موفقیت یک پروژه نقش دارد که یکى از آنها که در
همه رعایت مى‏شود، مدلسازى است. ما مدل مى‏کنیم تا کاربران تصویرى ازمحصول
نهایى را مشاهده کنند، ما حتى مدل مى‏کنیم تا ریسکهایى هایى را که بر
سرراه پروژه قرار دارد پیدا کنیم. پس مى‏توان گفت که مدلسازى در اصل یک
کار تکنیکى است. مدلسازى چیست؟ یک مدل ساده شده هستى است که وجود دارد.
در اصل مدل یک نقشه از سیستم را فراهم مى‏کند.
مدلها ممکن است دربرگیرنده جزئیات یک برنامه باشند.
پس به طور کلى مى‏توان گفت که یک مدل خوب، مدلى است که تمام عناصر درگیر
در پروژه و روابط بین آنها و نحوه اثرگذارى آنها را مشخص کند.
هر سیستمى ممکن است توسط چندین مدل شرح داده شود و در هر مدلى یک نقشه شماتیکى وجود دارد که بر تشریح سیستم مى‏پردازد.
پس با این همه چرا ما مدل مى‏کنیم؟ ما مدل مى‏کنیم تا که سیستمى را که
مى‏خواهیم پیاده‏سازى کنیم بهتر درک کنیم‏ از مدلسازى به چهار نتیجه
مى‏رسیم:
مدلها به ما کمک مى‏کنند که سیستمى را که مى‏خواهیم به آن
برسیم بهتر تصور کنیم. مدلها به ما اجازه مى‏دهند تا ساختار و رفتار سیستم
را مشخص کنیم. مدلها ما را در جهت ساخت صحیح سیستم راهنمایى مى‏کنند (براى
ما الگوهایى (Pattern) را ایجاد مى‏کنند که مى‏توانیم در پروژه‏هاى بعدى
خود از آنها استفاده کنیم. این کار باعث افزایش امکان Reuse در پروژه
مى‏شود). مدلها تصمیماتى را که در جهت کاربردى سیستم باید گرفته شوند
مستند مى‏کنند.
ما در اصل مدلها را براى سیستمهاى پیچیده ایجاد
مى‏کنیم. زیرا نمى‏توانیم آنها را یکجا تصور کنیم. انسان توانایى درک
چیزهاى پیچیده را ندارد و در درک آنها محدودیت دارد.
ولى با مدل سازى
در هر نسخه روى یک جزء از سیستم کار مى‏شود، باید توجه داشت که مدل‏سازى
مى‏تواند روى تخته، کاغذ، کارتهاى CRC و... صورت گیرد.
ولى چیزى که
مهم است مدل کردن سیستمهاى پیچیده مى‏باشد و شکستن آنها به سیستمهاى
کوچکتر که قابل درک بوده و به راحتى قابل پیاده‏سازى مى‏باشند.
اصول مدلسازى:
تجربه چهار اصل را براى مدلسازى پیشنهاد مى‏کند:
اول:
انتخاب مدلهایى که براى ساخت داراى تأثیرات کارآمد و عمیقى بر روى اینکه
چگونه مى‏توان به یک مشکل حمله کرد و چگونه مى‏توان براى آن راه‏حل پیدا
کرد مى‏باشند.
به معنى دیگر مدل خود را خوب انتخاب کنید.
یک مدل
خوب مشکلات موجود در سرراه پیاده‏سازى را تصویر مى‏کند و مسیرى را که راهى
مناسبتر از آن پیدا نمى‏کنید پیشنهاد مى‏دهد، ولى مدلهاى نامناسب شما را
به بى‏راهه راهنمایى خواهند کرد.
در تولید نرم‏افزار مدلهایى را که شما انتخاب مى‏کنید مى‏توانند تاثیر زیادى بر روى دید شما به مسائل داشته باشند.
اگر شما یک سیستمى را بعنوان پیاده‏ساز یک بانک اطلاعاتى درنظر داشته
باشید، به احتمال زیاد روى روابط موجودیتى که رفتارشان همانند triggerها و
Store Procedureها مى‏باشد تمرکز خواهید کرد.
اگر شما سیستمى را
بعنوان یک آنالیست مشاهده کنید، مدلها را به احتمال زیاد از دید الگوریتم
و جریان داده‏هایى که بین پروسس‏ها در حال حرکت مى‏باشند بررسى مى‏کنید.
پس نتیجه مى‏شود که هر مدل دیدى به سیستم ما مى‏دهد که این دیدها، گوناگون بوده و هزینه و سودهاى خاص خود را دارند.
دوم:
هر مدلى بسته به شرایط باید از لایه‏هاى گوناگونى بررسى شود.
این مسئله هم در دنیاى واقعى و هم در صنعت نرم‏افزار صادق است. گاهى یک
مدل سریع و راحت همانند User Interface مشخص مى‏کند که ما نیازمند چه
مى‏باشیم. این مسئله در تعیین Platform، شبکه و مسائلى از این قبیل حائز
اهمیت مى‏باشد.
بهترین مدلها آنهایى هستند که اجازه دهند شما جزئیات و
وابستگى‏هاى سیستم خود را بشناسید و متوجه شوید که به کدام علت به آنها در
سیستم خود نیازمند باشید.
در بسیارى از مدلها یک طراح یا کاربر
مى‏خواهد بر روى «چه چیز» متمرکز شود و یک پیاده‏ساز مى‏خواهد بر روى «چه
طور» تمرکز کند، هر دوى اینها مى‏خواهند یک سیستم را در لایه‏ها و زمانهاى
مختلف تصویر کنند.
سوم:
بهترین مدلها آنهایى هستند که به واقعیت نزدیک و در ارتباط با آن باشند.
مدل مناسب باید با دنیاى واقعى مرتبط باشد و مشخص کند که در کدام قسمتها داراى ضعف مى‏باشد.
در اصل تمامى مدلها حالت ساده شده‏اى از دنیاى واقعى هستند، نکته اصلى در
مدل این است که جزئیات اصلى و مهم سیستم از قلم انداخته نشده باشد.
در نرم‏افزار، نقطه ضعف در از بین رفتن ارتباط بین مدل آنالیز شده و مدلى که طراحى مى‏شود مى‏باشد.
این شکاف بین مدلها باعث ایجاد شکافهاى بیشترى در پروژه در زمانهاى مختلف خواهد بود.
چهارم:
هیچ مدلى به تنهایى کارایى کافى ندارد.
هر سیستم بزرگى بهتر است که داراى خط مشیى باشد که به سمت یک مجموعه از مدلهاى کوچک با کمترین وابستگى حرکت کند.
اگر شما سازنده یک ساختمان باشید، هیچ نقشه‏اى وجود ندارد که تمام جزئیات را براى شما مشخص کرده باشد.
در حداقل شرایط شما به چندین نقشه مانند برق ساختمان، طبقات، لوله‏کشى و... نیازمند باشید.
شاید جمله سؤال برانگیز، وجود کلمه «با کمترین وابستگى» در اصل چهارم مى‏باشد.
این به معناى داشتن مدلهایى است که مى‏توانند بطورى مستقل و جداگانه ساخته شده و استفاده شوند.
اما هنوز هم بر همدیگر وابستگى دارند.
مثلاً در نقشه ساختمان، نقشه برق ساختمان یک نقشه جداگانه و کامل مى‏باشد
که مى‏تواند پیاده‏سازى شود، ولى هنوز بر نقشه بناى ساختمان وابستگى دارد
زیرا با تغییر در آن ممکن است نقشه برق نیز دچار تغییر شود.
این
واقعیت در سیستمهاى نرم‏افزارى شى‏ءگرا صادق است. براى درک معمارى چنین
سیستمهایى شمانیازمند چندین View بهم مرتبط مى‏باشید که شامل موارد زیر
مى‏باشد.
- Usecase View (نیازمندیهاى سیستم را مشخص کرده و نمایش
مى‏دهد). - Design View (پیداکردن مشکلات سیستم و مشخص کردن راه‏حلهاى
مربوط به آنها). - Process View (پردازش Threadهاى موجود در سیستم را در
قالب توزیع شده مدل مى‏کند). - Development View (پیاده‏سازى و اداره کردن
درک فیزیکى سیستم را برعهده دارد). - Deployment View (بر روى مهندسى و
تکنولوژى گسترش برنامه متمرکز مى‏باشد). هر کدام از دیدها ممکن است داراى
ساختار گوناگونى باشند ولى درمجموع همه آنها نقشه یک سیستم نرم‏افزارى را
نشان مى‏دهند.
البته باید توجه داشت که در سیستمهاى گوناگون هر کدام از این مدلها ممکن است داراى اهمیت بیشترى نسبت به دیگر مدلها باشند.
مثلاً در Graphic User interface(GUI) دیدهاى Usecase مهم است. در
سیستمهاى Realtime دید پردازشى مهم است و در برنامه‏هاى تست و Web دید
پیاده‏سازى و گسترش برنامه از اهمیت بالایى برخوردار است. امروزه یک
سازمان نرم‏افزارى موفق سازمانى است که بتواند بسادگى نرم‏افزارهایى را
تولید کند که نیازهاى کاربران در آن دیده شده باشد.
چنین سازمانى که
بتواند چنین نرم‏افزارى را با روشها و ابزار مؤثر و در زمان مناسب
پیاده‏سازى کند، مى‏تواند در امر تجارت موفق باشد.
محصول اولیه یک تیم
تولید نرم‏افزار، بهینه نمى‏باشد و شعار نمى‏دهد بلکه مهم است که
نرم‏افزارى را پیاده‏سازى کرده باشد که نیازهاى کاربران و تجارت را
برآورده سازد.
بقیه موارد حالت ثانویه به حساب مى‏آیند.
نکته مهمى در این شعار وجود دارد.
متأسفانه بسیارى از سازمانهاى نرم‏افزارى درگیر حالت ثانویه مى‏باشند.
براى پیاده‏سازى نرم‏افزارى که اهداف موردنظر را برآورده سازد، شما باید
کاربران را ملاقات کنید تا نیازهاى واقعى سیستم شما بدست آید.
مى‏توان
گفت براى اینکه شما در نهایت بتوانید نرم‏افزارى با کیفیت بالا به وجود
آورید، باید داراى افراد و ابزارى مناسب به همراه هدف مشخص و واضحى باشید.
مدل کردن، قسمت مرکزى تمامى فعالیتهایى است که پیاده‏سازان نرم‏افزارى را به سمت تولید یک محصول مناسب راهنمایى مى‏کند.
ما سیستم‏ها را مدل مى‏کنیم براى اینکه رفتارها و ساختارهایى را که در
سیستم خود مى‏خواهیم بصورت کتبى داشته باشیم، ما مدل مى‏کنیم تا بتوانیم
معمارى سیستم خود را کنترل کنیم و بتوانیم سیستمى را که در حال ساختن آن
مى‏باشیم بهتر درک کنیم، امکان Reuse را در سیستم داشته باشیم و همچنین
ریسکهاى پروژه را مدیریت کنیم. بسیارى از سازمانهاى نرم‏افزارى شروع به
انجام کارهاى بزرگ مى‏کنند، ولى مشکل اصلى این است که آنها همانند ساختن
لانه براى پرنده‏ها عمل مى‏کنند (براى ساختن لانه پرنده مى‏توان با تعدادى
تخته و میخ و بدون نیاز به نقشه اقدام به ساخت لانه کرد). اگر شما واقعاً
مى‏خواهید که نرم‏افزارى را بدون هدف و در کمترین زمان ممکن تولید کنید
مشکلات این کار فقط نوشتن خود برنامه مى‏باشد، ولى در واقع هدف اصلى ایجاد
یک نرم‏افزار صحیح مى‏باشد و پیاده‏سازى یک نرم‏افزار کارا وابسته است بر
ابزار، فعالیتها و معمارى که آن نرم‏افزارى استفاده مى‏کند.
بسیارى
مواقع پروژه‏ها بصورت کوچک شروع مى‏شوند ولى پس از مدتى به پروژه‏هاى بزرگ
تبدیل مى‏شوند، بخاطر آنکه آنها موفقیت کارى خودشان را در این راه قربانى
مى‏کنند