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

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

Обзор

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

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

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

Особенно в области разработки программного обеспечения многие инструменты (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 IT, которое можно получить из их бизнес-представления с помощью механизма преобразования.

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

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.

Ссылки

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

[Kim-1] Перейти обратно: ^а ^б Ким, Уэстон, Ходжсон и Ли (2002 г.); Взаимодополняющее использование IDEF и UML. Инженерия информационных систем, Университет Дэджон, Южная Корея, Компьютеры и промышленная инженерия 50, 35–56.

[2] Закарян и Кусиак; Анализ процессов и реинжиниринг: Департамент промышленной инженерии, Университет Айовы, США, Компьютеры и промышленная инженерия 41, 135–150

[3] Бикман, (1989); Европейский комитет по стандартизации, ECN TC310 WG1, 1994 г.

[4] ВВС США (1981); Архитектура ICAM, часть 1, Огайо, Лаборатория материалов ВВС, Райт-Паттерсон

[5] Петерсон Дж.Л. (1981); Теория сетей Петри и моделирование систем, Энглвуд Клиффс, Нью-Джерси, Прентис Холл.

[6] # Маршалл, К. (2000); Моделирование предприятия с помощью UML, ISBN 0-201-43313-3 , Аддисон-Уэсли, Массачусетс.

[7] Франсуа Вернада ; Видение будущей работы целевой группы (IFAC-IFIP).

[8] Сильва М. и Валетт Р. (1989); Сети Петри и гибкое производство. Конспекты лекций по информатике, 424, 374–417.

[9] Чжу и др. (2004); Интеграция и управление бизнес-процессами на основе моделей: пример региональной сервисной платформы Bank SinoPac, IBM Corporation, Res. и Дев. Том. 48 № 5/6.

[10] Эрикссон и Пенкер (1998); UML Toolkit, Уайли, Нью-Йорк.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]