Точно так же, как диаграмма потока данных иллюстрирует процессы, происходящие в системе, модель данных отображает взаимоотношения данных. Широко используется такая модель данных, как диаграмма «сущность - связь» (entity-relationship diagrams, ERD) (Wieringa:1996). Если диаграмма «сущность — связь» представляет логические группы информации предметной области и их взаимосвязи, вы используете диаграмму «сущность - связь» в качестве инструмента анализа требований. Анализ диаграммы «сущность - связь» понять и связать компоненты данных компании или системы, не подразумевая, что в продукт будет обязательно включена база данных. И наоборот, когда вы создаете эту диаграмму в ходе разработки системы, вы определяете логическую или физическую структуру базы данных системы.
Объектами (entities) называются физические элементы (включая людей) или агрегация элементов данных, важных для бизнеса, анализ которого вы выполняете, или для системы, которую вы планируете создать (Robertso и Robertson, 1994). Объекты называются посредством существительных в единственном числе, они показаны в прямоугольниках на диаграмме «сущность - связь». На Рис. 11-2 показана часть диаграммы «сущность - связь» для Chemical Tracking System с использованием одной из нескольких применяемых для диаграмм такого типа систем обозначений. Обратите внимание, что объекты «Запрос химиката», «Каталог поставщика» и «Товары на складе химикатов» на диаграмме потока данных на рис. 11-1 показаны в виде хранилища данных. Другие объекты представляют действующие лица, взаимодействующие с системой («Сотрудник, разместивший заказ на химикат»), физические элементы, являющиеся частью деловых операций («Контейнер с химикатом»), и блоки данных, которые не показаны на уровне 0 диаграммы потока данных, но показаны на ее более низком уровне («История контейнера», «Химикат»).
|
Каждый объект описывается несколькими атрибутами; у отдельных экземпляров объекта будут различные значения атрибутов. Например, в атрибуты каждого химиката включены уникальный химический идентификатор, строгое название химиката и графическое представление его химической структуры. В словаре данных приводятся детальные определения этих атрибутов — это гарантирует, что объекты на диаграмме «сущность - связь» и соответствующие им хранилища данных на диаграмме потока данных определены идентично.
Ромбы на диаграмме «сущность – связь» обозначают взаимоотношения (relationships), показывающие логические и числовую связь пар объектов. Названия взаимоотношениям даются в соответствии с природой соединений. Например, взаимоотношения между элементами «Сотрудник, разместивший заказ на химикат», и «Запросом химиката» определяются как размещение. Вы можете прочитать это взаимоотношения как «Сотрудник размещает Запрос на химикат» или как «Запрос на химикат размещен Сотрудником». Согласно некоторым правилам, фигуру в форме ромба следует назвать «размещен тем-то», что имеет смысл, только если читать диаграмму слева направо. Когда вы покажете клиентам диаграмму «сущность - связь», попросите их проверить, все ли взаимоотношения показаны корректно и соответствующим образом. Также попросите их определите все возможные взаимоотношения с объектами, которые не показаны на модели.
|
Рис. 11-2. Часть диаграммы «сущность - связь» для Chemical Tracking System
Количество элементов (cardinality) каждого взаимоотношения, или его множественность, показаны цифрой или буквой на прямых, соединяющих объекты и взаимоотношения. Для диаграмм «сущность – связь» используются различные правила для обозначения количества элементов; условные обозначения на рис. 11-2 используются наиболее часто. Поскольку каждый Сотрудник, разместивший заказ на химикат, может разместить несколько запросов, то между элементами «Сотрудник, разместивший заказ на химикат», и «Запрос химиката» существует связь «один ко многим». Количество элементов показано цифрой 1 на линии, соединяющей элемент «Сотрудник, разместивший заказ на химикат», и взаимоотношение «размещение», и буквой М (много) на линии, соединяющей элемент «Запрос химиката» и взаимоотношение «размещение». Ниже перечислены другие возможные случаи:
· один к одному (каждый контейнер с химикатом отслеживается в одной Истории контейнера);
· многие ко многим (в каждом каталоге поставщика содержится множество Химикатов, а некоторые Химикаты встречаются в нескольких Каталогах поставщика).
Если вам известно более точное количество элементов, чем просто много, вы можете указать вместо общего М конкретное число или диапазон.
Моделирование проблем, а не ПО Как-то я в качестве представителя специалистов по ИТ работал в команде, которая занималась модернизацией бизнес-процессов. Наша задача заключалась в снижении в 10 раз времени, необходимого для того, чтобы новый химикат оказывался доступным для использования в продукте. В команду были включены представители следующих подразделений компании, задействованных в коммерциализации химиката: · химиков-синтетиков, которые создали новое вещество; · химиков-технологов, разрабатывающих процесс промышленного производства вещества; · химиков-аналитиков, разрабатывающих методы проверки чистоты вещества; · патентных поверенных, которые занимаются патентной защитой изобретения; · специалистов отдела охраны труда и здоровья, получающих разрешение правительства на использование химиката в потребительских товарах. После того как мы разработали новый процесс, который по нашему мнению должен был необыкновенно ускорить коммерческое применение химиката, я опросил членов команды, ответственных за каждый этап процесса. Я задал каждому два вопроса: «Какая информация вам нужна для выполнения этого этапа?» и «Какую информацию, которая появится в результате выполнения этого этапа, следует сохранить?». Собрав и сравнив ответы, я выявил те этапы, информацию для которых не поставлял никто, а также этапы, выходная информация которых не была нужна никому. Мы разрешили эти проблемы. Затем я нарисовал диаграмму потока данных, чтобы проиллюстрировать новый процесс коммерциализации химиката и диаграмму «сущность - связь» для моделирования взаимоотношений данных. Все наши элементы данных были определены в словаре. Такие модели анализа будут полезны в качестве инструментов взаимодействия, которые помогут членам команды выработать общее понимание нового процесса. Кроме того, модели представляют собой прекрасную точку отсчета для разработки требований для приложений и определения их границ. |
|