Автор работы: Пользователь скрыл имя, 18 Июня 2013 в 21:33, курсовая работа
Тема автоматизації системи житлоуправління по обліку мешканців та платежів являється актуальною, тому що через великий обсяг інформації, що надходить на обробку щодня, займає значну частину часу працівника. Використання автоматизованої системи (АС) допоможе прискорити процес отримання і обробки інформації, отримання інформації про клієнта, видах наданих послуг, його оплатах, заборгованості тощо.
Таким чином розробка даного програмного засобу (ПЗ) виправдовує себе автоматизацією великого набору процесів, які в підсумку знижують витрати часу роботи у багато разів.
Сфера житлово-комунального господарювання в нашій країні тривалий період перебуває у стані реформування, що й надалі створює ситуацію невизначеності.
3. забезпечити максимальну
незалежність проекту
4. забезпечити формальну
основу для однозначної
5. стимулювати розширення
ринку об’єктно-орієнтованих
6. інтегрувати кращий
практичний досвід
3.2 Створення UML діаграм ПЗ «Автоматизація житлоуправління»
Діаграма прецедентів - це графічне представлення всіх або частини акторів, прецедентів і взаємодій між ними. У кожній системі зазвичай є головна діаграма прецедентів, яка описує зовнішню межу системи та основні зовнішні функції (зовнішня поведінка) системи. Як приклад діаграми прецедентів розглянемо діаграму, яка зображує всі прецеденти для одного актора, яким є паспортист:
На рисунку 1 зображено модель прецедентів для актора Паспортист.
Рис. 1. Модель прецедентів для актора Паспортист
Діаграма станів визначає всі можливі стани, в яких може знаходитися конкретний об'єкт, а також процес зміни станів об'єкту в результаті настання деяких подій .
На діаграмі є два спеціальні стани - початкове (start) і кінцеве (stop). Початковий стан виділений чорною крапкою, воно відповідає стану об'єкту, коли він тільки що був створений. Кінцевий стан позначається чорною крапкою в білому кружку, воно відповідає стану об'єкту безпосередньо перед його знищенням. На діаграмі станів може бути один і лише один початковий стан.
На рисунку 2 зображено діаграму станів для актора Паспортист прецеденту Р1. Приписка жильця.
Рис. 2. Діаграма станів актора Паспортист прецедент Р1
Діаграми класів застосовуються для моделювання об'єктно-орієнтованих систем. На простих діаграмах показуються класи і відносини між класами. На складних діаграмах показуються класи, інтерфейси, кооперації і відносини між ними. Діаграми класів дають статичний вид системи. Можна також сказати, що діаграми класів являють собою погляди розробників на статичні стану проектованих систем. За допомогою діаграм класів складається словник системи. Діаграми класів є основою для створення діаграм компонентів і розгортання.
Рис. 3. Діаграма класів ПЗ «Автоматизація житлоуправління»
Діаграма послідовності. Однією з характерних особливостей систем різної природи і призначення є взаємодія між собою окремих елементів, з яких утворені ці системи. Йдеться про тому, що різні складові елементи систем не існують ізольовано, а роблять певний вплив один на одного, що і відрізняє систему як цілісне утворення від простої сукупності елементів. У мові UML взаємодія елементів розглядається в інформаційному аспекті їх комунікації, тобто взаємодіючі об'єкти обмінюються між собою деякою інформацією. При цьому інформація набуває форми закінчених повідомлень. Іншими словами, хоча повідомлення і має інформаційний вміст, воно набуває додаткової властивості робити направлений вплив на свого одержувача. Це повністю узгоджується з принципами ООАП, коли будь-які види інформаційної взаємодії між елементами системи мають бути зведені до відправки і прийому повідомлень між ними.
Для моделювання взаємодії
об'єктів в мові UML використовуються
відповідні діаграми взаємодії. Кажучи
про ці діаграми, мають на увазі
два аспекти взаємодії. По-перше,
взаємодії об'єктів можна
Раніше, при вивченні діаграм стану і діяльності, було відмічено одну важливу обставину. Хоча розглянуті діаграми і використовуються для специфікації динаміки поведінки систем, час в явному вигляді в них не присутній. Проте часовий аспект поведінки може мати істотне значення при моделюванні синхронних процесів, що описують взаємодії об'єктів. Саме для цієї мети в мові UML використовуються діаграми послідовності.
По-друге, можна розглядати структурні особливості взаємодії об'єктів. Для представлення структурних особливостей передачі і прийому повідомлень між об'єктами використовується діаграма кооперації.
Діаграма послідовностей для актора Паспортист представлена на рисунку 4.
Рис. 4. Діаграма послідовностей актора Паспортист
РОЗДІЛ IV. РОЗРОБКА ДОКУМЕНТАЦІЇ КОРИСТУВАЧА
4.1 Загальні відомості
Документація користувача ПЗ пояснює користувачам, як вони повинні діяти, щоб застосувати розроблювальний ПЗ. Вона необхідна, якщо ПЗ припускає яке-небудь взаємодію з користувачами. До такої документації належать документи, якими повинен керуватися користувач при інсталяції ПЗ (при установці ПЗ з відповідною настроюванням на середовище застосування ПЗ), при застосуванні ПЗ для вирішення своїх завдань і при управлінні ПЗ (наприклад, коли даний ПЗ буде взаємодіяти з іншими системами). Ці документи частково торкаються питань супроводу ПСЗ, але не стосуються питань, пов'язаних з модифікацією програм.
При створенні документації користувача слід розрізняти дві категорії користувачів ПЗ: ординарних користувачів ПЗ та адміністраторів ПЗ.
Ординарний користувач ПЗ використовує ПЗ для вирішення своїх завдань (в своїй предметній області). Це може бути інженер, який проектує технічний пристрій, або касир, який продає залізничні квитки за допомогою ПЗ. Він може і не знати багатьох деталей роботи комп'ютера або принципів програмування.
Адміністратор ПЗ управляє використання ПЗ ординарними користувачами і здійснює супровід ПЗ, не пов'язаний з модифікацією програм. Наприклад, він може регулювати права доступу до ПЗ між ординарними користувачами, підтримувати зв'язок з постачальниками ПЗ або виконувати певні дії, щоб підтримувати ПЗ в робочому стані, якщо він включений як частина в іншу систему.
Склад документації користувача залежить від аудиторій користувачів, на які орієнтовано розроблювальний ПЗ, і від режиму використання документів. Під аудиторією тут розуміється контингент користувачів ПЗ, у якого є необхідність у певній документації користувача ПЗ. Вдалий користувальницький документ суттєво залежить від точного визначення аудиторії, для якої він призначений. Користувацька документація повинна містити інформацію, необхідну для кожної аудиторії. Під режимом використання документа розуміється спосіб, що визначає, яким чином використовується цей документ. Звичайно користувачеві досить великих програмних систем потрібні або документи для вивчення ПЗ (використання у вигляді інструкції), або для уточнення деякої інформації (використання у вигляді довідника).
У відповідності зі сказаним
можна вважати типовим
4.2 Загальний функціональний опис ПЗ
ПЗ «Автоматизація житлоуправління» призначений для автоматизації роботи невеликого житлово-комунального господарства. ПЗ включає в себе:
Доступ до даних у ПЗ здійснюється згідно відведених ролей, та дозволяє кожному користувачеві виконувати тільки допустимі для нього задачі. Усі дані зберігаються у базі даних, що дозволяє користувачам виконувати необхідні запити, та швидко у зручній формі отримувати необхідну інформацію. Вимоги до комп’ютерної техніки та програмного забезпечення вказані у специфікації ПЗ (Додаток А).
4.3 Керівництво по інсталяції ПЗ
Програмний засів
Підключення бази даних.
ПЗ являється клієнт-серверним програмним засобом та дозволяє одночасно отримувати доступ користувачам із різних терміналів. Для цього необхідно на серверній машині встановити MS SQL Server 2000 та БД. Для цього потрібно:
Після інсталяції БД ПЗ «Автоматизація житлоуправління» готова для використання.
4.4 Інструкція по застосуванню ПЗ
Загальний вигляд ПЗ.
Рис. 5. Загальний вигляд ПЗ
На рисунку 5 представлено загальний вигляд ПЗ, який містить у собі наступні модулі:
Модулі 1, 2, 3, 8 доступні для усіх користувачів ПЗ.
Модулі 4,5,6 доступні тільки паспортисту.
Модуль 6 доступний тільки диспетчеру.
Модуль 7 доступний тільки бухгалтеру.
Аутентифікація у ПЗ. Аутентифікація у ПЗ здійснюється за допомогою логіну та паролю користувача. Згідно з введеними даними система дає доступ до доступних функцій, або забороняє вхід у систему (якщо логін або пароль невірні). На рисунку 6 зображено вікно Аутентифікації в ПЗ.
Рис. 6. Аутентифікація користувача в системі.
Після вводу логіну та паролю для авторизації в системі необхідно натиснути кнопку «Так». Або кнопку «Ні» для відміни дії.
Функції паспортиста. У програмному засобі передбачені наступні функції паспортиста:
Після аутентифікації паспортиста в системі, йому доступні усі вище перечисленні функції рисунок 7.
Рис. 7. Вікно паспортиста ПЗ.
Реєстрація заяви на прописку. Після подачі новим жильцем заяви на прописку, паспортист вносить дані у БД. Для цього необхідно натиснути кнопку «Оформити» модулю Заява на прописку. У активній формі внести необхідні дані рисунок 8.
Рис. 8. Реєстрація заяви на прописку.
Після внесення даних для реєстрації необхідно натиснути кнопку «Оформити» для реєстрації, або кнопку «Відмовитись» для відміни дії. Після реєстрації жилець з’являється у списку заяв модулю Заяви на прописку.
Відмітка про прописку. Для відмітки про прописку жильця потрібно виділити жильця у списку у модулі Заява на прописку та натиснути кнопку «Відмітити». У активній формі ввести дату прописки та натиснути кнопку «Змінити» для реєстрації, або кнопку «Відмовитись» для відміни дії. Після реєстрації жилець з’являється у списку жильців модулю Список жильців рисунок 9.
Рис. 9. Відмітка про прописку.
Зміна даних про жильця. Для зміни даних про жильця потрібно виділити жильця у модулі Список жильців та натиснути кнопку «Редагувати» модулю Дані про жильця рисунок 10.
Рис. 10. Редагування даних жильця.
Після зміни необхідних даних потрібно натиснути кнопку «Змінити» для зміни даних, або кнопку «Відмовитись» для відміни дії.
Информация о работе Структура житлово-комунальних господарств