객체지향의 한계를 넘어, AOP 전은영,이재훈 고덕윤
Let’s play AOP 특별한 순서 AOP의 개요 AOP의 요구공학 AOP의 UML 디자인 AOP의 구현
오늘 임원회의에서 보안정책 강화지시가 내려졌어요 전은영씨 왜요? 과장님 설마 인터넷뱅킹에도 적용되는건 아니죠? 정확해요 설마 몰디브은행 전산팀 오늘 임원회의에서 보안정책 강화지시가 내려졌어요 전은영씨 왜요? 과장님 설마 인터넷뱅킹에도 적용되는건 아니죠? 정확해요 설마 계좌이체, 입출금, 이자계산까지 다 적용되는건 아니죠? 그것도 정확해요 은영씨? 네? 일주일안에 무조건하세요 설마 시간을 일주일만 주시는건 아니죠? 역시 은영씨는 정확해요 힘들어요 한 달안에는 불가능해요 네…
I. Overview
프로그래밍 패러다임의 변화 초기 프로그래밍 언어 절차적 프로그래밍 객체지향 프로그래밍 관점지향 프로그래밍 프로그래밍 패러다임의 변화 초기 프로그래밍 언어 절차적 프로그래밍 객체지향 프로그래밍 관점지향 프로그래밍 발전된 객체지향 프로그래밍
OOP의 문제점 이런 구조인데.. 일주일 만에 완료하라고? 제대로 짜증이죠? 계좌이체 입출금 이자계산 로깅 로깅 로깅 보안 트랜잭션 트랜잭션 트랜잭션
OOP의 문제점 // core concern code --------------------------- if (fromAcc.hasEnoughMoney(amount) == false) { throw new AccountException(“not enough money”); } fromAcc.withdraw(amount); toAcc.credit(amount); // core concern code --------------------------- unlockingAccount(fromAcc); unlockingAccount(toAcc); saveAccount(fromAcc); saveAccount(toAcc); txManager.commit(); } catch(TransasferException e) { txManager.rollback(); errorHandler.saveAppException(e); errorHandler.sendErrorNotificationToManager(); logger.exception(e); throw new BakingRuntimeException(e); } catch(PersistentException e) { logger.exception(e); errorHandler.sendErrorNotificationToDBA(); throw new BakingRuntimeException(e); } finally { txManager.close(); connectDB.close(); } logger.end(“transfer”); } ... } public class AccountTransfer extends AbstractAccountModule { Logger logger = MyLogger.getLog(“accountTransfer”); TransactionManager txManager = new MyDBTransactionManager(TxDefinition.Default); PersistentHelper persistentHelper = new MyPersistentHelper(Account.class, DBConst.DBConnectionInfo); Authentication auth = new LDAPAuthentication(); ErrorHandler errorHandler = MyHandlerFactory.getErrorHandler(); ... public void transafer(Accouno fromAcc, Account toAcc, int amount) { logger.begin(“transfer”); if (auth.checkLoginedUser() == false) { throw new NotLoginedUserAccessException(); } if (auth.checkAuthorization() == false) { throw new AuthorizationFailException(); } persistentHelper.connectDB(); txManager.beginTransaction(); try { loadAccount(fromAcc); loadAccount(toAcc); lockingAccount(fromAcc); lockingAccount(toAcc); …
OOP의 문제점 중복코드 지저분한 코드 생산성 저하 재 활용성 저하 변화의 어려움
새로운 대안 Crosscut Concern (횡단관심) 묶자 계좌이체 입출금 이자계산 로깅 로깅 로깅 보안 보안 보안 트랜잭션
AOP 의 적용 public class AccountTransfer extends AbstractAccountModule { public void transafer(Accouno fromAcc, Account toAcc, int amount) { if (fromAcc.hasEnoughMoney(amount) == false) { throw new AccountException(“not enough money”); } fromAcc.withdraw(amount); toAcc.credit(amount); } … }
AOP 의 적용 Aspect Class 핵심관심모듈 횡단관심모듈 Weaving 로 깅 계좌이체 보 안 입출금 트랜잭션 이자계산
Inheritance vs. Aspect Dead-lock 발생, Data 영속성 오류 지저분한 코드 그렇다면, 이 문제는 OOP의 상속으로 해결이 가능하지 않아? Dead-lock 발생, Data 영속성 오류 지저분한 코드 (Java의 경우) 다중상속의 불가 재활용성의 감소 상위 클래스가 하위 클래스의 종속화
II. Requirement Engineering
AOP 요구공학의 기본 모델 Identify concerns Identify viewpoints, Discover requirements and relate to concerns Specify concerns Identify candidate aspects Specify and prioritize aspects Specify aspect dimensions
Ex. 고속도로 High-pass system 전국 고속도로에 High-pass 시스템을 도입 할 예정입니다. 자동차 안에 단말기를 설치하고, 그 단말기를 통해 통행 정보를 수집합니다. 통행정보에는 개인 데이터, 은행계좌번호, 자동차 상세내역이 포함됩니다. 단말기의 센서에 의해 계좌에서 자동으로 도로 요금이 지불됩니다. 허가된 자동차는 통과 시 부스에 녹색등이 켜지고, 지불 총액이 표시됩니다. 비 허가된 자동차가 통과 시 노란등이 켜지고 감시 카메라가 작동합니다.
Identify concerns 보안 반응 시간 다중 사용자 시스템 호환성 법적 이슈 정확성 가용성
Specify concerns Concern : 호환성 External Req. 사용자는 요금 지불 시 단말기를 켜야 한다. 경찰은 단말기가 없는 사용자를 관리한다.
Concern : 반응 시간 External Req. 톨게이트는 다음과 같은 과정을 거친다. 단말기 번호를 식별한다. 사용자가 지나기 전에 등을 켠다. 사용자가 지나기 전에 금액을 표시한다. 허가된 사용자가 아니면 사진을 찍는다. 시스템은 다음이 충족해야 작동한다. 사용자가 단말기를 켠다.
Discover requirements and relate to concern Viewpoint : 자동 지불 Concerns : 보안, 호환성, 반응시간 Requirements: 사용자의 카드번호, 계좌번호, 단말기 번호를 시스템으로 보낸다. 단말기 식별번호와 함께 시스템에 계좌번호를 보낸다. 새로운 정보를 수정하기 위해 새로운 계좌번호와 카드번호, 단말기 번호를 시스템에 보낸다.
Concerns : 반응시간, 정확성, 법적 이슈 Requirements : Viewpoint : 출구 Concerns : 반응시간, 정확성, 법적 이슈 Requirements : 운전자가 입구를 통과하지 않은 자면, 노란 불을 켠다. 요금은 입구의 위치에 따라 결정된다.
Identify candidate aspect 자동지불 : 보안, 호환성, 반응시간 출구 : 반응시간, 정확성, 법적 이슈 Candidate Aspect : 반응시간
Specify and prioritize aspects 보안 법적 이슈 <
Specify aspect dimensions Candidate Aspects Influence Mapping 호환성 Specification, Architecture, Design Evolution Function 반응시간 Architecture, Design Aspect 법적이슈 Specification Function 보안 Architecture, Design Aspect 가용성 Architecture Function 다중 사용자 Architecture, Design Aspect
III. UML Design
Using UML for OOM
Collaboration Diagram for OOM
Class Diagram for OOM
Using UML for AOM
Class Diagram for AOM
Collaboration Diagram with an Interceptor
Aspect Modeling using Collaboration Stereotype
장난해?
IV. Implementation
Coding AOP Joinpoint 계좌이체 Pointcut Advice 이체 로깅 Joinpoint Joinpoint
AspectJ의 포인트 컷 명칭 사용 예 발생 시점 excution Excution(void Point.setX(int) 메소드가 실행될 때 call Call(void Point.setX(int) 메소드가 호출될 때 handler Handler(ArrayOutOfBound Exception) 예외처리 발생시 this This(SomeType) 객체가 수행중일 때 target Target(SomeType) 대상객체가 SomeType일때 within Within(MyClass) 코드가 MyClass에 속할 때 cflow Cflow(call(void Test.main()) Joinpoint가 Test.main 안에 있을때
Coding AOP public class AccountTransfer extends AbstractAccountModule { public void transafer(Accouno fromAcc, Account toAcc, int amount) { if (fromAcc.hasEnoughMoney(amount) == false) { throw new AccountException(“not enough money”); } fromAcc.withdraw(amount); toAcc.credit(amount); } … }
그렇다면, 유지보수 시에도 한 개의 Aspect만 수정하면, 간단하네요 public aspect MethodLoggingAspect { Logger logger = MyLog.getLogger(“methodcall”); } pointcut methodcall() : execution(* *.*(..)) && !within(MethodLoggingAspect) pointcut methodcall() : execution (void AccountTransfer.transfer(..)) && !within(MethodLoggingAspect); before() : methodcall() { logger.begin(thisJoinPointStaticPart.getSignature().getName()); } after() : methodcall() { logger.end(thisJoinPointStaticPart.getSignature().getName()); }
AOP Tools
V. Quality Management
AOP 를 사용하면.. 각 모듈의 기능이 명확해진다. 일관적인 구현이 가능해진다. 재사용성의 향상 개발 대상의 기술이전이 쉽다.
AOP 로 개발할 때.. 개발정책을 확립하라. Logging을 강화하여 품질보증에 힘쓰라. Mock 객체를 이용하여 테스트 하라. What-if 분석에 충실 하라.
VI. Prospective AOP
해결해야 할 과제 표준의 부재 학습의 어려움 OOP와의 충돌 도입 전략의 부재
소프트웨어 Crisis 해결의 Solution Be the Solution 재사용성 개발 생산성의 향상 OOP의 장점을 극대화 “AOP가 없었을 때는 어떻게 개발을 했는지 모르겠다.” 소프트웨어 Crisis 해결의 Solution