SADT диаграммыГрафическое представление блочного моделирования. Графика SADT – диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами. Взаимодействие блоков друг с другом описывается посредствам интерфейсных дуг. Интерфейсные дуги выражают «ограничения», которые определяются, когда и каким образом выполняются и управляются. Различаются следующие типы связи в порядке возрастания их значимости: - случайная связь (показывает, что конкретная связь между функциями не значительная или отсутствует) - логическая связь (когда функции отображаются на одной диаграмма благодаря тому, что они попадают в общий класс или в общий набор элементов, хотя каких-то функциональных элементов между ними нет) - Временная связь (когда данные используются одновременно и функции включаются параллельно, а не последовательно) - Процедурная связь (когда функции группируются вместе, потому что выполняются в течение одного и того же процесса) - коммуникационная связь (когда функции группируются благодаря тому, что производят одни и те же входные данные) - последовательная связь (когда выход одной функции служит входом для следующей функции) - функциональная связь (когда все элементы функции влияют на выполнение одной и только конкретной функции) DFD диаграммы – диаграммы потоков данных. С помощью диаграмм потоков данных, требования к проектируемой системе представляются в виде иерархии процессов связанных потоками данных. Главная цель такого представления показать, как каждый процесс преобразует свои входные данные в выходные, и выявить отношения между этими процессами. Характерные компоненты: - Внешняя сущность – объект находится вне системы, но система передает ему данные или получает от него, - Процесс представляется собой преобразования входных потоков в выходные, в соответствие с определенными алгоритмом. Цель построения диаграммы DFD – сформулировать ясные и понятные требования на каждом уровне детализации и разбить эти требования на части с точно определенными отношениями между ними. Требования к диаграммам: - Размещать на каждой диаграмме от 3 до 6-7 процессов - декомпозицию потоков данных выполнять одновременно с декомпозицией процессов, - выбирать название для потоков и процессов, отражающих суть процесса или потока, - диаграмма не должна содержать деталей не существенных для этого уровня. После получения построения модели ее следует проверить на полноту исходных данных об объектах и на отсутствие информационных связей с другими объектам. Конечной целью построения является спецификация – точное описание требований, сформулированное в терминах характерных для целей задачи, а не для реализации. Решение о завершение детализации принимается исходя из следующих критериев: - наличие у процесса не большого количества входных и выходных потоков (2-3 потока), - возможность описания преобразования данных в виде последовательного алгоритма, - возможность описания логики процесса при помощи спецификации не большого объема (20-30 строк), - выполнения процесса единственной логической функцией преобразования входной информации в выходную. Спецификации должны соответствовать следующим требований: - для каждого процесса нижнего уровня может быть одна и только 1 спецификация - спецификация должна определять способ преобразования входных потоков в выходные. - в ней не должно быть метода реализации - набор конструкций для построения спецификации должен быть простым и понятным. Спецификация содержит – номер или/и имя процесса, списки входных и выходных данных, тело (описание процесса). Для описания спецификаций используется структурированный естественный язык, в состав этого языка входит – глаголы, ориентированные на действие, термины – которые определены на любой стадии проекта, предлоги и союзы, используемые в логических отношениях, так же допустимы общеупотребительные математические, физические термины, арифметические уравнения, таблицы, диаграммы, графики, допустимы комментарии. При использование языка принимаются следующие соглашения: 1. логика процесса выражается в виде комбинации, 1.1. последовательной конструкции, 1.2. конструкции выбора, 1.3 Итерации 2. Глаголы должны быть активными, не двусмысленными и ориентированными на целевое действие (вычислить, заполнить, извлечь). 3. Логика процесса должны быть выражена четко и не двусмысленно, что бы все одинаково понимали что делается с помощью этого процесса. ERD модель. Она была предложена Питером Ченом в 1976 году. Базовыми понятиями этой конструкции является: сущность, атрибут и связь. Сущность – совокупность реальных или абстрактных объектов предметной области обладающих одинаковым набором свойств. Для сущностей имеет место следующее соглашение: - Каждая сущность должна иметь уникальное имя, - Сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности либо наследуются через связи с другими сущностями, - Совокупность атрибутов сущности с их конкретными значениями однозначно идентифицирует каждый экземпляр сущности, - Каждая сущность может обладать любым количеством связей с другими сущностями. Атрибут – это некоторое свойство сущности. Характерные правила: - каждый атрибут должен иметь уникальное имя, - каждый атрибут принадлежит только одной сущности, - атрибуты могут наследоваться от других сущностей, но наследуемый атрибут должен быть либо первичным ключом, либо частью этого ключа, (ключ – это атрибут который однозначно характеризует сущность), - для каждого экземпляра сущности должно существовать значение каждого атрибута. Связь – это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным, в том числе нулевым количеством экземпляров второй сущности и наоборот, связь обычно выражается глаголом. IDEF. IDEF0 - методология функционального моделирования. Представляет собой набор взаимосвязанных функций. IDEF1 - методология моделирования информационных потоков, которая позволяет отображать и анализировать их структуру и взаимосвязи IDEF1X – методология построения реляционных структур «сущность-взаимосвязь», для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе. IDEF2 - методология динамического моделирования систем. IDEF3 – документирование технологических процессов, методология документирования процессов, происходящих в системе, описывающая сценарии и последовательность операций для каждого процесса. IDEF4 – методология построения объектно-ориентированных систем, позволяет отражать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы. IDEF5 – стандарт онтологического исследования сложных систем. Система может быть описана при помощи словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии системы в некоторый момент времени. IDEF6 - обоснование проектных действий. Назначение в облегчении получения знаний о способе моделирования при разработке систем управления предприятиями. «Почему модель получилась такой». IDEF7 – аудит информационной системы. IDEF8 - метод разработки интерфейсов взаимодействия операторов и системы. Стандарт фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции, сценарии взаимодействия, детали взаимодействия. IDEF9 – метод исследования и бизнес ограничений для обнаружение и анализа ограничений в условиях которых действует предприятие. IDEF10 – моделирование архитектуры выполнения. IDEF11 – information artifact modeling IDEF12 – организационное моделирование IDEF13 - трехсхемное проектирование преобразования данных. IDEF14 – метод проектирования компьютерных сетей, основанный на анализе требований специфических сетевых компонентов, существующих конфигураций сетей. Обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.
|
