3.2 Проведение анализа предметной области

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

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

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

Для описания поведения системы рекомендуется использовать диаграммы потоков данных (data flow diagrams). Эти диаграммы содержат 4 вида графических элементов:

• процессы, представляющие собой любые трансформации данных в рамках описываемой системы;

• хранилища данных;

• внешние по отношению к системе сущности;

• потоки данных между элементами трех предыдущих видов.

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

Диаграмма потоков данных должна быть приведена в приложении к РПЗ.

3.3 Проектирование программного средства

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

Примерный перечень этапов проектирования программного средства.

1 Проектирование архитектуры программного средства

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

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

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

1. Выделение компонентов.

• Выбирается набор «основных» сценариев использования — наиболее существенных и выполняемых чаще других.

• Определяются компоненты, отвечающие за определенные действия в рамках этих сценариев, т.е. за решение определенных подзадач.

• Каждый сценарий использования системы представляется в виде последовательности обмена сообщениями между полученными компонентами.

• При возникновении дополнительных хорошо выделенных подзадач добавляются новые компоненты, и сценарии уточняются.

2. Определение интерфейсов компонентов.

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

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

• Если интерфейсы недостаточны, они расширяются.

• Если интерфейс компонента слишком велик, или компонент отвечает за слишком многое, он разбивается на более мелкие.

3. Уточнение набора компонентов.

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

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

4. Достижение нужных свойств.

2 Концептуальное и логическое проектирование структуры информационного обеспечения

Успешное проектирование базы данных (БД) включает следующие шаги:

1. создание концептуальной модели;

2. трансформация концептуальной модели в логическую;

3. реализация проекта с использованием физической модели данных.

Концептуальное проектирование базы данных представляет собой процесс описания бизнес требований и данных с точки зрения пользователя.

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

• Объектно-ролевое моделирование — Object Role Modeling (ORM);

• «Сущность–связь» — Entity–Relationship (ER);

• Унифицированный язык моделирования — Unified Model Language (UML).

Логическая модель отражает структуру данных с точки зрения разработчика. На этом этапе определяется тип системы управления базами данных (реляционная, объектно–реляционная и т.д.), объекты БД, отношения между ними.

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

Если для отображения концептуального моделирования применялась ER–диаграмма, то она является и логической моделью.

Если для концептуального моделирования использовалась ORM или UML, то на данном шаге необходимо выполнить построение ER–диаграммы.

Концептуальная (если не совпадает с логической) и логическая модели данных выносятся в приложения к курсовому проекту.

3 Проектирование интерфейса программного средства

Проектирование пользовательского интерфейса основывается на следующих принципах.

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

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

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

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

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

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

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