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

Техническое задание.

Важной проблемой разработки является недопонимание между заказчиком и исполнителем. Данная проблема может привести к излишним затратам одной или обеих сторон. Техническое задание позволяет минимизировать данные затраты.

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

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

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

Согласно ГОСТ 34.602−89 технического задание должно содержать следующие пункты:

• 1. Общие сведения.
• 2. Назначения и цели создания системы.
• 3. Характеристика объектов автоматизации.
• 4. Требования к системе.
• 5. Состав и содержания работ по созданию системы.
• 6. Порядок контроля и приема системы.
• 7. Требование к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
• 8. Источники разработки.

Концептуальная модель.

«Концептуальная модель — это отражение предметной области, для которой разрабатывается база данных. 1».

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

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

Первая нормальная форма.

Для привидения базы данных к первой нормальной форме необходимо:

• 1. Первичный ключ должен быть уникальным для каждого экземпляра сущности базы данных.
• 2. Атомарность. Поля не должны иметь дубликатов и должны содержат только одно значение.
• 3. Порядок записи данных в таблицу не должен иметь значения.

Вторая нормальная форма.

Для приведения базы данных ко второй нормальной форме необходимо:

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

Третья нормальная форма.

Для приведения базы данных к третьей нормальной форме необходимо:

1. Привести базу данных ко второй нормальной форме.

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

IDEF1X.

«IDEF1X — это методология семантического моделирования данных.

Она разработана с учетом следующих требований:

1. Поддерживает разработку концептуальных схем Синтаксис IDEF1X поддерживает семантические конструкции, необходимые для разработки концептуальной схемы. Окончательная версия IDEFlX-модели обладает желаемыми характеристиками — непротиворечивостью, расширяемостью и адаптируемостью.

2. Обеспечивает ясный язык.

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

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

4. Надежно проверена на практике.

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

5. Возможность автоматизации.

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

IDEF1X использует подход сущностей-отношений к семантическому моделированию данных. Исходная разработка IDEF1 заключалась в расширении понятий сущности-отношения по методу П. Ченна, объединенных с понятиями реляционной теории Т. Кодда. Кроме того, для улучшения графического представления и процедур моделирования IDEFlX — методология семантически обогащена введением отношений категоризации (называемых также отношениями обобщения). Язык IDEF1X включает коммерческие разработки D. Appleton Company и The Database Design

Group.".

Сущности.

Зависимые и независимые сущности.

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

Правила:

• 1. Сущность должна иметь уникальное имя.
• 2. Обладать как минимум одним атрибутом.
• 3. Обладать уникальным атрибутом — ключом, по которому можно однозначно идентифицировать экземпляр сущности.

Атрибуты.

Типы атрибутов:

• 1. Простой (атомарный) — состоит из одного компонента.
• 2. Составной — состоит из нескольких компонентов.
• 3. Однозначный — содержит одно значение.
• 4. Многозначный — содержит несколько значений.
• 5. Производный — значения атрибута может быть определенно по значениям других атрибутов.
• 6. Ключевой — уникальный для каждого экземпляра сущности атрибут и служащий для идентификации экземпляра.
• 7. Не ключевой — не служит для идентификации экземпляра.
• 8. Обязательный — значение данного атрибута не может быть NULL.

Ключи.

• 1. Суперключ (superkey) — атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности.
• 2. Потенциальный ключ (potential key) — минимальный набор атрибутов для идентификации экземпляра сущности. Сущность может состоять из нескольких потенциальных ключей.
• 3. Первичный ключ (primary key) — потенциальный ключ, выбранный для идентификации экземпляра сущности.
• 4. Альтернативный ключ (alternative key) — потенциальные ключи, которые не выбраны как первичный ключ.
• 5. Внешний ключ (foreign key) — атрибут или множество атрибутов соответствующих первичному ключу родительской сущности, необходим для моделирования связи.

Связи.

Параметры связи:

• 1. Наименование — глагол определяющий семантику связи.
• 2. Кратность — отображает со сколькими экземплярами другой сущности может взаимодействовать экземпляр сущности.
• 3. Идентифицирующая — связи при которой внешний ключ входит в состав первичного ключа дочерней сущности.
• 4. Обязательная — при создании экземпляра дочерней сущности обязательно заполнение атрибутов внешнего ключа.
• 5. Степень участья — количество сущностей участвующих в связи. Для IDEF1X диаграммы используются унарные и бинарные связи, то есть между одной или двумя сущностями.

Use Case.

«Диаграмма вариантов использования (Use Case diagram — в русскоязычных источниках называется иногда диаграммой прецедентов) — это форма представления концептуальной модели проектируемой системы, которая описывает ее функциональное назначение и в дальнейшем будет детализирована и преобразована в модели логического и физического уровней. 3».

Система — это совокупность элементов для выполнения поставленной задачи.

Подсистема — это система входящая в состав другой системы.

На Use Case диаграмме система отображается в виде прямоугольника, а подсистема в виде прямоугольника вписанного в прямоугольник системы.

Между вариантами использования так же могут быть связи.

Включение. Указывает, что вариант использования включает другой вариант использования.

На Use Case диаграмме отображается в виде пунктирной стрелки с припиской .

Расширение. Указывает, что вариант использования будет расширен другим вариантом использования.

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

На Use Case диаграмме отображается в виде линии с не залитой стрелкой.

При составлении Use Case диаграммы следует придерживаться следующих правил:

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

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