Розробка програмного забезпечення: Система електронної черги для Державної Податкової Інспекції

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык украинский
Дата добавления 02.12.2015
Размер файла 508,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

АНОТАЦІЯ

В даній роботі розробляється програмне забезпечення за темою: «Розробка програмного забезпечення Система електронної черги для Державної податкової інспекції», призначене для роботи з електронною чергою документів на мобільному пристрої з ОС Android.

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

Android-додаток реалізовано в середовищі програмування Intellij IDEA.

Робота виконана на 76 сторінках машинописного тексту, містить 12 рисунків, 14 таблиць, 4 додатки та список використаних джерел з 7 найменувань.

Роботу викладено українською мовою.

АННОТАЦИЯ

В данной работе разрабатывается программное обеспечение по теме: «Разработка программного обеспечения Система электронной очереди для Государственной налоговой инспекции», предназначенное для работы с электронной очередью документов на мобильном устройстве из ОС Android.

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

Android-приложение реализовано в среде программирования Intellij IDEA.

Работа выполнена на 76 страницах машинописного текста, содержит 12 рисунков, 14 таблиц, 4 приложения и список использованных источников из 7 наименований.

Работа изложена на украинском языке.

ABSTRACT

In this work software is developed on the theme "An electronic queue for the State тax inspectorate". Designed to work with the electronic-queue documents on your mobile device from Android OS. The work contains a description and analysis of necessary process data encryption, a draft software section of the technical requirements for the development of software, code text, user manual.

Android-application is implemented in a programming environment Intellij IDEA.

Work done on 76 pages of typewritten text, contains 12 draws, 14 tables, 4 applications and a list of references from 7 names.

Work done in Ukrainian language.

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, ОДИНИЦЬ І ТЕРМІНІВ

1. ПЗ - програмне забезпечення.

2. UML - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення.

3. ІС - інформаційна система.

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

5. ОС - операційна система.

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

ВСТУП

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

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

Основними функціями такого ПЗ будуть: перегляд та керування власними документами; зміна опцій (атрибутів) документа; також застосована ідентифікація.

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

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

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

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

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

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

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

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

Додатки будуть містити технічне завдання, текст ПЗ, а також інструкцію користувача.

1. ОПИС ДІЯЛЬНОСТІ ДЕРЖАВНОЇ ПОДАТКОВОЇ ІНСПЕКЦІЇ ТА ПОСТАНОВКА ЗАДАЧІ ДЛЯ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

мобільний платформа екранний форма

1.1 Опис діяльності Державної Податкової Інспекції

Державна податкова інспекція відноситься до системи органів державної податкової служби України. До системи органів державної податкової служби належать:

· державна податкова адміністрація України;

· державні податкові адміністрації в Автономній Республіці Крим,

· державні податкові адміністрації в областях,

· державні податкові адміністрації в містах Києві та Севастополі,

· державні податкові інспекції в районах,

· державні податкові адміністрації в містах (крім міст Києва та Севастополя),

· державні податкові адміністрації в районах у містах (органи державної податкової служби).

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

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

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

Структура Державної податкової адміністрації України затверджується Кабінетом Міністрів України.

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

Завданнями органів державної податкової служби є:

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

· внесення у встановленому порядку пропозицій щодо вдосконалення податкового законодавства;

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

· формування та ведення Державного реєстру фізичних осіб - платників податків та інших обов'язкових платежів та Єдиного банку даних про платників податків - юридичних осіб;

· роз'яснення законодавства з питань оподаткування серед платників податків;

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

Призначення керівників органів державної податкової служби:

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

· Заступники Голови Державної податкової адміністрації України призначаються на посаду і звільняються з посади Кабінетом Міністрів України за поданням Голови Державної податкової адміністрації України. Кількість заступників Голови Державної податкової адміністрації України визначається Кабінетом Міністрів України.

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

· Державні податкові інспекції в районах, містах (крім міст Києва та Севастополя), районах у містах, міжрайонні та об'єднані державні податкові інспекції очолюють начальники, які призначаються на посаду і звільняються з посади Головою Державної податкової адміністрації України за поданням голів відповідних державних податкових адміністрацій в Автономній Республіці Крим, областях, містах Києві та Севастополі.

· Начальники управлінь податкової міліції призначаються Головою Державної податкової адміністрації України".

Статус органів державної податкової служби.

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

Державна податкова інспекція у районах міст виконує такі функції:

· здійснює контроль за додержанням законодавства про податки, інші платежі;

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

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

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

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

· здійснює контроль за погашенням векселів;

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

· забезпечує застосування та своєчасне стягнення сум фінансових санкцій, передбачених Законодавчими актами України за порушення податкового законодавства, а також стягнення адміністративних штрафів за порушення податкового законодавства, допущені посадовими особами підприємств, установ, організацій та громадянами;

· аналізує причини і оцінює дані про факти порушень податкового законодавства;

· проводить перевірки фактів приховування і заниження сум податків, інших платежів;

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

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

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

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

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

· подає відповідним фінансовим органам та органам Державного казначейства України звіт про надходження податків, інших платежів;

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

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

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

Державні податкові інспекції у районах, містах (крім міст Києва та Севастополя), районах у містах, міжрайонні та об'єднані державні податкові інспекції підпорядковуються відповідним державним податковим адміністраціям в Автономній Республіці Крим, областях, містах Києві та Севастополі.

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

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

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

1.1.1 Вибір цільової мобільної платформи

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

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

- Windows Phone (ОС від компанії Microsoft; 3% ринку);

- Android (ОС від компанії Google; 77% ринку)

- Bada (ОС від компанії Samsung; <1% ринку)

- TizenOS (ОС від компанії Samsung; <0.1% ринку)

- Symbian (не підтримується з 2012 року компанією Nokia)

- iOS (ОС від компанії Apple; 17% ринку)

- BlackBerry (ОС від компанії BlackBerry; 1,3% ринку)

- Maemo / MeeGo (спільна розробка Nokia та Intel; <1% ринку)

- Ubuntu Touch (ОС від компанії Canonical Ltd; <0.1% ринку)

Отже, згідно аналізу мобільних операційних систем, найбільшої популярності набрала саме ОС від розробників всесвітньо відомої компанії Google - Android. Вона є зручною у користуванні, має вільні SDK (набір із засобів розробки, утиліт і документації, який дозволяє програмістам створювати прикладні програми за визначеною технологією або для певної платформи (програмної або програмно-апаратної)), має підтримку нестандартного обладнання (відеокамери, фотоопарати, сенсорні екрани, GPS, компаси, акселерометри).

1.2 Аналіз існуючих рішень систем електронної черги для Державної податкової інспекції

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

- Податкова звітність (OPZ) - програмний пакет, за допомогою якого можна керувати порядком роботи по формуванню податкової звітності в електронному вигляді. ОПЗ-програмне забезпечення по формуванню та подачі платниками податків податкової звітності та реєстру отриманих та виданих податкових накладних до органів ДПС в електронному вигляді засобами телекомунікаційного зв'язку. Переваги: за допомогою вищеназваного програмного пакету, можна працювати з електронною чергою документів, але лише за допомогою комп'ютерів. Недоліки: відсутність підтримки ОС Android або iOS для віддаленої роботи з документами у разі крайньої необхідності [2].

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

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

1.3 Постановка задачі для розробки програмного забезпечення

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

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

1) Відображення списку документів з БД.

Вхідні дані:

- Текст документу.

2) Завантаження документів.

Вхідні дані:

- Текст документу;

- Завантаження документу (вибір: так/ні).

3) Заповнення документу.

Вхідні дані:

- Текст документу;

- Заповнення документу (вибір: так/ні).

Збереження змін.

Вхідні дані:

- Текст документу;

- Завантаження документу (так/ні);

- Заповнення документу (так/ні);

- Віднести документи за місцем проживання (так/ні).

Авторизація (як ступінь захисту).

Вхідні дані:

- Код паспорту;

- Серія паспорту.

Вимоги до організації вхідних і вихідних даних

Вимоги до організації вхідних даних

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

Вимоги до організації вихідних даних

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

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

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

- Процессор з архітектурою ARM V6 та тактовою частотою не менше 600 МГц;

- Не менше 150 Мб оперативної пам'яті;

- Роздільна здатність екрана не менша за 320х480 (VGA і вище);

- 5 Мб вільного простору.

Вимоги до програмної сумісності: ОС Google Android версії 2.3 та вище.

Для функціонування програми не потрібно жодного стороннього програмного забезпечення (на ОС Android).

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

Більш докладно дану інформацію викладено в Додатку А - Технічне завдання.

2. ПРОЕКТ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ЕЛЕКТРОННОЇ ЧЕРГИ ДЛЯ ДЕРЖАВНОЇ ПОДАТКОВОЇ ІНСПЕКЦІЇ

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

2.1 Ескізний проект програмного забезпечення, що працює на платформі Android для роботи з електронною чергою

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

2.1.1 Вибір засобів моделювання

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

Найбільш відомими візуальними моделями, використовуваними для проектування комп'ютерних систем і їхніх програмних забезпечень, є діаграми мови UML (Unified Modeling Language) і стандарту IDEF0, таблиці й діаграми стандарту IDEF1X. Ці візуальні моделі мають математичну основу у вигляді теорій графів, множин і матриць. На Рисунку 3.1 показано, чим відрізняється проектування з використанням UML від старих методів проектування.

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

Рисунок 2.1 - Схеми технологій програмування

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

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

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

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

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

Отже, для проектування розроблюваного ПЗ доцільно буде використати технологію SADT та мову UML. В якості середовища моделювання буде використаний найбільш відомий у світі CASE-засіб - пакет Rational Rose.

2.1.2 Виявлення акторів програмного забезпечення

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

Таблиця 2.1 - Виявлення акторів розроблюваного ПЗ

Актор

Короткий опис

Користувач

Особа, котра керує документами та їх атрибутами за допомогою мобільного пристрою з ОС Android.

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

Таблиця 2.2 - Виявлені варіанти використання

Основний актор

Найменування

Формулювання

1

2

3

Користувач

Авторизація

Цей варіант використання дозволяє користувачеві за допомогою даних авторизації підтвердити власний вхід до системи

Користувач

Вибір документу

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

Користувач

Вибір опцій документу

Цей варіант використання дозволяє користувачеві обирати опції документу для подальшої роботи з ними (завантаження документу; заповнення документу; віднесення документу за місцем проживання)

2.1.3 Функціональний аналіз програмного забезпечення

Аналіз варіантів виявив наступні взаємозв'язки за якими побудовано діаграму варіантів використання (рис. 2.2).

Рисунок 2.2 - Діаграма варіантів використання ПЗ

2.1.4 Аналіз вимог до програмного забезпечення

Реєстр варіантів використання

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

Таблиця 2.3 - Реєстр варіантів використання

Код

Основний актор

Найменування

Формулювання

М1

Користувач

Авторизація

Цей варіант використання дозволяє користувачу за допомогою даних авторизації підтвердити власний вхід до системи

М2

Користувач

Вибір документу

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

М3

Користувач

Вибір опцій документу

Цей варіант використання дозволяє користувачу обирати опції документу для подальшої роботи з ними (завантаження документу; заповнення документу; віднесення документу за місцем проживання)

Конкретизація варіантів використання

М1 Авторизація

Таблиця 2.4 - Варіант використання «Авторизація»

М1

Користувач

Авторизація

Цей варіант використання дозволяє користувачу за допомогою даних авторизації підтвердити власний вхід до системи

Основне діюче лице: Користувач

Інші учасники прецеденту: відсутні

Зв'язки з іншими варіантами використання: відсутні

Короткий опис

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

М2 Вибір документу

Таблиця 2.5 - Варіант використання «Вибір документу»

М2

Корисутвач

Вибір документу

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

Основне діюче лице: Користувач

Інші учасники прецеденту: відсутні

Зв'язки з іншими варіантами використання: відсутні

Короткий опис

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

М3 Вибір опцій документу

Таблиця 2.6 - Варіант використання «Вибір опцій документу»

М3

Користувач

Вибір опцій документу

Цей варіант використання дозволяє користувачу обирати опції документу для подальшої роботи з ними (завантаження документу; заповнення документу; віднесення документу за місцем проживання)

Основне діюче лице: Користувач

Інші учасники прецеденту: відсутні

Зв'язки з іншими варіантами використання: відсутні

Короткий опис

Даний варіант використання дозволяє користувачу обирати опції документу для подальшої роботи з ними (завантаження документу; заповнення документу; віднесення документу за місцем проживання).

2.1.5 Пошук ключових варіантів використання

Аналіз сформульованих варіантів використання показав, що з точки зору потенційних ризиків і архітектурної значимості є наступні прецеденти:

- Вибір документу;

- Вибір опцій документу.

Зведемо дані по їх деталізації до таблиці 2.10.

Таблиця 2.10 - Деталізація ключових прецедентів розроблюваного ПЗ

Вибір документу

Опис прецеденту

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

Дійові особи прецеденту

Користувач

Передумови

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

Потік подій

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

Базовий потік

1. Користувач запускає Android-додаток;

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

3. Користувач вводить дані для авторизації;

4. Система відкриває вікно зі списком документів;

5. Користувач обирає потрібний для роботи документ.

Постумови

При успішному завершенні прецеденту, користувач може працювати з БД документів.

Альтернативні потоки

Відсутні

Вибір опцій документу

Опис прецеденту

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

Дійові особи прцеденту

Користувач

Базовий потік

1. Користувач обирає необхідний документ зі списку;

2. Система надає можливість його переглянути та обрати опції (заповнити документ; завантажити документ і т.д.);

3. Користувач вибирає зі списку опцій потрібні;

4. Система зберігає внесені зміни.

Постумови

Відсутні.

Альтернативні потоки

Відсутні.

2.1.6 Побудова діаграм станів та переходів ПЗ

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

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

Діаграма станів ПЗ для дій користувача зображена на Рисунку 2.3.

Рисунок 2.3 - Діаграма станів ПЗ для дій користувачів ПЗ

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

2.1.7 Розробка екранних форм програмного забезпечення

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

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

Рисунок 2.5 - Стартове вікно розроблюваного ПЗ

Після вдалої авторизації відкривається вікно зі списком документів. Ескіз даної форми представлено нижче (рис.2.6).

Рисунок 2.6 - Вікно зі списком документів

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

Рисунок 2.7 - Опції документу №4

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

2.2 Технічний проект програмного забезпечення

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

2.2.1 Розробка діаграми класів до програмного забезпечення

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

В результаті було побудовано діаграму основних класів програми, зображену на рис.2.7.

Рисунок 2.7 - Діаграма класів програмного забезпечення

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

2.2.2 Розробка робочої документації

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

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

Технічний опис представлений у Додатку А.

Інструкція з експлуатації представлена у Додатку Б.

Програмний код ПЗ представлений у Додатку В.

Сертифікат на розробку концепції ПЗ в Додатку Г.

2.3 Робочий проект програмного забезпечення

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

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

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

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

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

- Виконання прийнятних стандартів при використанні мовних засобів.

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

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

2.3.1 Опис мови програмування Java для розробки програмного забезпечення на платформі Android

Мова Java - об'єктно-орієнтована мова програмування. Програма на Java транслюється в байт-код, що виконується віртуальною машиною Java (JVM) -- програмою, яка обробляє байт-код и передає інструкції обладнанню як інтерпретатор.

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

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

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

2.3.2 Опис середовища розробки програмного забезпечення, що працює на платформі Android

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

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

- Eclipse;

- Intellij IDEA.

При розробці програмного забезпечення буде використано середовище розробки Intellij IDEA, яке вже придбане розробником. Це рішення обумовлене широкою загальною популярністю даного середовища програмування та можливостями. Воно містить вільні Android SDK (інструменти для розробки) та багато корисних надбудов та плагінів.

2.3.3 Кодування програмного забезпечення

Виконавши аналіз середовищ розробки програмного забезпечення (пункт дипломної роботи 2.3.2) на мові програмування Java, було обрано саме Intellij IDEA. Для програмування Android-додатку, функціональні вимоги якого представлені в постановці задачі (більше детально - в Додатку А) дане середовище програмування більш ніж підходить. Проектування ПЗ показує, що першим і головним завданням є кодування саме MainActivity - головного класу в додатку.

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

package com.smokiyenko.burokrat.app;

import android.app.Activity;

import android.content.Intent;

import android.os.Bundle;

import android.view.Menu;

import android.view.MenuItem;

import java.util.ArrayList;

import java.util.Arrays;

public class MainActivity extends Activity implements DocumentFragment.OnFragmentInteractionListener {

private SessionResponse session;

@Override

protected void onCreate(final Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_search);

session = BurokratApplication.getEventBus().getStickyEvent(SessionResponse.class);

getActionBar().setDisplayHomeAsUpEnabled(true);

if (savedInstanceState == null){

DocumentFragment fragment = DocumentFragment.newInstance();

final ArrayList<String> documents = new ArrayList<String>();

documents.addAll(Arrays.asList(documentNames));

fragment.setDocuments(documents);

getFragmentManager().beginTransaction().add(R.id.fragment_container,fragment,"doc").commit();

}

}

@SuppressWarnings("Unused")

public void onEventMainThread(final DocumentsListResponse documentsListResponse){

getFragmentManager().getFragment(null,"doc");

}

@Override

public boolean onCreateOptionsMenu(final Menu menu) {

// Inflate the menu; this adds items to the action bar if it is present.

getMenuInflater().inflate(R.menu.search, menu);

return true;

}

@Override

public boolean onOptionsItemSelected(final MenuItem item) {

int id = item.getItemId();

if (id == R.id.action_settings) {

return true;

}

return super.onOptionsItemSelected(item);

}

@Override

public boolean onNavigateUp() {

if (getFragmentManager().getBackStackEntryCount() > 0){

getFragmentManager().popBackStack();

getActionBar().setTitle(R.string.title_activity_search);

} else {

onBackPressed();

}

return true;

}

@Override

public void onFragmentInteraction(final String name) {

getActionBar().setTitle(name);

DocumentChecklistFragment fragment = DocumentChecklistFragment.newInstance(name);

getFragmentManager().beginTransaction().replace(R.id.fragment_container,fragment).addToBackStack("doc").commit();

}

}

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

2.3.4 Тестування програмного забезпечення

Реалізація класів проводиться на основі підрозділу 2.2.1 (Діаграма класів) технічного проекту.

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

В даному пункті буде проаналізовано класи еквівалентності (правильні та неправильні), проведено тестування на правильність роботи додатку в різних ситуаціях. Зроблено висновки.

Представимо код класу, який тестуватиметься:

public class LoginActivity extends BaseBurokratActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_login);

}

@Override

public boolean onOptionsItemSelected(MenuItem item) {

// Handle action bar item clicks here. The action bar will

// automatically handle clicks on the Home/Up button, so long

// as you specify a parent activity in AndroidManifest.xml.

int id = item.getItemId();

if (id == R.id.action_settings) {

return true;

}

return super.onOptionsItemSelected(item);

}

@SuppressWarnings("Unused")

public void onEventMainThread(final SessionResponse session){

BurokratApplication.getEventBus().unregister(this);

BurokratApplication.getEventBus().postSticky(session);

startActivity(new Intent(this, MainActivity.class));

overridePendingTransition(android.R.anim.slide_in_left, android.R.anim.slide_out_right);

}

public void onLoginPressed(final View view) {

// startActivity(new Intent(this, MainActivity.class));

// overridePendingTransition(android.R.anim.slide_in_left, android.R.anim.slide_out_right);

TextView tvPassportId = (TextView) findViewById(R.id.login_passport_id);

TextView tvPassportSeries = (TextView) findViewById(R.id.login_passport_series);

BurokratApplication.getClient().login(tvPassportSeries.getText().toString() , tvPassportId.getText().toString());

}

}

Повний код розробленої програми представлено в Додатку В. В таблиці 2.11 представлені класи еквівалентності та граничні значення вхідних даних:

- Серія паспорту;

- Код паспорту.

Таблиця 2.11 - Класи еквівалентності вхідних даних для класу авторизації

Вхідні умови

Правильні класи еквівалентності

Неправильні класи еквівалентності

Серія паспорту

1. Рядок (2 символи)

2. Спецсимволи

3. Графічні зображення (в тому числі і смайлики)

4. К-сть символів не рівна двом

Код паспорту

5. Рядок (6 символів)

6. Кількість символів більша або менша за 6

7. Спецсимволи

8. Графічні зображення

Почнемо з тестування для правильних класів еквівалентності класу авторизації (табл.2.12).

Таблиця 2.12 - Тести з правильних класів еквівалентності для класу авторизації

№ тесту

Вхідні дані

Вихідні дані

1

В поле введення серії паспорту вводимо «ЕР»

Додаток просить ввести код паспорту.

Результат вірний.

5

В поле введення коду паспорту вводимо значення «000001»

Додаток (у випадку правильно введеної серії паспорту) перевіряє наявність даних в БД серверу. Продовжує роботу.

Результат вірний.

Отже, за результатами правильних класів еквівалентності - додаток працює правильно і без збоїв. Наступним кроком буде перевірка неправильних класів еквівалентності класу авторизації додатку (табл.2.13).

Таблиця 2.13 - Тести з неправильних класів еквівалентності класу авторизації

№ тесту

Вхідні дані

Вихідні дані

1

2

3

2

У вікно введення серії паспорту введемо будь-який символ ASCII (скопіюємо з інтернету)

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

Результат підтверджено

3

У вікно введення серії паспорту введемо графічний елемент - смайлик (скопіюємо з інтернету)

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

Результат підтверджено

4

У поле серії паспорту введемо значення з 3 символів

3-й символ не набирається. Максимальна довжина серії - 2 символи.

Результат підтверджено

6

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

7-й символ не набирається. Максимальна довжина коду - 6 символів.

Результат підтверджено

7

У вікно введення коду паспорту введемо будь-який символ ASCII (скопіюємо з інтернету)

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

Результат підтверджено

8

У вікно введення коду паспорту введемо графічний елемент - смайлик (скопіюємо з інтернету)

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

Результат підтверджено

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

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

Повний текст програми наведено в Додатку В.

3. РЕЗУЛЬТАТИ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

У результаті виконання дипломної роботи було розроблено програмне забезпечення, яке надає змогу користувачам мобільних пристроїв під управлінням ОС Android працювати з документами, наданими Державній Податковій Інспекції. Розроблене програмне забезпечення задовільняє вимогам, які поставлені в технічному завданні.

Створене ПЗ виконує такі функції:

- Введення, перегляд, видалення, редагування документів (лише зі свого профілю);

- Керування опціями (атрибутами) документу;

- Авторизація (як ступінь захисту).

В результаті розробки ПЗ було досягнуто поставлених раніше умов.

Програмне забезпечення функціонує під управлінням ОС Android 2.3.x і вище.

Android-додаток написано в середовищі програмування Intellij IDEA і представлено файлом «Burokrat.apk».

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

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

Робота з програмним забезпеченням здійснюється з використанням зручного інтерфейсу користувача й розрахована на роботу в режимі діалогу з користувачем, котрий не є програмістом. Представлені ескізні форми на рисунках 2.5, 2.6 і 2.7 є кінцевими та представляють собою розроблений інтерфейс Android-додатку. Обов'язковою є авторизація.

Детальніше опис користувацького інтерфейсу та функцій додатку можна переглянути в Додатку Б. Текст програми представлено в Додатку В.

4. ОХОРОНА ПРАЦІ

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

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

Дана система включає:

- аналіз шкідливих факторів і небезпек, які діють на людину;

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

4.1 Аналіз небезпечних і шкідливих факторів у відділі роботи з фізичними особами

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

Велику небезпеку становлять дисплеї з електронно-променевими трубками (ЕЛТ) - джерела шкідливих випромінювань, небезпечно впливає на здоров'я операторів.

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

Крім цього важливим моментом є показники частоти вертикальної і горизонтальної розгортки ЕЛТ. Прийняті стандарти на монітори не дозволяють використовувати ЕЛТ і відеоадаптери з частотою вертикальної розгортки менше 75 Гц.

Мікрокліматичні параметри впливають на самопочуття і здоров'я людини, а також на надійність роботи засобів обчислювальної техніки. Для комфортної роботи приймається температура 230 С і 180 С в теплу і холодну пору року відповідно, при відносній вологості 55%. [ГОСТ 12.1.005-88].

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


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.