پایگاه علمی سعید سان دانلود رایگان مقالات علمی کنفرانس و ژورنال
modeling چیست؟
امروزه یک سازمان نرمافزارى موفق سازمانى است که بتواند بسادگى نرمافزارهایى را تولید کند که نیازهاى کاربران در آن دیده شده باشد. چنین سازمانى که بتواند چنین نرمافزارى را با روشها و ابزار مؤثر و در زمان مناسب پیادهسازى کند، مىتواند در امر تجارت موفق باشد. محصول اولیه یک تیم تولید نرمافزار، بهینه نمىباشد و شعار نمىدهد بلکه مهم است که نرمافزارى را پیادهسازى کرده باشد که نیازهاى کاربران و تجارت را برآورده سازد. بقیه موارد حالت ثانویه به حساب مىآیند. نکته مهمى در این شعار وجود دارد. متأسفانه بسیارى از سازمانهاى نرمافزارى درگیر حالت ثانویه مىباشند. براى پیادهسازى نرمافزارى که اهداف موردنظر را برآورده سازد، شما باید کاربران را ملاقات کنید تا نیازهاى واقعى سیستم شما بدست آید. مىتوان گفت براى اینکه شما در نهایت بتوانید نرمافزارى با کیفیت بالا به وجود آورید، باید داراى افراد و ابزارى مناسب به همراه هدف مشخص و واضحى باشید.
مدل کردن، قسمت مرکزى تمامى فعالیتهایى است که پیادهسازان نرمافزارى را به سمت تولید یک محصول مناسب راهنمایى مىکند. ما سیستمها را مدل مىکنیم براى اینکه رفتارها و ساختارهایى را که در سیستم خود مىخواهیم بصورت کتبى داشته باشیم، ما مدل مىکنیم تا بتوانیم معمارى سیستم خود را کنترل کنیم و بتوانیم سیستمى را که در حال ساختن آن مىباشیم بهتر درک کنیم، امکان 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 را در سیستم داشته باشیم و همچنین ریسکهاى پروژه را مدیریت کنیم.
بسیارى از سازمانهاى نرمافزارى شروع به انجام کارهاى بزرگ مىکنند، ولى مشکل اصلى این است که آنها همانند ساختن لانه براى پرندهها عمل مىکنند (براى ساختن لانه پرنده مىتوان با تعدادى تخته و میخ و بدون نیاز به نقشه اقدام به ساخت لانه کرد).
اگر شما واقعاً مىخواهید که نرمافزارى را بدون هدف و در کمترین زمان ممکن تولید کنید مشکلات این کار فقط نوشتن خود برنامه مىباشد، ولى در واقع هدف اصلى ایجاد یک نرمافزار صحیح مىباشد و پیادهسازى یک نرمافزار کارا وابسته است بر ابزار، فعالیتها و معمارى که آن نرمافزارى استفاده مىکند. بسیارى مواقع پروژهها بصورت کوچک شروع مىشوند ولى پس از مدتى به پروژههاى بزرگ تبدیل مىشوند، بخاطر آنکه آنها موفقیت کارى خودشان را در این راه قربانى مىکنند.