95988

Побудова програмної моделі розповсюдження інфекції

Дипломная

Информатика, кибернетика и программирование

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

Украинкский

2015-10-01

1.67 MB

0 чел.

Побудова програмної моделі розповсюдження інфекції


МІНІСТЕРСТВО  ОСВІТИ  І   НАУКИ  УКРАЇНИ
ПОЛТАВСЬКИЙ ПОЛІТЕХНІЧНИЙ КОЛЕДЖ
НАЦІОНАЛЬНОГО ТЕХНІЧНОГО УНІВЕРСИТЕТУ
«ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ»

РЕФЕРАТ

Дипломна робота містить сторінок, таблиць, рисунків, список літератури з найменувань,  додатки.

Тема дипломної роботи

Об’єктом дослідження виступає програма яка візуалізує процес розповсюдження клітин інфекції

Предметом дослідження є мова програмування С++, та середовище розробки Builder.

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

Відповідно до мети наукового дослідження були поставлені та розв’язані наступні завдання:

  •  Створено программу яка візуалізує процесс розповсюдження;
  •  Складено порівняльна характеристика існуючих програм аналогічного призначення;
  •  Створено структурну схему програми;
  •  представити вихідні коди створеної системи створити та описати функціонал розробленої нами системи.

За результатами дослідження сформульовані

.

Рік виконання дипломної роботи       2015р.
Рік захисту роботи         2015р.

ЗМІСТ

[1] ЗМІСТ

[2] ВСТУП

[3] 1. ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ

[4]
2. ОГЛЯД ТА ПОРІВНЯЛЬНА ХАРАКТЕРИСТИКА МОДЕЛЕЙ КЛІТИННИХ АВТОМАТІВ

[4.1] 2.1. «Клітинний автомат»

[4.2] 2.2. «Машина Тюрінга»

[4.3] 2.3. «Гра життя (Гра Конвея)»

[5]
3. ОПИС ФУНКЦІОНАЛУ МАЙБУТНЬОЇ СИСТЕМИ

[5.1] 3.1.Сценарій використання

[5.2] 3.2. Основні прецеденти

[5.3] 3.3. Прототип інтерфейсу

[6] 4. ОПИС АРХІТЕКТУРИ СИСТЕМИ

[6.1] 4.1. Поняття про архітектуру системи

[6.2] 4.2.

[7] 5. ОПИС ПРОЕКТНИХ РІШЕНЬ

[7.1] 5.1. Мова С++

[7.2] 5.2. С++Builder

[8] 6. ЕКОНОМІЧНА ЧАСТИНА

[8.1] 6.1.

[8.2] 6.2.

[9] 7. ОХОРОНА ПРАЦІ В ГАЛУЗІ

[9.1] 7.1. Заходи з охорони праці

[10] ВИСНОВКИ

[11]
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ:

[12] ДОДАТОК А. ТАБЛИЦЯ – ПОРІВНЯЛЬНА ХАРАКТЕРИСТИКА  МОДЕЛЕЙ КЛІТИННИХ АВТОМАТІВ

[13] ДОДАТОК Б. ДІАГРАМИ ПРЕЦЕДЕНТІВ.

[14] ДОДАТОКВ. МОДЕЛЬ ІНТЕРФЕЙСУ

[15] ДОДАТОК Г. ВИХІДНІ КОДИ СТВОРЕНОЇ СИСТЕМИ

[16] ДОДАТОК Д. СКРІНШОТИ СТВОРЕНОЇ СИСТЕМИ


ВСТУП

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

Досягнути поставленої мети передбачається шляхом вирішення таких завдань:

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

Об’єктом дослідження є використання мови програмування с++ для створення програмний продукт який має  в графічному вигляді або за допомогою псевдографіки відображати динаміку розповсюдження хвороботворних мікроорганізмів

Предметом дослідження є консольна програма, яка моделює розповсюдження інфекції, створена засобами мови С++.

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

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

У першому розділі буде представлено опис предметної області завдання.

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

У третьому розділі буде представлено функціонал майбутньої програми та побудована модель прецедентів.

У четвертому розділі буде представлено  архітектуру системи.

У п’ятому розділі буде розділі буде представлено розрахунок економічних показників.

У шостому розділі буде представлено огляд питань з охорони праці в галузі.

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

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


1. ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ

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

  •  Якщо у живої клітини два чи три сусіди – то вона лишається жити;
  •  якщо у живої клітини один чи немає сусідів – то вона помирає від «самотності»;
  •  якщо у живої клітини чотири та більше сусідів – вона помирає від «перенаселення»;
  •  якщо у мертвої клітини рівно три сусіди – то вона оживає.

Дані правила отримали назву генетичних законів Конвея, вони задовольняють три основні умови:

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

повністю зникають;

переходять у стійку конфігурацію та перестають змінюватися взагалі;

виходять у коливальний режим з певним періодом.

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

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

Клітина має три стани: здорова, хвора та клітина після видужання, яка набула імунітет на певний проміжок часу. Центральна клітина на ділянці шкіри є хворою і може заразити будь-яку іншу сусідню на кожному проміжку часу з імовірність 50%, по проходженню 6 відрізків часу вона видужує і набуває імунітет який триватиме 4 відрізки часу (клітина, яка набула імунітет, не може бути зараженою і не може нікого заразити) потім вона втрачає імунітет і може знову заразитися.

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


2. ОГЛЯД ТА ПОРІВНЯЛЬНА ХАРАКТЕРИСТИКА МОДЕЛЕЙ КЛІТИННИХ АВТОМАТІВ

2.1. «Клітинний автомат»

Клітинний автомат (КА) – сукупність, до якої входить набір клітинок, які утворюють періодичну решітку, та задані правила переходу, що визначають стан клітини за теперішнім станом самої клітинки та тих її сусідів, що знаходяться від неї на певній відстані, яка не перевищує максимальну.

Основний напрям дослідження клітинних автоматів – алгоритмічна розв'язність якихось задач. Також розглядаються питання побудови початкових станів, при яких клітинний автомат вирішуватиме задану задачу. Залишається відкритим, наприклад, питання про можливість побудови машини Тюрінга у грі «Життя».

Поняття клітинних автоматів доволі широке, тому можна знайти доволі багато різних визначень.

Найпоширенішими є:

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

ВЛАСТИВОСТІ КЛІТИННОГО АВТОМАТУ

  •  Стани елементів

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

  •  Геометрія

Елементи можуть бути геометрично розташовані різноманітним чином. Розмірність простору може бути довільною, а число елементів – як безкінечним, так і скінченним. В останньому випадку виникає додаткова міра свободи в граничних умовах. Вони можуть бути різними, але на практиці використовуються постійні у часі (найчастіше – нульові) або періодичні граничних умовах. У динамічних КА геометрія може змінюватися з часом, а якщо геометрія різна на різних ділянках простору, такі кліткові КА називають неоднорідними.

  •  Сусідство

Сусіди – це елементи, від яких залежить елемент КА. Можна назвати поняття сусідства ключовим для КА. При тому сусідство розуміється не в геометричному сенсі, а в інформаційному. Хоча зазвичай інформаційний сенс накладається на геометричний. Сусідство одиничних автоматів встановлюється постійним для кожного одиничного автомата решітки і визначається спеціальним вектором – індексом сусідства. Як правило, розглядаються d-мірні регулярні решітки, в цілочислові точки яких поміщені копії деякого автомата Мура. Стан елемента в наступний момент часу обчислюється із стану самого елементу і його сусідів. Сусідство у більшій мірі визначається геометрією КА. Для різних цілей можлива зміна числа вхідних станів елемента. Якщо для кожного елемента КА число входів і виходів однакове, такий КА називається збалансованим.

  •  Локальне правило

Відповідно до локального правила змінюється стан елемента КА протягом часу. КА, в якому локальні правила різні для різних елементів, називається різнорідним. Локальне правило може бути недетермінованим, тобто змінюватися в часі або мати випадкову природу.

2.2. «Машина Тюрінга»

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

Машина Тюрінга – математичне поняття, введене для формального уточнення інтуїтивного поняття алгоритму. Названа на честь англійського математика Алана Тюрінга, який запропонував це поняття у 1936. Аналогічну конструкцію машини згодом і незалежно від Тюрінга ввів американський математик Еміль Пост.

Основна ідея, що лежить в основі машини Тюрінга, дуже проста. Машина Тюрінга – це абстрактна машина (автомат), що працює зі стрічкою, що складається із окремих комірок, в яких записано символи. Машина також має голівку для запису та читання символів із комірок і яка може рухатись вздовж стрічки. На кожному кроці машина зчитує символ із комірки, на яку вказує голівка та, на основі зчитаного символу та внутрішнього стану, робиться наступний крок. При цьому, машина може змінити свій стан, записати інший символ в комірку або пересунути голівку на одну комірку ліворуч або праворуч.

У кожної машини Тюрінга є стрічка, потенційно нескінченна в обидві сторони. Є скінченна множина символів стрічки S0, …, Sn, що називається алфавітом машини. У кожен момент часу кожна комірка може бути зайнята не більш ніж одним символом. Машина має деяку скінченну множину внутрішніх станів q0, q1, …, qn. У кожен даний момент часу машина знаходиться лише в одному із цих станів.

Нарешті, є голівка, яка у кожен даний момент часу знаходиться на одній із комірок стрічки. Машина діє не безупинно, а лише у дискретні моменти часу. Якщо у якийсь момент t голівка сприймає комірку (тобто знаходиться на комірці), що містить символ Si, і машина знаходиться у внутрішньому стані qj, то дія машини визначена однією із чотирьох дій:

  •  голівка затирає символ Si, і записує у тій же комірці новий символ Sk,
  •  голівка пересувається в сусідню ліву комірку,
  •  голівка пересувається в сусідню праву комірку,
  •  машина зупиняється.

У випадках (1)-(3) машина переходить у новий внутрішній стан qr, і готова знову до дії у наступний момент t + 1. Припустимо, що символ S0 представляє порожню комірку, і отже, голівка завжди сприймає деякий символ.

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

Тут перші два символи це відповідно внутрішні стани машини і сприйнятий символ, наступні три визначають дію машини (запис голівкою символу Sk, або переміщення голівки на одну комірку вліво, або переміщення голівки на одну комірку вправо) та новий стан машини. Якщо стрічка вкладена в машину Тюрінга, голівка машини встановлена на одну із комірок стрічки і машина приведена в один із своїх внутрішніх станів, то машина починає оперувати на стрічці: її голівка пише і стирає символи і пересувається з однієї комірки в іншу. Якщо при цьому машина колись зупиняється, то стрічка, яка розташована в ній в цей момент, називається результатом застосування машини до даної стрічки (Рисунок 2.1).

Рисунок 2.1– Схематична ілюстрація роботи машини Тюрінга

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

МОЖЛИВОСТІ МАШИНИ ТЮРІНГА

Багатство можливостей конструкції Тюрінга виявляється в тому, що якщо якісь алгоритми A та B реалізуються машинами Тюрінга, то можна будувати програми машин Тюрінга, які реалізують композиції алгоритмів A та B, наприклад, виконати A, потім виконати B або виконати A. Якщо в результаті утворилося слово так, то виконати B. У протилежному випадку не виконувати B або виконувати по черзі A, B, поки B не дасть відповідь ні.

У інтуїтивному сенсі такі композиції є алгоритмами. Тому їхня реалізація за допомогою машини Тюрінга служить одним із засобів обґрунтування універсальності конструкції Тюрінга.

Реалізованість таких композицій доводиться у загальному вигляді, незалежно від особливостей конкретних алгоритмів A та B. Доведення полягає в тому, що вказується засіб побудови з програм A та B програми потрібної композиції. Нехай, наприклад, потрібно побудувати машину A*B, еквівалентну послідовному виконанню алгоритмів A та B. Поки виконується алгоритм A, у програмі A*B працює частина A без урахування частини B. Коли алгоритм A дійде до кінця, то замість зупинки відбудеться перехід у перший стан частини B, і потім частина B буде працювати звичайним чином, наче частини A і не було.(Рисунок 2.2).

Рисунок 2.2– Принцип роботи машини Тюрінга

Аналогічно конструюють й інші композиції машин Тюрінга; щораз будуються загальні правила: що на що змінювати у вихідних програмах.

Описуючи різноманітні алгоритми для машин Тюрінга і стверджуючи реалізованість усіляких композицій алгоритмів, Тюрінг переконливо показав розмаїтість можливостей запропонованої ним конструкції, що дозволило йому виступити з такою тезою:

Всякий алгоритм може бути реалізований відповідною машиною Тюрінга.

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

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

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

усе, що реалізовано в одній з цих конструкцій, можна зробити і в інших

Ці твердження доводяться строго, тому що в них мова йде вже про тотожність формальних схем.[*]


2.3. «Гра життя (Гра Конвея)»

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

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

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

Показовим прикладом для ознайомлення з принципами роботи клітинного автомата є гра Джона Конвея "Життя". Індивідуум цієї популяції представлений клітиною в стані 1, у той час як клітина в стані 0 представляє порожній простір (для образності можна говорити про "живі" і "мертві" клітини). Мірою течії часу служить зміна поколінь колонії, яка відбувається за відомими правилами.

Популяція (або колонія) клітин в "Житті" може весь час зростати, безперервно міняючи своє розташування, форму і число клітин. Однак частіше колонія стає врешті-решт стаціонарною або циклічно повторює один і той же кінцевий набір станів. Довжина циклу називається періодом колонії. Приклад розвитку колонії показаний на рис.

Приклади розвитку колоній в грі" Життя ".

Найпоширеніші популяції клітин у грі Конвея "Життя"


3. ОПИС ФУНКЦІОНАЛУ МАЙБУТНЬОЇ СИСТЕМИ

3.1.Сценарій використання

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

У 1986 році Івар Якобсон, пізніше співавтор Уніфікованої Мови Моделювання (UML) та Раціонального Уніфікованого Процесу (RUP), вперше сформулював методику візуального моделювання для опису сценаріїв використання. Спочатку він використовував дещо інші терміни – англ. Usage scenarios і usage case , але жоден з них не був природним для англійської мови. І в кінцевому рахунку він зупинився на терміні use case – сценарій використання. Після створення Якобсоном методики моделювання сценаріїв використання багато людей посприяли поліпшенню цієї методики, включаючи Курта Біттнера, Алістера Кокберн, Ганнера Овергарда, і Джері Шнайдера.

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

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

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

Варіанти застосування сценаріїв у процесі розробки залежать від використовуваної методології розробки. В одних методологіях розробки все, що потрібно це короткий огляд сценарію. В інших сценарії використання ускладнюються і змінюються в ході розробки.[*]

3.2. Основні прецеденти

3.3. Прототип інтерфейсу

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

Створена система виглядає наступним чином: консольне вікно, в якому зображена матриця з заданим розміром, над матрицею показується якого стану набувають клітини на даному проміжку часу, а під матрицею нам задається питання: «Чи бажаєте ви продовжити(Y/N)».

Вводимо з клавіатури «Y»,нам буде представлено наступний проміжок. Якщо ми вводимо «N»,або якийсь інший символ то програма припиняє свою роботу. Якщо ввести «Y» кілька разів, то відображається стан клітин, яким він буде через декілька проміжків(скільки «Y», скільки проміжків пройде).

4. ОПИС АРХІТЕКТУРИ СИСТЕМИ

4.1. Поняття про архітектуру системи

Початок архітектурі програмного забезпечення як концепції було покладено в науково-дослідницькій роботі Едсгера Дейкстри в 1968 році і Девіда Парнаса на початку 1970-х. Ці вчені підкреслили, що структура системи ПЗ має важливе значення, і що побудова правильної структури - критично важливо. Популярність вивчення цієї області зросла з початку 1990-х років разом з науково-дослідницькою роботою по дослідженню архітектурних стилів (шаблонів), мов описання архітектури, документування архітектури і формальних методів.

У розвитку архітектури програмного забезпечення як дисципліни відіграють важливу роль науково-дослідницькі установи. Мері Шоу і Девід Герлан з університету Carnegie Mellon написали книгу під назвою «Архітектура програмного забезпечення: перспективи нової дисципліни в 1996 році», в якій висунули концепції архітектури програмного забезпечення, такі як компоненти, з'єднувачі (connectors), стилі і так далі. У Каліфорнійському університеті в Ірвайні інститут по дослідженню ПЗ насамперед досліджує архітектурні стилі, мови опису архітектури і динамічні архітектури.

Першим стандартом програмної архітектури є стандарт IEEE 1471: ANSI / IEEE 1471–2000: Рекомендації по опису переважно програмних систем. Він був прийнятий в 2007 році, під назвою ISO / IEC 42010:2007.

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

Архітектура системи – це структурна схема компонентів системи, взаємодіючих між собою через інтерфейси. Компоненти можуть складатися з послідовності більш дрібних компонентів та інтерфейсів. Розроблення архітектури ґрунтується на загальних довідниках, класифікаторах та ін. У ній ідентифікуються загальні частини системи, у тому числі готові програмні продукти і заново розроблені компоненти, а також багаторазово використовувані в інших застосуваннях.

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

Основні розв’язки щодо структури системи приймаються групою архітекторів і аналітиків. Вони передають окремі частини системи для реалізації невеликим групам розробників.

Проектування системи може здійснюватися на основі об'єкто-орієнтованого моделювання методом UML, який дозволяє враховувати аспекти, властиві діючим особам (акторам) системи, створювати сценарії виконання системи тощо. Об’єктний стиль проектування – це декомпозиція майбутньої системи на окремі підсистеми (пакети), визначення функціональних і нефункціональних вимог і об’єктної моделі предметної області. Носіями інтересів, можливостей і дій в системі (або пакеті) є діючі особи – актори. Пакет може складатися з об’єктної моделі, варіантів використання, що визначають сценарії поведінки системи, склад об’єктів і методів їхньої взаємодії. Поведінка об’єктів відображується діаграмами, що задають послідовність взаємодії об’єктів (діаграми послідовностей, взаємодії), правилами переходу від стану до стану (діаграми станів), а також діаграмами кооперації, в яких діючі особи зображуються графічно. Об’єкти і відповідні їм діаграми варіантів використання задають загальну архітектурну схему системи, у рамках якої здійснюється реалізація структури і специфіки поведінки компонентів. Загальна концепція об’єктного проектування – це побудова всіх сценаріїв, екранних діаграм для керування ними і їх випробування в різних варіантах використання. На вибір варіантів використання впливають нефункціональні вимоги (наприклад, забезпечення конфіденційності, швидкодії й ін.). На основі моделі опису вимог і понять проводиться уточнення складу і змісту функцій системи, методів їхньої реалізації у вигляді сценаріїв і діаграм потоків даних, у яких відображається взаємодія об’єктів як обмін повідомленнями між елементами системи для передачі даних і одержання відповіді після виконання операцій. Моделі вимог визначають призначення і місце вимог у таких системах. Цьому сприяють розроблені національні, корпоративні і відомчі стандарти. Вони фіксують правила формування нефункціональних вимог, у яких відображаються відомості про взаємодію і захист даних у системі. При цьому поведінка об’єктів представляється діаграмами UML, вони можуть уточнюватися при перегляді моделей вимог і складу об’єктів системи. Перегляд починається з вимог і пошуку місць локалізації для внесення необхідних змін у модель. Зміни можуть стосуватися функціональних і нефункціональних вимог у зв’язку з уточненням замовником обмежень на структуру системи, використовувані ресурси й умови середовища її функціонування.[***]

4.2.


5. ОПИС ПРОЕКТНИХ РІШЕНЬ

5.1. Мова С++

Для розробки програми нами було обрано мову програмування С++. Дана мова програмування була обрана з декількох причин:

  •  Швидкодія. Швидкість роботи програм на С++ практично не поступається програмам на С, хоча програмісти отримали в свої руки нові можливості і нові засоби.
  •  Масштабованість. Мовою C++ розробляють програми для найрізноманітніших платформ і систем.
  •  Можливість роботи на низькому рівні з пам'яттю, адресами, портами. (Що, при необережному використанні, може легко перетворитися на недолік.)
  •  Можливість створення узагальнених алгоритмів для різних типів даних, їхня спеціалізація, і обчислення на етапі компіляції, з використанням шаблонів.
  •  Підтримуються різні стилі та технології програмування, включаючи традиційне директивне програмування, ООП, узагальнене програмування, метапрограмування (шаблони, макроси).

Незважаючи на всі її переваги, мова С++ має також ряд недоліків, які ми далі стисло розглянемо.

Наявність безлічі можливостей, що порушують принципи типобезпеки приводить до того, що в С++ програми може легко закрастися важковловима помилка. Замість контролю з боку компілятора розробники вимушені дотримуватися вельми нетривіальних правил кодування. По суті, ці правила обмежують С++ рамками якоїсь безпечнішої підмови. Більшість проблем типобезпеки С++ успадкована від С, але важливу роль в цьому питанні грає і відмова автора мови від ідеї використовувати автоматичне управління пам'яттю (наприклад, збірку сміття). Так візитною карткою С++ стали вразливості типу «переповнювання буфера».

Погана підтримка модульності. Підключення інтерфейсу зовнішнього модуля через препроцесорну вставку заголовного файлу (#include) серйозно уповільнює компіляцію, при підключенні великої кількості модулів. Для усунення цього недоліку, багато компіляторів реалізують механізм прекомпіляції заголовних файлів (англ. Precompiled Headers).

Недостача інформації про типи даних під час компіляції (CTTI).

Мова C++ є складною для вивчення і для компіляції.

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

Препроцесор С++ (успадкований від C) дуже примітивний. Це приводить з одного боку до того, що з його допомогою не можна (або важко) здійснювати деякі завдання метапрограмування, а з іншою, в наслідку своєї примітивності, він часто приводить до помилок і вимагає багато дій з обходу потенційних проблем. Деякі мови програмування (наприклад, Scheme і Nemerle) мають набагато могутніші і безпечніші системи метапрограмування (також звані макросами, але макроси С/С++ вони мало нагадують).

З кінця 1990-х в співтоваристві С++ набуло поширення так зване метапрограмування на базі шаблонів. По суті, воно використовує особливості шаблонів C++ в цілях реалізації на їхній базі інтерпретатора примітивної функціональної мови програмування, що виконується під час компіляції. Сама по собі ця можливість вельми приваблива, але, внаслідкок вище згаданого, такий код вельми важко сприймати і зневаджувати. Мови Lisp/Scheme, Nemerle і деякі інші мають могутніші і водночас простіші для сприйняття підсистеми метапрограмування. Крім того, в мові D реалізована порівнянна за потужністю, але значно простіша в застосуванні підсистема шаблонного метапрограмування.

Хоча декларується, що С++ мультипарадигмена мова, реально в мові відсутня підтримка функціонального програмування. Частково, даний пропуск усувається різними бібліотеками (Loki, Boost) що використовують засоби метапрограмування для розширення мови функціональними конструкціями (наприклад, підтримкою лямбд/анонімних методів), але якість подібних рішень значно поступається якості вбудованих у функціональні мови рішень. Такі можливості функціональних мов, як зіставлення зі зразком взагалі украй складно емулювати засобами метапрограмування.

C++ (Сі-плюс-плюс) – мова програмування високого рівня з підтримкою декількох парадигм програмування: об'єктно-орієнтованої, узагальненої та процедурної. Розроблена Б'ярном Страуструпом (англ. Bjarne Stroustrup) в AT&T Bell Laboratories (Мюррей-Хілл, Нью-Джерсі) у 1979 році та початково отримала назву «Сі з класами». Згодом Страуструп перейменував мову у C++ у 1983 р. Базується на мові С. Визначена стандартом ISO/IEC 14882:2003.

У 1990-х роках С++ стала однією з найуживаніших мов програмування загального призначення. Мову використовують для системного програмування, розробки програмного забезпечення, написання драйверів, потужних серверних та клієнтських програм, а також для розробки розважальних програм таких як відеоігри.

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

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

Проте (за станом на час написання цієї статті) серед компіляторів С++ все ще продовжується битва за повну реалізацію стандарту С++, особливо в області шаблонів – частини мови, зовсім недавно повністю розробленій комітетом стандартизації.

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

Першим компілятором, що підтримав export в шаблонах, став Comeau C++ на початку 2003 року (п'ять років після виходу стандарту). У 2004 році бета-версія компілятора Borland C++ Builder X також почала його підтримку.

Обидва цих компілятора засновані на зовнішньому інтерфейсі EDG. Інші компілятори, такі як Microsoft Visual C++ або GCC, взагалі цього не підтримують. Ерб Саттер (Herb Sutter), секретар комітету із стандартизації Сі++, рекомендував прибрати export з майбутніх версій стандарту унаслідок серйозних складнощів в повноцінній реалізації, проте згодом остаточним рішенням було вирішено його залишити.

Із списку інших проблем, пов'язаних з шаблонами, можна навести питання конструкцій часткової спеціалізації шаблонів, які погано підтримувалися протягом багатьох років після виходу стандарту Сі++.

5.2. С++Builder

Для розробки даної програми ми використовували середовище C++ Builder

C++ Builder (по-українськи зазвичай вимовляють [сі-плюс-плюс білдер]) – середовище швидкої розробки (RAD), що випускається компанією Codegear, дочірньою фірмою компанії Embarcadero (раніше Borland). Призначена для написання програм на мові програмування C++. C++ Builder об'єднує Бібліотеку візуальних компонентів і середовище програмування (IDE), написане на Delphi з компілятором C++. Цикл розробки аналогічний Delphi, але з істотними поліпшеннями, доданими в C++ Builder.[1] Більшість компонентів, розроблених в Delphi, можна використовувати і в C++ Builder без модифікації, але, на жаль, зворотне твердження не вірне. C++ Builder містить інструменти, які дозволяють здійснювати справжню візуальну розробку Windows-програм методом drag-and-drop, спрощуючи програмування завдяки WYSIWYG редакторові інтерфейсу, вбудованому в його середовище розробки.

Історія

C++ Builder спочатку створювалася тільки для платформи Microsoft Windows. Пізні версії, що містять, компонентну бібліотеку Borland, засновану на Qt, підтримують і Windows і Linux.

У 2003 Borland випустила C++ BUILDERX (CBX), написаний за допомогою тієї ж інфраструктури, що і Jbuilder, який при цьому був мало схожий на C++ Builder або Delphi. Цей продукт призначався для розробки великих програм для крупних підприємств, але комерційного успіху не досяг. В кінці 2004 року Borland оголосила, що продовжить розвиток класичного C++ Builder і об'єднає його з середовищем розробки Delphi, припинивши, таким чином, розробку C++ BUILDERX.

Опісля приблизно рік після цього оголошення, Borland випустила Borland Developer Studio 2006, який включав Borland C++ Builder 2006, що пропонував покращене управління конфігурацією і відладкою. Borland Developer Studio 2006 єдиний повноцінний комплект, Delphi, що містить, C++builder і C#builder.

У 2007 Codegear випустила C++ Builder 2007, в якому реалізувала повну підтримку API Microsoft Windows Vista, збільшила повноту відповідності стандарту ANSI C++, прискорила розробку до 500 %, включила підтримку Msbuild, архітектури баз даних Dbx4 і «VCL для Web», підтримуючий AJAX. Підтримка API Microsoft Windows Vista включила додатки, спочатку оформлені в стилі Vista, і природну підтримку VCL для Aero і Vista Desktop. Codegear RAD Studio 2007 містить C++ Builder 2007 і Delphi. Також в 2007 Codegear «воскресила» марку «Turbo» і випустила дві «Turbo» версії C++ Builder: Turbo C++ Professional і Turbo C++ Explorer (безкоштовний), заснованих на Borland C++ Builder 2006.

В кінці 2008 року компанія Codegear випустила нову версію RAD Studio, до якої увійшли Delphi 2009 і С++ Builder 2009.Наступна версія, Codegear C++builder (кодове ім'я «Commodore»), володітиме підтримкою x86-64 і можливістю створювати природний  x86-64 код.


6. ЕКОНОМІЧНА ЧАСТИНА

6.1.

6.2.


7. ОХОРОНА ПРАЦІ В ГАЛУЗІ

7.1. Заходи з охорони праці


ВИСНОВКИ


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

*http://uk.wikipedia.org/wiki

**  Сценарій використання – Вікіпедія [Електронний ресурс]. Режим доступу: URL: http://uk.wikipedia.org/wiki/Сценарій_використання

*** Архітектура програмного забезпечення – Вікіпедія [Електронний ресурс]. Режим доступу: URL: http://uk.wikipedia.org/wiki/Архітектура_програмного_забезпечення

http://victoria.lviv.ua/html/ai/doc/ev-life.doc


ДОДАТОК А. ТАБЛИЦЯ – ПОРІВНЯЛЬНА ХАРАКТЕРИСТИКА  МОДЕЛЕЙ КЛІТИННИХ АВТОМАТІВ


ДОДАТОК Б. ДІАГРАМИ ПРЕЦЕДЕНТІВ.


ДОДАТОКВ. МОДЕЛЬ ІНТЕРФЕЙСУ


ДОДАТОК Г. ВИХІДНІ КОДИ СТВОРЕНОЇ СИСТЕМИ

#include <stdio.h>//Підключення бібліотек

#include <stdlib.h>// Підключення бібліотек

void main()

{

printf("Vvedite razmer uchastka shkiru: ");    // задається розмір матриці

int n;

scanf("%d", &n);

int** a = new int*[n];

int** b = new int*[n];

for (int i = 0; i < n; i++)

 {

 a[i] = new int[n];

 b[i] = new int[n];

 for (int j = 0; j < n; j++)

  a[i][j] = 0

}

a[n/2][n/2] = -1;

for (int time = 1; true; time++)

  {

 printf("\ntime = %d\n", time);

 for (int i = 0; i < n; i++)

 {

  for (int j = 0; j < n; ++j)

  printf("%c", a[i][j] < 0 ? '@' : (a[i][j] == 0 ? '_' : '#'));

  printf("\n");

 }

 printf("prodolgutj(y/n)? ");        // Чи бажаєте ви побачить наступний відрізок часу

 char ch;

 scanf(" %c", &ch);

 if (!(ch == 'y' || ch == 'Y')) break;

 for (int i = 0; i < n; i++) {

  for (int j = 0; j < n; j++) \

   {

   if (a[i][j] == -6)

    b[i][j] = 1;   // клітина набула імунітет

   else if (a[i][j] < 0)

    b[i][j] = a[i][j]-1;

   else if (a[i][j] == 4)

    b[i][j] = 0;   //клітина втратила імунітет

   else if (a[i][j] > 0)

    b[i][j] = a[i][j]+1;

   else {

//здорова клітина заражується від сусідніх(нижче)

  b[i][j] = 0;

  if (i-1 >= 0 && a[i-1][j] < 0 && rand()*2 > RAND_MAX)

  b[i][j] = -1;

  if (i+1 < n && a[i+1][j] < 0 && rand()*2 > RAND_MAX)

  b[i][j] = -1;

  if (j-1 >= 0 && a[i][j-1] < 0 && rand()*2 > RAND_MAX)

  b[i][j] = -1;

  if (j+1 < n && a[i][j+1] < 0 && rand()*2 > RAND_MAX)

  b[i][j] = -1;

   }

  }

 }

 int** tmp = a;

 a = b;

 b = tmp;

}

for (int i = 0; i < n; i++)

 {

 delete[] a[i];

 delete[] b[i];delete[] a;   delete[] b;  }


ДОДАТОК Д. СКРІНШОТИ СТВОРЕНОЇ СИСТЕМИ

Рисунок 2.1– Консольне вікно запущеної програми

Рисунок2.2 – Вирахуваний відрізок часу


ЗАВДАННЯ ТА КАЛЕНДАРНИЙ ПЛАН

ЗАВДАННЯ ТА КАЛЕНДАРНИЙ ПЛАН


 

А также другие работы, которые могут Вас заинтересовать

46307. Выбор продуктов в продуктовых инновациях 15.27 KB
  Существуют различные подходы к продуктовым инновациям: консервативный и радикальный.Консервативный подход к выбору новых более выгодных продуктов или услуг наиболее приемлем для финансовокризисных фирм ограниченных как в возможностях финансировать значительные стартовые инвестиции в новый бизнес так и в сроке окупаемости этих инвестиций.Консервативный подход к продуктовым инновациям сводится к выбору для освоения таких продуктов услуг или операций которые бы опирались на: уже созданный технологический а также коммерческий задел фирмы...
46308. Сущность и классификация затрат 15.26 KB
  Группировка по экономическим элементам отражает затраты которые распределяются по видам характеризующим их экономическое содержание их природное назначение. Все остальные являются комплексными собирающими затраты по обслуживанию и управлению производством. Прямые затраты непосредственно связаны с производством определенного вида продукции работ услуг и могут быть учтены в себестоимости данного вида продукции работ услуг сырье материалы полуфабрикаты комплектующие зарплата станочников и др.
46309. Эксплуатация машинно-тракторного парка при возделывании сахарной свеклы в СПК «Авангард» Сергачского района Нижегородской области 978.5 KB
  Огромное экономическое значение сахарной свеклы в народном хозяйстве. Она является главным источником доходов свеклосеящих хозяйствах. При удельном весе ее в пашне ≈ 8,6% удельный вес доходов составляет ≈ 44% от доходов растениеводства.
46310. Магнитные и электромагнитные приспособления в металлообработке 64.5 KB
  Значительный прогресс в металлообработке может быть достигнут за счет применения универсальных приспособлений, использующих энергию магнитного поля. Такие приспособления могут применяться в условиях единичного, серийного и массового производств
46311. Графическое обозначение технологической оснастки в документации 93.5 KB
  Рекомендации по выбору типа привода зажимных устройств При выборе типа привода ЗУ в соответствии с требованиями технического процесса обработки деталей на станке должны быть обеспечены необходимая сила жесткость и точность зажима заготовки с заданными отношениями их размера. Достоинства гидропривода: возможность применения сравнительно выгодных давлений масла до 10 МПа и выше что позволяет создавать большую силу зажима; работает плавно бесшумно; обеспечивает заданную производительность и точность. Недостатки гидропривода: высокие...
46312. Расчет приспособления на точность 270 KB
  Расчет приспособления на точность. Требуемую точность приспособления можно определить решением размерной цепи системы: заготовка – приспособление – станок – инструмент. При этом выявляется роль приспособления в достижении заданной точности выполняемого на заготовке размера то есть замыкающего звена размерной цепи. Для этого производят деление допуска ограничивающего отклонения от выполняемого размера на части одна из которых выделяется для приспособления.
46313. Расчет размерных цепей 197.5 KB
  При решении обратной задачи по значениям номинальных размеров допусков координат середин их полей предельных отклонений составляющих звеньев определяются те же характеристики замыкающего звена либо при необходимости вычислить погрешность замыкающего звена устанавливаются поле рассеяния координаты его середины или границы отклонений замыкающего звена на основании аналогичных данных для составляющих звеньев. Точность замыкающего звена размерной цепи достигается методами: полной взаимозаменяемости включением в размерную цепь всех...
46314. Контрольные и сборочные приспособления 98.5 KB
  Контрольные и сборочные приспособления. Контрольные приспособления Контроль качества изделий очень важен в современном машиностроении. Контрольные приспособления применяют для проверки заготовок деталей и узлов машины. Общая суммарная погрешность измерения определяется рядом ее составляющих: погрешностью схемы измерения; погрешностью установки контролируемого изделия; погрешностью настройки приспособления по эталону износу деталей приспособления а также колебаниями температуры.
46315. Особенности проектирования приспособлений для станков-автоматов, агрегатных станков и автоматических линий, состоящих из этих станков 58 KB
  Особенности проектирования приспособлений для станковавтоматов агрегатных станков и автоматических линий состоящих из этих станков При полной автоматизации цикла обработки необходима автоматизация приспособления. Требования к автоматическим приспособлениям: особое внимание должно быть обращено на удаление стружки.1 приведена схема пневматического приспособления для сверления отверстия в цилиндрических заготовках с подачей их из магазина. На автоматических линиях применяют два типа приспособлений: стационарные и приспособления – спутники.