Разработка онлайн-органайзера с использованием объектно-ориентированного подхода. Исследование 1 Методология проектирования информационных систем

• Название: Исследование 1 Методология проектирования информационных систем
• Анкор: Разработка онлайн-органайзера с использованием объектно-ориентированного подхода
• Дата: 25.05.2022
• Размер: 1.64 Mb.
• Имя файла: 132640.rtf
• Тип: Исследование; #550069
• страница: 5 из 19

1.7 Построение модели в Sybase PowerDesigner

Целью данного этапа является проведение анализа бизнес-процессов заказчика и на основе данного анализа построение модели автоматизированной системы управления (АСУ). Для этого необходимо произвести анализ требований пользователя к продукту. Также необходимо провести анализ роли пользователя (Actor) в системе и т.д. Задача это не простая и требует значительных аналитических усилий и опыта. Результатом этой работы должно быть четкое понимание роли пользователя, процесса и список объектов (сущностей), участвующих в этом процессе. Все это и должно найти отражение в диаграммах Sybase PowerDesigner. Кроме того, необходимо с помощью анализа запросов среднего целевого пользователя составить список требований к ИС.

Используем следующий подход: используем Use case diagram для отображения списка операций, которые должна выполнять наша система; иначе говоря, это требования к системе. Каждый Use case – это некоторый процесс (последовательность действий), поэтому мы должны использовать Sequence diagram для его детализации. На этой диаграмме мы отображаем объекты из предметной области (объекты, участвующие в бизнес-процессе); таким образом, мы получаем экземпляры некоторых классов и их взаимодействие. Sequence diagram отображает сам процесс.

1.8 Построение диаграмм

1.8.1 Use case diagram (диаграмма вариантов использования)

Данный тип диаграмм показывает проект в статическом состоянии, позволяет сделать анализ бизнес-процессов. На данном этапе мы описываем только функции, которые могут выполнять актеры. Актер представляет собой некоторую роль, которую играет пользователь по отношению к системе.

1.8.2 Sequence diagram (диаграммы последовательностей действий)

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) -сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

2. Проектирование базы данных

2.1 Требования к информационной системе

Цель работы: спроектировать и реализовать базу данных (БД) в СУБД PostgreSQL.

Данная работа содержит описание базы данных для программы-органайзера, рассчитанной на широкий круг пользователей. БД спроектирована с учетом следующих требований:

1. 
   Минимальная избыточность. Данные, хранимые в БД, могут содержать как "полезную", так и "вредную" избыточность. Последняя всегда имеет место при отсутствии концептуального представления данных, когда каждый пользователь создает для своих приложений отдельный набор данных. В этом случае, если нескольким пользователям требуются одни и те же данные, то они должны быть повторены в каждом наборе. Такая избыточность является неконтролируемой, поскольку, о ее существовании пользователи могут и не подозревать. Интеграция пользовательских представлений в единое концептуальное представление, как правило, устраняет эту избыточность данных. К "полезной" избыточности можно отнести периодические копии данных, хранящихся в БД. Эта избыточность легко контролируется. Более того, она является необходимой, например, для восстановления данных, разрушенных при случайных сбоях и в катастрофических ситуациях.
   

Таким образом, требование минимальной избыточности следует понимать как устранение "вредной"" (неконтролируемой) и сведение к минимуму "полезной" (контролируемой) избыточности данных;

2. 
   Целостность данных. Означает, что в базе данных установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей;
   
3. 
   Безопасность и секретность. Обеспечивает защиту данных от аппаратных и программных сбоев, от катастрофических и криминальных ситуаций, а также от некомпетентного доступа к ним.
   
4. 
   Независимость данных. Подразумевает возможность изменения структуры БД без изменения прикладных программ пользователей. Понимается в двух аспектах, а именно, как логическая и физическая независимость.
   

Логическая независимость предполагает возможность изменения концептуальной схемы БД без изменения прикладных программ пользователей.

Физическая независимость подразумевает возможность изменения способа размещения данных на физических носителях и (или) методов доступа к данным без изменения прикладных программ пользователей.

5. 
   Производительность. Характеризуется временем ответа на запросы пользователей.
   
6. 
   Гибкость и способность к расширению. Понимается как способность БД к наращиванию данных, а также увеличению количества возможных приложений и расширению функций в пределах каждого приложения.
   

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