설계 모델링

모델링의 개념

• 현재 업무를 파악하여 문제점을 인식하고 개선 사항을 도출하며 미래 모형의 설계를 도출하기 위한 모든 단계를 포함하는 활동
• 업무의 이해를 근간으로 데이터에 존재하는 업무 규칙과 이에 대한 명제를 명확하게 표현해 추상화하는 기법
• 현실 세계의 개체를 논리적 모델링과 물리적 모델링으로 업무를 설계하는 것

모델링의 원칙

커뮤니케이션 원칙

• 모든 사람들의 이해와 분명한 파악이 가능한 모델 제시
• 최종 사용자와 모든 이해관계자들을 최대한 고려
• [대상] 최종 사용자, 시스템 분석가, DB 관리자, 타전문가

모델링 상세화 원칙

• 조직 정부 구조의 최소 공토 분모 제시
• [분할] 복잡한 구조 및 프로세스는 요소 단위로 분할
• [제거] 불필요한 구조와 중복은 협의를 통해 제거

논리적 표현 원칙

• 조직의 비즈니스를 그대로 논리적으로 반영
• [분석] 경험에 의한 이른 판단보다 절차 준수
• [구체화] 단기간의 솔루션 구체화 시도는 지양

모델링의 단계

1. 요구사항 수집 및 분석
   사용자가 수행하는 업무의 개선 사항이나 신규 개발 시 시스템을 통해 주요 목적을 달성하기 위해 수집하고 분석하는 활동
   ex) 인터뷰, 사용자 분석, 회의 및 미팅

2. 개념 모델링
   업무 요건을 충족하기 위해 주제 영역과 핵심 데이터 집합, 핵심 데이터 집합 간의 관계를 정의하는 상위 수준의 개략적 데이터를 설계하는 작업
   ex) 주제 영역 정의, 후보 entity 선정, 핵심 entity 선정, 관계 정의

3. 논리 모델링
   업무의 모습을 모델링 표기법으로 형상화하여 사람이 이해하기 쉽게 표현하는 단계
   ex) 속성 정의, entity 상세화, 이력 관리 정의

4. 물리 모델링
   논리 데이터 모델을 특정 DBMS에 맞는 물리적인 스키마로 만드는 일련의 과정
   ex) 물리 환경 조사, 논리 모델 변환, 반정규화

모델링 시 고려 사항

• 커뮤니케이션 : 이해를 돕기 위한 비즈니스 지향적 모델과 기술적 상세 모델 두 가지를 관리해 의사소통이 용이하도록 고려
• 모델링 상세화 : 물리 모델 단계가 아닌 논리 모델 단계에서 선행하여 이후 작업이 구체화되고 상세화되도록 수행
• 논리적 표현 : 데이터 모델링 시 물리적인 제약 조건은 배제하고 논리적으로 사용자가 이해하도록 표현

소프트웨어 아키텍처

• 프로그램과 시스템 컴포넌트 간의 상호관계 구조이며, 이들을 설계하기 위한 지침과 원리를 나타냄
• 소프트웨어 컴포넌트들과 그들의 외부적으로 보여지는 특성, 그리고 그들의 상호 관계들로 구성되는 해당 시스템의 구조 또는 구조들을 총칭

비즈니스 측면)

• 변화 민첩성 : Agility(민첩성)을 통한 RTE 구현, 적시성
• 비용 절감 : 소프트웨어 재사용, 자산화를 통한 개발비 절감, TCO, ROI
• 표준화 : 재사용 가능한 산업별 표준화 지원

기술적 측면)

• 의사소통 수단 : 이해관계자들 간의 원활한 의사소통 수단
• 간략성 : 소프트웨어 복잡성 증가에 따른 해결 대안
• 관점(Aspect) 모형 : 이해관계자들 간의 관심사에 대한 모형 제시

Architecture Description(AD)

• 아키텍처를 기록하기 위한 산출물로, 하나의 AD는 시스템(System)에 대한 관심사를 나타내는 관심사(Concern)와 이에 대응하는 하나 이상의 이해관계자(Stakeholder)와 연관
• 하나의 AD는 시스템의 하나 이상의 View로 구성

이해관계자(Stakeholder)

• 소프트웨어 시스템 개발에 관련된 모든 사람과 조직을 의미
• 고객, 최종 사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등을 모두 포함

관심사(Concerns)

• 동일한 시스템에 대해 각 이해관계자들은 서로 다른 의견과 목표 수립
  ex) 사용자 입장 : 기본적인 기능 + 신뢰성/보안/사용성 요구
  유지보수자 입장 : 유지보수 용이 고려
  개발자 입장 : 적은 비용과 인력으로 개발

관점(Viewpoint)

• 이해관계자들이 보고 싶은 관점
• 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대한 다른 관점
• Viewpoint는 View를 구성하기 위한 규칙을 정의하는 패턴
• 각각의 View에 1:1로 대응함

View

• View는 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현

저장소(Repository) 구조

저장소 모델이라 하며, 대규모 데이터를 공유하는 소프트웨어 시스템에 사용
공유된 데이터베이스에 기반한 아키텍처로, 저장소를 통해 상호작용하는 아키텍처 스타일

MVC(Model/View/Controller) 구조

• 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 아키텍처 스타일
• 핵심 기능과 데이터 처리(Model), 사용자 측 정보 노출(View), 사용자 입력 관리(Controller) 3가지로 구성

클라이언트/서버 (Client/Server) 구조

클라이언트로부터의 요청으로 서버의 응답을 이용하여 Master-Slave로 상호작용하는 방식의 아키텍처 스타일

계층(Layered) 구조

계층적으로 조직화될 수 있는 서비스에 적합하며, 모듈의 응집된 집합을 계층으로 표현하고 계층 간 상호 사용이 가능한 관계로 정의된 아키텍처 스타일

Pipes and Filters(Data Flow) 구조

서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업구조의 아키텍처 스타일

소프트웨어 아키텍처 평가

분류	평가 모델	내용
시나리오 기반 평가 모델	SAAM	- Software Architecture Analysis Method
		- 수정 용이성과 기능 부석 중심의 최초의 아키텍처 평가 방법
		- 다양한 수정 가능성들의 관점에서 아키텍처를 분석
	ATAM	- Architecture Tradeoff Analysis Method
		- SAAM의 품질 속성에서 Trade off를 포함하여 평가 수행하는 평가 방법
	CBAM	- Cost Benefit Analysis Method
		- ATAM에서 부족한 경제적 평가 부분을 보강한 평가 방법
	EATAM	- Extending Architecture Tradeoff Analysis Method
		- 개별 평가 모델의 확장, 스테이지 기반 모델을 통한 PL 아키텍처 평가 수행 방법
설계/혼합 기반 평가 모델	ARID	- Architecture Review for Intermediate Design
		- 부분 아키텍처를 아키텍처 초기에 평가하는 방법
	ADR	- Active Design Review
		- 설계 기반 아키텍처 구성 요소 간 응집도를 중점으로 평가하는 방법

객체 지향

실세계의 개체를 속성과 메소드가 결합된 형태의 객체로 표현하는 방법
실세계의 문제 영역에 대한 표현을 소프트웨어 해결 영역으로 매핑하는 방법으로 객체 간에 메시지를 주고 받는 형태로 시스템이 구성
💫 결합도는 낮게, 응집도는 높게

객체 지향의 구성 요소

• 객체(Object) : 데이터(실체)와 그 데이터에 관련되는 동작(절차, 방법, 기능)을 모두 포함한 것
• 메시지(Message) : 객체들 간의 통신은 메시지를 통해 이루어지고, 메시지는 수신 받을 객체와 수행 메소드명, Argument로 구성됨
• 클래스(Class) : 동일 성격의 객체 그룹을 구현한 것으로 객체는 클래스의 한 인스턴스가 됨

객체 지향의 5대 상세 기법

캡슐화(Encapsulation)

• 속성과 메소드(함수)를 하나로 묶어서 객체로 구성하는 기법
• 하나로 묶은 객체는 재사용성을 높이고 오류율을 낮춤

추상화(Abstraction)

• 공통 성질을 추출하여 슈퍼 클래스를 설정하는 기법

다형성(Polymorphism)

• 동일한 이름의 오퍼레이션(메소드)이 각 클래스마다 다른 사양으로 정의될 수 있도록 하는 기법
• Overloading : 메소드의 이름은 같으나 Argument나 Return type이 다른 경우
• Overriding : Argument와 Return type이 같은 경우

정보 은닉(Information Hiding)

• 캡슐화된 항목들이 다른 객체(Object)에게 정보를 보이지 않게 하여 정보를 은닉하고 메시지 전달을 통해 다른 클래스 내의 메소드가 호출하게 하는 기법

상속(Ingeritance)

• 하위 클래스에게 자신의 속성과 메소드를 사용할 수 있도록 허용하여 재사용하는 기법

객체 지향 설계 원칙(SOLID)

단일 책임의 원칙(SRP ; Single Response Principle)

시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 설계 원칙

• 응집도 향상으로 유지보수성 향상
• 하나의 책임만을 수행하기 때문에 변화에 적응도 높음
• 두 개 이상의 책임을 가지면 온전한 책임을 다할 수 있도록 분리

개방 폐쇄 원칙(ORP ; Open Closed Principle)

소프트웨어 Entity(Class, Modules, Function)는 확장에는 열려있고, 수정에는 닫혀 있어야 한다는 설계 원칙

• 기존 코드의 변경 없이 확장을 통한 코드의 변경을 허용
• 기능의 상속이 아닌 설계의 유연성을 강조
• Overriding : 상속을 의미하지만, 크게 유연성 확보 차원의 원리

리스코프 교체의 원칙(LSP ; Liskov Substitution Principle)

자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 한다는 설계 원칙

• 클래스의 생성 목적에 맞게 설계하기 때문에 상/하위 클래스의 호환성 향상
• 하위 클래스는 상위 클래스의 책임을 넘지 않음
• 하위 클래스는 사용자의 요구 사항대로 설계됨

인터페이스 분리의 원칙(ISP ; Interface Segregation Principle)

어떤 클래스가 다른 클래스에 종속될 때는 최소한의 인터페이스만을 사용해야 한다는 설계 원칙
클라이언트는 자신이 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다는 원칙

• 인터페이스의 단일 책임을 강조
• 하나의 인터페이스에 해당 인터페이스의 목적에 부합되지 않는 기능을 선언하지 않기 때문에 구현 클래스에서 불필요한 기능의 구현을 방지
• 소스 레벨의 가독성 향상

의존관계 역전의 원칙(DIP ; Dependency Inversion Principle)

높은 레벨의 모듈은 낮은 레벨의 모듈을 의존하지 않고 서로 추상에 의존해야 한다는 설계 원칙
클라이언트 변경 최소화를 위해 클라이언트는 구체 클래스가 아닌 인터페이스나 추상 클래스에 의존한다는 설계 원칙

• 구현 클래스에 의존성을 제거하여 낮은 결함도 유지
• 추상화된 클래스에 의존하기 때문에 확장성이 높아져서 유지보수성 향상

디자인 패턴

• 소프트웨어 설계 시 발생하는 여러 가지 문제에 대한 사례를 분석하여 각 문제 유형별로 가장 적합한 설계를 모아 표준적인 해법과 작명법을 기술
• 프로그래밍 시 반복적으로 나타나는 설계 문제에 대한 경험 기반의 해결책 목록
• 객체 지향 설계 원칙에 입각하여 SW를 설계하기 위한 가장 효과적인 참고 자료

목적) 전문가들의 설계 노하우를 다른 개발자가 이해하고 적용할 수 있는 형태로 제공
생산성, 확장성, 재사용성, 구조 파악 용이성, 유지보수성이 좋은 소프트웨어를 설계/구현하기 용이

특징)
Interface : 구현(Implementation) 클래스가 아니라 인터페이스를 활용
Delegation : 상속(Ingeritance)과 위임(Delegation)을 사용
Loosely Coupling : 연관되는 정보를 최소화하여 낮은 결합도 추구

디자인 패턴의 분류

• 생성 패턴(Creational) : 객체의 생성 방식을 결정하고 클래스의 정의, 객체 생성 방식을 구조화, 캡슐화하는 패턴
• 구조 패턴(Structural) : 객체를 구조화하고 조직화하여 클래스 라이브러리 등으로 통합 시 유용한 패턴
• 행위 패턴(Behavioral) : 객체의 행위를 조직화, 관리, 연합하고 객체나 클래스 연동에 대한 유형을 제시하는 패턴

생성 패턴 "추상적인 공장을 프로토로 하나만 짓자" or "추공프싱빌"

• Abstract Factory : 관련성을 갖는 객체들 또는 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공하는 생성 패턴
• Factory Method : 인스턴스 생성과 관련된 결정을 서브클래스가 하도록 해서 객체 생성의 유연성을 극대화하는 생성 패턴, Virtual-Constructor(가상 생성자) 패턴이라고도 함
• Prototype : 인스턴스 객체의 내용을 그대로 복사하여 새로운 객체를 생성하는 방법을 제공하는 생성 패턴
• Singleton : 클래스의 인스턴스가 단 하나임을 보장하면서, 해당 인스턴스로의 접근 방법을 제공하는 패턴
• Builder : 복잡한 객체 생성 방법을 별도로 캡슐화하여, 구현 시 동일하나 과정으로 다양한 형태의 합성 객체를 얻을 수 있게 해주는 패턴

구조 패턴 "ABCD 파블록"

• Adapter : 호환성이 없는 객체 간 인터페이스를 이용해 작동하게 해주는 패턴
• Bridge : 추상부와 구현부를 분리해 결합도를 약화시키는 패턴
• Composite : 계층적 복합 객체를 트리 구조로 구성하고 각 요소들을 동일한 방식으로 사용할 수 있도록 해주는 구조 패턴
• Decorator : 객체의 재귀적 합성 구조를 통해 객체의 기능을 동적으로 확장하는 방법을 제공하는 구조 패턴
• Facade : 어떤 소프트웨어에서 복잡한 인터페이스의 집합에 대하여 단순화된 인터페이스를 제공하기 위한 구조 패턴
• Flyweight : 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 패턴
• Proxy : 접근 대상 객체와 동일한 인터페이스를 제공하는 대리인 객체를 이용해 목표 객체 접근 전에 추가적인 작업의 기회를 제공하는 패턴

행위 패턴

• Chain of Responsibility : 어떤 객체에서 서비스 요청이 전달되었을 때, 그 요청을 가장 잘 처리할 수 있는 객체까지 요청을 전파해서 처리할 수 있게 만들어주는 패턴
• Command : 행위를 목적으로 하는 객체로서 요청 자체를 객체화해 클라이언트에 파라미터로 넘겨 호출하는 객체와 수행하는 객체를 분리하는 패턴
• Iterator : "반복하다"라는 뜻으로 복합 객체의 내부 표현은 내부로 숨기고 순차적으로 순회하여 원하는 데이터를 찾아가도록 하는 패턴
• Mediator : 객체들 간의 상호작용을 분리하여 캡슐화함으로써 상호작용의 유연한 변경을 지원하는 패턴
• Memento : 캡슐화를 위배하지 않고 객체 내부 상태를 객체화하여 객체 상태의 저장 및 해당 상태로의 복구를 가능하게 해주는 패턴
• Observer : 객체에 등록된 옵저버를 통해 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고, 자동으로 내용이 갱신되는 일대다 방식의 패턴
• State : 객체의 상태가 변경될 때마다 별도의 행위를 지정해야 되는 객체를 정의 및 조직화하는 방법을 제공하는 패턴
• Strategy : 다양한 알고리즘을 각각의 클래스로 캡슐화하여 해당 클래스를 대체가 가능하도록 구성한 후, 알고리즘을 사용하는 클라이언트에 독립적으로 알고리즘 변경이 가능하도록 구성한 패턴
• Visitor : 데이터 구조와 기능 처리를 분리하는 패턴
• Interpreter : 간단한 언어의 문법을 정의하는 방법과 그 언어로 문장을 구성하는 방법, 문장을 해석하는 방법을 제시하는 패턴
• Template Method : 세부 처리는 서브클래스에서 개별적으로 정의하고, 공통적인 전체 처리 흐름은 상위 클래스에서 규정하는 패턴