Проектирование информационной системы "Художественная галерея"

“Технология” – это правила, по которым обрабатывается процесс функционирования пригласительного, как предприятия со своими внутренними правилами, и также обязанного “жить” согласно законодательству конкретной страны.

В оказании услуг принимает участие “Организатор” выставки. Чтобы предоставить номера и получить прибыль, в деятельности выставки должно участвовать “Оборудование” – обстановка здания, техника, художественные произведения, инвентарь и т.д.

После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на под­системы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции (Рис. 5)

Рис. 5 – Диаграмма декомпозиции IDEF0. Функционирование художественной галереи.

 

Весь процесс “Функционирования художественной галереи” разбивается 5:

1)     “Анализ заявки” представляет собой процесс предварительной регистрации;

2)     “Формирование списков” представляет собой процесс создания базы данных по определенной выставке;

3) “Аукцион” представляет собой процесс формирования аукциона;

4) “Производство пригласительных” создание пригласительных;

5) “Контроль” проверка качества.

 

 

 

6. Диаграммы классов UML

 

Диаграмма классов – диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними. Входит в UML. Помимо своего широкого применения, диаграммы классов концентрируют в себе большой диапазон понятий моделирования. Их основные элементы используются практически всеми типами диаграмм. Диаграмма классов описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. На диаграммах классов отображаются также свойства классов, операции классов и ограничения, которые накладываются на связи между объектами.

Свойства представляют структурную функциональность классов. В первом приближении можно рассматривать свойства, как поля класса. Они представлены в виде атрибутов и ассоциаций.

Атрибут описывает свойство в виде строки текста внутри прямоугольника класса.

Другая ипостась свойства – это ассоциация. Значительная часть информации, которую можно указать в атрибуте, проявляется в ассоциации. Ассоциации – это непрерывная линия между двумя классами, направленная от исходного класса к целевому. Имя свойства вместе с кратностью располагается на целевом конце ассоциации.

Кратность свойства обозначает количество объектов, которые могут заполнять данное свойство. Чаще всего встречаются данные кратности:

• 1 – только 1. Например, только одна буква “а” в слове “пар”
• 0..1 – может быть или не быть. Например, второй двигатель у самолета
• * — любое количество. Например, лепестков у цветка.

В большинстве случаев кратности определяются своими нижней и верхней границами. Нижняя граница может быть нулем или положительным числом, верхняя граница представляет собой положительное число или *(без ограничений). Если верхняя и нижняя границы совпадают, то можно указать одно число, например 1..1 эквивалентно 1.

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

На Рис. 8 представлена диаграмма классов.

 

Рис. 8 – Диаграмма классов.

 

 

 

 

 

7. Вывод

Я думаю, что каждая из этих таблиц может быть очень полезной, но для определённой группы людей. Например, для разработчиков БД необходима будет диаграмма классов. Для заказчика, чтобы понять, как работает программа с клиентом и администратором будет нужна диаграмма прецедентов. А диаграмма активности будет нужна как разработчикам программы для написания программного кода, так и администраторам программы для того чтобы знать что делать в определённых ситуациях и быстрого обслуживания клиентов. Диаграмма IDEF0 будет интересна заказчику, т.к. он будет видеть алгоритм процесса и кто и как выполняет свои обязанности.

В итоге лучше использовать обе технологии моделирования (объектно-ориентированная; функциональная) для выявления всех аспектов предметной области.