- یادگیری متد object- oriented برنامه نویسی شی گرا و visual modeling (مدلسازی بصری)
- بررسی انواع نمادهای گرافیکی
- نگاهی به انواع نمودارهای (UML Diagrams) UML
- توسعه نرم افزار با استفاده رز مدلسازی بصری (visual modeling)
مقدمه ای بر متد object- oriented (شی گرایی)
در متد شی گرایی (0.0) برنامه به قطعات بسیار کوچک یا آبجکت هایی تقسیم میشود که تا اندازه ای مستقل از یکدیگرند مانند ساختمانی از بلوک ها.
در اولین گام تعدادی آبجکت های اساسی (انوع مختلف بلوک ها) را بسازید یا به دست آزمایشی آورید. اولین باری که شما این بلوک های ساختمانی را دارید, میتوانید آنها را کنار هم گذاشته تا قصرتان را بسازید. به محض اینکه تعدادی آبجکت های اساسی در دنیای کامپیوتر ساختید یا به دست آورید میتوانید به سادگی آنها را کنار هم بگذارید تا برنامه های جدید را ایجاد نمایید. یکی از امتیازات اساسی متد شی گرایی این است که میتوانید یک بار component (اجزا) را ساخته و بارها و بارها از آنها استفاده کنید. درست مانند زمانی که میتوانید یک بلاک ساختمانی را در یک قصر, یک خانه یا یک سفید فضایی دوباره استفاده کنید, میتوانید از یک قطعه طرح یا کد شی گرایی در یک سیستم حسابداری, یک سیستم بازرگانی یا یک سیستم پردازش سفارش استفاده مجدد نمایید.
تفاوت شی گرایی با روش سنتی: در روش سنتی, روش توسعه به همراه اطلاعاتی که سیستم نگهداری خواهد کرد به خودتان وابسته است. در این روش پایگاه داده بر اساس نیازهای اطلاعاتی کار بران طراحی میکنیم و صفحاتی تهیه میکنیم تا اطلاعات را بگیرد, و گزارشاتی را چاپ میکنیم تا اطلاعات را برای کاربر نمایش دهد. یعنی بر روی اطلاعات متمرکز میشویم و کم توجه میکنیم که چه کاری با این اطلاعات انجام شده است یا رفتار سیستم چگونه است. این روش data- centric (مبتنی بر داده) نامیده شده است. مدلسازی data- centric مخصوص طراحی پایگاه داده و گرفتن اطلاعات خیلی سهم میباشد, اما انتخاب این روش در زمان طراحی برنامه های تجاری با مشکلاتی همراه است. یک چالش بزرگ این است که در خواهشهای سیستم چندین بار تغییر خواهند کرد.
سیستمی که روش data- centric استفاده مینماید, میتواند به آسانی تغییر در پایگاه داده را مدیریت نماید. اما اجرای تغییرات در قوانین تجاری یا رفتار (behavior) سیستم آن قدر آسان نمی باشد.
با استفاده از متد شی گرایی هم بر اطلاعات و هم بر رفتار متمرکز شویم.
مزیت این انعطاف پذیری با طراحی یک سیستم شی گرایی به خوبی شناخته شده است.
اصول شی گرایی عبارتند از: نهان سازی (Encapsulation), وراثت (Inheritance) و چند ریختی (Polymorphism)
Enlopsulation (نهان سازی)
در سیستم های شی گرایی, اطلاعات و رفتارها را در یک آبجکت بسته بندی میکنیم. این مطلب در قالب اطلاعات Encapsulation (پنهان سازی) ارجاع داده شده است و یا میتوانیم برنامه را به بخشهای کوچکی از توابع وابسته, تقسیم کنیم. مثلا یک حساب بانکی شامل: شماره حساب, تراز جاری, نام مشتری, آدرس., نوع حساب, نرخ بهره و تاریخ باز کردن حساب میباشد. رفتارهایی هم برای یک حساب بانک داریم مانند: باز کردن حساب, بستن حساب, به حساب گذاشتن, برداشت از حساب, تغییر نوع حساب, تغییر مشتری و تغییر آدرس ما این اطلاعات و رفتارها را باهم در یک آبجکت account پنهان میکنیم. در نتیجه, همه تغییرات سیستم بانکی تاثیرات اعمال شده به سیستم را محدود میکند. یک مفهوم مشابه نهان سازی,Information Hiding است, پنهان سازی اطلاعات توانایی است که جزئیات مبهم یک آبجکت را در نیای خارج پنهان مینماید. دنیای خارج به معنی هر چیزی از خارج از همان آبجکت دست حتی اگر چه دنیای خارج شامل بقیه سیستم باشد Inheritance (وراثت)
در سیستم های شی گرا وراثت به شما اجازه میدهد تا آبجکت های جدید را بر پای ابجکت های قدیمی ایجاد کنید. آبجکت CHILD ویژگی هایی یک آبجکت PARENT را به ارث میبرد.
یکی از مزایای اصل وراثت، سهولت در نگهداری است. وقتی چیزی تغییر میکند و بر همه تاثیر می گذارد، فقط آبجکت والد نیاز به تغییر دارد و آبجکت های فرزند به طور خورکار تغییرات را به ارث می برند. مثلا در طبعیت، اگر پستانداران به طور ناگهانی خونسرد شوند، فقط آبجکت پستانداران (mamaal) باید تغییر نماید. در یک سیستم بانکداری ممکن است از وراثت برای انواع مختلفی از حسابهایی که داریم استفاده کنیم.
این نوع مختلف حسابها شباهتهایی نیز دارند. هر کدام دارای یک شماره حساب، نرخ بهره و نام مالک میباشند بنابراین میتوانیم یک آبجکت والد بنام account (حساب) را ایجاد نماییم تا ویژگی های مشترک همه این حسابها را نگهداری میکنیم آبجکت های فرزند (child) میتوانند علاوه بر ویژگی هایی که به ارث برده اند، ویژگی ها منحصر به فرد خودشان راداشته باشند، مثلا حساب اعتباری یک حد موجودی و حداقل میزان پرداخت را خواهد داشت. سپرده گذاری نیز دارای یک موعد پرداخت میباشد.
تغییرات آبجکت والد بر روی همه فرزندان اثر خواهد گذاشت اما بچه ها آزاد هستند که بدون بر هم زدن آرامش فرزند دیگر یا والدشان تغییر نمایند.
Polymorphism (چند درختی)
سومین اصلی شی گرایی، ploymor phism است که به این معنی است که شکل ها یا پیامدهای زیادی از یک تابع ویژه را داشته باشیم. همانند وراثت، چند ریختی نیز در دنیای طبیعی دید میشود. چند ریختی در اصطلاحات یک سیستم شی گرایی به این معنی است که ما میتوانیم بسیاری از رخداد ها یا پیامدهای یک عمل ویژه را داشته باشیم.
مثلا ممکن است یک سیستم رسم اشکال گرافیکی را بسازیم.
مدلسازی بصری (visual modeling) چیست؟
یک طرح کلی به شما کمک میکند تا قبل از اینکه سیستم را بسازید آن را طراحی نمایید و در این صورت سیستم میتواند حتی در مقابل کوهی از تغییرات درخواست، مقاومت نماید. پس از جمع آوری درخواستهای خود، آن ها را تبدیل به کد مینمایید با تبدیل رسمی درخواستها به کد، میتوانید مطمئن شوید که واقعا درخواستها به وسیله که مطرح شده اند و آن کد میتواند به آسانی راه برگشت به درخواستها را طی کند این پردازش modeling (مدلسازی) نامیده شده است.
نتیجه پردازش مدلسازی این توانایی است که نیازهای تجاری را به درخواستهایی تبدیل کند تا در کد به صورت مدل در آید و آن را دوباره برگردند بدون اینکه درطول راه چندی گم شود.
مدلسازی بصری (visual modeling) پردازش گرفتن اطلاعات از مدل است و آن را با استفاده از مجموعه ای از عناصر گرافیکی استاندارد به صورت گرافیکی نشان میدهد. هدف اصلی مدلسازی بصری، ارتباط میان کاربران، برنامه نویسان، تحلیلگران، آزمایش کننده ها، مدیران و هر شخص دیگری که با پروژه در گیر شده است میباشد بعد از ایجاد این مدلها، میتوانیم آنها را به همه بخشهای وابسته نشان دهیم و آن بخشها میتوانند اطلاعات را از مدل به دست آورند. در مدلسازی بصری از نمادهای گرافیکی (مثل object modeling technolohy oM T, Booch تکنولوژی مدلسازی شی و unified Modeling Language زبان مدلسازی یکپارچه) برای نشان دادن چره های مختلف یک سیستم استفاده میشود.
• نمودارهای UML
• نمودار use case
• نمودار sequence (توالی)
• نمودار collaboration (همکاری)
• نمودار class (کلاس)
• نمودار state transition (در حالت)
• نمودار component
• نمودار Deployment
این نمودار ها جنبه های مختلفی از سیستم را نشان میدهند.
نمودارهای use case
نمودار های use case محاورات میان use case ها را نشان میدهد که عملیات سیستمی و عاملها (Actor) که نشان دهنده افراد یا سیستم هایی است که اطلاعات را برای سیستم فراهم کرده است و یا از آن دریافت میکنند را نمایش میدهند. use case ها درخواستهای سیستم را از دید کاربر نشان میدهند. بنابراین vse case ها عملیاتی هستند که سیستم فراهم میکند. عامل ها در واقع نگهدارنده پول (بانکدار) یک سیستم هستند. این نمودارها نشان میدهند که چه عاملهایی به use case ها مقدار اولیه میدهند. همچنین آنها نشان میدهند که چه موقع یک عامل، اطلاعات را از یک use case دریافت میکند.
تعدادی از ارتباطات این ارزش را دارند که بیشتر به آنها اشاره میشود. کارمند بانک همچنین، به use case تغییر PIN مقدار اولیه میدهد. use case پرداخت، فلشی را نشان میدهد که به سیستم اعتباری میرود سیستم های خارجی ممکن است عاملهایی باشند و در این مورد، سیستم اعتباری به عنوان یک عامل نشان میدهد که use case اطلاعاتی را تولید میکند که یک عامل از آن استفاده میکند. در این مورد use case پرداخت، اطلاعات پرداختی کارت اعتباری را برای سیستم اعتباری آماده میکند. اکثر اطلاعات دزدیدن نمودارهای use case قابل فهم میباشند زیر این نمودار همه عملیات سیستم را نشان میدهد. کاربران، مدیران پروژه، تحلیلگران، برنامه نویسان، مهندسان تضمین کیفیت و هر شخص دیگری که به سیستم وابسته است، میتواند مانند همه، این نمودارها را ببیند و بفهمد که چه سیستمی قرار است به انجام برسد.
نمودارهای sequence (توالی)
این نمودارها، برای نشان دادن جریان عملیات در یک use case استفاده شده اند، مثلا use case برداشت پول چند توالی sequences دارد مانند برداشت پول، تلاش برای برداشت پول از حساب بدون موجودی، تلاش برای برداشت پول با PIN اشتباه و غیره طرح معمولی برداشت 20 دلار پول و بدون هیچ مشکلی مانند وارد کردن PIN اشتباه یا وجوه ناکافی در حاسب در شکل زیر نشان داده شده است.
نمودار sequence جریان پردازش را در use case برداشت پول نشان میدهد عاملهای وابسته در بالای نمودار نشان داده شده اند، عامل مشتری هم در آن نشان داده شده است. هر فلش یک پیغام ارسالی بین عامل و آبجکت، یا آبجکت را نمایش میدهد تا عملیات مورد نیاز را به انجام برساند. نمودارهای sequence آبجکت ها را نمایش میدهند و نه کلاسها use case بدین ترتیب شروع میشود که مشتری کارتش را وارد کارت خوان میکند. کارت خوان شماره کارت را میخواند. آبجکت حساب joe را باز میکند و صفحه نمایش ATM را مقدار دهی مینماید. .صفحه نمایش از joe میخواهد که PIN را وارد نماید. او 1234 را وارد میکند. صفحه PIN را با آبجکت حساب تایید میکند و آنها را به هم جفت وجور میکند. صفحه انتخابهایش را برای joe آماده میکند و او 20 دلار را انتخاب میکند. سپس صفحه وجوه را از حساب بر میدارد. این سری از پردازشهایی که آبجکت حساب (account) به انجام میرساند را مقدار دهی میکند. ابتدا، حساب joe تایید میکند که حساب، حداقل شامل 20 دلار است سپس وجوه را از حساب کسر میکند بعدا به صندوق اطلاع میدهد که 20 دلار را آماده کند. همچنین حساب joe به صندوق اطلاع میدهد با یک رسید آماده کند. سرانجام به کارت خوان اطلاع میدهد تا کارت را باز پس دهد. بنابراین، این نمودار sequence تمام جریان پردازشی use case برداشت پول را با نشان دادن یک مثال مشخصی از اینکه joe دلار از حسابش بر میدارد را توضیح میدهد. کاربران میتوانند به این نمودارها نگاه کنند مشخصات پردازش تجاریشان را ببیند. تحلیلگران جریان پردازش را در نمودار sequence میبینند. برنامه نویسان آبجکت هایی که به کد نویسی نیاز دارند را به همراه عملکردهای آن آبجکت ها میبینند. مهندسین تضمین کیفیت میتوانند جزئیات پردازش و تولید test cas مبتنی بر پردازش را ببیند. نمودارهای sequence برای همه کسانی که در پروژه مسئول نگهداری پول هستند، مفید است.
نمودارهای Callaboration
نمودارهای collaboration دقیقا همان اطلاعات نمودارهای sequence را نشان میدهند. اگر چه نمودارهای collaboration اطلاعات را به روشی متفاوت و با یک هدف متفاوت نشان میدهند. در نمودارهای sequence آبجکت ها و ارتباطات عامل ها به ترتیب زمان توضیح داده شده اند، در حالی که در نمودار collaboration آبجکت ها و فعل و انفعالات عامل ها را بدون توجه به زمان نشان میدهد. در نمودارهای Collaboratim افراد به دلایل مختلف به این نمودارها مراجعه میکنند.
فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد
تعداد صفحات این مقاله 61 صفحه
پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید