프레임 기술(소프트웨어 엔지니어링)
Frame technology (software engineering)프레임 기술(FT)은 언어 중립(즉, 다양한 언어 처리) 시스템으로, 프레임이라 불리는 재사용 가능하고 기계 적응이 가능한 빌딩 블록으로부터 맞춤형 소프트웨어를[1] 제조한다.FT는 크고 복잡한 소프트웨어 시스템의 설계, 시공 및 진화에 수반되는 시간, 노력, 오류를 줄이기 위해 사용된다.FT의 기본은 유사하지만 미묘하게 다른 구성요소의 확산을[2] 막는 능력인데, 이는 프로그래밍 언어 구성(하위 경로, 클래스 또는 템플릿/세대)이나 매크로 및 발전기와 같은 추가 기법이 실제적이고 확장 가능한 솔루션을 제공하지 못한 문제를 야기하는 소프트웨어 엔지니어링이다.
많은 FT 구현이 존재한다.Netron Fusion은 비즈니스 소프트웨어 제작을 전문으로 하며 독점적이다.ART (Adaptive Reuse Technology) [2]는 FT의 범용 오픈소스 구현이다.Paul G. Bassett은 변화하는 요구사항과 상황에 맞게 프로그램을 수정(생성 및 수기)하는 데 수반되는 반복적이고 오류가 발생하기 쉬운 편집을 자동화하기 위해 첫 번째 FT를 발명했다.
도메인 모델링, 요건 수집, 아키텍처 및 설계, 건설, 시험, 문서화, 미세 조정 및 진화를 포함하여 FT가 소프트웨어 라이프사이클의 대부분의 측면을 어떻게 촉진할 수 있는지를 설명하는 실질적인 문헌이 현재 존재한다[3][4][5][6][7][8][9][10].FT와 대안적 접근법을[11] 독립적으로 비교함으로써 복잡한 시스템을 구축하고 유지하는 데 필요한 시간과 자원이 실질적으로 감소할 수 있음을 확인하게 된다.한 가지 이유: FT는 프로그래머를 소프트웨어의 고유한 중복성으로부터 보호한다.FT는 COTS 객체 라이브러리를 2/3 더 작고 단순한 동등한 XVCL 프레임 라이브러리에서 재현했다.[2][6] 사용자 지정 비즈니스 애플리케이션은 Netron Fusion에 의해 정기적으로 지정 및 유지 관리된다.조립된 소스 파일 크기의 5% – 15%인 SPC 프레임.[7]
프레임
아래는 두 가지 비공식적인 설명에 이어 보다 정확한 정의와 설명이 뒤따른다.
- 프레임은 자동화된 소프트웨어 조립 라인의 적응성 부품이다.각 자동차 모델의 세부 사항에 맞는 범퍼, 펜더 및 기타 부품을 갖추지 않고 범퍼, 펜더 등 한 개만 갖추는 자동차 공장을 상상해 보십시오.이제 이러한 일반적인 부품들이 복제되어 각 자동차 모델에 맞게 만들어질 수 있다고 상상해 보십시오.그러한 환상은 제조업에 혁명을 일으킬 것이다; 그리고 물리적인 부분에서는 불가능하지만, 이것은 프레임들이 소프트웨어(및 일반적으로 정보)를 위해 하는 것이다.
- 액자는 (프로그램) 텍스트를 "조리"하는 방법이다.그 지침서는 그 안에 있는 프레임 텍스트 덩어리와 다른 프레임의 재료들을 어떻게 혼합하는지에 대해 말하고 있다."chef"는 기본 레시피에 맞게 필요에 따라 재료를 변경(추가, 수정, 삭제)하는 프레임 명령과 같은 지시사항을 수행하는 프레임 프로세서다.
형식적으로 프레임은 프레임 텍스트 – 0개 이상의 일반(프로그램) 텍스트 및 프레임 명령(FT의 프레임 프로세서가 사용자 정의 프로그램을 제조할 때 수행함)으로 구성된 절차적 매크로다.각 프레임은 내포된 횡단구성요소의 계층 구조에서 일반적인 구성요소인 동시에, 그 횡단구성요소의 프레임과 자신을 통합하는 절차(더 높은 수준의 횡단구성요소에 유리한 통합 충돌을 해결하는 재귀적 과정)이다.출력물은 사용자 정의 문서로, 일반적으로 컴파일 가능한 소스 모듈이다.
주요 명령어
- 프레임(프로그램 텍스트 구축 중 시공 시 발생하는 절차 호출)
- 프레임 매개변수(구문 시간 변수 할당)에 식(목록)을 할당한다.
- 매개변수 표현식으로 레이블이 지정된 프레임 텍스트 블록 앞에, 대신 또는 뒤에 프레임 텍스트 삽입
- 프레임 매개변수(구축 시간 표현식 평가)를 인스턴스화한다.
- 가공할 프레임-프레임 선택(시공 사례 명세서)
- 특정 프레임 매개변수를 변경하면서 프레임 텍스트를 반복한다(문장 작성 중 시간).
프로세서는 명령을 일반 텍스트로 대체하고 일반 텍스트를 그대로 방출하여 프레임 텍스트를 변환한다.예:호출된 프레임을 처리한 결과에 의해 호출이 대체되고 할당을 무(無)로 대체하며, 인스턴스화는 문자열, 산술 표현식 및 내포된 프레임 파라미터의 결합이 될 수 있는 프레임 파라미터의 할당 식을 평가한 결과 발생하는 일반 텍스트가 된다.
구성 요소 관계
호출: 프레임 간의 구성 요소 관계 설정예를 들어, 그림 1에서: F는 J의 성분이고 C는 J의 하위 성분이다.물론 많은 구성요소는 F를 호출하는 I 및 J에서와 같이 동일한 하위 구성요소를 호출할 수 있으며, 각 구성요소는 다른 텍스트를 구성할 수 있다.전체 구성요소 구조는 일반적인 반밀라티스를 형성하며,[12] 각 프레임이 횡단구성요소의 뿌리가 된다.따라서 C는 자체적인 횡단구성요소로서 F와 C는 F 횡단구성요소의 구성요소, J, F, C는 J 횡단구성요소의 구성요소다.[13]
컨텍스트 범위 지정
컨텍스트 범위 지정은 FT와 다른 모델링 및 시공 시스템을 구분하는 것이다.각 프레임은 그것의 횡단구성요소를 통합하는 컨텍스트를 구성한다.내포된 횡단구성요소에서 하위 수준은 더 적은 정보를 통합하기 때문에 점차적으로 문맥이 없다.통합 충돌은 매개 변수를 할당하거나 삽입하는 가장 상황에 민감한 프레임을 위해 해결된다. 즉, 해당 프레임의 횡단구성요소에 있는 다른 모든 프레임에 읽기 전용이 된다.[14]그림 1에서 프레임 F와 C는 매개 변수 p에 서로 다른 값을 할당하면 충돌한다.따라서 F는 C – 즉, 프레임 프로세서가 P에 대한 C의 할당을 무시하고 F와 C에서 P에 F의 값을 사용한다.마찬가지로, J는 F와 C를 모두 무시할 수 있다.
컨텍스트 범위 지정이 중요한 이유는 주어진 컨텍스트에 임의의 (하위) 컴포넌트를 맞추는 데 필요한 모든 조정은 명시적이고 해당 컨텍스트에 로컬이기 때문이다.문맥 범위 지정이 없는 경우 그러한 조정은 대부분 암묵적, 분산적, 구성요소 변형 내에서 숨겨진다.그러한 변형은 확산되어 불필요한 중복성과 복잡성을 야기하는 경향이 있을 뿐만 아니라, 시스템 진화 또한 불필요하게 어렵고 오류가 발생하기 쉽다.
사양 프레임 및 템플릿
사양 프레임(SPC)은 전체 어셈블리의 최상위 프레임이므로 가장 상황에 맞는 프레임이다.프로세서는 완전한 프로그램이나 서브시스템을 제조하기 위해 그림 1의 L이나 M과 같은 SPC에서 시작한다.원칙적으로 SPC는 모든 세부사항을 사용자 정의할 수 있지만, 대부분의 예외(및 예외 등에 대한 예외)는 이미 다양한 횡단구성요소 프레임에 의해 처리되었기 때문에 SPC는 전체 조립품의 작은 부분이다.
프레임 라이브러리가 주어진 SPC는 자신이 구성하는 프로그램을 논리적으로 수반하므로 SPC는 소스 파일을 1차 제어 지점으로 대체한다.템플릿을 사용하여 프로그램을 만드는 SPC를 만든 다음 SPC를 사용하여 프로그램을 무한정 관리하고 발전시키는 것이 일상적이다.이러한 관행은 애플리케이션 프로그래머가 알고 관리해야 하는 세부사항의 수를 크게 줄인다.또한 손으로 원본 텍스트를 복사하고 편집하는 데 내재된 중복성, 복잡성, 오류를 방지한다.대부분의 구성 요소가 재사용되기 때문에 디버깅 시간도 단축되므로 사전 테스트가 필요하다.오류는 SPC에서 가장 덜 테스트되기 때문에 국소화하는 경향이 있다.
템플릿은 원형 SPC로, 그것을 어떻게 커스터마이징하는지를 설명하는 코멘트가 내장되어 있다.전형적으로 프로그램 종류는 소수인데, 각 종류는 템플릿으로 특징지어진다.그것을 복사하고 채움으로써, 프로그래머들은 그들이 필요로 하는 프레임, 그들의 구성 요소 관계, 또는 일반적으로 커스터마이징에 필요한 세부사항들을 기억할 필요 없이 템플릿을 SPC로 변환한다.
프레임 기반 도메인별 언어
FT 기반 도메인 고유 언어(FT-DSL)는 의미론(프로그램 코드로 표현)이 프레임으로 엔지니어링된 도메인 고유 언어다.일반적인 FT-DSL 편집기는 DSL 표현식과 DSL 표현식의 프로그램 코드 등가물을 표현하기 위해 프레임 의미학을 조정하는 프레임 사이에서 번역한다.이 횡단구성요소의 꼭대기에 앉은 SPC는 프로그램 코드에서 도메인별 언어로 표현할 수 없는 사용자 정의를 지정할 수 있다.따라서 사용자가 변경된 DSL 식에서 프로그램 코드를 재생성할 때 이전 사용자 정의는 손실되지 않는다.[15]
프레임 엔지니어링
프레임 엔지니어링은 소프트웨어 엔지니어링을 프레임 기술 환경에 적용한다.여기에는 도메인 분석, 설계, 쓰기, 테스트 및 이들이 구성하는 시스템과 함께 프레임의 공동 진화가 포함된다.[10]골격은 상향식 및 하향식 양쪽에서 발생한다.상향식 프레임 엔지니어는 일반적으로 유사한 프로그램 요소(텍스트 스니펫에서 서브시스템에 이르는 모든 세분화)의 그룹을 일반 동등 항목으로 통합하고 매개변수화하여 프레임을 만든다.하향식 접근방식은 영역 전문지식과 반복적인 프로토타입 정교화, 애플리케이션 및 아키텍처 요구사항, 기업 표준, 수익률이 투자를 크게 초과하는 재사용 가능한 자산 집합의 진화에 대한 욕구에 의해 제약을 받는다.(재사용은 프레임 라이브러리의 전체 크기를 전체 크기로 나누어 측정한다.개별 프레임 재사용 횟수를 계산하거나 계산하는 방법)
성숙한 프레임 라이브러리는 소프트웨어 프로젝트 이해 당사자들이 시스템의 새로운 특징에 대한 주의를 제한할 수 있기 때문에 비용 효율성을 높인다.성숙한 도서관은 정적이 아니다.프레임 엔지니어는 선택 명령을 사용하여 프레임의 이전 버전에서 제작된 프로그램에 대한 개보수가 필요 없이 새로운 요구사항을 충족하면서 재사용 가능한 프레임을 무한정 진화시킬 수 있다.[7]
각주
- ^ 소프트웨어는 여기서 강조하지만 적절한 프레임을 감안할 때 FT는 기술 및 최종 사용자 설명서, UML 모델, 테스트 사례, 법적 계약서, BOM 등 모든 종류의 문서를 조립할 수 있다.
- ^ a b S.자르자벡과 S.Li, "구성 및 적응" 메타프로그래밍 기법으로 중복 제거" Proc.유럽 소프트웨어 Eng.Conf./ACM/SIGSoft Simple.소프트웨어 엔지니어링의 기초, (ESEC/FSE 03) ACM Press, 2003, 페이지 237–246; ACM 고유 논문상 수상
- ^ P.G.Bassett "프레임 기반 소프트웨어 엔지니어링", IEEE 소프트웨어, 1987년 7월, 페이지 9 -16
- ^ "C.Holmes and A. Evens, "A Review of Frame Technology." Nov. 28 2003;" (PDF). Archived from the original (PDF) on 2004-07-19. Retrieved 2008-10-10.
- ^ F.Sauer, "프레임 지향 프로그래밍을 사용한 메타데이터 기반 다중 기술 코드 생성", 모델 기반 아키텍처 (Oopsla 02), 2002년 [1]
- ^ a b H. Basit, D.C. Rajapakse, S. Jarzabek, "Beyond Templates:STL에서의 클론에 관한 연구Int'l Conf.소프트웨어 Eng. (ICSE 05), ACM Press, 2005, 페이지 451–459
- ^ a b c P.G. Bassett, Framing Software Reuse: Real World의 교훈, 프렌티스 홀, 1997.
- ^ S. Jarzabek, Effective Software Maintenance and Evolution: A Reuse-based Access, Auerbach, 2007.
- ^ P.G.Bassett, "프레임 기반 소프트웨어 엔지니어링 사례", IEEE 소프트웨어, 2007년 7월, 페이지 90–99
- ^ a b P.G.Bassett, "어댑티브 컴포넌트:소프트웨어 엔지니어링의 에이스 인 더 홀" 커터 컨소시엄의 신속한 프로젝트 관리, Vol.5 #5
- ^ I. 그로스만과 M.Mah, QSM Associates, 1994년 기술 보고서 "소프트웨어 재사용에 대한 독립적 연구"
- ^ 세미라티스는 매개변수 값에 따라 노드와 그래프 구조가 달라질 수 있기 때문에 일반적이다.
- ^ 그 모호함은 하위조립체를 하나의 요소로 생각하는 정신적 습관을 반영한다.
- ^ 중첩되지 않은 횡단구성요소는 동일한 매개변수를 재할당할 수 있다.
- ^ 동일한 커스터마이징을 재생된 코드로 수작업으로 편집하여 FT의 발명에 박차를 가했다.