زبان مدلسازی یکنواخت یا، Unified Modeling Language (UML) یک زبان مدلسازی است که برای تحلیل وطراحی سیستمهای شی‌گرا بکار می‌رود. UML اولین بار توسط شرکت Rational ارائه شد و پس از آن از طرف بسیاری از شرکتهای کامپیوتری و مجامع صنعتی و نرم‌افزاری دنیا مورد حمایت قرار گرفت؛ به طوریکه تنها پس از یک سال، توسط گروه Object Management Group ، به عنوان زبان مدلسازی استاندارد پذیرفته شد. UML تواناییها و خصوصیات بارز فراوانی دارد که می‌تواند به طور گسترده‌ای در تولید نرم‌افزار استفاده گردد. در ادامة این مقاله ابتدا به تاریخچة UML و در ادامه به معرفی، ویژگیها و نمودارهای آن پرداخته می‌شود و در پایان، روند حرکت به سمت 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 با استفاده از یک سری مکانیزمهای گسترش‌پذیر امکان می‌دهد که بتوان زبانهای مدلسازی جدیدتری (با گسترش مفاهیم پایه‌ای موجود) ایجادکرد.
نمودارهای UML :
در این بخش به معرفی نمودارهای UML می‌پردازیم وعلاقمندان به آشنایی بیشتر را، دعوت به مطالعه مراجع معرفی شده، می‌نماییم:
نمودار کلاس (Class Diagram):
این نمودار،کلاسها، واسطها و همکاری و روابط بین آنها را نمایش می‌دهد. و نمودار اصلی و مرکزی UML میباشد. که بیان‌کننده ساختار ایستای سیستم نرم‌افزاری میباشد.
نمودار اشیاء Object Diagram) ( :
این نمودار، اشیاء سیستم و روابط بین آنها را نمایش می‌دهد. در واقع یک تصویر لحظه‌ای از نمودار کلاس میباشد.
نمودار موردکاربرد (Usercase Diagram) :
این نمودار، تعامل کاربران خارجی و سیستم را مدل می‌کند و از جهاتی شبیه نمودار سطح صفر DFD میباشد که جنبه‌های رفتاری سیستم را نمایش می‌دهد. این نمودار نقطه ورودی برای تمامی نمودارهای دیگری است که به تشریح نیازمندیها و معماری و پیاده‌سازی سیستم می‌پردازند.
نمودارهای تعامل (Interaction Diagram ) :
این نمودارها، بیان کننده تعامل هستند که شامل اشیاء مختلف و روابط بین آنها و همچنین پیغامهایی که بینشان رد و بدل می‌شود می‌باشند. این نمودارها جنبه‌های پویای یک سیستم را مدل می‌کنند و خود بر دو نوعند: نمودار توالی(Sequence Diagram) که ترتیب زمانی تعامل‌ها را نشان می‌دهد و نمودار همکاری(Collaboration Diagram) که تاکید بر نمایش ساختاری تعامل‌ها دارد.
نمودارحالت (Statechart Diagram):
این نمودار، بیان‌کننده جنبه‌های رفتاری سیستم میباشد و در واقع توصیف رسمی یک کلاس بوده که شامل حالات، انتقال بین حالات، رخدادها و فعالیتها میباشد. از این نمودارها برای نمایش دادن چرخه حیات اشیاء یک کلاس خاص نیز میتوان استفاده کرد.
نمودار فعالیت(Activity Diagram):
این نمودار، نوع خاصی است از نمودار حالت، که انتقال جریان از یک فعالیت به فعالیت دیگر را نمایش می‌دهد. این نمودار جنبه‌های پویای یک سیستم را نمایش می‌دهد. در واقع حالات این نمودار، گامهای ترتیبی انجام یک عمل را نمایش می‌دهند.
نمودار اجزاء(Component Diagram):
از جمله نمودارهای پیاده‌سازی میباشد و سازماندهی و روابط بین مجموعه‌ای از اجزاء را نمایش می‌دهد. این نمودار، جنبه های ایستای پیاده‌سازی یک سیستم را مدل می‌کند.
نمودار بهکارگماری(Deployment Diagram):
پیکربندی گره‌های پردازشی زمان اجرا را نمایش می‌دهد. که برای مدل کردن جنبه‌های ایستای بهکارگماری یک معماری بکار می‌رود. همچنین نمایش‌دهندة اجزای استفاده‌شده زمان اجرا مثل کتابخانه‌های DLL، فایل‌های اجرایی، کدهای مبدا و روابط بین آنها میباشد.البته این نمودارها تمام نمودارهای UML نیستند بلکه بسته به نیاز و با کمک ابزارهای Case میتوان نمودارهای دیگری نیز تعریف و استفاده کرد.
روند حرکت به سمت UML در جهان:
قبل از ارائه UML، زبان مدلسازی استانداردی وجود نداشت و استفاده‌کنندگان مجبور بودند از میان زبانهای مختلف موجود که هیچیک تقریباً کامل نبودند و تفاوتهایی با هم داشتند، یکی را انتخاب کنند. تفاوتهای زبانهای مدلسازی، چندان قدرت مدلسازی را افزایش نداده بود، اما در عوض باعث افول صنعت شیگرایی و سردرگمی کاربران شده بود. در چنین شرایطی طبیعی بود که استقبال زیادی از یک زبان مدلسازی استاندارد که ویژگیهای بارز زیادی داشت، بشود. بسیاری از شرکتها در همان اوایل کار به UML روی آوردند و تعداد دیگری نیز پس از تثبیت UML، آن را به عنوان استراتژی تولید ومستندسازی خود پذیرفتند.
OMG که کنسرسیومی است متشکل از 700 شرکت معتبر آمریکا، از UML حمایت کرد و آن را به عنوان زبان مدلسازی استاندارد خود اعلام کرد. البته علاوه بر استاندارد شدن، حمایت جداگانه شرکتهای بزرگ دنیا مثل Hewlett-Packard، I-Logix، Microsoft، IBM، Oracle و بسیاری دیگر، خود سبب افزایش کاربرد آن در محافل صنعتی و نرم‌افزاری دنیا گردید. امروزه نیز با ارائه نسخه 1.3 و رفع مشکلات گذشته، روز به روز بر کاربران آن افزوده می‌شود.
روند حرکت به سمت UML در ایران:
در ایران حرکت برخی شرکتها به سمت UML سریعتر انجام شد؛ بطوریکه در همان زمان استاندارد شدن UML در سال 1997، شرکتهایی در ایران، این ابزار را به عنوان استاندارد خود پذیرفتند و از آن در تولید محصولات خود استفاده کردند.
یکی از مشکلات پذیرش این زبان در ایران، مقاومتهایی است که در رابطه با خود شیگرایی مطرح می‌شود. البته نظیر این مقاومتها در دنیا نیز وجود داشت و سرو صداهای بسیاری را سبب شد. اما تا قبل از ظهور UML و با ارائه متدهای فراوان شیگرایی، این مشکل تا حدودی حل شده بود.
با توجه به روند حرکت شتابان به سمت UML در دنیا و با توجه به اهمیت استانداردسازی برای صنعت نرم‌افزار کشور، حرکت هرچه‌سریعتر به سوی این فناوری در کشور توصیه می‌شود.
اهمیت ترویج UML در کشور:
در کشور ما شرکتهای نرم‌افزاری که روشهای علمی طراحی و مهندسی نرم‌افزار را به کار برند بسیار کمیاب هستند. در واقع رقابت بین شرکتها بیشتر بر سر کاهش قیمت است و نه بهبود کیفیت. ممکن است تصور شود عامل اصلی بروز این مشکل، فرهنگ مصرف غلط در کشور است و لذا حل مشکل نیز به دست مصرف‌کنندگان است. اما بایستی از خود پرسید که مصرف‌کنندگان چگونه خواهند توانست یک محصول نرم‌افزاری را ارزیابی کرده و انتظارات خود را به طور دقیق مطرح نمایند؟ در این زمینه دولتها وظایف مهمی دارند و می‌توانند ابزارهای لازم را فراهم نمایند.
هرچند UML یک استاندارد برای تشخیص کیفیت نرم‌افزارها نیست ولی استانداردی برای مدلسازی نرم‌افزار است ولذا مراحل مختلف تعریف، طراحی و حتی تست نرم‌افزار را تسهیل نموده و کار تیمی و ارزیابی ناظران خارجی راآسان و ممکن می‌نماید. اگر استفاده از UML در تولید نرم‌افزار در کشور به یک فرهنگ تبدیل گردد، گام بزرگی به سوی دقت، کیفیت، مستندسازی و رعایت اصول مهندسی نرم‌افزار برداشته شده است.
برای درک بیشتر این موضوع سعی می شود برای مثال گزارش تجزیه و تحلیل سناریوی تصحیح خرابی مربوط به مرکز مخابرات ایران ، بخش شبکه،طرح شبکه مدیریت مخابرات را مورد تجزیه وتحلیل قرار دهیم تا اینکه با این موضوع بیشتر مانوس شویم.
چکیده:
در این گزارش، به تشریح سناریوی تصحیح خرابی پرداخته می شود. این سناریو، از سناریوهای سرویس نگهداری است و پس از رخداد خرابی و تعیین محل خرابی فعال می شود. آگاهی از خرابی و تعیین محل آن می‌تواند توسط مشتری سرویس، گزارش مشکل از یک سیستم عملیاتی مدیریت دیگر، پایش عملکرد و یا از سرویس تعیین محل خرابی داده می شود. تصحیح خرابی را اگر بتوان به صورت اتوماتیک انجام داد، با توجه به نوع خرابی با الگوریتمهای ویژه ای به صورت نرم افزاری و سخت افزاری انجام می گیرد. اما اگر نتوان به صورت اتوماتیک انجام داد، به صورت دستی انجام می گیرد و نفرات با توان مندیهای آنها در زمینه رفع عیب مشخص می شود. در این سناریو، برای رفع عیب در مدت زمانی خاص سیستم دوباره پیکربندی می شود تا سرویس به مشتری ارائه شود. با تغییر مقطعی در پیکربندی شبکه به گونه ای رفع عیب انجام گرفته است. اما عیب همچنان در شبکه وجود دارد و سیستم معیوب را باید تعمیر کرد.کارکرد مدیریت پردازش عیب، اطلاعاتی مبنی بر فاصله سیستم معیوب تا OS را معلوم و افراد با مهارتهای برطرف کننده عیب مشخص می‌کند. حتی نوع کاری که برای رفع عیب نیاز است، تعیین می کند. در این سناریو از زبان مدل سازی یکپارچه شده در تجزیه و تحلیل سناریو استفاده شده است. در این گزارش، پس از تشریح سناریو توضیحاتی در مورد زبان مدل سازی یکپارچه شده و طبیق آن بر سناریو نمایش داده می شود. در این زبان اصولا از چند نوع نمودار برای تحلیل استفاده می شود. برای شبکه مدیریت مخابرات از نمودارهای Use Case ، ترتیب پردازش، فعالیت و نسبت بین اشیاء استفاده می‌شود. در این گزارش نمودارهای Use Case و فعالیت مطرح می‌شود.
1- مقدمه
سرویس تصحیح خرابی از سرویس های نگهداری که هم برای شبکه انتقال و هم شبکه سوییچ کاربرد دارد، ریشه اصلی عیبی که از سناریوی تعیین محل خرابی بدست آمده و برچسب مشکل آن هم مشخص شده است، به عنوان یک ورودی برای فعال سازی این سرویس به کار می رود. برای تست دقیق تر و رفع مشکل نیاز به رسیدگی دقیق و تعمیر آن است. این تست به منظور تأیید مشکل تعیین شده اجراء می گردد تا مشکل رفع شود. این سناریو دو بخش دارد:
الف- بخش تعمیر که با ورودی تعیین محل خرابی یا گزارش مشکل شروع می‌شود.
ب- بخش بهبود که به طور اتوماتیک انجام می گردد. در این جا به تشریح سناریو پرداخته می شود.
2 - تشریح سناریوی سرویس تصحیح خرابی
شکل یک، سناریو این سرویس را با کارکردهای مختلف آن شرح می دهد.
در این سناریو، مجموعه کارکردهای مختلفی از حوزه های مدیریت خرابی و پیکربندی وجود دارد که پشت سرهم در جهت پیاده سازی سرویس اجراء می شود.
از حوزه های مدیریت خرابی مجموعه کارکردهای سرپرستی مشکل، تصحیح خرابی، تست کردن و نظارت بر آلارم را می توان نام برد و در حوزه مدیریت پیکربندی، کنترل و وضعیت پیاده سازی می شود.
برای پیاده سازی هر کدام از مجموعه کارکردهای فوق نیاز به کارکردهای همان مجموعه می باشد که در این قسمت به تشریح این کارکردها پرداخته می شود.
- مجموعه کارکرد تعیین محل خرابی، تعیین محل خرابی شبکه است. این کارکرد معمولا با مجموعه گزارش آلارم از قسمت همبستگی و فیلتر آلارم فعال می شود و یا با گزارشی از رویدادهای پارامترهای کارایی و همچنین عبور از آستانه های پارامترهای کارایی که گزارش و سپس بستگی آن پیدا و فیلتر می شود، فعال می گردد.
در این سناریو، از خروجی بلوک عملیاتی (تعیین محل خرابی شبکه) پس از تعیین محل خرابی، ورودی برای سرپرستی برچسب مشکل تهیه می شود تا برچسبی برای آن صادر شود.
- در قسمت سرپرستی مشکل، بلوک عملیاتی وجود دارد که گزارشات مشکل را از سمت مشتری سرویس وارد سناریوی تصحیح خرابی می کند. این عمل طی کارکردهایی انجام می گیرد. به این ترتیب که ابتدا گزارش مشکل وارد می شود سپس اطلاعاتی به آن برای تشریح بیشتر مشکل افزوده می شود. می توان گزارش کردن مشکل را Cancel کرد و یا اطلاعات مشکل را اصلاح نمود. تعریفی مناسب برای قالب دستور گزارش مشکل ثبت می کند و یا می تواند این تعریف مشکل را حذف و یا اصلاح نماید. این قسمت مجموعه کارکرد، ورودی برای برچسب مشکل می شود.
- سرپرستی مشکل، پس از این که یکی از ورودیهای یک یا دو فعال شد، برچسب مشکلی را تهیه می کند که به مشتری و یا اپراتور OS ارائه دهد. این برچسب مشکل می تواند از طرف مجموعه کارکرد تعیین محل خرابی Cancel/Clear شود.
– پس از این مرحله فهرست بندی و توزیع سرپرستی نیروهای تعمیر انجام می گیرد. این مجموعه، ایجاد یک سفارش کار را پشتیبانی می کند که در این راستا ممکن است تعمیر، رشد شبکه یا فعال سازی سرویس را پشتیبانی کند. این مجموعه، ورودیهای دیگری از مدیریت پردازش تعمیر و یا تنظیم تعمیر توسط مشتری و یا تست (انتخاب مدار، همبستگی تست و محل خرابی) دارد. در حقیقت برای اینکه خروجی 10 بر اساس پردازشهای این بلوک عملیاتی ایجاد شود، ابتدا به ورودی 4 ، 5 ، 9 نیاز و برای ایجاد خروجی 19 به ورودی 13 علاوه بر بقیه ورودیها نیاز است. در این جا بر اساس توالی پردازشها به تشریح آنها پرداخته می شود.
- مجموعه کارکرد تصحیح خرابی، مدیریت پردازش تعمیر
تصحیح خرابی، داده هایی را برای تعمیر منتقل می کند. این داده مشخصاتی از خرابی و نحوه کنترل آنها و در صورت امکان جایگزین کردن تجهیزات دیگر یا تسهیلاتی که بتواند رفع عیب کند، می دهد. یکی از کارکردهایی که در سناریوی سرویس تصحیح خرابی مورد نیاز است، مجموعه کارکرد مدیریت پردازش تعمیر است. این مجموعه، پایگاه داده ای از پردازشهای تعمیر را مدیریت می کند. شامل: سطح کارکنان، واحدهای کار، هزینه ها، زمان تعمیر، مؤثر بودن و کار آمد بودن برنامه ریزی زمانی را مدیریت می کند. این مجموعه کارکرد با بلوک کارکرد زمان بندی و سرپرستی توزیع در لایه تجارتی پیوسته شده است که نقش مدیر را اجرا کند. کارکرد مدیریت پردازش تعمیر،تأثیر متقابل با بلوک کارکردی که پارامترهای این مجموعه را برای پردازشهای خود استفاده می کند، دارد و بر اساس درخواستهایی که به آن می رسد، اطلاعاتی را فراهم می کند و سپس آنچه که بدست آمده، فهرست می کند. این عملیات را سرپرستی پخش نیروهای کار در بلوک کارکردی دیگری به عهده دارد. بلوک کارکرد پیوسته شده (مدیریت پردازش تعمیر) نقش عامل را اجراء می کند.
5-1 - تعیین حوزه سرپرستی- مدیر، عامل را برای تأسیس کردن یا تغییر دادن حوزه سرپرستی نیروی کار یا سیستم هدایت می کند.
5-2 - درخواست حوزه سرپرستی- مدیر عامل را برای فرستادن یک حوزه سرپرستی هدایت می کند. عامل پاسخ به اطلاعات در خواست شده می دهد.
5-3 - تعیین قواعد آموزشی - مدیر از عامل برای تأسیس کردن یا تغییر دادن نیازمندیها برای کلاسهای فعالیتهای تغییر، هدایت می کند.
5-4 - درخواست قواعد آموزشی- مدیر، عامل را برای فرستادن نیازمندیها به کلاسهای فعال سازی تعمیر هدایت می‌کند. سپس عامل پاسخ می دهد یا اطلاعات در خواست می شود.
5-5 - درخواست گزارش نیروی کار – مدیر از عامل در خواست می کند برای فرستادن گزارش اطلاعات نیروی کار برای وضعیتهای فعلی یا پیشین. عامل با اطلاعات در خواست شده پاسخ می دهد.
5-6 - درخواست گزارش کار – مدیر از عامل برای فرستادن گزارش جریان کار برای مدت پیش یا وضعیت فعلی در خواست می کند. سپس عامل با اطلاعات در خواست شده پاسخ می دهد.
5-7 - درخواست گزارش زمان بندی- مدیر از عامل در خواست می کند که گزارش زمان بندی ایستای وضعیتهای فعلی و زمان پیشین خود را بفرستد. عامل با اطلاعات درخواست شده پاسخ می دهد.
5-8 - در خواست گزارش مواد- مدیر از عامل فرستادن گزارش مصرف منابع اصلی را درخواست می کند. برای مدت پیش، عامل با اطلاعات در خواست شده پاسخ می دهد.
فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد
تعداد صفحات این مقاله 41 صفحه
پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید
دانلود مقاله زبان مدلسازی یکنواخت (UML)