نمودار مورد استفاده بازی انسان در مقابل انسان. نمایش الگوریتمی قوانین بازی چه کسانی و در چه مواردی به فیلمنامه نیاز دارند؟

از نمودارهای موردی استفاده کنید - برای مدل‌سازی رفتار یک سیستم، زیرسیستم یا کلاس از نظر موارد استفاده (یا موارد استفاده) استفاده می‌شوند.

نمودارهای مورد استفاده شامل عناصر زیر است:

سوابق؛

شرکت کنندگان (بازیگران)؛

روابط وابستگی، تعمیم و تداعی.

سابقه، این توصیف مجموعه ای از توالی اقداماتی است که توسط سیستم انجام می شود تا یک بازیگر (شرکت کننده، اجرا کننده) بتواند نتیجه خاصی را به دست آورد. یک نمایش گرافیکی از نمونه ای از سوابق در شکل 1 نشان داده شده است. 3.5.6.1.

برنج. 3.5.6.1. نمایش گرافیکی موارد استفاده نمونه در UML.

شرکت کننده (سوژه، بازیگر)- نقش‌های مختلفی که کاربران مورد استفاده را هنگام تعامل با آنها انجام می‌دهند. شرکت کننده می تواند یک شخص، یک دستگاه یا یک سیستم نرم افزاری دیگر باشد. یک نمایش گرافیکی از نمونه ای از شرکت کنندگان در شکل 1 نشان داده شده است. 3.5.6.2.

برنج. 3.5.6.2. نمایش گرافیکی شرکت کنندگان نمونه در UML

نمودارهای مورد استفاده معمولاً برای حل مشکلات زیر استفاده می شوند:

مدل سازی زمینه سیستم، که شامل شناسایی مشارکت کنندگان در تعامل با سیستم و همچنین نقش آنها می شود.

مدل‌سازی نیازمندی‌ها - برای تعیین عملکرد سیستم از یک ناظر خارجی، بدون در نظر گرفتن مشکلات اجرای عملکرد، خدمت می‌کند.

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

مدلسازی سیستم باید در مراحل زیر انجام شود:

شرکت کنندگان اطراف سیستم را شناسایی کنید. در عین حال، شناسایی و تجزیه و تحلیل گروه های علاقه مند به سیستمی که وظایف آن را انجام می دهد ضروری است.

جریان رویدادها را برای سوابق منعکس شده در نمودار اصلی سوابق در نظر بگیرید و توصیف کنید، یعنی: پیش شرط ها، جریان اصلی، جریان های فرعی، جریان های جایگزین، شرایط پسا.

شرکت کنندگان مشابه را با استفاده از روابط تعمیم/تخصص سازماندهی کنید.

شرکت کنندگان را در نمودار مورد استفاده قرار دهید و ارتباط آنها را با موارد استفاده سیستم شناسایی کنید.

مدل سازی نیازمندی ها - این توصیفی است از ویژگی ها و رفتار سیستم لازم برای اجرای پروژه، بدون در نظر گرفتن مکانیسم های اجرایی. سیستم کار باید تمام الزامات ذکر شده در مدل را برآورده کند.

الزامات سیستم مدلسازی باید در مراحل زیر انجام شود:

ایجاد زمینه سیستم، شناسایی مشارکت کنندگان اطراف سیستم؛

برای هر شرکت کننده - در نظر گرفتن رفتاری که او از سیستم انتظار دارد و می خواهد.

نامگذاری گزینه های رفتاری انتخاب شده به عنوان پیشینه

برجسته کردن رفتار مشترک به سوابق جدیدی که توسط دیگران استفاده خواهد شد.

جداسازی تغییرات در رفتار به سوابق جدیدی که جریان اصلی رویدادها را گسترش می دهد.

مدل سازی سوابق انتخاب شده، شرکت کنندگان، روابط بین آنها در یک نمودار سابقه.

تکمیل موارد استفاده با یادداشت هایی که الزامات سیستم غیر کاربردی را توصیف می کند.

شبیه سازی نمودارهای مورد استفاده با استفاده از مثال های خاص در شکل 1 نشان داده شده است. 3.5.6.3. و برنج 3.5.6.4.

برنج. 3.5.6.3. نمایش گرافیکی سوابق با استفاده از یک مثال خدمات

مشترکین تلفن همراه

لازم به ذکر است که موارد استفاده با یادداشت هایی تکمیل می شود که الزامات خاص غیر کاربردی را توصیف می کند، یعنی نظراتی که ممکن است با برخی از روابط بین موارد استفاده همراه باشد. بنابراین، معنای رابطه " شامل"این است که در این مثال، "اتصال" شامل "انتخاب اپراتور مخابراتی" است. معنای اتصال <> این است که سابقه، به عنوان مثال، "در نظر گرفتن پرسشنامه"، "بسط یافته است " استفاده از مورد "انعقاد قرارداد". در این مورد، این را می توان با این واقعیت توضیح داد که "انعقاد توافقنامه" تنها پس از بررسی پرسشنامه توسط اپراتور انجام می شود. "در نظر گرفتن یک برنامه" "بسط" سابقه "مسدود کردن شماره"، "تعویض سیم کارت"، "جزئیات حساب"، "تعویض شماره مشترک". بنابراین اتصال <> از اجرای یک سابقه خاص بسته به شرایط خاص صحبت می کند.

برنج. 3.5.6.4. نمایش گرافیکی سوابق

با استفاده از مثال یک سایت تولید.

این نمودارهای مورد استفاده شرکت کنندگان را هنگام تعامل با سیستم در شرکت ها توصیف می کنند.

نمودار مورد استفاده در مرحله تجزیه و تحلیل فرآیندهای اصلی که توسط سیستم اطلاعات پشتیبانی می شود، توسعه می یابد.

طراحی کامل سیستم نرم افزاری مجموعه ای از مدل های سطح منطقی و فیزیکی است که باید با یکدیگر سازگار باشند.

زبان UML استفاده می کند نمودارهای پیاده سازی که شامل نمودار جزءو نمودار استقرار.

برای تجزیه و تحلیل دقیق تر، قوانین بازی تخته ای در قالب بلوک دیاگرام هایی ارائه شد که مراحل اصلی روند بازی را توصیف می کند. نمودار کلی در شکل 1.1 نشان داده شده است.

برنج. 1.1.

این طرح شامل فرآیندهای فرعی زیر است:

1. مقداردهی اولیه. شامل الگوریتم هایی برای تعیین حق اولین حرکت و صدور تعداد اولیه کارت برای همه بازیکنان است.

2. مرحله توسعه. حاوی الگوریتمی برای قرار دادن کارت ها روی میز، به شکل حیوانات و خواص آنها.

3. مرحله تعیین عرضه مواد غذایی. حاوی الگوریتمی برای تعیین تعداد چیپس های غذایی است که در طول "فاز غذا" در دسترس بازیکنان قرار می گیرد.

4. مرحله تغذیه. شامل الگوریتم هایی برای تغذیه و استفاده از خواص حیوانات است.

5. مرحله انقراض و دریافت کارت های جدید. حاوی الگوریتم هایی برای انتقال حیوانات تغذیه نشده به زباله دان، تعیین تعداد و صدور کارت های جدید.

6. پایان بازی. این طرح شامل یک الگوریتم برای شمارش امتیاز و تعیین برنده است.

نمودارهای تفصیلی فرآیندهای فرعی در پیوست B آمده است. شرح الگوریتمی قوانین بازی.

مشخصات مورد نیاز

بازی در حال توسعه یک آنالوگ کامل از بازی تخته Evolution است، بنابراین، اول از همه، کل گیم پلی باید مطابق با قوانین بازی اصلی (تخته) باشد.

الزامات تجاری:

بازی در برابر کامپیوتر؛

انتخاب تعداد بازیکنان

الزامات عملکردی:

الزامات سیستم از نظر قوانین بازی:

صدور کارت؛

اطلاعات به روز در مورد کارت های فعلی را در دست بازیکنان و حیوانات آنها با تمام ویژگی های موجود در زمین بازی نگه دارید.

محاسبه ترتیب حرکات؛

تعیین و انتقال حق به حرکت اول؛

محاسبه برهمکنش بین خواص مختلف؛

تعیین عرضه غذا بر اساس تعداد بازیکنان؛

کارت ها را در شمع دور ریختنی قرار دهید.

اطلاعات مربوط به کارت‌ها را در شمع دور انداختن بازیکن ذخیره کنید.

سیستم مورد نیاز از دیدگاه بازیکن:

شروع یک بازی جدید؛

یک کارت به شکل یک حیوان قرار دهید.

کارت را به عنوان یک ملک قرار دهید.

رد شدن از نوبت؛

یک تراشه غذا از منبع غذا بردارید.

یک نشانه غذایی روی حیوان خود قرار دهید.

فعال کردن ویژگی اعمال؛

بازی را تمام کن

از مدل موردی استفاده کنید

ساختن یک نمودار مورد استفاده

تجسم نیازمندی ها با استفاده از آن اجرا می شودنمودارهای مورد استفاده (شکل 1.2 را ببینید).

برنج. 1.2.

مستندسازی موارد استفاده

مستندات سوابق در جداول زیر ارائه شده است (نگاه کنید به. جدول 1.1. - 1.15).

جدول 1.1. از حالت "ایجاد یک بازی جدید" استفاده کنید.

جدول 1.2. از حالت "تنظیم پارامترها" استفاده کنید.

جدول 1.4. "ادامه بازی".

جدول 1.5. سابقه "پایان دادن به بازی".

جدول 1.6. "بازی".

جدول 1.7. از مورد "دریافت کارت" استفاده کنید.

جدول 1.8 سابقه "برد".

جدول 1.9. Precedent "بازنده".

جدول 1.10. سابقه "پرش از حرکت".

جدول 1.11. Precedent "یک حرکت".

جدول 1.12 سابقه "قرار دادن یک کارت به شکل یک حیوان."

جدول 1.13 استفاده از مورد "قرار دادن یک کارت به عنوان یک توانایی."

جدول 1.14.

جدول 1.15. مورد استفاده "اعمال ویژگی".

و رفتار دیکتاتوری (از اعتیاد انگلیسی - تمایل، اعتیاد؛ lat. addictus - به صورت برده ای اختصاص داده شده) نوع خاصی از اشکال رفتار مخرب است که در تمایل به فرار از واقعیت از طریق تغییر خاصی در وضعیت روانی فرد بیان می شود. مترادف: اعتیاد.

انواع اصلی اعتیاد وجود دارد:

• سوء استفاده از یک یا چند ماده که حالت روانی را تغییر می دهد، به عنوان مثال، الکل، مواد مخدر، داروها، سموم مختلف.
• مشارکت در قمار، از جمله بازی های رایانه ای؛
• رفتار اعتیاد آور جنسی؛
• پرخوری؛
• اعتیاد به کار (کارگرایی);
• گوش دادن طولانی مدت به موسیقی، عمدتا بر اساس ریتم.

وقتی اعتیاد شکل می گیرد، کاهش رخ می دهد، یعنی. ساده سازی، هموارسازی روابط عاطفی بین فردی.

مجموعه علائم اختلالات روانی ناشی از استفاده بیش از حد از رایانه یا اینترنت توسط روانپزشکان تحت عنوان اعتیاد به رایانه و اینترنت یا سندرم رایانه توصیف می شود.

کشش آسیب‌شناختی به بازی‌های رایانه‌ای و اینترنت به اعتیادهای غیرشیمیایی یا رفتاری اشاره دارد، یعنی اعتیادهایی که مبتنی بر بسترهای بیوشیمیایی خاصی نیستند (برخلاف اعتیاد به الکل، اعتیاد به مواد مخدر، اعتیاد به نیکوتین).

1. اثرات بازی های رایانه ای بر روی بدن

دانشمندان تلاش هایی برای بررسی پیامدهای اعتیاد به رایانه در سطح روانی انجام داده اند و به موارد زیر دست یافته اند.

تغییرات فیزیکی در بدن تحت تأثیر چندین عامل ایجاد می شود:

• نشستن طولانی مدت در یک وضعیت یکنواخت، اغلب وضعیت بدن و اندام های داخلی فرد را مخدوش می کند.
• سوسو زدن مانیتور؛
• تابش الکترونیکی

پزشکان پیامدهای قرار گرفتن در معرض عوامل فوق را شامل می شوند:

1. کاهش ایمنی (خواص محافظتی بدن) - مستعد ابتلا به عفونت و سرطان.
2. اختلالات عصبی - تعدادی از مشاهدات توسط متخصصان مغز و اعصاب اطفال در مورد ایجاد حملات تشنجی وجود دارد که ناشی از اثر سوسو زدن مانیتور و تغییرات مکرر تصویر در طول بازی است (تحریک عکس فعالیت تشنجی مغز رخ می دهد).
3. تغییرات عصبی رویشی - این تغییرات شامل نوسانات فشار خون، ضربان قلب، تعداد تنفس، افزایش دمای بدن و سردرد است.
4. اختلالات عروقی. به دلیل وضعیت یکنواخت، احتقان در رگ های اندام ها، تورم و واریس ایجاد می شود.
5. تغییر در وضعیت بدن.
6. اختلال در عملکرد تولید مثل.
7. بدتر شدن بینایی.
8. اختلالات غدد درون ریز.

بنابراین، در ژاپن، مطالعات نشان داده‌اند که برای مثال، بازی‌های رایانه‌ای تنها بخش محدودی از مغز را در کودکان تحریک می‌کنند، بنابراین آنها باید بیشتر بخوانند، بنویسند و بشمارند. علاوه بر این، برای تحریک عملکرد مغز و رشد طبیعی، مهم است که کودکان بیرون از خانه با همسالان خود بازی کنند و با دیگران تعامل بیشتری داشته باشند.

به گفته دانشمندان آمریکایی، مشارکت بیش از حد در بازی‌های رایانه‌ای خشن منجر به اختلال در انتقال تکانه‌ها بین سلول‌های عصبی و کند کردن عملکرد مغز می‌شود (که با نتایج مطالعات تصویربرداری تشدید مغناطیسی عملکردی انجام شده بر روی نوجوانان شرکت‌کننده در مطالعه تأیید شد). این مهار به ویژه در نوجوانان مبتلا به اختلالات رفتاری، که در آنها فعالیت در قشر لوب فرونتال (مسئول احساسات و تکانشگری است) در حال حاضر به میزان قابل توجهی کاهش یافته است.

طبق آمار به دست آمده در ایالات متحده آمریکا، یک دانش آموز کلاس ششم به طور متوسط ​​4 ساعت در روز تلویزیون تماشا می کند - و این شامل زمانی نیست که او برای انجام بازی های مختلف در مقابل یک کامپیوتر یا صفحه تلویزیون صرف می کند. کودکان اعتراف می کنند که اغلب بیشتر از آنچه در نظر داشتند بازی می کنند. غیر معمول نیست که آنها به این دلیل از تحصیل خود غافل شوند.

بر اساس برخی برآوردها، حدود 40 درصد از کودکان آمریکایی 5 تا 8 ساله چاق هستند. بدیهی است که این امر ناشی از فعالیت بدنی ناکافی است - نتیجه ساعت های طولانی تماشای تلویزیون یا رایانه است. یک شرکت حتی شبیه سازهای ویژه ای را توسعه داده است که می توانید در حین انجام بازی های رایانه ای از آنها استفاده کنید. اما آیا بهتر نیست زمان زیادی را به این بازی ها اختصاص دهیم تا زمان کافی برای سایر فعالیت های لازم برای رشد همه جانبه شخصیت کودک وجود داشته باشد؟

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

2. تأثیر بر روان. ظهور اعتیاد به بازی

سرعت کامپیوتری شدن امروز از سرعت توسعه همه صنایع دیگر بیشتر است. یک فرد مدرن شروع به تعامل دائم با رایانه می کند - در محل کار، در خانه، در ماشین و حتی در هواپیما. رایانه ها به سرعت در حال معرفی خود به زندگی انسان هستند و جای خود را در آگاهی ما می گیرند و ما اغلب متوجه نمی شویم که تا حد زیادی به عملکرد آنها وابسته هستیم.

همزمان با ظهور رایانه ها، بازی های رایانه ای نیز ظاهر شدند که بلافاصله طرفداران زیادی پیدا کردند. با پیشرفت رایانه ها، بازی ها نیز پیشرفت کردند و افراد بیشتری را به خود جذب کردند. انتظار می رود بازار بازی های الکترونیکی در سال های آینده به طور پیوسته گسترش یابد. یک طبقه کامل از افراد طرفدار بازی های رایانه ای در جامعه شکل می گیرد. بازی به فعالیت اصلی آنها تبدیل می شود. دایره تماس های اجتماعی آنها بسیار باریک است، تمام فعالیت های دیگر فقط با هدف بقا و ارضای نیازهای فیزیولوژیکی انجام می شود. نکته اصلی این است که نیاز به بازی در رایانه را برآورده کنید. تجربه نشان می دهد که برای بسیاری از آنها این سرگرمی اصلاً مفید نیست و برخی به طور جدی به کمک نیاز دارند. اکثر آنها افرادی با مشکلات روانی شناخته شده هستند: زندگی شخصی نابسامان، نارضایتی از خود و در نتیجه از دست دادن معنای زندگی و ارزش های عادی انسانی. تنها ارزش برای آنها کامپیوتر و هر چیزی که به آن متصل است است.

برای سلامت روان، بزرگترین خطر بازی های رایانه ای اعتیاد است. یک فرد بیشتر مستعد اعتیاد به بازی های رایانه ای است، زیرا رویدادهای بازی های رایانه ای تکرار نمی شوند و کاملاً پویا رخ می دهند و خود روند بازی مستمر است. قبل از پایان هر بازی، مراحل منطقی خاصی وجود دارد که در بیشتر موارد کاملاً به یکدیگر گره خورده اند که سوژه را مجبور می کند حواس او پرت نشود، بلکه گذر کل بازی را از ابتدا تا انتها درک کند. به عنوان یک فرآیند واحد

بازی‌های رایانه‌ای، به‌ویژه بازی‌های نقش‌آفرینی، یکی از روش‌های اجرای به اصطلاح اعتیادآور هستند. فرار از واقعیت

با غوطه ور شدن کامل در بازی و دستیابی به موفقیت های معین در آن، شخص به این ترتیب (عملا) بیشتر نیازهای موجود خود را درک می کند و بقیه را نادیده می گیرد. در هر جامعه ای افرادی هستند که ترجیح می دهند از مشکلات فرار کنند. کسانی که الکل را به عنوان این روش انتخاب می کنند، الکلی ها، مواد مخدر - معتاد به مواد مخدر، کار - معتاد به کار، قمار - قماربازان آسیب شناسی نامیده می شوند. معتادان به اینترنت، بازی های رایانه ای – معتادان اینترنتی و غیره. در مورد دوم، شخص به جای حل مشکلات اینجا و اکنون، خود را در یک بازی رایانه ای غرق می کند. در آنجا، در بازی، او احساس خوبی دارد: او قوی، شجاع، مسلح، موفق است... زمان صرف شده برای بازی او را قوی تر و موفق تر در زندگی واقعی نمی کند. بنابراین، هنگام خروج از دنیای مجازی به دنیای واقعی، فرد احساس ناراحتی می کند، در یک محیط تهاجمی احساس کوچکی، ضعف و بی دفاعی می کند. و او می خواهد هر چه زودتر به جایی که برنده است بازگردد.

غوطه ور شدن کامل در بازی باعث می شود بازیکن در نوعی واقعیت مجازی شرکت کند، در فرآیندی پیچیده و متحرک که فقط برای او وجود دارد. این ویژگی بازی‌های رایانه‌ای است که به یک معتاد به بازی اجازه نمی‌دهد فرآیند را برای انجام هر گونه تعهد اجتماعی در زندگی واقعی قطع کند. برخی از آنها تمام شب را پشت کامپیوتر می نشینند و از زندگی واقعی خارج می شوند. اطرافیان شما نگران هستند، اما اغلب نمی دانند چه کنند. یکی از گیمرهای رایانه ای جوان گفت: وقتی با مردم آنلاین صحبت می کنم، برای آنها باهوش و ظریف به نظر می رسم. و با دیدن من در زندگی به من توصیه می کنند که وزن کم کنم.

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

البته، توسعه دهندگان چنین محصولات نرم افزاری علاقه مند هستند تا بازی را تا حد امکان جذاب کنند. وظیفه سازندگان نرم افزارهای بازی ایجاد حداکثر اثر غوطه وری است، به طوری که در زمان عرضه سری بعدی، فردی که معتاد به بازی های رایانه ای است، بدون تردید محصول خود را خریداری کند.

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

اعتیاد به بازی های رایانه ای اعتیاد به هیچ بازی رایانه ای نیست، زیرا بیشتر یک واکنش زنجیره ای روانی است. گیماهولیک پس از تکمیل یک بازی در هر سبکی که بیشتر از همه دوست داشت، به دنبال بازی‌های دیگر هم ژانر می‌گردد که به سبکی مشابه ساخته شده‌اند و از نظر تنش روانی پایین‌تر نیستند، و سپس میل به تکمیل همه بازی‌های (حداقل شناخته‌شده) این نوع که در حال حاضر تعداد زیادی از آنها در بازار وجود دارد.

بسیاری از بازی‌ها ژانرهای بازی را با هم ترکیب کرده‌اند که معتاد را مجبور می‌کند به سمت انواع دیگر بازی‌ها برود. لازم به ذکر است که تکمیل یک بازی کامپیوتری جدید از 5-6 ساعت تا چند روز و گاهی حتی هفته ها طول می کشد. برای اینکه یک gameaholic تا زمانی که ممکن است این یا آن بازی را انجام دهد، توسعه دهندگان سطوح فرعی کوچک اضافی را به آنها معرفی می کنند، به اصطلاح رازها، که جستجوی آنها زمان زیادی می برد. فردی که عاشق یک بازی کامپیوتری است، تا زمانی که تمام سطوح مخفی، اتاق ها را پیدا نکند و تمام پاداش ها را جمع آوری کند، در نهایت با آن خداحافظی نمی کند. با ایجاد سطوح فرعی مخفی، به نظر می رسد تولیدکنندگان بازیکن را به سمت یک احساس رقابتی خاص سوق می دهند که چه کسی برنده خواهد شد؟ که یکی از دلایل متعدد اعتیاد به بازی های رایانه ای است.

بازی هایی که در آن رویدادها مستقیماً به بازیکن بستگی دارد، یعنی. توسعه مستقل همراه با بازیکن، تمرکز بر نقاط ضعف و قوت او، یا داشتن پارامترهای تصادفی زیادی که بازیکن تعیین می کند، معتاد را مجبور می کند بارها و بارها از آنها عبور کند. هر بار، در هر موقعیت جدید، بازیکن بررسی می‌کند که اگر رویدادها به گونه‌ای متفاوت رخ دهند، چه اتفاقی خواهد افتاد. چنین بازی هایی حتی جذاب تر از بازی هایی هستند که بر اساس سناریو ساخته شده اند، زیرا آزادی عمل بیشتری را برای بازیکن فراهم می کنند و به او این فرصت را می دهند که مانند توسعه دهندگان یک سطح یا سناریوی خاص یک بازی رایانه ای احساس کند.

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

بنابراین، پیامدهای منفی اعتیاد به رایانه عبارتند از اعتیاد، که در علائم آسیب‌شناختی روانی (مانند ناتوانی در تغییر به سرگرمی‌های دیگر، احساس برتری نسبت به سایر افراد، فقیر شدن حوزه عاطفی) و محدود شدن دامنه علایق، بیان می‌شود. و مشکلات در برقراری ارتباط با همسالان و اختلالات جسمی (کاهش بینایی، خستگی).

عوامل خطر ابتلا به اعتیاد به رایانه را می توان به سه گروه تقسیم کرد:

1) اجتماعی

کار پیشگیرانه و توضیحی ناکافی در خانواده، تضعیف کنترل بهداشت شغلی در رایانه.

اشتیاق گسترده در میان همسالان و بزرگسالان (والدین) اطراف کودک برای بازی های رایانه ای و اینترنت.

انگیزه مالی - فرصتی برای کسب پول با بازی شرط بندی، کازینو آنلاین.

فقدان اوقات فراغت جایگزین – بی میلی یا نداشتن فرصت برای انجام کاری غیر از رایانه.

2) ارثی-بیولوژیکی

استعداد ارثی برای ایجاد نوع خاصی از فعالیت عصبی بالاتر. در ژنوم انسان، 31 ژن رمزگشایی شده است که مسئول تولید هورمون های خلق و خو - انتقال دهنده های عصبی (دوپامین، سروتونین، نوراپی نفرین، GABA) هستند. ویژگی های ذهنی فردی تا حد زیادی به میزان تولید و انتقال این مواد در سیستم عصبی مرکزی انسان بستگی دارد.

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

3) روانی-شخصیت شناختی

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

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

معتاد آینده توسط:

• حضور دنیای (صمیمی) خودش که هیچکس جز خودش به آن دسترسی ندارد.
• عدم مسئولیت؛
• فرآیندهای واقع گرایانه و انتزاع کامل از دنیای اطراف؛
• توانایی تصحیح هر گونه خطا از طریق تلاش های مکرر؛
• توانایی تصمیم گیری مستقل (در داخل بازی) بدون توجه به آنچه ممکن است منجر شود.

لازم به ذکر است که از آنجایی که در دوران کودکی توانایی های ذهنی فرد در فرآیند تعامل و سازگاری با محیط رشد می کند و برخلاف بزرگسالان - شخصیتی بالغ با مکانیسم های دفاعی روانی شکل گرفته، کودک آنچه را که به او پیشنهاد می شود بدون انتقاد می پذیرد. سپس سریعتر از بزرگسالان وابسته می شود. بنابراین، مسائل مربوط به پیشگیری زودهنگام از اعتیاد به رایانه در صلاحیت اول از همه والدین قرار دارد.

به طور کلی، مکانیسم اعتیاد یک فرد و شکل گیری اعتیاد به قمار مبتنی بر آرزوها و نیازهای ناخودآگاه است: فرار از واقعیت و پذیرش نقش. این مکانیسم‌ها بلافاصله پس از آشنایی فرد با بازی‌های رایانه‌ای نقش‌آفرینی فعال می‌شوند و کم و بیش به طور منظم آن‌ها را بازی می‌کنند و بدون توجه به هوشیاری فرد و ماهیت انگیزه فعالیت در بازی کار می‌کنند.

3. طبقه بندی روانشناختی بازی های رایانه ای

تمامی بازی های رایانه ای را می توان به دو دسته نقش آفرینی و غیر نقش آفرینی تقسیم کرد.

بازی های رایانه ای نقش آفرینی بازی هایی هستند که در آنها بازیکن نقش یک شخصیت رایانه ای را بر عهده می گیرد، یعنی. بازی خود بازیکن را ملزم می کند که به عنوان یک قهرمان رایانه ای خاص یا خیالی عمل کند. بازی‌های رایانه‌ای نقش‌آفرینی سطح کیفی جدیدی از وابستگی روان‌شناختی به رایانه را نسبت به بازی‌های غیر نقش‌آفرینی یا هر نوع فعالیت رایانه‌ای غیر بازی ایجاد می‌کنند. بدیهی است که وابستگی روانی به بازی های رایانه ای نقش آفرینی از نظر میزان تأثیرگذاری بر شخصیت بازیکن، قوی ترین است.

اجازه دهید معیارهای تعلق یک بازی رایانه ای به کلاس بازی های نقش آفرینی را برجسته کنیم:

یک بازی نقش آفرینی باید از طریق ویژگی های داستانی و چند رسانه ای (طراحی گرافیک و صدا) بازیکن را تشویق کند تا وارد نقش یک شخصیت رایانه ای و فضای بازی شود.

یک بازی نقش آفرینی باید به گونه ای ساخته شود که بر اساس هیجان انگیزه ای در بازیکن ایجاد نکند - برای جمع آوری امتیازات بیشتر، در نتیجه شکستن رکورد شخص دیگری، حرکت به سطح بعدی و غیره.

اگرچه در هر بازی رایانه ای عنصری از هیجان وجود دارد، اما در یک بازی نقش آفرینی این عامل نباید از اهمیت بالایی برخوردار باشد.

طبقه بندی ارائه شده در زیر فراگیر، کامل یا کامل نیست. به نظر می رسد این است:

I. بازی های رایانه ای نقش آفرینی.

• بازی هایی با نمایی از چشمان قهرمان رایانه شما.
• بازی هایی با نمای بیرونی قهرمان رایانه شما.
• بازی های رهبری

II. بازی های رایانه ای غیر نقش آفرین.

• بازی آنلاین.
• پازل.
• بازی برای سرعت واکنش
• قمار سنتی

ویژگی های بازی های رایانه ای

I. بازی های رایانه ای نقش آفرینی

ویژگی اصلی بیشترین تأثیر بر روان بازیکن، بیشترین عمق ورود به بازی و همچنین انگیزه فعالیت بازی بر اساس نیازهای پذیرش نقش و فرار از واقعیت است. در اینجا، سه نوع فرعی عمدتاً به دلیل ماهیت تأثیر آنها بر بازیکن، قدرت درگیری آنها در بازی و درجه عمق وابستگی روانی مشخص می شود.

1) بازی هایی با نمایی از چشم قهرمان رایانه شما. این نوع بازی با بیشترین نیروی سفت شدن یا ورود به بازی مشخص می شود. ويژگي در اينجا اين است كه ديد از چشم، بازيكن را برمي‌انگيزاند تا كاملاً با شخصيت كامپيوتر همذات پنداري كند تا كاملاً وارد نقش شود. پس از چند دقیقه بازی (زمان بسته به ویژگی های روانی فردی و تجربه بازی بازیکن متفاوت است)، فرد شروع به از دست دادن ارتباط با زندگی واقعی می کند، کاملاً روی بازی متمرکز می شود و خود را به دنیای مجازی منتقل می کند.

بازیکن می تواند دنیای مجازی را کاملا جدی بگیرد و اعمال قهرمان خود را متعلق به خود می داند. یک فرد انگیزه می گیرد تا در طرح بازی شرکت کند.

2) بازی هایی با دید بیرونی از قهرمان رایانه شما. مشخصه این نوع بازی ها قدرت کمتری در ورود به نقش نسبت به بازی قبلی است. بازیکن خود را از بیرون می بیند و اعمال این قهرمان را کنترل می کند.

شناسایی خود با یک شخصیت رایانه ای کمتر به چشم می خورد، در نتیجه درگیری انگیزشی و تظاهرات عاطفی نیز در مقایسه با بازی های با دید از چشم کمتر مشخص می شود. اگر در مورد دومی، در ثانیه های حساس زندگی قهرمان خود، شخصی ممکن است رنگ پریده شود و روی صندلی خود بی قرار شود و سعی کند از ضربات یا شلیک دشمنان رایانه ای طفره رود، در صورت مشاهده بیرونی، ظاهر خارجی. تظاهرات معتدل تر هستند، با این حال، شکست ها یا مرگ خود در پوشش یک قهرمان رایانه ای توسط بازیکن کمتر تجربه نمی شود.

3) بازی های رهبری این نوع به این دلیل نامگذاری شده است که در این بازی ها به بازیکن این حق داده می شود که فعالیت های شخصیت های رایانه ای تابع خود را هدایت کند. در این مورد، بازیکن می تواند به عنوان یک رهبر با مشخصات مختلف عمل کند: فرمانده یک گروه نیروهای ویژه، فرمانده کل ارتش، رئیس دولت، حتی خدایی که روند تاریخی را رهبری می کند. در این حالت فرد قهرمان کامپیوتر خود را روی صفحه نمی بیند بلکه نقشی را برای خود اختراع می کند. این تنها کلاس بازی های نقش آفرینی است که نقش به طور خاص داده نمی شود، بلکه توسط بازیکن تصور می شود. در نتیجه عمق غوطه ور شدن در بازی و نقش شما فقط برای افراد با تخیل خوب قابل توجه خواهد بود. با این حال، مشارکت انگیزشی در روند بازی و مکانیسم شکل گیری وابستگی روانی به بازی کمتر از سایر بازی های نقش آفرینی نیست.

II. بازی های رایانه ای غیر نقش آفرین

اساس تشخیص این نوع این است که بازیکن نقش یک شخصیت رایانه ای را بر عهده نمی گیرد، در نتیجه مکانیسم های روانی شکل گیری اعتیاد و تأثیر بازی ها بر شخصیت فرد کمتر قوی است. انگیزه فعالیت بازی بر اساس هیجان پاس دادن و (یا) امتیاز گرفتن است. چندین زیرگروه وجود دارد:

1) بازی های آرکید به این گونه بازی ها، بازی های کنسولی نیز گفته می شود، زیرا به دلیل تقاضای کم آنها در منابع رایانه ای، در کنسول های بازی گسترده شده اند. طرح معمولاً ضعیف و خطی است. تنها کاری که بازیکن باید انجام دهد این است که به سرعت حرکت کند، تیراندازی کند و جوایز مختلفی را در حین رانندگی با یک شخصیت کامپیوتری یا وسیله نقلیه جمع آوری کند. در بیشتر موارد این بازی ها از نظر تأثیرگذاری بر شخصیت بازیکن بسیار بی ضرر هستند، زیرا وابستگی روانی به آنها اغلب کوتاه مدت است.

2) پازل. این نوع بازی ها شامل نسخه های کامپیوتری بازی های مختلف رومیزی (شطرنج، چکرز، تخته نرد و ...) و همچنین انواع پازل هایی است که در قالب برنامه های کامپیوتری اجرا می شوند.

انگیزه مبتنی بر اشتیاق در اینجا با میل به شکست دادن رایانه، برای اثبات برتری خود بر دستگاه مرتبط است.

3) بازی برای سرعت واکنش. این شامل تمام بازی‌هایی می‌شود که بازیکن باید در آن مهارت و واکنش سریع نشان دهد. تفاوت بازی های آرکید در این است که اصلاً طرحی ندارند و قاعدتاً کاملاً انتزاعی هستند و هیچ ارتباطی با زندگی واقعی ندارند. انگیزه مبتنی بر اشتیاق، نیاز به تکمیل بازی، کسب امتیاز بیشتر، می تواند وابستگی روانی کاملاً پایداری را در فرد به این نوع بازی شکل دهد.

4) قمار سنتی. این شامل نسخه های رایانه ای بازی های ورق، رولت ها، شبیه سازهای دستگاه های اسلات، در یک کلام - نسخه های رایانه ای مجموعه بازی های کازینو است. جنبه‌های روان‌شناختی شکل‌گیری اعتیاد به این بازی‌های رایانه‌ای و مشابه‌های واقعی آن‌ها بسیار شبیه است و بنابراین، ما روی این موضوع تمرکز نمی‌کنیم.

بنابراین، بازی های رایانه ای نقش آفرینی تا حد زیادی به فرد امکان می دهد وارد فضای مجازی شده، (حداقل در طول بازی) از واقعیت جدا شده و وارد دنیای مجازی شود. در نتیجه بازی های رایانه ای نقش آفرینی تأثیر بسزایی بر شخصیت افراد دارد.

4. علائم اعتیاد به بازی

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

علائم اصلی این بیماری به شرح زیر است:

1. جذب، مشغولیت به بازی (خاطرات بازی های گذشته، برنامه ریزی برای آینده، افکار در مورد چگونگی پیدا کردن پول برای بازی)؛
2. احساس برانگیختگی عاطفی هنگام کار با کامپیوتر، عصبی بودن و هیجان در هنگام بازی.
3. بی میلی به حواس پرتی از بازی با کامپیوتر؛
4. احساسات، اضطراب یا تحریک زمانی که لازم است بازی را متوقف کنید.
5. استفاده از بازی ها به عنوان وسیله ای برای خلاص شدن از شر تجربیات ناخوشایند؛
6. تلاش برای برنده شدن پس از باخت، برای اصلاح وضعیت؛
7. دروغ گفتن و تلاش برای توجیه منطقی رفتار خود به منظور پنهان کردن میزان واقعی درگیری خود در بازی؛
8. فراموش کردن کارهای خانه، مسئولیت ها، مطالعه، جلسات در حین بازی با رایانه، بدتر شدن روابط در مدرسه، با والدین، با دوستان.
9. قرض گرفتن از دیگران برای خرید یک بازی جدید.
10. نادیده گرفتن سلامت، بهداشت و خواب خود به نفع گذراندن زمان بیشتر در رایانه؛

اگر فردی چهار علامت یا بیشتر داشته باشد، این یک بیماری است...

5. چه باید کرد؟

در حال حاضر، دانشمندان نمی توانند بدون ابهام بگویند که آیا نیاز به حل دقیق مشکلات اعتیاد به رایانه در بین جوانان وجود دارد یا خیر. از یک سو، چنین اعتیادی فرد را می بلعد، زمان زیادی را برای رشد و تعلیم می گیرد، موضوع را از فرآیند فعال اجتماعی خارج می کند، از سوی دیگر، اعتیاد به بازی های رایانه ای یک پدیده گذرا و موقت است.

اعتیاد به رایانه با سیگار، الکل، مواد مخدر و قمار تفاوت دارد زیرا در یک نقطه از زمان اشباع از رایانه رخ می دهد. سپس آزمودنی یا به طور حرفه ای درگیر آن می شود، یا کامپیوتر دیگر جایگاه مهمی در زندگی او ندارد. این سؤال اساساً به این دلیل باز می ماند که هرگز مشخص نیست یک معتاد رایانه، به ویژه یک معتاد به بازی، در چه مرحله ای به مرز سیری می رسد. آیا برای مطالعه و رسیدن به نتیجه خیلی دیر می شود؟ آیا او موقعیت اجتماعی خود را در دوران سرخوشی بازی های رایانه ای از دست خواهد داد در این صورت، این به معنای اخراج از مدرسه یا دانشگاه، اخراج از کار، از دست دادن عنوان یا موقعیت است؟

ممکن است اشباع بیش از حد بازی های رایانه ای در اوایل کودکی به زمان بسیار کمتری نسبت به یک دانشجوی دانشگاه نیاز داشته باشد. ممکن است کودک در مقایسه با بی نهایت امکانات و لحظات کشف نشده دنیای واقعی، به سرعت از یکنواختی صفحه خسته شود. اما، متأسفانه، هیچ تضمینی وجود ندارد که روان کودک توسط چنین آزمایش غیرموجهی آسیب نبیند.

یک راه اثبات شده برای جلوگیری از وابستگی شخص به بازی های رایانه ای این است که او را به زندگی واقعی جذب کنید تا خودش را در آن بشناسد. بسیاری از فعالیت های جالب (ارتباط با طبیعت، تمرینات یوگا، خواندن ادبیات آموزشی و غیره) وجود دارد که نه تنها به شما امکان می دهد دنیای خود را کشف کنید، هوشیاری و آگاهی را توسعه دهید، بلکه بدن را آموزش داده و وضعیت روانی را عادی می کند. واقعیت مجازی ناملموس بودن تأثیر، قراردادی بودن پارامترها و زودگذر بودن است - این زندگی نیست، فقط بخش ثانویه آن است، روندی موازی، اما نه اصلی. نادیده گرفتن قابلیت های کامپیوتری فایده ای ندارد.

سخنرانی 6:

استفاده از نمودارهای موردی: نمای نزدیک

چند کلمه در مورد الزامات

پس بیایید در مورد الزامات صحبت کنیم. ما به طور کلی درک می کنیم که این چیست - وقتی مشتری برای ما توصیف می کند که دقیقاً چه می خواهد، همیشه عباراتی مانند "من می خواهم که بررسی به روز رسانی به طور خودکار انجام شود، مانند آنتی ویروس ها"، "من یک دکمه سبز بزرگ در مرکز پنجره، که فرآیند را شروع می کند، " برنامهباید به شما امکان مشاهده و چاپ گزارش ها را بدهد، "و همه چیز باید زیبا و شفاف باشد، مانند ویستا"، "هنگام خروج باید یک تایید نمایش داده شود" و غیره، و غیره. البته، به عنوان توسعه دهندگان واقعی، ما درک می کنیم که که مشتری هرگز نمی داند دقیقا به چه چیزی نیاز دارد و اگر بفهمد نمی تواند آن را توضیح دهد. توسطدر اصل یکسان است! آنها توصیف می‌کنند که مشتری چگونه سیستم را تصور می‌کند، مشتری از سیستم چه می‌خواهد، عملکردی که از آن انتظار دارد، الزاماتی که بر روی آن قرار می‌دهد.

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

برنج. 6.1.

راستی، این تصویر شبیه چه نموداری است؟ درسته، نمودار فعالیت. و انتخاب این نمودار خاص در اینجا کاملاً توجیه شده است - به یاد داشته باشید، ما این را گفتیم نمودارهای فعالیتاغلب برای توصیف فرآیندهای تجاری استفاده می شود؟ تنها هشدار: معمولاً روند توسعه با انتشار یک محصول نرم افزاری پایان نمی یابد - یک محصول جدید در راه است تکرار، نیازمندی های جدید، به روز شده، نسخه جدید و غیره

به هر حال، اجازه دهید به الزامات برگردیم. بله، ما گفتیم که ورودی "جعبه سیاه" ما مجموعه ای از الزامات است. اما در چه شکلی؟ آنها چگونه مستند شده اند، این الزامات؟ فکر می کنم بیشتر خوانندگان به یاد دارند که چیست شرایط مرجع- سند اصلی که بدون آن هیچ پروژه ای در زمان شوروی آغاز نشد. این سند بزرگ، چند صفحه ای، با ساختار واضحی بود که توسط GOST ها (استانداردهای صنعت دولتی) تعیین شده بود. و توصیف کرد توسطدر اصل، چیزی بیش از الزامات سیستم در حال ایجاد!

مشخصات فنی - چیز توسط- در نوع خود خوب است. اما زمان گذشت، استانداردها، نمادها و روش‌های توصیف نیازمندی‌ها تغییر کردند. و به تدریج شرایط مرجعقبول کرد محلمجموعه ای از مصنوعات متشکل از دو نوع سند:

· از نمودارهای موردی استفاده کنید ;

· الزامات غیر کاربردی

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

الزامات غیر کاربردی - این توصیفی از ویژگی های سیستم به عنوان ویژگی های محیط و پیاده سازی است، عملکرد,توسعه پذیری, قابلیت اطمینانغیره فهرستسیستم مورد نیاز اضافی (برنج 6.2).

برنج. 6.2.

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

· به وضوح بین سیستم و محیط آن تمایز قائل شوید.

· تعیین کنید که کدام بازیگران با سیستم تعامل دارند و دقیقاً چگونه، چه عملکردی (مورد استفاده) از سیستم انتظار می رود.

· تعریف و توصیف در فرهنگ لغت دامنه (واژه نامه) مفاهیم کلی که برای توصیف دقیق عملکرد سیستم (سابقه) ضروری است.

این نوع فعالیت معمولاً به ترتیب زیر انجام می شود:

1. شناسایی بازیگران

2. تعریف سوابق.

3. ترسیم شرح هر سابقه.

4. توصیف مدل مورد استفاده به عنوان یک کل (این مرحله شامل ایجاد فرهنگ لغت دامنه است).

در ابتدا، الزامات در قالب یک سند متنی معمولی رسمی می شود که یا توسط خود کاربر یا توسط کاربر و توسعه دهنده با هم ایجاد می شود. در ادامه، الزامات به شکل جدول ارائه شده است. سوابق در ستون سمت چپ و بازیگران شرکت کننده در پیشینه در ستون سمت راست قرار می گیرند.

بیایید به یک مثال نگاه کنیم. منشی آن را روی سرور قرار می دهد منوغذاهای ناهار برای هفته. کارمندان باید بتوانند خود را با آن آشنا کنند منوو با انتخاب ظروف برای هر روز هفته بعد سفارش دهید. دفتر-مدیر باید بتواند فاکتور تولید کند و آن را پرداخت کند. سیستم باید در آن نوشته شود A.S.P..NET. این یک اینترنت ساده است کاربردبرای خودکار کردن سفارشات ناهار در دفتر.

ما فکر می کنیم اینجا همه چیز روشن است. جدولبا شرح الزامات می تواند، برای مثال، این باشد:

هیچ جا نمی گوید که سیستم باید در آن نوشته شود A.S.P..NET. واضح است که چرا: این یک نیاز غیر کاربردی است! و همچنین بدیهی است که منشی و دفتر-مدیران نیز کارکنان هستند. خواننده‌ای که سخنرانی‌های قبلی را به دقت خوانده است، مشکوک می‌شود که در این مورد، هنگام ایجاد مدلی از سوابق، صحبت در مورد بازیگران، می‌توان از تعمیم استفاده کرد. واقعا، نمودار مورد استفاده، که بر اساس این جدول ساخته شده است، می تواند به عنوان مثال، مانند این (برنج 6.3):

برنج. 6.3.

از نمودارهای موردی و نشانه گذاری آنها استفاده کنید

خوب، ما یک نمودار نمونه داریم. بنابراین، چه عناصری را روی آن می بینیم؟ اولین چیزی که توجه شما را جلب می کند بزرگ بودن آن است مستطیل، که در داخل آن بیضی ها قرار می گیرند، همانطور که قبلاً فهمیدیم، موارد قبلی را نشان می دهد. نام سیستم مدل شده در قسمت بالای مستطیل مشخص شده و نامیده می شود در داخل سیستم (سیستم مرز, موضوع مرز),زمینهیا فقط سیستم. این عنصر نمودار مرز بین آنچه شما دوست دارید را نشان می دهد تحلیلگردر قالب سوابق (در این چارچوب)، و توسط آنچه شما به عنوان بازیگر (خارج از آنها) به تصویر کشیده اید. اغلب این مستطیل نشان داده می شود مرزهای خود سیستم شبیه سازی شده. یعنی، در داخل مرز، مواردی وجود دارد - عملکردی که سیستم پیاده سازی می کند (و از این نظر، پیشینه ها را می توان به عنوان نمایشی از زیر سیستم ها و کلاس های مدل در نظر گرفت)، و در خارج - شخصیت ها: کاربران و دیگران موجودیت های خارجی، در تعامل با سیستم مدل شده.

باید گفت که چارچوب سیستم به ندرت در نمودارهای مورد استفاده به تصویر کشیده می شود، زیرا آنها به طور ضمنی توسط خود نمودار مشخص می شوند. توسطاساساً این عنصر هیچ اطلاعات معنی‌داری اضافی به نمودار اضافه نمی‌کند، بنابراین استفاده از آن برای تحلیلگر سلیقه‌ای است. ظاهر چارچوب سیستم در نمودار مورد استفاده اغلب توسط ویژگی های سبک طراحی شخصی دیکته می شود.

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

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

شاید واژه «نقش‌هایی که کاربر انجام می‌دهد» در تعریف بازیگر چندان واضح به نظر نرسد. این مفهوم در Zicom Mentor بسیار خنده دار توضیح داده شده است:

نقش یک کاربر خاص نیست، بلکه نوعی کلاه است که فرد هنگام تعامل با یک موجودیت بر سر می گذارد.

در واقع، یک کلاه دزدان دریایی به سر بگذارید و شما کاپیتان جک اسپارو هستید، اما یک کلاه بالا بگذارید و شما جک چاک دهنده هستید! شوخی کردم... "فیزیکی" کاربرمی تواند نقش یک یا حتی چند بازیگر را ایفا کند و وظایف خود را در هنگام تعامل با سیستم انجام دهد. برعکس، نقش یک بازیگر می تواند توسط چندین کاربر انجام شود.

روی نمودارها UMLاکتورها به عنوان مردان سبک نشان داده می شوند، زیرا، همانطور که البته به یاد دارید، ایده ایجاد نمادی بود که هر نمادی از آن را می توان به راحتی با دست به تصویر کشید (برنج 6.4):

برنج. 6.4.

با وجود ظاهر "انسانی" این نامگذاری، نباید فراموش کنیم که بازیگران لزوماً مردم نیستند. یک بازیگر، همانطور که قبلاً گفتیم، می تواند یک سیستم خارجی، یک زیر سیستم، کلاسبه هر حال، مرد کوچک ("چسبنده" ) تنها نام ector استفاده شده در نیست UML. در نمودارهای موردی، معمولاً شکل «انسان‌نمایی» بازیگر استفاده می‌شود، اما در نمودارهای دیگر و به‌ویژه در مواردی که بازیگر دارای صفات است، که نشان دادن آن مهم است، از تصویر ector به عنوان یک کلاس با کلیشه استفاده می شود<> (شکل 6.5):

برنج. 6.5.

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

و یک چیز دیگر - بازیگران نمی توانند با یکدیگر ارتباط برقرار کنند. تنها مورد قبول نگرشبین بازیگران - تعمیم(وراثت). دوباره، در مثال ما از سفارش ناهار در دفتر، دقیقاً می شد این نوع رابطه را بین بازیگران مشاهده کرد. این در زندگی واقعی به این معنی نیست دفتر- مدیر و منشی (و در واقع هر دو کارمند) نمی توانند ارتباط برقرار کنند: فقط این است که هنگام ایجاد یک مدل سابقه ای، چنین ارتباطی در حوزه مورد علاقه ما قرار نمی گیرد و بی اهمیت تلقی می شود.

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

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

برنج. 6.6.

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

خواننده با دقت ممکن است متوجه شده باشد که چقدر بی سر و صدا معرفی کردیم کلمه " سناریو". چیست؟ سناریوو مفهوم سناریو چه ارتباطی با مفهوم سابقه دارد؟ اولین سوال را کلاسیک ها به خوبی پاسخ داده اند (G. Buch):

اسکریپت دنباله خاصی از اقدامات است که یک رفتار را نشان می دهد.

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

سناریوها همچنین گاهی اوقات می توانند در نمودار استفاده دیده شوند. گاهی اوقات آنها را به عنوان " ورق کاغذ"، که روی آن نوشته شده است نام فایل، - یک مستطیل با گوشه پایین سمت چپ منحنی. در این مورد، مشخص شده است فایلشامل شرحی از این سناریو است. و گاهی سناریودر کامنت نوشته شده است همانطور که احتمالاً به خاطر دارید، نظرات با مستطیل هایی با گوشه سمت راست بالای منحنی نشان داده می شوند و با یک خط نقطه چین به عنصری که توضیح می دهند متصل می شوند.برنج 6.7).

برنج. 6.7.

همانطور که قبلا ذکر شد، اسکریپت ها را می توان به اشکال مختلف نوشت. این می تواند یک متن ساختار یافته اما غیر رسمی، یک متن ساختارمند رسمی، شبه کد, جدول, نمودار فعالیت، بالاخره! هر سناریویک تعامل کامل و خاص را که از دیدگاه کاربر هدف خاصی دارد، به شکل روایت توصیف می کند. اگر شکل جدولی ارائه سناریو را در نظر بگیریم، خطی که ستون های چپ و راست جدول را تقسیم می کند، نماد مرزی است که اقدامات کاربر را از اقدامات پاسخ سیستم جدا می کند. فرم جدولی بر مشارکت کاربر تاکید دارد که در طراحی رابط کاربری یک جنبه بسیار مهم است.

در اینجا نمونه ای از شرح متنی ساده (غیر رسمی) سناریو آمده است.

کاربر نام کاربری، رمز عبور، آدرس ایمیل و کد تایید را وارد کرده و روی دکمه "بعدی" کلیک می کند. سیستم از شما می خواهد که یک کد تأیید را وارد کنید. کاربر کد را وارد کرده و روی دکمه "بعدی" کلیک می کند. سیستم بررسی می کند که آیا کد با کد نشان داده شده در تصویر مطابقت دارد یا خیر .

آیا این یک روش آشنا نیست؟ بله، این توضیحات مربوط به ثبت نام کاربر در برخی از سایت ها است. درست است که کاملاً کامل نیست: مواردی که ورود به سیستم انتخابی کاربر قبلاً گرفته شده است در نظر گرفته نمی شود. آدرسایمیل اشتباه وارد شده، رمز عبورالزامات را برآورده نمی کند یا کد با کد نشان داده شده در تصویر مطابقت ندارد. در مورد چنین مواردی - سناریوهای جایگزین- کمی بعد صحبت می کنیم.

و اینجا همان یکی است سناریودر نمای جدول:

البته شما متوجه این موضوع شدید سناریومی توانید آن را به تفصیل شرح دهید - به عنوان مثال، قبل از اینکه از شما بخواهد یک کد تأیید را وارد کنید، سیستم تصویری را نمایش می دهد که در آن این کد به تصویر کشیده شده است. یعنی درخواست کنیدبرای وارد کردن کد را شامل می شود نتیجه گیریتصاویر با کد ذکر شده بعداً در این مورد نیز صحبت خواهیم کرد.

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

برنج. 6.8.

همانطور که می بینید، برای هر ارتباط در نمودار یک وجود دارد کثرتو معنای آن کاملاً روشن است، اما هنوز باید در مورد کثرت جداگانه صحبت کنیم. یکی سابقهسناریوهای متعددی را تعریف می‌کند که هر کدام نشان‌دهنده یکی از انواع احتمالی جریان رویدادها هستند که توسط مورد استفاده تعریف شده‌اند. سناریوها مانند موارد استفاده از یک کلاس مرتبط هستند. یک اسکریپت یک نمونه از یک مورد استفاده است، چگونه شی- نمونه ای از کلاس برای مثال، سیستم ممکن است شامل چندین ده سابقه باشد که هر کدام به تنهایی صف، می تواند در ده ها سناریو آشکار شود. به عنوان یک قاعده، سابقهنه یک توالی از اقدامات را توصیف می کند، بلکه بسیاری از اقدامات را توصیف می کند، و معمولاً غیرممکن است که تمام جزئیات مورد مورد بررسی را با استفاده از یک توالی اقدامات بیان کنید. تقریباً برای هر سابقه ای، می توان اصلی را شناسایی کرد سناریو، توالی "عادی" عمل را توصیف می کند و کمکی، توصیف می کند جایگزینتوالی هایی که با وقوع شرایط خاصی آغاز می شوند.

سؤال دیگر: آیا چنین توضیحی از مدل سابقه لازم است، آیا برای سطح معینی از تقریب قابل توجیه است یا «ضمنی» است؟ جایگزینآیا می توانید اسکریپت ها را حذف کنید؟ به عنوان مثال، در مثال قبلی با خرید بلیط در میز خدمات، سناریوهایی (و بر این اساس، سوابق) مربوط به گزینه‌ها را به تصویر نمی‌کشیم، زمانی که دیگر بلیطی برای پرواز انتخاب شده توسط مسافر باقی نمانده است. مسافر تصمیم خود را تغییر داد و می‌خواهد برای پرواز دیگری بلیط بگیرد پرداختبه صورت نقدی می رود یا توسطکارت اعتباری و غیره

"از زدن دور بوته بس کن!" - خواننده بی حوصله فریاد خواهد زد. ما در حال حاضر کار را تمام می کنیم. ما صرفاً می خواستیم خواننده را با ملایمت به سؤال رابطه بین سوابق سوق دهیم. و این روابط بسیار متنوع است. بیایید با یک دوست قدیمی شروع کنیم - رابطه تعمیم (ارث، تعمیم). ما قبلاً بیش از یک بار در مورد تعمیم صحبت کرده ایم نمودارهای کلاس. اما اجازه دهید هنوز جوهر این مفهوم را به یاد بیاوریم. همانطور که کلاسیک ها می گویند، تعمیم- این نگرشتخصص (تعمیم)، که در آن اشیاء یک عنصر تخصصی (تبار) را می توان جایگزین اشیاء یک عنصر تعمیم یافته (والد یا جد) کرد.

دقیقاً به همان روشی که معمولاً با کلاس ها انجام می دهیم، بعد از اینکه هر کدام را شناسایی و توصیف کردیم سابقه، باید همه آنها را بررسی کنیم تا ببینیم آیا آنها اقدامات یکسانی دارند - نگاه کنید تا ببینید آیا برخی از اقدامات با هم توسط چندین مورد استفاده انجام می شود (استفاده می شود). این قطعه مشترک بهتر در یک مورد استفاده جداگانه توضیح داده شده است. به این ترتیب ما کاهش خواهیم داد افزونگیبا استفاده از تعمیم سوابق مدل سازی کنید (اما گاهی اوقات آنها نه در مورد تعمیم، بلکه در مورد استفاده کنیدسوابق؛ چرا - اکنون خواهید فهمید). همانطور که در طول وراثت «فرض می‌شود»، مواردی از سوابق تعمیم یافته (فرزندان) رفتار ذاتی در سابقه تعمیم یافته (جد) را حفظ می‌کنند. به عبارت دیگر حضور (استفاده) در یک مورد استفاده X مورد استفاده عمومی Y به ما می گوید که نمونه استفاده از مورد X را شامل می شودرفتار پیشین Y . از تعمیم‌ها برای آسان‌تر کردن درک مدل استفاده از موارد استفاده «خالی» برای ایجاد موارد استفاده مورد نیاز مشتری استفاده می‌شود. کلاس، یا بهتر است از یک راه حل آماده استفاده کنید، آیا قیاس را احساس می کنید؟). چنین سوابق "کامل" نامیده می شود سوابق خاص. به «شاخه‌های» سوابق، که فقط برای استفاده مکرر در پیشینه‌های دیگر ایجاد می‌شوند، سابقه‌های انتزاعی می‌گویند. چکیده سابقه(و همچنین کلاس انتزاعی) خودش وجود ندارد توسطخود، اما نمونه مورد استفاده ملموس رفتار توصیف شده توسط موارد استفاده انتزاعی را که (دوباره) استفاده می کند، نشان می دهد. سابقه، که بازیگران هنگام تعامل با سیستم مشاهده می کنند ("کامل" سابقه، همانطور که قبلاً آن را نامیده ایم)، اغلب به نام " واقعی"سابقه

همانطور که در بالا گفتیم، تعمیم (وراثت) اغلب بین کلاس ها و رابط ها استفاده می شوند. با این حال، سایر عناصر مدل نیز می توانند از نظر وراثت با یکدیگر مرتبط باشند - به عنوان مثال، بسته ها (که در اینجا در مورد آنها صحبت نمی کنیم)، بازیگران، سابقه ...

به تصویر کشیده شده است تعمیمهمانطور که، البته، خواننده توجه به یاد می آورد، یک خط با یک فلش مثلثی "پر نشده" در انتها. تعمیم- این نگرشبین یک جد و یک نسل، و فلش همیشه به جد اشاره می کند. اگر به یاد داشته باشیم که اولاد خصوصیات جد خود را به ارث می برند (استفاده می کنند)، آنگاه عبارت ما که فلش های UMLهمیشه به سمت کسی است که از او چیزی می خواهند و از خدمات او استفاده می کنند (برنج 6.9):

برنج. 6.9.

همانطور که قبلاً گفتیم و در اولین مثال خود دیدیم از نمودارهای موردی استفاده کنید, تعمیممی توان برای ایجاد انواع مختلف اکتورها استفاده کرد. بازیگران نسل ویژگی های اساسی را از جد به ارث می برند و آنها را با ویژگی های خاص خود تکمیل می کنند. دقیقا همینطوره سابقه-نوادهرفتار و معناشناسی مورد استفاده والدین را به ارث می برد و رفتار آن را تکمیل می کند.

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

شمول چگونه به تصویر کشیده می شود؟ بله، بسیار ساده - مانند یک اعتیاد (خط نقطه چین با یک فلش، یادتان هست؟) با یک کلیشه<> . در این حالت، فلش به طور طبیعی به سمت پیشینه گنجانده شده است. توضیح این واقعیت آسان است اگر بیانیه ای را که قبلاً چندین بار در این دوره استفاده کرده ایم به خاطر بیاوریم: فلش همیشه به سمت عنصری است که از آن چیزی مورد نیاز است و از خدمات آن استفاده می شود. و اگر فرض کنیم جامع است سابقهشامل، وام گرفتن (استفاده از) رفتار سوابق گنجانده شده است، مشخص می شود که فلش فقط می تواند در این راه هدایت شود. و اینجاست نمودار، نشان دهنده موارد فوق است که از Zicom Mentor وام گرفته ایم (برنج 6.10):

تصویر را بزرگ کنید
برنج. 6.10.

همانطور که این مثال به وضوح نشان می دهد، استفاده از گنجاندن به شما این امکان را می دهد که از توصیف چندین بار یک مجموعه از اقدامات اجتناب کنید - رفتار کلی را می توان به سادگی به عنوان یک مورد استفاده در موارد پایه توصیف کرد.

بعدی - نگرش پسوندها. برای درک معنای گسترش، بیایید تصور کنیم که ما در مورد پرداخت هزینه برای محصولی که خریداری کرده ایم صحبت می کنیم. ما می توانیم پرداخت کنیم محصولاگر مبلغ از 100 دلار تجاوز نمی کند، پول نقد یا اگر مبلغ از 100 دلار بیشتر باشد، با کارت اعتباری پرداخت کنید اعتبار. به این ترتیب ما درک خود را گسترش داده ایم عملیاتپرداخت برای کالای خریداری شده و در مواردی که از روش های پرداخت دیگری غیر از پول نقد استفاده می شود. اما خود این موارد فقط تحت شرایط کاملاً تعریف شده به وجود می آیند: چه زمانی قیمت محصولدر محدوده خاصی قرار می گیرد.

مکمل های گسترش سابقهسوابق دیگری که تحت شرایط خاص "کار می کنند" - به سادگی به نسخه اصلی اضافه می شود سابقهدنباله ای از اقدامات موجود در مورد استفاده دیگر. نگرشگسترش مورد استفاده A به استفاده از مورد B به این معنی است که یک نمونه از استفاده B می تواند شامل (تحت شرایط خاص، که می تواند در پسوند توضیح داده شود؛ دقیقاً چگونه توضیح داده شده است، کمی بعد خواهیم گفت) رفتار توصیف شده در مورد استفاده A را شامل شود. یک مثال در نمودار زیر نشان داده شده است (.برنج 6.11):

برنج. 6.11.

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

نقطه گسترش در شرح داده شده است بخش اضافی use case، که با یک خط افقی از نام آن جدا شده است - همانطور که بخش های جداگانه ویژگی های یک کلاس و آن را فهرست می کنند عملیات. در زیر نمونه ای از توضیحات نقطه توسعه است که از Zicom Mentor به عاریت گرفته شده است (برنج 6.12).

برنج. 6.12.

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

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

با جمع بندی تمام موارد فوق می توان گفت که پسوند به شما امکان می دهد رفتار سیستم اختیاری را مدل کنید(می شود کلاساگر مسافر به تعداد لازم مایل پرواز نکند و کابین تقریباً خالی باشد، بلیط افزایش می یابد؟). واقعیت گسترش بستگی به تحقق شرایط دارد - گسترش ممکن است اتفاق نیفتد! آنها صرفاً دنباله‌های فردی از کنش‌ها هستند که فقط در شرایط خاصی انجام می‌شوند و در نقاط خاصی از فیلمنامه (معمولاً در نتیجه تعامل صریح با بازیگر) ایجاد می‌شوند.

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

این می تواند گفتگو را در مورد نماد نمودارهای مورد استفاده به پایان برساند. من فقط می خواهم چند کلمه بیشتر در مورد رابطه بین مفاهیم سابقه و همکاری. قبلاً در مورد همکاری صحبت کرده ایم (به یاد داشته باشید نمودارهای تعامل?) به عنوان مجموعه ای از نقش ها که با هم کار می کنند تا برخی از رفتارهای سیستم را ارائه دهند. همچنین اشاره کردیم که موارد استفاده به این سوال پاسخ می‌دهند که «سیستم چه کار می‌کند؟»، اما دقیقاً نمی‌گوییم چگونه این کار را انجام می‌دهد. در مرحله تجزیه و تحلیل، واقعاً نیازی به درک دقیق نحوه اجرای رفتار سیستم وجود ندارد. اما وقتی به سمت پیاده سازی می رویم، بهتر است بدانیم کدام کلاس ها (یا سایر عناصر مدل) با هم کار می کنند تا رفتار مورد نظر را ارائه دهند. یعنی منطقاً از بحث سابقه به بحث همکاری رسیدیم! بی جهت نیست که نام های همکاری و سابقه بسیار شبیه به هم هستند (البته خواننده به یاد دارد که همکاریبا یک بیضی نقطه‌دار نشان داده شده است) (برنج 6.13).

برنج. 6.13.

پس در چه نسبتی هستند سابقهو همکاری? از پاراگراف قبل به طور منطقی نتیجه می گیرد که این نگرشاجرا هر سابقهتوسط یک یا چند همکاری اجرا می شود. البته این به این معنی نیست که کلاس ها به شدت توزیع شده اند توسطتعاونی ها: طبقاتی که در همکاری شرکت می کنند که یک معین را اجرا می کند سابقه، در سایر همکاری ها شرکت خواهد کرد.

مدلسازی با نمودارهای مورد استفاده

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

بنابراین، به طور خلاصه، می‌توانیم سه دلیل برای استفاده از سوابق بیان کنیم. یا، بهتر است، سه روش استفاده از سوابق (تصادفی نیست که در ترجمه روسی اغلب می توانید پیدا کنید عبارت "مورد استفاده"!) هنگام کار بر روی سیستم:

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

· موارد استفاده به توسعه دهندگان اجازه می دهد تا هدف یک عنصر را درک کنند : یک سیستم، زیرسیستم یا حتی یک کلاس می تواند موجودیت های پیچیده ای باشد که از تعداد زیادی قسمت تشکیل دهنده تشکیل شده و دارای تعداد زیادی ویژگی و عملیات باشد. پیشینه‌های مدل‌سازی به شما این امکان را می‌دهد که رفتار سیستم را بهتر تصور کنید، درک کنید که کدام عناصر مدل چه نقشی در اجرای این رفتار دارند، در چه نوع همکاری قرار می‌گیرند و چه نوع سابقه (عملکرد سیستم) را اجرا می‌کنند.

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

موارد استفاده هم برای مهندسی رو به جلو و هم برای مهندسی معکوس مفید هستند. در طراحی مستقیم ما، توسطدر اصل، ما یک "ترجمه" از UMLبرای برخی زبان برنامه نویسی. و آفریده شده را آزمایش کنید کاربرددقیقاً بر اساس جریان وقایع توصیف شده توسط سوابق به شرح زیر است. مهندسی معکوسشامل ترجمه از یک زبان برنامه نویسی به یک زبان است UML-نمودار این کارها به چند دلیل باید انجام شود:

· برای یافتن خطاها و اطمینان از کفایت طرح :

انجام یک ترجمه معکوس پس از اولین ترجمه از UML به یک زبان برنامه نویسی و مقایسه مدل های اصلی و بازسازی شده UML ایده خوبی است (توصیه می شود که این ترجمه ها توسط تیم های مختلف انجام شود). این اطمینان حاصل می کند که طراحی سیستم با مدل مطابقت داشته باشد، هیچ اطلاعاتی در حین ترجمه از بین نرود و به سادگی برخی "اشکالات" را پیدا کند. این رویکرد ردیابی معنایی معکوس (یا RST - معکوس معنایی) نامیده می شود قابلیت ردیابی) و توسط INTSPEI ( http://www.intspei.com ) به عنوان یکی از تکنیک های اساسی روش INTSPEI P-Modeling Framework، اطلاعات مختصری در مورد آن می توانید در پیوست این دوره بیابید.

· زمانی که اسناد از دست رفته است : گاهی اوقات وظیفه اصلاح یک سیستم موجود است که کد آن ضعیف است. در این مورد، ترجمه از یک زبان برنامه نویسی به نمودارهای UML راهی عالی برای درک هدف سیستم و قطعات آن، عملکردی که ارائه می دهد و غیره است.

در نهایت باید توجه داشت که البته استفاده از نمودارهای موردی به تنهایی و همچنین سناریوهایی که تعریف می کنند برای ایجاد مدلی از رفتار سیستم کافی نیست. همانطور که بیش از یک بار اشاره کرده ایم، موارد استفاده به ما می گویند که سیستم چه کاری انجام می دهد، اما نمی گویند چگونه. فیلمنامه ها در مورد این صحبت می کنند، اما به صورت متن، که درک آنها را بسیار دشوار می کند. نمودارها به کمک می آیند تعاملاتی که سناریوها را تجسم می کنند. بنابراین، اکنون می‌توانیم «شبه نمودار» قدیمی خود را تکمیل کنیم و روی آن تکیه کنیم (برنج 6.14):

برنج. 6.14.

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

برنج. 6.16.

دوم نمودار، همچنین به خوبی طراحی شده است، به ما می گوید که اردک ها واقعاً دوست ندارند برای آبجو هزینه کنند و ترجیح می دهند اعتباری بنوشند (برنج 6.17).

برنج. 6.17.

به هر حال، به فریم های نمودار نشان داده شده در این مثال توجه کنید - مستطیل، که قسمت محتوای نمودار را از هم جدا می کند و یک قسمت ویژه برای نام آن در بالای صفحه دارد.

و در نهایت تصویر سوم که مثال خوبی نیست از نمودارهای موردی استفاده کنید، اما فقط خنده دار است. این یک داستان در مورد روش های رفتاری است که به شما امکان می دهد در هر امتحانی شکست بخورید (!)برنج 6.18):

برنج. 6.18.

نتیجه گیری

· مدل مورد استفاده به شما امکان می دهد سیستم را در سطح مفهومی توصیف کنید.

· از نمودارهای موردی استفاده کنید - وسیله ای عالی برای ارتباط بین کارشناسان، کاربران و توسعه دهندگان و همچنین مبنایی برای آزمایش سیستم در حال ایجاد.

· یک مورد استفاده توصیفی از مجموعه ای از رویدادهای متوالی (شامل گزینه های احتمالی) است که توسط سیستم انجام می شود که منجر به نتیجه مشاهده شده توسط بازیگر می شود.

· بازیگر مجموعه ای از نقش هایی است که کاربر در حین تعامل با یک موجودیت انجام می دهد.

· مقدمات (مثل فاعل) قابل تعمیم است، یعنی خواص اجداد خود را به ارث می برند و تکمیل می کنند.

· موارد استفاده همچنین می‌توانند وارد روابط گنجاندن و گسترش با یکدیگر شوند، که به شما امکان می‌دهد موارد استفاده را به اجزای ساده‌تر تجزیه کنید و رفتار اختیاری را برجسته کنید.

· هر مورد استفاده توسط یک یا چند همکاری اجرا می شود.

· سناریوها موارد استفاده را مشخص می‌کنند و نمودارهای تعامل سناریوها را تجسم می‌کنند.

سوالات امنیتی

· الزامات غیر کاربردی چیست؟ چگونه در نمودارهای مورد استفاده نشان داده می شوند؟

· چه روش هایی برای به تصویر کشیدن اکتورها می شناسید؟

· بازیگران چه نوع روابطی می توانند با یکدیگر برقرار کنند؟

· منظور از رابطه شمول و گسترش چیست؟

· نقطه گسترش چیست؟

· دلایلی را که برای استفاده از سوابق می دانید فهرست کنید.

· موارد استفاده در مهندسی رو به جلو و معکوس چگونه استفاده می شود؟

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

به عبارت دیگر، نمودار است جزئیمشخصات

بیایید به یاد بیاوریم که در رویکرد مورد بررسی، شناسایی سوابق اصلی (اما نه همه ممکن) در مرحله اولیه توسعه نقش کلیدی ایفا می کند که این رویکرد را از یک رویکرد کاملاً الگوریتمی متمایز می کند. در این مورد، سناریوهای موفق (گزینه ها) معمولاً ابتدا در نظر گرفته می شوند.

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

به عبارت دیگر، فیلمنامه است جزئیالگوریتم سازی

مثال. ثبت نام بیمار برای قرار ملاقات در کلینیک.

این مثال ساده چیزی شبیه به سناریوی مورد استفاده پنهان زیر را در پشت آن فرض می‌کند (طبیعی است که آن را یک نظر در مورد نام مورد استفاده قرار دهیم):

"بیمار برای اهداف پیشگیرانه با کلینیک تماس می گیرد تا با پزشک قرار ملاقات بگذارد. ثبت نام کننده کلینیک نزدیکترین دوره رایگان را در گزارش ثبت نام پیدا می کند، زمان را با بیمار هماهنگ می کند و آن را در گزارش ثبت می کند."

قرار ملاقات (هماهنگ قرار ملاقات [با پزشک]) - نام سابقه. بیمار (بیمار) - نقش یک شخص. ارتباط بین یک بازیگر و یک سابقه، تداعی ارتباط است (به طور خلاصه، ارتباط به شکل پیام است)

مثال 2: شفاف سازی نمودار قبلی (با بسط دادن آن).

نمودار دوم جزئیات بیشتری از وضعیت را نشان می دهد. بازیگران جدید در اینجا ظاهر می‌شوند: برنامه‌ریز - ثبت‌نام، پزشک - پزشک، منشی - کارمند، و سوابق جدید لغو قرار ملاقات - لغو قرار ملاقات، درخواست دارو - درخواست درمان و صورت‌حساب پرداخت - پرداخت صورت‌حساب.

چارچوب‌های مدل‌سازی UML بزرگ دارای قابلیت نسخه‌سازی هستند. در این حالت، می‌توان نمای را گروهی از نمودارها در نظر گرفت که یا به آخرین نسخه یا به همه آنها مربوط می‌شود. بدیهی است که دومی ارجح است.

در حال حاضر اولین مثال "سوال اصلی همه زمان ها و مردم" را پیش روی ما قرار می دهد: "خب، چرا من به این نمودارهای پیشین نیاز دارم؟" یک گزینه حتی محبوب تر: "به هر حال چه کسی به آنها نیاز دارد - همه این نمودارها!" در طول فرآیند یادگیری، بهتر است آن را در درون خود پنهان نکنید، بلکه آن را به سمت خود هدایت کنید و آن را بازنویسی و مشخص کنید. به چه کسی دقیقاو چه زمانی دقیقاو چرا دقیقاآیا آنها مفید هستند؟

برنامه نویس، البته، امکانات پیاده سازی نرم افزار را برای خود خواهد دید - خطوط کلی [معماری، ساختار] برنامه آینده. برای درک سایر احتمالات، فقط باید خود را در نقشی متفاوت تصور کنید. به عنوان مشتری - برای ارزیابی سودمندی استفاده از سیستم در کار خود. در نقش مشتری و مدیر - هنگام بحث در مورد کار. در نقش یک آزمایشگر - هنگام آماده سازی تست برای اجرای شاخه های خاصی از سیستم نرم افزاری.

اخلاق قدیمی است - مفید است که جای دیگری را بگیریم، به جهان از چشم او نگاه کنیم.

اما بیایید دوباره به یک مثال خاص نگاه کنیم. چرا چنین توضیحی لازم است؟ برای کسی که با حوزه موضوعی آشناست - در این مورد، سیستم مراقبت های بهداشتی - اطلاعات جدیدی در این نمودار وجود ندارد. از نظر او قبلاً به طور ضمنی در اولی وجود دارد و می توان از آن استخراج کرد. با این حال، اولا، همه افراد به یک اندازه با این دامنه آشنا نیستند. ثانیاً، آنها ممکن است هم در مورد خود دامنه و هم در مورد اینکه چه ویژگی هایی از آن باید در سیستم در حال توسعه منعکس شود، نظرات متفاوتی داشته باشند. در نهایت، ممکن است در آینده به سادگی فراموش کنیم که بر سر چه چیزی توافق کرده ایم.

به عبارت ساده، برای درک نیاز به نمودارها اصلا، کافی است خود را فردی تصور کنید که همه چیز را نمی داند، همه چیز را به خاطر نمی آورد، نمی داند چگونه همه چیز را انجام دهد و غیره. خلاصه خیلی خوبه که متواضع تر باشیم...

شرح ارتباطات نمودارهای توالی [سیستم] - نمودارهای توالی

نمودارهای توالی برخی از سیستم های اشیاء - مصنوع مدل (بخشی از توضیحات مستند) موارد استفاده مورد استفاده برای توصیف جزئی رفتارسیستمی از اشیا در قالب سناریوهای ممکن، اصلی (موفق) و جایگزین.

هدف اصلی چنین نمودارهایی نمایش رویدادهایی است که توسط مجریان به سیستم در سراسر مرزهای آن منتقل می شود. هر یک از آنها یک توصیف شماتیک ارائه می دهد سناریوی پیشینبه عنوان دنباله ای از رویدادهای تولید شده توسط بازیگران خارجی - و فشرده، قابل مشاهده(برای تجزیه و تحلیل، کنترل و غیره) شرح رویدادهای تولید شده در خود سیستم. به عبارت دیگر، نمودار سعی می کند به این سوال پاسخ دهد: "چه رویدادهای اصلی از بیرون آغاز می شوند" نه اینکه سیستم دقیقاً چگونه به سیگنال های خارجی واکنش نشان می دهد. نه دقیقا و به طور کامل - فقط تا حد ممکن.

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

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

به یاد بیاورید که کلاس ها و اشیاء در OOP - به ترتیب در سطحی کم و بیش انتزاعی - نمایش ایستا از یک مدل را توصیف می کنند. آنها حاوی نشانه ای از روش ها هستند - یک مرجع نامگذاری شده برای تعریف قوانین (الگوریتم ها) بالقوهرفتار اشیا، در حالی که رفتار واقعی اشیاء را در ارتباط با یکدیگر پنهان می کند. به زبان ساده، آنها به این سؤال پاسخ می‌دهند که «یک شیء داده شده چگونه می‌تواند رفتار کند» به جای این سؤال که اشیاء چگونه رفتار می‌کنند – با هم، به عنوان یک کل.

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

از برنامه نویسی رویه ای، ما با مفهوم بسیار آشنا هستیم [وضعیت] آثار، که رفتار واقعی یک شی را به صورت دنباله ای از تغییرات در حالات آن توصیف می کند. در این مورد، هر یک از حالت ها به شکل مجموعه ای نامگذاری شده از مقادیر متغیر توصیف می شود - ویژگی های وضعیت جسم در یک نقطه خاص از زمان. مدل مدیریت امری (فرمان) دلالت بر آن دارد کسی(مجری سطح بالا) تغییرات را به یک شیء فرعی فرمان می دهد و رویه های مرتبط با آن را مطابق با برخی از قوانین فراخوانی می کند - یک الگوریتم، برنامه ای برای تغییرات در یک شی تابع. آهنگ تماس- و شاخه ای از اجرای الگوریتم وجود دارد که به صورت دنباله ای از نام رویه های مربوطه نمایش داده می شود.

در این مورد، ما دوباره در مورد مسیر تماس صحبت می کنیم - به طور دقیق تر، در مورد مسیر پیامی که چنین تماس هایی را آغاز می کند. اما در مورد پیچیده‌تر سیستمی از اشیاء که (از طریق فراخوانی روشی از شی مبدا) حالات شی گیرنده (و همچنین، احتمالاً به عنوان یک اثر جانبی، حالات اشیاء دیگر) را تغییر می‌دهند. تغییر حالت اکنون به عنوان "رویدادی در زندگی یک شی" تعبیر می شود.

هنوز اشیاء خارجی وجود دارند که فرآیندهای پیام رسانی داخلی را آغاز می کنند، اما در موارد پیچیده تر، هیچ "فرمانده" اصلی و سلسله مراتبی از تابعیت وجود ندارد.

مثال. رزرو هتل.

شی خارجی که جریان پیام را آغاز می کند پنجره Reservation است. شی پنجره Reservation یک پیام makeReservation() را به سرویس HotelChain مناسب ارسال می کند. که به نوبه خود، پیام makeReservation() را به هتل ارسال می کند. اگر هتل اتاق های در دسترس داشته باشد، شی هتل روش های رزرو و تایید را فراخوانی می کند.

هر یک از "خطوط حیات" عمودی نقطه‌دار نشان‌دهنده زمان پر از رویداد وجود بالقوه یک شی است - به شکل تغییرات در حالات سایر اشیاء و تغییر در حالت‌های خود. هر فلش تماس با روشی را برای ارسال پیام توصیف می کند. فلش از فرستنده به گیرنده پیام می رود و نوار فعالیت (دوره پردازش پیام - نوار فعال سازی) را در مختصات زمانی برجسته می کند.

در نمودار، شی هتل خود را فراخوانی می کند (خود فراخوانی) تا در دسترس بودن یک اتاق را تعیین کند. اگر شرط IsRoom درست باشد، هتل اشیاء Reservation و Confirmation را ایجاد می کند. ستاره روی تماس موجود به معنای تکرار است - یک تماس چرخه ای (به منظور یافتن اینکه آیا اتاق برای تمام روزهای اقامت مورد انتظار مهمان در دسترس است یا خیر). عبارت در پرانتز به معنای یک شرط (گزاره) است.

این نمودار همچنین شامل یک توضیح توضیحی در قالب متن بر روی یک مستطیل با گوشه منحنی است - ممکن است و در هر مورد غیر واضح، برای هر نمودار UML دیگری ضروری است.

نمودارهای همکاری (تعامل) –

نمودارهای همکاری

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

مثال. همان چیزی است - رزرو اتاق هتل.

مستطیل‌هایی که نقش‌های شیء را نشان می‌دهند با نام کلاس و/یا شی برچسب‌گذاری می‌شوند (در حالت دوم، نام کلاس با یک دونقطه از نام شی جدا می‌شود). پیام های موجود در نمودار همکاری شماره گذاری شده است. در این حالت، پیام‌های سطح پایین - که در طول پردازش یک پیام خاص ارسال می‌شوند - با پیشوندهایی که با نقطه‌هایی از شماره پیام سطح بالاتر جدا شده‌اند شماره‌گذاری می‌شوند - مطابق با دنباله این تماس‌ها.

به عبارت دیگر، در این روش شناخته شده (نشانگذاری درخت خطی) واقعیت زیر یا تودرتوی فرآیندهای پردازش پیام پنهان در اینجا - یکی در دیگری - رمزگذاری می شود. مانند قبل، آنها نمی توانند همپوشانی داشته باشند.

شرح ساختار. نمودارهای حالت نمودارهای استیتچارت

نمودارهای حالت، یا نمودارهای خودکار، شاید برای ما آشناترین باشند. یا بهتر بگویم، باید باشدما با - حداقل از دوره مقدماتی ریاضیات گسسته آشنا هستیم.

اجازه دهید مقررات کلی را یادآوری کنیم. ماشین حالت محدود مدلی از پاسخ احتمالی (در قالب یک واکنش مستقیم و معکوس) یک شی مدل سازی به رویدادهای خارجی - تغییرات در محیط خارجی (اطراف، پیرامون، موقعیت، زمینه و غیره) است.

مفهوم خودکار برای درک نمودار منطقی عملکرد یک کامپیوتر به عنوان دستگاهی که گام به گام عمل می کند، مرکزی است. یک و تنهایک عملیات (مانند هر عملیات دیگری) که یک عملیات کاربردی را شبیه سازی می کند (اعمال یک تابع در یک آرگومان). به طور ضمنی، مفهوم خودکار در ابتدای مفاهیم اولیه برنامه نویسی نهفته است - برای مثال، رفتار برنامه ها به عنوان مبدل جریان ها و/یا فایل های متوالی. اما در این مورد، باید مفاهیم قبلی را به خاطر بسپاریم. نه در مورد کامپیوتر یا برنامه، بلکه در مورد سگ به همان اندازه معروف آکادمیسین پاولوف...

به طور کلی ماشین به چنین تغییراتی در محیط واکنش نشان می دهد

• به وضوح با تغییر در وضعیت ساختار داخلی آن، نامرئی از بیرون و پنهان در داخل آن مشخص می شود. چنین حالت‌های داخلی نام‌گذاری شده‌اند، اما در تئوری خودکار توضیح داده نشده‌اند.
• تغییر در وضعیت محیط - ضمنی، زیرا وجود چنین حالات محیطی ضمنی است، اما خود حالت ها تعیین نمی شوند.

بازخورد تغییری در رفتار (وضعیت داخلی) یک خودکار است که (به طور غیرمستقیم) در نتیجه اقدامات خود برای تغییر محیط رخ می دهد.

به صراحت تعریف شده است ارتباطخودکار با محیط، در فرم

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

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

• ورودی - تایپ کردن روی صفحه کلید - [احتمالاً] یک شناسه عمومی معتبر (فعال، صحیح) کاربر - مانند شماره پاسپورت. در این مورد، این شماره تامین اجتماعی مشتری SSN (شماره تامین اجتماعی)،
• وارد کردن یک شناسه شخصی معتبر [احتمالاً] کاربر به عنوان مشتری این پین بانک (شماره شناسه شخصی)
• ارسال این اطلاعات برای تایید

شرح حالات مجاز [داخلی] ممکن با نام شروع می شود. دریافت SSN - دریافت SSN، دریافت پین - دریافت پین، اعتبارسنجی - بررسی و رد کردن - امتناع، در صورت عدم موفقیت سناریوی پیش‌فرض. بعد، انتقال از حالت به حالت تعریف می شود، برای هر زوجایالت ها و تمام ترکیبات ممکنپیام ها

آنچه در نظریه مجموعه ها بر حسب مفهوم بنیادی توضیح داده شده است محصول دکارتیمجموعه ها

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

اما قابلیت‌های زبان‌ها همیشه با نیاز به حل مشکل مشخص می‌شود، و قبل از "وارد شدن به داخل جعبه (سیاه یا خاکستری)" ارزش دارد به کدام یک فکر کنید؟ نظریه کلاسیک پیچیدگی محاسباتی یک "انفجار اطلاعات" را تعریف می کند - انبوهی از اطلاعات که شخص نمی تواند آن را از نظر نمایی مدیریت (مدیریت) کند (مثلاً 2 n). که بدون شک است، اما... در عمل برنامه نویسی، چند جمله ای ها (در این مورد، حداقل n 2) از قبل در حالت کلی قرار دارند. غیر قابل مدیریت - کنترل نشده، تجزیه و تحلیل، تأیید و غیرهبرای اینکه در چهره هرج و مرج به نظر برسید، تنها کاری که باید انجام دهید این است که ماشینی با 50 حالت را تصور کنید. به نظر زیاد نیست... اگر نه برای 2500 انتقال ممکن.

این مربوط می شود هرنمودارها - باینری و نمودارهای دیگر، بدون توجه بهدر مورد تفسیر، نوع تکلیف شرح و روش حل آن. من امیدوارم که اکنون نه تنها منشأ UML، بلکه همه روش‌های ساختاری دیگر در برنامه‌نویسی و به طور کلی، هدف فرمالیسم‌های ریاضی را درک کنیم. و تو گفتی - "انتزاعی خالی، جدا از زندگی"... زندگی کیست؟ - نه از زندگی یک توصیفگر مدل.

اجازه دهید به یک ویژگی جالب مثال توجه کنیم. مجوز یک چیز (شیء فیزیکی) نیست، نه سیستمی از این اشیاء، بلکه فرآیند. و البته در عین حال مورد توجه و توصیف کنونی ماست.

نمودارهای فعالیت –

نمودارهای فعالیت

نمودارهای فعالیت، در اصل، فلوچارت های شناخته شده ای با تعدادی ویژگی هستند که منعکس کننده تغییر در رویکرد رویه ای تحت تأثیر OOP و آن ایده هایی از توصیف های جزئی هستند که قبلاً با رویکرد تکراری مرتبط بودیم.

به طور خاص، تفسیر الگوریتم ها به عنوان یک توصیف تجمعی از بسیاری از سناریوهای موفق و ناموفق از سوابق - در موارد پیچیده تنها به طور جزئی در هر مرحله از توسعه توصیف می شود.

قابل توجه ترین تفاوت ها در مثال زیر قابل مشاهده است.

مثال. طرح عملکرد دستگاه خودپرداز برای خدمات رسانی به مشتری (مشتری) یک بانک (بانک).

مانند قبل، شرایط (مقدمات) با الماس، روش ها (عملگرهای [سفارشی]) با مستطیل هایی با انتهای گرد نشان داده می شوند.

شرط نگهبانی در اینجا به عنوان بررسی برای اینکه آیا یک روند نادرست از رویدادها باید رخ دهد - یعنی. سناریوی بد اساسا، نیاز به رسیدگی به یک استثنا منطقی (ناشی از شکست "زمان منطقی"، نه "زمان اجرا").

خطوط شنا "شناگران" را از هم جدا می کنند - اشیایی که روش های آنها اجرا می شود. همانطور که از مثال مشاهده می شود، در واقع آنها در اینجا چنین تفسیر می شوند موضوعات فعالیت، انجام چند کار کلی.

در تضاد شدید با رویکردهای ضروری اولیه و رویه های بعدی. در شیء اول اجرا می کندفرمان، در دوم - اقدامات در حال انجام هستند.در هر دو مورد - بدون اشاره صریح به سوژه (بازیگر) شروع کننده (شروع، فعال کردن) عمل (عملیات). نمودارهای جریان (یعنی نمودارهای جریان) جریان انتقال کنترل را با یک موضوع کنترل ضمنی و یک شی کنترل صریح بیان می کنند. در این مورد، بهتر است در مورد موضوعات - در چارچوب توزیع و انتقال قدرت و مسئولیتبرای این یا آن قسمت از کار

در ادامه تحلیل این موارد، بسته به حوزه موضوعی خاص، می‌توان دو تفسیر از مثال را مجاز دانست.

· دستگاه خودپرداز و بانک با هم یک سیستم سرور را تشکیل می دهند که کار را برای مشتری آغاز کننده (بازیگر) انجام می دهد - که دارای اولویت است که در ترتیب موضوعات منعکس شده است.

· همه آزمودنی ها برخی از کارهای مشترک را انجام می دهند و منافع همکاری متقابل سودمند را دنبال می کنند. مشتری کار را آغاز می کند نه به این دلیل که اولویت مطلق دارد - بلکه فقط به این دلیل که "این بار هنوز کسی باید اول شروع کند." به عبارت دیگر، در نمودارهای دیگر ترتیب متفاوتی از ترتیب موضوعات امکان پذیر است.

البته، اولین تفسیر، مشخصه رویکردهای مدرن «مشتری-سرور»، برای این حوزه موضوعی مناسب‌تر است.

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

پیامد فوری «تقسیم کار» که در اینجا بین چندین بازیگر به وجود می‌آید، نیاز به هماهنگی موازی‌سازی در حال ظهور در اجرای اقدامات است. در نمودار، چنین هماهنگی با نوع جدیدی از انشعاب - چنگال و پیوستن به فرآیندها نشان داده شده است.

موازی گرایی موضوعی بسیار پیچیده است که در معرض تفاسیر بسیاری است. در چارچوب نیاز به توصیف حوزه موضوعی، ادامه مبحث تقسیم کار بین موضوعات بر اساس نیاز به دستیابی به یک نتیجه مشترک، طبیعی است. در این نسخه "چند پردازنده" ترتیب اقدامات مهم نیست.

بر اساس قابلیت های توصیفگر، تفسیر متفاوتی امکان پذیر است. می دانیم که این فرآیند باید در نقطه ای آغاز شود و در نقطه ای پایان یابد. اما [هنوز] ما دقیقاً ترتیب اقدامات را نمی دانیم.

وظیفه توصیف حوزه موضوعی.

مدل دامنه کلاس‌های مفهومی را نمایش می‌دهد - از دیدگاه مدل‌ساز، کلاس‌های اصلی مفاهیم مرتبط با حوزه موضوعی (نه به اجرای نرم‌افزار).

در مورد مدل سازی کسب و کار - فعالیت های شرکت های بزرگ - معمولا در مورد منطق کسب و کار، مدل سازی کسب و کار و غیره صحبت می کنند. در UML، یک مدل دامنه به صورت مجموعه ای از نمودارهای کلاس نمایش داده می شود , که روی آن ویژگی ها و متدها نام برده شده است، اما به طور کلی پیاده سازی نشده اند. به عبارت دیگر، در صورت امکان، رابط های کلاس تعریف می شوند.

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

درست است، در رویکرد پیشنهادی، این دیگر به معنای تبعیت یک جانبه نیست - همانطور که فوری ضروری است (گاهی) - بازخورد(بازخورد) - ممکن است به دلیل عدم امکان تکمیل کار در شرایط معین - برای مثال، با منابع زمانی معین (یعنی به موقع) درخواست تغییر کار کند.

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

مدل دامنه نمایش می دهد:

· اشیاء دامنه یا کلاس های مفهومی.

· انجمن هابین کلاس های مفهومی؛

· ویژگی ها و عملیات کلاس های مفهومی (نام ویژگی ها و روش ها).

نمونه ای از نمودار کلاس. طرح پرداخت سفارش

این مثال تقریباً سناریوی زیر (موفقیت‌آمیز) پرداخت (پرداخت) سفارش (سفارش) توسط مشتری (مشتری) برخی از شرکت‌های تجاری و حمل و نقل را نشان می‌دهد: «مشتری که فهرستی از کالاها را سفارش داده است (به مورد - مشخصات اموال کالا در یک نقطه جداگانه از سفارش) می تواند هزینه سفارش را با کارت اعتباری (اعتباری)، وجه نقد (نقد) یا چک بانکی (چک) پرداخت کند."

لطفاً توجه داشته باشید که نمودارهای کلاس، علاوه بر خود کلاس ها، در قالب یک نمودار انواع ارتباطات واقعی (تداعی) بین کلاس ها را توصیف می کنند.

به عبارت دیگر، هنگام توصیف ساختار طبقات، از نظریه مجموعه ها و روابط (رابطه) استفاده می کنیم. رابطه ایرویکردی که قبلاً هنگام تسلط بر پایگاه های داده رابطه ای در نظر گرفتیم. اجازه دهید در اینجا به امکان نشان دادن تعدد روابط توجه کنیم، که به طور دقیق تر (در مقایسه با "یک" و "چند") توضیح می دهد که چند شی (نمونه) از یک کلاس می تواند در یک رابطه معین با کلاس دیگر باشد. 0..1 - نه بیشتر از یک، 1 - دقیقا 1، 1* - نه کمتر از یک، و غیره.

برخی از سردرگمی ها در اینجا معمولاً از انواع مختلف اتصالات ناشی می شود. در اینجا، ارتباط هر گونه ارتباط احتمالی بین کلاس ها است، صرف نظر از اینکه چه رابطه بیشتری بین اشیاء دلالت دارد.

برخی از آنها - مانند قبل - به شرح ساختار داده مربوط می شود. اینها برای مثال، رابطه مشتری-سفارش و رابطه «قسمت-کل» (تجمیع، رابطه تجمیع) بین کلاس‌های Order و OrderDetail هستند.

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

نشانک برای آینده علاوه بر "فقط اتصالات"، یکی از ویژگی های خاص UML توانایی تعریف انواع دیگر، سفارشی از اتصالات، و همچنین گروه بندی کلاس ها در بسته ها- به دلایلی غیر از مواردی که قبلاً صحبت کردیم. از جمله آینده، هنوز برای ما ناشناخته است.

معمولاً بسته‌ها (و همچنین در ابتدا ماژول‌ها و مؤلفه‌ها) با حل مشکلات ویژه پردازش برنامه‌ها به عنوان داده (مثلاً کامپایل) همراه هستند، اما ما آزادیم که از آنها به دلایل اصلی دیگر استفاده کنیم (اگر واقعاً اصلی باشند).

نمودارهای اشیاء *

نمودارهای اشیا بسیار کمتر از نمودارهای کلاس استفاده می شوند. در واقع در اینجا به سطح پیاده سازی نرم افزار نزول می کنیم. استفاده از آنها زمانی مفید است که یک نمایش گرافیکی به جلب توجه شرکت کنندگان در توسعه به آن دسته از ویژگی های پیاده سازی که تشخیص آنها از متن برنامه دشوار است کمک کند.

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

مثال 1: روابط بازگشتی

در اینجا ما سلسله مراتبی از کلاس ها را که بخش های دانشگاه را توصیف می کنند، فرض می کنیم.

مثال 2: پیوندهای استاتیک ارثی.

mathStat، math، statistics، applicationMath، mathEd – اشیاء، ارجاع به کلاس دپارتمان

احتمالاً یک مثال پیچیده تر و مهم تر، شرح احتمالات نه همیشه آشکار تغییر در یک برنامه عضویت یک شی در کلاس های مختلف - در مورد سلسله مراتب وراثت است.

نمودارهای مؤلفه و نمودارهای استقرار -

نمودارهای اجزا و استقرار

جزء[معماری سیستم نرم افزار] - یک ماژول، بخشی از [متن] یک برنامه، که به طور سنتی با اتوماسیون، پردازش الگوریتمی کد برنامه (برنامه ها به عنوان داده) مرتبط است. هنگام استفاده از UML، آنها به عنوان آنالوگ های فیزیکی نمودارهای کلاس در نظر گرفته می شوند و به روشی مشابه توصیف می شوند. به عبارت دیگر، نمودارهای مؤلفه یک آنالوگ رسمی از نمودارهای کلاس هستند که برای توصیف معماری نرم افزار و ساختار یک سیستم نرم افزاری در نظر گرفته شده است.

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

در برنامه نویسی کامپوننت، مفهوم کامپوننت از این هم فراتر می رود و تعریف واضح تری دارد. به سادگی - یک رابط نامگذاری شده، اما [هنوز] پیاده سازی نشده است. پس از تولد در محیطی با مشکلات صرفاً سیستمی (به ویژه در اینجا مهم است که مشکل پشتیبانی نسخه را به خاطر بسپارید)، در اینجا به یک ابزار راه حل تبدیل می شود. هروظایف (با افزایش پیچیدگی).

نمودارهای استقراردر درجه اول برای توصیف در نظر گرفته شده است پیکربندی فیزیکی(معماری) نرم افزار و سخت افزار. بنابراین، مثال زیر روابط بین نرم افزار و اجزای سخت افزاری یک سیستم نرم افزاری پردازش معاملات املاک و مستغلات را نشان می دهد.

مثال. محیط فیزیکی برای حمایت از فروش املاک و مستغلات.

در اینجا سرور املاک و سرور بانک سرورهای یک آژانس املاک و یک بانک رهنی هستند که در پاسخ به درخواست مشتری (مشتری) خود وام می دهند. PC یک کامپیوتر مشتری است که به کاربر سیستم نرم افزاری که ما در حال توسعه آن هستیم این امکان را می دهد تا مطابق با لیست پیشنهادات موجود در پایگاه داده خود، درخواست هایی را به بانک و آژانس ارائه دهد.

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

درک مفهومی این اصطلاح شفاف است. مشتری نمی تواند ساختار داخلی پیچیده سیستم ها را بداند (اگرچه باید بداند که پیچیده است و بنابراین از کار توسعه دهندگان قدردانی می کند). بیشتر از این. او یک متخصص بسیار ماهر نیست نبایددر عملکرد آنها تداخل ایجاد کند - حتی اگر دلیلی برای این وجود داشته باشد توانایی فیزیکی. این یک تعریف غیر مستقیم از مرزهای اخلاقی، یک مشتری صادق و به سادگی - فرد با فرهنگ. نه هکر

با این حال، برای عملکرد عادی کل سیستم، او حق دسترسی به رابط را دارد - شرحی که به احتمال زیاد او فقط در قالب یک کتابچه راهنمای کاربر در آن می داند. غیر رسمیمتن یا فرم گرافیکی، یعنی. در معمولیزبان انسان به عبارت ساده، کسی هنوز باید اصول اولیه را برای او توضیح دهد - "چه، چگونه و چرا".

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

اما من نمی خواهم بررسی خود را از UML با این به پایان برسانم، بلکه با یک درخواست برای خواننده.

1. مفهوم سازی سیستم:ایده پشت برنامه یک بازی توسعه حافظه است.

2. مدل تحلیلییک نمایش دقیق و واضح از مشکل است که به شما امکان می دهد به سؤالات پاسخ دهید و راه حل بسازید.

3. مدل طراحیاجرای راه حل هایی برای مشکلات درک شده در مرحله تجزیه و تحلیل است.

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

پیچیدگی.بازی باید از گزینه های سختی استاندارد (مثلا آسان، متوسط، سخت) پشتیبانی کند. کاربر باید بتواند سختی بازی خود را سفارشی کند.

سطوح.صرف نظر از نوع دشواری، بازی باید از سطوح پشتیبانی کند. سطح حداکثر تعداد ارقام روی صفحه را تعیین می کند. آن ها تعداد ارقام تابعی از سطح است.

نکات.اگر انتخاب یک شکل دشوار است، بازیکن می تواند یک اشاره را انتخاب کند.

پایگاه داده.در صورت امکان، اطلاعات بازیکن باید در سیستم ذخیره شود.

الزامات اضافیهمه چیز باید انجام شود تا بازی مقیاس پذیر باشد، یعنی. کاربر می تواند گزینه های سختی مختلف را به بازی خود متصل کند.

ما از یک رویکرد تکراری برای توسعه برنامه استفاده خواهیم کرد. در اولین تکرار، ما تنها بخش کوچکی از الزامات را اجرا خواهیم کرد، زیرا این اولین بازخورد را ارائه می دهد.

مدل موارد استفاده، سوابق

بیایید سوابق را در نظر بگیریم بازیو تنظیم سختی

مصنوعات اصلی در مدل‌سازی موارد استفاده، نمودارهای مورد استفاده، موارد استفاده و نمودارهای توالی مورد استفاده هستند. بسیاری از تازه واردان OOA/P از مدل‌سازی موردی استفاده می‌کنند فقط بر روی نمودارهای مورد استفاده تمرکز می‌کنند که ذاتاً چندان مفید نیست. درک این نکته مهم است که نمودارها فقط نشان می دهند نام ها، نام ها سوابقو نه خود سوابق.

شکل 1. نمودار مورد استفاده

این را به شما یادآوری کنیم سابقهداستانی در مورد استفاده از یک سیستم توسط یک بازیگر است که بعداً می تواند برای وضوح بیشتر در نمودارهای توالی مورد استفاده پیش بینی شود.

شناسایی بازیگرانتنها فرد فعال بازیکن است. بازیکن بخشی از سیستم نیست، زیرا سیستم نمی تواند اعمال او را کنترل کند، ما فقط می توانیم توالی خاصی از اقدامات را از بازیکن انتظار داشته باشیم.

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

شناسایی رویدادهای پایانیرویدادهای پایانی نیز باید تعریف شوند. برای سختی تنظیمات قبلی، این تنظیم پارامترهای سختی بازی است، همه چیز در اینجا واضح است. برای سابقه بازیوضعیت متفاوت است: مورد استفاده بازیمی تواند تا زمانی که بازی برنده یا باخت ادامه یابد. رویداد نهایی Game precedent رویدادی خواهد بود که بازیکن از این سرویس خسته شود، یعنی. از بازی خارج شوید

توصیه های اولیه: فقط تراکنش های کاملی که برای کاربر سیستم معنا پیدا می کند باید به عنوان سابقه انتخاب شوند. اگرچه روش شناسان پیشرو قبلاً سبکی از پیشینه نوشتن را تعریف کرده اند، این بدان معنا نیست که ما باید به شدت از آن پیروی کنیم (یا صرفاً به دلیل اختلاف نظر از آن پیروی نکنیم). فراموش نکنیم که سوابق به سؤال «چی» پاسخ می دهند و نه به سؤال «چگونه»، یعنی. نیازی به توضیح در سابقه نیست که چگونه این یا آن نتیجه حاصل می شود.

سابقه بازی.

سابقه تنظیم سختی

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

در حال حاضر ما طراحی خواهیم کرداستفاده از موارد در نمودارهای توالی مورد استفاده. اگرچه چنین مفهومی در UML وجود ندارد، اما به ما این امکان را می دهد که پیوند منطقی خاصی را در استدلال برای ساخت مدل ها بازسازی کنیم.

شکل 2. از نمودار توالی مورد استفاده کنید بازی

شکل 3. از نمودار توالی مورد استفاده کنید تنظیم دشواری

تجزیه و تحلیل برنامه

نیازی به تجزیه و تحلیل دامنه نیست، زیرا برنامه در دنیای واقعی آنالوگ ندارد. بیایید برنامه را تجزیه و تحلیل کنیم: ما جنبه هایی از برنامه نرم افزاری را که برای کاربر قابل مشاهده است برجسته می کنیم و دیدگاه او را منعکس می کنیم. اما تجزیه و تحلیل حوزه موضوعی را می توان طبق یک طرح مشابه انجام داد.

مدل کلاس کاربردی

یکی از مصنوعات تحلیل برنامه، نمودارهای کلاسی است. برنامه های کاربردیاین به این معنی است که در مدل‌ها توصیه نمی‌شود که کلاس‌هایی را که به سطح پیاده‌سازی تعلق دارند (لیست‌ها، درخت‌ها و غیره انواع داده‌های انتزاعی) نمایش دهید.

کلاس هاما سوابق را به عنوان منبع کلاس های بالقوه برجسته خواهیم کرد، اما این تنها منبع نیست. به طور معمول کلاس ها با اسم ها مطابقت دارند. به عنوان مثال، از جمله - سیستم (صفحه نمایش) شکل را نشان می دهد،کلاس های بالقوه را می توان انتخاب کرد سیستم(صفحه نمایش)، شکل

مشکل: یک قسمت از گفتار ممکن است به آرامی در قسمت دیگر جریان یابد. برای مدت طولانی در مورد سوال عذاب نکشید همبستگی کلمات کلیدی با لیستی از کلاس های بالقوهمدل‌های کلاس به مرور زمان اصلاح می‌شوند و اغلب ساختن یک مدل کاملاً صحیح بلافاصله غیرممکن است. اگرچه این بدان معنا نیست که این یک فعالیت بی فایده است.

بیایید کلاس های بالقوه را برای مثال خود انتخاب کنیم: بازیکن، بازی، شکل، دشواری، سطح، بیضی، مستطیل.

نظر:به طور کلی، برای هر مورد استفاده معمولاً باید مدل کلاس خود را بسازید. اما از آنجایی که برنامه کوچک است، ما یک مدل کلاس واحد برای هر دو مورد استفاده خواهیم ساخت.

خواص.بیایید ویژگی های کلاس ها را تعریف کنیم. خواص مفاهیمی هستند که هویت خاص خود را ندارند. در این مورد، برای مثال، رنگ شکل (اما اگر ما یک ویرایشگر گرافیکی بسازیم، رنگ به احتمال زیاد چنین فردی خواهد داشت). چنین ویژگی هایی را می توان در لیست کلاس های بالقوه یافت.

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

نظر دهید: اگر در حال ساخت یک مدل برنامه یا دامنه هستید، نباید شناسه داخلی را نیز به عنوان ویژگی تعیین کنید. این نوع ویژگی در دنیای واقعی معنایی ندارد، بلکه فقط برای پیاده سازی راحتی به ارمغان می آورد.

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

به عنوان مثال، یک بازی با سختی آن تعریف می شود.

شکل 4. نمودار کلاس کاربرد

دو ارتباط در نمودار وجود دارد - بازی با سختی تعیین می شود, رقم با پیچیدگی تعیین می شود.

شناخت الگوی طراحی صحافی کم، من یک اشتباه احتمالی می بینم که یکی از این انجمن ها اضافی است، اما کدام یک را در مرحله طراحی تصمیم خواهم گرفت.

عملیات.هنگام مدل سازی کلاس ها، می توانید بلافاصله واضح ترین عملیات را شناسایی کنید. برای مثال می توان یک شکل ترسیم کرد.

توصیه: به طور کلی، نمودار کلاس به موازات نمودار تعامل ساخته شده است. پیام یک فراخوانی به یک تابع کلاس است. بنابراین بهتر است عملیات کلاس را از نمودارهای تعاملی بگیریم.

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

شکل 5. نمودار کلاس کاربرد با خلاصه

نظر:شاید این تعمیم نقطه ای برای گسترش بیشتر انواع ارقام نمایش داده شده بر روی صفحه ارائه دهد.

خلاصه: مدل‌های کلاس برای چیزی بیش از تعریف ساختارهای داده مفید هستند. ردیابی مدل های کلاس به شما امکان می دهد انواع خاصی از رفتار را بیان کنید، به عنوان مثال. سوابق

مدل حالت برنامه

یکی دیگر از مصنوعات مرحله تحلیل برنامه، نمودارهای حالت است. نمودارهای حالت برای اشیاء دامنه ای که رفتار غیر ضروری، از جمله چرخه ای، دارند، مورد نیاز است. اکثر کلاس ها در مورد ما نیازی به استفاده از نمودارهای حالت ندارند. به عنوان مثال، این کلاس Figure است - برای این برنامه مهم نیست که شکل در چه وضعیتی است.

اجازه دهید کلاس هایی را که حالت های متفاوتی دارند شناسایی کنیم. مثلاً این کلاس است بازی. این کلاس می تواند در ایالت ها باشد بازی ها، پیروزی هاو غیره

بیایید حالت های طبقاتی را برجسته کنیم بازی ها. برای انجام این کار، بیایید به صورت ذهنی یک شی از کلاس را تصور کنیم بازی،تلاش برای درک تفاوت های این شی در حالت ها بازی، برد، باخت. در حالت Game، جسم یک شکل را ترسیم می کند، اما در حالت های دیگر این کار را نمی کند. به عبارت دیگر، ارتباط بین طبقات بازیو شکلحاضر در یک حالت بازی، و در ایالات پیروزیو از دست دادناین انجمن وجود ندارد (بنابراین ایالات پیروزیو از دست دادنبرای من قابل تشخیص نیست).

با توجه به مقیاس کوچک مثال، ممکن است به نظر برسد که این مدل ها ضروری نیستند. در عمل، در این مورد، می توان آنها را به پیاده سازی نرم افزار نسبت داد، اما در اینجا تمایل به ارائه نمونه ای از مدل سازی نمودار حالت وجود دارد.

انتخاب رویداد. پس از انتخاب حالت ها، لازم است رویدادهایی که باعث انتقال بین حالت ها می شوند انتخاب شوند.

· رویداد سیگنال رویداد دریافت یا ارسال سیگنال است.

· رویداد تغییر رویدادی است که در اثر اجرای یک عبارت بولی ایجاد می شود.

· رویداد زمانی رویدادی است که در اثر دستیابی به یک لحظه از زمان مطلق یا انقضای یک بازه زمانی ایجاد می شود.

رویداد را تغییر دهید رعایت شرایط بازییک شی کلاس را ترجمه می کند بازیاز ایالت بازی هادر یک ایالت پیروزی. رویداد را تغییر دهید عدم رعایت شرایط بازییک شی کلاس را ترجمه می کند بازیاز ایالت بازی هادر یک ایالت از دست دادن. بنابراین، رویدادهای مختلف جسم را به حالت های مختلف می آورند.

رویدادها نقاطی در یک خط زمانی هستند و حالت ها فواصل هستند.

شکل 6. نمودار حالت برای یک کلاس بازی

رویدادها می توانند در داخل ایالت ها نیز رخ دهند، اما این رویدادها باعث انتقال بین حالت ها نمی شوند. به عنوان مثال در حالت Game وقایع ترسیم فیگورها و اتفاقات بازیکنی که یک فیگور را انتخاب می کند رخ می دهد.

نمودار حالت یک جسم یک خودکار (گراف) است که رئوس آن حالت ها و یال ها رویدادها هستند.

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

طراحی اپلیکیشن

طراحی سیستم انتخاب یک استراتژی سطح بالا برای حل مشکلات است.

مدل تعامل برنامه

بیایید به سوابق برگردیم، زیرا مدل های تعاملی بر اساس مدل های پیشین ساخته شده اند. نمودارهای دنباله‌ای مصنوع از پیشینه‌ها به سؤال «چی» پاسخ دادند، در این بخش نمودارهای دنباله‌ای را می‌سازیم که به سؤال «چگونه» در هنگام حل مسائل مورد استفاده بازی پاسخ می‌دهند.

بیایید به سناریوی Game use case بپردازیم، که پس از رویداد راه‌اندازی این سرویس توسط Player، مقداردهی اولیه می‌شود.

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

ایجاد یک شکل شامل دنباله ای از اقدامات است: تعیین تصادفی پارامترهای شکل آینده و ایجاد شکل با توجه به پارامترها.

تعیین مقادیر ویژگی های شکل آینده. از آنجایی که یک شکل با ویژگی ها (نوع، رنگ، موقعیت) تعیین می شود و مقادیر ویژگی ها باید تصادفی باشد، کلاسی مورد نیاز است که مسئول تشکیل تصادفی مقادیر ویژگی ها باشد - یک کلاس. الگوریتم. مقادیر مشخصه به سختی بازی بستگی دارد. به عبارت دیگر، در اینجا متوجه کلاس binding می شویم الگوریتمو پیچیدگی- یعنی مقادیر ویژگی تابعی از مشکلات.بنابراین پیچیدگیبه کلاس منتقل شد الگوریتمبه عنوان یک پارامتر یعنی پیچیدگیهنگام شروع بازی باید به عنوان پارامتر ارسال شود.

ایجاد یک شکل. پارامترهای شکل آینده تعریف شده است، اما کدام کلاس مسئول ایجاد شکل خواهد بود؟ در اینجا الگوی طراحی Creator را اعمال می کنیم که طبق آن کلاسی که اطلاعات بیشتری در مورد شیء دارد ایجاد می شود، این کلاس Algorithm است. کلاس Algorithm موقعیت قطعه جدید را به کلاس Game برمی گرداند. پس از ایجاد شکل، کلاس منتظر می ماند تا کاربر یک شکل را انتخاب کند.

انتخاب یک شکل کلاس Game controller این رویداد را مدیریت خواهد کرد. خود کلاس کنترل کننده صحت انتخاب شکل بازیکن را بررسی می کند، زیرا تمام اطلاعات مربوط به آن را دارد. اگر بازیکن انتخاب درستی داشته باشد، سیستم دوباره یک رقم جدید ترسیم می کند، در غیر این صورت بازی به حالت باخت می رود.

شکل 7. از نمودار توالی مورد استفاده کنید بازی

خلاصه: همه نمی توانند با من در مورد رویکردی که در اینجا برای تجزیه و تحلیل و طراحی این سیستم خاص اتخاذ شده است موافق باشند. به طور کلی، منعکس کننده یک دیدگاه نسبتاً ذهنی از چیزها است.

پس واژه برای هکرها. منبع اصلی

البته همه آنچه در بالا گفته شد 100% واضح و 100% برای شما مفید نبود - به معنای آمادگی 100% فردا شروع به توسعه سیستم های نرم افزاری پیچیده با قابلیت اطمینان 100٪ کنید . به نظر می رسد که سیستم هایی که امروزه بسیار مرتبط هستند، 100٪ از اطلاعات محافظت می کنند "در برابر هکرهای شیطانی که در جایی پنهان شده اند." من معتقد نیستم که تضمین های 100٪ در اینجا امکان پذیر است - یا اصلاً ضروری است. در هر صورت، این کتابچه راهنمای ساده، اهداف دست نیافتنی برای خود تعیین نکرد. فقط همین است دستورالعمل برای یک کاربر (مشتری) هنوز واجد شرایط زبان UML. نوشته شده، تا آنجا که ممکن است، "به شیوه ای انسانی".

هیچ کس کامل نیست - نه شما، "مشتری آموزش"، و نه من، "سرور" شما. شما به اندازه کافی مطالعه نکردید یا من به اندازه کافی مطالعه نکردم، اکنون برای جستجوی مقصران بسیار دیر شده است. در اینجا ما فقط اولین تکرار را در فرآیند آماده سازی انجام دادیم. البته، برای برنامه نویسی به اندازه کافی قابل اعتماد سیستم های پیچیده، شما هنوز باید عمیق تر بروید، تخصص داشته باشید، و بدانید و بتوانید کارهای بسیار بیشتری انجام دهید. این واضح است. اما این راهنما در مورد چیز دیگری است. در اینجا من نمی خواستم یک قدم به جلو بردارم، اما عقب نشینی کن- برای اینکه به شما نشان دهم که ابتدا باید بتوانید دوباره درک کنید قبلا گذشت. اغلب - سوء تفاهم، گذشت توسط

هکر یک جنایتکار شیطانی نیست. حداقل در ابتدا. برعکس، به یک علاقه‌مند به برنامه‌نویسی، هکر نیز گفته می‌شود. سپس هکرها من و شما هستیم. خوب، بدون علاقه به کار، زندگی خسته کننده است. ما هنوز آدم هستیم نه ربات. همه افراد کامل نیستند، همه فردی هستند.

اما در ابتدا همه ما متعهد می شویم که 1) همه چیز را 2) یکباره 3) به طور کامل انجام دهیم. و این طبیعی است - تا زمانی که تأثیر زیادی بر دیگران، نزدیک و دور نداشته باشد. لحظه حقیقت زمانی فرا می رسد که سناریوی ایده آل ما به شکست ختم می شود. سپس برخی شروع به یادگیری جدی کار می کنند و آنهایی که خونسردتر هستند شروع به جستجوی مقصران می کنند. "آنها به اندازه کافی آموزش ندادند، آنها آن را به روش صحیح آموزش ندادند" - به طور کلی، آنها منابع کافی را فراهم نکردند. عزیزم خودت خیلی سرمایه گذاری کردی؟ آیا در پشت ایمان تزلزل ناپذیر شما به قدرت بی حد و حصر شهود خود، امید به شانس و ... تنبلی معمولی، عدم تمایل به کار پنهان نیست؟

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

نکته اینجا خود پول، قراردادها و سایر مصنوعات نیست. اینها فقط نمادهای یک قرارداد اجتماعی، نشانه های اعتماد و توافق بین مردم هستند. شما فقط باید چیزهایی را برای آینده ثبت کنید تا گذشته را فراموش نکنید. منبع اصلی، منبع روابط انسانی است. اگر آن را ضرب نکنید، واقعاً - چه کسی به این همه ریاضیات نیاز دارد؟ این یک معامله است - موافقت کردید؟

امیدوارم الان بهتر بفهمی من دقیقا روی چه چیزی و چه کسی حساب می کردم. اینم ریاضی...

مراجع

1. Grady Booch، James Rambo، Ivar Jacobson - UML Language. راهنمای کاربر. انتشارات DMK Press, 2007, 496 p. کلاسیک از سازندگان UML.

2. کریگ لارمن - استفاده از UML 2.0 و الگوهای طراحی. انتشارات ویلیامز، 2008، 736 ص. منعکس کننده رویکرد مهندسی غالب به OO AP امروز است.

3. J. Rambo، M. Blaha - UML 2.O. مدل سازی و توسعه شی گرا. ویرایش دوم - سن پترزبورگ: پیتر، 2007. - 544 ص. همان چیز، با کمی پیچش عملی تر.

4. Rational University - مواد برنامه آکادمیک شرکت IBM (به http://www.ibm.com/ru/software/info/students/ مراجعه کنید): ملزومات مدل‌سازی بصری، مبانی گل رز منطقی. گنجینه ای از نمونه ها، آزمایش ها و آزمایشگاه ها.

در ادامه مطلب

1. مارتین فاولر. UML. مبانی.انتشارات سمبل پلاس، 1385، 192 ص. مرجع سریع

2. دانشگاه عقلی- مواد برنامه آکادمیک شرکت IBM (به http://www.ibm.com/ru/software/info/students/ مراجعه کنید): تسلط بر تحلیل و طراحی شی گرا، مدیریت مدیریت توسعه تکراری و موارد دیگر.

3. برتراند مایر. طراحی شی گرایی سیستم های نرم افزاری. انتشارات چاپ روسی 2005، 1204 ص. نمای کلاسیک تری از وضعیت مدرن را منعکس می کند. نیاز به آمادگی ریاضی خوبی دارد.

ادبیات اضافی - برای معلمان.

اف. نوویکوف. شرح کار عملی دانشجویان (LP) در رشته "تحلیل و طراحی در UML" - گروه "فناوری های برنامه ریزی"، دانشگاه ایالتی سنت پترزبورگ فناوری اطلاعات، مکانیک و اپتیک، سن پترزبورگ، 2007

در بالا، نویسنده بر روی فردیآماده سازی اما تنها راه قابل اعتماد برای آزمایش عملی درک مفاهیم فوق از OO AP - به ویژه "معیار 36.6" - جمعی است، توسعه تیم. توسعه روش شناختی F. Novikov شروع خوبی در اینجا می دهد - در قالب طرحی برای انجام کارهای آزمایشگاهی مربوطه. اگرچه نویسنده شخصاً کارهایی با ماهیت بازیگوش را برای اجرای آنها توصیه می کند که تظاهر به جدی بودن ندارند. به عنوان مثال - شطرنج، چکرز، و دیگر بازی های تخته.

با این حال، ارزش دوباره خواندن را دارد رومئو و ژولیت، برای درک اینکه معنای واقعی نقل قول به خود گل رز اشاره نمی کند. حتی - منطقی یا مجازی. موضوع اصلی تراژدی در همان ابتدا ذکر شده است: دو خانواده به همان اندازه محترم در ورونا، جایی که رویدادها با ما ملاقات می کنند...

دانشجویان این دوره به محصولات نرم افزاری دارای مجوز از IBM و Microsoft دسترسی دارند - برای انجام این کار، فقط با معلم دوره (نویسنده این راهنما) تماس بگیرید.

در محدوده تعریف شده توسط یک جوک محبوب. معلم به معلم: "خب، دانش آموزان احمق بودند. توضیح دادم و توضیح دادم - من قبلاً همه چیز را فهمیده بودم، اما آنها هنوز هم نمی فهمیدند!

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

با توجه به برنامه درسی: (- اما به پس کلمه ج

اصطلاحات روسی زبان مربوط به مشکلات مورد بررسی هنوز به طور کامل ایجاد نشده است. در صورت اشکال در ترجمه، نویسنده برای جلوگیری از درک مبهم، از «کاغذ ردیابی» استفاده می کند. ترجمه نادرست واقعیت های دیگران به واقعیت های خود باعث ایجاد مشکلات بسیار دشواری می شود.

همکاری - همکاری. در روسی کلمه همکارمعنای منفی دارد، به همین دلیل است که اغلب در مورد نمودارهای همکاری صحبت می کنند.

نویسنده فصل آناستازیا سابیرزیانوا است. من فقط تغییرات سبکی جزئی ایجاد کردم - زیرا سبک زنده و صادقانه او را در ارائه روند توسعه دوست دارم. واضح است که اگر می خواست، می توانست دروغ بگوید... از این گذشته، آناستازیا از دانشکده ریاضیات محاسباتی و علوم کامپیوتر در KSU فارغ التحصیل شد و در حال حاضر تجربه بسیار زیادی در توسعه عملی برنامه های تجاری دارد. با این حال، احتمالاً به همین دلیل است که نتوانستم ... N.B.

آنچه درست است در نظر گرفتن نیاز به تلقی سایر اجزای گفتار به عنوان اسم در چنین مواردی است. اجازه دهید مثال "Authorization" را به یاد بیاوریم که در آن عملیات را تفسیر می کنیم اجازه دهدبه عنوان یک فرآیند N.B.

کلمات کلیدی: معنی واژه نامه- فهرست فشرده ای از اصطلاحات اساسی که حوزه موضوعی را توصیف می کند. در مورد بقیه، نظر آناستازیا به خوبی با مفهوم OO AP مطابقت دارد. یک مدل نه تنها و نه چندان نتیجه نهایی توسعه است. این نتیجه کنونی درک مشکلات مرتبط با آن است. از این رو ضرورت و سودمندی آزمون هاست. N.B.

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

ما در این راهنما به مفهوم بسیار مفید آن اشاره نکردیم الگوی طراحی(علاوه بر این، صادقانه بگویم، من چنین قالبی را به خاطر ندارم). در حال حاضر - قبل از اینکه او را از طریق ادبیات بشناسید (به عنوان مثال مراجعه کنید)، خواننده اینجا و بیشتر می تواند او را اینگونه بخواند: توسعه دهندگان پیشرو با تجربه گسترده توصیه می کنند کلاس زیر را در این شرایط ایجاد کنید. N.B.

در موارد ساده. به طور کلی، پیام اشاره می کنددر هر تماس، و نسبت پیام ها و عملیات باید به طور خاص مشخص شود. N.B.

و همچنین تمایل به جلوگیری از خطاهای احتمالی در مراحل اولیه. N.B.

تصادفی نیست که در بالا به آن اشاره کردم موضوعاتاقدامات اساسا، من با آناستازیا در درک او از ماهیت رویکرد، که قبلا و در مقدمه مثال بیان شد، موافقم. همه توسعه دهندگان سوژه یا به سادگی افراد هستند. نه خدایان، اما نه روبات ها. و هر فرد بسته به صلاحیت های نظری، تجربه عملی و بسیاری موارد دیگر که برای درک مسائل بسیار مفید است، اما راه حل ها را به وضوح از پیش تعیین نمی کند، رویکرد شخصی خود را برای حل مشکلات دارد. زندگی پیچیده است - زبان ها ساده هستند.

بیماری های برنامه نویسی مدرن، که UML در تلاش برای درمان آن است، برعکس می آید. بدون درک مشکلات، اغلب از قبل مطمئن هستیم که راه حل منحصر به فرد است. هر کدام مال خودشان است. به همین دلیل است که درجه حرارت "به طور متوسط ​​در بیمارستان" اغلب از 36.6 نرمال بالاتر می رود - N.B.