پروژه UML رزرو بلیط آنلاین
با پیشرفت تکنولوژیهای سیستمهای اطلاع رسانی ، سمت و سوئی که این گونه سیستمهای اطلاعاتی پیدا نموده اند به علت حجم انبوه اطلاعات بیشتر به سمت سیستمهای پویایی بوده که مبتنی بر پایگاه های داده ای قدرتمند می باشند.
در این میان نباید نقش طراحان و تحلیل گران این گونه سیستمها را نادیده گرفت. چرا که در صورت نبود یک تحلیل مناسب از یک سیستم ، نمی توان از آن سیستم به نحو اساسی استفاده نمود.
در سیستم جاری (سیستم نرم افزاری رزرو بلیط آژانس هواپيمايي) سعی برآن شده که با روش تحلیل UML به بررسی سیستم با دید نرم افزاری پرداخته شود.
مراحل مختلف طراحی و تحلیل به شرح ذیل انجام خواهد شد:
• درفصل اول پروژه به بررسی Use Case ها و سناریوی Actor ها که در حقیقت وظائف آنها و روالهایی است که انجام می شود می پردازیم.
• در فصل دوم به بررسی Class Diagram خواهیم پرداخت.
• در فصل سوم به بررسی Sequence Diagram ها (نمودارهای توالی) خواهیم پرداخت.
• در فصل چهارم به بررسی Collaboration Diagrams خواهیم پرداخت.
• در فصل پنجم به بررسی نمودارهای Activity خواهیم پرداخت.
• در فصل ششم به بررسی نمودارهای StateCharts خواهیم پرداخت.
• در فصل هفتم به بررسی ER Diagram یا نمودار Entity Relations پرداخته خواهد شد.
• در فصل هشتم به بررسی و رسم نمودارهای DFD (نمودارهای جریان داده ها) خواهیم پرداخت.
• در فصل نهم به طراحی پایگاه داده خواهیم پرداخت.
• در نهایت در فصل دهم ب بررسی Source برنامه خواهیم پرداخت.
با بهره گیری از پایه کامپیوتر و زبانهای برنامه نویسی بسیار قوی ، سیستمهای نرم افزاری زیادی در سراسر جهان پا به عرصه حیات نهاده اند. پروژه های نرم افزاری مختلفی طراحی و پیاده سازی گردیده اند که می توان اطلاعات ثبت شده در آنها را با سرعت بسیار زیادی بدست آورد.
این گونه نرم افزارها مزایای بسیار زیادی دارند. البته در حال حاضر با بهره گیری از ویژگیهای شئ گرایی به قابلیتهای این سیستمها اضافه شده اند و امنیت اطلاعات را بسیار بالا برده و بیشتر و بهتر می توان از ابزار و امکانات سخت افزاری و نرم افزاری موجود استفاده کرد.
هدف سیستم جاری
هدف از طراحی و پیاده سازی این سیستم ، نر م افزاری است که با آن بتوان در آن عملیات رزرو و فروش بلیط را به صورت آنلاین انجام داد.
زبان تحلیل سیستم
تحلیل سیستم با استفاده از زبان مدلسازی یکنواخت UML انجام خواهد شد. زبان مدلسازی یکنواخت یا Unified Modeling Language) UML)، یک زبان مدلسازی است که برای تحلیل وطراحی سیستمهای شی‌گرا بکار می‌رود. UML اولین بار توسط شرکت Rational ارائه شد و پس از آن از طرف بسیاری از شرکتهای کامپیوتری و مجامع صنعتی و نرم‌افزاری دنیا مورد حمایت قرار گرفت. به طوریکه تنها پس از یک سال ، توسط گروه Object Management Group ، به عنوان زبان مدلسازی استاندارد پذیرفته شد. UML تواناییها و خصوصیات بارز فراوانی دارد که می‌تواند به طور گسترده‌ای در تولید نرم‌افزار استفاده گردد.
تاریخچة UML
دیدگاه شی‌گرایی (Object Oriented) از اواسط دهه 1970 تا اواخر دهه 1980 در حال مطرح شدن بود. در این دوران تلاشهای زیادی برای ایجاد روشهای تحلیل و طراحی شی‌گرا صورت پذیرفت. در نتیجة این تلاشها بود که در طول 5 سال یعنی 1989 تا 1994، تعداد متدولوژیهای شی‌گرا از کمتر از 10 متدولوژی به بیش از 50 متدولوژی رسید. تکثر متدولوژیها و زبانهای شی‌گرایی و رقابت بین اینها به حدی بود که این دوران به عنوان "جنگ متدولوژیها" لقب گرفت. از جمله متدولوژیهای پرکاربرد آن زمان می‌توان از Booch، OOSE، OMT، Fusion، Coad-Yourdan، Shlayer-Mellor وغیره نام برد. فراوانی و اشباع متدولوژیها و روشهای شی‌گرایی و نیز نبودن یک زبان مدلسازی استاندارد، باعث مشکلات فراوانی شده بود. از یک طرف کاربران از متدولوژیهای موجود خسته شده بودند، زیرا مجبور بودند از میان روشهای مختلف شبیه به هم که تفاوت کمی در قدرت و قابلیت داشتند یکی را انتخاب کنند. بسیاری از این روشها، مفاهیم مشترک شی‌گرایی را در قالبهای مختلف بیان می‌کردند که این واگرایی و نبودن توافق میان این زبانها، کاربران تازه‌کار را از دنیای شی‌گرایی زده می‌کرد و آنها را از این حیطه دور می‌ساخت. عدم وجود یک زبان استاندارد، برای فروشندگان محصولات نرم‌افزاری نیز مشکلات زیادی ایجاد کرده بود.
اولین تلاشهای استانداردسازی از اکتبر 1994 آغاز شد، زمانی که آقای Rumbaurgh صاحب متدولوژی OMT به آقای Booch در شرکت Rational پیوست و این دو با ترکیب متدولوژیهای خود، اولین محصول ترکیبی خود به نام "روش یکنواخت" را ارائه دادند. در سال 1995 بود که با اضافه شدن آقای Jacobson به این دو، روش یکنواخت ارائه شده با روش OOSE نیز ترکیب شد واین خود سبب ارائة UML نسخة 0.9 در سال 1996 گردید. سپس این محصول به شرکتهای مختلفی در سراسر جهان به صورت رایگان ارائه شد و استقبال شدید شرکت‌ها از این محصول و تبلیغات گسترده شرکت Rational، سبب آن شد که گروه OMG، نسخة 1.0 UML را به عنوان زبان مدلسازی استاندارد خود بپذیرد. تلاشهای تکمیلی UML استاندارد ادامه پیدا کرد و نسخة 1.1 آن در سال 1997 و نسخه 1.3 آن در سال 1999 ارائه گردید.
UML چیست؟
UML یا زبان مدلسازی یکنواخت، زبانی است برای مشخص کردن (Specify)، مصورسازی (Visualize)، ساخت (Construction) و مستندسازی (Documenting) سیستمهای نرم‌افزاری و غیر نرم‌افزاری و نیز برای مدلسازی سیستمهای تجاری. اما چرا مدل و مدلسازی؟
ایجاد یک مدل برای سیستمهای نرم‌افزاری قبل از ساخت یا بازساخت آن، به اندازه داشتن نقشه برای ساختن یک ساختمان ضروری و حیاتی است. بسیاری از شاخه‌های مهندسی، توصیف چگونگی محصولاتی که باید ساخته شوند را ترسیم می‌کنند و همچنین دقت زیادی می‌کنند که محصولاتشان طبق این مدلها و توصیفها ساخته شوند. مدلهای خوب و دقیق در برقراری یک ارتباط کامل بین افراد پروژه، نقش زیادی می‌توانند داشته باشند. شاید علت مدل کردن سیستمهای پیچیده این باشد که تمامی آن را نمی‌توان یکباره مجسم کرد، بنابراین برای فهم کامل سیستم و یافتن و نمایش ارتباط بین قسمتهای مختلف آن، به مدلسازی می‌پردازیم. UML زبانی است برای مدلسازی یا ایجاد نقشه تولید نرم‌افزار.
به عبارت دیگر، یک زبان، با ارائه یک فرهنگ لغات ویک مجموعه قواعد، امکان می‌دهد که با ترکیب کلمات این فرهنگ لغات و ساختن جملات، با یکدیگر ارتباط برقرار کنیم. یک زبان مدلسازی، زبانی است که فرهنگ لغات و قواعد آن بر نمایش فیزیکی و مفهومی آن سیستم متمرکزند. برای سیستمهای نرم‌افزاری نیاز به یک زبان مدلسازی داریم که بتواند دیدهای مختلف معماری سیستم را در طول چرخة تولید آن، مدل کند.
فرهنگ واژگان و قواعد زبانی مثل UML به شما می‌گویند که چگونه یک مدل را بسازید و یا چگونه یک مدل را بخوانید. اما به شما نمی‌گویند که در چه زمانی، چه مدلی را ایجاد کنید. یعنی UML فقط یک زبان نمادگذاری (Notation) است نه یک متدولوژی. یک زبان نمادگذاری شامل نحوة ایجاد و نحوة خواندن یک مدل می‌باشد، اما یک متدولوژی بیان می‌کند که چه محصولاتی باید در چه زمانی تولید شوند و چه کارهایی با چه ترتیبی توسط چه کسانی، با چه هزینه‌ای، در چه مدتی و با چه ریسکی انجام شوند.
ویژگیهای UML
UML دارای ویژگیهای بارز فراوانی است که در این قسمت به آنها می‌پردازیم. UML یک زبان مدلسازی است اما چیزی فراتر از چند نماد گرافیکی است. بطوریکه در ورای این نمادها، یک سمانتیک (معناشناسی) قوی وجود دارد، بطوریکه یک تولیدکننده می‌تواند مدلهایی تولید کند که تولید‌کننده‌های دیگر و یا حتی یک ماشین آن را بخواند و بفهمد. بنابراین یکی دیگر از نقش‌های مهم UML "تسهیل ارتباط" بین اعضای پروژه و یا بین تولیدکنندگان مختلف می‌باشد. این ارتباط بسیار مهم است. شاید دلیل اصلی اینکه تولید نرم‌افزار به صورت فریبنده‌ای دشوار است، همین عدم ارتباط مناسب بین اعضای پروژه باشد و اگر در تولید نرم‌افزار، بین اعضای پروژه گزارشهای هفتگی و مداوم وجود داشته باشد، بسیاری از این دشواریها برطرف خواهد شد.
البته این را هم باید در نظر گرفت که UML کمی پیچیده است و این به خاطر آن است که سعی شده است نمودارهایی فراهم شود که در هر موقعیتی و با هر ترتیبی قابل استفاده باشند. دلیل دیگر پیچیدگی از آنجا ناشی می‌شود که UML ترکیبی است از زبانهای مختلف، که برای حفظ سازگاری و جمع کردن خصوصیات مثبت آنها، ناگزیر از پذیرش این پیچیدگی می‌باشد.
UML موفقیت طرح را تضمین نمی‌کند، اما در عین حال خیلی چیزها را بهبود می‌بخشد. به عنوان مثال استفاده از UML، تا حد زیادی، هزینه‌های ثابتی نظیر آموزش و استفاده مجدد از ابزارها را در هنگام ایجاد تغییر در سازمان و طرحها کاهش می‌دهد.
مساله دیگر اینکه، UML یک زبان برنامه‌نویسی بصری (visual) نیست، اما مدلهای آن را می‌توان مستقیماً به انواع زبانهای مختلف ارتباط داد. یعنی امکان نگاشت از مدلهای UML به کد زبانهای برنامه‌نویسی مثل Java و VC++ وجود دارد که به این عمل "مهندسی روبه‌جلو" می‌گویند. عکس این عمل نیز ممکن است؛ یعنی این امکان وجود دارد که شما بتوانید از کد یک برنامه زبانی شی‌گرا، مدلهای UML معادل آن را بدست آورید. به این عمل "مهندسی معکوس" می‌گویند. مهندسی روبه‌جلو و معکوس از مهمترین قابلیتهای UML به شمار می‌روند، البته نیاز به ابزار Case مناسبی دارید که از این مفاهیم پشتیبانی‌کنند.
اگر با زبانهای مدلسازی دیگر کار کرده باشید، برای کار با UML مشکل چندانی نخواهید داشت. اما برای شروع کار با UML به عنوان اولین زبان مدلسازی، بهتر است فقط با نمودارهای خاصی کار کنید. برای این کار بهتر است ابتدا با نمودارهای مورد کاربرد و تعامل کار کنید و پس از مدتی کار و آشنا شدن با ویژگیهای اولیة آن، به یادگیری و استفاده از نمودارها واجزای دیگر بپردازید. در مقایسه با زبانهای مدلسازی دیگر مثلER و زبان فلوچارتی DR، زبان UML نمودارهای قویتر و قابل‌فهمتری را ارائه می‌دهدکه شامل تمامی مراحل چرخة حیات تولید نرم‌افزار (تحلیل، طراحی، پیاده‌سازی و تست) می‌شود.
یکی دیگر از ویژگیهای مهم UML این است که مستقل از متدولوژی یا فرایند تولید نرم‌افزار می‌باشد و این بدان معنی است که شما برای استفاده از UML، نیاز به استفاده از یک متدولوژی خاص ندارید و می‌توانید طبق متدولوژیهای قبلی خود عمل کنید با این تفاوت که مدلهایتان را با UML نمایش می‌دهید. البته مستقل‌بودن از متدولوژی و فرایند تولید، یک مزیت برای UML می‌باشد؛ زیرا بسیاری از انواع پروژه‌ها و سیستمها نیاز به متدولوژی خاص خود دارند. اگر UML در پی پیاده کردن همة اینها بر می‌آمد، یا بسیار پیچیده می‌شد و یا استفاده خود را محدود می‌کرد. البته متدولوژیهایی براساس UML در حال شکل‌گیری می‌باشند.
از دیگر ویژگیهای UML می‌توان به پشتیبانی از مفاهیم سطح بالای شی‌گرایی مثل Collaboration، Framework، Pattern و Component اشاره کرد. همچنین UML با استفاده از یک سری مکانیزمهای گسترش‌پذیر امکان می‌دهد که بتوان زبانهای مدلسازی جدیدتری (با گسترش مفاهیم پایه‌ای موجود) ایجادکرد.
در ادامه به بررسی و تحلیل سیستم آژانس هواپيمايي خواهیم پرداخت.
Use Case Diagrams
در این قسمت به بررسی و شناخت Use Case ها ، Actor ها ، رسم Use Case Diagram ها و در نهایت نوشتن سناریویی برای هر یک از Use Case Diagram ها خواهیم پرداخت. در ابتدا بایستی بدانی که مفاهیم هر یک از عبارات فوق چیست؟
Use case چیست؟
Use Case ها که در فاز آنالیز پروژه برای شناساسیی و تقسیم بندی فعالیت های سیستم استفاده می شوند و می تونند به عنوان سرویس ها یا کارکردهایی که سیستم برای کاربران خودش فراهم می کنه نیز توصیف بشوند.
دو دیدگاه وجود دارد: یکی داخلی , دید ساختاری و دیگری خارجی و دید وظیفه گرایی(task Oriented)
در دیدگاه اول ما باید کلاسها و متدها را تعریف کنیم و سپس واسطهای کاربری (user interface)را تعریف کنیم. مشکل اینجاست که برای کاربر مهمترین چیز رفتار سیستم است ولی واسطهای کاربری تنها قسمت آخر فرآیند را تعریف می کنند. و این مارو به سمت مشکلاتی می بره نظیر اینکه سیستم تمام کارکردهایی که ما می خواهیم در اختیارمون قرار نمی ده و یا کارکردهایی رو داره که مورد نیاز ما نبوده.
در دید دوم ،سیستم از Actor ها و فعالیتها و کلاسهایی که به فعالیتها وصل شده اند پشتیبانی می کند.در این دیدگاه هیچ کار ناخواسته ای وجود ندارد و سیستم تمام فعالیتهای کاربر را پشتیبانی می کند که همه آنها در Use case Diagram نمایش داده می شود.
Actor چیست؟
Actor هـا نقشـهایـی را ارائـه مـی دهـنـد کـه تـوســط کـاربــران سیــــسـتمـــهای اطـلاعـاتی (Information System=IS) انجام می شود. این Actor ها می توانند انسانها ,کامپیوترها , سخت افزارها و حتی نرم افزار ها باشند. تنها چیزی که آنها را Actor می کند این است که آنها باید بیرون از قسمتی باشند که توسط سیستم به use case ها تقسیم شده است ویکسری ورودی برای سیستمهای اطلاعاتی فراهم می کنند و یکسری از آنها خروجی می گیرند.
دیاگرام use case چیست؟
دیاگرامهای use case با استفاده از Use case و Actor عملکرد (Functionality) سیستم رامدلسازی می کنند.
ارتباطات بین use case ها چگونه است؟
ارتباط بین use case ها یا به صورت Extends است و یا به صورت Uses .Uses دلالت بر این دارد که یک use case برای انجام وظیفه و فعالیتش نیازمند use case دیگری است. Extends دلالت بر این دارد که use case ی یک امکان و گزینه اختیاری برای use case دیگر است که در بعضی شرایط از آن استفاده می کند.
شناسائی Actor های سیستم
Actor ها در حقیقت مکانیسمی برای طبقه بندی External User ها هستند. Actor ها می توانند در چهار گروه User ، Applications ، Devices و External Events باشند. در سیستم جاری با دو نوع اکتور سرو کار داریم:
• Actor کاربر
• Actor External Events
Actor کاربر
کاربران سیستم در حالت کلی شامل Actor مدیر وب سایت ، Actor مشتریان وب سایت (مسافرین) و Actor کارمندان شرکت می باشند.
Actor مسافر و Actor کارمند و Actor مدیر با رابطه Generalization با Actor کاربر سیستم ارتباط دارند و تمامی خواص Actor کاربر سیستم را دارا هستند. در حالت کلی ، کاربر به استفاده کننده سیستم نرم افزاری رزرو بلیط گفته می شود که سایر تعاریف Actor های سیستم از آن مشتق می شود. (ارث بری دارند)
مفهوم ارث بری در نمودار صفحه بعدی بدین معنی است که در حالت کلی Actor کاربر سیستم دارای یک سری اطلاعات اعم از اطلاعات تماس ، اطلاعات شناسنامه ای و . . . می باشد که می توان در تعریف Actor ها آنها را در کلاس کلی تعریف نمود و در تعریف سایر خواص مربوط به Actor ها موارد تکراری را از کلاس اصلی مشتق گرفت. (در نمودار کلاس به صورت کامل در این مورد رسم نمودار خواهد شد)
Actor مدیر
شرح: مدیر در بالاترین مقام از نظر دسترسی و مدیریت در شرکت و در سيستم آژانس هواپيمايي را داراست و کار اصلی کدیریت در سيستم آژانس هواپيمايي را انجام می دهد و بر نحوه کارکرد کارمندان و سيستم آژانس هواپيمايي اظراف کامل دارد.
Actor مسافر
شرح: مسافر کسی است که برای رزرو و یا خرید بلیط به وب سایت مراجعه می نماید و عملیات خود را در یکی از قالبهای ذکر شده (رزرو و یا خرید) انجام می دهد.
Actor کارمندان
کارمند کسی است که تمامی عملیات مربوط به هماهنگ سازی و تطبیق عملیات رزرو بلیط را که توسط مسافرین ثبت شده انجام می دهد. کارندان موظف به گزارش دهی روزانه به مدیر سیستم می باشند.
External Events Actor
این گونه Actor ها به صورت Periodic با سیستم محاوره دارند. در سیستم جاری یک Timer برای ثبت ونگهداری زمان شروع و پایان استفاده کاربران سیستم (تمامی اکتورها) تعبیه گردیده است.
سایر External Events Actor در هنگام نیاز بررسی خواهند شد.
شناسائی Use Case ها
Functionality های زیر به درخواست مشتری پس از چند مرحله مصاحبه شناسایی و استخراج گردیده است:
1- ثبت نام در سیستم (Sign Up)
2- ورد به سیستم ( Log In / Sign In)
3- خروج از سیستم (Sign Out)
4- مشاهده فهرست زمانی و ساعات سرویسها و حرکتها (Main Menu)
5- ثبت بلیط (Ticket Register)
6- رزرو بلیط (Ticket Reserve)
7- پرداخت وجه به صورت آنلاین (Online Pay Money)
8- تائید تکمیل عملیات (Confermation)
9- تعریف سرویس مسافرتی جدید (Define New Travel Service)
10- استخدام کارمند (Staff Employment)
11- صندوق پیام مدیر (Admin Mailbox)
12- تعریف شرح وظائف (functions of the organs)
13- صندوق پیام کارمند (Staff Mailbox)
14- گزارش عملکرد ( Report Of Jobs)
برخی از Use Case های فوق مرکب هستند و در توضیحات سناریوها نیز به صورت مرکب توضیح داده خواهند شد.