شکل ۳ – ۱۱٫ نمودار use case نظارت واحد تدارکات بر موجودی انبار
با توجه به شکل ۳-۱۲، به منظور درخواست قطعه از انبار توسط واحد تولید، انبار دار به بررسی وجود کالای در خواستی و تایید و چاپ گزارش درخواستی می پردازد که عاملی مسئول گزارش گیری انبار دار از درخواست ارسالی می باشد. در صورت وجود مواد مورد نیاز به مسئول مواد اولیه تحویل داده می شود. در صورت تغییر مواد اولیه مورد نیاز واحد تولید، چنانچه تغییر قبل از تائید انبار باشد، می توان بر روی درخواست تغییر ایجاد کرده و درخواستی را ویرایش یا اضافه کرد ولی چنانچه انباردار درخواست را تائید نموده باشد، اپراتور تغذیه خط قادر به تغییر لیست درخواستی نخواهد بود و باید درخواست دیگری صادر و به انبار اطلاع دهد. سرویس ویرایش درخواست قطعات مسئول این عملیات می باشد.
۱٫سرویس درخواست قطعه از انبار
-
- سرویس گزارش گیری انباردار از درخواست ارسالی
-
- سرویس ویرایش درخواست قطعات
شکل ۳-۱۲ نمودار use case درخواست قطعات مورد نیاز واحد تولید از انبار(مواد اولیه)
پس از انتخاب سفارش آماده به اجرا، به منظور بررسی وضعیت موجودی/ عدم وجودی محصول درخواستی، اطلاعات به بخش انبار فرستاده می شوند. (به عبارتی عاملی مسئول بررسی وضعیت موجودی انبار به واسطه ی سیستم می باشد). چنانچه مشتری در هر مرحله از سفارش خواستار کنسل کردن سفارش درخواستی باشد، سرویسی عملیات حذف اطلاعات مربوطه را انجام می دهد. همچنین، در صورتی که مشتری خواستار هرگونه تغییراتی در سفارش مورد نظرش باشد، اطلاعات ویرایش شده جهت اعمال تغییرات به بخش انبار ارسال می شود. در غیر این صورت، این سرویس وضعیت را به حالت سفارش اجرا شده، ثبت می کند.
۱٫سرویس اجرای سفارش درخواستی
-
- سرویس اعمال تغییر در سفارش
-
- سرویس اولویت بندی سفارشات
-
- سرویس کنسل کردن سفارش محصول درخواستی
-
- سرویس بررسی وضعیت موجودی انبار(محصول)
-
- سرویس پرداخت هزینه سفارشات
شکل ۳-۱۳٫ نمودار use case اجرای محصول درخواستی مشتری
به منظور پرداخت سفارش اجرا شده مطابق شکل ۳-۱۴ ابتدا به واسطه ی سرویسی عملیات صدور صورتحساب انجام می شود. بدین صورت که چنانچه مشتری مشمول تخفیف باشد، در محاسبه ی صورتحساب به اندازه ی میزان تخفیف از کل هزینه کسر می گردد. پس از صدور صورتحساب و ارسال آن برای مشتری، مشتری بایستی اقدام به پرداخت هزینه کند. بدین منظور سرویسی مسئولیت پرداخت آنلاین هزینه ها را بر عهده دارد. تا در صورتی سفارش به مشتری تحویل داده می شود که پرداخت صورتحساب به صورت کامل انجام گرفته باشد. از این رو پس از ثبت میزان هزینه پرداختی توسط مشتری، عاملی مسئول کنترل وضعیت پرداختی مشتریان می باشد به نحوی که در صورت پرداخت کامل صورتحساب، وضعیت پرداخت به حالت وضعیت کامل بروز رسانی شده و در غیر این صورت ضمن ثبت وضعیت ناکامل به منظور پرداخت میزان هزینه ی باقی مانده، گزارشی از وضعیت پرداخت به بخش فروش ارسال می شود تا پرداخت میزان هزینه باقی مانده را پیگیری کند. با این تفاسیر می توان گفت که مدیریت اجرای میزان هزینه ی سفارشات پرداختی مستلزم اجرای ۳ سرویس ریز دانه ی صدور صورتحساب، پرداخت آنلاین و بررسی وضعیت پرداخت صورتحساب می باشد.
( اینجا فقط تکه ای از متن فایل پایان نامه درج شده است. برای خرید متن کامل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )
۱٫سرویس پرداخت هزینه سفارش اجرا شده
-
- سرویس صدور صورتحساب
-
- سرویس پرداخت آنلاین
-
- سرویس بررسی وضعیت پرداخت صورتحساب
شکل ۳ – ۱۴٫ نمودار use case مدیریت هزینه ی سفارشات اجرا شده
با توجه به شکل ۳-۱۵سفارش اجرا شده باید به مشتری تحویل داده شود، در صورتی که مشتری محصول خود را در زمان تعیین شده، دریافت نکرده باشد، با اعلام عدم دریافت، پیگیری های لازم توسط بخش فروش انجام می گیرد و با دریافت تائیدیه دریافت وضعیت دریافت محصول در data storeتحت عنوان سفارش تحویل داده شده به روز رسانی می شود.
-
- سرویس بررسی وضعیت تحویل محصول به مشتری
شکل ۳ – ۱۵٫ نمودار use case تحویل محصول به مشتری
با توجه به نمودار کاربری ۳ –۱۶ مشتری به واسطه ی این سیستم، بایستی قادر به ثبت گزارشات بازخوردهایی از سفارشات دریافت شده باشد. در راستای این بازخوردهای ثبت شده، بخش پشتیبانی، به واسطه ی سرویسی، قادر به بررسی وضعیت رفع/ عدم رفع شکایت مشتری از سفارش دریافتی خواهد بود. که به منظور اجرای این سرویس بایستی عاملی، عملیات مربوط به بررسی وجود / عدم وجود شکایت مشتری از سفارش را انجام دهد.
-
- سرویس بررسی وضعیت رفع مشکل مشتری
-
- سرویس بررسی وجود / عدم وجود شکایت مشتری از سفارش دریافتی
شکل ۳ – ۱۶٫ نمودار use case پشتیبانی مشتری
۳-۷ الگوی راه حل پیشنهادی متدولوژی SOMAبرای استفاده در سیستم های اطلاعاتی
با توجه به این مسئله که بسیاری از سازمانهای بزرگ چندین سیستم اطلاعاتی را برای ارائه سیستم های مختلفی که از سازمان انتظار می رود نصب کرده اند، برخی از سرویس های قابل استخراج از سیستم اطلاعاتی به عنوان یکی از این سیستم ها نمایش دادیم. سرویس های این سیستم اطلاعاتی می توانند با ارسال یک پیام درخواست که معمولا مبتنی بر فایل XML می باشند، در دسترس قرار بگیرند. از آنجاییکه هریک از سرویس های سیستم و هر برنامه کاربردی دیگر، می توانند در هر جایی مستقر شده، و پروتکل ها و فرمت ها ی داده مختلفی را به کار ببرند، به منظور استفاده از سرویس های این سیستم، درخواست کننده های این سیستم اطلاعاتی در داخل و یا خارج از سازمان، در انتقال یا یکپارچه سازی نقطه به نقطه با مشکلاتی از جمله عدم دسترس پذیری و استفاده مجدد از یک سرویس در میان چندین مصرف کننده مواجه می شوند.
برای رفع این گونه مشکلات می توان، یکی از الگوهای راه حل پیشنهادیSOMA و معماری سرویس گرا، یعنی مولفه ی میان افزار باس سرویس سازمان[۱۲] را به کار برد. از دیدگاه مصرف کنندگان برنامه های کاربردی و سرویس ها، یک سرویس می تواند به سادگی، پیرامون یک ESB و با بهره گرفتن از انتقال پیام، درخواست شده و در دسترس قرار بگیرد. همچنینESB ، امکان انتقال فرمت های داده را، با تبدیل فرمت برنامه ی کاربردی درخواست کننده سرویس به یک استاندارد باز و تبدیل استاندارد باز به فرمت متعلق به برنامه کاربردی، و بالعکس را فراهم می کند.
به طور کلی ESBاقدامات زیر را انجام می دهد:
-
- امکان ایجاد اتصال سست بین سرویس ها را فراهم می کند.
-
- امکان این را فراهم می کند تا سرویس ها با یکدیگر براساس ملزومات QOS و طی تراکنش های خاص نظیر سنکرون، آسنکرون، دائمی و غیر دائمی، اتصال سست و اتصال ضعیف، ارتباط برقرار می کنند.
- به عنوان زیر ساختی متداول برای معماری سرویس گرا، رخدادها و پیغام های آن می باشد، به نحوی که پلت فرم های ناهمگون را به صورت شفاف به هم متصل می سازد.