Software engineering #5' software architecture

12
2012 년년 N4tech ¼ 년년 년년년 이이이 2012.02.03( 이 )

description

Software engineering

Transcript of Software engineering #5' software architecture

Page 1: Software engineering #5' software architecture

2012 년도 N4tech ¼ 분기 세미나

이오준2012.02.03( 금 )

Page 2: Software engineering #5' software architecture

Schedule 소프트웨어 공학

1st weak - chapter 01. 소개

2nd weak - chapter 02. 프로세스

3rd weak - chapter 03. 계획

4th weak - chapter 04. 요구 분석

5th weak - chapter 05. 설계원리와 아키텍처

6th weak - chapter 06. 객체지향 설계

7th weak - chapter 07. 상세 설계와 UI 설계

8th weak - chapter 08. 코딩

9th weak - chapter 09. 테스팅

10th weak - chapter 10. 유지 보수

11th weak - chapter 11. 품질

12th weak - chapter 12. 첨단 소프트웨어 공학 기술

Page 3: Software engineering #5' software architecture

소프트웨어 아키텍처

소프트웨어 시스템을 구성하는 서브시스템과 컴포넌트 그리고 그것들의 관계

Page 4: Software engineering #5' software architecture

패턴

특정 설계 정황 (design context) 에서 반복해서 발생하는 설계 문제에 대해 그

해법에 대한 검증된 일반 스키마 . 해법 스키마는 그 해법을 구성하는 컴포넌트들 ,

컴포넌트들의 책임과 관계 , 컴포넌트들 간의 협력 방법을 서술하는 기준이 된다 .

계획 , 도식

Page 5: Software engineering #5' software architecture

패턴의 구성

정황 – 문제를 발생시키는 주어진 상황

문제 – 해당 정황에서 반복적으로 발생하는 문제

해법 – 해당 문제에 대한 검증된 해답

Page 6: Software engineering #5' software architecture

대부분의 사람들은 턱이 낮은 커다란 통 유리창으로 삼면이 둘러싸인 밝은 공간에 앉아

쉬는 것을 좋아 한다 . 대게 이런 곳은 사람들에게 편안함과 휴식을 제공할 수 있다 .

만약 방에 창이 없다면 , 그 방에 있는 사람은 두 가지 영향력 사이에서 고민하게 된다 .

1. 그대로 앉아서 편히 쉰다 .

2. 환한 빛이 있는 곳으로 나간다 .

편하게 앉아 쉴 수 있는 공간에 창이 없다면 , 사람들은 이런 갈등을 쉽게 떨치지 못할

것이다 .

그러므로 , 하루 종일 유유자적 오랜 시간을 보낼 방에는 적어도 하나 이상의 통유리가

배치된 유리 거실을 두어야 한다 .

정황

문제

해법

Page 7: Software engineering #5' software architecture

MVC - 정황

사용자 인터페이스는 상황에 따라 변경되기 쉽다 . 예를 들어 에플리캐이션의

기능을 확장할 때 , 메뉴는 새기능에 액세스할 수 있어야 하며 , 사용자

인터페이스는 고객의 환경에 따라 바뀌어야 한다 . 또한 각기 다른 ‘외양 및

분위기’를 표준으로 하는 플랫폼들로 시스템이 옮겨져야 하는 경우도 있다 .

심지어 윈도우 시스템을 새 버전으로 업그레이드할 경우에도 코드를 고쳐야 할 지

모른다 . 수명이 긴 시스템의 사용자 인터페이스는 말 그대로 움직이는 과녁이다 .

Page 8: Software engineering #5' software architecture

MVC - 문제

유연성을 갖춘 시스템을 구축하려면 비용이 많이 들고 오류가 발생하기 쉽다 . 사용자

인터페이스가 핵심 기능과 밀접히 얽혀 있으면 더욱 그렇다 . 결국 각기 다른 소프트웨어

시스템들 마다 각각 사용자 인터페이스를 구현하고 유지 보수해야 한다는 의미이다 . 게다

가 , 업데이트를 위해 변경을 시도할 경우 많은 모듈을 배포해야 한다 . 요약하면 , 상호작용

소프트웨어 시스템을 개발할 때에는 다음 두 가지 측면을 고려해야 한다 .

- 사용자 인터페이스에 대한 변경은 쉬워야 하며 , 런타임에도 변경이 가능해야 한다 .

- 사용자 인터페이스를 새로운 환경에 적응시키고 이식 할 때 , 애플리케이션 핵심 기능을

담당하는 코드에 영향을 미쳐서는 안 된다 .

Page 9: Software engineering #5' software architecture

MVC - 해법

이 문제를 해결하기 위해서는 상호작용 애플리케이션을 프로세스 , 출력 , 입력 이렇게 세

영역으로 나누어야 한다 .

- 모델 컴포넌트가 핵심 데이터와 기능을 캡슐화한다 . 모델은 특정 입력 동작이나 출력

방식으로 부터 독립적이어야 한다 .

- 뷰 컴포넌트가 사용자에게 정보를 출력한다 . 뷰는 모델로부터 정보를 얻는다 . 하나의

모델에 여러 뷰가 존재할 수 있다 .

- 각 뷰에는 그에 상응하는 컨트롤러 컴포넌트가 존재한다 . 컨트롤러는 입력을 감지하는

이벤트를 통해 입력을 받는다 . 이벤트는 서비스 요청으로 해석되어 모델이나 뷰로 전달된

다 . 사용자는 오직 컨트롤러를 통해서만 시스템과 상호작용 한다 .

Page 10: Software engineering #5' software architecture

패턴의 효용

- 특정 설계 상황에서 발생하는 설계 문제를 제기하며 문제에 대한 해법을 제시한다 .

- 기존에 이미 입증된 설계 경험을 정리한 것이다 .

- 설계에 대한 공통 어휘와 공감대를 제공한다 .

Page 11: Software engineering #5' software architecture

패턴의 종류

아키텍처 패턴 – 소프트웨어 시스템의 기본 구조 구성을 다룬다 .

디자인 패턴 – 서브 시스템과 컴포넌트들 그리고 그들의 관계의 정의를 다룬다 .

이디엄 – 특정 언어의 기능을 사용해 컴포넌트들과 그 관계들을 구현하는 것을 다룬다 .

Page 12: Software engineering #5' software architecture

감사합니다 .

질문 & 답변