11 28 Reading_Assignment_7(20094068 3학년 이준서) - JunSeoLee/project_team_5 GitHub Wiki

###관점 지향 프로그래밍

컴퓨터 과학은 프로그래밍 언어의 진화를 경험해왔다. 구조화 된 공식 번역, 절차 적 프로그래밍과 같은 개념을 통해 구조적 프로그래밍, 함수 형 프로그래밍, 논리 프로그래밍, 추상 데이터 유형과 프로그래밍 등으로, 프로그래밍 기술의 각 단계는 소스 코드 수준에서 문제의 명확한 분리를 달성하는 능력을 전진했다. 현재의 지배적인 프로그래밍 패러다임은 객체 지향 프로그래밍이다. 하나의 객체로 문제를 분해하여 소프트웨어 시스템을 구축하는 아이디어이고 그리고 그 객체의 코드를 작성한다. 이러한 개체 추상적 하나의 개념 (육체적)개체에 동작 및 데이터를 저장한다. 객체 지향은 현재 소프트웨어 개발의 전체 스펙트럼에 반영된다.

ologies 및 도구 - 우리는 OO 방법론, 분석 및 설계 도구, 객체 지향 프로그래밍 언어가 있다. 유지 이해할 수 있는 소스 코드를 OOP로 가능하게 하고 있는 동안 같은 사용자 그래픽 인터페이스, 운영 체제 및 분산 응용 프로그램과 같은 복잡한 응용 프로그램을 작성한다. 객체 지향은 간단한 시스템 개발에 성공 큰 복잡성 열망으로 이어진다. 객체 지향은 영리한 아이디어이지만, 특정 제한 사항이 있다. 우리는 지금 많은 요구 사항을 단일 현장을 중심으로 행동으로 깔끔하게 분해하지 않는 것을 보고 있다. 깔끔하게 분리되지 않은 것들 객체 기술 어려움, 글로벌 제약과 유행성 행동과 관련된 문제를 지역화하고 적절하게 문제를 분리하는, 그리고 특정 도메인 지식을 적용 할 수 있다. OO 패러다임의 표현력을 높이기 위해 보고 후 개체 프로그래밍(POP) 메커니즘은 현재 연구를 위한 한 분야이다. POP 기술의 예로는 생식 도메인 특정 언어를 포함한다. 예를 들어 일반 프로그래밍, 제약 언어, 반사와 메타 프로그래밍, 기능 지향 개발, 뷰 / 관점, 비동기 메시지 브로커 등이 있다. 관점 지향 하나의 중요한 POP 기술 - (AOP 프로그래밍) AOP는 컴퓨터 시스템이 잘 분리하고 시스템의 여러 문제 (그 속성 또는 영역)와의 관계의 몇 가지 설명을 지정하여 프로그래밍하고 직조 기본 AOP 환경의 메커니즘에 의존하거나 구성하는 개념에 근거에 그들을 함께 일관성을 가지는 프로그램이다. 문제는 캐싱 및 버퍼링 같은 낮은 수준의 개념에 대한 서비스의 보안 및 품질과 같은 높은 레벨의 개념에 이르기까지 다양하다. 앞의 나온 내용들은 기능이나 동기화 및 트랜잭션 관리와 같은 비즈니스 규칙, 또는 (조직) 비 기능적, 같은 기능을 할 수 있다. OOP의 경향은 클래스 사이에 공통점을 찾는 동안 상속 트리에 AOP는 일류 요소로 분할시켜 실현하고, 객체 구조에서 수평으로 배출하려고 시도한다. 시스템의 구조 실현은 다른 여러 요소를 교차하면서 몇 가지 문제가 깔끔하게 특정 구조 부분에서 지역화 된 것을 발견 할 것이다. AOP는 같은 크로스 커팅 문제의 실현을 단순화 메커니즘에 초점을 맞추고 있다. 서로 상의 요구 사항(공통 구조 분해)을 구현하는 것과 크로스 커팅을 소개한다. 서로 상 요구 사항의 예는 일관된 잠금 프로토콜 다음에 작업의 전체 세트가 필요한 동기화 정책, 글로벌 정보를 필요로 복잡한 개체 그래프의 순회, 회계 메커니즘을 포함한다. 그는 모든 부과 조치 서비스에 대한 우려의 일관성 있는 중복 사본의 생성과 품질을 요구하는 결함 허용 메커니즘을 통보해야 한다. 이 시스템은 우선 순위의 미세 조정이 필요하다. 하나는 포트란 이후의 모든 프로그래밍 언어는 서브 프로그램을 작성하고 명시 적으로 호출하여 문제를 분리하는 방법을 가지고 있다. 서브 프로그램은 좋은 생각이다. 우리는 철저하게 자신의 사용을 승인. OOP 블록 구조와 구조화 프로그래밍의 아이디어를 폐기하지 않은 것처럼 AOP는 기존의 기술을 거부하지 않는다. 그러나 종종 관심의 표현은 깔끔하게 서브 루틴 호출에 의해 실현 될 수 없다. 다른 구조 요소에 해당 코드가 엉 키게 되고 관심이 엉망이 된다. 횡단 관심의 표현을 지역화 서브 루틴 및 상속 이외의 메커니즘이 문제를 덜기 위해, AOP는 측면을 제공한다. AOP 시스템도 일관된 시스템으로 측면과 기본 코드를 짜기 위한 몇 가지 메커니즘을 제공해야한다. 서브 프로그램은 또 다른 단점이 있다. 그들은 호출하는 구성 요소의 프로그래머의 부품에 대한 지식과 협력 모두를 필요로 한다. 즉, 하나는 명시적으로 서브 루틴을 호출하기 위해 알고 있어야하고, 그것을 호출하는 방법을 알고 있어야 한다. AOP 시스템은 추가적인 문제를 모르는 코드의 동작을 호출하기 위한 암시 적 호출 메커니즘을 제공한다. 프로그래밍 시스템에서 여러 우려의 표현을 분리하면 간단하게 시스템의 진화, 더 이해하는 시스템, 적응성, 커스터마이즈, 쉽게 재사용을 약속이 있다. AOP의 몇 가지 요소는 이 목표를 향해 작동합니다. 기존의 프로그래밍 이해하기 쉬운 화면 코드와 대상을 만드는 코드를 통해 배포 할 수 있는 단일 텍스트 구조의 동작으로 크로스 커팅 문제를 잡을 수 있다. 프로그래머는 항상 자신의 프로그램이 미래에 처리 할 필요가 있는 수요를 예측할 수 없는 변화 프로그램을 중요시 해야 한다. 그리고 그렇게 나온 프로그래밍은 재사용도 할 수 있으며, 측면은 다른 구성 요소에 연결 할 수 있다.

AOP 문제 – 그 문제 본질에서 AOP가 프로그래밍 기술이다. 모든 프로그래밍 기술과 마찬가지로, AOP는 두 프로그래머가 의사소통이 없는 컴퓨터 시스템이 작동하는 시스템에서 프로그램을 이해 가능하게 할 것을 해결해야 한다. 따라서 AOP 시스템의 목적은 전산 시스템에서 크로스 커팅 문제를 표현하는 방법을 제공 할뿐만 아니라, 또한 이러한 메커니즘을 보장하기 위해 개념적이고 간단하고 효율적으로 구현되어 있다. 현제 이 부분에서 서로 다른 문제에 대한 다른 접근 방법의 미묘한 차이에 반응을 보여야 한다. 시스템 간의 주요 차이점은 결합 프로그램과 측면의 기술에 있다. AOP 클리어 박스 접근 방식은 프로그램과 측면의 혼합물을 생산 프로그램과 화면 내부를 검사 할 수 있다. 반면에, 블랙 박스는 화면 래퍼로 덮개 구성 요소를 접근한다. 명심해야 할 다른 문제는 다음과 같다. 첫 번째로 AOP 시스템은 측면을 지정하는 방법에 대해 설명한다. 화면 파라미터, 측면이 특정 사용을 위해 사용자 정의 할 수 있는 정도는 측면 코드가 시스템의 나머지와 상호 작용하는 장소를 정의 포함하고 그리고 OO 의존성을 가진다. AOP 메커니즘은 비 OO 프로그래밍 시스템에서 사용할 수 있다. 두 번째로 어떤 구성 메커니즘은 시스템을 제공한다. 이 지배적 분해의 존재의 문제를 포함한다, (측면 적용하는 한 분해가 있는가, 또는 동일하게 다루는 모든 문제이다), 명시적인 구성 언어 (시스템 측면 적용되는 기술에 대해 별도의 언어를 가지고 있나? 이 특정 도메인 또는 일반 언어인가?), 서로 다른 측면의 가시성, 메인 프로그램과 측면 사이에 권한의 대칭, 측면에는 동작을 삭제할 수 순수 단조했는지 여부, 어떤 메커니즘 측면 간의 갈등을 해결하기 위해 제공된다, 과에 어느 정도의 구성 및 실행이 있다. 세 번째로 구현 메커니즘이다. 이 시스템이 실행되는 조성물 동적 컴파일 타임에 정적으로 결정 또는 여부이며, 정적 / 동적 차이를 포함한다. 프로그램의 요소가 개별적으로 컴파일 할 수 있는지 여부를 모듈 컴파일, 배포에서 장소, AOP 메커니즘은 기존의 시스템에 적용 할 수 있는지 여부. 확인을 조성하기 위한 메커니즘이 있는지 여부 및 검증, 대상 AOP 메커니즘이 소스 코드를 바이트 코드 또는 오브젝트 코드에 적용되었는지 여부표현이 있다. 네 번째로 디커플링이다. 이 메인 코드의 작가는 측면이 적용되는가를 알고 있어야하는 여부, 망각이 포함되며, 친밀감, 프로그래머는 측면 코드를 준비 할 수 있는지, 측면이 그것의 전체 또는 일부만 등의 프로그램에 적용할지 여부가 있다. 다섯 번째로 소프트웨어 프로세스이다. 이 시스템은 시스템 구축 활동을 구성하는 제공하는 것에 대한 방법론, 프레임 워크, 전체 프로세스를 포함, 측면 메커니즘 측면 재사용을 가능하게 재사용, 측면 메커니즘은 일반 또는 특정 도메인에 적용 할 수 있는지 여부를 도메인 특이성, 하나는 화면 시스템의 성능을 분석 할 수 있는지 여부를 가능케 하는 여부, 메커니즘 디버깅 측면과 시스템을 활성화하고 테스트 용이성이 있다. 위의 특별한 부분의 문서는 AOP의 주요 지적 tree, 역사적 발전, AOP의 응용 프로그램 및 완벽한 AOP 소프트웨어 엔지니어링 프로세스 방향으로의 개선을 포함한다. AOP는 많은 독립적 인 연구 경로의 융합이다. 기본 소프트웨어 엔지니어링 원리의 초기 표현에서 영감을 인용했다. 우리는 게스트 편집자 Tzilla 엘라 드에 의해 검토, 필드의 여러 유명 사이에 논의 섹션을 시작합니다. 오브젝트에만 밀접한 관련 지식이 있어야한다고 말한 Karl Lieberherr는 "데메테르의 법칙"을 주장했다. 구조와 행동 문제의 표현을 분리하기 위해 새로운 프로그래밍 기법을 사용하였다. 그리고 클래스 구조를 통해 코드를 추출하여 엉킴을 방지하는 적응 방법의 사용을 보여주었다. 1980년대 후반 William Harrison과 Harold Ossher는 소프트웨어 환경과 도구 통합에 대한 자신의 작업 동안 얻은 통찰력을 사용하여 (시스템 변형을 구축 할 수 있는 적절한 계층 구조의 후속 조성, 주제를 다른 클래스 계층 구조, 우려를 구현하는 각 개별 사양의 개념을 개척 지향 프로그래밍)와 같은 이론을 확립했다. Peri Tarr, 그들은 여러 동시 동일한 소프트웨어의 분해, 기존의 우려를 추출 할 수 있도록 하기 위해 이 방법을 진화시켰다. Ossher와 Tarr는 (재) 모양 진화하는 소프트웨어에 대한 우려의 다차원 분리를 사용하였다. Mehmet Aksit 및 Twente 대학교에서 그의 그룹은 AOP에 대한 필터 기반 접근 방식의 초기 및 가장 눈에 띄는 지지자이다. 1980년대 후반에, 필터의 원리는 일반 데이터 추상화 메커니즘을 표현하기 위해 개발되었다. 이 같은 구성 가능한 방식으로 여러 보기, 동기화 interobject 통신 및 실시간 사양과 같은 문제의 다양한 유형을 표현하기 위해 확장되었다. 이 문제에 Bergmans 및 Aksit의 기사이다. 간단하게 요약하여 구성 필터를 사용하여 여러 우려를 구성시킨다. 그리고 기본 구성 요소 주위에 필터를 배치하여 명시 적으로 필터의 측면을 구현하는 방법에 대해 설명한다. 크로스 커팅 문제에 초점을 우려하고, 기술 이전의 분리에서 AOP를 구별한다. 또한 AO 언어의 시리즈를 개발하고, 소프트웨어 디자인 측면의 역할 분석을 AOP에서 하는지 확인하고, AOP를 구축할 때 계층화 접근으로 운영 체제 측면을 구조화시키고, 도메인 특정 모델링에 가로로 자르는 제약 조건 처리의 가상 디자인과, 반사 metaobject는 프로토콜을 사용하여 AOP를 실시한다.

내 생각: AOP에서 사용하는 개념은 크게 4가지가 있는 것 같다. 점점(pointcut), 안내(advice), 내부타입선언(inter type declaration), 그리고 이들을 모두 묶어서 하나의 단위로 추상화하는 상황(aspect)가 있다. 접점(pointcut)은 공통의 관심사가 여러 개의 객체나 계층을 가로지를 때 그들과 만나게 되는 지점을 의미한다. 접점을 골라낸 후 할일을 정의하는 것이 안내(advice)이다. 객체지향의 메소드인 것 같다. 접점 전후로 해야 할일을 정의하는 알고리즘이 주 내용을 이룬다. 내부타입정의(inter type declaration)는 OOP와 달리 객체에 새로운 필드를 동적으로 더하는 것을 가능하게 만드는 걸 의미하는 것 같다 마지막으로, OOP에서 클래스가 변수와 메소드를 한곳에 묶어서 하나의 객체로 추상화하듯, AOP에서 사용되는 접점, 안내, 내부타입정의를 한 곳에 묶어서 추상화한 것을 상황(aspect)이라고 하는 것 같다. 본인은 AOP는 OOP를 대체할 만한 방법론이 아닌 단지 보완적인 방법론으로 생각한다. 그러나 새로운 방법론이 추가 된다면 가능성이 있어 보인다.