Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Задачи и этапы предпроектного обследования).pdf

• механизмы означают средства, компоненты или инструменты, используемые для выполнения действия; представляют размещение (allocation) действий.

Семантика стрелок для данных (data):

• входы (Inputs) – это действия, которые генерируют эти данные (are activities that produce the data);

• выходы (Outputs) потребляют эти данные (consume the data);

• управления (Controls) влияют на внутреннее состояние этих данных (influence the internal state of the data).

Роли SADT-процесса: • авторы (Authors) – разработчики SADT модели;

• комментаторы (Commenters) – рецензируют (review) работу авторов;

• читатели (Readers) – возможные (the eventual) пользователи SADT диаграмм;

• эксперты (Experts) – те, от кого авторы получают специальную информацию о требованиях и ограничениях;

• технический комитет (Technical committee) – технический персонал, ответственный за рецензирование (reviewing) SADT модели на каждом уровне;

• библиотекарь проекта (Project librarian) – ответственный за все документы проекта;

• менеджер проекта (Project manager) – имеет полную техническую ответственность за системный анализ и проектирование (has overall technical responsibility the system analysis and design);

• аналитик (Monitor) (Chief analyst) – эксперт в области SADT, помогающий и консультирующий персонал проекта по использованию SADT;

• инструктор (Instructor) – обучает авторов и комментаторов SADT.

Этапы моделирования. Разработка SADT модели представляет собой итеративный процесс и состоит из нижеследующих условных этапов.

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

• что поступает в предметную область на «входе»;

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

• кто является ответственным за выполнение каждой из функций;

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

• что является результатом работы объекта (на выходе)? На основе полученных результатов опросов создается черновик модели (Model Draft).

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

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

Метод SADT получил дальнейшее развитие. На его основе в 1981 году разработана известная методология функционального моделирования IDEF0.

Методология функционального моделирования IDEF0

IDEF0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis). Модель IDEF0 – это графическое описание (информационной) системы или предметной области (subject), которое разрабатывается с определенной целью с выбранной точки зрения. Модель IDEF0 представляет собой набор из одной или более (иерархически связанных) IDEF0-диаграмм, которые описывают функции системы или предметной области (subject area) с помощью графики, текста и глоссария.

Применение IDEF0

IDEF0 используется для создания функциональной модели, то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0. Функциональная модель – это структурное представление функций, деятельности или процессов в пределах моделируемой системы или предметной области. Методология IDEF0 может быть использована для моделирования широкого спектра как автоматизированных, так и неавтоматизированных систем. Для проектируемых систем IDEF0 может быть использована сначала для определения требований и функций, и затем для реализации, удовлетворяющей этим требованиям и исполняющей эти функции. Для существующих систем IDEF0 может быть использована для анализа функций, выполняемых системой, а также для учета механизмов, с помощью которых эти функции выполняются.

Цели стандарта IDEF0

Основные цели (objectives) стандарта:

1) задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;

2) обеспечить средства для полного и единообразного (consistently) моделирования функций системы или предметной области, а также данных и объектов, которые связывают эти функции;

3) обеспечить язык моделирования, который независим от CASE методов или средств, но может быть использован при помощи этих методов и средств;

4) обеспечить язык моделирования, который имеет следующие характеристики:

• общий (generic) – для анализа как (информационных) систем, так и предметных областей;

• строгий и точный (rigorous and precise) – для создания корректных, пригодных к использованию моделей;

• краткий (concise) – для облегчения понимания, коммуникации, согласия между заинтересованными лицами и проверки. (to facilitate understanding, communication, consensus and validation);

• абстрактный (conceptual) – для представления функциональных требований, независимых от физических или организационных реализаций;

• гибкий – для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision). Правила IDEF0 требуют достаточной строгости и точности для удовлетворения нужд аналитика без чрезмерных ограничений (to satisfy needs without overly constraining the analyst). IDEF0 правила включают следующее:

• управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпозиции;

• связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей;

• связанность интерфейса диаграмм (Diagram Interface Connectivity) – наличие номеров узлов, функциональных блоков, С-номеров (C-numbers) и подробных ссылочных выражений (Detail Reference Expression);

• связанность структуры данных. (Data Structure Connectivity) – коды ICOM и использование круглых скобок (ICOM codes and the use of parentheses);

• уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий в метках и заголовках;

• синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;

• ограничения на разветвления стрелок данных (Data Arrow Branch Constraint) – метки для ограничений потоков данных на разветвлениях;

• разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);

• маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);

• наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;

• цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

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

Основные понятия IDEF0

В основе методологии лежат четыре основных понятия:

• функциональный блок;

• интерфейсная дуга;

• декомпозиция;

• глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис.). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение «Управление» (Control);

• левая сторона имеет значение «Вход» (Input);

• правая сторона имеет значение «Выход» (Output);

• нижняя сторона имеет значение «Механизм» (Mechanism).

ICOM. В IDEF0 принята система маркирования, позволяющая аналитику точно идентифицировать и проверять связи по стрелкам между диаграммами. Эта схема кодирования стрелок получила название ICOM – название по первым буквам английских эквивалентов слов вход (Input), управление (Control), выход (Output), механизм (Mechanism). ICOM – это коды, предназначенные для идентификации граничных стрелок, содержат префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер. Буква следует перед числом, определяющим относительное положение точки подключения стрелки к родительскому блоку; это положение определяется слева направо или сверху вниз.

Основной ICOM-код – это узловой номер, который появляется там, где выполняется декомпозиция функционального блока и создается его подробное описание на дочерней диаграмме. Все остальные ссылочные коды базируются на узловых номерах. Например, код «C3», написанный возле граничной стрелки на дочерней диаграмме, указывает, что эта стрелка соответствует третьей (слева) управляющей стрелке родительского блока. ICOM-коды представляют собой ссылочные выражения, которые присваиваются всем элементам модели: диаграммам, блокам, стрелкам и примечаниям. Коды используются в различных контекстах для точного указания на нужный элемент модели. Например, кодирование связывает каждую дочернюю диаграмму со своим родительским блоком. Если блоки на дочерней диаграмме подвергаются дальнейшей декомпозиции и подробно описываются на дочерних диаграммах следующего уровня, то на каждую новую диаграмму назначаются новые ICOM коды, связывающие граничные стрелки этих диаграмм со стрелками их родительских блоков. Иногда буквенные ICOM-коды, определяющие роли граничных стрелок (вход, управление, механизм), могут меняться при переходе от родительского блока к дочерней диаграмме. Например, управляющая стрелка в родительском блоке может быть входом на дочерней диаграмме. Аналогично, вход родительского блока может быть управлением для одного или более дочерних блоков. Коды ICOM позволяют:

• быстро проверять согласованность внешних стрелок диаграммы с граничными стрелками соответствующего блока родительской диаграммы;

• связывать граничные стрелки на дочерней диаграмме со стрелками родительского блока;

• обеспечивать согласованность декомпозиции, поскольку все стрелки, входящие в диаграмму и выходящие из нее, должны быть учтены;

• обеспечивать требуемую строгость;

• создавать совокупность неявных связующих звеньев между страницами, которые можно быстро изменить при изменении границ;

• облегчать процесс чтения и рецензирования IDEF0-диаграмм;

• облегчать проверку согласованности декомпозиции;

• упрощать внесение локальных изменений в диаграмму;

• объединять различные варианты диаграмм в модели.

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

1) прежде чем составлять список данных, записать имена и коды для всех стрелок, образующих границу. Это поможет при декомпозиции уменьшить вероятность пропуска части граничных стрелок;

2) аналитик должен представить себе рисунок новой диаграммы как бы внутри декомпозируемого блока;

3) зрительно продлить внешние стрелки почти до края диаграммы и зрительно соединить каждую внешнюю стрелку диаграммы с соответствующей граничной стрелкой декомпозируемого блока;

4) присвоить код каждой зрительной связи (I -для входных стрелок, С – для связей между стрелками управления, О – для связей между выходными стрелками, М – для связей между стрелками механизма;

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

6) записать каждый код около окончания каждой внешней стрелки;