Этапы проектирования ИС с применением UML

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм.

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

На этапе описания бизнес-объектов используются – модели бизнес-объектов и диаграммы последовательностей.

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

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

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

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

• Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде.
• Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.
• Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).
• Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.
• Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.
• Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.
• Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.
• Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.

На рис. 3.10 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..." (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности).

Рис. 3.10. Взаимосвязи между диаграммами UML

Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML.

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

Основные задачи этапа:

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

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

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

Пример диаграммы классов, описывающей процедуры защиты доступа к данным, приведен на рис. 3.11.

Рис. 3.11.Диаграмма классов "Защита доступа"

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

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

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

Процесс сбора и анализа требований включает следующие шаги:

• анализ и формирование программных требований;
• определение архитектуры ИС;
• определение ограничений реализации ИС;
• анализ архитектуры аппаратного обеспечения, коммуникаций.

3.5. Анализ и формирование требований к ИС

Функциональные требования

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

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

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

Функциональные требования, как минимум должны включать:

• общесистемные требования, согласованные всеми заинтересованными представителями бизнес-процессов:

- характеристику ИС;

- основные цели создания ИС и ее назначение;

- планируемое развитие ИС;

- требования к ИС в целом;

- требования к структуре данных ИС;

- требования к функциональности ИС;

- требования к интерфейсу пользователя;

- требования к отчетам;

- требования к средствам администрирования;

- требования к средствам разработки;

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

- требования к документированию;

- требования к программному и аппаратному обеспечению по объему требуемых ресурсов, быстродействию, надежности.

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

- документирование форматов входных и выходных данных;

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

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

- методы обнаружения и исключения ошибочных транзакций по ходу их обработки;

- средства, поддерживающие неотказуемость транзакций;

• формализованные требования, согласованные всеми заинтересованными представителями бизнес-процессов:

- описание детальных спецификаций ПО в части функциональности системы;

- требования к разработке и документированию интерфейсов с внутренними подсистемами;

- требования к разработке и документированию алгоритмов обработки данных;

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

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

Требования к внешним интерфейсам ИС, в зависимости от конкретных условий эксплуатации, включают:

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

Нефункциональные требования

Нефункциональные требования должны быть использованы для определения требований и ограничений ИС. Требования должны быть использованы в качестве основы на ранней стадии выполнения проекта по созданию системы и оценки ее жизнеспособности.

Нефункциональные требования включают:

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

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

Основные требования пользователей к информационным системам

ИС должны обеспечивать:

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

Требования к ИС пользователей должны быть документированы и необходимо проверять соответствие работ по следующим категориям систем:

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

Общими требованиями к ИС являются:

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

Требования по обеспечению информационной безопасности

Информационная безопасность в ИС должна обеспечиваться организационно–техническими и аппаратно – программными средствами.

Программно – аппаратные средства защиты информации должны быть лицензионными, сертифицированными и обеспечивать:

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