Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы».pdf

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

В рамках ООАП исторически рассматривались три графических нотации:

диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD),

диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT),

диаграммы потоков данных (Data Flow Diagrams, DFD).

Диаграммы "сущность-связь" (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними.

Основными понятиями данной нотации являются понятия сущности и связи. При этом под сущностью (entity) понимается произвольноемножество  реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. В этом случае любой рассматриваемый объект может быть экземпляром одной и только одной сущности, должен иметь уникальное имя или идентификатор, а также отличаться от других экземпляров данной сущности.

Связь (relationship) определяется как отношение или ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения, в частности "отец-сын" или производственные - "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи.

Графическая модель данных строится таким образом, чтобы связи между отдельными сущностями отражали не только семантический характер соответствующего отношения, но и дополнительные аспекты обязательности связей, а также кратность участвующих в данных отношениях экземпляров сущностей. Нотация диаграмм (ERD) реализована в различных программных средствах. Пример диаграммы ERD, разработанной с помощью средства моделирования бизнес-процессов ARIS  изображен на рис.1.1.

---

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

Рис. 1.1. Диаграмма "сущность-связь" для примера сотрудников компании, работающих над различными проектами

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

Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем

Нотация IDEF1 - для документирования информации о производственном окружении систем

Нотация IDEF2 - для документирования поведения системы во времени

Нотация IDEF2 никогда не была полностью реализована. Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X. Методология IDEF нашла применение в правительственных и коммерческих организациях, поскольку в 1993 году появился стандарт FIPSправительства США для  двух технологий IDEF0 и IDEF1X. В течение последующих лет этот стандарт продолжал активно развиваться и послужил основой для реализации в некоторых CASE-средствах, наиболее известным из которых является AllFusion Process Modeler (новое название BPwin ) компании Computer Associates.

Процесс моделирования IDEF представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы какой-либо предметной области. Функциональная модель IDEF отображает структуру процессов функционирования системы и ее отдельных подсистем, то есть, выполняемые ими действия и связи между этими действиями. Для этой цели строятся специальные модели, которые позволяют в наглядной форме представить последовательность определенных действий. Исходными строительными блоками любой модели нотации IDEF0 процесса являются деятельность (activity) и стрелки (arrows).

---

Одна из наиболее важных особенностей нотации IDEF0 - постепенное введение все более детальных представлений модели системы помере  разработки отдельных диаграмм. Построение модели IDEF0 начинается с представления всей системы в виде простейшей диаграммы, состоящей из одного блока процесса и стрелок ICOM, служащих для изображения основных видов взаимодействия с объектами вне системы. Поскольку исходный процесс представляет всю систему как единое целое, данное представление является наиболее общим и подлежит дальнейшей декомпозиции. Пример представления общей модели процесса оформления кредита в банке, разработанной с помощью CASE-средства AllFusion Process Modeler , изображен на рис. 1.2

Рис. 1.2. Пример исходной диаграммы IDEF0 для процесса оформления кредита в банке

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

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

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

---

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

2.1 Сущность поставленной задачи

В настоящее время процесс автоматизации рабочих мест специалистов характерен для всех областей, где имеет место взаимодействие человека с компьютером. Автоматизированное рабочее место (АРМ) специалиста или сотрудника позволяет автоматизировать и облегчит его работу. Зачастую внедрение автоматизированных рабочих мест имеет экономические предпосылки, так как их использование более выгодно.

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

На программный продукт «Автоматизированная система коменданта общежития» были возложены следующие задачи:

- Ведение базы данных о каждом жителе (номер комнаты, паспортные данные);

- Ведение учета выдачи инвентаря;

- Учёт информации о различных видах оплат (номер квитанции, дата оплаты, сумма)

Основная задача, которую необходимо автоматизировать, - ведение учёта о жителях общежития.

Данная программа должна содержать несколько таблиц данных.

Работа коменданта при отсутствии автоматизированного рабочего места сопряжена с рядом неудобств. Процесс ведения и учёта данных о жителях занимает много времени.

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

---

При проектировании принимались во внимание следующие требования:

-Система должна нормально функционировать на стандартных персональных компьютерах типа IBM.

- Система не должна иметь привязки к аппаратной части для возможности переноса ее на новую платформу из-за старения компьютерной техники.

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

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

- Система должна иметь возможность наращивания как программной, так и аппаратной части.

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

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

2.2 Проектирование модели

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

Для этого мы построим следующие диаграммы:

- диаграмма вариантов использования;

- диаграмма классов;

- диаграмма компонентов;

- диаграмма последовательности.

Для графического представления выполняемых программой действий необходимо особым образом связать объекты и выполняемые ими действия между собой. Под объектом понимается отдельный экземпляр класса, он имеет собственное имя и конкретное значение атрибутов.

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

Представим проектируемую систему в виде множества сущностей, взаимодействующих друг с другом с помощью вариантов использования без рассмотрения внутренней структуры этих сущностей.

---