Idef — Инструментарий для моделирования архитектуры предприятия


Содержание

Моделирование архитектуры предприятия. Обзор языка ArchiMate

Проект создания ArchiMate

Язык ArchiMate был разработан в Нидерландах в рамках исследовательского проекта, возглавляемого Telematica Instituut 1 , в сотрудничестве с рядом организаций и университетов. Финансирование осуществлялось голландским правительством, банком ABN AMRO, пенсионным фондом Stichting Pensioenfonds ABP и Centrum voor Wiskunde en Informatica 2 . После завершения проекта язык ArchiMate был опробован и использован в таможенной и налоговой администрации Нидерландов, ABN AMRO и ABP Pension Fund [2, 3].

В 2008 году право собственности и дальнейшего развития ArchiMate было передано одной из ведущих организаций по разработке открытых и независимых от поставщиков ИТ-стандартов — консорциуму The Open Group, активно развивающего стандарт архитектуры предприятия TOGAF [9] 3 . В феврале 2009 года в качестве технического стандарта была опубликована первая версия языка The ArchiMate 1.0 Specification. В 2012 году вышла вторая версия The ArchiMate 2.0 Specification, а также была введена сертификационная программа, которая включает сертификацию специалистов, аккредитацию обучающих курсов и сертификацию программных средств, поддерживающих стандарт языка ArchiMate. Сейчас действует модификация второй версии стандарта The ArchiMate 2.1 Specification, опубликованная в 2013 году [4]. О ней и пойдет речь в статье 4 .

Исходные положения при создании языка

Созданию языка ArchiMate предшествовала большая информационно-аналитическая работа, в ходе которой был проведен анализ сложившейся практики разработки архитектуры предприятия и определены потребности заинтересованных сторон в проектировании, коммуникациях и представлении, реализации и управлении изменениями архитектуры предприятия [5].

В конечном итоге в ходе всестороннего анализа целей и требований удалось сформулировать исходные положения, которых разработчики придерживались при создании языка, и основные свойства, которыми должен обладать язык описания архитектуры общего назначения [4, 5]:

  • сервисная ориентированность языка — понятие «сервис» удобно и наглядно для представления взаимодействий внутри системы 5 или между системами. К тому же, сервисы уже используются в разных предметных областях и понятны различным заинтересованным сторонам;
  • послойное строение языка — заимствование из архитектурных фреймворков точки зрения на предприятие как на систему различных систем, образующих слои (уровни) представления предприятия;
  • связность языка — введение в состав языка набора четко определенных отношений, которые устанавливают связи и зависимости как внутри предметных областей, так и между ними;
  • компактность языка — ограничение набора понятий языка таким образом, чтобы, оставаясь простым и доступным, язык был достаточным для моделирования 80 % архитектурных задач;
  • язык уровня предприятия — акцент на более крупный уровень детализации, чем в языках, используемых для моделирования на более низких уровнях (например, UML — для моделирования приложений, BPMN — моделирование бизнес-процессов);
  • совместимость языка — совместимость понятий языка с понятиями языков на других уровнях моделирования, например, понятия проектного управления должны без затруднений выражаться более общими понятиями архитектурного языка;
  • прагматичность — максимальное использование понятий и конструкций из других языков там, где это возможно;
  • расширяемость языка — определение механизмов и средств расширения понятий, входящих в ядро языка, для отражения специфики исследуемых предметных областей;
  • независимость языка от конкретных архитектурных фреймворков и методологий.

Базовые понятия языка — элементы и отношения

К базовым понятиям языка относятся понятия «элемент» и «отношение» [4, 5]. Именно на основе элементов и отношений строятся описания (создаются модели) предприятия или его отдельных частей. Элементы — это «кирпичики» различного содержания, формы и предназначения, а отношения — различного рода соединения, связывающие элементы.

Элементы. Элементы в языке различаются по трем признакам, или аспектам (рис. 1) [4]:

Рис. 1. Метамодель — основные понятия языка.

  • структурный/поведенческий;
  • внешний/внутренний взгляд на систему;
  • индивидуальный/коллективный.

Первый аспект разделяет элементы языка на три типа: активный структурный элемент, пассивный структурный элемент и элемент поведения.

  1. Активный структурный элемент (active structure element) определяется как некая сущность, которая способна выполнять определенные действия. Это могут быть бизнес-исполнители, компоненты приложений или устройства, которые реально исполняют те или иные действия.
  2. Пассивный структурный элемент (passive structure element) определяется как некоторый объект, на котором выполняются действия. Обычно это информационные объекты или объекты данных, также они могут быть использованы для представления физических объектов, над которыми выполняются те или иные действия.
  3. Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.

Элементами поведения являются процессы, функционалы (функции), сервисы и события. Они назначаются активным структурным элементам, чтобы показать, кто или что производит те или иные действия. Следует отметить, что разделение элементов по аспекту «структурный/поведенческий» похоже на структуру человеческих языков, в которых в состав предложений входят существительное-подлежащее (в ArchiMate — активный структурный элемент, то есть субъект поведения), глагол-сказуемое (элемент поведения, то есть выполнение поведения) и существительное-дополнение (пассивный структурный элемент, то есть объект, на котором выполняется поведение).

Пример 1. Использование элементов «бизнес-исполнитель», «бизнес-роль», «бизнес-процесс» и «бизнес-сервис» 6 .

В модели показана страховая компания, которая представляется как бизнес-исполнитель. В ее состав входят два отдела — отдел страхования багажа и отдел страхования поездок (рис. 2). Отделу страхования поездок назначена бизнес-роль по продаже соответствующих страховок — «Продавец страховок на поездки». В этой роли отдел страхования поездок выполняет бизнес-процесс по выписыванию страхового полиса — «Выписать страховку на поездку». Данный бизнес-процесс реализует бизнес-сервис страхования поездок, который предоставляется потребителю.

Рис. 2. Пример использования элементов «бизнес-исполнитель», «бизнес-роль», «бизнес-процесс» и «бизнес-сервис».

Второй аспект различает внешний и внутренний взгляды на систему, и на этой основе вводятся понятия «сервис» и «интерфейс» (рис. 1.).

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

Сервисы являются основными связующими звеньями между различными слоями. Например, приложение обеспечивает сервисы для слоя бизнес-процессов и, в свою очередь, использует сервисы инфраструктурного слоя. Исходя из этого, различают внутренние и внешние сервисы. Внутренние сервисы — это сервисы, доступные внутри данного слоя; внешние сервисы — это сервисы слоя, доступные извне данного слоя. В таблице 1 суммируется разделение элементов на структурные/поведенческие и на внешние/внутренние, которое играет центральную роль в языке [9].

Таблица 1. Распределение элементов языка по аспектам структурный/поведенческий и внешний/внутренний.

Пример 2. Использование элементов «функционал приложений», «сервис приложений» и «интерфейс приложений».

В модели показано, что сервис приложений «Сервис обработки транзакций» реализуется функционалом приложений «Учет» и доступен другим компонентам через интерфейс приложений «API обработки транзакций» (рис. 3). Функционал приложений «Учет» выполняется компонентом приложений «Компонент учета». Сервис приложений «Обработка транзакций» используется функционалом приложений «Биллинг», который выполняется компонентом приложений «Компонент биллинга». Функционал приложений «Биллинг» предлагает сервис приложений «Сервис создания накладной», который может быть использован для поддержки бизнес-процессов. Данный сервис доступен через интерфейс приложений «Экран биллинга».

Рис. 3. Использование элементов «функционал приложений», «сервис приложений» и «интерфейс приложений».

Пример 3. Продукт, состоящий из нескольких бизнес-сервисов.

В модели показан продукт «Телебанкинг», предлагаемый клиентам (рис. 4). Открытие счета и поддержка приложений (например, helpdesk и т. п.) осуществляется соответствующими бизнес-сервисами, которые реализуются бизнес-исполнителем «Клиентский отдел». Как часть продукта потребитель может также использовать банковский сервис, который предлагает такие сервисы приложений, как электронный денежный перевод и предоставление статуса счета. Сервисы приложений реализуются компонентом приложений «Телебанкинг».

Рис. 4. Продукт, состоящий из нескольких бизнес-сервисов.

Третий аспект учитывает то, что определенное действие (поведение) может выполняться одним структурным элементом и коллективом, то есть совместно несколькими структурными элементами (например коллективом сотрудников). Соответственно выделяют активный структурный элемент «совместная бизнес-деятельность» и элемент поведения членов этого коллектива — «взаимодействие».

  1. Совместная деятельность (collaboration) определяется как группировка (или объединение) — возможно, временная — двух или более структурных элементов для выполнения некоторого совместного поведения.
  2. Взаимодействие (interaction) определяется как единица поведения, выполняемая в рамках совместной деятельности двух или более структурных элементов.

Пример 4. Использование элемента «совместная бизнес-деятельность».

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

Рис. 5. Использование элемента «совместная бизнес-деятельность».

Отношения. Отношения в языке — это различного рода соединения, связывающие элементы и определяющие свойства этих соединений (например, физические/логические, между структурными элементами и элементами поведения). Отношения в языке разделяются на три группы: структурные, динамические и другие.

  • Структурные отношения — это отношения, которые моделируют структурные зависимости между элементами одного или разных типов.
  • Динамические отношения — это отношения, которые используют для моделирования зависимостей между элементами поведения (действиями).
  • В группу «другие» относят отношения, которые не входят в первые две группы. Многие из отношений были заимствованы из существующих стандартов: например, композиция (composition), объединение (aggregation), ассоциация (association) и специализация (specialization) взяты из UML 2.0, а запуск (triggering) используется во многих языках моделирования бизнес-процессов.

Полный перечень элементов и отношений, образующих ядро языка ArchiMate, представлен соответственно в приложениях 2 и 3 в конце статьи. Эти типы элементов и отношений поддерживают моделирование архитектур на фазах B (Бизнес-архитектура)), C (Архитектура информационных систем) и D (Технологическая архитектура) метода разработки архитектуры TOGAF.

Слои языка

Обычно архитектурные описания делают для различных областей, или так называемых «слоев» организации. Эти области называют слоями в том смысле, что более нижние слои обеспечивают функциональность более высоким. В этом контексте для описания предприятия в языке определяются три основных слоя: бизнес-слой, слой приложений и технологический слой [4]. Они хорошо соотносятся с фазами TOGAF и с соответствующими архитектурами — B (Бизнес-архитектура), C (Архитектура информационных систем) и D (Технологическая архитектура). В каждом слое используется общая концепция элементов языка (с их аспектами) и отношений. Это позволяет выделить в слоях несколько доменов, описывающих различные предметные области в рамках слоя. Соотношение слоев, элементов и отношений языка и архитектурных доменов показано на рисунке 6 [6, 7].

Рис. 6. Соотношение слоев и аспектов языка и архитектурных доменов.

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

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

Общая структура моделей внутри разных слоев похожа, поскольку используются те же типы элементов и отношений (эта общая метамодель показана на рис. 1). Однако природа элементов и степень их детализации различны и определяются потребностями каждого слоя. Кроме того, могут использоваться некоторые дополнительные понятия. Например, в бизнес-слое используются понятия продукта и связанного с ним контракта, смыслового значения бизнес-объекта и ценности продукта/услуги.

Взаимосвязи между слоями формируются отношениями «использование» и «реализация»:

  • отношение типа «использование» показывает, как более высокий слой использует сервисы более низкого слоя;
  • отношение типа «реализация» показывает, как элементы более низких слоев могут реализовывать сопоставимые элементы более высоких слоев.

Например, элемент «объект данных» в слое приложений может реализовывать элемент «бизнес-объект» в бизнес-слое. А элемент «артефакт» в технологическом слое может реализовывать элемент «объект данных» или элемент «компонент приложений» в слое приложений.

Пример 5. Многослойное представление архитектуры предприятия.

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

Рис. 7. Многослойное представление архитектуры предприятия.

Механизмы расширения языка

Язык используется для специальных целей, например, поддержки специальных типов анализа, или для отражения особенностей определенных доменов (функциональных/предметных областей) предприятия (например, финансовый домен организации). В этих случаях понятий, входящих в ядро языка, может оказаться недостаточно.

Язык предоставляет средства по расширению множества понятий, входящих в его ядро. Эти дополнительные понятия отражают специфику исследуемых доменов и используется только в этих целях. Тем самым ядро не перегружается новыми понятиями и обозначениями, которые не будут применяться другими пользователями языка. Расширение ядра языка осуществляется двумя способами [5]:

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

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

Первое расширение необходимо для поддержки фаз A (Видение архитектуры) и H (Управление изменениями архитектуры) метода разработки архитектуры TOGAF, а также предварительной фазы и фазы управления требованиями. Для этого ядро языка было расширено элементами и отношениями, связанными с мотивационными факторами: «заинтересованная сторона», «драйвер», «требования» и т. д. Перечень элементов и отношений, связанных с мотивационными факторами, дан в приложении 4.

Второе расширение предназначено для поддержки фаз E (Возможности и решения), F (Планирование перехода) и G (Руководство реализацией) метода разработки архитектуры TOGAF. Для этого ядро языка было расширено элементами и отношениями, связанными с реализацией и переходом: «пакет работ», «поставляемый результат», «разрыв» и т. д. Перечень элементов и отношений, связанных с реализацией и переходом, приводится в приложении 5.

Способы представления

Полная модель архитектуры предприятия достаточно сложна и объемна. Более того, заинтересованные стороны часто самостоятельно определяют требуемые им представления общей архитектуры предприятия. Для этого язык вводит понятие «представление» (view) архитектуры и обеспечивает гибкий подход к работе с архитектурными представлениями.

Представление архитектуры — это часть общего архитектурного описания, которая исследует заданный перечень вопросов и адресована определенному кругу заинтересованных сторон.

Представления задаются способами представления (точками зрения, viewpoints), которые используются для показа определенных аспектов архитектуры по отдельности или в связке.

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

Можно сказать, что представление — это то, что мы видим, а способ представления — это точка зрения, с которой мы смотрим [4]. Способ представления позволяет фокусировать внимание на определенных аспектах архитектуры, которые определяются интересами заинтересованных сторон. Именно они в конечном итоге определяют, какие элементы и отношения будут включены в представление.


Способы представления классифицируются в языке по двум измерениям: по назначению и по содержанию. В свою очередь каждое из измерений разбивается соответственно на 3 типа и 3 уровня:

  • по назначению — для проектирования, для принятия решений, для информирования;
  • по содержанию — детальный уровень, уровень согласованности и обзорный уровень.

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

Язык предоставляет набор стандартных способов представления, в который входят 18 способов. Описание каждого стандартного способа представления включает целевую аудиторию (перечень заинтересованных сторон), общие указания по использованию, назначение, уровни содержания и включенные в него элементы и отношения. Кроме того, для привлечения внимания к определенным аспектам архитектурной модели могут использоваться цвета. Использование цвета оставлено на усмотрение пользователей языка. Например, в спецификации языка цвета применяются для выделения слоев: желтый цвет используется для бизнес-слоя, синий — для слоя приложений и зеленый — для технологического слоя.

TOGAF и ArchiMate

TOGAFи ArchiMate являются стандартами The Open Group, которые непосредственно относятся к разработке архитектуры предприятия. С одной стороны, у TOGAF и ArchiMate имеются свои спецификации, и они могут использоваться по отдельности, независимо друг от друга, или вместе с другими стандартами. С другой стороны, существуют значительные преимущества при совместном использовании TOGAF и ArchiMate.

Основная цель языка в контексте методологии TOGAF — представление архитектурных моделей. ArchiMate дополняет TOGAF, обеспечивая необходимый набор понятий и обозначений. Язык позволяет создавать как отдельные модели, в том числе соответствующие представлениям TOGAF, так и модели, объединяющие различные домены архитектуры. С включением двух расширений язык полностью покрывает все фазы метода разработки архитектуры TOGAF (таблица 2).

Таблица 2. Использование понятий языка на различных фазах метода разработки архитектуры TOGAF.

В рамках консорциума The Open Group продолжаются работы по развитию ArchiMate, сближению его спецификации со спецификацией TOGAF. В частности, рассматривается разработка новых расширений языка, которые будут включать понятия для моделирования бизнес-политик и процессов принятия решений [6].

Литература

1. Q084 ArchiMate Forum. Information Sheets. The ArchiMate Forum of The Open Group. The Open Group, July 2014

2. Telematica Instituut. Annual Report, 2005.

3. Sethuraj Nair. ArchiMate: Its Time Has Come?

4. ArchiMate 2.1 Specification, Open Group Standard, December 2013.

5. M. Lankhorst et al, Enterprise Architecture at Work – Modelling, Communication and Analysis, Second Edition, Springer, 2009.

6. H. Jonkers, D. Quartel, H. Franken, ArchiMate for Integrated Modelling Throughout the Architecture Development and Implementation Cycle, Uporabna Informatika, 2012.

7. H. Jonkers, E. Proper, M. Turner, TOGAF and ArchiMate: A Future Together. A Vision for Convergence & CoExistence, The Open Group, November 2009.

9. G. Berrisford, M. Lankhorst, Using ArchiMate with an Architecture Method. A conversation, 2009.

1 В 2009 году название организации было изменено на Novay.

2 Проект продолжался с июля 2002 года по декабрь 2004 года. Стоимость и трудоемкость проекта составили соответственно около 4 млн евро и 35 человеко-лет.

3 Information Management писал об этом стандарте в статьях «The Open Group Architecture Framework (TOGAF) Часть 1. Структура, ключевые понятия, модель и инструменты развития архитектуры, информационный контент» (Information Management № 4 2013) и «Часть 2. Континуум предприятия, ссылочные модели и управление развитием архитектуры» (Information Management № 5 2013).

4 Автором статьи выполнен перевод данной версии стандарта на русский язык.

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

6 Приведенные примеры взяты из спецификации языка [4].

© Интернет-проект «Корпоративный менеджмент», 1998–2020

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

Далее рассмотрим стандартные методы системного структурного анализа, описанные серией федеральных стандартов США «Icam Definition», в соответствии с [19, 20, 46 — 48, 98, 99]. Подробную информацию по всем стандартам этой серии можно найти на сайте http://www.idef.com.

Стандарт IDEF0 (FIPS183) предназначен для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Данный документ представляет собой оформление (по инициативе Министерства обороны США) в виде стандарта технологии анализа сложных систем SADT (Structured Analysis and Design Technique), разработанной группой американских аналитиков во главе с Дугласом Россом в 1973 году.

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

Методология IDEF0 основана на следующих положениях:

1. Система и модель. Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Здесь М – модель, А – моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.

2. Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме (чаще говорят SADT-диаграмме), основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.

3. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже с точки зрения технологии SADT. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.

4. Итеративное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.

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

Примеры задач, решаемых на основе методологии моделирования IDEF0:

— Анализ и реинжиниринг бизнес-процессов.

— Разработка информационной системы управления данными о качестве.

Цукерберг рекомендует:  JavaScript Замыкания, разбираемся в вопросе с примерами

— Разработка регламентов и процедур обеспечения качества продукции и создания систем обработки данных о качестве. Функциональная модель позволяет заменить традиционные руководства по качеству в виде описательных текстовых бумажных документов – стандартизованными электронными моделями, целостность и непротиворечивость которых поддерживается автоматически. При необходимости из них всегда можно получить бумажный отчет в привычном виде.

— Проектирование информационной инфраструктуры, процедур и регламентов информационного взаимодействия.

— Задачи анализа рисков в плане информационной безопасности.

Рассмотрим в соответствии с работой [47] принципы построения диаграмм по технологии SADT (IDEF0).

Графический язык SADT прост и гармоничен. В основе методологии лежат четыре основных понятия.

Первым из них является понятие «функциональный блок». Функциональный блок графически изображается в виде прямоугольника (см. рис. 3.23) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: верхняя сторона имеет значение «управление» (control); левая сторона имеет значение «вход» (input); правая сторона имеет значение «выход» (output); нижняя сторона имеет значение «механизм» (mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

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

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

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

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

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

Модель SADT всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы в виде краткого описания и зафиксирована точка зрения. Определение и формализация цели разработки SADT-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логистических цепочек. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.

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

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот – отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке» не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в технологии SADT предусмотрено понятие «туннелирование». Обозначение «туннеля» в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

Последним из специфических понятий SADT является понятие «глоссарий». Для каждого из элементов SADT-диаграмм: функциональных блоков, интерфейсных дуг – существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Набор, называемый глоссарием, является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Если технологию SADT рассматривать как аналог технологии DFD, то глоссарий будет выполняет роль словаря данных, используемого при построении DFD-диаграммы.

Обычно SADT-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

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

— ограничение количества подходящих к одному функциональному блоку интерфейсных дуг четырьмя.

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

Технология SADT содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов [47]:

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

— Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах SADT (IDEF0) – читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

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

Примеры контекстных SADT-диаграмм и их декомпозиции, подготовленный с применением инструментального пакета BPwin, представлен на рисунках 3.24 – 3. 28.

Построение архитектуры организации

2.3. Особенности языка ARIS

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS — Architecture of Integrated Information System , разработанный германской фирмой IDS Scheer. Его методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику.

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:


  1. организационные модели, представляющие структуру системы — иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
  2. функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций , необходимых для достижения поставленных целей;
  3. информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
  4. модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.

Все эти модели представляют собой диаграммы, элементами которых являются разнообразные объекты — » функция «, «событие», «структурное подразделение», «документ» и т.п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа .

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

Относительно новой моделью ARIS является диаграмма eEPC ( extended Event Driven Process Chain — расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0 , >DFD , обладая всеми их достоинствами и недостатками. eEPC — диаграмма предназначена для детального описания бизнес-процесса и отражает логику его выполнения. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Используемые при построении модели символы логики позволяют отразить ветвление и слияние ветвей бизнес-процесса. Исполнители, документы и элементы прикладных комплексов привязываются к бизнес-функциям. Условия выполнения бизнес-функций, а также их результаты отражаются посредством событий. Другими словами, детальная модель бизнес-процесса представляет собой последовательность событий и бизнес-функций, обеспечивающую достижение заданного результата

Следует отметить, что Архитектура Интегрированных Информационных Систем ARIS предназначена, прежде всего, для разработки информационных систем – от определения требований до описания реализации. Тем не менее, она охватывает и предшествующие этапы, связанные с документированием корпоративных знаний, а именно, описанием организационной структуры, моделированием бизнес-процессов, документированием архитектуры приложений, данных и оборудования и т.п.

2.4. Современные языки и среды моделирования архитектуры организации

Введение концепции архитектуры организации предъявило дополнительные требования к языкам моделирования (напомним, что архитектура организации аккумулирует знания о его процессах, поведении, информационных и материальных потоках, ресурсах и организационных единицах, инфраструктуре и архитектуре систем).

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

Среда моделирования архитектуры организации должна включать следующие 4 компонента:

  1. Блок элементарных объектов организации, а именно:
    1. описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого организацией в настоящее время);
    2. средства, используемые для порождения таких представлений (т.е. данных по объектам) согласно определенным правилам (например, ERP , SCM , CRM , СУБД ).

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

    1. определение бизнес-целей и требований, охватывающих направления бизнеса, миссию, цели, критические факторы успеха, критические бизнес-результаты, видение, выявление требований различных типов (функциональных, системных, технологических) и их документирование;
    2. моделирование бизнеса с позиции менеджера, включающее построение концептуальных диаграмм с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий;
    3. моделирование бизнес-процессов;
    4. моделирование бизнес-функций;
    5. моделирование оргструктуры, включая ее нисходящую логическую схему, а также логические схемы принятия решений;
    6. моделирование ресурсов;
    7. преобразование бизнес-моделей в модели приложений и технологической архитектуры.

    Существующие среды моделирования архитектуры организаций могут быть классифицированы следующим образом:

    1. универсальные интегрирующие среды (например, Zachman Framework , GERAM ),
    2. языки моделирования организаций (например, семейство IDEF , DFD -технология, ARIS , BPML ),
    3. программные среды моделирования (например, ARIS 6 Collaborative Suite , Popkin System Architect , METIS , Casewise Corporate Modeler ),
    4. мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition , UEML ).

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

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

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

    Среда Zachman Framework базируется на методе Захмана, широко известном в мировой практике. Суть этого метода сводится к формализованному представлению модели организации в виде матрицы. В строках этой матрицы показываются различные представления архитектуры организации с использованием различных типов моделей . Для простоты понимания эти представления соотносятся с категориями специалистов, определенным образом связанных с деятельностью любой организации (например, «владелец» организации, проектировщик, разработчик и субподрядчик). По столбцам матрицы разнесены основные аспекты деятельности (объекты — «что», действия — «как», местоположения — «где», люди — «кто», время — «когда» и мотивы — «почему»). Структура этой матрицы приведена в таблице 2.1.

    Таблица 2.1. Матрица Захмана
    Объекты (что?) Действия (как?) Дислокация (где?) Люди (кто?) Время (когда?) Мотивы (зачем?)
    Планировщик Сфера действия
    Владелец Модель организации
    Конструктор Модель системы
    Разработчик Техническая модель
    Субподрядчик Компоненты
    Данные Функции Сеть Организация Расписание Стратегия
    Элементы архитектуры

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

    Согласно данному подходу, рассматриваемый объект — это люди (заказчики, пользователи, аналитики, конструкторы и «изготовители» системы), организационные структуры, графики работы организации, цели и стимулы организации и отдельных людей, а также программы, данные и коммуникации. И все эти компоненты должны быть понятным и непротиворечивым образом соединены в единую систему.

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

    Idef — Инструментарий для моделирования архитектуры предприятия

    Традиционное доброе время суток Вам, уважаемые коллеги!

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

    Именно подобные инструменты мы и обсудим сегодня.

    Инструментарий разработки и моделирования требований к процессам и архитектуре программных продуктов

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

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

    Как было отмечено ранее, архитектурное проектирование информационных систем это область деятельности, которая имеет достаточно общего с архитектурным проектированием в строительстве.

    «Строительство» — старший собрат информационных технологий. Поэтому было бы оптимально, для процессов создания программных продуктов, многое, необходимое для развития данной профессиональной области, почерпнуть, поинтересовавшись тем, как в строительстве успешно решались схожие задачи. В гражданском и промышленном строительстве языком описания архитектуры являются архитектурно-строительные чертежи, объемные прототипы и модели, текстовые описания возводимых объектов. Младший собрат поступил правильно и перенял необходимый опыт у старшего. В качестве средств разработки и моделирования характеристик информационных продуктов, в архитектурном проектировании используются различные языки, которые принято называть нотациями, а инструментами, которые поддерживают работу с нотациями CASE средствами.

    Из современных нотаций можно выделить следующие:

    • Блок-схемы (схемы алгоритмов)

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

    В широком значении термина «блок-схемы» он является метанотацией. Различные спецификации «блок-схем» получили свое определенное назначение и форму представления необходимой информации, в зависимости от специфики каждой конкретной нотации, но при этом общие правила построения моделей наследуются от правил построения «блок-схем».

    • DFD-диаграмма (диаграмма потоков данных)

    DFD – это нотация структурного анализа.

    В данной нотации принято описывать внешние, по отношению к разрабатываемому продукту:

    • Источники данных;
    • Адресаты данных;
    • Логические функции;
    • Потоки данных;
    • Хранилища данных.

    Диаграмма потоков данных — это один из первых и основных инструментов структурного анализа и проектирования верхнеуровневой архитектуры программных продуктов, существовавших до последующего широкого распространения UML.

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

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

    В современных процессах разработки программного обеспечения подобный подход к проектированию программных продуктов практически не применяется, по причине смещения акцентов создания информационных систем от структурного к объектно-ориентированному подходу.

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


    • ER-диаграмма (диаграмма сущность-связь)

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

    • EPC-диаграмма (диаграмма событийной цепочки процессов)

    Событийная цепочка процессов – это тип нотации, задача которой заключается в создании моделей бизнес процессов. Она используется для моделирования, анализа и реорганизации бизнес-процессов. Ее отличие, от ранее рассмотренных, состоит в том, что EPC применяют для создания функциональных моделей, имитирующих конкретные процессы, реализуемые в определенном программном продукте.

    История развития данного типа диаграмм связана с разработкой одноименного метода в рамках работ по созданию методологии ARIS (Architecture of Integrated Information Systems — Архитектура интегрированных информационных систем.

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

    Один из самых распространенных типов нотаций на сегодняшний день – это BPMN (Business Process Model and Notation).

    EPC, ER, BPMN — это не просто нотации, а методы реализации конкретных моделей процессов. BPMN по своему назначению более уместно сравнивать c диаграммами EPC. Причина этого заключается в том, что они имеют схожую цель – функциональное моделирование бизнес процессов. Рассматриваемая диаграмма самый новый, из приведенных в обзоре, принятый стандарт моделирования бизнес процессов. Главное позиционируемое преимущество диаграммы BPMN – понятная всем стэйкхолдерам разрабатываемой архитектуры и программного продукта визуализация моделируемых процессов.

    Нотация имеет достаточно понятный инструментарий, позволяющий моделировать как относительно простые, так и сложные бизнес-процессы. Это достигается за счет применения двух групп элементов:

    • Первая группа (simple notation) состоит из основных элементов BPMN, которые удовлетворяют требованиям создания простой графической нотации. Подавляющее большинство бизнес-процессов моделируются с использованием элементов данной группы.
    • Вторая группа (powerful notation) содержит полный «пакет» элементов BPMN. В него кроме основных блоков входят специфические комплексные модули, представляющие различные типы и виды элементов, необходимых для моделирования самых сложных процессов.

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

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

    UML (Unified Modeling Language) — не просто нотация или группа нотаций, а язык графического описания для объектного моделирования.

    UML — это язык широкого профиля, который создан для формирования серии нотаций, поддерживающих полный цикл разработки, как архитектуры, так и функциональности программных продуктов, реализуемых по принципам объектно-ориентируемого программирования.

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

    Язык UML получил популярность за счет жесткой связки с популярной и распространенной методологии разработки и внедрения программных продуктов RUP, в соответствии с которой организована работа многих консалтинговых и производственных компаний отрасли информационных технологий. Не смотря на множество преимуществ, UML не является панацей и абсолютным универсумом в процессах проектирования архитектур и программных продуктов.

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

    UML, в отличие от ER и BPMN диаграмм, поддерживает генерацию не просто отдельной функциональности, привязанной к специфичным типам информационных систем, а целостного программного кода на основании сформированных UML-моделей.

    Самая специфичная и наименее распространенная нотация из всех рассматриваемых в сегодня.

    EIP (Enterprise Integration Patterns) диаграммы — это набор из 65 шаблонов диаграмм, которые предназначены для описания специализированных процессов взаимодействия между программными продуктами. Специфика данной нотации состоит в том, что она разработана для описания конкретных процессов, обеспечивающих интеграционное взаимодействие между приложениями и функциональность программных продуктов, ориентированных на обмен сообщениями между информационными системами.

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

    На сегодняшний день, в силу своей специфичности, данный вид нотации не имеет широкого распространения, но, учитывая темпы роста популярности интеграционных процессов, можно спрогнозировать, что в ближайшее время интерес к EIP-диаграммам вырастет.

    • Модели компонентов, программных продуктов и функциональных процессов

    Модели, как таковые, не являются нотациями, а представляют собой набор необходимых для реализаций процессов/подпроцессов, представленных в виде нескольких взаимодополняющих друг друга нотаций, с целью моделирования конечного результата. Говоря о модели, со структурной точки зрения, корректно будет сказать, что это «метанотация», включающая в себе несколько основных нотаций, реализация диаграмм которых запланированы для качественной разработки конкретной архитектуры.

    Таким образом, модель – это абстракция, которая фокусирует субъекта, работающего с ней на основных, критичных для реализации, характеристиках конечного продукта. Из примеров CASE средств, способных реализовать и представить нотации в виде модели можно выделить ARIS, UML.

    Так же возможна схема, когда исполнитель разработает необходимые диаграммы в разных CASE средствах, после чего компилирует модель самостоятельно. В таких случаях дальнейшее сопровождение и развитие модели затруднительно (сложность сопровождения, развития, управления моделью) и целиком и полностью лежит на «плечах» ответственных за это специалистов;

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

    После того, как реализованы несколько моделей требований, можно приступать к реализации прототипов, если это предусмотрено и спланировано в проекте разработки программного продукта.

    Прототип представляет собой «черновой» вариант конечной реализации программного продукта или его компонента, разработанного с учетом определенных ограничений для демонстрации заинтересованным сторонам на определенной стадии разработки только архитектуры или программного продукта в целом.

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

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

    Жизненный цикл прототипа заканчивается в тот момент, когда ожидания стэйкхолдеров подтверждены и разработанный облик (не более) будущего продукта запланирован к реализации;

    Работа по созданию интерфейсов — это отдельная область разработки программных продуктов, которая не определяет архитектуры, но в большинстве случаев зависит от неё. Именно поэтому мы решили упомянуть её в конце списка, факультативно.

    Эта область требует к себе довольно много внимания и сил. Она определяет многие функциональные характеристики программных продуктов (эргономика, дизайн интерфейсов, воспринимаемость и удобство работы с информацией и т.д.).

    Значимость корректных и эффективных интерфейсов все больше и больше растет для разнообразных программных продуктов. Интерфейс представляет собой «верхушку», с помощью которой пользователь будет взаимодействовать с «нутром» программного продукта.

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

    На текущий момент есть множество инструментов для создания интерфейсов разной степени сложности и детальности. Мы выделим следующие Balsamiq mockup, Axure RP и пр.

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

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

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

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

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

    О функциональных и нефункциональных требованиях к архитектуре и функциональности программного обеспечения

    Обсуждение различных типов и видов требований мы начали в предыдущей ранее.

    В этой статье мы уделим больше внимания рассмотрению функциональных и нефункциональных требований к архитектуре программного обеспечения.

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

    Многие современные ученые области инженерии требований высказывают мнение о том, что не бывает нефункциональных требований.

    Нефункциональные требования — это абсолютно функциональные требования, которые описывают функции системы с точки зрения «каких-то» стэйкхолдеров, о которых забыли в процессе сбора и анализа требований. Вы знаете какое-нибудь программное обеспечение, в процессе разработки которого активно участвовали будущие специалисты групп сопровождения, тестирования, развития его архитектуры и функциональности? Как часто проектируя программные продукты о многих его характеристиках, не значимых на первый взгляд для бизнес стейкхолдеров, но критичных для других пользователей, просто забывают или намеренно игнорируют, считая их не значимыми и второстепенными.

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

    Вся проблема заключается в том, что для современного бизнес мира «последующее» значит то, о чем можно забыть сегодня и не вспоминать до тех пор, пока забытое не напомнит о себе. В случае с нефункциональными требованиями такой подход к работе может оказаться слишком дорогостоящим. Как только информационный продукт перейдет в стадию промышленной эксплуатации и над ним начнут работать группы специалистов, которые должны будут поддерживать достаточно высокий уровень сервисной поддержки и развития системы, может оказаться, что его реализация не включает в себя множество разнообразных технических аспектов. Ведь именно от таких аспектов зависит качество продукта, обеспечивающее оптимальность бизнес процессов, моделей и данных. Довольно распространенная ситуация, когда на ранних фазах создания программных продуктов о таких характеристиках как надежность, быстродействие, безопасность многие специалисты и стэйкхолдеры, вовлеченные в процесс проектирования архитектуры и функциональности просто не задумываются, отдавая их на дальнейшую проработку и реализацию разработчикам. Все бы хорошо, но для разработчиков существует множество факторов, в соответствии с которыми, модели программных компонентов, которые не имеет четких требований будут реализованы не так как задумывалось при составлении специализированных документов, а так, как разработчик «сможет». Это «сможет» будет определяться квалификацией, инструментарием и, конечно же тем, количеством времени, которое у него/них будет в наличии, а его, как известно, практически всегда не хватает. Таким образом, получается следующий парадокс – качество продукта будет напрямую зависеть не от стэйкхолдеров, а от специалистов, для которых важность продукта, который они разрабатывают, не очевидна. Стэйкхолдерам важно получить законченную функциональности в сроки согласованных работ, а иногда даже намного, намного ранее и получить дополнительное время на реализацию качественных атрибутов, значимость которых определяется только в процессе разработки не всегда возможно. Именно поэтому многие характеристики разрабатываемого программного продукта и его архитектуры, скрытые от внимательного взора руководства, необходимо обозначать в активностях, предваряющих стадии проектирования и разработки. Многое на этой стадии зависит от опыта и мастерства системного архитектора и его команды, от профессионализма которых будет зависеть стратегический успех информационной системы, разрабатываемой для бизнес необходимостей конкретной организации.

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

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

    Высокоуровневое назначение программного продукта — приносить выгоду его владельцу за счет автоматизации труда (интеллектуального, физического, монотонного и т.д. ) человека, а в идеале за счет полной замены человеческого ресурса и фактора, если это возможно.

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

    Но при разработке определенной информационной системы классификация требований необходима для целей дальнейшей их трассировки и управления ими. Традиционно выделяют 2 основные группы описание которых и более подробную литературу по работе с которыми наши коллеги найдут в соответствующей литературе.

    Сначала мы рассмотрим функциональные требования.

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

    Цель использования данной группы требований (как следует из названия) заключается в регламентации возможностей и соответствующем им поведении разрабатываемого программного продукта.

    Функциональные требования должны отвечать на вопрос — Каким образом должны быть алгоритмизированы процессы информационного продукта, чтобы взаимодействия между пользователем и системой удовлетворяло потребности стэйкхолдеров?

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

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

    На сегодняшний день существует множество подходов к разработке и фиксации функциональных требований. Кратко рассмотрим наиболее популярные из них:

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

    Дополнительно отметим, что в подобном подходе основная тяжесть создания полноценного документа, охватывающего весь программный продукт, ложится на сотрудника, ответственного за сбор, анализ и синтез информации. При современной динамике изменений бизнес процессов, данных, поступающих от внешних и внутренних аспектов бизнеса и непосредственно влияющих на требования стэйкхолдеров, классический подход становится наименее эффективным. Именно поэтому в последнее время водопадные модели разработки программного обеспечения заменяются «гибкими» подходами (agile), цель которых в быстром и эффективном решении возникающих задач, даже если следующая будет противоречить предыдущей.

    • Use cases (Варианты использования)


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

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

    Но, при попытке тотального применения к работе над функциональными требованиями этого подхода существует вероятность того, что отдельные, незначимые для определенных стэйкхолдеров, потребности будут не учтены. В этом случае существует вероятность упустить суть конкретных функциональных требований, которые, как правило, скрыты от постороннего взгляда. Чтобы этого не произошло, важно использовать в обработке зафиксированных use cases классический подход, в рамках которого должен быть проведен анализ, систематизация и синтез информации. Это поможет выявить истинное назначение предполагаемого к реализации функционала и не упустить отдельных деталей.

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

    Они регламентируют внутренние и внешние условия функционирования программного продукта. Выделяют следующие основные группы нефункциональных требований:

    • Атрибуты качества;
      • Безопасность;
      • Надежность;
      • Производительность;
        • Скорость и время отклика приложения;
        • Пропускная способность workflow;
        • Количество необходимой оперативной памяти;
    • Ограничения;
      • Платформа реализации архитектуры и программного продукта;
      • Тип используемого сервера приложений;

    Нефункциональные требования описывают условия, которые не относятся к поведению и функциональности системы но обеспечивают их на уровне компонентов архитектуры программного продукта.

    Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии с стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с, после того, как поступила соответствующая команда»

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

    Выводы

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

    Надеемся статья получилась комплексной и цельной.

    Стандарт динамического моделирования IDEF2

    Стандарт информационного моделирования IDEF1

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

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

    Стандарт IDEF0 представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

    Модель IDEF0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. Общее число уровней в модели (включая контекстный) не должно превышать 5-6. Практика показывает, что этого вполне достаточно для построения полной функциональной модели современного предприятия любой отрасли [2].

    Стандарт IDEF1 был разработан как инструмент для анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия. Применение методологии IDEF1 как инструмента построения наглядной модели информационной структуры предприятия по принципу «как должно быть».

    Основными составляющими компонентами информационной модели являются:

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

    словарь – значение каждого элемента модели описывается текстовым фрагментом.

    Базовым понятием в методологии IDEF1 является понятие сущности. Сущность определяется как реальный или абстрактный объект, набор отличительных свойств которого, называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты [2].

    IDEF2 — Simulation Model Design — методология динамического моделирования развития систем.

    В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

    Стандарт моделирования процессов IDEF3 – IDEF14

    Как и в методе IDEF0, основной единицей модели IDEF3 является диаграмма. Другой важный компонент модели — действие, или в терминах IDEF3 «единица работы». Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя [2].

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

    Соединения «и» инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему соединению «и», должны завершиться, прежде чем начнется выполнение следующего действия. После обнаружения пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены [2].

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

    Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно аналитиком. Соединение J2 может активизировать проверку данных чека и/или проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных — при оплате наличными. И то, и другое действие инициируются при частичной оплате, как чеком, так и наличными [2].

    IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы [2].

    IDEF5 – методология исследования сложных систем.

    Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику [2].

    IDEF6 — Design Rationale Capture — Обоснование проектных действий.

    Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели [2].

    IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

    IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции) [2].

    IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение [2].

    IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

    IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

    IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

    IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан [2].

    IDEF14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии [2].

    Дата добавления: 2015-07-13 ; Просмотров: 2416 ; Нарушение авторских прав? ;

    Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

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

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

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

    Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

    IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

    IDEF0 – Integration DEFinition language – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей. [pdf]

    Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

    В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

    IDEF0 используется для создания функциональной модели, то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0.

    Функциональная модель – это структурное представление функций, деятельности или процессов в пределах моделируемой системы или предметной области.

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

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

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

    Цели стандарта IDEF0 [pdf]

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

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

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


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

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

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

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

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

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

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

    Строгость и точность (Rigor and Precision) [IDEF.com (http://www.idef.com/IDEF0.htm)]

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

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

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

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

    связанность структуры данных. (Data Structure Connectivity) – 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

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

    Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

    По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»).

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

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

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

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

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

    Рис. Функциональный блок

    Интерфейсная дуга/стрелка (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.

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

    В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».

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

    Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

    Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

    Последним из понятий IDEF0 является глоссарий (Glossary).

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

    Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

    В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

    Idef — Инструментарий для моделирования архитектуры предприятия

    Традиционное доброе время суток Вам, уважаемые коллеги!

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

    Именно подобные инструменты мы и обсудим сегодня.

    Инструментарий разработки и моделирования требований к процессам и архитектуре программных продуктов

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

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

    Как было отмечено ранее, архитектурное проектирование информационных систем это область деятельности, которая имеет достаточно общего с архитектурным проектированием в строительстве.

    «Строительство» — старший собрат информационных технологий. Поэтому было бы оптимально, для процессов создания программных продуктов, многое, необходимое для развития данной профессиональной области, почерпнуть, поинтересовавшись тем, как в строительстве успешно решались схожие задачи. В гражданском и промышленном строительстве языком описания архитектуры являются архитектурно-строительные чертежи, объемные прототипы и модели, текстовые описания возводимых объектов. Младший собрат поступил правильно и перенял необходимый опыт у старшего. В качестве средств разработки и моделирования характеристик информационных продуктов, в архитектурном проектировании используются различные языки, которые принято называть нотациями, а инструментами, которые поддерживают работу с нотациями CASE средствами.

    Из современных нотаций можно выделить следующие:

    • Блок-схемы (схемы алгоритмов)

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

    В широком значении термина «блок-схемы» он является метанотацией. Различные спецификации «блок-схем» получили свое определенное назначение и форму представления необходимой информации, в зависимости от специфики каждой конкретной нотации, но при этом общие правила построения моделей наследуются от правил построения «блок-схем».

    • DFD-диаграмма (диаграмма потоков данных)

    DFD – это нотация структурного анализа.

    В данной нотации принято описывать внешние, по отношению к разрабатываемому продукту:

    • Источники данных;
    • Адресаты данных;
    • Логические функции;
    • Потоки данных;
    • Хранилища данных.

    Диаграмма потоков данных — это один из первых и основных инструментов структурного анализа и проектирования верхнеуровневой архитектуры программных продуктов, существовавших до последующего широкого распространения UML.

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

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

    В современных процессах разработки программного обеспечения подобный подход к проектированию программных продуктов практически не применяется, по причине смещения акцентов создания информационных систем от структурного к объектно-ориентированному подходу.

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

    • ER-диаграмма (диаграмма сущность-связь)


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

    • EPC-диаграмма (диаграмма событийной цепочки процессов)

    Событийная цепочка процессов – это тип нотации, задача которой заключается в создании моделей бизнес процессов. Она используется для моделирования, анализа и реорганизации бизнес-процессов. Ее отличие, от ранее рассмотренных, состоит в том, что EPC применяют для создания функциональных моделей, имитирующих конкретные процессы, реализуемые в определенном программном продукте.

    История развития данного типа диаграмм связана с разработкой одноименного метода в рамках работ по созданию методологии ARIS (Architecture of Integrated Information Systems — Архитектура интегрированных информационных систем.

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

    Один из самых распространенных типов нотаций на сегодняшний день – это BPMN (Business Process Model and Notation).

    EPC, ER, BPMN — это не просто нотации, а методы реализации конкретных моделей процессов. BPMN по своему назначению более уместно сравнивать c диаграммами EPC. Причина этого заключается в том, что они имеют схожую цель – функциональное моделирование бизнес процессов. Рассматриваемая диаграмма самый новый, из приведенных в обзоре, принятый стандарт моделирования бизнес процессов. Главное позиционируемое преимущество диаграммы BPMN – понятная всем стэйкхолдерам разрабатываемой архитектуры и программного продукта визуализация моделируемых процессов.

    Нотация имеет достаточно понятный инструментарий, позволяющий моделировать как относительно простые, так и сложные бизнес-процессы. Это достигается за счет применения двух групп элементов:

    • Первая группа (simple notation) состоит из основных элементов BPMN, которые удовлетворяют требованиям создания простой графической нотации. Подавляющее большинство бизнес-процессов моделируются с использованием элементов данной группы.
    • Вторая группа (powerful notation) содержит полный «пакет» элементов BPMN. В него кроме основных блоков входят специфические комплексные модули, представляющие различные типы и виды элементов, необходимых для моделирования самых сложных процессов.

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

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

    UML (Unified Modeling Language) — не просто нотация или группа нотаций, а язык графического описания для объектного моделирования.

    UML — это язык широкого профиля, который создан для формирования серии нотаций, поддерживающих полный цикл разработки, как архитектуры, так и функциональности программных продуктов, реализуемых по принципам объектно-ориентируемого программирования.

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

    Язык UML получил популярность за счет жесткой связки с популярной и распространенной методологии разработки и внедрения программных продуктов RUP, в соответствии с которой организована работа многих консалтинговых и производственных компаний отрасли информационных технологий. Не смотря на множество преимуществ, UML не является панацей и абсолютным универсумом в процессах проектирования архитектур и программных продуктов.

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

    UML, в отличие от ER и BPMN диаграмм, поддерживает генерацию не просто отдельной функциональности, привязанной к специфичным типам информационных систем, а целостного программного кода на основании сформированных UML-моделей.

    Самая специфичная и наименее распространенная нотация из всех рассматриваемых в сегодня.

    EIP (Enterprise Integration Patterns) диаграммы — это набор из 65 шаблонов диаграмм, которые предназначены для описания специализированных процессов взаимодействия между программными продуктами. Специфика данной нотации состоит в том, что она разработана для описания конкретных процессов, обеспечивающих интеграционное взаимодействие между приложениями и функциональность программных продуктов, ориентированных на обмен сообщениями между информационными системами.

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

    На сегодняшний день, в силу своей специфичности, данный вид нотации не имеет широкого распространения, но, учитывая темпы роста популярности интеграционных процессов, можно спрогнозировать, что в ближайшее время интерес к EIP-диаграммам вырастет.

    • Модели компонентов, программных продуктов и функциональных процессов

    Модели, как таковые, не являются нотациями, а представляют собой набор необходимых для реализаций процессов/подпроцессов, представленных в виде нескольких взаимодополняющих друг друга нотаций, с целью моделирования конечного результата. Говоря о модели, со структурной точки зрения, корректно будет сказать, что это «метанотация», включающая в себе несколько основных нотаций, реализация диаграмм которых запланированы для качественной разработки конкретной архитектуры.

    Таким образом, модель – это абстракция, которая фокусирует субъекта, работающего с ней на основных, критичных для реализации, характеристиках конечного продукта. Из примеров CASE средств, способных реализовать и представить нотации в виде модели можно выделить ARIS, UML.

    Так же возможна схема, когда исполнитель разработает необходимые диаграммы в разных CASE средствах, после чего компилирует модель самостоятельно. В таких случаях дальнейшее сопровождение и развитие модели затруднительно (сложность сопровождения, развития, управления моделью) и целиком и полностью лежит на «плечах» ответственных за это специалистов;

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

    После того, как реализованы несколько моделей требований, можно приступать к реализации прототипов, если это предусмотрено и спланировано в проекте разработки программного продукта.

    Прототип представляет собой «черновой» вариант конечной реализации программного продукта или его компонента, разработанного с учетом определенных ограничений для демонстрации заинтересованным сторонам на определенной стадии разработки только архитектуры или программного продукта в целом.

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

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

    Жизненный цикл прототипа заканчивается в тот момент, когда ожидания стэйкхолдеров подтверждены и разработанный облик (не более) будущего продукта запланирован к реализации;

    Работа по созданию интерфейсов — это отдельная область разработки программных продуктов, которая не определяет архитектуры, но в большинстве случаев зависит от неё. Именно поэтому мы решили упомянуть её в конце списка, факультативно.

    Эта область требует к себе довольно много внимания и сил. Она определяет многие функциональные характеристики программных продуктов (эргономика, дизайн интерфейсов, воспринимаемость и удобство работы с информацией и т.д.).

    Значимость корректных и эффективных интерфейсов все больше и больше растет для разнообразных программных продуктов. Интерфейс представляет собой «верхушку», с помощью которой пользователь будет взаимодействовать с «нутром» программного продукта.

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

    На текущий момент есть множество инструментов для создания интерфейсов разной степени сложности и детальности. Мы выделим следующие Balsamiq mockup, Axure RP и пр.

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

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

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

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

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

    О функциональных и нефункциональных требованиях к архитектуре и функциональности программного обеспечения

    Обсуждение различных типов и видов требований мы начали в предыдущей ранее.

    В этой статье мы уделим больше внимания рассмотрению функциональных и нефункциональных требований к архитектуре программного обеспечения.

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

    Многие современные ученые области инженерии требований высказывают мнение о том, что не бывает нефункциональных требований.

    Нефункциональные требования — это абсолютно функциональные требования, которые описывают функции системы с точки зрения «каких-то» стэйкхолдеров, о которых забыли в процессе сбора и анализа требований. Вы знаете какое-нибудь программное обеспечение, в процессе разработки которого активно участвовали будущие специалисты групп сопровождения, тестирования, развития его архитектуры и функциональности? Как часто проектируя программные продукты о многих его характеристиках, не значимых на первый взгляд для бизнес стейкхолдеров, но критичных для других пользователей, просто забывают или намеренно игнорируют, считая их не значимыми и второстепенными.

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

    Вся проблема заключается в том, что для современного бизнес мира «последующее» значит то, о чем можно забыть сегодня и не вспоминать до тех пор, пока забытое не напомнит о себе. В случае с нефункциональными требованиями такой подход к работе может оказаться слишком дорогостоящим. Как только информационный продукт перейдет в стадию промышленной эксплуатации и над ним начнут работать группы специалистов, которые должны будут поддерживать достаточно высокий уровень сервисной поддержки и развития системы, может оказаться, что его реализация не включает в себя множество разнообразных технических аспектов. Ведь именно от таких аспектов зависит качество продукта, обеспечивающее оптимальность бизнес процессов, моделей и данных. Довольно распространенная ситуация, когда на ранних фазах создания программных продуктов о таких характеристиках как надежность, быстродействие, безопасность многие специалисты и стэйкхолдеры, вовлеченные в процесс проектирования архитектуры и функциональности просто не задумываются, отдавая их на дальнейшую проработку и реализацию разработчикам. Все бы хорошо, но для разработчиков существует множество факторов, в соответствии с которыми, модели программных компонентов, которые не имеет четких требований будут реализованы не так как задумывалось при составлении специализированных документов, а так, как разработчик «сможет». Это «сможет» будет определяться квалификацией, инструментарием и, конечно же тем, количеством времени, которое у него/них будет в наличии, а его, как известно, практически всегда не хватает. Таким образом, получается следующий парадокс – качество продукта будет напрямую зависеть не от стэйкхолдеров, а от специалистов, для которых важность продукта, который они разрабатывают, не очевидна. Стэйкхолдерам важно получить законченную функциональности в сроки согласованных работ, а иногда даже намного, намного ранее и получить дополнительное время на реализацию качественных атрибутов, значимость которых определяется только в процессе разработки не всегда возможно. Именно поэтому многие характеристики разрабатываемого программного продукта и его архитектуры, скрытые от внимательного взора руководства, необходимо обозначать в активностях, предваряющих стадии проектирования и разработки. Многое на этой стадии зависит от опыта и мастерства системного архитектора и его команды, от профессионализма которых будет зависеть стратегический успех информационной системы, разрабатываемой для бизнес необходимостей конкретной организации.

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

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

    Высокоуровневое назначение программного продукта — приносить выгоду его владельцу за счет автоматизации труда (интеллектуального, физического, монотонного и т.д. ) человека, а в идеале за счет полной замены человеческого ресурса и фактора, если это возможно.

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

    Но при разработке определенной информационной системы классификация требований необходима для целей дальнейшей их трассировки и управления ими. Традиционно выделяют 2 основные группы описание которых и более подробную литературу по работе с которыми наши коллеги найдут в соответствующей литературе.

    Сначала мы рассмотрим функциональные требования.

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

    Цель использования данной группы требований (как следует из названия) заключается в регламентации возможностей и соответствующем им поведении разрабатываемого программного продукта.

    Функциональные требования должны отвечать на вопрос — Каким образом должны быть алгоритмизированы процессы информационного продукта, чтобы взаимодействия между пользователем и системой удовлетворяло потребности стэйкхолдеров?

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

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

    На сегодняшний день существует множество подходов к разработке и фиксации функциональных требований. Кратко рассмотрим наиболее популярные из них:

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

    Дополнительно отметим, что в подобном подходе основная тяжесть создания полноценного документа, охватывающего весь программный продукт, ложится на сотрудника, ответственного за сбор, анализ и синтез информации. При современной динамике изменений бизнес процессов, данных, поступающих от внешних и внутренних аспектов бизнеса и непосредственно влияющих на требования стэйкхолдеров, классический подход становится наименее эффективным. Именно поэтому в последнее время водопадные модели разработки программного обеспечения заменяются «гибкими» подходами (agile), цель которых в быстром и эффективном решении возникающих задач, даже если следующая будет противоречить предыдущей.

    • Use cases (Варианты использования)

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


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

    Но, при попытке тотального применения к работе над функциональными требованиями этого подхода существует вероятность того, что отдельные, незначимые для определенных стэйкхолдеров, потребности будут не учтены. В этом случае существует вероятность упустить суть конкретных функциональных требований, которые, как правило, скрыты от постороннего взгляда. Чтобы этого не произошло, важно использовать в обработке зафиксированных use cases классический подход, в рамках которого должен быть проведен анализ, систематизация и синтез информации. Это поможет выявить истинное назначение предполагаемого к реализации функционала и не упустить отдельных деталей.

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

    Они регламентируют внутренние и внешние условия функционирования программного продукта. Выделяют следующие основные группы нефункциональных требований:

    • Атрибуты качества;
      • Безопасность;
      • Надежность;
      • Производительность;
        • Скорость и время отклика приложения;
        • Пропускная способность workflow;
        • Количество необходимой оперативной памяти;
    • Ограничения;
      • Платформа реализации архитектуры и программного продукта;
      • Тип используемого сервера приложений;

    Нефункциональные требования описывают условия, которые не относятся к поведению и функциональности системы но обеспечивают их на уровне компонентов архитектуры программного продукта.

    Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии с стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с, после того, как поступила соответствующая команда»

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

    Выводы

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

    Надеемся статья получилась комплексной и цельной.

    Анализ программных средств для моделирования архитектуры предприятия

    Автор работы: Пользователь скрыл имя, 10 Декабря 2013 в 15:32, реферат

    Файлы: 1 файл

    Реферат.docx

    Существующие среды моделирования архитектуры предприятий могут быть классифицированы следующим образом:

    • универсальные интегрирующие среды (например, Zachman Framework, (GERAM),
    • языки моделирования предприятий (например, IDEF, ARIS, BPML),
    • программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS),
    • мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).

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

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

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

    Конкурирующая среда GERAM (Generalised Enterprise Reference Architecture and Methodology) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современного предприятия (любого типа) в течении всего времени его существования. GERAM обеспечивает поддержку всех вышепредставленных элементов среды моделирования архитектуры, базируясь при этом на:

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

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

    Следует отметить, что в настоящее время прослеживается тенденция к обогащению подходов в части покрытия среды моделирования, например, одна из последних разработок университета г.Бордо GRAI Integrated Methodology (GRAI-GIM) обеспечивает референсную модель с концепцией, языком, графическим

    формализмом и инженерным методом реализации методологии К наиболее распространенными в настоящее время языкам моделирования

    предприятий относятся, прежде всего, IDEF, ARIS и BPML.

    Идея создания семейства стандартов IDEF (Integrated Computer Automated Manufacturing Definition) родилась в середине 70-х годов в ВВС США, как решение проблемы повышения производительности и эффективности информационных технологий, возникшей при реализации программы ICAM (Integrated Computer Aided Manufacturing). Часть этого семейства из 14 стандартов, относящихся к методам и технологиям создания моделей сложных систем и проектирования компьютерных систем, имеет непосредственное отношение к моделированию бизнес-процессов, а именно: IDEF0 (модель функций), IDEF1 и его расширение IDEF1X (информационная модель и модель данных, соответственно), IDEF2 (динамическая модель), IDEF3 (модель процессов) и IDEF4 (объектно-ориентированные методы проектирования). Часть стандартов семейства фактически осталась на бумаге (стандарт IDEF2), другая часть (IDEF0 и IDEF1X) превратилась в стандарт правительства США, известный как FIPS. Основными недостатками IDEF являются:

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

    ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры предприятия. Сам язык включает более 100 типов моделей, 90% из которых практически никогда не используются, инструментальная поддержка осуществляется продуктом той же компании – разработчика методологии. Этот продукт имеет цену, на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.

    Одной из последних разработок в данной области является создание специального языка, ориентированного на моделирование бизнес-процессов

    BPML (Business Process Modeling Language). Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и потоков событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутрь е-бизнес-процессов.

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

    которые трудно сравнивать из-за различного синтаксиса и семантики языков

    моделирования (которые к тому же часто точно не определены). Собственный синтаксис и ограниченная (ориентированная на поддерживающий

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

    Решением данной проблемы занимается рабочая группа, созданная

    компаниями – производителями языков моделирования, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом,семантикой и правилами взаимоотношений (отображений) между различными языками моделирования архитектуры предприятий. Проект UEML включает разработку:

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

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

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

    EA tools (Enterprise Architecture tools) — это набор инструментов, ориентированный на моделирование архитектуры предприятия. Инструменты этой группы должны позволить связывать различные разрозненные типы данных в единое целое. Одной из основных особенностей продуктов класса Enterprise Architecture Tools является возможность не только моделировать различные элементы деятельности компании (программно-аппаратные средства, бизнес-процессы, приложения, интерфейсы, организационная структура, стратегические цели), но и интегрировать их.

    Enterprise Architecture Tools должны включать в себя следующие компоненты: репозиторий (repository), обеспечивающий структурированное хранение всех данных, описывающих состояние компании; метамодель (metamodel), которая поддерживает возможность описания всех слоев архитектуры предприятия ( бизнес, информация, приложения, технологии) и обеспечивает связи между всеми объектами; возможность создавать и импортировать модели; возможность извлекать информацию из репозитория и предоставлять ее пользователям, как в текстовом, так и в графическом виде.

    BPA (Business Process Analyze) — это набор инструментов, ориентированный на моделирование и управление бизнес- процессами. При описании приложений этой группы часто используют термин BPMS (Business Process Management System) или BPM-система. BPA Tools (BPMS) позволяют не только моделировать бизнес-процессы, но и проводить мониторинг их количественных параметров, что позволяет выявлять узкие места и оптимизировать бизнес- процессы. BPA Tools ориентированы на анализ, моделирование, оптимизацию конкретных бизнес-процессов.

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

    Metadata Repositories – это хранилище информации о текущей структуре предприятия. Подобные хранилища данных включают в себя информацию о бизнес- процессах, приложениях, интерфейсах, программно- аппаратных средствах. Информация, хранящаяся в такой базе данных, собирается из различного количества источников и, как правило, частично совпадает с информацией, находящейся в CMDB (configuration management databases).

    Хранилище информации, как правило, не существует само по себе и является элементом инструментов, ориентированных на использование Business Process Analyze или Enterprise Architecture tools.

    Database and Data Design Tools — набор инструментов, ориентированный на разработку моделей, описывающих информационную архитектуру предприятия. Инструменты этой группы включают в себя возможность визуального представления информации и редакторы для физического и логического описания модели данных.

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

    OOA&D (Object-Oriented Analysis and Design) — это набор инструментов для объектно- ориентированного анализа и проектирования. Используются для анализа предметной области и проектирования информационных систем с использованием объектно-ориентированного подхода.

    Современные приложения, использующиеся для объектно-ориентированного анализа, должны интегрироваться с инструментами моделирования бизнес-процессов (BPA Tools) и системами проектирования баз данных.

    Наиболее интересный вариант классификации программных продуктов, использующихся для разработки моделей, предложен аналитиками IFEAD, которые выделяют следующие направления: Software Engineering (Разработка программного обеспечения), Service Oriented Architecture (Сервис ориентированная архитектура), Enterprise Architecture (Архитектура предприятия), Business / IT strategy (Бизнес / ИТ стратегия), Enterprise / IT portfolio (Предприятие / ИТ портфель), Program Management (Управление программами), Governance, Risk, Compliancy (Управление, риски, соответствие условиям).

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


    В рамках данной работы рассмотрены следующий программные продукты: Sybase PowerDesigner, ER/Studio XE3 Business Architect и ARIS Business Architect.

    Краткая характеристики POWER DESIGNER

    Sybase PowerDesigner™ — программа проектирования современных информационных систем. Она предоставляет уникальную возможность ускорения аналитических процессов и разработки программного обеспечения, сочетая традиционные преимущества средств моделирования реляционных баз данных с новыми, производительными и эффективными по стоимости технологиями моделирования на базе языка UML.

    Описание работы

    В самом общем виде под архитектурой предприятия (ЕА — Enterprise Architecture) понимается всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных отношений. Согласно ISO 15704 (“Industrial Automation Systems – Requirements for Enterprise-Reference Architectures and Methodologies. 1999”) архитектура предприятия должна включать роль людей, описание процессов (функции и поведение), и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия.

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

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

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

    Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

    IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

    IDEF0 – Integration DEFinition language – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей. [pdf]

    Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

    В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

    IDEF0 используется для создания функциональной модели, то есть результатом применения методологии IDEF0 к системе есть функциональная модель IDEF0.

    Функциональная модель – это структурное представление функций, деятельности или процессов в пределах моделируемой системы или предметной области.

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

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

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

    Цели стандарта IDEF0 [pdf]

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

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

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

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

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

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

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

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

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

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

    Строгость и точность (Rigor and Precision) [IDEF.com (http://www.idef.com/IDEF0.htm)]

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

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

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

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

    связанность структуры данных. (Data Structure Connectivity) – 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

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

    Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

    По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»).

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

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

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

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

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

    Рис. Функциональный блок

    Интерфейсная дуга/стрелка (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.

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

    В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».

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

    Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

    Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

    Последним из понятий IDEF0 является глоссарий (Glossary).

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

    Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

    В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

    Курсовая работа: Разработка модели предприятия тепличного хозяйства, используя методологии проектирования > Название: Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD и IDEF3
    Раздел: Рефераты по экономико-математическому моделированию
    Тип: курсовая работа Добавлен 10:17:47 26 ноября 2009 Похожие работы
    Просмотров: 14143 Комментариев: 16 Оценило: 7 человек Средний балл: 4.1 Оценка: 4 Скачать

    Министерство образования и науки РФ

    Федеральное агентство по образованию

    Государственное образовательное учреждение высшего профессионального образования


    «Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD и IDEF3»

    2. Теоретическое введение

    3. Описание предметной области

    4. Описание BPwin

    4.1 Принцип построения модели IDEF0

    4.2 Принцип построения модели DFD

    4.3 Принцип построения модели IDEF3

    5.1 Модель тепличного хозяйства

    5.2 Математическая модель

    6. Сравнительный анализ

    6.2 Сравнение инструментальных средств

    Целями данной курсовой работы были:

    применение методов предпроектного обследования предприятия;

    анализ полученных материалов для последующего моделирования;

    разработка модели процесса в стандарте IDEF0;

    описание документооборота и обработки информации в стандарте DFD;

    описания процессов в стандарте IDEF3;

    разработка смешанной модели описания процесса на основе стандартов IDEFO, DFD и IDEF3.

    создание сценариев работы предприятия;

    построение структурной схемы предприятия;

    создание математической модели данного предприятия.

    2. Теоретическое введение

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

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

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

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

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

    Основными целями моделирования при разработке проектов являются:

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

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

    упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

    анализ требований и проектирование спецификаций корпоративных информационных систем.

    3. Описание предметной области

    Для рассмотрения в данной курсовой работе было взято за основу работа тепличного хозяйства. Это предприятие специализируется на выращивании сельскохозяйственных культур. Реализация продукции производится по заявке заказчика.

    Организация работы осуществляется по следующей схеме:

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

    Во главе всего предприятия стоит руководство, в лице начальника и его заместителя. Их основной функцией является контроль деятельности предприятия.

    Далее идут основные отделы и службы предприятия:

    Служба охраны труда, основная функция которого подготовка персонала;

    Бухгалтерский отдел занимается документооборотом;

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

    Сектор технического обслуживания, занимается ремонтными работами.

    Отделы, службы и рабочие места данного предприятия представлены в таблице №1:

    Задачи и функции нашего тепличного хозяйства показаны в таблице №2:

    Документация представлена в таблицах №3:

    Справочник организаций представлен в таблице №4:

    Далее приведена схема, описывающая сценарий работы предприятия с соответствующими выводами по каждому из этапов: от заказчика поступает заявка на поставку определенной продукции тепличного хозяйства менеджеру по продажам. Он по продажам обрабатывает эту заявку и принимает решение. Параллельно этому бухгалтер производит расчет стоимости оказания услуг. Как только все эти этапы пройдены, начинается процесс заключения контракта. Менеджер по продажам обсуждает с заказчиком условия контракта и производит его заключение. После этого заказчик вносит платеж. Контроль над внесением платежа входит в обязанность бухгалтерии. Бухгалтер получает выписку из банка, и формирует приказ о начале выполнения заказа, который передается технологу. Технолог в свою очередь составляет план – график проводимых работ и ведет учет необходимых средств. После составления плана – графика работ, отдается приказ садовнику об осуществлении земельных работ. Садовник проводит земельные работы и собирает урожай. Собранный урожай отправляется заказчику. По ходу всего производственного цикла к начальнику предприятия поступают отчеты о деятельности менеджера по продажам, бухгалтера и технолога. Начальник контролирует весь процесс деятельности предприятия, и если необходимо, делает замечания по работе его персонала с целью улучшения процесса производства и работы всего предприятия в целом.

    Схема сценария работы предприятия

    4. Описание BPwin

    BPwin относится к малым интегрированным средствам моделирования, которые поддерживают несколько типов моделей и методов.

    Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня — BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Основной из трех методологий, является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.

    BPwin автоматизирует задачи, связанные с построением моделей развития, обеспечивая семантическую строгость, необходимую для гарантирования правильности и непротиворечивости результатов. Это достигается применением в BPwin следующих методологий: IDEF0, DFD и IDEF3.

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

    В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEFO, так и IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок.

    Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А3.1 А3.2, АЗ.З, А3.4 и т. д.

    В результате дополнения диаграмм, IDEFO диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEFO изображаются зеленым цветом, DFD – синим.

    BPwin так же как и локальные интегрированные системы, практически не позволяют выполнить комплексный анализ систем, который в большей или меньшей степени необходим для создания малых, средних и крупных ИСУП. С их помощью можно разрабатывать локальные ИС или небольшие подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, т. е. когда нет необходимости в комплексном анализе предприятия. Типичная сфера использования малых интегрированных средств — решение задач так называемой “кусочной” автоматизации предприятия.

    4.1 Принцип построения модели IDEFO

    Основу методологии IDEFO составляет графический язык описания бизнес-процессов. Модель в нотации IDEFO представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

    IDEFO-модель предполагает наличие четко сформулированной цели единственного субъекта моделирования и одной точки зрения.

    Модель может содержать четыре типа диаграмм:

    контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

    диаграммы дерева узлов;

    диаграммы только для экспозиции (FEO).

    Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

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

    верхняя сторона имеет значение «управления»;

    Вторым элементом методологии и нотации является «поток» (в стандарте называемый — «интерфейсная дуга») — элемент, описывающий данные, неформальное управление, или что-либо другое «оказывающее влияние» на функцию, изображенную блоком. В зависимости от того, к какой стороне блока направлен поток, он, соответственно, носит название «входной», «выходной», «управляющий».

    Изобразительным элементом, представляющим «поток», является стрелка.

    Управление — это что управляет деятельностью бюро, в данной разрабатываемой модели — это законы об индивидуальном ПУ.

    Стрелки «входа» вносят функции входных данных, в контекстной диаграмме – это персональные данные работника.

    Стрелки «выхода» – выходные данные. В контекстной диаграмме – это различные сведения, которые подаются в Пенсионный фонд РФ.

    Стрелка «механизма» — это влияющие на процессы данные. В диаграмме – это персонал и ПК.

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

    После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам.

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

    Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor.

    4.2 Принцип построения модели DFD

    Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

    Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.

    В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС — проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.

    Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:

    4.3 Принцип построения модели IDEF3

    IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEFO и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.

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

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

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

    разветвления стрелок (Fan-out Junction)

    Обозначение Наименование Смысл в случае слияния стрелок (Fan-in Junction)
    ||& Asynchronous AND Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены
    ||&|| Synchronous AND Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно
    ||O Asynchronous OR Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
    ||O|| Synchronous OR Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно
    ||X Только один предшествующий процесс завершен Только один следующий процесс запускается

    Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEFO и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

    Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка |R| – (добавить в диаграмму объект ссылки — Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих