Размещено на http://www.allbest.ru/

ЗМІСТ

• ВВЕДЕННЯ
• 1. ЗМІСТОВИЙ ОГЛЯД ПРЕДМЕТНОЇ ОБЛАСТІ. ОСНОВНІ ВИМОГИ ДО СИСТЕМИ
• 2. УНІФІКОВАНА МОВА МОДЕЛЮВАННЯ UML
• 3. РОЗРОБКА МОДЕЛІ ПРОГРАМНОЇ СИСТЕМИ ЗАСОБАМИ UML
• 3.1 Розробка виду з погляду прецедентів
• 3.2 Розробка виду з погляду проектування
• 3.3 Розробка виду з погляду реалізації
• ВИСНОВОК
• СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

ВВЕДЕННЯ

Використання інформаційних технологій в індустрії розваг спрямовано на створення повноцінних додатків. Перед тим, як розпочати створення гри, зазвичай складають план розробки. В першу чергу визначається бізнес-логіка - для кого створюється гра та на який прошарок населення вона спрямована. Далі відбувається проектування архітектури гри, визначаються її параметри та функції. Потім наступає етап реалізації, тобто безпосередньо кодування та створення дизайну гри. Останнім етапом є тестування. Дана розробка буде виконуватися в стилі RPG (Role Playing Game) - покрокової рольової гри. Цей термін означає, що гравці в тому чи іншому ступені асоціює себе з персонажем.

Для моделювання й аналізу програмного забезпечення використовують: Rational Rose, AllFusion ERwin Data Modeler, ARIS та інші.

IBM Rational Rose Enterprise надає набір функцій, керованих моделлю, для розробки цілого ряду додатків, у тому числі на мовах Ada, ANSI C ++, C ++, CORBA, Java, Java EE, Visual C ++ і Visual Basic. Це програмне забезпечення дозволяє прискорити розробку таких додатків завдяки створенню коду на основі візуальних моделей з використанням UML (Unified Modeling Language).

Rational Rose Enterprise пропонує загальний інструмент моделювання і мова для спрощення робочого середовища і можливості більш швидкого створення якісного програмного забезпечення.

Моделювання найпоширеніших додатків - надає функції візуального моделювання для розробки додатків багатьох типів.

Розробка веб-додатків - пропонує інструменти XML і веб-моделювання веб-додатків. програмний рольовий гра

Інтеграція проектування і розробки додатків - уніфікує роботу колектив проекту шляхом надання спільних коштів виконання і нотації моделі UML.

ARIS (акронім від англ. Architecture of Integrated Information Systems) - методологія і тиражований програмний продукт для моделювання бізнес-процесів організацій. Продукт і методологія належать німецькій компанії Software AG як результат поглинання компанії IDS Scheer учасника методології Августа-Вільгельма Шеера.

Будь-яка організація в методології ARIS розглядається з двох точок зору: організаційної, функціональної, оброблюваних даних, структури бізнес-процесів, продуктів і послуг. При цьому кожна з цих точок зору розділяється ще на три підрівні: опис вимог, опис специфікації, опис впровадження. Для опису бізнес-процесів пропонується використовувати близько 80 типів моделей, кожна з яких належить тому чи іншого аспекту. ARIS надає візуальний інструментарій для забезпечення наочності моделей. Також інструментарій поставляється з набором референтних моделей, заздалегідь розроблених для типових процесів в різних галузях. Загальний принцип в інструментарії - можливість інтеграції моделей різних типів у рамках одного репозиторію допомогою декомпозиції (деталізації) об'єктів. Таким чином, будь-яку організацію можна описати за допомогою ієрархії моделей - від узагальнення: наприклад, процеси верхнього рівня за допомогою моделі VAСD (англ. Value added chain diagram) до рівня процедур та ресурсного оточення функцій.

Серед великої кількості можливих методів опису можна виділити наступні:

· eEPC (англ. extended event-driven process chain) - метод опису процесів;

· ERM (англ. Entity-relationship model) - модель «сутність-зв'язок» для опису структури даних;

· UML (англ. Unified modeling language) - уніфікований об'єктно-орієнтована мова моделювання.

Крім того, в ARIS передбачена можливість створення сценаріїв автоматизації складання різних аналітичних звітів, нормативних документів, нових моделей. Кожен сценарій являє собою підпрограму, запускаемую в ARIS Business Architect (або Toolset - більш ранньої версії) або безпосередньо на сервері ARIS. Сценарії пишуться на спеціальному мові програмування - SAX Basic. Для автоматизованого формування того чи іншого звіту в ARIS сценарії оперують даними з бази моделей, виокремлюючи з неї конкретні об'єкти і моделі.

Технологія ARIS Script дозволяє в автоматичному режимі проводити:

· Формування нормативних документів на підставі моделей ARIS (наприклад, паспорт процесу, регламент процесу).

· Формування аналітичних звітів на підставі моделей ARIS.

· Інтеграцію ARIS Toolset з іншими додатками і базами даних.

· Формування бази моделей ARIS на підставі готових специфікацій.

Продукт ARIS використовується в різних проектах з реінжинирингу та оптимізації бізнес-процесів, ІТ-проектах типу впровадження та експлуатації ERP-систем, зокрема, є пророблена інтеграційне рішення для SAP R / 3. Також програмне забезпечення ARIS складає основу пакету Business Process Analysis Suite корпорації Oracle. Технічно інструментарій ARIS досить простий для вивчення, має інтуїтивно зрозумілий інтерфейс. Моделі легко копіюються і вставляються у файли документів (наприклад, формату doc) у вигляді малюнків. При цьому інструмент володіє обширним функціоналом: від опису до стратегічного планування.

AllFusion ERwin Data Modeler (раніше ERwin) - CASE-засіб для проектування та документування баз даних, яке дозволяє створювати, документувати і супроводжувати бази даних, сховища і вітрини даних. Моделі даних допомагають візуалізувати структуру даних, забезпечуючи ефективний процес організації, управління та адміністрування таких аспектів діяльності підприємства, як рівень складності даних, технологій баз даних та середовища розгортання.

AllFusion ERwin Data Modeler (ERwin) призначений для всіх компаній, що розробляють і використовують бази даних, для адміністраторів баз даних, системних аналітиків, проектувальників баз даних, розробників, керівників проектів. AllFusion ERwin Data Modeler дозволяє управляти даними в процесі корпоративних змін, а також в умовах стрімко змінюються технологій.

AllFusion ERwin Data Modeler (ERwin) дозволяє наочно відображати складні структури даних. Зручна у використанні графічна середу AllFusion ERwin Data Modeler спрощує розробку бази даних і автоматизує безліч трудомістких завдань, зменшуючи терміни створення високоякісних і високопродуктивних транзакційних баз даних і сховищ даних. Дане рішення покращує комунікацію організації, забезпечуючи спільну роботу адміністраторів і розробників баз даних, багаторазове використання моделі, а також наочне уявлення комплексних активів даних в зручному для розуміння та обслуговування.

Програми ERwin, BPwin і ERwin були розроблені компанією Logic Works. Назва BPwin склалося зі скорочення BP (англ. Business process) і суфікса win, отражавшего орієнтацію на графічні операційні системи.

У 1998 році компанія Logic Works була поглинена фірмою Platinum Technology. Та у свою чергу, всього через рік, в 1999 році була куплена Computer Associates.

1. ЗМІСТОВИЙ ОГЛЯД ПРЕДМЕТНОЇ ОБЛАСТІ. ОСНОВНІ ВИМОГИ ДО СИСТЕМИ

Комп'ютери вже досить давно увійшли в наше життя. Вони змінили світ і можливості людини. Неможливо уявити своє життя без комп'ютера, він істотно полегшив життя людини. За допомогою комп'ютера для учнів школи і студентів немає нічого простішого ніж «написати» реферат, курсову, дипломну роботу, або знайти потрібну інформацію в інтернеті. У роботі бухгалтера комп'ютер є, без сумніву, основним робочим інструментом.

Особливості індустрії комп'ютерних ігор багато в чому схожі з іншими відгалуженнями індустрії розваг (наприклад, музична індустрія), проте ігрову індустрію часто засуджують за малі винагороди розробників. Це сприяє існуванню незалежних розробок, які починаються після того як розробники залишають свої старі компанії і засновують власні нові компанії і проекти. У найбільш значних випадках такі компанії поступово розвиваються в величезні безликі корпорації, які беруть правила ведення бізнесу своїх попередників, підтримуючи таким чином згаданий цикл.

На відміну від сучасної музичної індустрії, для якої розвиток технологій знизило вартість створення контенту практично до нуля, завдяки чому будь-який незалежний музикант може самостійно створити продукт практично професійної якості, для створення сучасної комп'ютерної гри потрібно все більше число як залучених до створення працівників, так і все більш потужне обладнання. Ця обставина робить ігрових видавців, які фінансують створення ігор, істотно більш впливовими, ніж видавці в музичній індустрії.

Доходи ринку відеоігор в найближчі роки можуть зрівнятися з доходами спортивної індустрії. Аудиторія мобільних ігор росте стрімкими темпами, а в світі кіберспорту зростає число професійних тренерів, світових турнірів з мільйонними призовими фондами і навіть допінгових скандалів і договірних матчів.

На даний момент Україна входити в топ-50 країн за прибутковістю індустрії комп'ютерних ігор. Згідно з підрахунками аналітиків, в Україні сумарний дохід від ігор в 2014 році склав $ 118,6 млн, випередивши такі країни як Ізраїль і Сінгапур.

Зараз розроблено безліч різноманітних комп'ютерних ігор, а їх творці випускають у світ все нові. Так як створення комп'ютерних ігор ставиться до підтримки сфери розваг, то їх класифікація не так проста, як може здатися на перший погляд. Жанри ігор формувалися без структурно і інтуїтивно протягом тривалого часу. Розробники ігор проводили сміливі експерименти, створюючи нові ігрові механіки. Невдалі експерименти забувалися, а вдалі ігри ставали прикладом для інших розробників. Розробники копіювали популярну ігрову механіку, додаючи трохи ідей від себе, таким чином навколо найбільш популярних ігор утворювалися цілі класи схожих між собою ігор, ці класи і стали називати ігровими жанрами. Поділ на жанри дуже корисно на практиці. Ігри певного жанру цікаві вже сформувалася ігровий аудиторії. Розробник оголошує, що випускає гру в такому-то жанрі, і гравці вже приблизно уявляють собі, що буде відбуватися в грі, навіть без уточнюючих коментарів розробників. Часто фірма-розробник однозначно не може вказати жанр нової гри, так як має намір продати цей програмний продукт більшій кількості кінцевих користувачів, що не звужуючи тематикою коло потенційних покупців. Зазвичай ігри в основному класифікуються за жанрами, а також за кількістю гравців. Вони поділяються на кілька типів: квести, екшн, рольові ігри (рпг), файтинги, стратегії, симулятори, логічні та азартні та інші (рис. 1.1).



Рисунок 1.1 Класифікація ігор

Найвідоміші ігри, в яких є право вибору - це РПГ, іноді екшн і квести. Гравець самостійно вибирає персонаж, одягає його, наділяє здібностями. У грі передбачена свобода дій, яка впливає на процес і результат гри. Даний тип гри викликає стійке звикання, гравець ототожнює себе з персонажем, розвиває його за своїм образом і подобою. Ігровий процес сприймається як реальність. Багатьом РПГ - гри нагадують фантастичні книги з можливістю управління головним героєм, що становить особливий інтерес для читаючих ігроманів. Розумне захоплення подібними іграми схоже на пристрасть до читання книг, воно не шкідливо, навпаки, розвиває фантазію, захоплює пізнанням історії, відображає реальність.

Розроблюваний додаток, модель якого розробляється в даній курсовій роботі, є такою РПГ грою.

2. УНІФІКОВАНА МОВА МОДЕЛЮВАННЯ UML

Мова UML розвивається з 1994 року і є результатом злиття трьох найбільш відомих об'єктно-орієнтованих підходів: методу Буча, ОМТ і OOSE. У 1997 році мову UML було прийнято комітетом OMG як стандарт. Вона практично замінила собою всі інші об'єктно-орієнтовані підходи. Мова UML є грандіозною спробою розробити на основі об'єктно-орієнтованого підходу універсальну мову графічного моделювання для аналізу і проектування складних комп'ютерних систем. Вона об'єднує велику кількість різних графічних нотацій з метою впорядкування хаотичного набору графічних засобів, які використовуються під час створення програмного забезпечення. Стандартизація тут суттєво підвищує рівень розуміння між різними фахівцями, які розроблюють складну систему. Крім того, стандарт полегшує процес перенесення специфікацій, виконаних у різних CASE-пакетах.

В основному документі щодо мови UML описано версію UML 1.1 1997 року. Ця праця грунтується на настанові з UML.

Нижче коротко розглядаються поняття UML, на яких засновано засоби структурної декомпозиції проекту та розроблюваної системи.

Пакет - це простір імен проекту, який складається з множини сутностей, виражених за допомогою понять і діаграм UML. Пакети можуть включати в себе інші пакети.

Модель - це тип пакету, який є певним закінченим образом системи, що описує її з певного погляду. Наприклад, для розроблюваної системи можна побудувати модель випадків використання, яка буде визначати функціональні вимоги до неї.

Погляд - це певний спосіб бачення системи, з огляду на який будується певна модель системи. Погляд включає в себе набір графічних нотацій та їх семантику. Виділяються такі погляди на систему: статичний, випадків використання, взаємодії, скінченно-автоматний, активностей, фізичний, керований.

Підсистема - це вид пакету, який описує певну частину системи, виділену в єдине ціле за реалізаційними або функціональними міркуваннями. Структура підсистеми ділиться на дві частини - декларативну та реалізаційну. Перша визначає зовнішню поведінку підсистеми і може включати в себе випадки використання, інтерфейси та ін. Реалізаційна частина описує, яким чином реалізується декларативна частина.

За допомогою UML розробники програмного забезпечення можуть забезпечити повне угоду у використовуваних графічних позначеннях, щоб представити загальні поняття, такі як: компонент, узагальнення, клас, поведінку та агрегація. За рахунок цього досягається велика ступінь концентрації на архітектурі і проектуванні.

UML-діаграма - це спеціалізований мова графічного опису, призначений для об'єктного моделювання в сфері розробки різного програмного забезпечення.Варто відзначити, що є кілька видів таких діаграм:

· Діаграма класів UML являє собою статичну структурну діаграму, призначену для опису структури системи, а також демонстрації атрибутів, методів і залежностей між кількома різними класами.

· Діаграма компонентів UML являє собою повністю статичну структурну діаграму. Призначається вона для того, щоб продемонструвати розбиття певної програмної системи на різноманітні структурні компоненти, а також зв'язки між ними. Діаграма компонентів UML як таких може використовувати різноманітні моделі, бібліотеки, файли, пакети, виконувані файли і ще безліч інших елементів.

· Діаграма діяльності UML відображає розкладання певної діяльності на кілька складових частин. В даному разі поняттям «діяльність» називається специфікація певного виконуваного поведінки у вигляді паралельного, а також координованого послідовного виконання різних підлеглих елементів - вкладених типів діяльності та різних дій, об'єднаних потоками, що йдуть від виходів певного вузла до входів іншого. Діаграма діяльності UML досить часто використовуються для того, щоб моделювати різні бізнес-процеси, паралельні і послідовні обчислення. Крім усього іншого ними моделюються різноманітні технологічні процедури.

· Діаграма станів має представлений кінцевий автомат з простими і композитними станами, а також переходами. Кінцевий автомат являє собою специфікацію послідовності різних станів, через які проходить певний об'єкт, або ж взаємодія у відповідь на деякі події свого життя, а також відповідні дії об'єкта на такі події. Кінцевий автомат, який використовує діаграма станів UML, закріплюється за вихідним елементом і використовується для того, щоб визначити поведінку його примірників. В якості аналогів таких діаграм можуть використовуватися так звані дракон-схеми.

· Діаграма варіантів використання UML відображає на собі всі відносини, які виникають між акторами, а також різними варіантами використання. Головне її завдання - здійснювати собою повноцінне засіб, за допомогою якого замовник, кінцевий користувач або ж який-небудь розробник зможе спільно обговорювати поведінку і функціональність певної системи.

· Діаграма комунікації точно так само, як і діаграма послідовності UML, є транзитивною, тобто виражає в собі взаємодію, але при цьому демонструє його різними способами, і при необхідності з потрібним ступенем точності можна перетворити одну в іншу. Діаграма комунікації відображає в собі взаємодії, які відбуваються між різними елементами композитної структури, а також ролями кооперації. Головною відмінністю її від діаграми послідовності є те, що на ній досить явно вказуються зв'язки між елементами, а час не використовується в якості окремого вимірювання.

· Діаграма співпраці дозволяє продемонструвати взаємодії між кількома об'єктами, абстрагуючись від послідовності трансляції повідомлень. Даний тип діаграм в компактному вигляді відображає в собі абсолютно всі передані і прийняті повідомлення певного об'єкта, а також формати цих повідомлень. З причини того, що діаграми послідовності і комунікації являють собою просто-напросто різний погляд на одні й ті ж процедури, Rational Rose надає можливість створювати з діаграми послідовності комунікаційну або ж навпаки, а також здійснює повністю автоматичну синхронізацію.

Незважаючи на те, що UML досить широко розповсюджений і використовуваний стандарт, його часто критикують через наступні недоліки:

· Надмірність мови. UML часто критикується, як невиправдано велика і складна. Вона включає багато надлишкових або практично невикористовуваних діаграм і конструкцій. Частіше це можна почути у відношенні UML 2.0, чим UML 1.0, тому що більше нові ревізії включають більше « розроблених-комітетом» компромісів.

· Неточна семантика . Тому що UML визначена комбінацією себе (абстрактний синтаксис), OCL (мовою опису обмежень -- формальної перевірки правильності) і Англійської (докладна семантика), то вона позбавлена скутості властивим мовам, точно певним техніками формального опису. У деяких випадках абстрактний синтаксис UML, OCL і Англійської суперечать один одному, в інших випадках вони неповні. Неточність опису самої UML однаково відбивається на користувачах і постачальниках інструментів, приводячи до несумісності інструментів через унікальне трактування специфікацій.

· Проблеми при вивченні й впровадженні. Вищеописані проблеми роблять проблематичним вивчення й впровадження UML, особливо коли керівництво насильно змушує використовувати UML інженерів при відсутності в них попередніх навичок (стаття ACM "Death by UML Fever" на англ. містить цікаве оповідання про кількість таких випадків.).

· Тільки код відображає код . Ще одна думка -- що важливо робочі системи, а не гарні моделі. Як лаконічно виразився Джек Ривс, «The code is the design» (англ. «Код і є проект»). Відповідно до цієї думки, існує потреба в кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідного або здійсненного коду. Однак цього все-таки може бути недостатньо, тому що UML не має властивостей повноти по Тьюрінгу і будь-який згенерований код буде обмежений тим, що може розглянути або припустити інтерпретуючий UML інструмент.

· Кумулятивне навантаження/Неузгодженість навантаження (Cumulative Impedance/Impedance mismatch). Неузгодженість навантаження -- термін з теорії системного аналізу для позначення нездатності входу системи сприйняти вихід іншої. Як у будь-якій системі позначень UML може представити одні системи більш коротко й ефективно, чим інші. Таким чином, розроблювач відмінюється до рішень, які більш комфортно підходять до переплетенню сильних сторін UML і мов програмування. Проблема стає більш очевидної, якщо мова розробки не дотримується принципів ортодоксальної об'єктно-орієнтованої доктрини (не намагається відповідати традиційним принципам ВОП).

· Намагається бути всім для всіх. UML -- це мова моделювання загального призначення, що намагається досягти сумісності з усіма можливими мовами розробки. У контексті конкретного проекту, для досягнення командою проектувальників певної мети, повинні бути обрані застосовні можливості UML. Крім того, шляхи обмеження області застосування UML у конкретній області проходять через формалізм, що не повністю сформульований, і який сам є об'єктом критики.

3. РОЗРОБКА МОДЕЛІ ПРОГРАМНОЇ СИСТЕМИ ЗАСОБАМИ UML

Rational Rose - потужне CASE-засіб для проектування програмних систем будь-якої складності. Одним з достоїнств цього програмного продукту буде можливість використання діаграм на мові UML. Можна сказати, що Rational Rose є графічним редактором UML діаграм.

У розпорядження проектувальника системи Rational Rose надає наступні типи діаграм, послідовне створення яких дозволяє отримати повне уявлення про всю проектованої систему і про окремі її компонентах:

· Use case diagram (діаграми прецедентів);

· Deployment diagram (діаграми топології);

· Statechart diagram (діаграми станів);

· Activity diagram (діаграми активності);

· Interaction diagram (діаграми взаємодії);

· Sequence diagram (діаграми послідовностей дій);

· Collaboration diagram (діаграми співробітництва);

· Class diagram (діаграми класів);

· Component diagram (діаграми компонент).

3.1 Розробка виду з погляду прецедентів

Вид з погляду прецендентів включає наступні типи діаграм:

· діаграмма прецендентів;

· діаграма діяльності;

· діаграма станів.

Розглянемо на прикладі предметної області “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”, кожну з діаграм розглянемо більш детально.

Діаграма прецедентів

Цей вид діаграм дозволяє створити список операцій, які виконує система. Часто цей вид діаграм називають діаграмою функцій, тому що на основі набору таких діаграм створюється список вимог до системи і визначається безліч виконуваних системою функцій.

Даний тип діаграм використовується при описі бізнес процесів автоматизованій предметноії області, визначенні вимог до майбутньої програмної системі. Відображає об'єкти як системи, так і предметної області і завдання, ними виконуються. Кожна така діаграма або, як її зазвичай називають, кожен Use case - це опис сценарію поведінки, якого дотримуються дійові особи (Actors).

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.1)

Рисунок 3.1 Діаграма прецедентів для “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”

Дана діаграма складається з прецедентів: “Вибрати персонаж”, “Задати параметри персонажу”, “Налаштування”, “Вибрати варіант гри” та актору “Гравець”. На діаграмі прецеденти та актори взаємодіють між собою. Між прецедентами в мові UML використовують дві залежності: відношення включення <<include>> та відношення розширення <<extended>>.

Діаграма діяльності

Діаграма діяльності -- в UML це візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станів кінечного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій.

Дія є фундаментальною одиницею визначення поведінки в специфікації. Дія отримує множину вхідних сигналів, та перетворює їх на множину вихідних сигналів. Одна із цих множин, або обидві водночас, можуть бути порожніми. Виконання дії відповідає виконанню окремої дії. Подібно до цього, виконання діяльності є виконанням окремої діяльності, буквально, включно із виконанням тих дій, що містяться в діяльності. Кожна дія в діяльності може виконуватись один, два, або більше разів під час одного виконання діяльності. Щонайменше, дії мають отримувати дані, перетворювати їх та тестувати, деякі дії можуть вимагати певної послідовності. Специфікація діяльності (на вищих рівнях сумісності) може дозволяти виконання декількох (логічних) потоків, та існування механізмів синхронізації для гарантування виконання дій у правильному порядку.

Діаграма діяльності описує деякий алгоритм виконання роботи. Діаграма містить початкові і кінцеві вершини, які позначаються у вигляді повідомлень. Діаграма, яка представлена в даній курсовій роботі починається з “ Запуску гри” - початкова вершина і “Кінець гри” - кінцева вершина. Діаграма діяльності містить повідомлення, які позначаються скругленими прямокутниками, зв'язок, що позначається у вигдялі направлених стрілочок.

Приведена нижче діаграма відображає стани, в яких знаходиться система під час роботи з нею гравця (рис. 3.2).



Рисунок 3.2 Діаграма діяльності “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”

Діаграма станів

Діаграми станів застосовуються для того, щоб пояснити, яким чином працюють складні об'єкти. Діаграма станів показує, як об'єкт переходить з одного стану в інший. Очевидно, що діаграми станів служать для моделювання динамічних аспектів системи (як і діаграми послідовностей, кооперації, прецедентів ідіаграми діяльності). Часто можна почути, що діаграма станів показує автомат. Діаграма станів корисна при моделюванні життєвого циклу об'єкта. Від інших діаграм діаграма станів відрізняється тим, що описує процес зміни станів тільки одного примірника певного класу - одного об'єкта, причому об'єкта реактивного, тобто об'єкта, поведінка якого характеризується його реакцією на зовнішні події. Поняття життєвого циклу вдаються якраз до реактивних об'єктів, даний стан (і поведінку) яких обумовлено їх минулим станом. Але діаграми станів важливі не тільки для опису динаміки окремого об'єкта. Вони можуть використовуватися для конструювання виконуваних систем шляхом прямого і зворотного проектування.

Діаграма, яка відображена в даній курсовій роботі містить наступні стани системи: “Проходження «точки збереження»”, Формування нового файлу”, “Збереження параметрів ігрового поля”, “Збереження параметрів персонажу”, “Збереження файлу до папки”. Приведена нижче діаграма відображає стани системи під час моменту гри (рис. 3.3)

Рисунок 3.3 Діаграма станів “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”

3.2 Розробка виду з погляду проектування

Вид з погляду прецендентів включає наступні типи діаграм:

· діаграмма послідовності;

· діаграма класів;

· діаграма кооперацій.

Розглянемо на прикладі предметної області “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”, кожну з діаграм розглянемо більш детально.

Діаграма послідовності

Діаграма послідовностей відноситься до діаграм взаємодії UML, що описує поведінкові аспекти системи, але розглядає взаємодію об'єктів у часі. Іншими словами, діаграма послідовностей відображає часові особливості передачі і прийому повідомлень об'єктами.

На діаграмі послідовностей показано у вигляді вертикальних ліній різні процеси або об'єкти, що існують водночас. Надіслані повідомлення зображуються у вигляді горизонтальних ліній, в порядку відправлення.

Головними елементами в діаграмі послідовності є об'єкти, які представлені у вигляді прямокутників: “Гравець”, “Гра”, “Персонаж”, “Карта”; вертикальні лінії, які відображають життя об'єкта та повідомлення, які графічно представлені у вигляді стрілок. На діаграмі послідовності визначимо передачу повідомлень між об'єктами.

Приведена нижче діаграма відображає взаємодію даних об'єктів між собою з допомогою повідомлень під час відновлення користувачем гри після проходження «точки збереження» або «паузи»(рис. 3.4)



Рисунок 3.4 Діаграма послідовності “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”

Діаграма класів

Діаграма класів -- статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм. Діаграма класів (class diagram) служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. На цій діаграмі показують класи, інтерфейси, об'єкти й кооперації, а також їхні відносини.

Діаграма класів складається з наступних класів: «Гравець», «Гра», «Персонаж», «Карта», «Сценарій», «Місія», «Модуль допомоги», «Модуль налаштування», «Герой», «Бот», «Комп'ютер ».

Між класами установлюється асоціація ”один до багатьох”, ”багато до багатьох”. Кожен клас має атрибути.

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.5)



Рисунок 3.5 Діаграма класів “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”

Діаграма кооперацій

Діаграма кооперацій - це діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між об'єктами, а час як окремий вимір не використовується (застосовуються порядкові номери викликів).

Кооперація (collaboration) - специфікація множини об'єктів окремих класів, спільно взаємодіючих з метою реалізації окремих варіантів використання в загальному контексті модельованої системи.

Виділяють такі рівні кооперації: рівень специфікації - показує ролі класифікаторів і ролі асоціацій в розглянутому взаємодії, та рівень прикладів - вказує екземпляри і зв'язки, що утворюють окремі ролі в кооперації.

Діграму кооперацій можно представити у вигляді діаграми послідовності. Діаграма кооперацій складається з об'єктів та повідомлень. Об'єкти позначаються у вигляді прямокутника: “Грав1:Гравець”, “Г1:Гра”, “Титан:Персонаж” та “К1:Карта”. Об'єкти взаємодіють між собою за допомогою повідомлень.

Приведена нижче діаграма відображає взаємодію даних елементів між собою під час формування нового сеансу гри (рис. 3.6).

Рисунок 3.6 Діаграма кооперацій “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів»

3.3 Розробка виду з погляду реалізації

Діаграма компонентів

Діаграма компонентів -- в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними.

Модуль програмного забезпечення може бути представлено в якості компоненти.

Я показую діаграму реалізації своєї системи у вигляді наборів компонент, за допомогою яких вона буде реалізована.



Рисунок 3.6 Діаграма компонентів “ Моделювання роботи інформаційної системи програмного забезпечення для клієнтського застосування комп'ютерної гри «Тіні забутих днів» ”

Розроблена модель програмного забезпечення, яка описана в UML - нотації, може бути реалізована за допомогою мови високого рівня С++ або Delphi. Кожна з цих мов програмування підтримує реалізацію класів і можливість використання алгоритмів спадкоємства, агрегації і композиції. Система може бути описана в програмному середовищі Rational Rose і перетворена в програмний код при внесенні деяких доповнень.

ВИСНОВОК

Автоматизація процесу моделювання -- це засіб автоматизації при створенні імітаційних програмних моделей,що дають змогу не тільки вилучити проміжну ланку між аналітиком і людиною, що приймає рішення, а й під час створення моделі використовувати терміни предметної галузі, в якій працює аналітик.

В цій курсові роботі була розроблена модель гри з виділеними персонажами та ролями. Структура була описана в програмному середовищі Rational Rose.

Інформація, необхідна для опису наочної області, залежить від реальної моделі і може включати відомості про все що стосується обраної теми. В даному випадку модель програмної системи описує процес підбору персонажу та проходження місій за сценарієм гри «Тіні забутих днів».

Модель як абстракція, що описує сутність проблеми або структури ІС без несуттєвих деталей, допомагає зрозуміти проблему всім учасникам проекту. А застосування інструментальних CASE-систем веде до скорочення витрат на розробку програмного забезпечення за рахунок зменшення числа ітерацій і числа помилок, до поліпшення якості продукту за рахунок кращого взаєморозуміння розробника і замовника, до полегшення супроводу готового програмного забезпечення.

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. І.О.Чмир та ін., Моделювання систем в середовищі UML: посібник для ВНЗ. Черкаси,2004

2. М.Фаулер, К.Скотт, Основи. Посібник з уніфікованої мови UML. М:Біном, 2000

3. Ларман К., Применение UML и шаблонов проектирования - М.: «Вильямс» ,2001.-496с.

4. Леоненков А.В.,Самоучитель UML - СПб.: «БХВ-Петербург», 2001.-432с.

5. А. Асоненков Самовчитель по UML, БХВ - Пітер, 2002 р.

6. http://ru.wikipedia.org - вікіпедія

Размещено на Allbest.ru

...