Требования к данным

Требования к данным Ценность информационных систем заключается в том, что они предоставляют возможность манипулировать данными. Используйте этот раздел шаблона для описания различных аспектов данных, которые будет потреблять система в качестве входной информации, как-то обрабатывать и возвращать в виде выходной информации. Можно описать много схем для точного документирования данных (которые также называют информацией). Компьютерные системы работают с данными так, чтобы это приносило пользу клиентам. Хотя они и явно непоказаны на трехуровневой модели требований, но требования к данным охватывают все три уровня. Всюду, где есть функции, есть данные. Независимо от того, как представлены данные — пиксели в видеоигре, пакеты в вызове сотового телефона, квартальные показатели вашей компании, операции банковского счета или что-либо другое, функциональность программы создается для создания, изменения, отображения, удаления, обработки и использования данных. Бизнес-аналитик должен начинать собирать определения данных по мере того, как они появляются в процессе выявления требований. Хорошей отправной точкой являются входной и выходной потоки на контекстной диаграмме системы. Эти потоки представляют главные элементы данных на высоком уровне абстракции, которые бизнес-аналитик должен преобразовать в подробности требований в процессе их выявления. Существительные, которые пользователи упоминают в процессе выявления требований, часто указывают на важные сущности данных: заказ химиката, сотрудник, химикат, состояние, отчет об использовании химиката. Здесь описываются приемы анализа и представления данных, которые важны для пользователей вашего приложения, а также способы определения отчетов и панелей мониторинга, которые должно создавать ваше приложение. Логическая модель данных Модель данных — это визуальное представление объектов и наборов данных, которые будет обрабатыватьсистема, а также отношений между ними. Существует много видов нотации для моделирования данных, в том числе диаграммы отношений «сущность–связь» и диаграммы классов UML. Можно включить модель данных для бизнес-операций, выполняемых системой или логическое представление данных, с которыми будет работать система. Это не то же самое, что модель данных реализации, которая реализуется в виде дизайна базы данных. Модель данных предоставляет высокоуровневое представление данных системы, а словарь данных дает подробную картину. Диаграмма вариантов использования Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом сценарием варианта использования или потоком событий (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку. Достоинства модели вариантов использования заключаются в том, что она:  определяет пользователей и границы системы;  определяет системный интерфейс;  удобна для общения пользователей с разработчиками;  используется для написания тестов; является основой для написания пользовательской документации; хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные). Активный субъект (actor ) отождествляется с чем-то или с кем-то, взаимодействующим с системой,т.е. играет определённуюрольпо отношению к системе, это может быть не обязательно пользователь будущей системы, так же это может быть внешняя система. Варианты использования (use cases) позволяют моделировать диалог между активным субъектом и системой и отображают функции системы. С каждым вариантом использования связан определенный поток событий, происходящих по мере выполнения соответствующих функций системы. При описании потока событий определяется, что необходимо осуществить, и игнорируются аспекты того, как это делается. Между активным субъектом и вариантом использования устанавливаются связь ассоциация (association relationship), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного вариантаиспользования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия. Помимо связей между субъектом и вариантом использования, связи могут устанавливаться и между вариантами использования. Связи бывают двух типов - включающими (inclusive) и расширяющими (extensive). ПРИМЕР Описание процесса работы будет произведено на примере приложения «АСУ Склад». Предприятие производит оптовую реализацию промышленной продукции широкого ассортимента. Поставщиками компании выступают заводы и фабрики, находящиеся на территории РФ. Клиенты предприятия – предприниматели, фирмы и др. организации, осуществляющие розничную и мелкооптовую продажу. Постановка задачи на проектирование информационной системы Проектируемая система обязана производить учет и контроль движения продуктов на складе. Автоматизировать процесс выписки накладных, счётов и других документов. Описание бизнес-процесса «Реализация продукции со склада» Клиент, решивший оформить заказ на поставку продукции, обращается в офис предприятия. Менеджер согласовывает с клиентом все условия по оформлению заказа. При этом менеджер обязан проверить наличие на складе каждого из заявленных продуктов. В случае если все затребованные клиентом позиции продуктов есть в наличии, либо клиентом приняты альтернативные варианты, заказ передается в бухгалтерию, и клиенту предлагается его оплатить. Если клиент оплачивает заказ по наличному расчету, то после оплаты бухгалтер сразу выписывает две товарно-транспортные накладные, которые передаются клиенту. После получения накладной клиент прибывает на склад за своим товаром. Кладовщик выдает необходимые продукты и делает отметку в обоих экземплярах накладной о том, что груз выдан. Далее, клиент расписывается в двух экземплярах накладной и отбывает с полученным товаром и одним экземпляром накладной. Второй экземпляр накладной остается у кладовщика. Для создания диаграммы вариантов использования необходимо: 1. Создать usecase диаграмму с именем «Основная функциональность» 2. Проанализировать какие активные субъекты должны взаимодействовать с будущей системой. 3. Создать actor’ов. (Например, Менеджер, Бухгалтер и Кладовщик). 4. Создать прецеденты. Например,  Оформление заказа.  Оформление счёта.  Оформление накладной.  Выдача товара. 5. Для пояснения можно использовать комментарии. 6. Расставить связи, обозначающие зависимость (необходимо продумать, какие прецеденты находятся в отношении зависимости). 7. Результатом является подобная диаграмма: Диаграмма классов Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Вид и интерпретация диаграммы классов существенно зависит от точки зрения (уровня абстракции): классы могут представлять сущности предметной области (в процессе анализа) или элементы программной системы (в процессах проектирования и реализации). Основные элементы диаграммы классов Основными элементами являются классы и связи между ними. Классы характеризуются при помощи атрибутов и операций. Атрибуты описывают свойства объектов класса. Большинство объектов в классе получают свою индивидуальность из-за различий в их атрибутах и взаимосвязи с другими объектами. Однако, возможны объекты с идентичными значениями атрибутов и взаимосвязей. Т.е. индивидуальность объектов определяется самимфактом их существования, а не различиями в их свойствах. Имя атрибута должно быть уникально в пределах класса. За именем атрибута может следовать его тип и значение по умолчанию. Операция есть функция или преобразование. Операция может иметь параметры и возвращать значения. Виды связей:  ассоциация  агрегация  наследование. Ассоциация (association) – представляет собой отношения между экземплярами классов. Каждый конец ассоциации обладает кратностью (синоним – мощностью, ориг. — multiplicity), которая показывает, сколько объектов, расположенных с соответствующего конца ассоциации, может участвовать в данном отношении. В примере на рисунке каждый Товар имеет сколь угодно Записей в накладной, но каждая Запись в накладной обязательно один Товар. В общем случае кратность может быть задана любым множеством. Ассоциации может быть присвоено имя. В качестве имени обычно выбирается глагол или глагольное словосочетание, сообщающие смысл и назначение связи. Также, на концах ассоциации под кратностью может указываться имя роли, т.е. какую роль выполняют объекты, находящиеся с данного конца ассоциации. Агрегация (aggregation) – это ассоциация типа «целое-часть». Агрегация в UML представляется виде прямой с ромбом на конце. Ромб на связи указывает, какой класс является агрегирующим (т.е. «состоящим из»), — класс с противоположного конца — агрегированным (т.е. те самые «части»). Композиция (composition) – это такая агрегация, где объекты-части не могут существовать сами по себе и уничтожаются при уничтожении объекта агрегирующего класса. Композиция изображается так же, как ассоциация, только ромбик закрашен. Важно понимать разницу между агрегацией и композицией: при агрегации объекты-части могут существовать сами по себе, а при композиции — нет. Пример агрегации: автомобиль—колесо, пример композиции: дом—комната. Наследование (inheritance) – это отношение типа «общее-частное». Позволяет определить такое отношение между классами, когда один класс обладает поведением и структурой ряда других классов. При создании производного класса на основе базового (одного или нескольких) возникает иерархия наследования. Реализация принципов наследования является ключевой предпосылкой возможности повторного использования кода, поскольку это основной инструмент достижения полиморфизма. Диаграмма состояний Диаграмма состояний (Statechart diagram) показывает, как объект переходит из одного состояния в другое. Диаграммы состояний служат для моделирования динамических аспектов системы. Данная диаграмма полезна при моделировании жизненного цикла объекта. От других диаграмм диаграмма состояний отличается тем, что описывает процесс изменения состояний только одного экземпляра определенного класса - одного объекта, причем объекта реактивного, то есть объекта, поведение которого характеризуется его реакцией на внешние события. ПРИМЕР На диаграмме состояний можно отобразить следующие элементы нотации UML: