소프트웨어 설계

소프트웨어 설계

 

 

 

GoF(Gangs of Four) 디자인 패턴

 

디자인 패턴이란?

디자인 패턴은 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 해결하기 위해 사용되는 패턴입니다.
5개의 생성 패턴, 7개의 구조 패턴, 11개의 행위 패턴 합쳐서 총 23개의 패턴으로 구성되어있습니다.

 

 

생성 패턴

기존 코드의 유연성과 재사용을 증가시키는 객체를 생성하는 다양한 방법을 제공합니다.

생성 패턴	요약 설명
팩토리 메서드(Factory Method)	객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴
추상 팩토리(Abstract Factory)	구체적인 클래스에 의존하지 않고 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
빌더(Builder)	복잡한 객체들을 단계별로 생성할 수 있도록 하는 패턴
프로토타입(Prototype)	클래스들에 의존시키지 않고 기존 객체들을 복사할 수 있도록 하는 패턴
싱글턴(Singleton)	클래스의 인스턴스가 하나만 존재하도록 보장하는 패턴

 

 

구조 패턴

구조를 유연하고 효율적으로 유지하면서 객체와 클래스를 더 큰 구조로 조합하는 방법을 설명합니다.

구조 패턴	요약 설명
어댑터(Adapter)	호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 하는 패턴
브릿지(Bridge)	클래스 또는 밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조(추상화 및 구현)로 나눈 후 각각 독립적으로 개발할 수 있도록 하는 패턴
복합체(Composite)	객체들을 트리 구조로 구성한 후, 복합객체와 단일객체를 구분 없이 다루는 패턴
데코레이터(Decorator)	객체들을 새로운 행동들을 포함한 특수 래퍼 객체들 내에 넣어서 위 행동들을 해당 객체들에 연결시키는 패턴
파사드(Facade)	서브 시스템 집합에 대해 하나의 통합된 인터페이스를 제공하는 패턴
플라이웨이트(Flyweight)	각 객체에 데이터를 유지하는 대신 여러 객체들의 상태의 공통 부분을 공유하여 RAM에 더 많은 객체를 포함하게 하는 패턴
프록시(Proxy)	원본 객체를 대신하여 처리하게 함으로써 흐름을 제어하는 패턴

 

 

행동 패턴

객체 간의 효과적인 의사소통과 책임 할당을 처리합니다.

행동 패턴	요약 설명
책임 연쇄(Chain of Responsibility)	핸들러의 체인을 따라 요청을 전달하는 패턴. 각 핸들러는 요청을 받으면 처리할 것인지 다음 체인의 핸들러로 전달할지를 결정합니다.
커맨드(Command)	요청을 객체 형태로 캡슐화하는 패턴
인터프리터(Interpreter)	특정 언어를 구현하는 패턴
반복자(Iterator)	객체의 기본 표현을 노출하지 않고 원소를 순서대로 순회할 수 있게하는 패턴
중재자(Mediator)	객체 간의 혼란스러운 의존 관계들을 줄일 수 있는 패턴. 객체 간의 직접 통신을 제한하고 중재자 객체를 통해서만 통신하게 합니다.
메멘토(Memento)	객체의 구현 세부 사항을 공개하지 않으면서 해당 객체의 이전 상태를 저장하고 복원할 수 있게 해주는 패턴.
옵저버(Observer)	객체에 상태 변화를 관찰하고, 상태 변화에 따라 관찰하고 있는 객체들이 이를 알 수 있게 만드는 구독 매커니즘의 패턴
상태(State)	객체의 내부 상태가 변경될 때 해당 객체가 그의 행동을 변경할 수 있도록 하는 패턴
전략(Strategy)	알고리즘들의 패밀리를 정의하고, 캡슐화 하여 객체를 상호 교환할 수 있게하는 패턴
템플릿 메서드(Template Method)	상위 클래스에서 알고리즘의 골격을 정의하고 구체적인 처리는 서브클래스에 위임해서 처리하는 패턴
비지터(Visitor)	알고리즘들이 작동하는 객체들로부터 분리할 수 있도록 하는 패턴

 

 

디자인 패턴 장단점

 

장점

• 개발자 간의 원활한 의사소통을 지원
• 소프트웨어 구조 파악이 쉽다
• 재사용을 통한 개발 시간을 단축할 수 있다
• 설계 변경 요청에 대해 유연히 대처할 수 있다
• 객체지향 설계 및 구현의 생산성을 높이는데 적합

 

단점

• 객체지향 설계/구현 위주로 사용
• 초기 투자 비용 부담

 

 

 

 

 

 

소프트웨어 개발방법론

 

폭포수 방법론 (waterfall methodology)

- 소프트웨어 개발 방법론 중 하나로 개발 생명 주기를 폭포수가 내려오는 것처럼 순차적으로 ‘일련의 단계’로 나누어 개발하는 방법을 의미합니다.

 

- 해당 방법론을 통해 각 단계는 이전 단계의 결과물을 입력으로 받아 다음 단계의 결과물을 출력하는 구조를 가지고 있습니다.(방법론의 원칙적으로 완료된 단계(이전 단계)로 돌아갈 수는 없습니다)

 

- 계획 및 분석(Discover) - 설계(Design) - 개발(Develop) - 테스트 - 운영/유지보수 단계를 가집니다.

 

애자일 방법론(Agile methodology)

- 소프트웨어 개발 방법론 중 하나로 ‘반복적이고 점진적인 개발 방법’을 통해 개발을 진행하는 것을 특징으로 합니다.

- 개발 초기부터 고객의 요구 사항을 반영하여 빠르게 개발하고 그 과정에서 지속적으로 피드백을 받아 개발을 진행합니다.

- 각각의 단계는 계획 및 분석(Discover) - 설계(Design) - 개발(Develop) - 테스트단계를 '작은 단위의 사이클로 분리'하고 사이클이 종료가 되면 다음 사이클로 반복적으로 진행합니다.

- 애자일 방법론의 종류는 대표적으로 칸반(Kanban), 스크럼(Scrum), 익스트림 프로그래밍 (Extreme Programming, XP)이 존재합니다

• 날렵한 재뻐른 이란 사전적 의미
• 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점을 두고 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용
• 절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각

 

 

애자일 방법론 종류

 

• 익스트림 프로그램밍(xp, extreme programming)
• 스크럼 (scrum)
• 린(lean)
• DSDM (Dynamic system development Method) 기능 중심 개발
• Crystal
• ASD (Adaptive Software Development) 적응형 소프트웨어 개발 방법론
• DAD (Disciplined Agile Delivery) 학습 애자일 배포

 

 

 

애자일 선언문

 

공정과 도구보다 개인과 상호작용을

포괄적인 문서보다 작동하는 소프트웨어를

계약 협상보다 고객과의 협력을

계획을 따르기보다 변화에 대응하기를

 

 

애자일 12가지 원칙

1. 고객만족
2. 변화 수용
3. 짧은 주기 소프트웨어 제공
4. 협업 강화
5. 동기 부여
6. 대면 대화
7. 소프트웨어 진척도
8. 지속 가능한 개발
9. 기술적 탁월성
10. 간결함
11. 자율적인 팀
12. 정기적 반성

 

 

XP(eXtreme Programming) 12 실천사항

 

• Pair programming
• Planning game
• Test driven development
• Whole team
• Continuous integration
• Design improvement
• Small releases
• Coding standards
• Collective code ownership
• Simple design
• System metaphor
• Sustainable pace

 

XP(eXtreme Programming ) 특징

• 1999년 Kent beck이 제안하였으며 개발 단계 중 요구사항이 시시 각각 변동이 심한 경우 적합한 방법론
• 요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것을 목표로한다.
• 요구사항을 모두 정의해 놓고 작업을 진해하는 것이 아니라 요구사항이 변경되는 것을 적용하는 방식으로 예측성보다는 적응성에 더 높은 가치를 부여한 방법
• 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상시키는 방법

 

 

 

 

 

 

 

 

 

폭포수 방법론 , 애자일 방법론 차이점

분류	폭포수 방법론(Waterfall Methodology)	애자일 방법론(Agile Methodology)
개요	계획 중심, 선형적인 개발 방법	반복적이고 점진적인 개발 방법
프로세스	단계별로 엄격하게 분리된 개발 단계	반복적인 개발 단계
요구사항	초기에 명확하게 정의하고 변경 어려움	유연하게 대처 가능
테스트	개발 완료 후 테스트	개발 초기부터 테스트
방향성	예측 가능한 방향성	변경 가능한 방향성
비용	변경 및 오류 수정 비용이 높음	초기 비용이 낮으나 유지보수 비용 높음
적용 분야	큰 규모의 프로젝트	중간, 작은 규모의 프로젝트
장점	명확한 계획과 예측 가능성, 문서화 용이성	요구사항 변경 대처 용이, 고객 요구사항 반영
단점	변경 어려움, 유연성 부족, 반응성 떨어짐	계획 변경 어려움, 초기 비용 낮지 않음

 

 

린 방법론(lean Methodology)

- 소프트웨어 개발 방법론 중 하나로 이전 제조 산업에서 비롯된 개발 방법론으로 ‘낭비를 최소화하고 가치를 최대화하는 것’을 목적으로 합니다.

 

- 린 방법론은 제품을 개발하는 전 과정에서 고객의 피드백을 수시로 반영하며, 불필요한 작업을 최소화하여 생산성을 높이는 것을 목표로 합니다.

- 린은 제조 산업에서 사용하는 방법을 소프트웨어 개발방법론과 결합하여 사용합니다. 린 방법론의 종류는 린 소프트웨어 개발 (LSD), 린 UX, 린 스타트업, 린 애자일, 린 시스템스 엔지니어링이 있습니다

 

 

CASE(Computer-Aided Software Engineering)

 

CASE의 분류

• 상위(upper) : 요구 분석 및 설계 단계 지원 (모델 간 모순검사, 모델 오류검증, 자료 흐름도 작성)
• 하위(lower) : 소스 코드 작성, 테스트,문서화 과정 지원
• 통합(integrate) : 소프트웨어 개발 주기 전체 과정 지원

 

원천 기술 

1. 구조적 기법
2. 프로토타이핑 기술
3. 정보 저장소 기술

 

제공하는 기능

• 개발을 신속하게 할 수 있고 오류 수정이 쉬워 s/w 품질이 향상
• 소프트웨어 생명주기의 전체 단계를 연결해 주고 자동화시켜 주는 통합된 도구를 제공해 주는 기술
• 소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능을 제공
• S/w 개발 단계의 표준화를 기할 수 있으면 자료 흐름도 작성 기능을 제공
• 모델들 사이의 모순 검사 기능을 제공하며 다양한 소프트웨어 개발 모형을 지원

 

 

 

 

럼바우(Rumbaugh) 객체지향 분석 기법

 

- 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 객체지향 분석(Object-oriented Analysis) 기법

• 객체 모델링(Object Modeling): 정보 모델링이라고도 한다 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체를 다이어그램으로 표시한ㄴ다
• 동적 모델링(Dynamic Modeling): 제어흐름, 상호작용, 동작순서등의 상태를 시간 흐름에 따라 상태 다이어그램으로 표시한다.
• 기능 모델링(Functional Modeling):  자료흐름도(DFD)를 이용하여 여러 프로세스 간의 자료 흐름을 표시한다. 어떤 데이터를 입력하여 어떤 결과를 가져올 수 있을지를 표현한다.

 

- 럼바우 객체지향 분석 기법의 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행된다.

 

 

UML 모델링

 

UML 모델링 특징

먼저 UML은 객체지향 설계를 위한 표준 언어로, 소프트웨어 시스템의 산출물을 가시화, 명세화, 구축, 문서화 하는데 사용됩니다.

• 가시화 : 소프트웨어의 개념 모델을 시각적인 그래픽 형태로 표기하고, 표기법에 사용하는 심벌에 명확한 정의를 부여하는 것 입니다. 이것을 통해 개발자들은 원활한 소통을 할 수 있습니다.
• 명세화 : 정확하고, 명백하며, 완전한 모델을 만드는 것을 말합니다. UML은 소프트웨어 개발을 위한 분석, 설계, 구현 각 단계에서 필요한 모델을 정확하고 완전하게 명세하는 역할을 합니다.
• 구축 : 다양한 프로그래밍 언어로 표현하는 것 입니다. 또한 이미 구축되어 있는 소스코드를 UML로 역변환하여 분석하는 역공학(Reverse Engineering)도 있습니다.
• 문서화 : 요구사항을 표현하고 시스템을 테스트하는 언어도 제공합니다.

 

 

 

 

구성요소 설명

 

사물

구조 사물 : 시스템의 구조를 표현하는 사물(클래스, 인터페이스, 통신, 유스케이스, 노드 등)

행동 사물 : 시스템의 행위를 표현하는 사물(교류, 상태 머신)

그룹 사물 : 시스템의 개념을 그룹화 하는 사물(패키지)

주해 사물 : 시스템의 부가적으로 개념을 설명하는 사물(노트)

 

관계

의존 관계(Dependency Relationship)

• 연관 관계와 같지만 메소드를 사용할 때와 같이 매우 짧은 시간만 유지 
• 영향을 주는 객체에서 영향을 받는 객체 방향으로 점선 화살표를 연결

 

연관 관계(Association Relationship) : 두 사물 간의 구조적 관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말합니다. 연관을 표현할 때는 이름과 역할 그리고 다중성을 표기합니다. ('has-a')관계라고도 합니다. 예시) 자동차와 부품들의 관계가 있습니다.

 

일반화 관계(Generalization Relationship) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말합니다. ('is-a')관계라고도 합니다. 예시) 부모 클래스로서의 자동차와 자식클래스로서의 택시, 버스, 트럭 등

 

실체화 관계(Realization Relationship) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정하는 것 입니다. 예시) TV의 행동중 일부가 리모컨의 행동을 실체화 함 클래스(TV)와 인터페이스(리모컨)가 가지는 관계가 실체화 관계

 

 

다이어그램

구조 다이어그램 : 정적 모델링을 위한 다이어그램

행위 다이어그램 : 동적 모델링을 위한 다이어그램

 

정적 모델링 도구

정적 모델링 도구란 UML의 구조 다이어그램에 해당합니다. 시스템의 지속적이고 정적인 측면을 모델링하는 특징이 있습니다.

정적 모델링구조의 종류로는 클래스 다이어그램, 오브젝트 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램 등이 있습니다.

 

Class diagram 클래스 다이어그램 

Object diagram 오브젝트 다이어그램

composite structure diagram 복합 구조 다이어그램

deployment diagram 배치 다이어그램

component diagram 컴포넌트 다이어그램

package diagram 패키지 다이어그램

 

클래스 다이어그램 (class diagram)

객체지향 모델링에서 가장 많이 사용하는 개념입니다. 클래스는 객체지향 프로그램에서 속성과 행위를 갖는 하나의 객체 단위입니다. 클래스의 구성 요소로는 이름, 속성, 메서드 입니다.

 

클래스 다이어그램 작성 절차

1. 클래스 명세를 결정하고, (클래스 후보 추출)→업무 명세서에서 명사를 찾아냅니다.
2. 메서드(오퍼레이션)를 찾아낸 후,
3. 필요한 속성을 추출하는 과정입니다.

 

 

오브젝트 다이어그램 (object diagram)

• 오브젝트는 클래스의 인스턴스(구체적인 예)
• 오브젝트 다이어그램은 특정 시점의 오브젝트들의 구조적 상태를 표현

 

 

 

 

 

패키지 다이어그램 (package diagram)

유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

 

 

 

 

컴포넌트 다이어그램 (component diagram)

연관성이 높은 기능과 관련된 데이터를 하나로 묶어 처리하도록 만들어진 단위입니다.

모든 컴포넌트는 반드시 다른 컴포넌트와 통신할 수 있는 인터페이스가 정의되어 있으며, 컴포넌트의 인터페이스와 인터페이스의 구현은 컴포넌트를 구성하는 내부에 캡슐화 되어 있다.

인터페이스에 의해서 기능이 정의된, 독립적으로 개발, 배포, 조립 가능한 시스템의 구성단위입니다.

 

 

배치 다이어그램 (deployment diagram)

노드를 입체적으로 표현하고, 그 사이를 의존 화살표와 접속 관계를 나타내는 실선으로 연결해 이들 간의 통신 관계를 나타낸 것입니다. 이를 다르게 설명하면 네트워크, 하드웨어 또는 소프트웨어들을 실행 파일 수준 컴포넌트들과 함께 표현한 것 입니다.

 

 

 

 

 

 

 

동적 모델링 도구

UML의 행위 다이어그램과 인터랙션 다이어그램에 해당합니다.

시간의 흐름에 따라 유동적으로 변하는 객체의 상태나 행위, 객체 간의 상호작용 등을 표현합니다.

 

Use case diagram 유스케이스 다이어그램

Activity diagram 활동 다이어그램

Collaboration diagram 

State diagram 상태 다이어그램

Sequence diagram 순차 다이어그램

Communication diagram  통신 다이어그램

 

Interaction 표기법의 종류

Interaction overview diagram 

Timing diagram 

 

유스케이스 다이어그램 (use case diagram)

액터의 관점에서 본 시스템의 기본적인 행동을 기술한 것 입니다.

개념 레벨의 유스케이스는 이용자의 요구 를 기술하는 수단입니다.

필요한 유스케이스(기능요구)가 모두 적혀 있는지 확인가능합니다.

 

 

 

순차 다이어그램 시퀀스 다이어그램 (Sequence Diagram)

객체 간의 동적 상호작용을 시간의 흐름에 따라 나타낸 것 입니다.

특징으로는 객체의 메서드(오퍼레이션)와 속성을 상세히 정의한 것 입니다.

객체의 책임(Responsibility) : 순차 다이어그램의 객체는 다른 객체가 의뢰하는 일을 처리하는 과정입니다.

또한 순차 다이어그램은 유스케이스를 실현합니다.

 

 

 

 

통신 다이어그램 (Communication Diagram)

순차 다이어그램이 메시지에 대한 시간적 순서를 나타낸 것이라면, 통신 다이어그램은 객체들 사이에 주고받는 메시지를 표현한 것 입니다.

객체 와 객체 사이를 연결하는 링크 그리고 그 링크 사이에 오가는 메시지 로 구성됩니다.

 

 

 

 

상태 다이어그램 (state diagram)

객체의 상태가 이벤트의 발생 혹은 시간의 경과에 의해 어떻게 변화하는지를 나타낸 것 입니다.

특정 객체가 생성하여 소멸할 때까지의 라이프 사이클을 모델화 한 것 입니다.

※ 표현하는 방법은 객체가 가질 수 있는 상태를 모서리가 둥근 사각형으로 나타내고, 전이(상태의 변화)를 나타내는 화살표와 화살표 위에 이벤트와 조건 등을 표시합니다.

 

 

 

활동 다이어그램 (activity diagram)

예전부터 사용해왔던 순서도와 모양이 매우 비슷합니다.

순서도 를 객체지향 스타일로 개선시킨 형태입니다.

객체지향 스타일 모델을 상위 수준뿐만 아니라 하위 수준으로도 표현하기 위해, 객체나 조직 또는 역할에 대한 행위를 표현할 수 있도록 구획면을 추가했습니다.

※ 구획면이란 수영장의 레인처럼 구분된 세로 방향의 영역을 말하는데, 활동 다이어그램에 표현된 각 활동의 수행 주체를 표현할 때 이용됩니다.

 

 

 

 

 

 

 

UML 모델링 절차

1. 초기 클래스 다이어그램 작성
2. 유스케이스 다이어그램 작성
3. 클래스 다이어그램 변경
4. 순차 다이어그램과 통신 다이어그램 작성
5. 인터페이스를 식별(클래스 다이어그램 변경)
6. 활동 다이어그램과 상태 다이어그램을 작성
7. 컴포넌트 다이어그램 및 배치 다이어그램 작성

 

 

 

시스템 구성 요소

1. 입력(Input) : 처리방법, 처리할 데이터, 조건을 시스템에 투입 하는것

2. 처리(Process) : 입력된 데이터를 처리 방법과 조건에 따라 처리하는것

3. 출력(Output) : 처리된 결과를 시스템에서 산출하는것

4. 제어(Control) : 자료를 입력하여 출력될 때 까지의 처리 과정이 올바르게 진행되는지 감독하는것

5. 피드백(Feedback) : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리 하는것

 

Maintenance는 유지 보수, 시스템 구성요소에는 포함되지 않는다.

 

 

요구사항

 

요구사항 개발 프로세스 순서

도출 (elicitation) -> 분석(analysis) -> 명세(specification) -> 확인(validation)

 

요구사항 분석

 

• 소프트웨어가 환경과 어떻게 상호작용하는지 이해하고, 사용자의 요구사항은 구조화와 열거가 어려워 명확하지 못하거나 모호한 부분이 많아
• 이러한 요구를 걸러내기 위한 과정을 통하여 요구사항을 도출하고 요구사항 정의를 문서화하는 과정
• 도출된 사항을 분석하고 소프트웨어 개발 범위를 파악하여 개발 비용 일정에 대한 제약을 설정하고 타당성 조사를 수행한다

 

 

요구 추출 (requirement elicitation) : 프로젝트 계획 단계에 정의한 문제의 범위 안에 있는 사용자의 요구를 찾는 단계

도메인 분석(domain analysis) 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링

비기능적 : 요구에서 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 성능, 보안 품질, 안정성 등에 해한 요구사항을 도출

 

 

 

 

소프트웨어

 

시스템 품질 속성

 

품질속성	내용
가용성 (Availability)	소프트웨어가 필요할 때 작업을 수행할 준비가 되었는지 판단 오류 발생 시 시스템의 반응을 판단하는 척도 시스템 오류를 완화시켜 서비스 중단 시간을 최소화 하는 것
변경용이성 (Modifiability)	변경 사항의 지역화	의미적 응집성 유지, 변경처리예상, 모듈 일반화, 변경의 폭 제한
-	파급효과(연쇄작용)의 방지	정보은닉, 기존 인터페이스 유지, 통신 경로 제한, 중개자 사용
-	바인딩 시점의 연기	런타임 등록, 설정파일, 다형성, 컴포넌트 교체, 전해진 프로토콜 준수
성능 (Performance)	시스템 이벤트에 정해진 시간 내에 응답해야 함
보안성 (Security)	인증되지 않은 접근으로부터 데이터와 정보를 보호 비밀성 및 무결성 (인가 받지 않은 데이터 및 서비스 접근 통제)
시험용이성 (Testability)	테스팅을 통해 결함을 발견
사용편의성 (Usability)	사용자가 얼마나 쉽게 쓰는지에 대한 척도 시스템 기능 학습, 시스템 효율적 사용, 오류의 영향 최소화, 사용자 요구에 따른 시스템의 적용, 신뢰와 만족 증가

 

 

소프트웨어 설계 분류

 

상위설계

• 아키텍처 설계
• 데이터 설계
• 인터페이스 정의
• 사용자 인터페이스 설계

 

하위설계

• 모듈 설계
• 자료 구조 설계
• 알고리즘 설계

 

추상화

• 시스템 내의 공통 성질을 추출한 뒤 추상 클래스를 설정하는 기법
• 현실 세계를 컴퓨터 시스템에 자연스럽게 표현할 수 있다
• 기능 추상화, 제어 추상화, 자료 추상화

 

아키텍처 설계 과정

설계 목표 설정 -> 시스템 타입 결정 -> 스타일 적용 및 커스터마이즈 -> 서브 시스템의 기능, 인터페이스 동작 작성 -> 아키텍처 설계 검토

 

파이프 필터

• 데이터 흐름을 생성하고 처리하는 시스템을 위한 구조
• 필터는 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송
• 노드와 간선으로 구성
• 각 처리 과장은 필터 컴포넌트에서 이루어지며 처리되는 데이터는 파이프를 통해 흐른다. 이 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있다
• 컴파일러 연속한 필터들은 어휘 분석 파싱 의미 분석 그리고 코드생성을 수행한다.
• 상태 정보 공유를 위해 비용이 소요되며 데이터 변환에 오버헤드가 발생할 수 있다

 

 

 

인터페이스 (user interface)

 

UI 설계 지침

• 사용자 중심 : 실사용자의 이해를 바탕으로 쉽게 이해하고 쉽게 사용할 수 있는 환경 제공
• 일관성 : 사용자가 기억하기 쉽고 빠른 습득이 가능하도록 버튼이나 조작법을 제공
• 단순성 : 인지적 부담을 줄이기 위해 쉽게 조작되도록한다

 

 

사용자 인터페이스 종류

• CUI(character user interface) : 문자 방식의 명령어 입력
• GUI (graphic user interface) : 그래픽 환경 기반의 마우스 입력
• WUI (web user interface) : 인터넷과 웹 브라우저를 통해 웹페이지를 열람하고 조작
• CLI (command line interface) : 사용자가 컴퓨터 자판 등을 이용해 명령 문자열을 입력하여 체계를 조작

 

 

 

객체지향

 

캡술화 ( encapsulation)

• 서로 관련성이 높은 데이터와 그와 관련된 기능을 묶는 기법
• 결함도가 낮아져 소프트웨어 개발에 있어 재사용성이 높다
• 정보은닉을 통하여 타 객체와 메세지 교환 시 인터페이스가 단순

 

 

객체지향 설계 원칙

SRP 단일 책임 원칙 (Single responsibility principle)	한 클래스는 하나의 책임만 가져야 한다.
OCP 개방-폐쇄 원칙 (Open/closed principle)	“소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
LSP 리스코프 치환 원칙 (Liskov substitution principle)	“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라. 부모 클래스가 들어갈 자리에 자식 클래스를 대체하여도 계획대로 작동해햐한다.
ISP 인터페이스 분리 원칙 (Interface segregation principle)	클라이언트는 자신이 사용하지 않는 메소드와 의존관계를 맺으면 안 된다. 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다.
DIP 의존관계 역전 원칙 (Dependency inversion principle)	의존 관계를 맺으면 변하기 쉽고 변화 빈도 가높은 것보다 변하기 어렵고 변화 빈도가 낮은 것에 의존한다

 

 

 

정보은닉 (information hiding) : 객체 내부의 속성과 메소드를 숨기고 공개된 인터페이스를 통해서만 메시지를 주고받을 수 있도록 하는 것을 의미

 

 

객체 지향 기법

 

- 현실의 개체(Entity)를 하나의 객체(Object)로 만들어 소프트웨어를 개발할 때 객체들을 이용해 프로그램을 작성할 수 있도록 하는 기법

 

장점

 

1) 재사용성, 확장성 -> 개발기간 단축, 유지보수 쉬움

2) 복잡한 구조를 단계적, 계층적으로 표현

3) 데이터 병렬 처리

 

구성요소

 

1) 객체(Object)

- 데이터와 데이터를 처리하는 함수를 캡슐화한 소프트웨어 모듈

- 데이터 : 객체 정보, 속성, 상태

- 함수 : 객체가 수행하는 기능

2) 클래스(Class)

- 공통된 속성, 연산을 갖는 객체들의 집합

- Instance : 클래스에 속한 각각의 객체

- Superclass : 상위 class

- Subclass : 하위 class

3) 메시지(Message)

- 객체들 간 상호작용을 하기 위한 수단

- 객체 이름, 메소드 이름, 인자로 구성

 

특징

 

1) 캡슐화(Encapsulation)

- 데이터와 함수를 하나로 묶는 것을 의미

- 재사용성 증가, 오류 파급 효과 감소

- 인터페이스가 단순해짐, 객체 간 결합도가 낮아짐

 

2) 정보 은닉(Information hiding)

- 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근

- 다른 객체에게 주는 영향을 감소시킴

 

3) 추상화(Abstraction)

- 불필요한 부분을 생략하고 중요한 것에만 중점을 두어 모델화

 

4) 상속성(Inheritance)

- 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받음

- 상위 클래스에 정의된 속성을 재정의하지 않아도 된다.

- 새로운 속성과 연산을 추가하여 사용 가능

- 다중 상속성(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속

 

5) 다형성(Polymorphism)

- 같은 함수, 기능에 대해 다른 정의를 통해 각 클래스가 다른 행동을 할 수 있게 해줌

- Overloading : 같은 이름을 가진 함수지만 인자가 달라 각기 다른 인자에 따라 함수를 선택해 수행

- Overriding : 상위 클래스로부터 상속받은 함수들을 다르게 구현하여 사용

 

생명 주기

 

계획 및 분석 -> 설계 -> 구현 -> 테스트 및 검증

 

1) 계획 및 분석(객체 지향 분석, OOA)

- 사용자의 요구사항을 분석하여 클래스, 속성, 연산 등을 정의하여 모델링하는 작업

2) 설계(객체 지향 설계, OOD)

- 분석을 통해 생성한 모델을 설계 모델로 변환하는 작업

- 설계 : 문제 정의 -> 요구 명세화 -> 객체 연산자 정의 -> 객체 인터페이스 결정 -> 객체 구현

3) 구현(객체 지향 프로그래밍, OOP)

- 객체라는 단위를 중심으로 프로그램을 개발하는 작업

- 유지보수가 쉽고 재사용 가능

- 확장성 제공

4) 테스트 및 검증

- 클래스 테스트 : 캡슐화된 클래스나 객체를 검사하는 과정

- 통합 테스트 : 객체를 결합해 프로그램을 완성시키는 과정에서의 테스트

-> thread 기반 테스트 : 각각의 thread가 개별적으로 테스트

-> 사용 기반 테스트 : 독립 클래스를 테스트한 후 종속 클래스를 테스트

- 확인 테스트 : 사용자 요구사항에 대한 만족 테스트

- 시스템 테스트 : 모든 요소들이 올바른 기능을 수행하는 지 테스트

 

 

 

 

 

 

분산 시스템

 

 

미들웨어

• 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어
• 이기종 하드웨어, 소프트웨어, 네트워크, 프로토콜, 운영체제 환경등에서 시스템 간의 표준화된 연결을 도와주는 소프트웨어
• 표준화된 인터페이스를 통하여 시스템 간의 데이터 교환에 있어 일관성을 제공
• 운영체제와 애플리케이션 사이에서 중간 매개 역할을 하는 다목적 소프트웨어