Проектирование системы автоматизации автостоянки

ICONIX использует  только 20% диаграмм UML и больше подходит  для небольших проектов по  сравнению с RUP. Сложный процесс разработки ПО упрощается до использования минимума шагов, ведущих к создания ПО.

В отличие от довольно сложного RUP ICONIX не требует привлечения консультантов, которые бы преобразовали этот процесс для конкретной компании. ICONIX компактнее, легче в изучении. RUP полностью показывает весь ЖЦ разработки ПО, ICONIX же фокусирует свое внимание на фазе анализа.

В настоящее время в процессе RUP на фазе анализа и дизайна применяется ICONIX, которая является подключаемым модулем от Rational SoftWare.

ICONIX как и RUP основан на прецедентах, является итеративным и инкрементным. Его основная задача – найти ответ на вопрос: как максимально быстро добраться от прецедентов к работающей системе, используя минимум промежуточных шагов.

Основные этапы процесса следующие:

• анализ требований

• предварительное проектирование

• детальное проектирование

• реализация

Процесс основан на построении минимального количества моделей, которые отражают будущую систему. Это динамические и статические модели.

На этапе анализа:

1. Проводится архитектурный анализ программного обеспечения
2. Создаются модели прецедентов
3. Создается модель пользовательского интерфейса

На этапе предварительного проектирования:

1. Дополняется и уточняется модель прецедентов
2. Создаются классы уровня предварительного проектирования, участвующие в вариантах использования
3. Создаются предварительные диаграммы классов для каждого варианта использования
4. Осуществляется распределение классов по пакетам
5. Дополняется Модель предметной области

На этапе детального проектирования:

1. Проектируется архитектура системы
2. Создаются диаграммы последовательности
3. Уточняются классы уровня детального проектирования и уточняются диаграммы классов
4. Создается общая диаграмма классов и диаграммы классов по пакетам
5. Создается модель данных с атрибутами и связями (ER-диаграмма)
6. Создается диаграмма состояний

На этапе реализации:

1. Создаются диаграмма компонентов, если это необходимо
2. Создается физическая база данных
3. Создаются исходный код

Каждый этап завершается рецензирование, когда созданные диаграммы обсуждаются с коллегами.

Обоснование выбора технологии создания ПО ИС для проекта курсовой работы

Для проектирования ИС была выбрана технология ICONIX, т.к.:

• она подходит для относительно не больших проектов
• основной упор делает на анализе и проектирование ПО
• может использоваться небольшой группой разработчиков
• обеспечивает высокое качество разрабатываемого проекта ИС

 

При проектировании ИС используется объектно-ориентированный подход CASE – средство Rational Rose, язык визуального объектно-ориентированного моделирования UML.

Основной функцией  Rational Rose является построение различного рода диаграмм и спецификаций UML, которые определяют архитектуру системы, а также ее статические и динамические аспекты.  Rational Rose средство визуального моделирования с использованием языка UML. Это язык графического описания для объектного моделирования в области разработки программного обеспечения, с помощью его Rational Rose способен выполнять всевозможные задачи в проектировании.

Rational Rose - CASE-средство, предназначенное для автоматизации  этапов анализа и проектирования  ПО, а также для генерации кодов  на различных языках и выпуска  проектной документации. Преимущества средства:

• Содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах;
• В основе лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты;
• Можно выделить 7 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта, средства контроля проекта, средства сбора статистики и генератор документов, генератор кодов.
• Средство Rational Rose функционирует на различных платформах;
• Способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования

 

Глава 2. Проектирование системы при помощи технологии ICONIX

 

Описание предметной области

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

Информация о зонах стоянки: вся стоянка разделена на зовы (центральная, восточная и т.д.). Каждая зона поделена на стояночное место (места пронумерованы). В системе фиксируется данные о постановки машины на стоянку (дата, автомобиль, зона и место стоянки).

Если автомобиль продается, то формируется документ  продажи машины, в котором указывается данные о покупателе, данные о машине, дата и время продажи, данные о менеджере.

Система учета по требованию пользователя формирует и выдает на печать следующие отчеты:

• отчет по проданным автомобилям;
• отчет по зонированию стоянки.

Этап анализа технологии ICONIX

На данном этапе происходит:

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

При анализе предметной области были выделены следующие основные абстракции:

• автомобиль
• зоны стоянки
• стояночное место
• покупатель
• менеджер
• документ постановки машины на стоянку
• документ  продажи автомобиля

 

В ходе анализа были сформулированы следующие функциональные требования:

- система должна:

1. Вести учёт автомобиля (осуществлять ввод новой машины, просмотр, поиск сортировку, редактирование, удаление)
2. Вести учёт зон стоянки (осуществлять ввод новой зоны, просмотр, поиск сортировку, редактирование, удаление)
3. Вести учёт стояночных мест (осуществлять ввод нового места, просмотр, поиск сортировку, редактирование, удаление)
4. Вести учёт покупателей (осуществлять ввод нового покупателя, просмотр, поиск сортировку, редактирование, удаление)
5. Вести учёт менеджеров (осуществлять ввод нового менеджера, просмотр, поиск сортировку, редактирование, удаление)
6. Вести учёт документов постановки машины на стоянку (осуществлять ввод нового документа постановки машины на стоянку, просмотр, поиск сортировку, редактирование, удаление)
7. Вести учёт документов продажи автомобиля (осуществлять ввод нового документа продажи автомобиля, просмотр, поиск сортировку, редактирование, удаление)
8. Формировать отчёт по проданным автомобилям
9. Формировать отчёт по зонированию стоянки

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

Цель построение диаграммы – документирование функциональных требований (ДВИ) к системе.

На (ДВИ) отражаются две сущности языка UML, актёр и вариант использования (прецедент).

Актер (actor) – роль, которую играют пользователи системы во время взаимодействия с ней. Актерами могут быть как люди, так и другие автоматизированные системы.

Прецедент (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера.

ДВИ будет построена по следующим правилам:

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

ДВИ для данного проекта представлена на Рисунок 1 – диаграмма вариантов использования.

Рисунок 1 – диаграмма вариантов использования

 

В ходе детального изучения обязанностей сотрудников фирмы ДВИ была переработана и представлена в Рисунок 2 – диаграмма вариантов использования.

Рисунок 2 – диаграмма вариантов использования

Этап предварительного проектирования.

На данном этапе выполняются следующие работы:

1. Выполняется сценарий вариантов использования: выполняется формирования вариантов использования (создаются варианты использования).
2. Выполняется анализ вариантов использования (для каждого варианта использования выделяются классы и строятся диаграммы классов).

Создадим сценарии для следующих вариантов использования:

учет читателей;

учет выдачи и приема документов;

Сценарий ВИ – конкретная последовательность действий, которая иллюстрирует ВИ.

Сценарий состоит из следующих частей:

1. Краткое описание того, что происходит в варианте использования
2. Актер, инициирующий данный ВИ
3. Предусловие – это условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам
4. Постусловие – это условия, которые всегда должны быть выполнены после завершения ВИ. Предусловия и постусловия указывают порядок выполнения ВИ системы. Не у всех ВИ бывают постусловия
5. Основной поток событий – поэтапное описание того, что должно происходить во время выполнения ВИ. Описание того, что будет делать система с точки зрения пользователя. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок).
6. Альтернативный поток событий – описывает отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

Разработаем ВИ для учёта автомобилей

S1 - просмотр справочника  автомобилей.

S2 - ввод нового автомобиля (марка, выводится из другого справочника).

S3 - редактирование автомобиля.

S4 - удаление автомобиля.

Прототип интерфейса представлен на Рисунок 3 – прототип интерфейса главной страницы ПО.

Рисунок 3 – прототип интерфейса главной страницы ПО

 

S1 - просмотр справочника автомобилей.

Прототип интерфейса представлен на Рисунок 4 - прототип интерфейса просмотр справочника автомобили.

Рисунок 4 - прототип интерфейса просмотр справочника автомобили

 

Актер: «Менеджер»

Предусловие: …

Постусловие: …

Основной поток событий:

Менеджер	Система
Выбирает команду просмотра Справочника «Автомобили»	Открывает экранную форму  справочника «Автомобили». Загружает информацию об автомобилях из БД. (Е1).
Выбирает команду закрыть справочник «Автомобили»	Закрывает форму.

Сценарий завершен.

 

S2 - ввод нового автомобиля (марка, выводится из другого справочника)

Актер: «Менеджер»

Предусловие: открыт справочник «Автомобили»

Постусловие: открыт справочник «Автомобили»

Основной поток событий:

Менеджер	Система
Вводит команду добавить автомобиль	Открывает экранную форму  «Добавить автомобиль».
Вводит данные в форму
Вводит информацию о марке автомобиля	Открывается форма справочника «Марки автомобилей» Загружаются сведения о марках из БД
Выбирает марку (Е2)	Закрывает форму справочник «Марки автомобилей». Информация поступает в форму добавления автомобиля.
Сохраняет информацию (Е3)	Добавляет данные в справочник
Закрывает форму «Добавление автомобиля»	Закрывает форму «Добавления автомобиля» Активирует справочник автомобилей Обновляет данные

 

Сценарий завершен.

 

S3- редактирование автомобиля.

Краткое описание: …

Актер: «Менеджер»

Предусловие: наличие автомобиля, открыт справочник «Автомобили»

Постусловие: открыт справочник «Автомобили»

Основной поток событий:

Менеджер	Система
Выбирает автомобиль
Вводит команду редактировать автомобиль	Открывает экранную форму  «Добавление автомобиля» Выводит информация из БД в форму
Меняет данные в форме
Меняет марку	Открывает форму справочника «Марки автомобилей» Загружаются сведения о марках  из БД
Выбирает марку (Е2)	Закрывает форму справочника «Марки автомобиля» Информация поступает в форму редактирование Автомобиля
Сохраняет информацию (Е3)
Закрывает форму	Закрывает форму «Редактирование автомобиля» Активирует форму справочника «Автомобили» Обновляет данные