Визуальные модели деятельности

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

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

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

Важным вопросом является выбор графической нотации, которая должна быть понятна всем заинтересованным сторонам, иначе она не будет полезна. Нотация – совокупность графических объектов, которые используются в моделях. Она является синтаксисом языка моделирования. Графическая нотация – система обозначений, предназначенная для представления информации об отдельных аспектах моделируемой предметной области. Было разработано несколько методов моделирования, использовавших разные нотации (представления элементов модели). В современных технологиях широко используется метод (нотация) американского ученого Г. Буча (Grady Booch), который разработал нотацию графических символов для описания различных аспектов модели. Так, компоненты реального мира (объекты) в этой модели представляются в виде облаков. Такое представление является иллюстрацией того, что эти компоненты могут быть почти чем угодно. Отношения между объектами представляются различного вида стрелками. Более простая графика использована в технологии объектного моделирования (OMT, Object Modeling Technology). Нотация ОМТ разработана Дж. Рамбо (James Rumbaugh). Эту нотацию поддерживают многие современные промышленные инструменты моделирования программного обеспечения, в частности Rational Rose.

2. Логические и физические модели
структур данных

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

Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей БД. Основные компоненты модели – это:

· сущности;

· их атрибуты;

· связи между ними.

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

Физическая модель данных, напротив, связана с реализацией схемы данных в конкретной СУБД. Физическая модель отражает компонентный состав проектируемой системы с точки зрения ее реализации на некоторой технической базе и вычислительных платформах конкретных производителей. В процессе построения физической модели данных следует определить:

· наименования таблиц;

· типы данных для всех полей.

Физическая модель данных должна быть обязятельно нормализована.

3. Современные технологии
и CASE-средства

3.1. IDEF-технология разработки
информационных систем

Современный комплекс IDEF-технологий основан на стандарте 1960-х гг. SADT (Structured Analysis and Designer Technique). Он содержит:

· IDEF0 – технологию функционального моделирования, позволяющую документировать процесс производства и отображать информацию об использовании ресурсов на каждом этапе проектирования системы;

· IDEF1Х – технологию моделирования структуры данных;

· IDEF2 – технологию динамического моделирования поведения системы во времени (не была полностью реализована);

· IDEF3 – технологию моделирования бизнес-процессов в системе;

· IDEF4 – технологию построения объектно-ориентированных систем;

· IDEF5 – технологию онтологического (принципиального, структурного) исследования системы.

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

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

IDEF1Х -технология связана с построением реляционных структур данных. С помощью логической модели данных разрабатывается БД информационной системы и решаются задачи нормализации БД. На основе логической модели данных осуществляется физическое проектирование. С помощью физической модели реализуется реляционная модель данных в рамках используемой СУБД.

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

· пополнение нормализованной БД;

· просмотр данных в каждой из таблиц;

· построение запросов для пополнения базы данных, для просмотра данных в таблицах и выполнения вычислений.

Остальные технологии комплекса (IDEF2, IDEF4, IDEF5) менее популярны и не нашли широкого распространения при разработке информационных систем.