Проектування системи масового обслуговування

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

Зміст

Вступ

1. Результати обстеження предметної області

1.1 Попередня інформація

1.1.1 Цілі проекту

1.1.2 Користувачі системи

1.2 Бачення виконання проекту та його границі

1.3 Звіт про обстеження

1.3.1 Аналіз існуючого рівня автоматизації

1.3.2 Загальні вимоги до ІС

2. Задачі автоматизації

3. Вимоги до апаратної складової системи

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

4.1 Коротка характеристика методів та засобів

4.2 Функціональна модель системи

4.3 Модель потоків даних

4.4 Модель взаємодії потоків даних

4.5 Діаграма дерева вузлів

4.6 Постановка задачі

4.6.1 Завдання

5. Методи та засоби об'єктно-орієнтованого аналізу і проектування

5.1 Коротка характеристика засобів

5.2 Модель досліджуваної системи

5.2.1 Діаграми бізнес-варіантів використання (можливо декілька представлень)

5.2.2 Діаграми діяльності (activity diagram) для бізнес-варіантів використання

5.2.3 Діаграми станів для об'єктів системи

5.2.4 Діаграми послідовності (Sequence diagram) для бізнес-варіантів використання

5.2.5 Діаграми класів(можливо діаграми класів та діаграма пакетів) системи

5.2.6 Фізичні діаграми(компонентів та розгортання)

6. Реалізація

6.1 Коротка характеристика вибраного засобу автоматизації

6.2 Інтерфейси введення та виведення даних

Список літератури

Додатки



Вступ

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

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



1. Результати обстеження предметної області

автоматизація проектування бізнес інтерфейс

1.1 Попередня інформація

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

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

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

черги виробів кожного типу, що надходять на конвеєр;

час роботи конвеєра;

кількість «холостих» ходів;

час складання виробу кінцевого продукту.

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

1.1.1 Цілі проекту

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

1.1.2 Користувачі системи

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



1.2 Бачення виконання проекту та його границі

Цей проект я проектуватиму у Visual Studio, яке включає інтегроване середовище розробки програмного забезпечення та ряд інших інструментальних засобів. При об'єктно-орієнтованому проектування буду використовувати Rational Rose, він дозволяє моделювати системи до написання коду, так що ви можете з самого початку бути впевнені в адекватності їх архітектури. За допомогою готової моделі недоліки проекту легко виявити на стадії, коли їх виправлення не вимагає ще значних витрат. А перевіряти свої результати планую через програму GPSS World, яка призначена для імітаційного моделювання систем з дискретними і безперервними процесами.

1.3 Звіт про обстеження

1.3.1 Аналіз існуючого рівня автоматизації

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

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

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

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

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

1.3.2 Загальні вимоги до ІС

Інформаційна система повинна відповідати вимогам гнучкості, надійності, ефективності та безпеки.

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

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

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

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

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

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

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

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

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

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

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

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



2. Задачі автоматизації

Таблиця 1 - Задачі автоматизації

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



3. Вимоги до апаратної складової системи

Проектування системи виконувалося на комп'ютері з такими параметрами:

Процесор: Intel® Core™ i7-470MQ @ 2.40 ГГц

Оперативна пам'ять: 8.00 ГБ

Відеоадаптер: NVIDIA GeForce GTX 760

Пам'ять:1 Тб

Тип системи: 64 - розрядна операційна система



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

4.1 Коротка характеристика методів та засобів

У структурному аналізі і проектуванні використовуються різні моделі, які описують:

Функціональну структуру системи;

Послідовність виконуваних дій;

Передачу інформації між функціональними процесами;

Відносини між даними.

4.2 Функціональна модель системи

IDEF0 (Integration Definitionfor Function Modeling) - методологія функціонального моделювання для опису функцій підприємства, що пропонує мову функціонального моделювання для аналізу, розробки, реінжинірингу і інтеграції інформаційних систем бізнес процесів; або аналізу інженерії розробки ПО. Методологія IDEF0 є розвитком методу структурного аналізу і проектування SADT (Structured Analysis and Design Technique).

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

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

Цілі стандарту IDEF0 :

задокументувати і пояснити техніку моделювання IDEF0 і правила її використання;

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

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

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

загальний - для аналізу систем і предметних областей;

строгий і точний - для створення коректних, придатних до використання моделей);

короткий - для полегшення розуміння, комунікації, згоди між зацікавленими особами та перевірки;

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

гнучкий - для підтримки різних фаз життєвого циклу проекту.

4.3 Модель потоків даних

Діаграми потоків даних (Data Flow Diagrams - DFD) є ієрархію функціональних процесів, пов'язаних потоками даних. Мета такого подання - продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити відносини між цими процесами. Для побудови DFD традиційно використовуються дві різні нотації, які відповідають методам Йордона - ДеМарко і Гейне-Серсона. Ці нотації незначно відрізняються один від одного графічним зображенням символів. Відповідно до даних методами модель системи визначається як ієрархія діаграм потоків даних, описують асинхронний процес перетворення інформації від її введення в систему до видачі споживачеві. Практично будь-який клас систем успішно моделюється за допомогою DFD-орієнтованих методів. Вони з самого початку створювалися як засіб проектування інформаційних систем (тоді як SADT -як засіб моделювання систем взагалі) і мають більш багатий набір елементів, які адекватно відображають специфіку таких систем.

4.4 Модель взаємодії потоків даних

Метод моделювання IDEF3, який є частиною сімейства стандартів IDEF, був розроблений в кінці 1980-х років для закритого проекту ВВС США. Цей метод призначений для таких моделей процесів, в яких важливо зрозуміти послідовність виконання дій і взаємозалежності між ними. Хоча IDEF3 і не досяг статусу федерального стандарту США, він набув широкого поширення серед системних аналітиків як доповнення до методу функціонального моделювання IDEF0 (моделі IDEF3 можуть використовуватися для деталізації функціональних блоків IDEF0, що не мають діаграм декомпозиції). Основою моделі IDEF3 служить так званий сценарій процесу, який виділяє послідовність дій і підпроцесів аналізованої системи.

4.5 Діаграма дерева вузлів

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

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

4.6 Постановка задачі

4.6.1 Завдання

На комплектувальних конвеєр складального цеху кожні 5 ± 1 хв надходять 5 виробів першого типу і кожні 20 ± 7 хв надходять 20 деталей другого типу. Конвеєр складається з секцій, що вміщають по 10 виробів кожного типу. Комплектація починається тільки при наявності деталей обох типів в необхідній кількості і триває 10 хв. При нестачі деталей секція конвеєра залишається порожньою.

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

Призначення.

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

Мета.

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

Зв'язки.

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

Технічні засоби.

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

Періодичність використання.

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

Вхідні дані.

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

Вихідні дані.

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

Малюнок 1 Алгоритм імітаційної моделі

ОДЗ.

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

Тестові варіанти.

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



5. Методи та засоби об'єктно-орієнтованого аналізу і проектування

5.1 Коротка характеристика засобів

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

5.2 Модель досліджуваної системи

5.2.1 Модель дослідження системи - це є об'єктно-орієнтована модель

Діаграми бізнес-варіантів використання (можливо декілька представлень).

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

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

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

Варіант використання (use case) служить для опису сервісів, що система надає актору. Іншими словами, кожен варіант використання визначає деякий набір дій, чинений системою при діалозі з актором. При цьому нічого не говориться про те, яким чином буде реалізована взаємодія акторів із системою.

5.2.2 Діаграми діяльності (activity diagram) для бізнес-варіантів використання

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

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

5.2.3 Діаграми станів для об'єктів системи

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

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

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

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

5.2.4 Діаграми послідовності (Sequence diagram) для бізнес-варіантів використання

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

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

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

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

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

5.2.5 Діаграми класів(можливо діаграми класів та діаграма пакетів) системи

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

Діаграма класів є граф, вершинами якого є елементи типу «класифікатор», пов'язані різними типами структурних відносин.

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

На даній діаграмі не вказується інформація про тимчасові аспекти функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи.

5.2.6 Фізичні діаграми(компонентів та розгортання)

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

Діаграма розгортання в UML моделює фізичне розгортання артефактів на вузлах.

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

Існує два типи вузлів:

Вузол пристрою;

Вузол середовища виконання.

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

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



6. Реалізація

6.1 Коротка характеристика вибраного засобу автоматизації

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

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

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

Блоки і транзакти - це тільки два з багатьох типів об'єктів системи GPSS WORLD. У загальному випадку, коли транзакт входить в блок, то проводиться деяка операція над третім об'єктом. Наприклад, вхід транзакта в блок SEIZE змушує транзакт зайняти об'єкт системи GPSS WORLD, званий пристроєм. Цей тип об'єктів зазвичай використовується для представлення окремих ресурсів модельованих компонент.

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



6.2 Інтерфейси введення та виведення даних

Моделюючі в GPSS World за допомогою команд на мові GPSS я вибудував імітаційну модель задля вирішення поставленої задачі, приклад коду: FF1 STORAGE 10

FF2 STORAGE 10

TOC1 GENERATE 5,1

SPLIT 4

QUEUE QUE1

ENTER FF1

DEPART QUE1

TEST E QUE1,10,TOC3

LEAVE FF1,10

TERMINATE 9

TOC2 GENERATE 20,7

SPLIT 19

QUEUE QUE2

ENTER FF2

DEPART QUE2

TEST E QUE2,10,TOC3

LEAVE FF2,10

TERMINATE 9

TOC3 SEIZE KAN

ADVANCE 10

SAVEVALUE 1+,1

RELEASE KAN

TERMINATE

GENERATE 480

TERMINATE 1

START 1 

Висновки

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

Проаналізуючи звіт програмних додатків, в яких реалізував імітаційну модель на мові GPSS та Сі-шарп, деякі мої параметри збіглися, де які ні. Обидва звіти затвердили, що у середньому кінцевих продуктів буде виготовлюватися 40 одиниць. А ось інакше: звіт від GPSS World каже, що ефективнішою буде не початкові параметри, а ті що нам дають для визначення ефективності. Завдяки цьому я набув досвіду в проектування подібних моделей та аналізу їх.



Список літератури

1. ГОСТ 19.701 - 90 ЕСПД. Схемы алгоритмов, программ, данных и систем

2. Буч, Гради. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд. - М.: «Издательство Бином», СПб.: «Невский диалект», 1999 г.

3. Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник. - СПб.: Питер, 2002 г.

4. Кратчен, Филипп. Введение в Rational Unified Process, 2-е издание. - М.: «Вильямс», 2002 г.

5. Фаулер М. Рефакторинг: улучшение существующего кода. - СПб.: «Символ-Плюс», 2002 г.

6. Рамбо Дж., Якобсон А., Буч Г. Унифицированный процесс разработки программного обеспечения. - СПб.: Питер, 2002 г.

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

8. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. М.,СИНТЕГ, 2000

9. Калянов Г.Н. Структурный системный анализ. М., Лори, 1996

10. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., Финансы и статистика, 2000.

11. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, 2003



Додаток А

Малюнок 2 Звіт GPSS World



Додаток Б

Малюнок 3 Діаграма класів

Малюнок 4 Діаграма послідовності

Малюнок 5 Діаграма варіантів

Малюнок 6 Діаграма станів



Малюнок 7 Діаграма компонентів

Малюнок 8 Діаграма розгортання



Додаток В

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

namespace ConsoleApplication1

{

class ClassConveyor

{

private

int timeHours, needGoodsToCompilation; byte timeCompilation; //условие

int sectionOne, sectionTwo, assembledDetails, emptySectionOne, emptySectionTwo, emptyConveyor, emptyError; //

ClassProduct first = new ClassProduct(), second = new ClassProduct();

//timeFirstStep = 5, timeSecondStep = 20, rangeFirstStep = 1, rangeSecondStep = 7

public ClassConveyor() //консттруктор

{

timeHours = 8;

timeCompilation = 10;

needGoodsToCompilation = 10;

}

private void Compilation()

{

ClassProduct first = new ClassProduct(5, 5, 1);

ClassProduct second = new ClassProduct(20, 20, 7);

bool busy = false; //занятость конвейера

byte counterBusy=0; //счетчик занятости конвейера

assembledDetails = 0; //собранно деталей

sectionOne = 0; sectionTwo = 0; //накопитель изделий перед сборкой

emptySectionOne = 0; emptySectionTwo = 0; emptyConveyor = 0; emptyError = 0; //счетчик простоя

int counterBusyFirst = first.TimeToSupply(), counterBusySecond = second.TimeToSupply();//время поступления изделий 1и2 типа

for (int i = 0; i < timeHours * 60; i++)//время

{

if (counterBusyFirst > 0)//поступает изделий 1 типа

{

counterBusyFirst--;

if(counterBusyFirst == 0)

{

sectionOne += first.ProductGet();

counterBusyFirst = first.TimeToSupply();

}

}

if (counterBusySecond > 0)//поступает изделий 2 типа

{

counterBusySecond--;

if (counterBusySecond == 0)

{

sectionTwo += second.ProductGet();

counterBusySecond = second.TimeToSupply();

}

}

if (sectionOne >= needGoodsToCompilation && sectionTwo >= needGoodsToCompilation && busy==false)

{

busy = true; counterBusy = timeCompilation;

sectionOne -= needGoodsToCompilation;

sectionTwo -= needGoodsToCompilation;

}

if (busy == false && sectionOne < needGoodsToCompilation) emptySectionOne++;

if (busy == false && sectionTwo < needGoodsToCompilation) emptySectionTwo++;

if (busy == false && sectionOne > needGoodsToCompilation && sectionTwo > needGoodsToCompilation) emptyError++;

if (busy == false) emptyConveyor++;

if (busy && counterBusy != 0)

{

counterBusy--;

if (counterBusy == 0)

{

busy = false;

assembledDetails++;

}

}

}

}

private void Result(int x, double y, double a, double b)

{

Console.Clear();

Console.Write("Зроблених деталей = "); Console.WriteLine(x);

Console.WriteLine("Вiдсоток простою конвеєра = {0:f3}", y,"%");

Console.WriteLine("Вiдсоток простою конвеєра через секцiї № 1 = {0:f3}", a,"%");

Console.WriteLine("Вiдсоток простою конвеєра через секцiї № 2 = {0:f3}", b,"%");

}

public void Analysis()

{

int averageAssembledDetails = 0, quantity = 10000;

double averageEmptyConveyor = 0, averageEmptySectionOne = 0, averageEmptySectionTwo = 0;

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

{

this.Compilation();

averageAssembledDetails += this.assembledDetails;

averageEmptyConveyor += ((Convert.ToDouble(this.emptyConveyor)*100)/(Convert.ToDouble(timeHours)*60));

averageEmptySectionOne += ((Convert.ToDouble(this.emptySectionOne) * 100) / (Convert.ToDouble(timeHours) * 60));

averageEmptySectionTwo += ((Convert.ToDouble(this.emptySectionTwo) * 100) / (Convert.ToDouble(timeHours) * 60));

}

averageAssembledDetails /= quantity;

averageEmptyConveyor /= quantity;

averageEmptySectionOne /= quantity;

averageEmptySectionTwo /= quantity;

Result(averageAssembledDetails, averageEmptyConveyor, averageEmptySectionOne, averageEmptySectionTwo);

}

}

class ClassProduct

{

private int product, timeStep, rangeTime;

public ClassProduct() { }

public ClassProduct(int c,int t,int r)

{

product = c;

timeStep = t;

rangeTime = r;

}

public int TimeToSupply()

{

Random r= new Random();

if (r.Next(2) == 0) return timeStep + r.Next(rangeTime + 1);

else return timeStep - r.Next(rangeTime + 1);

}

public int ProductGet()

{

return product;

}

}

class Program

{

static void Main(string[] args)

{

ClassConveyor x = new ClassConveyor();

x.Analysis();

Console.ReadKey();

}

}

}



Додаток Г

Малюнок 9 Консоль з аналізом програми

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

...