Інформаційна система фільтрації зображень

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

Міністерство освіти і науки України

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

Кафедра біомедичної кібернетики

КУРСОВА РОБОТА

з дисципліни «Управління ІТ-проектами»

за напрямом підготовки 6.050101 «Комп'ютерні науки»

Інформаційна система фільтрації зображень

Київ 2015



Зміст

Вступ

1. Життєвий цикл програмного продукту

2. Технічне завдання

3. IDEF0 методологія

4. IDEF3 методологія

5. UML діаграми

Висновок

Література

програмний інтерфейс інформаційний



Вступ

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

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

· написання технічного завдання;

· побудова функціональної моделі системи IDEF;

· побудова моделі на мові UML, що розглядає процес створення програмного продукту від задуму до виконуваного коду.



1. Життєвий цикл програмного продукту

Для розробки даного програмного продукту була обрана каскадна модель життєвого циклу, оскільки за стандартом ISO/IEC 12207:2008, вимоги до програмного продукту формулюються одразу. ПП не передбачає якихось додаткових напрямків для аналізу, а спрямований в чітко визначене русло - цифрова фільтрація.

Каскадна (або послідовна) модель. Передбачає строго послідовне в часі і однократне виконання всіх фаз проекту з детальним попереднім плануванням і визначеними вимогами [2].

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

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

2. Технічне завдання

1. Короткий опис ідеї розробки

Назва програми «Інформаційна система фільтрації зображень в частотній області».

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

2. Призначення і область застосування

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

3. Вимоги до програми

3.1 Вимоги до функціональних характеристик

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

а) Фільтрація вхідного зображення;

б) Відображення вхідного зображення;

в) Відображення вихідного зображення;

г) Збереження інформації користувача та результатів фільтрації.

д) Відображення Фур'є-образу вхідного зображення

е) Відображення Фур'є-образу вихідного зображення

3.2 Вимоги до надійності

Надійне (стійке) функціонування програми має бути забезпечене виконанням Замовником сукупності організаційно-технічних заходів, перелік яких наведено нижче:

а) організацією безперебійного живлення технічних засобів;

б) використанням ліцензійного ПЗ;

в) регулярним виконанням вимог ГОСТ 3396.0-96 (Державний стандарт України Захист Інформації. Технічний захист інформації. Основні положення).

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

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

3.3 Умови експлуатації

3.3.1 Кліматичні умови експлуатації

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

* температура навколишнього повітря від + 10 ° C до + 35 ° С;

* атмосферний тиск від 630 до 800 мм ртутного стовпа;

* відносна вологість повітря не більше 80%;

* запиленість повітря не більше 0,75 мг / мі;

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

3.3.2 Вимоги до кваліфікації та чисельності персоналу

Мінімальна кількість персоналу, необхідного для роботи програми, має становити не менше 2осіб:

а) лікар (аналіз результуючих даних та прийняття рішення);

б) оператор (обслуговування та підтримка програмної частини, створення резервних копій);

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

До складу технічних засобів повинен входити IВМ-сумісний персональний комп'ютер (ПЕОМ), що виконує роль сервера та має наступні мінімальні характеристики:

а) процесор Pentium-IV 1024 MHz;

б) оперативну пам'ять об'ємом, 256 Мбайт;

в) вільний простір на HDD: 100 МБ;

г) операційна система Windows 2003/2007/ХР/Vista;

д) 86х-розрядний тип системи.

3.5 Вимоги до інформаційної та програмної сумісності

Вимоги до інформаційних структур і методів розв'язання, програмних засобів та захисту інформації:

а) програма реалізується в NI LabVIEW13.0;

б) системні програмні засоби, що використовуються програмою, повинні бути представлені ліцензійною локалізованою версією ОС Windows 2003/2007/ХР/Vista.

в) вимоги до захисту інформації та програм не пред'являються.

3.6 Вимоги до упаковки і маркування

Програма поставляється у вигляді програмного виробу - на зовнішньому накопичувачі (компакт-диску).

3.7 Вимоги до транспортування і зберігання

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

При транспортуванні і зберіганні програмного виробу повинен бути передбачений захист від попадання пилу і атмосферних опадів.

4. Вимоги до програмної документації

4.1 Попередній склад програмної документації

Програмна документація повинна містити:

- титульний аркуш;

- зміст;

- структуру розподілу робіт;

- технічне завдання;

- результати проектування системи;

- проектна структура системи;

- опис процесу реалізації;

- висновки про розроблену систему.

5. Техніко-економічні показники

5.1 Економічні переваги розробки

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

6. Стадії та етапи розробки

6.1 Стадії розробки

Розробка повинна бути здійснена у вісім стадій:

- підготовка технічного завдання;

- попереднє проектування;

- безпосередня розробка програмного продукту;

- проведення тестування ПП;

- розробка та підготовка документації;

- впровадження ПП і його інтеграція з іншими системами;

- супровід і технічна підтримка;

- оформлення курсової роботи.

6.2 Етапи розробки

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

На стадії попереднього проектування мають бути виконані такі етапи робіт:

- постановка задачі;

- збір та аналіз вимог;

- розробка проекту системи;

- розробка структурної схеми програми;

- вибір ЖЦ та технології, їх обґрунтування.

На стадії проектування повинні бути виконані такі етапи робіт:

- дизайн системи та розробка інтерфейсу;

- розробка модулів програми у середовищі NI LabVIEW2013;

- об'єднання модулів в одну програму.

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

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

6.3 Зміст робіт поетапно

На етапі розробки технічного завдання повинні бути виконані такі роботи:

- постановка задачі;

- визначення і уточнення вимог до технічних засобів;

- визначення вимог до програми;

- визначення стадій, етапів і термінів розробки програми і

документації на неї;

- узгодження і затвердження технічного завдання.

На етапі попереднього проектування мають бути виконані такі роботи:

- розробка структурної схеми програми;

- необхідні діаграми.

На етапі проектування програми виконується кодування програми.

На етапі тестування роботи програми виконується перевірка виконання програми для виявлення дефектів в логіці і функціонуванні.

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

3. IDEF0 методологія

IDEF0 -- Function Modeling -- методологія функціонального моделювання і графічного описання процесів, призначена для формалізації і опису бізнес-процесів. Особливістю IDEF0 є її акцент на ієрархічне представлення об'єктів, що значно полегшує розуміння предметної області. В IDEF0 розглядаються логічні зв'язки між роботами, а не послідовність їх виконання в часі [3].

Модель IDEF0 може містити:

· Контекстну діаграму (в кожній моделі може бути лише одна)

· Діаграми декомпозиції

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

· Діаграми експозиції (FEO)

Контекстна діаграма - діаграма, що описує систему в цілому.

Рис. 1. Контекстна діаграма

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

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



Рис. 2. Діаграма декомпозиції I рівня

Головні процеси розробки інформаційної системи фільтрації зображень в частотній області:

1. Створення дизайну та розробка інтерфейсу

2. Розробка модулів

3. Інтеграція модулів

4. Тестування

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



Рис. 3. Діаграма декомпозиції II рівня (декомпозований блок «Створення дизайну та розробка інтерфейсу»)

Дана діаграма є композицією блоку «Створення дизайну та розробка інтерфейсу». Основні процеси:

1. Створення головної форми

2. Оцінювання 1 етап

3. Створення додаткових елементів та піктограм

4. Оцінювання 2 етап

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

Рис. 4. Діаграма декомпозиції II рівня (декомпозований блок «Розробка модулів»)

Дана діаграма є композицією блоку «Розробка модулів». Основні процеси:

1. ReadFile - зчитує вхідне зображення.

2. Two Button Dialog - запитує, який тип фільтра використати і передає прийняте рішення наступному модулю.

3. Filtering Module - виконує фільтрацію.

4. Write Image And Vision Info File 2 - виконує запис в файл. На виході отримуємо файл з результуючим зображенням.

5. WinDraw - візуалізує зображення на екрані.

В якості вхідних даних виступає структурна схема програми, керування процесу здійснюється ТЗ (технічним завданням), в якості механізмів виступають комп'ютер та середовище розробки LabVIEW 2013, на виході одержуємо модулі. Це стосується всіх блоків.

Рис. 5. Діаграма декомпозиції III рівня (декомпозований блок «Filtering Module»)

Дана діаграма є декомпозіцєю «Filtering Module». Основні процеси:

1. ImageToComplexPlane - перетворює зображення в комплексну форму.

2. FFT - здійснює швидке перетворення Фур'є.

3. ComplexAttenuate - здіснює фільтрацію.

4. InverseFFT - здійснює зворотнє перетворення Фур'є.

5. ComplexPlaneToImage - здіснює перетворення зображення в дійсну форму.

В якості вхідних даних виступає структурна схема програми, керування процесу здійснюється ТЗ (технічним завданням), в якості механізмів виступають комп'ютер та середовище розробки LabVIEW 2013, на виході одержуємо модулі. Це стосується всіх блоків. Також на вхід «ImageToComplexPlane» подається вхідне зображення, а в якості керуючого механізму для «ComplexAttenuate» додатково виступає рішення про вибір типу фільтра.

Діаграми дерева вузлів - діаграма, що описує ієрархічну структуру моделі інформаційної системи.

Рис. 6. Діаграма дерева вузлів

4. IDEF3 методологія

IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) - методологія моделювання та стандарт документування процесів, що відбуваються в системі. Метод документування технологічних процесів являє собою механізм документування та збору інформації про процеси. IDEF3 показує причинно-наслідкові зв'язки між ситуаціями і подіями в зрозумілій експерту формі, використовуючи структурний метод вираження знань про те, як функціонує система, процес або підприємство [3].



Рис. 7. IDEF3 «Тестування»

Основні процеси:

1. Підготовчі роботи

2. Тестування ІС

a. Функціональне тестування

b. Usability тестування

c. Тестування безпеки

d. Тестування продуктивності

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



5. UML діаграми

1. Use Case

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

Рис. 8. Use Case Diagramm

В результаті аналізу були виділені такі актори: «Лікар» та «Оператор». Обидва актори можуть виконувати одні і ті ж самі операції за умови відповідної попередньої підготовки.

Операції:

1. Завантаження зображення.

2. Вибір типу фільтра.

3. Процес фільтрації.

4. Вивід зображень на екран.

5. Збереження результату.

2. Statechart Diagramm

Statechart Diagramm або Діаграма станів відображає скінчений автомат у вигляді графу, вершинами якого є стани об'єкта, поведінка якого моделюється, а переходами - події, які переводять об'єкт, який розглядається, з одного стану в інший. При цьому вважається, що час перебування об'єкта в певному стані набагато більший за час, необхідний для переходу з одного стану в інший, тобто переходи між станами здійснюються миттєво [5]. Спочатку вводиться шлях до файлу з вхідним зображенням та шлях файлу збереження. Потім відбувається передача шляху на перевірку. Якщо шлях/файл не існує, то відбувається повернення до попередньої дії, користувачу пропонується заново ввести шлях до файлу. Якщо ж шлях/файл існує - відбувається зчитування вхідного зображення, збереження його в пам'яті та вивід на екран. Далі користувачу пропонується обрати тип фільтра. Зчитане зображення перетворюється в комплексну форму, проходить перетворення Фур'є, та виводиться на екран (Фур'є-образ зображення). Потім перетворене зображення фільтрується згідно з обраним типом фільтра, і на екран виводиться Фур'є-образ зображення з накладеним фільтром. Після цього відфільтроване зображення проходить зворотнє перетворення Фур'є. Дійсна форма зображення виводиться на екран та зберігається у файл, вказаний на початку.

3. Class Diagramm

Class Diagramm або Діаграма класів - головний тип діаграм UML, які відображають логічну структуру програмної системи та суттєво впливають на процес генерації програмного коду. Основними елементами діаграми класів є безпосередньо класи (classes) та відношення між ними (relations).

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

Рис. 9. Class Diagramm

На рисунку наведено діаграму класів системи. Класи пов'язані між собою в основному наслідуванням. Клас ComplexAttenuate залежить від класу Two Button Dialog.

4. Activity Diagramm

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

Спочатку обирається файл з вхідним зображенням та файл збереження. Потім відбувається перевірка шляху до файлу вхідного зображення. Якщо шлях/файл не існує, то користувачу пропонується заново ввести шлях до файлу. Якщо ж шлях/файл існує - відбувається зчитування вхідного зображення, збереження його в пам'яті та вивід на екран. Зчитане зображення перетворюється в комплексну форму, проходить перетворення Фур'є, та виводиться на екран (Фур'є-образ зображення). Вибір типу фільтра відбувається наступним чином: за замовчування користувачу пропонується обрати тип фільтра ФВЧ (фільтр верхніх частот). Якщо користувач погоджується - відбувається фільтрація. Якщо користувач не погоджується, йому пропонується обрати тип фільтра ФНЧ (фільтр нижніх частот). Якщо користувач погоджується - відбувається фільтрація. Якщо користувач не погоджується - знову пропонується ФВЧ і т.д. В разі натиснення «Отмена» користувач може відмінити операцію.

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



Рис. 10. Activity Diagramm



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

5. Sequence Diagramm

Sequence Diagramm або Діаграма послідовності -- діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень в часовій шкалі [4]. На діаграмі послідовностей показано у вигляді вертикальних ліній різні процеси або об'єкти, що існують водночас. Надіслані повідомлення зображуються у вигляді горизонтальних ліній, в порядку відправлення.

Користувач вводить шлях до файлів вхідного зображення, збереження зображення та обирає тип фільтра. Об'єкт ReadFile приймає шлях до файлу, зчитує зображення, передає зображення об'єкту WinDraw, та передає зображення об'єкту ImageToComplexPlane. Об'єкт ImageToComplexPlane приймає зображення, перетворює його в комплексну форму та передає комплексну форму об'єкту FFT. Об'єкт FFT приймає комплексну форму зображення, перетворює, передає Фур'є-образ об'єктам WinDraw та ComplexAttenuate. Об'єкт Two Button Dialog робить запит на тип фільтра, приймає рішення про обраний тип від користувача та передає прийняте рішення об'єкту ComplexAttenuate. Об'єкт ComplexAttenuate приймає Фур'є-образ зображення, рішення про тип фільтра, фільтрує зображення та передає Фур'є-образ з накладеним фільтром об'єктам WinDraw та InverseFFT. Об'єкт InverseFFT приймає відфільтроване зображення, виконує зворотнє перетворення Фур'є та передає перетворене зображення об'єкту CompexPlaneToImage. Об'єкт CompexPlaneToImage приймає перетворене зображення, перетворює його в дійсну форму та передає об'єкту Write Image And Vision Info File 2. Об'єкт Write Image And Vision Info File 2 приймає дійсну форму зображення, записує в файл та передає об'єкту WinDraw. Об'єкт WinDraw візуалізує зображення на екрані.

6. Collaboration Diagramm

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

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

7. Component Diagramm

Component Diagramm або Діаграма компонентів відображає фізичне представлення програмної системи у вигляді сукупності елементів, які називають компонентами (components) [5].

Рис. 11. Component Diagramm

Інформаційна система представлена у вигляді виконуваного файлу Filter.exe. Filter.exe створений на основі головного модуля Main.vi. Main.vi включає підмодулі:

1. TwoButtonDialog.vi

2. WinDraw.vi

3. ReadFile.vi

4. FFT.vi

5. ImageToComplexPlane.vi

6. ComplexPlaneToImage.vi

7. InverseFFT.vi

8. WriteImageAndVisionInfoFile2.vi

9. ComplexAttenuate.vi

ReadFile.vi включає Db_input.

WinDraw.vi включає Db_output.



Висновок

В ході даної курсової роботи було поставлено ряд завдань і всі вони були виконані, а саме:

- Розроблено технічне завдання (ТЗ) згідно ГОСТ 19.106-78.

- Побудовані діаграми контекстна та декомпозиції IDEF0, IDEF3 та основні діаграми UML.

Згідно з ГОСТ 34.602-89 ТЗ є основним документом, що визначає вимоги і порядок створення (розвитку або модернізації) інформаційної системи, відповідно до якого проводиться її розробка і приймання при введенні в дію.

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



Література

1. Станислав Черемных, И. Семенов, В. Ручкин Моделирование и анализ систем. IDEF-технологии: практикум - Москва: Финансы и статистика ISBN 5-279-02564-Х; 2006.

2. Джим Арлоу, Айла Нейштадт UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование - Санкт-Петербург: Символ-Плюс, 2007.

3. Хассан Гома UML-проектирование систем реального времени параллельных и распределенных приложений - Москва: ДМК Пресс, 2011.

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