구성 요소 중심 개발이란 무엇입니까?

Question

구성 요소 중심 개발 용어가 광범위하게 사용되기 시작했습니다. 제어의 역전과 관련하여.

1. 무엇입니까?
2. 어떤 문제가 해결됩니까?
3. 언제 적절하고 그렇지 않습니까?

Answer 1

무엇입니까?

귀하의 답변의 정의 가이 질문을 잘 다루고 있다고 생각합니다. 그러나 정의에 구성 요소가 그 종속성을 명시 적으로 정의해야한다는 이유에 의문을 제기합니다. 구성 요소의 표준 예는 ActiveX 제어입니다. 종속성을 명시 적으로 정의해야합니까?

어떤 문제가 해결됩니까?

복잡성 관리. 구성 요소의 구현에 대해서만 생각할 수있게함으로써이를 해결하려고합니다. 구성 요소 만 작성하면됩니다. ~ 아니다 그것들을 결합하거나 관리하는 방법에 대해 생각해야합니다. 이는 구성 요소 외부의 일부 프레임 워크 또는 인프라에 의해 수행되며 구성 요소 저자에게 중요하지 않습니다.

언제 적절하고 그렇지 않습니까?

3 번의 또는 던지기 응용 프로그램에서 반드시 적합한 것은 아닙니다. 구성 요소 아키텍처의 나쁜 냄새는 구성 요소가 아닌 구성 요소를 관리하고 결합하기 위해 인프라를 생각하거나 작업하는 데 시간을 소비하는 경우입니다.

Answer 2

"광범위한"용어인지는 확실하지 않지만 VCS (버전 제어 시스템)에서는 프로그램을 구축하는 데 필요한 파일 세트를 관리하는 두 가지 방법을 알고 있습니다.

• 시스템 기반 접근법, 모든 세트에 공통 수명주기가 있고 모든 사람으로 태그가 지정되어야합니다.
• 개별 파일 세트에 자체 수명주기가 있고 메타 라벨이 구성 요소의 모든 레이블을 참조하여 해당 구성 요소 간의 구성 및 종속성에 의해 모든 시스템을 지정하는 구성 요소 기반 접근법.

그만큼 적용 아키텍처 이러한 구성 요소를 식별하는 데 사용됩니다.

• 기능적 도메인 및 응용 프로그램
• 제 3 자 라이브러리
• 프레임 워크

그것이 모든 프레임 워크의 기본이기 때문에 IOC가 들어오는 곳입니다. 그것이 해결하는 문제는 응용 프로그램의 일부를 더 잘 식별 할 수 있다는 것입니다.
상인의 이익 및 손실 (위치)을 계산하기 위해 PLR (이익 및 손실) 응용 프로그램을 설계한다고 가정 해 봅시다.
당신은 그것이 단일 응용 프로그램이 아니라 여러 가지 구성이라는 것을 빨리 깨달을 것입니다.

• 구이
• 발사통
• 디스패처 (여러 서버에서 계산을 발송하려면 모두 계산할 수있는 메모리가 충분하지 않기 때문에!)
• 기타 등등

그런 다음 다른 모듈을 플러그인 할 수있는 IOC (Computation Framework)를 식별 한 다음 프레임 워크에 의해 적절한 시간에 호출됩니다.

또는 순전히 식별 할 수 있습니다 기술 프레임 워크 (KPI, 로그, 예외 관리)는 다른 사람이 사용할 수 있습니다. 기능의 구성 요소.

프로젝트 관리 측면에서 VC를 통한 글로벌 조정을 보장하면서 각 부품을 독립적으로 개발할 수 있습니다.

Answer 3

구성 요소 기반 개발은 실제로 새로운 것이 아닙니다. 나는 구성 요소 중심 개발을 모르지만 CBD라고 가정하겠습니다. 유닉스가 설계된 방식입니다. 데스크탑 경기장에서 Delphi의 VCL은 재사용 가능한 부품 및 타사 시장이있는 구성 요소를 사용하는 데 성공했습니다. 우리는 이제 일부 기술이 성숙함에 따라 CBD의 부흥을보고 있습니다. 예를 들어 간단한 웹 앱은 SOA 및 RESTFUL WS로 발전하고 있습니다. 모든 Java 남자들에 대해 이야기 한 것은 모듈성과 IOC입니다.

당신이 찾고있는 대답은 통제의 반전의 이유와 기준 Ke Jin.

또한, 이러한 고전적인 OO 프로그래밍 언어의 명령 자연은 나무 (저수준 논리 제어 절차 코드)의 산림 (고급 아키텍처/구조)을 놓치는 경향이 있습니다. 기존 애플리케이션을 인수하는 개발 및 유지 보수 엔지니어는 해외 설계/아키텍처 문서 및 저수준 코드 주석/패턴에 의존해야합니다.

구성 요소 기반 개발 (CBD) 패러다임은 배관 논리를 프레임 워크로 전환하여 구성 요소를 조작하고 선언적 설명을 제공 한 사용자/개발자를 기반으로 응용 프로그램을 설정하여 위의 두 가지 문제를 해결합니다. 일반적인 혼란과는 달리, 그러한 선언적 설명은 응용 프로그램 설정 스크립트가 아닙니다. 오히려, 그들의 근본적인 의도는 명령적인 배관 절차를 의무화하지 않고 응용 프로그램 아키텍처/구조를 명시 적으로 표현하는 것입니다 (즉, How 대신에 무엇을 설명). CBD 패러다임의 목표는 이러한 프레임 워크에 의해 효과적이고 유연한 응용 프로그램 구성을 지원하고 애플리케이션 개발자가 저수준의 배관 복잡성에 대해서는 비즈니스 로직 및 도메인 문제에 집중하는 것입니다.

선언적 응용 프로그램 설명과 IOC 기술을 결합한 CBD 프레임 워크를 IOC 프레임 워크라고합니다. 전임자와는 달리 IOC 프레임 워크는입니다 비 침습적 그리고 사용하십시오 종속성/구성 주입/설정 시나리오.

Wikipedia에 따르면, 구성 요소 기반 개발은 구성 요소 기반 소프트웨어 엔지니어링 (CBSE).

그것은] 소프트웨어 엔지니어링의 지점이며 우선 순위는 우려의 분리 주어진 소프트웨어 시스템에서 사용 가능한 광범위한 기능과 관련하여.

이것은 다소 모호하기 때문에 자세한 내용을 살펴 보겠습니다.

개별 구성 요소는 관련 기능 세트 (또는 데이터)를 캡슐화하는 소프트웨어 패키지 또는 모듈입니다.

모든 시스템 프로세스는 별도의 구성 요소에 배치되므로 각 구성 요소 내의 모든 데이터 및 기능이 의미 적으로 관련되어 있습니다 (클래스의 내용과 마찬가지로). 이 원칙으로 인해 구성 요소는 종종 모듈 식 그리고 결합력 있는.

따라서이 정의에 따르면, 구성 요소는 한 가지 일을 정말 잘하고 한 가지 일만 할 수 있습니다.

시스템 전체의 조정과 관련하여 구성 요소는 서로 통신합니다. 인터페이스. [...]이 원칙은 다음과 같은 구성 요소를 초래합니다. 캡슐화.

따라서 이것은 우리가 좋은 API 또는 SOA에 대해 생각하는 것과 비슷하게 들립니다.

그만큼 제공 인터페이스는 롤리팝으로 표시됩니다 필수의 인터페이스는 UML의 구성 요소의 바깥 쪽 가장자리에 연결된 열린 소켓 기호로 표시됩니다.

_{(원천: wikimedia.org)}

구성 요소의 또 다른 중요한 속성은 그것들이 있다는 것입니다 대체 가능, 초기 구성 요소의 요구 사항이 (인터페이스를 통해 표현 된) 구성 요소에 의해 충족되는 경우 구성 요소를 다른 설계 시간 또는 런타임으로 대체 할 수 있습니다.

재사용 성은 고품질 소프트웨어 구성 요소의 중요한 특성입니다. 소프트웨어 구성 요소는 다양한 프로그램에서 재사용 할 수 있도록 설계 및 구현해야합니다.

대체성과 재사용 성은 구성 요소를 구성 요소로 만드는 것입니다. 그렇다면 이것과 객체 지향 프로그래밍의 차이점은 무엇입니까?

OP (Object-Oriented Programming)의 아이디어는 소프트웨어가 실제 또는 상상 된 객체의 정신 모델에 따라 작성되어야한다는 것입니다. [...

대조적으로 구성 요소 기반 소프트웨어 엔지니어링은 그러한 가정을하지 않으며 대신 전자 제품 또는 기계공 분야에서와 같이 조립식 구성 요소를 함께 붙여서 소프트웨어를 개발해야한다고 명시하고 있습니다.

Answer 4

연구를 한 후 내 정의는 다음과 같습니다.

구성 요소 중심 개발 코드가 비즈니스 기능을 제공하기위한 애플리케이션 재단을 형성하기 위해 함께 결합 된 재사용 가능하고 테스트 가능한 구성 요소로 코드를 조각화하는 소프트웨어 개발의 접근 방식입니다. 구성 요소의 조합 및 관리는 일반적으로 제어의 역전 컨테이너.

구성 요소 자체는 일부 서비스 계약을 구현 하고이 계약을 이행하기 위해 필요한 종속성을 명시 적으로 정의하는 클래스입니다. 실제 구현은 구성 요소 외부의 다른 모든 사람들에게 숨겨져 있습니다.

관련된 링크들:

• 구성 요소 중심 개발 및 IOC 컨테이너

Answer 5

나는 구성 요소 기반 소프트웨어 엔지니어링을 플러그 가능한 구성 요소를 사용하여 소프트웨어 시스템을 개발하기위한 접근법으로 본다. 구성 요소가 "계약 상 지정된 인터페이스 및 명시 적 컨텍스트 종속성 만있는 구성 단위", 어느 "독립적으로 배포 할 수 있으며 타사 구성이 적용됩니다.. "(Clemens Szyperski,"구성 요소 소프트웨어 : 객체 지향 프로그래밍 이상")

CBSE는 유연한/적응 가능한 소프트웨어 시스템의 코드 재사용 및 빠른 조립을 용이하게합니다.

수년간이 주제에 중점을 둔 상당한 연구가 있습니다. 플래그십 이벤트 (구성 요소 기반 소프트웨어 엔지니어링에 대한 ACM SIGSOFT 심포지엄)은 현재 14 년째에 있으며 몇 가지 새로운 트렌드가 떠오르고 있습니다.

또한 오늘날 업계에서 많이 사용하는 재사용 가능, 플러그 가능 및 확장 가능한 구성 요소의 좋은 예를 원한다면 MS Enterprise Library.

Answer 6

부품 (또는 기타 재사용 가능한 자산)을 응용 프로그램에 결합하는 데 관심이 있으시면 소프트웨어 제품 라인 방법론.

소프트웨어 제품 라인에서 구성 요소 (또는 하위 수준 코드 요소) 간의 종속성은 해당 구성 요소 외부에서 명시 적으로 관리됩니다. 이것은 일반적으로 a를 사용하여 수행됩니다 기능 모델 여기에는 다음과 같은 규칙이 포함되어 있습니다

• 이 두 구성 요소는 함께 사용해서는 안됩니다 (상호 독점 성)
• 이 구성 요소를 사용하는 경우이 다른 구성 요소를 사용하거나 (상호 의존성)
• 일부 지정된 구성 요소 세트의 조합 (선택성)

다른 복잡한 규칙은 모델링하려는 종속성의 복잡성에 따라 가능합니다.

기능 모델링 대신 때때로 사용되는 또 다른 방법은 코드 생성기를 사용하여 완성 된 응용 프로그램에 조립할 다양한 구성 요소를 구성하는 것입니다. 기능 모델링과 코드 생성을 결합 할 수도 있습니다.

코드 생성 외에도 도메인 별 모델링, 모델 중심 소프트웨어 개발, 소프트웨어 패밀리로 검색 할 수있는 다른 용어.

Answer 7

Unity 3D를 사용하려고 할 때까지 실제로 구성 요소 중심의 개발이 무엇인지 이해하지 못할 것입니다. 그것은 ActiveX 또는 이전에 본 것 중 하나가 아닙니다. 이전에 본 것은 다른 구성 요소 의미가 있습니다.

구성 요소 중심의 개발은 최근에 모든 사람에게 말하면, 당신은 두 가지를 의미합니다.

1. 물체 - OOP 프로그래밍 또는 실제 대상의 개체와 같습니다.
2. 객체의 구성 요소 - 객체 기능의 일부 또는 능력 중 하나와 같습니다.

따라서: 구성 요소 - 객체가 아닙니다. 객체의 기능입니다.

따라서 표준 OOP 프로그래밍에서 새로운 기능으로 기본 객체를 확장해야 할 때 기본 객체를 상속하여 새 파생 된 객체를 만들어야합니다.

구성 요소 구동 개발에서 확장 된 객체가 필요할 때 빈 객체를 만들고 상속없이 다른 구성 요소로 채우는 것입니다. 구성 요소 중심 개발에는 클래스가 없습니다. 사전 랩 대신 - 미리 정의 된 구성 요소가있는 사전 정의 된 객체입니다.

내가 말했듯이 당신은 시도 할 때까지 결코 이해하지 못할 것입니다. 구성 요소-드라이브 개발을 사용하면 항상 프로그래밍을 사용할 필요가 없으며, 그래픽 편집기를 대신 사용할 수 있으며, 일반적인 OOP의 상속 지옥에서 벗어날 수 있습니다. 구성 요소 자체는 일반적인 프로그래밍으로 프로그래밍되었지만 객체를 포함한 더 높은 레벨 시스템은 주로 편집기에 구성 요소를 사용하고 결합하면 맞춤형 객체 동작을 수신하면됩니다.

따라서 : 구성 요소 중심 개발은 다음과 같습니다.

1. 프로그래밍없이 편집기 만 사용하여 프로그램의 논리를 만들 수있는 큰 힘.
2. OOP 상속 물에서 당신의 마음을 해방시킵니다. 개발을보다 간단하고 빠르게 만듭니다.
3. 코드를 터치하지 않고도 프로그램을 고도로 사용자 정의하고 확장 가능하게 만듭니다. 더 적은 오류와 버그.
4. REST 시스템에 큰 영향을 미치지 않고 특정 구성 요소를 재 프로그래밍하여 프로그램 코드를 더 쉽게 유지 관리합니다.
5. 등...

또한 구성 요소 기반 (DRIVEN) 프로그래밍은 OOP 프로그래밍을 대체하지 않고 OOP 또는 일반적인 프로그래밍 위에 있습니다. 저수준 구성 요소의 구현에 CBP에서 여전히 사용되는 일반적인 프로그래밍. 이 기사는 CBP에 대한 좋은 설명도 가지고 있다고 생각합니다. http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf