Функциональная архитектура программного обеспечения - Википедия - Functional software architecture

А функциональная архитектура программного обеспечения (FSA) - архитектурная модель, определяющая предприятие функции, взаимодействия и соответствующие ЭТО потребности. Эти функции могут использоваться в качестве справочника различными эксперты в предметной области разрабатывать IT-системы как часть кооперативного информационного предприятия. Таким образом, оба программисты Корпоративные архитекторы могут создать информационную интегрированную организационную среду.

Обзор

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

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

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

Особенно в области разработки программного обеспечения многие инструменты (A4 Tool, CAME, ARIS ), языки (ACME, Rapide, UML ) и методы (DSDM, RUP, ISPL ) разработаны и широко используются. Кроме того, переход между разработчиками программного обеспечения (этап 3) и программистами (этап 4) уже в высокой степени формализован, например, объектно-ориентированный разработка.

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

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

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

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

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

Разработка

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

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

Оптимизация внутренних и внешних бизнес-процессов посредством реинжиниринга процессов - одна из основных задач, которые может иметь предприятие во времена высокого внешнего давления. А бизнес-процесс включает в себя деятельность по созданию ценности с определенными входами и выходами, которые взаимосвязаны и тем самым совместно вносят вклад в результат (продукт или услугу) процесса. Реинжиниринг процессов охватывает множество точек зрения на то, как изменить организацию. Он связан с реорганизацией стратегических процессов, систем, политик и организационных структур с целью оптимизации процессов организации.[2]

Моделирование бизнеса

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

  • Методология компьютерно-интегрированной производственной архитектуры открытых систем (CIMOSA)[3]
  • Методология интегрированного определения (IDEF)[4]
  • Сети Петри[5]
  • Унифицированный язык моделирования (UML) или унифицированный язык моделирования предприятия (UEML)[6][7]
  • Диаграммы функций предприятия (EFD)

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

Архитектура открытых систем компьютерно-интегрированного производства

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

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

Интегрированное определение (IDEF)

IDEF это структурированное моделирование метод, который впервые был разработан для моделирования производственных систем. Он уже использовался ВВС США в 1981 году. Первоначально он имел 4 различных обозначения для моделирования предприятия с определенной точки зрения. Это были IDEF0, IDEF1, IDEF2 и IDEF3 для функционального анализа, анализа данных, динамического анализа и анализа процессов соответственно. В последние десятилетия постепенно разрабатываются несколько инструментов и методов интеграции нотаций.

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

Сети Петри

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

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

В последние годы несколько попыток показали, что сети Петри могут способствовать развитию интеграции бизнес-процессов. Одна из них - методология Model Blue, разработанная IBM Китайская исследовательская лаборатория и подчеркивает важность бизнес-интеграции на основе моделей как нового подхода к созданию интегрированных платформ.[9] Также показано соответствие между их бизнес-представлением Model Blue и эквивалентной сетью Петри, что указывает на то, что их исследование сокращает разрыв между бизнесом и ИТ. Однако вместо сетей Петри они скорее используют собственное ИТ-представление Model Blue, которое может быть получено из их бизнес-представления с помощью механизма преобразования.

Единый язык моделирования

UML является широко распространенным языком моделирования для разработки программных систем и приложений. Сообщество объектно-ориентированного программирования также пытается использовать UML для моделирования предприятий. Они подчеркивают использование корпоративных объектов или бизнес-объектов, из которых состоят сложные корпоративные системы. Набор этих объектов и соответствующие взаимодействия между ними могут представлять сложную бизнес-систему или процесс. В то время как сети Петри фокусируются на взаимодействии и состояниях объектов, UML больше фокусируется на самих бизнес-объектах. Иногда их называют «строительными блоками предприятия», которые включают ресурсы, процессы, цели, правила и метамодели.[10] Хотя таким образом UML можно использовать для моделирования интегрированной программной системы, утверждалось, что реальность бизнеса можно смоделировать с помощью языка моделирования программного обеспечения. В ответ объектно-ориентированное сообщество создает бизнес-расширения для UML и адаптирует язык. UEML является производным от UML и предлагается в качестве языка бизнес-моделирования. Остается вопрос, правильна ли эта трансформация бизнеса. Ранее было сказано, что UML в сочетании с другими "чистыми" бизнес-методами может быть лучшей альтернативой.

Диаграммы функций предприятия

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

EFD, возможно, можно было бы использовать в качестве бизнес-интерфейса для языка моделирования программного обеспечения, такого как UML. Основное сходство с IDEF как инструментом моделирования указывает на то, что это возможно. Однако необходимы дополнительные исследования для улучшения техники EFD таким образом, чтобы можно было выполнять формальные сопоставления с UML.[1] о дополнительном использовании IDEF и UML способствовало принятию IDEF в качестве интерфейса для бизнеса. Аналогичное исследование следует провести с EFD и UML.

Рекомендации

  1. ^ а б Ким и Уэстон, Ходжсон и Ли (2002); Дополнительное использование IDEF и UML. Инженерия информационных систем, Университет Деджон, Южная Корея, Компьютеры и промышленная инженерия 50, 35–56.
  2. ^ Закарян и Кусяк; Анализ процессов и реинжиниринг: Департамент промышленной инженерии, Университет Айовы, США, Компьютеры и промышленная инженерия 41, 135–150
  3. ^ Бикман, (1989); Европейский комитет по стандартизации, ECN TC310 WG1, 1994
  4. ^ ВВС США (1981); Архитектура ICAM, часть 1, Огайо, Лаборатория материалов ВВС, Райт-Паттерсон
  5. ^ Петерсон Дж. Л. (1981); Теория сетей Петри и моделирование систем, Englewood Cliffs, N.J., Prentice Hall.
  6. ^ # Маршалл, К. (2000); Моделирование предприятия с помощью UML, ISBN  0-201-43313-3, Аддисон-Уэсли, Массачусетс.
  7. ^ Франсуа Вернадат; Видение будущей работы целевой группы (IFAC-IFIP).
  8. ^ Сильва, М. и Валетт, Р. (1989); Сети Петри и гибкое производство. Конспект лекций по информатике, 424, 374–417.
  9. ^ Zhu et al. (2004); Интеграция бизнес-процессов на основе моделей и управление ими: пример региональной сервисной платформы Bank SinoPac, IBM Corporation, Res. & Dev. Vol. 48 № 5/6.
  10. ^ Эрикссон и Пенкер (1998); UML Toolkit, Wiley, New York.