이번에는 아키텍쳐라는 것을 배워보자.
아키텍쳐는 (architecture) 해석하면 알 수 있듯이 무슨 구조인가??
즉, 뼈대 같은 것들을 말할 것 같다??
배워보자
우리는 앞서 요구 분석 작업을 했다.
그 요구 분석 작업을 통하여 무엇을 개발할 지 결정했고
그 이후에 도메인 영역의 문제에 집중해서 모델링 했다.
설계 단계로 넘어가면서 솔루션 영역의 과제들
예를 들어 소프트웨어의 내부 구조, 자료와 사용자 인터페이스를 어떻게 만들 것인지 정해야 한다.
다시 말해서 요구 분석 명세서에 기술된 기능을 여러가지 제한 요건에 맞도록 설계하는 일이 필요하다
건축 설계를 예로 들었지만 소프트웨어 설계도 마찬가지다.
** 설계는 일반적으로 창조작인 작업이라고 할 수 있다
++ 그렇다고 체계적인 접근이 없는 것은 아니다.
창의적인 방법은 기존의 것을 쓰지 않는 것을 의미하는 것은 아니다.
그래서 우리는 이 체계적인 접근을 배우고 있고 특히 소프트웨어에서 필요한 것들을 배우고 있다.
소프트웨어를 설계하기 위한 세부적인 작업(체계적인 접근)을 알아보자.
1. 소프트웨어 아키텍처 설계
전체 시스템을 이루는 서브시스템, 또는 모듈이 무엇이며 서브시스템 사이의 관계를 파악하는 것
2. 인터페이스 설계
서브시스템 사이의 인터페이스를 설계하고 정의하는 것
3. 자료 저장소 설계
파일이나 데이터베이스를 설계하는 것
4. 모듈 설계
시스템의 컴포넌트가 되는 모듈, 즉 프로그램의 알고리즘에 대한 설계
5. 사용자 인터페이스 설계
메뉴나 입력 양식, 출력 화면 및 인쇄물을 설계하는 작업
위 접근을 한 마디로 말하자면 분석 단계에서 파악한 요구를 구현 가능하게 만드는 설계안을 만드는 작업이랄까?
** 개념적이고 추상적인 것을 구체적이고 실제적으로 바꾸는 작업이다.
그렇다면 소프트웨어 아키텍쳐는 뭐고 아키텍쳐 설계는 뭔가?
용어를 정의해보자
소프트웨어 아키텍쳐란 주요 컴포넌트 사이의 인터페이스와 인터랙션을 포함한
시스템 구조의 설계 유형을 말한다.
그렇다면 아키텍쳐 설계는 뭐가 될까?
아키텍쳐 설계는 개발 중인 시스템에 대한 아키텍쳐를 정하는 의사 결정 과정이란다.
**그렇다 소프트웨어 아키텍쳐란 의사 결정의 집합체라고 볼 수 있다.
컴포넌트란 명백한 역할을 가지고 있으며 독립적으로 존재할 수 있는 시스템의 부분이다.
( 같은 기능을 가진 다른 컴포넌트로 대체 가능)
**대부분의 컴포넌트들은 재사용 가능하도록 설계된다.
++ 특정 목적을 위한 것들도 존재한다
모듈이란 프로그래밍 언어의 문법 구조에서 정의된 컴포넌트를 말한다.
예를 들자면 메소드, 클래스, 패키지는 Java프로그램의 모듈이다.
C프로그래밍 언어에서의 모듈의 파일과 함수이다.
그렇다면 이번에는 왜? 를 따져보자
왜 우리는 아키텍쳐를 설계해야할까?
우선 앞에서 체계적인 접근을 위해서라고 말했다.
두 번째는??
예를 들자면
어플리케이션 코드(C1,C2,C3,C4)가 써드파티 컴포넌트( 데이터 베이스)에 너무 의존하게 되고
만일 데이터베이스가 바뀐다면 어플리케이션 코드의 대부분을 수정해야 한다.
이런 위험을 피하려면 어플리케이션 객체로부터 데이터베이스를 숨기기 위하여
데이터베이스 래퍼(wrapper)를 개발해야 한다.
이렇게 하면 데이터베이스가 갱신되거나 교체되었을 때 비즈니스 객체에 대하여 보호할 수 있다.
데이터 베이스가 바뀐다면 비즈니스 객체를 그대로 두고 래퍼만 수정하면 된다.
근데 아키텍쳐 설계를 제대로 안하면???
데이터베이스가 바뀐다면???
오류는 나중에 발견할수록 미치고 팔짝 뛴다고 했었는데...
소프트웨어 완료 직전에 데이터베이스에 수정이 생긴다면???
말 안해도 알겠지?
그래서 아키텍쳐 설계를 한다.
그럼 이유도 알았겠다. 아키텍쳐에 더 알아보자
우리는 요구 분석에서 "비기능적 요구"에 대해 알아본 적이 있다.
비기능적 요구는 유스케이스에서 나오지도 않고
어플리케이션이 무엇을 하느냐가 아니라 어플리케이션이 어떻게 기능을 제공하느냐에 초점이 맞춰져있다.
비기능적 요구는 3가지 영역으로 나눌 수 있다.
1. 기술적 제약
ex) Java 언어로 개발해라, Linux에서만 실행가능하다. 등
2. 비즈니스 제약
말 그대로 경영측면에 대한 조건으로
"미들웨어 공급자가 가격을 올려 오픈소스 버전으로 바꿔야 한다" 같은 경우다.
3. 품질 제약
확장성, 가용성, 변경용이성, 이식성, 사용성, 성능 등에 대한 요구다.
++ 언제 많이 봤던 단어들 아닌가?? ㅋㅋㅋ 품질 측정할 때 저런 것 봤었다.
**아키텍쳐는 설계에 대한 여러 관점을 명시적으로 언급해야 한다.
**개발자는 기능적인 요구를 이해하고 동시에 기능들이 비기능적인 요구 다시 말해서 품질 목표를 만족하도록 플랫폼을 만들어야 한다.
++저기 품질 제약도 있다 살짝 참고하고
++ 왼쪽 그림도 어떤 흐름인지 살짝 보자.
?? 그렇다면 아키텍쳐는 어떻게 나타내고 표현해야할까??
완벽하게 만들어진 아키텍쳐는 시스템의 추상적인 요약이므로 매우 유용한데 이해하기 쉽도록 추상화 한 것이다.
**추상의 의미는 아무리 강조해도 계속나온다 다시 알아보자면 "불필요한 것 삭제, 가장 중요한 것만 남긴다"
그렇다면 아키텍쳐는 추상화 되었으니 정말 중요한 것만 남은 것으로 보이겠네요 ㅎㅎ
맞다.
아키텍쳐를 표현하는 방법 중 가장 많이 쓰이는 방법은 계층적 분할(hierarchical decompositions)라고 한다.
상세 수준에 따라 나누어 표현된 컴포넌트를 더 자세히 나타내기 위하여 분할하는 방법이다.
++ 브로커와 서버가 밑에서 더 나누어진 것이 보인다.
2개의 계층이 존재하고 2개의 컴포넌트가 분할되었다.
UML을 사용한 모델링에서 클래스 다이어그램이 어느 정도 작성되었으면
품질 목표에 맞는 아키텍쳐를 찾고 서브시스템으로 분할해야한다.
그런데 서브시스템 분할은 자꾸 바뀔 수 있다.
하나로 합쳐지기도 하고 다른 하나가 2개로 나눠지기도 하고 새로운 기능이 추가될 수 있다.
그래서 UML에서는 패키지라는 개념을 도입했는데
패키지는 클래스를 의미 있는 관련된 그룹으로 구성하는 메커니즘이다.
특징을 살펴보면
1. 패키지는 중첩될 수 있음
최상위층에는 구조적인 개체들 예를 들어 사용자 인터페이스, 비즈니스 도메인, 서브시스탬과 관련된 패키지가 형성되며 하위 층에는 더 작은 개념의 비즈니스 작업, 예를 들면 Video, Inventory 같은 것으로 표현한다.
2. 복잡한 시스템을 서브시스템으로 나누어 적절한 컨트롤 가능
패키지 이름을 정하여 알고 있으면 외부에서 패키지 안의 자세한 사항을 모르더라도 import할 수 있다.
ex) Java에서 버튼을 만들고 싶다?? Jbutton을 import하면 버튼에 관련된 것들은 다들어있다. ㅎㅎ
3. 소프트웨어 구조를 표현하는데 적합
패키지가 클래스의 그룹이므로 높은 수준의 추상화된 서브시스템을 표현할 수 있기 때문이다.
myGUI가 java.awt에 포함된 내용을 사용하고 있다는 의미다.
(패키지를 가리키면 클래스를 가리키는 것 보단 보기 쉬워지겠지?)
4. 서브시스템으로 분할하면 객체 사이의 의존성을 최소화할 수 있어 솔루션 도메인의 복잡성을 줄일 수 있음
Facade 패턴이 간결하고 통합된 인터페이스로 서브시스템을 캡슐화 하여 클래스 사이의 의존도를 줄일 수 있게 한다.
이 그림이 Clerk User Interface 패키지 안에 또 다른 패키지인 Business System Client가 있는 것이고
Business System Client 클래스는 Customer, Rental UI 클래스를 감추는 Facade 클래스이다.
다음에는 설계 원리부터 알아보자
'컴퓨터(Computer Science) > 소프트웨어공학(Software engineering)' 카테고리의 다른 글
프로젝트 계획(11) 아키텍쳐 설계 과정 [소프트웨어공학] (1) | 2020.05.01 |
---|---|
프로젝트 계획(10-1) 아키텍쳐 설계 원리 [소프트웨어공학] (0) | 2020.04.28 |
모델링 도구 starUML 기본 UI, 살짝 [소프트웨어공학] (0) | 2020.04.25 |
프로젝트 계획(9-4) - 모델링 도구 UML, starUML [소프트웨어공학] (0) | 2020.04.25 |
프로젝트 계획(9-3) - 동적 모델링 (dynamic modeling) [소프트웨어공학] (0) | 2020.04.25 |