Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Армія
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2010
Тип роботи:
Курсова робота
Предмет:
Інженерія програмного забеспечення
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет “Львівська політехніка”
Курсова робота
З дисципліни:
«Програмування, частина 4. Інженерія програмного забезпечення»
На тему
«Армія»
Львів 2010
Зміст
Вступ 3
Завдання 5
1. Вибір життєвого циклу 6
2. Аналіз аналогів 7
3.Моделювання системної архітектури засобами UML
3.1. Аналіз предметної галузі 8
3.2. Розробка архітектури програмного забезпечення 19
4. Тестування програмного забезпечення 18
4.1.Теоретична частина 20
4.2.Тестування "чорної скриньки" 22
4.3.Тестування "білої скриньки" 23
4.4.Перевірка на модель 26
4.5.Тестування на відмову 27
Висновок 28
Список літератури 29
Додаток А
Вступ
При розробці системи для армії була використана уніфікована мова моделювання UML.
Мова UML є інструментом візуального моделювання систем, тому основним за собом її використання вважаються діаграми. Кожна з діаграм віддзеркалює певний аспект системи, а вся множина діаграм - становить структурну основу проекту.
Обєктно-орієнтована методологія опирається на систему діаграм – одиничних описів фрагментів системи. Різні типи діаграм відображають різні аспекти системи. У кожній діаграми є своя мета і своя аудиторія. Моделювання здійснюється як «порівнений спуск» від концептуальної моделі до логічної, а потім до фізичної моделі програмної системи.
В UML інтегровані різноманітні відомі засоби візуального моделювання, які добре зарекомендували себе на практиці, зокрема, забезпечується можливість опису двох визначальних видів об'єктних моделей:
структурних (або статичних) моделей – описується структура сутностей системи, включаючи класи, інтерфейси, відношення, атрибути;
моделей поведінки (або динамічних моделей) – описується поведінка (функціонування) об'єктів системи, включаючи методи, взаємодію, процес зміни станів окремих компонент чи всієї системи.
Надати користувачу засоби візуального моделювання систем різного призначення з акцентацією на можливості їх розробки та отримання документації. (UML містить як абстрактні конструкції для представлення моделей, так і цілком конкретні, які дозволяють описувати деталі реалізації програмних систем).
Забезпечити користувачів засобами розширення та специфікації з метою більш точного опису конкретних предметних областей. (Хоча у більшості випадків для побудови моделей цілком достатньо базових конструкцій UML, все ж в UML уведено механізм розширення базових понять. Крім того, можлива спеціалізація базових понять, шляхом доповнення останніх новими атрибутами чи властивостями).
Підтримувати таку специфікацію моделей, яка, з одного боку, була б незалежною від конкретних мов програмування і, з іншого боку, забезпечувала б потенційні можливості реалізації у таких мовах.
Діаграма UML – це зображення у вигляді графа з вершинами (сутностями) і ребрами (відношеннями).
Основна мета діаграм – візуалізація архітектури розроблюваної системи з різних точок зору.
Діаграма – деякий зріз системи. Звичайно діаграми дають згорнуте представлення елементів, із яких складається розроблювана система. При цьому один і той самий елемент може бути присутнім у декількох (а іноді й в усіх) діаграмах.
При візуальному моделюванні з UML використовуються вісім видів діаграм, кожна з яких може містити елементи певного типу. Типи можливих елементів і Діаграми прецедентів або діаграми використання (use case diagrams). Такі діаграми описують функціональність, яка буде надаватись користувачам системи, котра проектується. Представляються шляхом використання прецедентів та акторів, а також відношень між ними. Набір усіх прецедентів діаграми фактично визначає функціональні вимоги, за допомогою яких може бути сформульоване технічне завдання.
Діаграми класів (class diagrams) описують статичну структуру класів. Дозволяють (на концептуальному рівні) формувати "словник предметної області" та (на рівні специфікацій і рівні реалізацій) визначати структуру класів у програмній реалізації системи. Можуть використовуватись для генерації каркасного програмного коду (в реальній мові програмування).
Для опису динаміки використовуються діаграми поведінки (behavior diagrams), що підрозділяються на
діаграми станів (statechart diagrams);
діаграми діяльності (активності) (activity diagrams);
діаграми взаємодії (interaction diagrams), що у свою чергу підрозділяються на
діаграм послідовності (sequence diagrams);
діаграм кооперації (співробітництва) (collaboration diagrams).
І, нарешті, діаграми реалізації (implementation diagrams) поділяються на
компонентні діаграми· (діаграми компонентів) (component diagrams);
діаграми розгортання· (deployment diagrams).
Спочатку для програмної системи серією діаграм прецедентів визначається її зовнішня функціональність (виділяються всі прецеденти та актори, а також відношення між ними).
Уся подальша робота над проектом має здійснюватись на основі прецедентів: для кожного прецеденту формується опис його динаміки у вигляді серії діаграм взаємодії та діаграм діяльності.
З отриманих описів шляхом виявлення об'єктів, що задіяні в реалізації прецедентів, будуються діаграми класів.
Для визначення поведінки класів із складною динамікою реагування на події можуть формуватись діаграми станів.
Розміщення об'єктів по програмних модулях описується в компонентних діаграмах, а розміщення програмних модулів по вузлах комп'ютерам мережі – у діаграмах розгортання.
Завдання
Розробити модель функціонування системи засобами UML на тему: Армія.
Події в сучасному світі змінюються дуже динамічно. Зростають потоки інформації, яку потрібно якісно і швидко обробляти. До неї завжди має бути вільний доступ і вона має бути організована належним чином. В таких випадках стають недоцільними старі методи її обробка та зберігання. Наприклад якщо є велика база даних і потрібно знайти якийсь елемент, тоді доводиться годинами ритись у ній щоб знайти даний елемент. Тобто картотеки і величезні архіви значно поступаються сучасним методам обробки інформації.
На даний момент в силу технічного розвитку стали популярними електронні бази даних та інші програмні продукти, що обробляють інформацію.
На сьогоднішній день практично всі установи у яких є потреба обробки і зберігання інформації є комп’ютеризовані, що значно спрощую обробку інформації.
Даний програмний продукт що проектується є призначеним для покращення обробки потоків інформації в такій установі як армія. В армії також є немала кількість інформації яку потрібно опрацьовувати. Сюди входить: інформація про солдатів, дані про працівників армії, реєстрація порушень дисципліни, участі в громадських заходах, відвідувачів. Ця програма має в значний мірі пришвидшити інформаційні процеси, що проходять в армії, тобто спростити роботу командира роти, чергового по роті, чергового на КПП-це потрібно зробити в першій частині роботи. Вона має забезпечити швидкий доступ до інформації, яку потрібно знайти.
В другій частині необхідно провести тестування на відмову, структурне тестування (білого ящика), тестування чорного ящика, та перевірку на модель розробленого програмного забезпечення.
1.Вибір життєвого цикл
При розробці системи для військової частини для досягнення оптимального результату найбільш підходяшою є модель життєвого циклу при якій була б можливість повернутися на певний попередній етап розробки при винекненні певних помилок, що дало б можливість швидкого їх виправлення (ітераційна модель). В результаті це б дало можливість як найкраще, і як найшвидше виконати поставлене завдання.
Дану модель можна представити в графічному вигляді таким чином:
Рис.1- Графічне зображення моделі життєвого циклу.
Хоча дана модель не є повінстю досконалою, але вона повністю підходить для вирішення поставленої задачі.
2. Аналіз аналогів
Перед початком розробки системи для армії було досліджено існуючі аналоги, які використовуються в сучасній армії для оптимізації військової служби.
Проаналізувавши існуючі системні рішення було зроблено висновок, що на сьогоднішній день в Україні не існує такої системи, яка б на основі однієї програмної розробки виконувала б всі поставленні завдання. Так в армії для задоволення потреб всіх користувачів використовується ціла низка програмного забезпечення, а в деяких випадках працівники змушені обходитись без нього. Таким чином кожен з них, для здійснення оптимальної роботи повинен розібратися як працює не одна, а одразу декілька програм. А це може бути дещо проблематичним для деяких працівників.
Для ведення обліку солдатів і особового складу в більшості випадків використовується програма Microsoft Office Access, з пакету Microsoft Office, або аналоги, що дозволяють створювати бази даних.
Складання розкладів чергувань і розкладу навчання і досі виконуються спочатку без програмного забезпечення, лише після його повної розробки, він переноситься в електронний вигляд для розповсюдження. Для цього також використовується найрізноманітніше програмне забезпечення.
Для обміну даними з міжнародними організаціями, іншими військовими частинами, та міністерством оборони України, також використовуються різноманітні програмні засоби для обробки електронної пошти.
Система, яка є розроблена під час виконання даного курсового проекту повністю перевершує існуючі програмні рішення і є оптимальною для організації роботи військової частини, адже вона поєднує в одному модулі вирішення всіх поставлених задач.
3.Моделювання системної архітектури засобами UML
3.1. Аналіз предметної галузі
Під час розробки системи для роботи військової частини спочатку було визначено всіх потенційних користувачів даної системи і визначено всі їх вимоги до даної системи. Таким чином серед прецедентів, які мають відношення до військової частини можна виділити:
Солдат
Командир військової частини
Командир роти
Черговий по роті
Черговий по КПП
Бухгалтерія
Секретар
Далі було проаналізовано всі їх вимоги від системи, які можна структуризувати наступним чином:
Рис.2- Ієрархія точок зору усіх користувачів системи.
Для графічного відображення вимог кожного користувача системи було використано уніфіковану мову моделювання UML. За допомою якої було створен діаграми прецедентів, що і відображає їх вимоги.
Командир військової
частини
Рис.3 – Діаграми прецедентів: Командира військової частини (А) і командира роти (Б).
А)
Б)
В)
Рис.4 – Діаграми прецедентів: солдата (А), викладача (Б) і секретаря (В).
А) Б)
Рис.5 – Діаграми прецедентів: Чергового по КПП (А), Чергового по роті(Б)
На першому періоді розробки системи було визначено місце системи в середовищі:
Рис.6. - Структурна схема моделі системного середовища.
При реалізації системи було змоделювано ряд стандартних процесів, які відбуваються в військовій частині, серед яких можна виділити процес прийняття солдата в армію, процес моніторингу порядку, процес формування і проведення військових навчань.
Рис.7 – Модель процесу прийняття солдата в армію .
Рис.8 – Модель процесу моніторингу порядку в військовій частині.
Рис.9- Модель процесу організації військових навчань.
При реалізації даної системи використовується ряд баз даних:
Рота;
Солдат;
Інвентарь;
Військові навчання;
Офіцерський склад.
Кожна база даних зберігає відповідну інформацію, і містить поля за допомогою яких вона звязується з іншими базами даних, що забезпечує можливість реалізації системи.
Для відображення сутності та звязків між базами даних можна використати наступну діаграму:
Рис.10. – Модель сутності баз даних, та звязків між ними.
Вигляд системи з точки зору проектування
В даній системі проектуються такі класи:
Клас Soldeir(солдат) містить атрибути: ім’я, прізвище, домашня адреса, номер казарми, рід військ, строк служби. Використовуються такі методи: встановлення даних про солдата і визначення їх.
Клас Officer(офіцер) містить атрибути: ім’я, прізвище, звання, вік, стаж роботи, домашня адреса. Використовуються методи: визначення даних про офіцера.
Клас Commander_Company(командир роти) наслідує клас Officer(офіцер). Використовуються методи: перекличка роти, командування.
Клас Inventory(інвентар) містить атрибути: номер предмету, кількість предметів. Використовуються методи: видати предмет, зареєструвати предмет.
Рис.11. – Модель проектування класів та звязків між ними, а також методів,які в них використовуються.
3.2. Розробка архітектури програмного забезпечення
Наступним етапом в розробці системи є розробка архітектури програмного забезпечення. На цьому етапі визначається структуру системи, та структуру керування та взаємодії складових сисеми.
Для реалізації структури системи було використано модель системи керування військової частини. Яка забезпечує доступ до потрібної інформації кожному користувачу. Всі дані зберігаються на одному більш-менш потужному компютері, що дозволяє централізувати роботу, і економити при виборі параметрів машин клієнтів, що здешевлює реалізацію системи.
Рис.12. Структура системи для роботи військової частини
Для реалізації системи роботи військової частини було обрано модель , що керується подіями. А саме модель передачі повідомлень.
Рис.13- Модель керування.
4. Тестування програмного забезпечення
4.1. Теоретична частина
Тестування програмного забезпечення - це процес аналізу або експлуатації програмного забезпечення з метою виявлення дефектів.
Тестування передбачає "аналіз" або "експлуатацію" програмного продукту. Тестова діяльність, що пов'язана з аналізом результатів розробки програмного забезпечення, називається статичним тестуванням. Воно передбачає перевірку програмних кодів, контроль та перевірку програми без запуску на комп'ютері. Тестова діяльність, що передбачає експлуатацію програмного продукту, називається динамічним тестуванням. Динамічне та статичне тестування доповнюють одне одного.
Мета розробника полягає в тому, щоб зробити програмний код без дефектів, який відповідає призначенню програмного продукту та відповідає вимогам замовника. Мета тестувальника пов'язана з аналізом коду та експлуатації програми, що у результаті повинно призвести до виявлення дефектів, які проявляються під час його інтегрування, конфігурування та виконання в різних середовищах.
Тестування програмного забезпечення виконує дві базові функції: верифікацію та атестацію. Верифікація забезпечує відповідність результатів конкретної фази процесу розробки вимог даної та попередньої стадії. Атестація є гарантією того, що програмний продукт задовольняє системним вимогам.
Програмний продукт є якісним, коли:
під час роботи користувача з програмним продуктом виникає невелика кількість відмов;
програмний продукт надійний, а це означає, що його використання рідко викликало аварійні відмови;
програмний продукт задовольняє вимогам більшості користувачів.
Процес тестування є дуже важливим при розробці програмного забезпечення. Адже на цьому етапі можна ще до введення в експлуатацію виявити помилки в його роботі. На сьогоднішній день цьому процесу приділяють надзвичайно велику увагу всі розробники, адже він допомагає економити і підтримувати імідж фірми.
Тому розроблено велику кількість методів тестування, серед яких :
Тестування на відмову;
Структурне тестування ("білого ящика");
Тестування "чорного ящика";
Перевірка на модель;
Та інші.
Для тестування розробленого програмного забезпечення в даному курсовому проекті будуть використані саме такі методи тестування.
Будь яке тестування повинно складатися з наступних елементів і процесів, тобто виконуватись за наступною схемою:
Рис. 14 – Схема процесу тестування.
4.2.Тестування "чорної скриньки"
4.3.Тестування "білої скриньки"
4.4.Перевірка на модель
4.5. Тестування на відмову
Висновок
Під час виконання даного курсового проекту було досягнуто основну його мету, тобто було розроблено програмну системи армії.
При проектуванні архітектури системи було використано мову UML. Перевага її в тому що за допомогою діаграм можна представити практично всі основні моделі, які потрібні для розробки системи – при цьому вони є досить зрозумілими для програміста або менеджера проекту. Хоча також є певні недоліки – нема жорсткої стандартизації при розробці певної системи. Це може призвести до того що різними особами окремі моменти на схемі можуть інтерпретуватися по різному. Також відсутність чіткої стандартизації ускладнює вивчення. Але попри все це використання даної мови все ж полегшує процес розробки.
При розробці системи головний акцент робився на автоматизацію процесу роботи армії. Хоча до досконалості ще дуже далеко, оскільки потрібно проводити комплексні дослідження і спостереження, консультуватися у спеціалістів. Тому перед впровадженням потрібно провести детальне тестування.
В процесі виконання другої частини курсового проекту – проведення тестування програмного забезпечення було досліджено як окремі підсистеми так і модуль в цілому на відповідність їх поставлених вимогах. Для цього було розроблено ряд тестів різноманітного характеру. І було визначено, що дана система, яка була розроблена під час виконання курсового проекту є достатньо стабільною у використанні і є дуже спеціалізована і прив’язана до вирішення конкретно поставленого завдання. Хоча вона повністю задовольняє вимоги навчального процесу, адже вона написана відповідно до вимог Венгерської нотації і виконує поставленні завдання.
Список літератури
Орлов С.А., «Технологія розробки програмного забезпечення» Питер., 2002 – 322с
Фаулер М., «UML. Основы, 3-е издание / Пер. с англ.» - СПб.: Символ-плюс, 1999. - 192 с.
Дудзяний І.М., «Обєктно-орієнтоване моделювання програмних систем»- Львів, Видавничий центр ЛНУ ім. Івана Франка, 2007.
Коротун Т.М., «Моделі і методи тестування програмних систем», Київ, 2006.
Андон Ф.И., Коваль Г.И.,Коротун Т.М, Сус лов В.Ю. «Основы инженерии качества программных систем» . – Киев: Академпериодика, 2002. – 504 с.
Додаток А
06.03.2013 23:03-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора