Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Анализ и разработка моделей информационных процессов и структур..pdf
Скачиваний:
34
Добавлен:
05.02.2023
Размер:
1.99 Mб
Скачать

создания программного обеспечения. В UML используются все те же диаграммы, что и в других средствах анализа, однако собранные воедино, они дают возможность наиболее полно рассмотреть предметную область и подвергнуть ее более глубокому анализу. Так, из методологии OOSE Айвара Якобсона были взяты диаграммы прецедентов (Use Case Diagram) для анализа предметной области. Для создания иерархической структуры объектов в методе UML применяются диаграммы классов (Class Diagram). Они отображают взаимосвязи между объектами, классами системы, их атрибуты и поведение. По своей значимости диаграммы классов, пожалуй, являются наиболее весомыми в объектном анализе, так как от качества классификации объектов зависит жизнеспособность будущей системы. Диаграмма поведения системы (Interaction Diagram), диаграммы последовательности (Sequence Diagram) и взаимодействия (Collaboration Diagram) вместе дают трехмерную модель взаимодействия объектов системы относительно времени. С помощью диаграмм состояний (State Diagram) описывается структура переходов объектов из одного состояния в другое при возбуждении определенных событий. Также используются диаграммы активности (Activity Diagram) для описания алгоритмов выполнения определенных операций. Для того чтобы описать

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

Таким образом, объектно-ориентированная декомпозиция на базе UML поддерживает все стадии жизненного цикла проектов – от анализа требований к системе до проекта на конкретном языке программирования. Средства визуального проектирования, поддерживающие язык UML (такие как, например, CASE-средство Rational Rose), обеспечивают генерацию кода и обратное проектирование для множества языков программирования

иописания интерфейсов (например, PowerBuilder, CORBA IDL и др.), а также имеют поддержку моделей ERwin и языка описания данных DDL для большинства СУБД.

2.4. Основы методологии разработки информационных систем на базе моделей предметной области

Тенденция развития информационных систем приводит к возрастанию их сложности. Современные крупные проекты характеризуются следующими особенностями:

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

50

наличие тесно взаимодействующих компонентов; отсутствие прямых аналогов ограничивает возможность

использования тепловых решений; необходимость интеграций существующих и разрабатываемых

приложений; функционирование в неоднородной среде различных аппаратных

программных платформ; разнородность отдельных групп разработчиков по уровню

квалификации и традициям использования тех или иных инструментальных средств;

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

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

Ключом решения проблем проектирования информационных систем является грамотная организация процесса создания программного обеспечения, реализация технологических принципов промышленного конструирования информационных систем. Эти же проблемы способствовали появлению программных технологических средств социального класса, так называемых case-средств (Computer Aided Software Engineering).

Case-средства реализует case-технология создания и сопровождения информационных систем.

Под термином «case-средства» понимают программные средства, поддерживающие этапы анализа и формулировки требований к системе, проектирование прикладного программного обеспечения и баз данных, автоматическую генерацию кода, тестирование, документирование, управление конфигурацией информационной системы и управление проектом.

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

Большинство существующих case-средств основано на методологиях структурного анализа и проектирования, которые используют спецификации в виде диаграмм для описания внешних требований, связи

51

между моделями, динамики поведения системы и архитектуры программных средств.

Использование case-средств дает разработчику следующие преимущества:

улучшает качество программного обеспечения за счет средств автоматического контроля проекта;

за короткое время можно получить прототип создаваемой системы. Это позволяет на ранних этапах проектирования оценить ожидаемый результат;

освобождает разработчика от рутинной работы; поддерживает сопровождение программного обеспечения.

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

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

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

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

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

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

52

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

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

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

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

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

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

Основные этапы подхода Мартина

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

53

Стратегическое

информационное

планирование

Анализ бизнес-процессов

Логическое

проектирование

системы

Физическое проектирование и реализация

Диаграммы декомпозиции, диаграммы "сущность-связь", матрицы информационного планирования.

Нормализованные модели данных, диаграммы зависимости данных, диаграммы декомпозиции, матрицы "сущностьпроцесс".

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

Рис. 2.4. Основные этапы подхода Мартина

Этап стратегического информационного планирования начинается с построения стратегического плана для бизнес-системы, включающего цели и стратегии их достижения. Далее строится модель предметной области, отражающая существующую специфику и определяющая основные бизнес-процессы и организационную структуру бизнес-системы, а также определяется порядок разработки информационной системы. При моделировании используются диаграммы декомпозиции (иерархические древовидные структурные диаграммы) и диаграммы «сущность–связь» для представления основных бизнес-процессов и структур данных, соответственно.

На этапе анализа основные бизнес-процессы, разработанные на этапе 1, используются для разбиения общей задачи на частные, при этом основное внимание уделяется определению информационной и функциональной моделей для частных задач. При этом диаграммы «сущность–связь» трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD, диаграммы зависимости данных (диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы «сущность–процесс».

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

54