기능성 소프트웨어 아키텍처

이 글은 독자들에게 혼란스럽거나 불명확할 수 있다. 기사에 대해 명확하게 설명할 수 있도록 도와주십시오. 토크 페이지에서 이에 대한 논의가 있을 수 있다.(2011년 5월) (이 템플릿 메시지를 제거하는 방법과 시기 알아보기)

기능 소프트웨어 아키텍처(FSA)는 엔터프라이즈 기능, 상호작용 및 해당 IT 요구를 식별하는 아키텍처 모델이다.이러한 기능들은 서로 다른 도메인 전문가들이 협동 정보 주도 기업의 일부로서 IT 시스템을 개발하기 위한 참고 자료로 활용할 수 있다.이러한 방식으로 소프트웨어 엔지니어와 엔터프라이즈 설계자 모두 정보 중심적이고 통합된 조직 환경을 만들 수 있다.

개요

통합 소프트웨어 시스템을 개발 및 구현해야 할 경우 몇 가지 작업과 그에 상응하는 책임은 일반적으로 다음과 같이 나눌 수 있다.

1. 전략적 관리 및 비즈니스 컨설턴트는 보다 효율적이고 효과적인 비즈니스 프로세스와 관련하여 목표를 설정한다.
2. 기업 엔지니어들은 기업 아키텍처의 형태로 보다 효율적인 사업 프로세스 설계와 특정 정보 시스템에 대한 요청을 생각해낸다.
3. 소프트웨어 엔지니어는 특정 아키텍처 기술 언어(ADL)를 사용하여 시스템의 구성 요소와 구조적 특징을 기술하는 이 정보 시스템의 설계를 제안한다.
4. 컴퓨터 프로그래머들은 다른 모듈들을 코드화하고 실제로 시스템을 구현한다.

기술된 업무분과는 실제로는 훨씬 더 복잡하고 또한 더 많은 행위자들이 참여하지만 그것은 조직이 사업목표를 달성할 수 있는 소프트웨어 시스템을 만드는 데 서로 다른 배경을 가진 사람들이 참여하는 것을 요약한다.이 시스템 개발 프로세스 내에서 서로 다른 행위자들에 의해 생산되는 매우 다양한 자료들이 여러 행위자들 사이에서 교환되고 이해될 필요가 있다.

특히 소프트웨어 엔지니어링 분야에서는 많은 도구(A4 Tool, COME, ARIS), 언어(ACME, Rapide, UML) 및 방법(DSDM, RUP, ISPL)이 개발되어 광범위하게 사용되고 있다.또한, 소프트웨어 엔지니어(3단계)와 컴퓨터 프로그래머(4단계) 간의 전환은, 예를 들어 객체 지향적 개발에 의해 이미 고도의 공식화 되어 있다.

전략적 목표 설정(1단계)과 그에 따른 사업 기회 및 약점 탐색은 백년 이상 광범위하게 논의되고 조사된 대상이다.비즈니스 프로세스 리엔지니어링, 제품 소프트웨어 시장 분석 및 요구사항 분석과 같은 개념은 일반적으로 알려져 있으며 이러한 맥락에서 광범위하게 사용된다.이러한 전략적 투입변수는 각각 소프트웨어 설계와 구현에 사용할 수 있는 우수한 기업 설계(2단계) 개발에 사용되어야 한다.

최근의 연구는 이러한 기업 아키텍처들이 몇 가지 다른 방법과 기법에 의해 개발될 수 있다는 것을 보여주었다.이러한 방법과 기법이 상세하게 논의되기 전에 기업 아키텍처의 정의는 다음과 같다.

엔터프라이즈 아키텍처는 전략적 정보 자산 기반으로서, 미션 수행에 필요한 정보 및 미션 수행에 필요한 기술, 변화하는 미션 요구에 대응하여 새로운 기술을 구현하기 위한 과도기적 프로세스를 정의한다.

이 정의는 비즈니스 프로세스의 개선과 필요한 정보 시스템의 개발을 위한 풍부한 전략 정보원으로서 아키텍처를 이용하는 것을 강조한다.이러한 제도적 청사진이 정의, 유지 및 효과적으로 구현된다면, 조직의 비즈니스 운영과 운영을 지원하는 기본 IT 간의 상호의존성과 상호관계를 최적화하는 데 도움이 된다.

이 항목의 시작 부분에 기능 소프트웨어 아키텍처의 정의를 읽으면 우리는 기능 소프트웨어 아키텍처를 통합 정보 시스템 개발을 위한 풍부한 참조 자료로 사용할 수 있는 엔터프라이즈 아키텍처의 한 유형으로 볼 수 있다.그것을 기능적 소프트웨어 아키텍처라고 명명하는 것은 실무자들이 그것을 기술 아키텍처의 전략적 입력으로 사용할 것을 권장한다.따라서 기능 소프트웨어 아키텍처와 ADL 유형 사이의 공식적인 매핑이 필요하다.이러한 방법으로, 소프트웨어 아키텍처의 전략적 입력으로서 엔터프라이즈 아키텍처의 공식적인 사용과 재사용이 실현될 수 있다.

개발

기업의 경계가 확장됨에 따라, 필요한 사업, 사람, IT 시스템 활동에 대한 공통적인 "큰 그림"이 개발되고 관련 당사자들에 의해 공유되는 것이 점점 더 중요해지고 있다.^[1]기능적 소프트웨어 아키텍처는 비즈니스 기능 및 해당 IT 요구에서 조직을 해체함으로써 이를 실현한다.이러한 방식으로 기업 엔지니어는 소프트웨어 엔지니어가 이러한 IT 시스템 개발에 사용할 수 있는 풍부한 개략도 참조를 제공한다.

기능적 소프트웨어 아키텍처의 개발은 다양한 (결합된) 방법과 기법에 의해 수행될 수 있다.다양한 방법과 기법의 조합을 통해 기업 엔지니어들과 소프트웨어 엔지니어들 사이의 "격차"를 채우는 것이 주요 목표가 될 것이다.그러나, 이 목표는 조합된 방법들로 인해 양 당사자가 개발하고 사용하는 명확하고 풍부한 기능적 소프트웨어 아키텍처가 발생할 때만 달성할 수 있다.

프로세스 리엔지니어링을 통해 내외부 비즈니스 프로세스를 최적화하는 것은 외부 압력이 높을 때 기업이 가질 수 있는 주요 목표 중 하나이다.비즈니스 프로세스에는 특정 입력 및 출력이 있는 가치 창출 활동이 포함되며, 이러한 활동은 상호 연결되어 프로세스의 결과(제품 또는 서비스)에 공동으로 기여한다.프로세스 리엔지니어링은 조직을 어떻게 변화시킬 것인가에 대한 다양한 관점을 다룬다.그것은 조직의 프로세스를 최적화하기 위한 전략적, 부가가치 프로세스, 시스템, 정책 및 조직 구조의 재설계와 관련이 있다.^[2]

비즈니스 모델링

기업 엔지니어링 공식 방법론, 방법 및 기법은 조직에게 재사용 가능한 비즈니스 프로세스 솔루션을 제공하기 위해 설계, 테스트 및 광범위하게 사용된다.

• 컴퓨터 통합 제조 오픈 시스템 아키텍처(CIMOSA) 방법론^[3]
• 통합 정의(IDEF) 방법론^[4]
• 페트리 네츠^[5]
• UML(Unified Modeling Language) 또는 UEML(^[6][7]Unified Enterprise Modeling Language)
• 엔터프라이즈 기능 다이어그램(EFD)

이러한 방법론/기술 및 방법은 모두 기업 및 그 기본 프로세스를 모델링하는 데 다소 적합하다.그렇다면, 그 중 효과적이고 효율적인(재설계된) 프로세스에 필요한 정보 기술 시스템의 추가 개발에 적합한 것은?더 중요한 것은 정보 및 소프트웨어 엔지니어가 IT 시스템의 효율성을 실현하는 데 있어 불명확한 결과를 사용할 수 없거나 사용할 수 없을 때 왜 시간이 많이 소요되는 엔터프라이즈 방법론을 사용하는가?이러한 질문에 대한 답을 제시하기 전에 위에 열거된 방법에 대한 몇 가지 간략한 설명이 제공된다.

컴퓨터 통합 제조 오픈 시스템 아키텍처

CIMOSA는 엔터프라이즈 요구사항의 비즈니스, 인력 및 IT 측면을 인코딩하기 위한 템플릿과 상호 연결된 모델링 구조를 제공한다.이것은 정보 보기, 기능 보기, 자원 보기, 조직 보기 등 다양한 관점에서 이루어진다.이러한 구조는 상세 IT 시스템의 설계와 구현을 촉진하고 구조화하는 데 사용될 수 있다.

서로 다른 관점으로 나누면 기업 및 소프트웨어 엔지니어에 대한 명확한 참조가 된다.그것은 서로 다른 기업 기능(활동, 프로세스, 운영)과 해당 자원에 대한 정보 요구를 보여준다.이러한 방식으로, 어떤 IT 시스템이 특정 활동과 프로세스에서 정보 요구를 충족시킬 것인지 쉽게 결정할 수 있다.

통합 정의(IDEF)

IDEF는 제조 시스템의 모델링을 위해 처음 개발된 구조화된 모델링 기법이다.이미 1981년 미 공군이 사용하고 있었다.처음에는 특정 관점에서 기업을 모델로 한다는 네 가지 다른 생각을 가지고 있었다.각각 기능, 데이터, 동적 및 프로세스 분석을 위한 IDEF0, IDEF1, IDEF2 및 IDEF3이 그것이었다.과거 수십 년 동안, 공명의 통합을 위한 몇 가지 도구와 기법이 점진적으로 개발되었다.

IDEF는 다양한 분해된 비즈니스 기능을 통해 비즈니스 프로세스가 어떻게 흘러가는지를 해당 정보 입력, 출력 및 행위자를 통해 명확하게 보여준다.CIMOSA와 마찬가지로 다른 엔터프라이즈 뷰도 사용한다.또한 IDEF는 시스템의 추가 개발을 위해 UML-다이아그램으로 쉽게 변환될 수 있다.이러한 긍정적인 특성은 기능적 소프트웨어 아키텍처의 개발을 위한 강력한 방법으로 만든다.

페트리 네츠

페트리 그물은 제조 시스템을 모델링하는 것으로 알려진 도구다.^[8]그것들은 표현력이 뛰어나고 동시 시스템 모델링을 위한 좋은 공식성을 제공한다.가장 유리한 특성은 상태의 단순한 표현, 동시 시스템 전환 및 전환 기간을 모델링하는 기능이다.

따라서 페트리 네트는 특정 비즈니스 프로세스를 해당 상태와 전환 또는 내부 및 결과물로 모델링하는 데 사용될 수 있다.게다가 페트리 네트는 다른 소프트웨어 시스템과 이들 시스템 간의 전환을 모델링하는 데 사용될 수 있다.이런 식으로 프로그래머들은 그것을 개략적인 코딩 참고자료로 사용한다.

최근 몇 년 동안 페트리 네트가 비즈니스 프로세스 통합 개발에 기여할 수 있다는 것을 여러 차례 시도했다.그 중 하나가 IBM 중국 연구소에서 개발한 모델 블루 방법론이며, 통합 플랫폼 구축을 위한 새로운 접근방식으로서 모델 중심 비즈니스 통합의 중요성을 개략적으로 설명하고 있다.^[9]그들의 Model Blue 비즈니스 뷰와 동등한 Petri Net 간의 매핑도 보여 그들의 연구가 비즈니스와 IT 간의 격차를 좁힌다는 것을 보여준다.그러나 페트리 넷트 대신 자체적인 모델 블루 IT 뷰를 사용하는 것이 더 바람직하며, 이는 혁신 엔진을 통해 비즈니스 관점에서 도출할 수 있다.

통합 모델링 언어

UML은 소프트웨어 시스템과 응용 프로그램의 개발을 위해 널리 받아들여지는 모델링 언어다.객체 지향 커뮤니티도 기업 모델링 목적으로 UML을 이용하려고 한다.그들은 복잡한 기업 시스템이 만들어지는 기업 객체나 사업 객체의 사용을 강조한다.이러한 개체들의 집합과 그들 사이의 상응하는 상호작용은 복잡한 비즈니스 시스템이나 과정을 나타낼 수 있다.Petri Nets가 개체의 상호 작용과 상태에 초점을 맞추는 경우 UML은 비즈니스 개체 자체에 더 초점을 맞춘다.때로는 자원, 프로세스, 목표, 규칙 및 변혁을 포함하는 "엔터프라이즈 빌딩 블록"이라고 불린다.^[10]이러한 방식으로 UML을 통합 소프트웨어 시스템을 모델링하는 데 사용할 수 있지만, 비즈니스 현실은 소프트웨어 모델링 언어로 모델링될 수 있다는 주장이 제기되어 왔다.이에 대해 객체지향적 커뮤니티는 UML을 위한 사업 확장을 하고 언어를 적응시킨다.UEML은 UML에서 파생되었으며 비즈니스 모델링 언어로 제안되었다.이 사업 전환이 과연 옳은 일인가 하는 의문이 남는다.앞서 UML이 다른 '순수한' 사업 방식과 결합하는 것이 더 나은 대안이 될 수 있다고 말한 바 있다.

엔터프라이즈 함수 다이어그램

EFD는 엔터프라이즈 기능과 해당 상호작용을 표현하기 위해 사용되는 모델링 기법이다.이러한 표현에서 "기능 모듈"과 트리거를 통해 서로 다른 비즈니스 프로세스를 모델링할 수 있다.시작 비즈니스 프로세스는 서로 다른 기능에 다른 입력을 전달한다.모든 기능과 하위 기능을 통해 흐르는 프로세스는 여러 개의 출력을 생성한다.엔터프라이즈 기능 다이어그램은 비즈니스 프로세스와 그에 상응하는 기능, 입력, 출력 및 트리거를 매우 쉽고 상세하게 표현한다.이러한 방식으로 EFD는 IDEF0 다이어그램과 많은 유사점을 가지고 있으며, 이는 기능과 트리거의 조합으로 비즈니스 프로세스를 계층적으로 나타내기도 한다.차이점은 EFD가 비즈니스 기능을 조직의 계층적 관점에 배치하고, 조직 내 특정 프로세스의 다운스트림을 정리한다는 점이다.반대로 IDEF0 도표는 화살표 사용을 통해 특정 비즈니스 기능의 책임을 보여준다.또한 IDEF0은 모든 (하위) 기능의 입력과 출력에 대한 명확한 표현을 가지고 있다.

EFD는 UML과 같은 소프트웨어 모델링 언어의 비즈니스 프런트엔드로 사용될 수 있다. 모델링 도구로서의 IDEF와 가장 유사한 점은 이 작업이 수행될 수 있음을 나타낸다.그러나, IDEF와 UML의 보완적 사용에 관한 EFD 기법을 UML에 대한 공식적인 매핑이 이루어질 수 있는 방법으로 개선하기 위해 더 많은 연구가 필요하다.^[1]유사한 연구가 EFD와 UML로 수행되어야 한다.

참조