CamelAct

Library/Framework./Platform

Library : 재사용이 필요한 기능들을 모듈화해서 언제든지 호출하여 사용가능하도록 한 것
Framework : 원하는 기능 구현에만 빠르게 집중하여 개발할 수 있도록 공통적으로 필요한 기능을 갖추고 있다. 프레임워크 안에 기능을 추가해야하고, 프레임워크가 정한 규칙, Life cycle에 의존하여 개발해야한다.
Platform : 프로그램이 실행되는 환경을 말함, 어플리케이션을 동작시킬 때 기반이 되는 OS와 그밖의 환경, 설정 등

Complexity

시간 복잡도 - 문제 해결하는데 걸리는 시간과 함수 관계
공간 복잡도 - 완료하는데 필요한 자원 공간의 양

Stakeholder의 의견이 조율이 되지 않을 때에는 어떻게 해야하나?

먼저 Stakeholder들간의 의견들을 토대로 후보모델들을 분석해야 한다. ATAM과 같은 방법을 통하여 각 stakeholder가 가지는 요구사항과 그에 따른 품질 속성, 후보모델들의 architecture를 분석한다.
그리고, 각 후보모델들에 대한 분석 결과를 기반으로, CBAM(Cost Benefit Analysis Method)와 같은 평가방법을 통해 architecture 중에 최적의 architecture를 선택한다.

Balanced mvc?

MVC Style 과 Client-Server Style을 통합한 것
Client 와 Server 각각에 MVC Style이 적용되어 있다

MVC와 MVVM의 차이를 설명해보세요

MVC는 상호 통신을 하지만 MVVM의 경우 단 방향으로 통신하며, 모든 응답은 event로 처리되거나 binding 한다
Comment) MVC에서는 View가 직접 Model을 참조할 수 있다는 차이점이 있다고 조언

본인의 설계가 타당한지 어떻게 확신하는가?

평가검증에서 QA Scenario 정의하고 scenario를 성공하기 위한 Architectural Approach를 제시

Product line 과 Application과 Domain 관점에서 차이

Product 들을 categorising 한 후 필요한 product들을 선택해서 최종 product 를 만들어 내는 것으로 재사용성을 극대화하며, 수많은 모델로 파생되는 것에 효율적으로 대응할 수 있게 된다.
전체 product들의 기능들을 use case별로 나열하고 해당 기능들을 category별로 정리를 한 후, product별 공통적인 기능, 특정 category의 Product가 필요로 하는 기능들로 분류한다.
그리고, 기능별 category, 공통 기능으로서의 category, family product들이 가지는 공통 기능등으로 나누어, category별 기능 component들을 정의하여 개발
실제 product 개발시 category별 기능들을 선택하여 조합하여 최종 product를 정의하여 개발
수많은 파생모델이 존재하는 경우, category별 개발된 component

SPL

#. SPL? (Software Product Line)
- 재사용 단위인 core asset을 이용하여, 공통 부분은 가져다 쓰고, 가변 부분은 개발하여 product을 만들어내는 방법
 
#. SPL 효과
- 생산성 향상
- 품질 향상
- 비용 감소
- 빠른 제품 출시

아키텍처 드라이버를 도출하는 단계를 설명하라

Architecture driver란 SW architecture가 가져야하는 Functional Requirement와 Non-functional Requirement이다.
목표를 설정 -> Use case들을 도출 -> Use case diagram에서 quality scenario 도출 -> quality attribute들을 도출 한 후, architecture를 결정하는데 있어 중요한 것들을 선택. 

Architecture Design / Architecture Style / Architecture Pattern / Design Pattern 의 차이점

Architecture Design: Architecture를 만들어(design해) 가는 과정 전체
Architecture Style: high level의 컴포넌트 간의 관계를 보여준다. 각 컴포넌트는 package 정도의 단위이다. 구조적인 표현에 초점, 품질속성과 관련 장단점 추리기
Architecture Pattern: 보다 세분화된 컴포넌트 간의 관계를 보여준다. Functional View(Component Diagram)가 그려진다. 문제와 연관된 솔루션 제시
Design Pattern: Class 단위의 세분화된 구조를 보여준다. Information View(대략적인 Class Diagram)와 Behavior View(Sequence Diagram, State Machine Diagram)가 그려진다.

COR과 decorator는 responsibility를 덧붙이는 구조로 유사한것 같은데 차이점은?

cor은 연결리스트와 같이 수평한 구조로 책임을 덧붙이며, decorator는 계층적으로 책임을 덧붙입니다. 

State Machine Diagram에서 병렬 수행을 나타내는 notation은 무엇인가?

Parallelization node & Synchronization node

State Machine Diagram에서 transition을 표시하는 3가지

Event (trigger), Guard (condition), Activity (Effect)

스테이트 다이어그램에서 orthogonal 스테이트가 무엇인지
Compatible and independent 하게 동시에 존재하는 2개 이상의 스테이트 

OOAD와 SW Architecture 차이가 무엇인가?

  : OOAD는 주어진 문제에 맞도록 클래스간의 구조와 동작들에 패턴을 적용하여, 클래스에 대한 패턴
  : SW Architecture는 전체 system을 목적에 맞는 architecture style을 적용하여 subsystem이나 component단위로 분리하고 component들간의 관계와 communication을 정의하는 것으로, 전체 System에서의 subsystem과 component들에 대한 패턴
  이러한 관점에서 보았을 때, SW공학은 비기능적인 요구사항을 고려하여 비기능적 요구사항을 만족시키기 위한 개발 과정에서 구조적인 변경 가능성을 최소화 해 줄 수 있다. 반면 OOAD는 넓은 범위에서 component별 구조를 고려하지 않기 때문에 추후 발생할 비기능적인 요구사항이나 NFR변경에 취약한 구조가 될 수 있다. 

알고리즘을 다양하게 쓸 수 있는 패턴들과 component level interface를 정의하는 게 어떤 차이가 있나?

=> Strategy pattern.
=> Provided interface <-> required interface
  : Strategy는 특정 behavior나 method의 알고리즘이나 동작 방식이 runtime에 바뀔 수 있는 경우 적용하는 패턴으로, context class가 strategy interface를 member로 가짐으로서 알고리즘을 변경할 수 있다.
  : Strategy pattern의 경우, 해당 클래스를 사용하는 client측에서 어떤 알고리즘을 쓸 것인가를 확인하고 명시적으로 알고리즘을 교체하지만, component level interface는 외부 component가 내부 component를 볼 수 없기 때문에 component level interface를 통해 제공되는 behavior가 변경되더라도 이를 알 수 없다. 

마이크로 커널을 클래스 레벨로 어떻게 구성할 것인가?

Microkernel architecture - system requirement가 빈번히 변경되는 경우, minimum functionality만을 제공하는 core system과 각 feature들을 분리하고, 특정 기능이 필요한 경우 해당 기능을 구현한 plugin을 사용하여 기능을 동작하는 architecture style.
  : Microkernel에서 core system은 정해진 순서에 따라 동작을 진행하고, 그 과정에서 plugin의 인터페이스를 순서대로 호출하도록 해야 한다. 그리고, plugin 개발자는 core system에서 요구하는 plugin에서 제공해야하는 interface들을 구현하는 형태로 plugin을 개발하여 제공하면 된다. 따라서, 이러한 형태에 가장 적합한 Template method pattern을 적용하여, core system에서 필요로 하는 인터페이스를 abstract class로 정의하여 두고, plugin개발자는 concrete class로 plugin을 개발하여 제공함으로써 기능을 동작하도록 할 수 있다.

ADD (Attribute Driven Design) 방법론

기능 요구사항, 품질 요구사항을 아키텍처에 반영하는 아키텍처 설계 방법이다.
분해할 모듈을 선택 > 선택한 모듈을 분해하고 정제(동인 결정, 스타일 선택, 기능 할당, 하위 인터페이스 정의, 하위 제약사항 변경) > 계속 반복

Architecture viewpoint 중 Logical View에서는 use case를 묶어서 component에 할당하게 되는데, 어떤 use case들이 한 component로 할당되도록 하는 판단 기준이 있나?

cohesion은 높고 coupling은 낮도록 component 나누거나 합치기 

Abstract Class를 상속하는 것 보다 Interface를 구현하도록 하는 것이 갖는 장점은?

Abstract Class : is a 관계가 명확하고 일부 구현이 필요한 경우
Interface : 역할 구분을 명확하게 하고 다중 상속, 일부 구현이 필요 없는 경우

Repository Style과 Black board style의 공통점과 차이점을 설명하고, 저장되는 내용의 차이도 설명하라

Data centric architecture로 Data를 어떻게 다루는지에 따라 구성된 Architecture라는 점에서 공통점이 있다.
Repository style은 data storage가 passive한 역할을 수행하며, system의 subsystem 또는 component들이 data를 읽거나 쓰고자 할 때 storage에 정보를 저장하거나 읽어준다.
Blackboard style은 data storage가 active한 역할을 수행하며, data storage의 state에 따라 event가 trigger되어 subsystem이나 component에 해당하는 Knowledge source가 연산이나 동작을 수행한다. Blackboard style은 control이 있다.

SW 개발 vs 모델링

- SW 개발 = 모델링 + 구현 + 테스트
- 모델링 = 요구사항 정의 + 분석 + 설계