37697

Встановлення вимог до функціональності програмного забезпечення із застосуванням засобів UML (Use Case diagram) та вербальних Специфікацій

Лабораторная работа

Информатика, кибернетика и программирование

Поселення відбувається портє і далі передається адміністратору для підтвердження внесення даних до БД. Адміністратор виконує всі операції з БД в тому числі: внесення змінення та видалення записів з бази а також внесення службової інформації що передбачає внесення особистих даних адміністратора та портьє. Портьє надає інформацію про поселення клієнтів адміністратору АС у вигляді: Перелік кімнат різних класів у готелі. Основний потік Надання інформації адміністратору.

Украинкский

2013-09-25

150 KB

20 чел.

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

Національний авіаційний університет

Лабораторна робота №1

З дисципліни “Методологія розробки ПП та великих ПС ”

Тема: «Встановлення вимог до функціональності програмного забезпечення із застосуванням засобів UML (Use Case diagram) та

вербальних Специфікацій»

Виконав:      студент ФКН-405

       Рощак І. М.

Перевірив:    Варнавський В.В.

Київ 2010

Тема: Встановлення вимог до функціональності програмного забезпечення із застосуванням засобів UML (Use Case diagram) та

вербальних Специфікацій

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

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

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

Діаграми прецедентів UML

Діаграми прецедентів (Use Case Diagram) є графічним засобом специфікування вимог, які використовуються  для визначення наступного:

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

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

  1.  визначення діючих осіб (actors);
  2.  визначення варіантів використання системи, виходячи з потреб діючих осіб;
  3.  встановлення зв’язків між суб’єктами та варіантами використання. Зв’язки включення та розширення обов’язково підписуються позначеннями «include» та «extend».

Завдання

1. За узгодженням з викладачем обрати варіант завдання (предметну галузь) для виконання лабораторних робіт.

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

3. Побудувати діаграму прецедентів на основі проведеного попереднього аналізу.

Автоматизована система надання послуг готелем

Опис предметної галузі

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

Поселення відбувається порт’є і далі передається адміністратору для підтвердження внесення даних до БД. Адміністратор виконує всі операції з БД в тому числі: внесення, змінення та видалення записів з бази а також внесення службової інформації, що передбачає внесення особистих даних адміністратора та портьє. Кінцевий користувач не має доступу до бази даних, а може лише виконувати функції перегляду і пошуку.

Вербальні специфікації прецедентів

  1.  Короткий опис. Портьє надає інформацію про поселення клієнтів адміністратору АС у вигляді:

- Перелік кімнат різних класів у готелі.

- Кількість, строк, майновий опис кімнат, що були здані.

- Особисті дані портьє.

Суб’єкт – портьє

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

Основний потік

Надання інформації адміністратору. Якщо інформація неповна виконується А1

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

А1. Неповна інформація щодо анкети клієнта готелю. Якщо передана інформація щодо анкети неповна, або некоректно заповнена, адміністратор повідомляє про це портьє, та направляє анкету на пере заповнення.

Постумови

Адміністратор отримує інформацію, що має бути заповнена до бази даних.

  1.  Короткий опис. Адміністратор вносить інформацію про клієнта, до бази даних та заповнює службову інформацію, що складається з власних даних та особистих даних портьє.

2.1. Адміністратор вносить інформацію до бази даних

2.1.1. Адміністратор заповнює службову інформацію

2.1.1.1. Адміністратор заповнює особисті дані

2.1.1.2. Адміністратор заповнює особисті дані портьє

Субєкт – адміністратор

Передумова – виклик форми для заповнення службової інформації

Основний потік

2.1.1.2.1. Адміністратор заповнює власні особисті дані

2.1.1.2.2. Адміністратор заповнює особисті дані портьє

2.1.1.2.2.1 У випадку відсутності повної інформації щодо особистих даних портьє виконується В1

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

В1. Адміністратор не володіє юридичною інформацією. Він інформує портьє про відсутність інформації. Після надання портьє повної інформації прецедент повторюється

Постумови

Юридична інформація вноситься до бази даних, інакше стан системи залишається незмінним.

2.1.2. Адміністратор підтверджує інформацію про клієнта

2.1.2.1. Внесення інформації про особисті дані

2.1.2.2. Внесення інформації про юридичні дані

Субєкт – адміністратор

Передумова – виклик форми для заповнення інформації клієнта.

Основний потік

2.1.2.2.1. Адміністратор підтверджує дані про клієнта

2.1.2.2.1.1. Заповнення особистої інформації клієнта

2.1.2.2.1.2. Заповнення юридичної інформації клієнта

2.1.2.2.1.3. Заповнення інформації відносно замовленої кімнати.

У випадку відсутності повної інформації по одному з цих пунктів виконується С1

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

С1. Адміністратор не володіє інформацією про замовлену кімнату. Він  інформує портьє про відсутність інформації про замовлену кімнату. Після надання портьє повної інформації прецедент повторюється

Постумови

Вноситься інформація про замовлення до бази даних, інакше стан системи залишається незмінним.

2.1.2.3. Внесення інформації про розклад

Субєкт – адміністратор

Передумова – виклик форми для заповнення інформації про розклад

Основний потік

2.1.2.3.1. Заповнення інформації про розклад для певної групи

2.1.2.3.1. Відсутність повної інформації про розклад. Система оповіщує про відсутність повних даних, виконується D1

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

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

Постумови

Інформація про розклад вноситься до бази даних, інакше стан системи залишається незмінним.

2.2. Адміністратор видаляє інформацію

Субєкт – адміністратор

Передумова – адміністратор володіє інформацією про клієнтів

  

Основний потік

2.3.1. Система попереджує про безповортне видалення даних.

2.3.1.1. Якщо адміністратор не підтверджує видалення даних виконується F1

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

F1.Адміністратор відмовився від видалення даних. Система завершує прецедент.

Постумови

Інформація видаляється з бази даних, інакше стан системи залишається незмінним.


 

А также другие работы, которые могут Вас заинтересовать

31133. Статические модели объектно-ориентированного представления программных систем 142.29 KB
  Диаграмма классов это набор классов и связей между ними. Диаграммы классов используются: в ходе анализа для указания ролей и обязанностей сущностей которые обеспечивают поведение системы; в ходе проектирования для фиксации структуры классов которые формируют системную архитектуру. Отношения в диаграммах класса. Ассоциации отображают структурные отношения между экземплярами классов.
31134. Динамические модели объектно-ориентированного представления программных систем: автоматы 336.98 KB
  Динамические модели обеспечивают представление поведения системы путем отображения изменения состояний в процессе работы системы в зависимости от времени. Автомат описывает поведение в терминах последовательности состояний через которые проходит объект в течение своей жизни. Диаграмма схем состояний отображает конечный автомат выделяя поток управления от состояния к состоянию. Конечный автомат поведение определяющее последовательность состояний в ходе существования объекта.
31135. Динамические модели объектно-ориентированных программных систем: диаграммы взаимодействия Use Case 14.52 KB
  Диаграмма сотрудничества это диаграмма взаимодействия выделяющая структурную организацию объектов посылающих и принимающих сообщения. Иначе диаграмму сотрудничества называют диаграмма кооперации. Диаграмма последовательности это диаграмма взаимодействия отображающая сценарий поведения в системе и обеспечивающая более наглядное представление порядка передачи сообщений. Графически диаграмма последовательности это разновидность таблицы которая показывает объекты размешенные вдоль оси икс и сообщения упорядоченные во времени вдоль оси...
31136. Модели реализации объектно-ориентированных программных систем 34.82 KB
  Модели реализации обеспечивают представление системы в физическом мире рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. Рисунок 1 обозначение компонента Сходные характеристики: наличие имени; реализация набора интерфейсов; участие в отношения зависимости; возможность быть вложенными; наличие экземпляров экземпляры у компонентов только у диаграмм размещения № Описание различий 1 Классы логические абстракции компоненты физические предметы. 2 Компоненты являются...
31137. Стандартные методы совместного доступа к базам и программам в сложных информационных системах 150.16 KB
  ODBC это программный интерфейс PI доступа к базам данных разработанный фирмой X Open. ODBC это широко распространенный комплекс драйверов фирмы Microsoft для связи с разнородными базами данных удовлетворяющий стандартом ISO. Технологии связи с разнородными базами данных в условиях архитектуры клиент сервер с использованием ODBC. Клиентская часть состоит из: Управляющий модуль ODBC.
31138. Проектирование интегрированных ИС 68.03 KB
  Требование к корпоративным информационным системам: Функциональная часть: это функциональная интеграция и полнота; функциональная локализация; мониторинг функционирования. Организационное обеспечение: модульность; интеграция структуры; информационная безопасность. Применительно к промышленному предприятию состав систем составляющих корпоративную информационную систему во взаимосвязи с пользователями на различных уровнях управления может быть представлен в следующем виде: Интеграция функциональной части системы предполагает решение...
31139. Архитектура ЭИС 33.93 KB
  ЭИС совокупность организационных технических программных и информационных средств объединенных в единую систему с целью сбора обработки хранения и выдачи необходимой информации предназначенной для выполнения функций управления. ЭИС связывает объект и систему управления между собой и внешней средой через информационные потоки: ИП1 нормативная информация создаваемая государственными учреждениями в части законодательства; поток информации о конъюнктуре рынка создаваемые конкурентами потребителями поставщиками; ИП2 отчетная...
31140. Общая характеристика процесса проектирования ИС 32.86 KB
  Экономикоорганизационные принципы: Принцип эффективности ИС. Принцип стандартизации. Принцип системного подхода. Принцип интеграции.
31141. Технология проектирования ИС 82.83 KB
  Состав компонентов технологии проектирования Таким образом проектирование ИС задается регламентированной последовательностью технологических операций выполняемых в процессе создания проекта на основе того или иного метода в результате чего стало бы ясно не только что должно быть сделано для создания проекта но и как кому и в какой последовательности это должно быть сделано. Методология проектирования ИС предполагает наличие некоторых концепций принципов проектирования реализуемых набором методов проектирования которые в свою очередь...