طراحی برنامه

در ساليان اخير ، متدولوژی های متفاوتی بمنظور طراحی برنامه ، پياده سازی و در اختيار طراحان برنامه های کامپيوتری قرار گرفته شده است . برخی از اين متدلوژی ها ی طراحی، پيچيده و برخی ديگر ساده می باشند . در تمامی حالات ، هدف يکی است : کمک به برنامه نويسان در جهت نوشتن برنامه ها ئی که بسادگی نوشته ، اشکال زدائی و در نهايت نگهداری گردند .
در اين مقاله به بررسی مسائل مرتبط با طراحی برنامه پرداخته و در اين راستا در ابتدا با يک متدولوژی ساده آشنا خواهيم شد. متدلوژی استفاده شده با اينکه بسيار مقدماتی می باشد ولی اهداف ما را در جهت نحوه طراحی يک برنامه بخوبی تامين خواهد کرد .در اين مقاله ، به بررسی الگوريتم و مراحل پنج گانه برنامه نويسی خواهيم پرداخت . پس از آشنائی با متدولوژی ارائه شده در اين مقاله ، در بخش دوم مقاله ، با متدولوژی UML)Unified Modeling Language ) آشنا خواهيم شد. UML ، يک متدولوژی رايج بمنظور طراحی برنامه های کامپيوتری خصوصا" برنامه نويسی شی گراء است .

اهميت طراحی برنامه

فرض کنيد يک مسئله را برای تعدادی دانشجو تعريف و از آنان خواسته شده است که برنامه ای بمنظور حل مسئله مورد نظر ، طراحی و پياد ه سازی نمايند. پس از صرف چند ثانيه ، بلافاصله دانشجويان شروع به تايپ کد مورد نظر خود بمنظور حل مسئله می نمايند . در بين دانشجويان ، دانشجوئی وجود دارد که کاغذی را بر می دارد و شروع به نوشتن موضوع می نمايد. دقايقی سپری می گردد ، اما همچنان دانشجويان مشغول تايپ برنامه خود ويا احتمالا" اشکال زدائی! آن هستند .تقريبا" بدون استثناء ، دانشجوئی که ديرتر از ديگران آغاز نموده است ، با سرعت بيشتری تکليف خود را به پايان رسانده و حتی راه حل ارائه شده توسط وی ، نيز از ساير دانشجويان بمراتب بهتر است .چرا؟ در صورتيکه به کاغذی که در اختيار دانشجو قرار داده شده ، دقت نمائيد ، يک طرح مناسب بمنظور طراحی برنامه را برای مسئله، مشاهده خواهيد کرد . برخی از دانشجويان نيز ممکن است چندين کاغذ را تکميل و يک طراحی پيچيده را انجام داده باشند. نکته مهم در اين رابطه اين است که اين دانشجويان ( چه آنانی که يک طراحی ساده را انجام داده اند و چه آنانی که يک طراحی پيچيده را دنبال نموده اند ) دارای يک الگو( طرح ) برای برنامه خود ، می باشند .

الگوريتم

هر برنامه، می بايست دارای يک طرح و يا الگو بوده تا برنامه نويس بر اساس آن عمليات خود را دنبال نمايد.از ديدگاه برنامه نويسان ، هر برنامه نيازمند يک الگوريتم است . بعبارت ساده ، الگوريتم ، بيانه ای روشمند بمنظور حل يک مسئله بخصوص است . از منظر برنامه نويسان ،الگوريتم بمنزله يک طرح کلی و يا مجموعه دستورالعمل هائی است که با دنبال نمودن آنان ، برنامه ای توليد می گردد.

الگوريتم های ميکرو در مقابل ماکرو

الگوريتم ها دارای ويژگی های متفاوتی می باشند . ما می توانيم در رابطه با الگوريتم استفاده شده به منظور نوشتن يک برنامه مشخص صحبت نمائيم . از اين زاويه ، ما صرفا" در رابطه با الگوريتم در سطح ماکرو(macro level) ، صحبت نموده ايم . در چنين مواردی ، الگوريتم ارائه شده ، سعی در بدست آوردن جنبه های عمومی برنامه از طريق يک مرور کلی به برنامه در مقابل درگير شدن در جزئيات را دارد.ما می توانيم در رابطه با الگوريتم ها ، از سطح "ميکرو" صحبت نمائيم . از اين زاويه ، به سطوح پايين تر رفته و به عوامل اساسی ونگهدارنده ای که يک جنبه خاص از برنامه را با يکديگر مرتبط می نمايد، صحبت کرد. مثلا" در صورتيکه شما دارای داده هائی هستيد که می بايست قبل از استفاده مرتب گردند ،الگوريتم های مرتب سازی متعددی در اين زمينه وجود داشته و می توان يکی از آنها را بمنظور تامين اهداف مورد نظر خود انتخاب نمود. انتخاب يک الگوريتم مرتب سازی ، صرفا" باعث حل شدن يکی از جنبه های متفاوت برنامه می گردد . پس از مرتب سازی داده ها ،می بايست از يک الگوريتم ميکرو ديگر بمنظور نمايش داده ها ی مرتب شده استفاده گردد .
همانگونه که احتمالا" حدس زده ايد ، ما می توانيم تمام الگوريتم های ميکرو را بمنظور ايجاد يک الگوريتم ماکرو ، جمع آوری نمائيم . اگر ما با الگوريتم های ميکرو ، آغاز نمائيم ، و حرکت خود را بسمت نمايش ماکروی يک برنامه ، پيش ببريم ، کاری را انجام داده ايم که موسوم به طراحی " پايين به بالا" (buttom-up) ، است . اگر ما فعاليت خود را با يک الگوريتم ماکرو آعاز و حرکت خود را بسمت پائين و الگوريتم های ميکرو ، ادامه دهيم ، طراحی از نوع " بالا به پايين " (top-down) را انجام داده ايم .
شايد اين سوال مطرح گردد که کدام روش بهتر است ؟ اگر شما تمام مقالاتی را که تاکنون در اين زمينه نوشته شده اند را دنبال نمائيد ، هرگز به يک نتيجه قابل قبول دست نخواهيد يافت . هر رويکرد، دارای نکات مثبت و منفی مربوط به خود است . صرفنظر از رويکرد طراحی استفاده شده ، می بايست دارای الگوئی (طرحی) مناسب برای برنامه باشيم .حداقل، نيازمند يک اعلاميه از مسئله برنامه نويسی و يک طرح ( الگو) برای برخورد با مسئله ، خواهيم بود . پس از شناخت مسئله ، می توان نحوه حل مسئله را ترسيم کرد. شناخت عميق و مناسب نسبت به مسئله ای که قصد حل آن را داريم ، شرط اساسی و ضروری برای طراحی يک برنامه است .
با توجه به اينکه اين اعتقاد وجود دارد که شناخت جامع و کلی از مسئله ای که حل آن را داريم ، بخشی ضروری در اولين مرحله برنامه نويسی است ، ما در ادامه از رويکرد "بالا - پايين "، تبعيـت می نمائيم . فراموش نکنيم که رويکرد فوق ، امکان مشاهده مجازی از هر مسئله برنامه نويسی را فراهم خواهد نمود.

مراحل پنج گانه

هر برنامه را صرفنظر از ميزان پيچيدگی آن ، می توان به پنج مرحله اساسی تجزيه کرد :
• مقدار دهی اوليه
• ورودی
• پردازش
• خروجی
• پاکسازی
در ادامه به بررسی هريک از مراحل فوق ، خواهيم پرداخت .

مرحله مقداردهی اوليه

مرحله مقداردهی اوليه ، اولين مرحله ای است که می بايست در زمان طراحی يک برنامه در رابطه با آن فکر کرد . مرحله فوق ، شامل تمامی عمليات مورد نيازی است که برنامه می بايست قبل ازبرقراری ارتباط با کاربر ، انجام دهد . در ابتدا ممکن است اين موضوع که عملياتی را قبل از برقراری ارتباط با کاربر می بايست انجام داد ، تا اندازه ای عجيب بنظر رسد ولی احتمالا" برنامه های زيادی را مشاهده نموده ايد که در اين راستا عمليات مشابهی را انجام می دهند. مثلا" ، در زمان استفاده از برنامه هائی نظير Word ، Excel و يا برنامه های مشابه ديگر ، با چنين مواردی برخورد نموده ايم . مثلا" با انتخاب گزينه منو File ، می توان ليستی از فايل هائی را که با آنها کار کرده ايم در بخش انتهائی منوفوق ، مشاهده کرد. ( مشاهده آخرين فايل های استفاده شده در يک برنامه خاص ، با استفاده از جادو! ميسر نشده است ) . برنامه مورد نظر شايد ، ليست فايل های اخير را از ديسک خوانده و آنها را به ليست مربوطه در منوی File ، اضافه کرده باشد . با توجه به اينکه ليست فايل های فوق ، می بايست قبل از اينکه برنامه هر چيز ديگر را برای کاربر نمايش دهد ، خوانده و نمايش داده شوند ، می توان انجام عمليات فوق را نمونه ای از مرحله مقداردهی اوليه، در نظر گرفت.
يکی ديگر از عمليات متداول که به اين مرحله مرتبط می باشد ، خواندن فايل های Setup است . چنين فايل هائی ممکن است حاوی اطلاعاتی در رابطه با نام مسيرهائی باشند که بانک ها ی اطلاعاتی خاصی و يا فايل های ذخيره شده ديگری را بر روی ديسک را مشخص می نمايند . با توجه به نوع برنامه ای که اجراء می گردد ، فايل های Setup می توانند شامل اطلاعاتی در رابطه با فونت های نمايش ، نام و محل چاپگر ، رنگ های زمينه و رويه ، وضوح تصوير صفحه نمايشگر و اطلاعات مشابهی ديگر باشند . ساير برنامه ها ممکن است مستلزم خواندن اطلاعاتی در رابطه با اتصالات شبکه ، مجوزهای امنيتی و دستيابی به اينترنت ، رمزهای عبور و ساير اطلاعات حساس ديگر باشند . در چنين مواردی فايل های Setup دارای نقشی مهم خواهند بود.
در زمان طراحی يک برنامه ، همواره می بايست در رابطه با اطلاعاتی که يک برنامه قبل آغاز خدمات و عمليات خود به آنها نيازمند است ، انديشيد و برای آنان در مرحله مقداردهی اوليه راهکار مناسب را انتخاب کرد . مرحله مقداردهی اوليه احتمالا" جائی است که می بايست از طريق آن اقدام به ارائه راهکار مناسب در جهت پاسخ به نيازهای فوق ، کرد.

مرحله ورودی

مرحله ورودی ، در حقيقت چيزی است که انتظار داريد باشد! مرحله فوق ، شامل اخذ ( جمع آوری ) هر آنچيزی است که يک برنامه برای انجام فعاليت های خود به آنها نياز خواهد داشت . دراکثر موارد، اگر استنباط مناسبی از عملياتی را که يک برنامه قصد انجام آنان را دارد ، حاصل گردد، مشخص نمودن ليستی از ورودی ها ، کاری ساده خواهد بود. مثلا" اگر شما قصد نوشتن يک برنامه وام را داريد ، می دانيد که می بايست از کاربر ميزان وام درخواستی ، بهره موردنظر و مدت زمان وام ، درخواست گردد.
در حالات ديگر، لازم است در رابطه با نوع ورودی هائی که می بايست از کاربر اخذ گردد، بررسی لازم و مبتنی بر انديشه را دنبال نمود. مثلا" در صورتيکه قصدنوشتن يک برنامه دفترچه آدرس را داريد ، آيا می خواهيد نام فايل حاوی دفترچه تلفن و محل ذخيره فايل مربوطه را در هر مرتبه که برنامه اجراء می گردد ، از کاربر درخواست نمائيد ؟ بعبارت ديگر برخی از مراحل ورودی می توانند و شايد می بايست ، توسط مرحله مقدار دهی انجام شوند. ماهيت واقعی ميزان اطلاعاتی که می توان آنها را در مرحله مقداردهی خواند ، بستگی به رفتار برنامه دارد. بعنوان يک قانون عمومی می توان به اين مورد اشاره داشت که اکثر کاربران تمايل دارند که اطلاعات تکراری در يک فايل Setup و يا مقداردهی اوليه ذخيره گردد (در مقابل اينکه هر مرتبه که برنامه اجراء می گردد ، مجبور به ورود اطلاعات تکرای باشند ) .
فايل های Setup بسيار مناسب بوده و در هرموردی که امکان بخدمت گرفتن آنان منطقی بنظر می آيد ، می بايست از آنان استفاده گردد . برخی ديگر از اطلاعات اوليه دارای ماهيت خاص خود بوده و تا زمانيکه کاربر آنها را تايپ ننمايد ، شناخته نمی گردند . در مثال وام اشاره شده ، می توان از TextBox های متعددی بمنظور احذ اطلاعات از کاربر و استفاده از آنان در برنامه ، کمک گرفت . با توجه به اينکه کاربر می بايست با اين TextBox ها مرتبط تا اطلاعات موردنياز برنامه را وارد نمايد ، روشی را که شما بمنظور ارائه Textbox ,Labels ,Menus و ساير عناصر برنامه ، استفاده می نمائيد ، يکی از بخش های مهم يک برنامه يعنی رابط کاربر ( user interface ) را مشخص خواهد کرد . فراموش نکنيم يکی از عوامل موفقيت هر نرم افزار ، بخش رابط کاربر آن است . طراحی مناسب بخش فوق ، امروزه بعنوان تخصصی خاص در طراحی و پياد ه سازی نرم افزار مطرح و دارای جايگاه خاص خود است .

مرحله پردازش

مرحله پردازش ، شامل انجام عمليات بر روی ورودی (ورودی ها ) ، بمنظور توليد نتايج مورد نظر برای برنامه است . در مثال وام ، برنامه پس از دريافت ورودی های مورد نظر ( ميزان وام ، درصد بهره و زمان وام ) آنها را از طريق يک معادله مالی بيکديگر مرتبط و پس از حل معادله ، نتيجه مورد نظر حاصل خواهد شد( ميزان پرداخت ماهانه ) . بعبارت ديگر ، مرحله پردازش قادر به دريافت ورودی ، برخورد با آنها و توليد پاسخ مناسب به مسئله است . توجه داشته باشيد که مرحله پردازش همواره باعث نمايش چيزی بر روی نمايشگر نخواهد شد. هدف ، عمل ( عمليات ) برروی داده ( داده ها ) بمنظور توليد يک نتيجه ( نتايج ) است . در اين رابطه هيچگونه استثنائی وجود ندارد . در صورتيکه در برنامه ای از قبل می دانيم که مرحله پردازش زمان زيادی طول خواهد کشيد ، منطقی است که فيدبک های لازم بمنظور آگاهی کاربر از ميزان و درصد انجام پردازش ( پردازش ها ) در اختيار وی گذاشته شود ( در زمانيکه برنامه در حال اجراء است ) . در اين رابطه می توان از روش های متعددی استفاده کرد . ( ارائه يک ميله پيشرفت ، برآورد زمان تقريبی بمنظور اتمام عمليات ) .

مرحله خروجی

مرحله فوق ، پاسخ ( پاسخ ها ی) مناسب و مورد انتظار را به کاربران مبنی بر حل مسئله مورد نظر ، ارائه می نمايد. تعداد زيادی ازبرنامه ها ، پاسخ نهائی ( نتيجه ) خود را از طريق يک Textbox ، نمايش و در اختيار کاربر قرار می دهند . ، مثلا" اگر برنامه ای نوشته شده است که قصد محاسبه و نمايش ميزان پرداخت ماهيانه يک وام دريافتی را داشته باشد ، می توان نتيجه بدست آمده (پرداخت ماهانه) را از طريق يک textbox ، ارائه تا پاسخی مناسب در ارتباط با مرحله خروجی يک برنامه، داده شده باشد . ساير برنامه ها ممکن است دارای وضعيتی بمراتب پيچيده تر باشند .مثلا" می توان برنامه ای را در نظر گرفت که نام ، آدرس ، شماره تلفن و ساير اقلام اطلاعاتی را از بانک اطلاعاتی خوانده و در ادامه آنها را بر روی صفحه نمايشگر ، نشان دهد. برنامه هائی اينچنين ، نيازمند شکل مناسبتری از نمايش خروجی بوده و نمی توان با استفاده از چند textbox به خواسته خود دست يافت ( ارائه يک خروجی مطلوب و انعطاف پذير) در اينگونه موارد می بايست از راهکارهای مناسبتری استفاده گردد . مثلا" می توان از جداول خاصی بمنظور نمايش اطلاعات مورد نظر استفاده کرد .( استفاده از grid و يا List box که برنامه در صورت ضرورت آنان را تکميل نمايد ) . نکته مهمی که می بايست در رابطه با مرحله خروجی رعايت گردد ، آگاهی از اين موضوع است که با توجه به نمايش نتايج خروجی برای کاربر، بخش فوق را می توان جزئی از بخش رابط کاربر يک نرم افزار در نظر گرفت . در زمان ورود اطلاعات ( مرحله ورودی ) از عناصر متفاوتی بمنظور اخذ اطلاعات توسط کاربر در بخش رابط استفاده می گردد ، در مرحله خروجی ، بخش رابط کاربر با کاربر بگونه ای ديگر مرتبط خواهد شد ( ارتباطی بمراتب غير فعالتر نسبت به مرحله ورود اطلاعات ) .

مرحله پاکسازی ( Cleanup )

مرحله پاکسازی ، بمنظور خاتمه بخشيدن مودبانه يک برنامه، پس از تکميل عمليات مربوطه است. می توان اين مرحله را بعنوان مکمل مرحله مقداردهی اوليه در نظر گرفت .با اينکه تعداد زيادی از برنامه های ساده قادرند بسادگی و بدون انجام عمليات تکميلی توسط برنامه نويس ، خاتمه يابند ولی برنامه های پيچيده زيادی نيازمند برخی کمک ها در اين زمينه می باشند. مثلا" اگر برنامه ای يک فايل Setup را بمنظور مقداردهی برخی از متغيرها در زمان مرحله مقداردهی اوليه ، خوانده باشد ، مرحله پاکسازی می تواند شامل بهنگام سازی آندسته از متغيرهای موجود در فايل Setup باشد که نشاندهنده آخرين اطلاعات کاربر است . مرحله پاکسازی ، اغلب شامل بستن فايل ها ( فايل های Setup و بانک اطلاعاتی) است . برخی برنامه ها ميزان استفاده از برنامه توسط کاربران را ثبت و اطلاعات مربوطه را در مکانهائی که Log file ناميده می شوند ، ذخيره می نمايند( ثبت مشخصات افراديکه برنامه را اجراء نموده بهمراه ساير اطلاعات مرتبط نظير تاريخ و زمان آغاز و توقف برنامه ، در خيلی از برنامه ها به امری ضروری تبديل شده است ) .
يکی ديگر از انواع فايل های Log به فايل های ثبت خطاء برمی گردد( error log file ) . هدف اين نوع از فايل ها ، ثبت اطلاعاتی در رابطه با هر نوع خطائی است که ممکن است در مدت زمان اجرای يک برنامه ، محقق گردد. برنامه نويسان با استفاده از محتويات اين نوع فايل ها ، قادر به اشکال زدائی برنامه خواهند بود .
عمليات واقعی و مورد نظری که می بايست در مرحله پاکسازی ، انجام گردد ، به نيازهای يک برنامه بستگی خواهد داشت . معمولا" اگر در برخی برنامه ها عمليات خاصی را در مرحله مقدار دهی اوليه انجام می هيم ، می بايست برخی از عمليات متناظر با آنان را در مرحله پاکسازی انجام داد . باز نمودن و بستن فايل های مورد نياز در يک برنامه ، نمونه ای متداول از دو مرحله فوق می باشد .

آيا هر برنامه شامل پنج مرحله گفته شده است؟

در پاسخ به سوال فوق می بايست با صراحت پاسخ منفی داده شود. در اين راستا ، برنامه های متعددی وجود دارد که مثلا" به مراحل مقداردهی اوليه و يا پاکسازی ، نياز نخواهند داشت . مراحل مقداردهی اوليه و پاکسازی در مرحله طراحی برنامه های پيچيده مورد توجه جدی قرار خواهند گرفت. بموازات افزايش تجربه در نوشتن برنامه ، شناخت مناسبی در اين رابطه بوجود می آيد( کدام برنامه به تمام مراحل پنج گانه نياز و کداميک نياز ندارند).طراحان می بايست همواره يک مسئله برنامه نويسی را با فرض وجود پنج مرحله ياد شده ،دنبال نمائيد . قطعا" حذف يک مرحله در زمان طراحی بمراتب ساده تر از ناديده گرفتن ! اوليه آن خواهد بود.

پالايش يک طرفه ( Sideways Refinement )

همانگونه که قبلا" اشاره گرديد ، ما علاقه مند به طراحی بالا به پايين می باشيم .( الگوريتم ماکرو بعنوان يک نقطه شروع در فرآيند طراحی برنامه) . پس از انتخاب رويکرد فوق ، می بايست شناخت مناسبی نسبت به مسئله ای که قصد حل آن وجود دارد ، ايجاد گردد. تا رسيدن به سطح ميکرو( ارائه الگوريتم های ميکرو) بمنظور حل مسئله مورد نظر راه زيادی را در پيش خواهيم داشت. بموازات حرکت از سطح مرور کلی برنامه به خصوصيات و ويژگی های يک برنامه ، می بايست دانش خود را نسبت به جرئيات مربوطه افزايش داد .
از پنج مرحله گفته شده ، می توان بمنظور نقطه شروع ديد ماکرو خود در زمان فرآيند طراحی استفاده کرد. درادامه ، می توان هر يک از مراحل را بدقت بررسی تا جزئيات بيشتری در رابطه با مرحله مورد نظر ، مشخص گردد ( استخراج جزئيات لازم در رابطه با تحقق هر مرحله ) . فرآيند فوق ، " پالايش يک طرفه " ، ناميده می شود . در ادامه ، بمنظور شناخت مناسب فرآيند پالايش يک طرفه ، به بررسی يک نمونه می پردازيم .
فرض کنيد ، کاربری دارای يک فايل بانک اطلاعاتی است که در آن تمام قرار ملاقات های وی ، ذخيره شده اند . قرار ملاقات ها در بانک اطلاعاتی با نظم و ترتيب خاص ( تاريخ قرار ملاقات ) ذخيره شده اند . کاربر ، می خواهد قادر به مشاهده قرار ملاقات های خود بر اساس حروف الفبائی و بر اساس نام خانوادگی اشخاص مورد نظری که قصد ملاقات با وی را دارند ، باشد. چگونه می توان از پالايش يک طرفه ، بمنظور طراحی يک را ه حل استفاده کرد؟

پالايش يک طرفه مرحله مقدار دهی اوليه

می دانيم که کاربر دارای يک بانک اطلاعاتی شامل قرار ملاقات ها ، می باشد. ما همچنين می دانيم که کاربر می خواهد ليستی از قرار ملاقات های خود را بصورت مرتب شده و بر اساس نام خانوادگی مشاهده نمايد . موارد فوق ، ديد ماکروی ما از الگوريتم است . بنابراين ، در مرحله مقداردهی اوليه چه عملياتی می بايست انجام داد ؟ واضح است که ما نيازمند باز نمودن بانک اطلاعاتی قرار ملاقات ها می باشيم . ما همچنين نيازمند يک فرم ( مثلا" يک فرم مبتنی بر VB.NET و يا فرم وب ) بمنظور نمايش نتايج پس از مرتب سازی قرار ملاقات ها ، خواهيم بود. ( فرض می شود از مکان بانک اطلاعاتی بر روی شبکه آگاهی داريم ، و می توان نام و رمز عبور کاربر را از بانک اطلاعاتی مربوطه بمحض آغاز اجرای برنامه توسط کاربر ، مشخص کرد) .
همانگونه که در شکل فوق ، مشاهده می گردد بموازات حرکت از سمت چپ بسمت راست ، جزئيات مربوطه افزايش خواهد يافت . شکل فوق ، پالايش يک طرفه ، ليستی از برنامه های جانبی و توابع مورد نياز بمنظور انجام فعاليت های مربوطه در مرحله مقداردهی اوليه را نشان می دهد . هر روتين کوچک، مسئول انجام عملياتی خاص خواهد بود .

شبه کد ( Pseudo Code )

عمليات پالايش را می توان در رابطه با هر مرحله با استفاده از "شبه - کد " ، دنبال کرد. شبه کد ،الگوريتمی برای بيان عملياتی است که می بايست توسط يک روتين محقق گردد . در اين راستا از يک گرامر مشابه انگليسی ، استفاده می گردد . مثلا" شبه کد ، روتين IsValidUser بصورت زير خواهد بود:

شبه کد روتين IsvalidUser

Is ValidUser()   If  CurrentUserName Not in ValidUserList         Display Invalid User Error Message         Terminate Program   Else        Return ValidUserIDNumber End

شبه کد ، عملياتی را که يک روتين می بايست انجام دهد ، بدون اتکاء به گرامر يک زبان برنامه نويسی خاص ، تشريح می نمايد. شبه کد ، زبانی مبتنی بر گرامری خاص نبوده و الگوريتمی از عمليات مورد نظر که می بايست توسط يک روتين انجام شود را مشخص می نمايد. مزيت شبه کد، شباهت زياد آن به زبان انگليسی است و می توان آن را با افراديکه برنامه نويس نبوده و بنوعی در فاز طراحی صاحبنظر می باشند ، به اشتراک تا صحت استنباطات حاصل شده تائيد و يا اصلاح گردد.( در فاز طراحی می بايست يک ارتباط مستمر با کاربران صاحبنظر برقرارگردد، ما قرار است مسئله آنان را حل نمائيم نه مسئله خود را و يا نمی خواهيم مسئله ای ديگر را بر حجم مسائل آنان اضافه نمائيم!) بدين ترتيب ، امکان تشخيص خطاء و اعمال تعييرات لازم در خصوص برخورد با خطاهای احتمالی در ابتدا فراهم می گردد ( يکی از اصول مهندسی نرم افزار در اين رابطه به اين موضوع اشاره می نمايد که به هر ميزان که زمان کشف يک خطاء در چرخه حيات يک برنامه سريعتر باشد ، هزينه برخورد با خطاء کاهش خواهد يافت ) .
پس از آگاهی از اهداف ارائه شده در شبه کد ، می توان بسادگی اقدام به ترجمه شبه کد مربوطه به کدهای برنامه نويسی با استفاده از زبان مورد نظر نمود. فراموش نکنيم که طراحی خوب ، همواره پياده سازی ساده تر برنامه ها را بدنبال خواهد شد.

UML چيست ؟

مراحل پنج گانه برنامه نويسی ، نقطه شروع مناسبی برای طراحی يک برنامه است ( اولين فاز). در ادامه با استفاده از پالايش ( بهسازی ) يکطرفه مراحل پنج گانه برنامه نويسی ، فاز دوم طراحی يک برنامه انجام خواهد شد . استفاده از شبه کد بمنظور ارائه جزئيات پالايش ، کمک قابل توجه و مفيدی در ارتباط با طراحی برنامه را بدنبال خواهد داشت . رويکرد فوق ( مراحل پنج گانه برنامه نويسی ) ، روشی مفيد بمنظور طراحی يک برنامه است . در اين راستا برخی از طراحان برنامه های کامپيوتری ترجيح می دهند که از يک روش دقيق تر و موشکافانه تر استفاده نمايند . UML(Unified Modeling Language) مبتنی بر چنين رويکردی است .
UML ،زبانی استاندارد بمنظور مشخص نمودن ، پيش بينی ، ايجاد و مستند سازی توليدات نرم افزاری است . UML ، مجموعه ای از بهترين امکانات مهندسی را بمنظور استفاده در مدل سازی سيستم های بزرگ و پيچيده ارائه که کارآئی آنان به اثبات رسيده است . UML يک متدولوژی رسمی برای پياده سازی نرم افزار است .

روند شکل گيری UML

برنامه نويسی شی گراء ( OOP ) ، از اوايل سال 1960 مطرح گرديد . برنامه نويسی شی گراء با اينکه بعنوان يک ايده جديد مطرح شده بود ولی بسرعت زبان های مدل سازی شی گراء برای پوشش ايده فوق ، مطرح و پياده سازی گرديدند. در فاصله سال های 1970 تا اواخر 1980 چندين زبان مدل سازی شی گراء پياده سازی گرديد . تعداد زبان ها ی مدل سازی شی گراء در سال 1995 به بيش از پنجاه نمونه رسيده بود .
از افراد فعال و پيشرو در اين زمينه می توان به Jim Rumbaugh ( شرکت جنرال الکتريک )، Grady Booch ( شرکت Rational software ) و Ivar Jacobson ( شرکت Objectory ) اشاره نمود. هر يک از افراد فوق ، تلاش گسترده ای را در جهت مدل سازی زبان برنامه نويسی انجام داده بودند . در سال 1994 ، Rumbaugh شرکت جنرال الکتريک را ترک و به Booch در شرکت Rational Software ملحق گرديد. يک سال بعد ، شرکت Rational Software ، شرکت Objectory را خريداری و افراد ياد شده همکاری خود را با يکديگر و در يک شرکت مشترک آغاز نمودند. ماحصل همکاری فوق ، ارائه اولين نسخه UML 0.9 توسط شرکت Rational software در سال 1996 بود .
در ساليان بعد ، OMG)Object Management Group) ، تلاش های گسترده ای را بمنظور ارتقاء و بهسازی UML آغاز نمود. در اواسط سال 2001 ، اعضاء OMG ، کار خود را بمنظور ارتقاء به UML 2.0 آغاز نمودند. در حا ل حاضر ، UML شامل مدل سازی ويژوال ، شبيه سازی و امکانات پياده سازی است . تعداد زيادی از ابزارهای UML طراحی و در اختيار علاقه مندان قرار گرفتند . Rational Rose 2002 از شرکت Rational Software ، نرم افزار Describe Enterprise از شرکت Embarcadero Technologies و Visio 2002 از شرکت مايکروسافت . نمونه هائی از ابزارهای UML می باشند .

دياگرام های UML

UML يک ابزار ويژوال بوده و از انواع متفاوتی دياگرام استفاده می نمايد . هر يک از دياگرام های UML ، امکان مشاهده يک سيستم نرم افزاری را از ديدگاههای متفاوت و با توجه به درجات متفاوت Abstraction در اختيار پياده کنندگان قرار می دهد. برخی از دياگرام های UML عبارتند از :
• Class Diagram
• State Diagram
• Sequence Diagram
• Collaboration Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram

آناليز شی گراء (OOA)

آناليز شی گراء و يا OOA ، يک متدولوژی قدرتمند برای تجزيه و تحليل فرآيند پياده سازی نرم افزار است . در زمان استفاده از OOA ، هر چيز در فرآيند پياده سازی نرم افزار بمنزله کلاس در نظر گرفته خواهد شد ( اين طرز تفکر می بايست محور آناليز سيستم قرار گيرد ) . مثلا" در يک بيمارستان هر يک از عناصر موجود نظير : دکتر ، پرستار ، بيمار و ملاقات کننده ، بمنزله يک کلاس در نظر گرفته می شوند . هر نسخه جديدی که از يک کلاس ايجاد می گردد ، بمنزله يک نمونه ( Instance ) از کلاس در نظر گرفته خواهد شد . محوريت فرآيند آناليز شی گراء ، تاکيد بر ايجاد کلاس های مورد نياز سيستم است .
مهمترين و اصلی ترين رويکرد OOA ،يافتن پاسخ مناسب برای سوالاتی است که با What شروع و در فرآيند پياده سازی نرم افزار حضوری موثر دارند . نمونه سوالات OOA در اين زمينه عبارتند از : " چه کلاس هائی در برنامه وجود دارد؟" . " چه چيزی را برنامه انجام خواهد داد ؟" " هر يک از کلاس ها در برنامه چه عملياتی را بمنظور حل مسئله انجام خواهند داد ؟" " مسئوليت هر کلاس در برنامه چيست ؟" در OOA ، تاکيد بر آناليز اشياء ، فعاليت ها و مسئوليت های سيستم نرم افزاری است .

طراحی شی گراء ( OOD )

نکته اساسی در طراحی شی گراء ، تاکيد و سرو کار داشتن با سوالاتی است که با How شروع و در فرآيند پياده سازی نرم افزار حضوری فعال و موثر خواهند داشت . " چگونه اين کلاس داده را جمع آوری می کند ؟" . " چگونه اين کلاس گزارش را چاپ می نمايد ؟" ، نمونه سوالاتی در اين زمينه می باشند .در نمونه مثال بيمارستان، وضعيت فوق به خصلت ها ، صفات و متدهای يک کلاس مرتبط می گردد .
بنابراين OOA ، کلاس های مورد نظر و ضروری بمنظور نيل به اهداف نرم افزار را مشخص می نمايد و محور عمليات بر جستجو و تبين جايگاه يک کلاس در برنامه متمرکز است . در OOD ، تاکيد بر پياده سازی کلاس ها ، صفات و خصايصی است که بمنزله هسته يک کلاس مطرح می گردند . ترکيب هر يک از فعاليت های فوق ( آناليز شی گراء و طراحی شی گراء ) بهمراه پياده سازی لينک هائی که با کلاس ها سروکار دارند جملگی بعنوان بخشی از فرآيند OOP ( برنامه نويسی شی گراء ) محسوب می گردند.

دياگرام های کلاس UML

دياگرام کلاس در UML يکی از مهمترين دياگرام ها تلقی می گردد . دياگرام فوق ، مسئوليت مدل سازی ساختار کلاس و محتويات را با استفاده از عناصری نظير کلاس ها ، اشياء و پکيج ها برعهده دارد . اين دياگرام همچنين ، ارتباطاتی نظير : توارث و پيوستگی را نمايش خواهد داد. دياگرام فوق ، شکل خلاصه و استانداردی بمنظور نمايش يک کلاس را ارائه می نمايد. در اين راستا از يک مستطيل که به سه بخش متفاوت تقسيم می گردد ، استفاده می شود. در اولين بخش مستطيل ، نام کلاس قرار می گيرد . در دومين بخش مستطيل ، خصلت های يک کلاس قرار خواهند گرفت ( ممکن است از واژه صفات و يا متغير نيز استفاده گردد ) و در بخش سوم ، متدهای يک کلاس قرار می گيرند.متدهای هر کلاس ، عملياتی را که يک کلاس می تواند انجام دهد ، مشخص می نمايند. شکل زير ، يک دياگرام کلاس نمونه را نشان می دهد. در اولين بخش ، نام کلاس Vehicle مشخص شده است .نام هر کلاس با يک حرف بزرگ شروع و در موارديکه نام کلاس شامل بيش از يک کلمه باشد ، هر کلمه در نام کلاس با يک حرف بزرگ آغاز می گردد . Vehicle ، PassengerCar و IncomeStatement نمونه هائی در اين زمينه می باشند .استفاده از از فضای خالی بين کلمات تشکيل دهنده نام يک کلاس ، مجاز نمی باشد .

خصايص کلاس (Properties , Attributes)

در دياگرام کلاس Vehicle و در بخش دوم از شش خصلت Integer استفاده شده است . در نمونه کلاس های ديگر ، يک کلاس ممکن است دارای دهها خصلت باشد .در برخی زبانهای برنامه نويسی نظير ويژوال بيسيک دات نت ،از خصلت با نام Prtoperty نيز ياد می گردد. هر خصلت می تواند دارای مقادير متفاوتی باشد . مقادير جاری خصلت ها ، وضعيت يک کلاس را تشريح می نمايند . در مقام مقايسه می توان خصايص يک شی را نظير نقش اسامی در يک جمله در نظر گرفت ( مقايسه فوق صرفا" جنبه آموزشی دارد ) .

علايم + و -

همانگونه که مشاهده می گردد ، هر entry دربخش دوم دياگرام کلاس Vehicle ، دارای يک علامت - در جلوی نام خود است .در بخش سوم ، برخی از Entry ها ، دارای علامت + و برخی ديگر دارای علامت - می باشند . وجود علامت + در ابتدای يک آيتم ( خصلت ، متد ) ، نشاندهنده در دسترس بودن آن از طريق خارج از کلاس است . بعبارت ديگر ، علامت +، امکان استفاده از آيتم مورد نظر و تاثيرگذاری بر وضعيت يک کلاس را نشان می دهد . علامت + ، عمومی بودن ( Public ) عناصر کلاس مربوطه را نشان می دهد .
اگر يک Entry با يک علامت - شروع گردد ، بدين معنی خواهد بود که آيتم مورد نظر صرفا" برای استفاده خود کلاس در دسترس بوده و امکان استفاده از آن برای خارج از کلاس ميسر نخواهد بود. بنابراين علامت - ، نشاندهنده خصوصی ( Private ) بودن عناصر مربوط به يک کلاس است .
استفاده از علائم + و - ، نشاندهنده نوع دستيابی به هر يک از عناصر مربوط به يک کلاس است . در حقيقت علامت + ، روشی بمنظور ارتباط با کلاس را مشخص نموده و علامت - نشاندهنده عناصری است که صرفا" برای خود کلاس قابل استفاده خواهند بود .
ايجاد يک آيتم بصورت خصوصی همواره مورد توجه طراحان شی گراء بوده و تامين کننده اهداف کپسوله سازی در برنامه نويسی شی گراء است . با کپسوله سازی داده ، امکان بروز تغييرغيرعمد داده در برخی بخش ها ی برنامه و از طريق خارج از کلاس به حداقل مقدار خود خواهد رسيد . بدين ترتيب، تشخيص و برطرف نمودن خطاهای احتمالی ، بسرعت و بسادگی ميسر خواهد شد .

متدهای کلاس ( عمليات )

عنصر سوم در دياگرام کلاس ، نشاندهنده نوع عمليات مرتبط با کلاس است . در UML آيتم های موجود در اين بخش را "عمليات " ( Operations ) ، ودر برخی از زبان های برنامه نويسی نظير ويژوال بيسيک دات نت ، به آنان "متد" گفته می شود . متدها ، نحوه ارتباط برنامه نويسان با يک کلاس را مشخص می نمايند. هر متد عمليات خاصی را در ارتباط با يک کلاس انجام خواهد داد.اگر خصلت ها را بمنزله اسامی در يک جمله در نظر بگيريم ، می توان متدها را بمنزله افعال موجود در يک جمله در نظر گرفت .

متدهای کلاس و آرگومان ها

در برخی موارد يک متد نيازمند اطلاعات خارجی بمنظور انجام وظايف محوله است . مثلا" در دياگرام کلاس Vehicle از متد زير استفاده شده است :

+SetSpeed(DesiredSpeed:Integer):Integer

علامت + نشاندهنده اين موضوع است که ( ) SetSpeed يک متد Public است . بنابراين امکان استفاده از آن توسط يک برنامه نويس وجود خواهد داشت .بمنظور ارسال داده به متد مورد نظر از آرگومان استفاده شده که بين علامت پرانتز قرار می گيرند.در مثال فوق ، پارامتر مورد نظر DesiredSpeed بوده و از نوع Integer است . در انتهای علامت پرانتز بسته ، ازيک کالون ":" ، که بدنبال آن کلمه Integer آمده است ، استفاده شده است . اين بدان معنی است که متد ( ) SetSpeed يک مقدار صحيح را به برنامه صدازننده ، بر می گرداند.
در نمونه کلاس Vehicle از دومتد بمنظور افزايش و يا کاهش سرعت استفاده شده است :

-IncreaseSpeed(DesiredSpeed:Integer):Integer -DecreaseSpeed(DesiredSpeed:Integer):Integer

هر يک از متدهای فوق ، عمليات مورد نظر در رابطه با افزايش و يا کاهش سرعت را انجام خواهند داد . برای نيل به خواسته فوق ( افزايش و يا کاهش سرعت ) می توان دو متد فوق را با يکديگر تلفيق و در يک متد واحد ديگر جايگزين نمود:

-ChangeSpeed(DesiredSpeed:Integer):Integer

در صورتيکه پارامتر DesiredSpeed مثبت باشد ، سرعت افزايش و در غير اينصورت ( پارامتر منفی باشد ) ، سرعت کاهش خواهد يافت.

Dim MyVehicle as New Vehicle Dim ObjectSpeed as integer ' Some code that does something... ObjectSpeed = MyVehicle.GetSpeed() ObjectSpeed = MyVehicle.ChangeSpeed(-ObjectSpeed)

درنمونه مثال فوق ، در ابتدا يک شی Vehicle با نام MyVehicle تعريف شده است . در ادامه ، متد GetSpeed در ارتباط با شی MyVehicle فرا خوانده شده است .بمنظور جداسازی نام شی از متد مربوطه از علامت نقطه استفاده شده است .
فرض کنيد که Vehicle با سرعت 55مايل در ساعت در حال حرکت است . مقدار ObjectSpeed ، پنجاه و پنج در نظر گرفته می شود .در صورتيکه در ادامه مقداری منفی را به متد فوق پاس دهيم سرعت کاهش پيدا خواهد کرد. اگر مقدار 55 - را به متد ChangeSpeed() پاس دهيم ، توقف اتومبيل را بدنبال خواهد داشت .
همانگونه که مشاهده می شود ، برخی از متدها با علامت - شروع شده اند . اين بدان معنی است که آنان متدهای اختصاصی ( Private) بوده و خارج از کلاس قابل دستيابی نخواهند بود. چنين متدهائی به ساير متدها ی موجود در کلاس ، سرويس و خدمات لازم را ارائه و استفاده از آنان برای برنامه نويس مجاز نخواهد بود.بعبارت ديگر متدهای فوق بعنوان ايترفيس کلاس مطرح نبوده و از خدمات آنان در داخل کلاس استفاده خواهد شد . در چنين مواردی ممکن است يک متد که بصورت Public تعريف و امکان استفاده از آن در خارج از کلاس و توسط برنامه نويسان وجود دارد ، خود از خدمات چندين متد خصوصی استفاده نمايد .
يک دياگرام کلاس UML ، امکان مرور سريع و فشرده پتانسيل ها ی يک کلاس را فراهم و نحوه ارتباط يک برنامه نويس با کلاس مورد نظر را نيز مشخص خواهد شد. اگر يک کلاس را بعنوان يک جعبه سياه در نظر بگيريم ، علامت "-" ، نشاندهنده آيتم هائی درون جعبه سياه است که امکان استفاده از آنان توسط برنامه نويسان وجود نخواهد داشت . علامت "+" ، نشاندهنده امکاناتی است که می توان از آنان بمنظور ارتباط با متدها و خصايص يک کلاس استفاده کرد . آيتم های Public يک کلاس ، اينترفيس لازم برای يک کلاس را تعريف و نحوه ارتباط با آن را مشخص می نمايند. در حقيقت متدهای Public ، نحوه استفاده از يک کلاس را به برنامه نويسان ديکته خواهند کرد .

خلاصه

• الگوريتم ،اعلاميه ای سازماندهی شده بمنظور حل يک مسئله خاص و يا سوالاتی است که می بايست پاسخ آنان مشخص گردد . يک الگوريتم مناسب ، تمامی مراحل لازم بمنظور انجام فرآيندهای مورد نياز و حل يک مسئله را ارائه می نمايد .
• مقداردهی اوليه ، ورودی ، پردازش ، خروجی و پاکسازی ، پنج مرحله متفاوت برنامه نويسی می باشند .
• مراحل پنج گانه برنامه نويسی ، نگرشی ماکرو از يک برنامه را ارائه می نمايند . مثلا" مرحله ورودی ممکن است نيازمند اخذ داده از صفحه کليد ، خواندن يک جدول تنظيمات از يک بانک اطلاعاتی و نهايتا" خواندن اطلاعات بيشتر از بانک اطلاعاتی ديگر باشد . بهسازی ( پالايش ) يکطرفه ، فرآيندی است که بر اساس آن يکی از مراحل برنامه نويسی (نظير مرحله ورودی ) بررسی و به آن جزئيات بيشتری اضافه اضافه خواهد شد . عمليات فوق تا استخراج و مشخص شدن تمامی جزئيات لازم در رابطه با يک مرحله خاص ادامه خواهد يافت . عمليات بهسازی ( پالايش ) يکطرفه ، زمانی متوقف می گردد که کد واقعی يک تابع نوشته گردد .محوريت فرآيند فوق ، تبديل الگوريتم های ماکرو به ميکرو است :

Input Step->ReadKeyboard( ) ReadSetupTable( ) ->ReadTable1( ) ->(Code) ReadTable2( ) ReadTable3( )

• UML ، از کلمات Unified Modeling Language اقتباس شده است . مزيت استفاده از UML ، تفکر مبتنی بر برنامه نويسی شی گراء است .بلاک های اوليه ايجاد UML کلاس ، خصلت و متد ناميده می شوند. دياگرام های کلاس UML تمام سه عنصر OOP را در يک دياگرام مناسب نمايش می دهند .
• در OOP ، واژه های Private و Public به نحوه دستيابی به خصلت ها بر می گردد . اگرخصلتی از نوع Private باشد ،امکان تغيير آن صرفا" برای کسانی که به کلاس فوق تعلق دارند، وجود خواهد داشت .اگر خصلتی از نوع Public باشد ، ساير اشياء امکان دستيابی کامل به خصلت را ( اعمال تغييرات مورد نظر ) خواهند داشت.