آبجی
24th May 2010, 01:21 AM
ساسان نيكوكار امروزه يك سازمان نرمافزارى موفق سازمانى است كه بتواند بسادگى نرمافزارهايى را توليد كند كه نيازهاى كاربران در آن ديده شده باشد.
چنين سازمانى كه بتواند چنين نرمافزارى را با روشها و ابزار مؤثر و در زمان مناسب پيادهسازى كند، مىتواند در امر تجارت موفق باشد.
محصول اوليه يك تيم توليد نرمافزار، بهينه نمىباشد و شعار نمىدهد بلكه مهم است كه نرمافزارى را پيادهسازى كرده باشد كه نيازهاى كاربران و تجارت را برآورده سازد.
بقيه موارد حالت ثانويه به حساب مىآيند.
نكته مهمى در اين شعار وجود دارد.
متأسفانه بسيارى از سازمانهاى نرمافزارى درگير حالت ثانويه مىباشند.
براى پيادهسازى نرمافزارى كه اهداف موردنظر را برآورده سازد، شما بايد كاربران را ملاقات كنيد تا نيازهاى واقعى سيستم شما بدست آيد.
مىتوان گفت براى اينكه شما در نهايت بتوانيد نرمافزارى با كيفيت بالا به وجود آوريد، بايد داراى افراد و ابزارى مناسب به همراه هدف مشخص و واضحى باشيد.
مدل كردن، قسمت مركزى تمامى فعاليتهايى است كه پيادهسازان نرمافزارى را به سمت توليد يك محصول مناسب راهنمايى مىكند.
ما سيستمها را مدل مىكنيم براى اينكه رفتارها و ساختارهايى را كه در سيستم خود مىخواهيم بصورت كتبى داشته باشيم، ما مدل مىكنيم تا بتوانيم معمارى سيستم خود را كنترل كنيم و بتوانيم سيستمى را كه در حال ساختن آن مىباشيم بهتر درك كنيم، امكان 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 را در سيستم داشته باشيم و همچنين ريسكهاى پروژه را مديريت كنيم. بسيارى از سازمانهاى نرمافزارى شروع به انجام كارهاى بزرگ مىكنند، ولى مشكل اصلى اين است كه آنها همانند ساختن لانه براى پرندهها عمل مىكنند (براى ساختن لانه پرنده مىتوان با تعدادى تخته و ميخ و بدون نياز به نقشه اقدام به ساخت لانه كرد). اگر شما واقعاً مىخواهيد كه نرمافزارى را بدون هدف و در كمترين زمان ممكن توليد كنيد مشكلات اين كار فقط نوشتن خود برنامه مىباشد، ولى در واقع هدف اصلى ايجاد يك نرمافزار صحيح مىباشد و پيادهسازى يك نرمافزار كارا وابسته است بر ابزار، فعاليتها و معمارى كه آن نرمافزارى استفاده مىكند.
بسيارى مواقع پروژهها بصورت كوچك شروع مىشوند ولى پس از مدتى به پروژههاى بزرگ تبديل مىشوند، بخاطر آنكه آنها موفقيت كارى خودشان را در اين راه قربانى مىكنند
چنين سازمانى كه بتواند چنين نرمافزارى را با روشها و ابزار مؤثر و در زمان مناسب پيادهسازى كند، مىتواند در امر تجارت موفق باشد.
محصول اوليه يك تيم توليد نرمافزار، بهينه نمىباشد و شعار نمىدهد بلكه مهم است كه نرمافزارى را پيادهسازى كرده باشد كه نيازهاى كاربران و تجارت را برآورده سازد.
بقيه موارد حالت ثانويه به حساب مىآيند.
نكته مهمى در اين شعار وجود دارد.
متأسفانه بسيارى از سازمانهاى نرمافزارى درگير حالت ثانويه مىباشند.
براى پيادهسازى نرمافزارى كه اهداف موردنظر را برآورده سازد، شما بايد كاربران را ملاقات كنيد تا نيازهاى واقعى سيستم شما بدست آيد.
مىتوان گفت براى اينكه شما در نهايت بتوانيد نرمافزارى با كيفيت بالا به وجود آوريد، بايد داراى افراد و ابزارى مناسب به همراه هدف مشخص و واضحى باشيد.
مدل كردن، قسمت مركزى تمامى فعاليتهايى است كه پيادهسازان نرمافزارى را به سمت توليد يك محصول مناسب راهنمايى مىكند.
ما سيستمها را مدل مىكنيم براى اينكه رفتارها و ساختارهايى را كه در سيستم خود مىخواهيم بصورت كتبى داشته باشيم، ما مدل مىكنيم تا بتوانيم معمارى سيستم خود را كنترل كنيم و بتوانيم سيستمى را كه در حال ساختن آن مىباشيم بهتر درك كنيم، امكان 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 را در سيستم داشته باشيم و همچنين ريسكهاى پروژه را مديريت كنيم. بسيارى از سازمانهاى نرمافزارى شروع به انجام كارهاى بزرگ مىكنند، ولى مشكل اصلى اين است كه آنها همانند ساختن لانه براى پرندهها عمل مىكنند (براى ساختن لانه پرنده مىتوان با تعدادى تخته و ميخ و بدون نياز به نقشه اقدام به ساخت لانه كرد). اگر شما واقعاً مىخواهيد كه نرمافزارى را بدون هدف و در كمترين زمان ممكن توليد كنيد مشكلات اين كار فقط نوشتن خود برنامه مىباشد، ولى در واقع هدف اصلى ايجاد يك نرمافزار صحيح مىباشد و پيادهسازى يك نرمافزار كارا وابسته است بر ابزار، فعاليتها و معمارى كه آن نرمافزارى استفاده مىكند.
بسيارى مواقع پروژهها بصورت كوچك شروع مىشوند ولى پس از مدتى به پروژههاى بزرگ تبديل مىشوند، بخاطر آنكه آنها موفقيت كارى خودشان را در اين راه قربانى مىكنند