PDA

توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : مقاله مدلسازى (Modeling) چيست؟



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

استفاده از تمامی مطالب سایت تنها با ذکر منبع آن به نام سایت علمی نخبگان جوان و ذکر آدرس سایت مجاز است

استفاده از نام و برند نخبگان جوان به هر نحو توسط سایر سایت ها ممنوع بوده و پیگرد قانونی دارد