مدلسازی 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 را در سیستم داشته باشیم و همچنین ریسکهای پروژه را مدیریت کنیم.

بسیاری از سازمانهای نرم‏افزاری شروع به انجام کارهای بزرگ می‏کنند، ولی مشکل اصلی این است که آنها همانند ساختن لانه برای پرنده‏ها عمل می‏کنند (برای ساختن لانه پرنده می‏توان با تعدادی تخته و میخ و بدون نیاز به نقشه اقدام به ساخت لانه کرد).

اگر شما واقعاً می‏خواهید که نرم‏افزاری را بدون هدف و در کمترین زمان ممکن تولید کنید مشکلات این کار فقط نوشتن خود برنامه می‏باشد، ولی در واقع هدف اصلی ایجاد یک نرم‏افزار صحیح می‏باشد و پیاده‏سازی یک نرم‏افزار کارا وابسته است بر ابزار، فعالیتها و معماری که آن نرم‏افزاری استفاده می‏کند. بسیاری مواقع پروژه‏ها بصورت کوچک شروع می‏شوند ولی پس از مدتی به پروژه‏های بزرگ تبدیل می‏شوند، بخاطر آنکه آنها موفقیت کاری خودشان را در این راه قربانی می‏کنند.

نوشته : ساسان نیکوکار