close

Вход

Забыли?

вход по аккаунту

?

отчет по практике

код для вставкиСкачать
Міністерство освіти і науки молоді та спорту України
Дніпропетровський національний університет ім. О. Гончара
Кафедра математичного забезпечення ЕОМ
Звіт про виробничу практику
Спеціальність "Програмна інженерія"
Студента 3-го курсу групи ПЗ-09-1
Троценка Євгена Ігоровича
Керівник практики від кафедри: Земляна Світлана Валентинівна
Керівник практики від підприємства: м. Дніпропетровськ
2012 р.
Реферат
Хвильовий алгоритм
Хвильовий алгоритм - алгоритм, що дозволяє знайти мінімальний шлях в графі з ребрами одиничної довжини. Заснований на алгоритмі пошуку в ширину. Застосовується для знаходження найкоротшого шляху в графі, в загальному випадку знаходить лише його довжину.
Суть алгоритму
На двовимірній карті (матриці), що складається з "прохідних" і "непрохідних" комірок, позначена комірка старту і комірка фінішу. Мета алгоритму - прокласти найкоротший шлях від комірки старту до комірки фінішу, якщо це, звичайно, можливо. Від старту у всі напрями поширюється хвиля, причому кожна пройдена хвилею комірка позначається як "пройдена". Хвиля, у свою чергу, не може проходити через комірки помічені як "пройдені" або "непрохідні". Хвиля рухається, поки не досягне точки фінішу або поки не залишиться непройдених комірок. Якщо хвиля пройшла всі доступні комірки, але так і не досягла точки фінішу, значить, шлях від старту до фінішу прокласти неможливо. Після досягнення хвилею фінішу, прокладається шлях в зворотному напрямі (від фінішу до старту) і зберігається в масиві.
Різновиди
Заповнення по матриці в 4 напрямках, він же алгоритм Лі - більш точний, але менш швидкий метод.
Заповнення по матриці в 8 напрямків - більш швидкий, але менш точний метод. Шлях по діагоналі приблизно в 1.4 рази довший, ніж по горизонталі й вертикалі, саме тому комірки, розташовані по діагоналі, мають коефіцієнт +3, а по горизонталі й вертикалі - коефіцієнт +2.
Існує також алгоритм А* (A-star) - направлений хвильовий алгоритм.
Практичне застосування
Хвильовий алгоритм - один з основних при автоматизованому трасуванні (розводці) друкованих плат. Він має досить велику кількість різноманітних модифікацій, що дозволяють покращити знайдений розв'язок з точки зору затрат пам'яті та швидкодії. Також одне з характерних застосувань хвильового алгоритму - пошук найкоротшої відстані на карті в стратегічних комп'ютерних іграх.
Опис алгоритму
Алгоритм складається з кількох етапів, серед яких основними можна виділити наступні: підготовчий етап, етап поширення хвилі та етап побудови шляху.
На підготовчому етапі проводиться аналіз комірок, що присутні на карті, визначаються зайняті комірки. Решта комірок позначаються як вільні, їм присвоюється вага "0". В лічильник кроків К записується 1.
Етап поширення хвилі полягає у знаходженні точки фінішу шляхом перебору сусідніх комірок та присвоєння їм відповідних ваг. В першу чергу перевіряються всі комірки, суміжні з початковою. Якщо комірка має вагу "0", їй присвоюється значення з лічильника кроків. Комірки з іншою вагою (заповнені на попередніх кроках), а також комірки, відмічені як зайняті, залишаються без змін. Якщо одна з комірок є точкою фінішу, алгоритм переходить на наступний етап - побудову шляху. В іншому випадку лічильник кроків збільшується на одиницю і описаний для початкової точки алгоритм повторюється для всіх точок з вагою К-1. Якщо кінцева точка не знайдена, і для всіх точок з вагою К-1 в околі не лишилось вільних комірок, то вважається, що шлях не існує.
На етапі побудови шляху (згортання хвилі) починаємо рух з кінцевої точки. Для цієї точки обирається комірка з її околу (вага цієї комірки буде К). Тоді для цієї комірки знову шукається суміжна з вагою К-1. Таким чином продовжується доти, поки не знайдено комірку з вагою 1, в околі якої знаходиться початкова точка (вага початкової точки 0). Таким чином маємо побудований шлях, який також відносить до множини шляхів мінімальної довжини.
Драйвер JDBC
Кожна база даних має віддавати свої дані назовні - користувачам. Передача даних від сервера клієнтському додатку проводиться за певними правилами (певного протоколу), який для кожного виробника може бути свій. Для того, щоб програмісту не влазити в усі ці нетрі виробник бази даних розробляє драйвери для спілкування зі своєю базою даних. Для Java - це JDBC-драйвери. Найголовніше, що для Java-програміста НЕ ВАЖЛИВО, до якого сервера він підключається. Робота з драйвером буде завжди однакова. Таким чином єдине, що може перешкодити легкому перенесенню бази даних з SQL-сервера одного виробника на іншого - це особливості самих SQL-запитів. Якщо ж вони у вас не дуже складні і підкоряються стандартам, то швидше за все перенесення не буде проблематичним. Розглянемо простий приклад взаємодії з базою даних.
ОРМ
ORM (англ. Object-relational mapping, Об'єктно-реляційна проекція) - технологія програмування, яка зв'язує бази даних з концепціями об'єктно-орієнтованих мов програмування, створюючи "віртуальну об'єктну базу даних".
Проблема
У об'єктно-орієнтованому програмуванні об'єкти в програмі представляють об'єкти з реального світу. Як приклад можна розглянути адресну книгу, яка містить список людей разом з кількома телефонами і кількома адресами. В термінах об'єктно-орієнтованого програмування вони представлятимуться об'єктами класу "Людина", які міститимуть наступний список полів: ім'я, список (або масив) телефонів і список адрес.
Суть проблеми полягає в перетворенні таких об'єктів у форму, в якій вони можуть бути збережені у файлах або базах даних, і які легко можуть бути витягнуті в подальшому, зі збереженням властивостей об'єктів і відносин між ними. Ці об'єкти називають "постійними" (англ. persistent). Історично існує кілька підходів до рішення цієї задачі.
Реляційні СУБД
Вирішення проблеми зберігання даних існує - це реляційні системи управління базами даних. Використання реляційної бази даних для зберігання об'єктно-орієнтованих даних приводить до семантичного провалу, примушуючи програмістів писати програмне забезпечення, яке повинне уміти як обробляти дані в об'єктно-орієнтованому вигляді, так і вміти зберегти ці дані в реляційній формі. Ця постійна необхідність в перетворенні між двома різними формами даних не тільки сильно знижує продуктивність, але і створює труднощі для програмістів, оскільки обидві форми даних накладають обмеження одна на одну.
Реляційні бази даних використовують набір таблиць, що представляють прості дані. Додаткова або зв'язана інформація зберігається в інших таблицях. Часто для зберігання одного об'єкта в реляційній базі даних використовується декілька таблиць; це, у свою чергу, вимагає застосування операції JOIN для отримання всієї інформації, що відноситься до об'єкта, для її обробки. Наприклад, в розглянутому варіанті із записною книгою, для зберігання даних, швидше за все, використовуватимуться як мінімум дві таблиці: люди і адреси, і, можливо, навіть таблиця з телефонними номерами.
Оскільки системи управління реляційними базами даних зазвичай не реалізують реляційного представлення фізичного рівня зв'язків, виконання кількох послідовних запитів (що відносяться до однієї "об'єктно-орієнтованої" структури даних) може бути дуже витратне. Зокрема, один запит вигляду "знайти такого-то користувача і всі його телефони і всі його адреси і повернути їх у такому форматі", швидше за все, буде виконаний швидше за серію запитів вигляду "Знайти користувача. Знайти його адреси. Знайти його телефони". Це відбувається завдяки роботі оптимізатора і витратам на синтаксичний аналіз запиту.
Деякі реалізації ORM автоматично синхронізують завантажені в пам'ять об'єкти з базою даних. Для того, щоб це було можливим, після створення SQL-запиту, що перетворює об'єкт в SQL, отримані дані копіюються в поля об'єкта, як у всіх інших реалізаціях ORM. Після цього об'єкт повинен стежити за змінами цих значень і записувати їх у базу даних.
Системи управління реляційними базами даних показують хорошу продуктивність на глобальних запитах, які зачіпають велику ділянку бази даних, але об'єктно-орієнтований доступ ефективніший при роботі з малими об'ємами даних, оскільки це дозволяє скоротити семантичний провал між об'єктною і реляційною формами даних.
При одночасному існуванні цих двох різних світів збільшується складність об'єктного коду для роботи з реляційними базами даних, і він стає схильнішим до помилок. Розробники програмного забезпечення, що ґрунтується на базах даних, шукали легший спосіб досягнення постійності їхніх об'єктів.
Рішення
Розроблена безліч пакетів, що знімають необхідність в перетворенні об'єктів для зберігання в реляційних базах даних.
Деякі пакети вирішують цю проблему, надаючи бібліотеки класів, здатних виконувати такі перетворення автоматично. Маючи список таблиць в базі даних і об'єктів в програмі, вони автоматично перетворять запити з одного вигляду в іншій. В результаті запиту об'єкта "людина" (з прикладу з адресною книгою) необхідний SQL-запит буде сформований і виконаний, а результати "магічним" чином перетворені в об'єкти "номер телефону" всередині програми.
З погляду програміста система повинна виглядати як постійне сховище об'єктів. Він може просто створювати об'єкти і працювати з ними як завжди, а вони автоматично зберігатимуться в реляційній базі даних.
На практиці все не так просто і очевидно. Всі системи ORM зазвичай проявляють себе в тому або іншому вигляді, зменшуючи в деякому роді можливість ігнорування бази даних. Більш того, шар транзакцій може бути повільним і неефективним (особливо в термінах згенерованого SQL). Все це може привести до того, що програми працюватимуть повільніше і використовувати більше пам'яті, чим програми, написані "вручну".
Але ORM позбавляє програміста від написання великої кількості коду, часто одноманітного і схильного до помилок, тим самим значно підвищуючи швидкість розробки. Крім того, більшість сучасних реалізацій ORM дозволяють програмістові при необхідності жорстко задати код SQL-запитів, який використовуватиметься при тих або інших діях (збереження в базу даних, завантаження, пошук тощо) з постійним об'єктом.
DAO
У програмному забезпеченні data access object (DAO) - це об'єкт, який надає абстрактний інтерфейс до якого-небудь типу бази даних або механізму зберігання. Певні можливості надаються незалежно від того, який механізм зберігання використовується і без необхідності спеціальним чином відповідати цьому механізму зберігання. Цей шаблон проектування застосуємо до безлічі мов програмування, більшості програмного забезпечення, що потребує зберіганні інформації і до більшої частини баз даних, але традиційно цей шаблон пов'язують з додатками на платформі Java Enterprise Edition, взаємодіючими з реляційними базами даних через інтерфейс JDBC, тому що він з'явився в рекомендаціях від фірми Sun Microsystems.
Сервлет
Java Servlet API - стандартизований API для створення динамічного контенту до веб-сервера, використовуючи платформу Java. Сервлети - аналог технологій PHP, CGIі ASP.NET. Сервлети може зберігати інформацію між багатьма транзакціями, використовуючи HTTP кукіз, сесії або через редагування URL.
Servlet API, що міститься в пакеті javax.servlet, описує взаємодію веб-контейнера і сервлета. Веб-контейнер - це компонент веб-сервера, що створений для взаємодії з сервлетами. Він відповідає за управління життєвим циклом сервлетів, перетворення URL у певний сервлет та забезпечення того, щоб клієнт, який зробив URL запит, має відповідні права доступу.
Стандарти та специфікації
Сервлети, інтерфейси та базові класи, протоколи роботи з ними, робоче оточення, описуються у відповідних специфікаціях компанії Sun Microsystems.
Для полегшення розробки HTTP сервлетів, у специфікації описано абстрактний клас HttpServlet, від якого розробникам пропонується успадковувати свої сервлети.
Схема роботи та застосування
Клієнт (наприклад, Веб-оглядач), відвідує веб-сторінку та надсилає HTTP запит на сервер.
Web-сервер отримує запит та передає його контейнеру сервлетів. Контейнер сервлетів може виконуватись в тому ж самому процесі, що і веб-сервер, в окремому процесі на тій же системі, що і веб-сервер, або взагалі в окремому процесі на іншій системі.
Контейнер сервлетів з'ясовує який сервлет слід викликати, виходячи з інформації про конфігурацію утримуваних сервлетів, та викликає його, передаючи в якості параметрів об'єктні представлення запиту та відповіді.
Сервлет використовує об'єкт запиту для отримання інформації про віддаленого користувача, параметри HTTP запиту, тощо. Сервлет виконує запрограмовані в ньому дії та надсилає результати роботи через об'єкт відповіді.
Після того, як сервлет припиняє обробку запиту, контейнер сервлетів перевіряє коректність відправки відповіді, та повертає управління до головного веб-сервера.
Сервлети, також, використовуються в технології JSP. Шаблони сторінок транслюються у вихідні тексти Java-класів успадкованих від стандартних класів сервлетів. Java-компілятор компілює ці вихідні тексти в Java-байт коди. Отримані скомпільовані класи можуть використовуватись в сервлет-контейнері. Як правило, сервлет-контейнери виконують усі ці допоміжні дії автоматично.
Apache Tomcat Apache Tomcat - контейнер сервлетів, розроблений Apache Software Foundation. Повністю написаний мовою програмування Java та реалізує специфікацію сервлетів і Java Server Pages від Sun Microsystems, що є стандартами для розробки веб-застосунків на Java.
Зміст
Вступ11
Постановка індивідуального завдання12
Методи досягнення розв'язку завдань13
Створення власного алгоритму для обходу перешкод13
Реалізація хвильового алгоритму15
Перехід до дискретної карти16
Заповнення буферного масиву17
Пошук шляху18
Модифікація маршруту19
Виведення миттєвої статистики роботи комп'ютера (сервера) на веб-сторінку20
Отримання інформації по оперативній пам'яті20
Отримання інформації по процесору20
Метод виведення інформації21
Запис та зчитування статистики з бази даних22
Додання інформації про стан процесора24
Статистика унікальних по IMEI звернень за день до сервера25
Статистика унікальних по логіну звернень при вимкненій клієнтській програмі26
Аналіз отриманих результатів27
Висновки і рекомендації28
Перелік посилань29
Вступ
Компанія ТОВ "Вайлдек" займається розробкою програмного забезпечення для операційних систем "Android". Підприємство створює веб і локальні програми та ігри.
Протягом проходження практики я знайомився з технологіями, що застосовуються компанією під час роботи, структурою проекту,ефективними шляхами вирішення різноманітних задач, виконував реальні завдання в існуючому проекті, над яким працює компанія. В цілому, я здобув нові знання та отримав цінний досвід роботи в галузі розробки програмного забезпечення.
Постановка індивідуального завдання
Упродовж проходження практики переді мною ставилось декілька різних задач:
1. Вирішення проблеми обходу перешкод на карті:
a. Для двох даних точок - початкової та кінцевої - необхідно визначити, чи існують перешкоди. Точки задаються двома координатами на площині, а перешкоди представляються собою прості полігони, задані впорядкованим набором своїх вершин b. В разі, якщо перешкоди існують, побудувати шлях обходу перешкоди. При цьому шлях має складатись з обмеженої певним числом кількості точок
2. Виведення миттєвої статистики роботи комп'ютера (сервера) на веб-сторінку - загальної кількість оперативної пам'яті, кількості вільної оперативної пам'яті, загальної кількості потоків, кількості робочих потоків та потоків, що очікують . 3. Накопичення статистики роботи сервера у базі даних через деякі інтервали часу та виведення накопиченої інформації на веб-сторінку
4. Розширення виду інформації, що накопичується додатковими полями - рівнем завантаженості процесору
5. Додання статистики унікальних по IMEI звернень за день до сервера 6. Додання статистики унікальних по IMEI за день звернень клієнтських програм., що встановлені на приладі користувача, але не завантажувались деякий час
Методи досягнення розв'язку завдань
Створення власного алгоритму для обходу перешкод
Для реалізації цього алгоритму застосовувалася мова програмування високого рівня Java.
В основу методу було покладено аналітичний погляд на задачу пошуку обходу перешкод
В наявності вже був метод, що перевіряє чи перетинає відрізок, заданий двома точками, багатокутник, заданий впорядкованим набором своїх вершин, і метод, що повертає кількість таких перетинів.
Наведемо алгоритм у вигляді переліку пунктів:
Наступний алгоритм повторюється в циклі, поки є перешкоди між початковою та кінцевою точкою, тобто є ітераційним. 1. Будуємо відрізки, що сполучають початкову точку та всі вершини багатокутника
2. Для кожного відрізка визначаємо, чи має місце його перетин з багатокутником. Якщо так - вершина, що відповідає цьому відрізкові, відкидається; інакше - додається до списку "вершин-кандидатів"
3. Для даного багатокутника будується обмежуючий прямокутник
4. Через початкову точку та всі вершини зі списку "вершин-кандидатів" будуються рівняння прямих. Для кожної прямої знаходяться можливі точки перетину з обмежуючим прямокутником
5. Через початкову точку та отримані точки перетину будуються відрізки. Для кожного побудованого відрізка перевіряється, чи перетинає від багатокутник (окрім відповідної вершини). Якщо так - вершина, що відповідає цьому відрізку відкидається, інакше - додається до списку "крайових" вершин багатокутника.
6. Серед всіх крайових точок обирається найближча до точки призначення
7. Користуючись вже сформованим списком точок перетину відрізків, що відповідають всім вершинам (з'єднуються початкову точку і ці вершини), обираємо точку перетину, відповідну до отриманої "крайової" точки. Ця точка перетину і буде точкою курсування, і вона додається до маршруту
Реалізація хвильового алгоритму
Для реалізації цього алгоритму застосовувалася мова програмування високого рівня Java
Хвильовий алгоритм - це алгоритм, що дозволяє знайти мінімальний шлях у графі з ребрами одиничної довжини. Він заснований на основі алгоритму пошуку в ширину. Застосовується для знаходження найкоротшого шляху в графі. Більш детальний опис алгоритму див. вище в розділі "Реферат".
Реалізація здійснюється шляхом наступних кроків:
1. Перехід до дискретної карти map. Карта представляє собою двовимірний масив цілих чисел (для координат Х та У). Елементи карти заповнюються 0 (для вільних клітинок) та 1 (для клітинок, що містять перешкоду). Індекси елементів в карті представляють собою координати на початковій карті, переведені до дискретного представлення шляхом масштабування. 2. "Розповсюдження хвилі", завдяки якому заповнюється буферний масив buf.
3. Пошук шляху за допомогою заповненого buf
4. Модифікація знайденого шляху для ліквідація проміжних точок
Наведемо блок-схему реалізації хвильового алгоритму.
Перехід до дискретної карти
Наведемо алгоритм у вигляді послідовності пунктів, зобразивши таким чином логіку переходу до дискретної карти на більш концептуальному рівні, не вникаючи в особливості програмного коду
1. Створення дискретної карти як набору клітинок (двовимірний масив цілих чисел). Розмірність отримується шляхом масштабування розмірності вихідної карти
2. Значення всіх клітинок заповнюються нулями
3. Для всіх багатокутників будується обмежуючий прямокутник
4. Для кожного обмежуючого прямокутника перебираються клітинки, що до нього входять:
a. Визначається чи належить чергова клітинка многокутнику чи його границі, якщо так - відповідна клітинка отримує значення 1.
Таким чином, формується двовимірний масив, де 0 відповідає вільному місцю, а 1 - перешкоді.
Заповнення буферного масиву
Пошук шляху
Модифікація маршруту
Виведення миттєвої статистики роботи комп'ютера (сервера) на веб-сторінку
Отримання інформації по оперативній пам'яті Для роботи з оперативною пам'яттю було використано клас MemoryMXBean. Для створення об'єкту було застосовано фабрику ManagementFactory, а саме - її метод getMemoryMXBean. В наступну рядку було створено об'єкт mem:
MemoryMXBean mem = ManagementFactory.getMemoryMXBean(); Отримання загального об'єму оперативної пам'яті здійснюється шляхом виклику методу getHeapMemoryUsage().getMax()
Отримання об'єму використаної оперативної пам'яті здійснюється шляхом виклику методу mem.getHeapMemoryUsage().getUsed() Отримання інформації по процесору
Для роботи з процесором було використано клас OperatingSystemMXBean. Для створення об'єкту було застосовано фабрику ManagementFactory, її метод getOperatingSystemMXBean(). Об'єкт proc було створено наступним чином:
com.sun.management.OperatingSystemMXBean proc =
(com.sun.management.OperatingSystemMXBean) ManagementFactory.getOperatingSystemMXBean();
Для отримання завантаженості процесора використовувався метод getSystemCpuLoad().
Метод виведення інформації
Варто зазначити, що цю задачу було здійснено за допомогою технології Apache Tomcat (більш детально див. реферат).
У середовищі Intellij Idea було створено Web-Application. Логіку отримання інформації по серверу було реалізовано у вихідному java-файлі "Statistics.java". У цьому файлі було створено клас Statistics, що унаслідується від HttpServlet. Єдиний метод, що виконує всю необхідну логіку має таку сигнатуру
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException Після отримання інформації про стан сервера (див. вище) ми передаємо її через об'єкт req (запит) шляхом встановлення нового атрибуту table: req.setAttribute("table",table);
В цьому атрибуті ми передаємо всі зібрані дані.
У файлі "web.xml" було оголошено сервлет наступним чином servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>Statistics</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/aaa</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>MyServlet.jsp</welcome-file>
</welcome-file-list>
Зауважимо, що у файлі "MyServlet" не здійснено відображення на екран. Натомість це здійснено у файлі "index.jsp". Ця сторінка є головною при відкритті сайту. У файлі "index.jsp" інформація, що була передана, записується до комірок звичайної html-таблиці. Запис та зчитування статистики з бази даних
Очевидно, що миттєва статистика не є дуже цінною інформацією для отримання реального уявлення про роботу сервера. Тож задачу було розширено до отримання стану сервера через певні проміжки часу, запис отриманої інформації до бази даних та зчитування цих даних з бази даних і її виведення на веб-сторінку. В якості бази даних використовувалась MySQL. Робота з адміністрування бази даних здійснювалась за допомогою СУБД SqlYog. Зв'язок Java з MySQL здійснювалась за допомогою спеціального драйвера JDBC (більш детально див. у рефераті).
Таблиця в базі даних, до якої записувались дані мала назву "activity_stat" і містила наступні стовпці:
1. Id (int)
2. All Memory (int)
3. Used Memory (int)
Для роботи з базою даних із обєктно-орієнтованої мови програмування високого рівню Java було застосовано так званий ORM - підхід (більш детальна інформація в рефераті).
В декількох словах, можна сказати, що таблиці "activity_stat" відповідає клас ActivityStat, що містить однойменні з стовпцями таблиці поля, а також методи доступу до цих полів (так звані гетери та сетери).
Обгорткою до цього класу є клас ActivityStatDAO - він забезпечує логіку взаємодії з базою даних, в ньому реалізовані методи для виконання SQL-запитів, запису інформації до таблиці та зчитування з неї.
Обгорткою над ActivityStatDAO послуговується клас StatisticService. Він використовує попередній клас для реалізації логіки роботи з базою даних.
У вигляді схеми викладену вище ідею можна зобразити наступним чином:
Необхідно додати декілька слів про те, як здійснюються запити до бази даних і аналізуються результати цих запитів.
Запити виконуються за допомогою об'єктів класу PreparedStatement. Цей об'єкт створюється за допомогою об'єкту класу Connection наступним чином:
PreparedStatement insert = connection.prepareStatement(ТЕКСТ ЗАПИТУ)
Під час створенню цього об'єкту ми одразу його ініціалізуємо текстом запиту, який необхідно виконати. Однією з переваг такого виконання запитів є можливість параметризації. Для цього в тексті запиту при ініціалізації необхідно поставити на місці параметра знак питання "?". Між ініціалізацією та виконанням запиту в такому разі мають знаходитись операції підстановки параметрів: метод setInt (setLong,setStrin відповідно). Цей метод має наступну сигнатуру:
prepareStatement.setInt(paramNumb,paramValue),
де першим параметром є номер аргумента для підстановки, а другим - значення цього аргументу. Виконуватись запит може декількома способами в залежності від виду запиту. Для запитів типу insert чи update має місце виклик методу executeUpdate, наприклад: insert.executeUpdate().
Цей метод поверне кількість доданих (змінених) записів в таблиці.
Для видалення даних можна викликати метод execute.
Якщо необхідно виконати запит типу Select необхідно скористатись методом executeQuery:
ResultSet resultSet = loadAll.executeQuery()
В наведеному вище прикладі loadlAll - це об'єкт класу PreparedStatement, що ініціалізований select запитом; resultSet - об'єкт однойменного класу, що містить результат вибірки. Для того, щоб перебирати рядки результату вибірки, треба викликати метод next об'єкта resultSet. А для доступу до певного поля треба скористатись методом getInt(getLong, getString для інших типів даних відповідно). Наведемо приклад:
while (resultSet.next()) {
dailyStats.add(resultSet.getInt(id))
}
Додання інформації про стан процесора
Для реалізації цієї задачі знадобилось додати до таблиці "activity_stat" поле CPU. Також, було модифіковано класи ActivityStat (додано поле CPU з відповідними гетерами та сетерами).
В класах ActivityStatDAO та StatisticService були змінені готові методи таким чином, щоб вони забезпечували запис та зчитування ще й інформації про стан процесора. Метод отримання завантаженості процесора було описано вище.
Статистика унікальних по IMEI звернень за день до сервера Для реалізації цієї задачі я ознайомився зі створеними таблицями "history_connect_temp", "history_connect" та "daily_stat". Перші дві таблиці містили всі необхідні дані, що стосуються клієнта:
1. ip
2. id
3. uid
4. screenWidth
5. connectType
..........
Отже, до цих двох таблиць мною було додано додаткове поле imei
Таблиця daily_stat містила кількість унікальних звернень за різними параметрами. Стовпці цієї таблиці:
1. unique_by_id_count
2. unique_by_UID_count
3. date
...........
До цієї таблиці мною було додано поле unique_by_imei_count.
Згідно з ORM, першим двом таблицям відповідав клас HistoryConnectItem. До нього я додав відповідне поле (а також гетер та сетер).
Третій таблиці відповідав клас DailyStat. До цього класу мною було додано поле uniqueByImeiCount.
Наведемо схему:
Для виконання цієї задачі знадобилось змінити класи DailyStatDAO та StatisticService (змінено текст sql-запитів, в яких з'явилось ще одне поле, внесено зміни до методів зчитування та запису до таблиці в розрахунку на ще одне поле). Для отримання саме унікальних звернень по IMEI за день в класі DailyStatDAO було створено метод, що з таблиці "history_connect_temp" отримує відповідну кількість унікальних по полю IMEI запитів. Статистика унікальних по логіну звернень при вимкненій клієнтській програмі
Для виконання цієї задачі мені знадобились ті ж таблиці та класи, що і в попередній задачі. До таблиці "daily_stat" та відповідного класу було додано поле uniqueByTreatmentCount. Для забезпечення роботи цієї функціональності було змінено класи DailyStatDAO (тим же шляхом, що і в попередній задачі - шляхом зміни тексту sql-запитів, додання ще одного поля при записі і зчитування даних у відповідних методах). Варто звернути увагу на поле connectType таблиці "history_connect_temp". Це поле є одним із значень enum-у ConnectType. До цього enum-у мною було додано ще одну константу з іменем TREATMENT. Вона позначає, що поточна сесія представляє собою звернення не відкритої програми-клієнта до сервера. В свою чергу, у класі DailyStatDAO я додав метод, що знаходить кількість унікальних по логіну записів в таблиці "history_connect_temp", в яких поле connectType дорівнює ConnectType.TREATMENT.
Аналіз отриманих результатів
Шляхом методів, підходів та технологій, описаних в попередньому розділі було досягнуто наступних поставлених переді мною цілей:
1. Вирішено проблему обходу перешкод на карті
2. Здійснено виведення миттєвої статистики роботи комп'ютера (сервера) на веб-сторінку - загальної кількість оперативної пам'яті, кількості вільної оперативної пам'яті, загальної кількості потоків, кількості робочих потоків та потоків, що очікують . 3. Реалізовано накопичення статистики роботи сервера у базі даних через деякі інтервали часу та виведення накопиченої інформації на веб-сторінку
4. Проведено розширення виду інформації, що накопичується додатковими полями - рівнем завантаженості процесору
5. Зроблено додання статистики унікальних по IMEI звернень за день до сервера 6. Додано статистику унікальних по IMEI звернень за день клієнтських програм., що встановлені на приладі користувача, але не завантажувались деякий час
Висновки і рекомендації
Таким чином, ознайомившись з існуючим робочим проектом, деякими новими для себе технологіями та підходами, мною було виконано всі поставлені переді мною задачі. Рішення завдань є досить ефективними та сучасними. Застосовано технології та методології, що широко використовуються компаніями з виробництва програмного забезпечення.
Всі задачі виконані в повному обсязі і в поставлені строки.
Перелік посилань
1. http://uk.wikipedia.org
2. http://www.java-course.ru/students/students.php?name=part3
2
Документ
Категория
Без категории
Просмотров
233
Размер файла
511 Кб
Теги
практике, отчет
1/--страниц
Пожаловаться на содержимое документа