정보처리기사

소프트웨어 설계

조회: 223 댓글: 0개 2023.05.03 18:23 수요일

GoF 디자인 패턴

분산 시스템 마스터 슬레이브 파이프 자꾸 쳐 나오는데 뭐냐 진짜

소프트웨어 아키텍처 설계에서 시스템 품질 속성

  1. 가용성
  2. 변경용이성
  3. 성능
  4. 보안성
  5. 사용편의성
  6. 시험용의성

1.Booch(부치)
- 미시적, 거시적 개발 프로세스를 모두 사용하는 분석방법.
- 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의
2. Jacobson(제이콥슨)
- Use Case를 사용하여 분석(사용자, 외부 시스템, 다른 요소들이 시스템과 상호 작용 하는 방법을 기술)
3. Coad-Yourdon
- E-R 다이어그램을 사용하여 객체의 행위를 모델링
- 객체 식별, 구조 식별
4. Wirfs-Brock
- 분석과 설계간 구분이 없으며, 고객 명세서를 평가하여 설계 작업까지 연속적으로 수행

fan in fan out

럼바우 Rumbaugh

  1. 객체 object
    객체
    1. 정보 모델링, 시스템에서 요구
  2. 동적 dynamic
    상태
    1. 제어, 흐름, 동작
  3. 기능 functional
    자료흐름도
    1. DFD

사용자 인터페이스의 구분

  1. CLI(Command Line Interface)
    텍스트 형태 인터페이스
  2. GUI(Graphical User Interface)
    마우스로 선택하여 작업하는 그래픽 환경 인터페이스
  3. NUI(Natural User Interface)
    사용자의 말이나 행동으로 기기 조작하는 인터페이스
  4. VUI(Voice User Interface)
    사람의 음성으로 기기 조작하는 인터페이스
  5. OUI(Organic User Interface)
    모든 사물과 사용자 간의 상호작용을 위한 인터페이스

하향식 통합 테스트

-계층 구조상에서 시스템의 주요 컴포넌트들을 찾고 그것을 낮은 수준의 컴포넌트들로 분해하는 것으로 단계적 정제라 하며 메인 모듈의 설계에서 시작하여 단계적으로 구체화시키는 것
-하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.
-하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계초기 단계에서 필요하다.

상향식 통합 테스트

-가장 기본적인 컴포넌트를 먼저 설계한 다음 이것을 사용하는 상위 수준의 컴포넌트를 설계하는 것
-상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.
-기존 컴포넌트들을 조합하여 시스템을 개발하는 경우에는 상향식이 적합
시스템 명세가 명확한 경우와 모든 것을 새로 개발하는 작업에는 하향식이 적합하다.

Use Case의 구성 요소 간의 관게

  1. 연관 관계 association
    유스케이스와 액터간의 상호작용이 있음을 표현한다.
    @use case 와 actor의 관계
  2. 포함 관계 include
    하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다.
    @시스템의 기능이 별도의 기능을 포함
  3. 확장 관계 extend
    확장 기능 유케와 확장 대상 유케 사이에 형성되는 관계이다.
    @기본 use case 수행 시 특별한 조건을 만족할 때 수행할 usecas
  4. 일반화 관계 generalization
    유사한 유케 또는 액터를 모아 추상화한 유케 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계이다.
    @하위 use case/action이 상위 use case/actor에게 기능/역할을 상속받음
  5. 그룹화
    ..
    @여러개의 usecase를 단순화하는 방법

요구사항 개발 프로세스

  1. 도출 elicitation
  2. 분석 analysis
  3. 명세 specification
  4. 확인 validation

시스템 구성요소
처제피입출

  1. 입력 input
    처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
  2. 처리 process
    입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
  3. 출력 output
    처리된 결과를 시스템에서 산출하는 것
  4. 제어 control
    자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
  5. 피드백 feedback
    출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것

UI 설계 원칙

  1. 직관성
    누구나 쉽게 이해 사용
  2. 유효성
    목적을 정확하고 완벽하게
  3. 학습성
    쉽게 배우고 익힐
  4. 유연성
    요구사항을 최대한 수용하고 실수를 최소화

소프트웨어 아키텍처 패턴

  1. layers
    하위 모듈들의 그룹으로 나눌 수 있는 구조화된 프로그램에 사용
  2. client-server
    컴포넌트가 다른 컴포넌트에게 서비스를 요청
  3. pipe-filter
    데이터 스트림을 생성하고 처리하는 시스템에 사용
    서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복
  4. mvc
  5. master-slave
    마스터 컴포넌트가 동등한 구조를 지닌 슬레이브들에게 작업 분산
  6. broker
    분리된 컴포넌트들로 이루어진 분산 시스템에 사용
  7. peer-to-peer
    몰라 서로 교환?
  8. event-bus
    이벤트 소스, 리스너, 채널, 버스
  9. blackboard
    결정 가능한 해결 전략이 알려지지 않은 문제에 유용
  10. interpreter
    언어 번역

객체지향의 주요 개념

  1. 캡슐화 Encapsulation
    데이터와 데이터를 처리하는 함수를 하나로 묶은 것
    캡슐화된 객체의 세부 내용이 은폐되어 변경이 발생해도 파급이 적음
    캡슐화된 객체들은 재사용이 용이
    인터페이스가 단순해지고 객체간의 결합도가 낮아짐
  2. 상속성 Inheritance
    부모 클래스의 속성과 연산을 하위 클래스가 상속받는 것
    하위 클래스는 상속받은 것 외에 새로운 것을 첨가 가능
    클래스의 재사용, 소프트웨어의 재사용을 높이는 중요한 개념
  3. 다형성 Polymorphism
    하나의 메시지에 대해 각 객체가 갖고 있는 고유한 방법대로 응답하는 것
    하나의 클래스나 메서드가 다양한 방식으로 동작이 가능한 것
    오버로딩과 오버라이딩
  4. 추상화 abstraction
    데이터들의 공통된 성질을 추출해 슈퍼 클래스 선정

XP(익스트림 프로그래밍)

  1. 5원칙
    1. 단순성(Simplicity)
    2. 소통(Communication)
    3. 피드백(feedback)
    4. 용기(courage)
    5. 존중(respect
  2. 기본원리

디자인 패턴

  1. Visitor
    각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성함.
    분리된 처리 기능은 각 클래스를 방문하여 수행
  2. Observer
    한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달.
    분산된 시스템 간에 이벤트 생성, 발행(publish), 수신(subscribe)할 때 이용
  3. Bridge
    구현부에서 추상층을 분리, 서로가 독립적으로 확장함
    기능과 구현을 두 개의 별도 클래스로 구현함.
  4. Factory Method
    객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 결정 하는 것.
    Virtual-Constructor 패턴이라고도 함

CASE(Computer Aided Software Engineering)의 주요 기능
 - S/W 라이프 사이클 전 단계의 연결
 - 그래픽 지원
 - 다양한 소프트웨어 개발 모형 지원

자료흐름도(Data Flow Diagram)의 구성요소
 - 프로세스(Process)
 - 자료 흐름(Data Flow)
 - 자료 저장소(Data Store)
 - 단말(Terminal)

자료흐름도 설명

  1. 자료 흐름 그래프 또는 bubble 차트라고도 한다.
  2. 구조적 분석 기법에 이용된다.
  3. DFD의 요소는 화살표, 원, 사각형, 직선으로 표시한다.

자료 사전
 - 정의 =
 - 구성,연결 +
 - 반복 { }
 - 주석 **
 - 선택 [ㅣ]
 - 생략 ( )

UML 확장 모델
스테레오 타입 객체 표현기호 << >>

UML(Unified Modeling Language)의 기본 구성요소
띵(Thing)
다(Diagram)
리(Relationship)

UML 관계
 - Dependency(의존) : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 말합니다 (Cascade 생각하셈)
 - Realization(실체화) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
 - Generalization(일반화) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말합니다.('is-a')관계
 - Association(연관) : 두 사물간의 구조적 관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함 ('has-a')관계라고도 합니다

 분류다이어그램 유형 목적 
 구조/정적 다이어그램
(Structure Diagram)
클래스 다이어그램
(Class Diagram) 
시스템을 구성하는 클래스들 사이의 관계를 표현한다. 
객체 다이어그램
(Object Diagram) 
객체 정보를 보여준다. 
복합체 구조 다이어그램
(Composite Structure Diagram)
복합 구조의 클래스와 컴포넌트 내부 구조를 표현한다.
배치 다이어그램
(Deployment Diagram)
소프트웨어, 하드웨어, 네트워크를 포함한 실행 시스템의 물리 구조를 표현한다. 
컴포넌트 다이어그램
(Component Diagram)
컴포넌트 구조 사이의 관계를 표현한다. 
패키지 다이어그램
(Package Diagram)
클래스나 유스케이스 등을 포함한 여러 모델 요소들을 그룹화해 패키지를 구성하고 패키지들 사이의 관계를 표현한다. 
 행위/동적 다이어그램
(Behavior Diagram)
활동 다이어그램
(Activity Diagram) 
업무 처리 과정이나 연산이 수행되는 과정을 표현한다. 
상태 머신 다이어그램
(State Machine Diagram)
객체의 생명주기를 표현한다. 
유스케이스 다이어그램
(Use Case Diagram)
사용자 관점에서 시스템 행위를 표현한다.
상호 작용 
다이어그램
Interaction
Diagram)
순차 다이어그램
(Sequence Diagram) 
시간 흐름에 따른 객체 사이의 상호작용을 표현한다. 
상호작용 개요 다이어그램
(Interaction Overview
Diagram)
여러 상효작용 다이어그램 사이의 제어 흐름을 표현한다. 
통신 다이어그램
(Communication
Diagram)
객체 사이의 관계를 중심으로 상호작용을 표현한다. 
타이밍 다이어그램
(Timing Diagram)
객체 상태 변화와 시간 제약을 명시적으로 표현한다. 

사용자 인터페이스를 설계할 경우 고려해야 할 가이드라인
 - 사용성을 심미성보다 우선하여 설계해야 한다.
 - 효율성을 높이게 설계해야 한다.
 - 발생하는 오류를 쉽게 수정할 수 있어야 한다.
 - 사용자에게 피드백을 제공해야 한다.

기타
EAI(Enterprise Application Integration): 기업 응용 프로그램 통합으로 기업용 응용 프로그램의 구조적 통합 방안을 가리킴
FEP(Front-End Processor): 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 차지하는 시간을 줄여주는 프로그램이나 하드웨어
GPL(General Public License): 자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이선스
Duplexing: 이중화(데이터베이스의 회복 기법 중 가장 간단한 것)

captcha