자격증/정보처리기사 인강 - 필기

제1과목 소프트웨어 설계

kms152000 2024. 4. 16. 08:21

1. 요구사항 확인

 

1-1. 현행 시스템 분석

(1) 현행시스템 파악의 정의

  • 구성된 하위 시스템
  • 제공하는 기능
  • 다른 시스템들과 어떤 정보를 주고 받는지
  • 어떤 기술요소를 사용하는지
  • 사용하고 있는 소프트웨어 및 하드웨어
  • 구성된 네트워크

 

 (2) 현행 시스템 파악의 목적

향후 개발하고자 하는 시스템의 개발범위 및 이행방향성 설정에 도움을 주는 것

 

(3) 현행 시스템 파악

  1. 플랫폼 기능 분석: 소프트웨어를 구동시키는데 필요한 환경
  2. 플랫폼 성능 특성 분석: 응답시간, 가용성, 사용률, 경과시간, 처리량
  3. 운영체제 분석
  4. 네트워크 분석
  5. DBMS 분석
  6. 비즈니스 융합분석

(4) 현행 시스템 분석 - 개발 기술 환경 정의

  1. 운영체제
    • 하드웨어와 소프트웨어 리소스를 관리
    • 컴퓨터 프로그램을 위한 공통 서비스를 제공하는 소프트웨어
    • Windows, UNIX, Linux, IOS, Android
      • 관련 고려 사항: 신뢰도, 성능, 기술지원, 주변기기, 구축비용
  2. DBMS
    • 사용자, 다른 애플리케이션, 데이터베이스와 상호작용
    • 데이터를 저장하고 분석하기 위한 소프트웨어 애플리케이션
    • 데이터베이스 생성, 조회, 변경 등의 관리가 주요 기능
    • Oracle, Ibm DB2, MySQL등
      • 관련 고려 사항: 가용성, 성능, 기술지원, 상호 호환성, 구축비용
  3. 미들웨어
    • middle + software
    • 운영체제와 소프트웨어 애플리케이션 사이에 위치
    • 소프트웨어 애플리케이션에게 운영체제가 제공하는 서비스를 추가 및 확장
      • 미들웨어 솔루션 유형(암기)
      • DB: 접속 미들웨어
      • WAS: 웹 환경을 구현
      • MOM: 메시지 기반의 비동기형 메시지를 전달(우체국, 메일시스템)
      • RPC: 원격 프로시저를 로컬 프로시저처럼 호출하는 방식
      • ORB: 객체 지향 미들웨어로 다른 컴퓨터의 프로그램을 네트워크를 통해 호출
      • TP-Monitor: 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시(항공기나 철도 예약 업무)
        • 관련 고려 사항: 가용성, 성능, 기술지원, 구축비용
  4. 오픈소스
    • 소스코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있다.
      • 관련 고려 사항: 라이선스의 종류, 사용자 수, 기술의 지속 가능성, 상호 호환성, 구축비용

 

 

 

1-2. 소프트웨어 개발 생명 주기, 개발 방법론

소프트웨어 개발 생명주기 모델(암기)

: 소프트웨어를 어떻게 개발할 것인가에 대한 전체적인 큰 흐름

 

<폭포수 모델 waterfall model>

요구사항 분석 → 설계 → 구현 → 테스팅 → 유지보수

  • 앞 단계가 완료될 때까지 대기 상태
  • 완성된 모습을 후반부가 되기 전엔 볼 수 없다.
  • 고객이 원하는 모습이 아니어도 수정이 어렵다.

<원형 모델 Prototype model>

요구사항 정의 →원형 설계 →원형 개발 →고객평가 →요구사항조정 →완제품

  • 점진적으로 시스템을 개발해 나가는 방법
  • 원형을 가능한 빨리 개발한 후 고객과 검증하는 것이 목적

<나선형 모델 Spiral model>

계획 및 정의 →위험 분석 →개발 →고객 평가

  • 고비용의 시스템 개발이나 큰 시스템 구축 시 효과적
  • 프로젝트 수행 시 발생하는 위험을 최소하려는 목적
  • 개발자가 위험을 정확하게 분석하지 못했다면 심각한 문제

 

 

소프트웨어 개발 방법론(암기)

  • 소프트웨어를 생산하는 데에 필요한 프로그래밍 개발 과정들을 정리 및 표준화
  • 프로그래머들이 프로그래밍 개발과정에서 각 개인이 일관성 유지
  • 프로그래머들간의 효과적인 협업을 도움

구조적 개발 방법론(1970년대): 기능중심

정보공학 방법론(1980년대): 자료구조중심

객체지향 개발 방법론(1990년대): 객체중심

CBD 방법론(2000년대): 컴포넌트중심

 

<구조적 분석>

자료흐름도 →자료사전 →소단위명세서

  • 효율적인 시스템 분석 명세서 작성 목
  • 도형 중심의 분석용 도구 이용
  • 사용자의 요구사항을 파악하고 문서화하는 체계적인 분석 기법
  • 사용자의 요구 사항을 정확하게 작성 가능
  • Yourdon등에 의해 개발

 

자료흐름도(Data Flow Diagram: DFD)(암기)

자료흐름도(Data Flow Diagram: DFD)

 

자료사전(Data Dictionary: DD)(암기)

자료사전(Data Dictionary: DD)

 

소단위 명세서(Mini Specification): 자료흐름도에 나타난 모든 최소 단위의 처리에 대해 자료흐름이 변환되는 절차 또는 

논리적인 활동을 기술하는 도구

 

 

애자일(Agile)

  • 2001년 'Agile연합'모임 결성
  • 원칙 - '가볍지만 충분한'
  • 개인과의 상호작용
  • 제대로 동작하는 소프트웨어의 개발에 집중
  • 고객과의 협력

애자일(Agile) 방법론 유형

  1. XP(eXtreme Programming) 
    • 의사소통 개선과 즉각적 피드백
    • 5가지 가치 - 용기, 단순성, 의사소통, 피드백, 존중
    • 12가지 실천사항 - 계획게임, 짝 프로그래밍, 짧은 릴리즈 주기, 코드 공동 소유, 메타포, 지속적인 통합, 단순 설계, 주당 40시간 작업, 테스트 기반 개발, 고객의 참여, 리팩토링, 코딩 표준
  2. 스크럼(SCRUM)
    • 프로젝트 관리를 위한 상호, 점진적 개발방법론
    • XP와 달리 진행 체계 수립, 역할, 정의에 중점
    • 기존 폭포수 모델이나 프로토타이핑 같은 모델과 달리 모든 LifeCycle을 담지 않는다.
    • 5가지 가치 - 확약, 전념, 정직, 존중, 용기
      1. Product Owner(PO): 제품 책임자, 제품에 대한 요구사항 →백로그 작성 주체
      2. Scrum Master(SM): 스크럼팀의 스크럼이 잘 수행될 수 있도록 도와주는 역할
      3. 백로그: 요구사항 리스트
      4. 제품 백로그: 전체 기간 동안 개발할 백로그
      5. 스프린트(암기): 짧은 기간 동안에 동작하는 SW를 사용자에게 제공 →피드백 받고 수정
  3. 린(LEAN)
    • 도요타의 대표적인 생산 방식
    • 인력, 생산 설비 등을 필요한 만큼만 유지하면서 생산 효율을 극대화하는 방식
    • 전적으로 고객 관점
  4. Crystal(크리스탈)
  5. ASD(Adoptive Software Development)
  6. FDD(Feature Driven Development)
    • 기능중심개발

 

객체지향 방법론

  • 소프트웨어를 개발할 때 작은 단위의 모듈들을 구성 및 재사용
  • 표기법이라도 통일하자는 제안에 의해 UML을 사용하게 되었다.
  • 객체, 클래스, 캡슐화, 데이터 은닉, 상속, 조합, 다항성의 개념
    • 객체: 업무수행을 위한 대상이 되는 사람, 장소, 사물, 사건 및 개념
    • 클래스: 공통 속성과 행위를 가진 객체를 묶어 추상화한 개념
    • 캡슐화: 구현부가 외부에 노출되지 않게 싸여진 상태
    • 데이터 은닉: 각각의 객체가 자신의 속성(데이터)과 메서드(행위)를 다른 객체에게 숨기고 있는 것
    • 상속: 클래스가 가진 속성과 행위를 객체가 물려 받는 것
    • 조합: 다른 객체를 사용하여 객체를 구성하는 것
    • 다형성: 같은 메서드에 다르게 반응하는 것.
  • SOLID (객체 지향 설계) (암기)
    • SRP: 단일 책임 원칙(Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다.
    • OCP: 개방-폐쇄 원칙(Open/closed principle) 소프트웨어 요소는 확장에는 열려 있고 변경에는 닫혀 있어야한다.
    • LSP: 리스코프 치환 원칙(Liskov substitution principle) 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다
    • ISP: 인터페이스 분리 원칙(Interface segregation principle) 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
    • DIP: 의존관계 역전 원칙(Dependency inversion principle) 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
  • (암기)Rumbough(럼바우)의 OMT: 객체모델링(객체다이어그램), 동적모델링(상태다이어그램), 기능모델링(자료흐름도)
  • Booch 방법론: DFD
  • Coad/Yourdon 방법론: E-R다이어그램

 

 

 

1-3. 요구사항 확인, 분석 모델 확인

요구사항 개발 프로세스

도출 →분석 →명세(시스템 정의서, 요구사항 명세서, 소프트웨어요구사항명세서) →확인

 

요구사항 분석 기법

  1. 요구사항 분류(Requirement Classification)
    • 요구사항이 기능(조회,인출,입금,송금 등, 예시: 자판기에서 콜라를 선택하면 콜라 나옴)인지 비기능(안전, 보안, 예시: 콜라가 3초안에 나옴)인지
  2. 개념 모델링(Conceptual Modeling)
    • 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심
    • 대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용한다.
    • 사용 시나리오를 나타내기 위해 유스케이스 다이어그램이 많이 사용된다.
  3. 요구사항 할당(Requirement Allocation)
  4. 요구사항 협상
  5. 정형 분석(Formal Analysis)
    • 형식적으로 정의된 시맨틱(Semantics)을 지닌 언어로 요구사항을 표현한다.
    • 정확하고 명확한 표현
    • 정형 분석은 요구사항 분석의 마지막 단계에서 이루어진다.
      • 정형 명세기법: 수학적 원리와 표기법, Z 정형 명세 언어
      • 비정형 명세기법: 자연어를 기반으로 서술, 작성하기 쉬우나, 애매모호한 표현으로 오해석 위험 있음.

 

UML의 구성요소(암기)

  1. 사물(Things) - 기본요소
  2. 관계(Relationship) - 사물 간의 관계
  3. 다이어그램(Diagram) - 사물과 관계를 도형으로 표현

(암기)

 

유스케이스 다이어그램

  • 시스템을 사용하는 목적을 사용자 관점에서 기술
  • 목적 달성을 위한 사용자와 시스템 사이의 상호작용을 알 수 있다.
  • 시스템이 제공하는 기능과 서비스등을 정의하고 시스템의 범위를 결정한다.
  • 관계(액터와의(사용자))
    1. 연관 관계
      • 유스케이스와 엑터간의 상호작용을 표현
      • 실선으로 연결
    2. 의존 관계(포함관계, 확장관계)
      • 포함관계
        • 하나의 유스케이스가 다른 유스케이스의 실행을 전제
        • '포함하는 유스케이스'에서 '포함되는 유스케이스' 방향으로 점선 화살표 연결 
      • 확장관계
        • 특정 조건에 따라 확장 기능 유스케이스를 수행하기도 하는 경우
        • '확장 기능 유스케이스'에서 '확장 대상 유스케이스' 방향으로 점선 화살표 연결
    3. 일반화 관계
      • 유사한 유스케이스, 엑터들을 모아 추상화하여 그룹핑
      • '구체적인 유스케이스'에서 '추상적인 유스케이스' 방향으로 끝부분이 삼각형의 테두리인 실선 화살표로 연결

Stereo Type(스테레오 타입)

  • UML에서 제공하는 기본 요소 외에 추가적인 확장요소를 나타내는 것
  • 길러맷(<< >>) 사이에 적는다.

 

분석 자동화 도구 - CASE(Computer Aided Software Engineering)

장점

  • 구조적인 것들을 그대로 활용 가능
  • 결함, 생략, 불일치 발견이 쉽다.
  • 요구 정보를 추출하고 분석하는 것을 도와준다.
  • 원형이나 프로그램의 개발 및 유지가 용이
  • 반복적인 업무를 벗어나 창의적 업무 가능
  • 점진적 개발 가능
  • 재활용성을 재고시켜 준다.
  • 모든 것들이 그림으로 표현되어 있어 정보시스템의 공유가 쉽다.

 

 

 

2. 화면 설계

2-1. UI 요구사항 확인

8가지 일반적인 소프트웨어 아키텍처 패턴(암기)

  1. 계층화 패턴(레이어드 패턴)
    • 하위 모듈들의 그룹으로 나눌 수 있는 구조화된 프로그램 
    • 일반적인 데스크톱 애플리케이션 , 전자상거래 웹 애플리케이션
      • 장점: 추상화, 캡슐화, 응집 높음, 재사용
      • 단점: 이웃층과의 커뮤니케이션이 제한적
  2. 클라이언트-서버 패턴
    • 클라이언트가 서버에 서비스를 요청하면 서버는 클라이언트에게 적절한 서비스를 제공
    • 이메일, 문서 공유 및 은행 등의 온라인 애플리케이션
      • 장점: 데이터 집중화, 보안
      • 단점: 병목(특정 시간에 몰리면 병목 발생 가능), 비용
  3. 마스터-슬레이브 패턴
    • 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산하고, 슬레이브가 반환한 결과값으로부터 최종 결과값을 계산
    • 마스터는 일을 분배하는 역할을 가지고 있으며, 슬레이브는 전달된 기능을 수행
    • 컴퓨터 시스템에서 버스와 연결된 주변장치, 다중 스레드 응용프로그램
      • 장점: 정확성(서비스의 실행은 설계된 로직대로만 동작)
      • 단점: 마스터에 장애가 발생시 데이터 손실
  4. 파이프-필터 패턴
    • 각 처리 과정은 필터 컴포넌트에서 이루어지며, 처리되는 데이터는 파이프를 동해 흐른다.
    • 이 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있다.
    • 컴파일러
      • 장점: 필터 추가 쉬움(단순성), 재사용, 병렬성
      • 단점: 다른 패턴보다 복잡, 오류발생시 필터 간 데이터 손실 발생 가능, 가장 느린 필터에 의해 효율성 결정
  5. 브로커 패턴
    • 서버는 자신의 기능들을 브로커에 넘겨주며, 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리디렉션한다.
  6. 피어 투 피어 패턴
    • 각 컴포넌트를 피어라고 부른다. 피어는 클라이언트로서 피어에게 서비스를 요청할 수도 있고, 서버로서 각 피어에게 서비스를 제공할 수도 있다.
    • 파일 공유 네트워크, 암호화폐
  7. 이벤트-버스 패턴
    • 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행하며, 리스어는 특정 채널에서 메시지를 구독한다.
    • 이벤트 스트림을 생성하는 이벤트 생산자와 이벤트를 수신 대기하는 이벤트 소비자로 구성
    • 알림 서비스
  8. 모델-뷰-컨트롤러 패턴 = MVC 패턴
    • 모델 - 데이터의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보
    • 뷰 - 사용자가 볼 결과물을 생성하기 위해 모델로부터 전보를 얻어와 사용자에게 정보를 표시
    • 컨트롤러 - 사용자로부터의 입력을 처리하고 모델에 명령을 보냄으로써 모델의 상태를 변경함

 

 

일반적인 소프트웨어 아키텍처 패턴 사용의 장점

  1. 소프트웨어 시스템의 구조를 구성하기 위한 기본 틀이 제시되어 개발 시간을 단축할 수 있다.
  2. 검증된 구조로 개발되어 있어 안정적 개발이 가능하다.
  3. 공통 아키텍처가 공유되므로 의사소통이 간편해진다.
  4. 시스템 구조를 이해하기 쉬워 유지보수도 쉬워진다.

 

소프트웨어 아키텍처 품질요구사항(암기)

  1. 기능성
  2. 이식성
  3. 유지보수성
  4. 효율성
  5. 사용성
  6. 신뢰성

 

 

UI란?

사용자가 시스템을 원활히 사용하도록 돕는 장치/소프트웨어

 

UI의 종류(암기)

  • CLI(Command Line Interface): 텍스트 기반 인터페이스
  • GUI(Graphic User Interface): 그래픽 반응 기반 인터페이스
  • NUI(Natural User Interface): 직관적 사용자 반응 인터페이스(터치, 음성등)

UI의 설계 원칙(암기)

  • 직관성: 누구나 쉽게 이해하고 사용 가능
  • 유효성: 사용자의 목적을 정확하게 달성 가능
  • 학습성: 누구나 쉽게 배우고 익힘 가능
  • 유연성: 사용자의 요구사항을 최대한 수용, 오류를 최소화

UI의 설계 지침: UI 개발과정에서 꼭 지켜야 할 공통의 조건(암기)

  • 사용자 중심: 사용자가 이해하기 편하고 쉽게 사용 가능
  • 일관성: 버튼이나 조작법을 쉬운 사용법으로
  • 단순성: 조작 방법 간단하게 인지적 부담 감소
  • 결과 예측 가능: 기능 보고 예상 가능
  • 가시성: 주요 기능들 메인 화면에 노출
  • 표준화
  • 접근성: 사용자의 직무, 연령, 성별 등 다양한 계층 수용
  • 명확성
  • 오류 발생 해결

 

2-2. UI 설계

UI 화면 설계의 기본 구성 요소

  1. 윈도우
  2. 메뉴
  3. 아이콘
  4. 포인터

UI 화면 설계 도구

  1. 스토리보드
    • 정책, 프로세스, 와이어프레임등 모든 정보가 포함된 설계 산출물
  2. 프로토타입
    • 실제 구현된 것처럼 시뮬레이션할 수 있는 모형
    • 프로그래밍 되지 않았지만 완성품과 유사
  3. 와이어프레임
    • 이해 관계자들의 협의와 공유를 위해 실제 사용자가 보는 화면 위주의 레이아웃을 라인으로만 설계한 문서 - 손그림, 파워포인트
  4. 목업
    • 실제품을 만들어 보기 전, 디자인의 검토를 위해 실물과 비슷하게 시제품을 제작하는 작업의 프로세스, 결과물을 통칭하는 것으로 실제 서비스와 같은 모습이지만 정적이다.

 

Feedback: UI와 관련된 기본 개념 중 하나로, 시스템의 상태와 사용자의 지시에 대한 효과를 보여주어 사용자가 명령에 대한 진행 상황과 표시된 내용을 해석할 수 있도록 도와주는 것

 

완전성: UI 시나리오 문서 작성의 요건중, 누락없이 최대한 빠짐없이 상세하게 기술해야 한다.

 

스토리보드: 전체의 내용을 쉽게 이해할 수 있도록 주요 장면을 그림으로 정리한 계획표

 

감성공학: 인간특성을 파악하려는 연구에 기본을 둔 생체 측정 기술

 

 

3. 애플리케이션 설계

3-1. 공통 모듈 설계-1

UML 구성요소 - 연관관계

: 다중성 - 객체 하나에 몇 개의 객체가 연결되어 있는지를 밝히는 것

  • 1: 정확히 하나
  • 0..1: 0 or 1
  • 0..*: 다수
  • 1..*: 하나 혹은 그 이상

: 집합연관 - 전체 쪽 객체 하나가 부분 쪽 객체들을 소유, has-a 관계

 

UML 구성요소 - 일반화 관계

: 일반화된 사물과 좀 더 특수화된 사물 사이의 관계

 

<컴포넌트component>

: 분명한 역할을 가지고 있는 하드웨어 또는 소프트웨어 조각

  • 독존할 수 있으며 같은 기능을 가진 다른 컴포넌트로 대체 시킬 수 있어야 함
  • 대부분의 컴포넌트는 재사용 가능 하도록 설계. ex) 사용자인터페이스, 뱅킹업무, 창고관리등

 

  1. 모듈의 개념
    • 전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드
    • 자체적으로 컴파일 가능하고 다른 프로그램에서 재사용이 가능하다.
  2. 공통 모듈
    • 여러 기능 및 프로그램에서 공통적으로 사용할 수 있는 모듈 ex) 날짜 처리를 위한 유틸리티 모듈
  3. 공통 모듈에 대한 명세 작성의 원칙
    1. 정확성(Correctness): 해당 기능이 실제 시스템 구현 시 필요한지 여부를 알 수 있도록 정확하게 작성한다.
    2. 명확성(Clority): 해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록 작성한다.
    3. 완전성(Completeness): 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술한다.
    4. 일관성(Consistency): 공통 기능들 간에 상호 충돌이 없도록 작성한다.
    5. 추적성(Traceability): 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성한다.

 

<재사용(Reuse)>

: 개발 시간 및 비용 절감을 위하여 이미 검증된 기능을 파악하고 재구성하여 시스템에 응용하게 위해 적합하게 최적화시키는 작업이다.

  1. 함수와 객체 재사용
  2. 컴포넌트 재사용
  3. 애플리케이션 재사용

 

<모듈화(Modularity)>

  1. 모듈화 개념: 프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화함으로써 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 용이하게 하는 기법을 의미한다.
  2. 모듈화 필요성: 모듈의 크기가 너무 작아서 모듈 개수가 많아지면 모듈 간의 통합 비용이 많이 들고, 모듈의 크기가 너무 크면 모듈 간의 통합 비용이 상대적으로 줄어드는 대신 모듈 하나를 개발하는 데 드는 비용이 커진다.

<응집도 Cohesion> (순서까지 암기)

: 응집도는 모듈 내부에서 구성 요소 간에 밀접한 관계를 맺고 있는 정도로 평가되며, 응집도가 높을수록 필요한 요소들로 구성되어 있고 낮을수록 관련이 적은 요소들로 구성되어 있다.

 

 

<결합도 Coupling> (순서까지 암기)

: 모듈과 모듈 간에 어느 정도 관련성이 있는지를 나타내며, 관련이 적을수록 모듈의 독립성이 높아 모듈 간 영향이 적어지게 된다.

3-2. 공통 모듈 설계-2

(암기)

<순차Sequece 다이어그램 모델링>

  • 객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링 하는 것
  • 다이어그램의 수직 방향이 시간의 흐름을 나타냄
  • 객체 사이의 기능, 순서, 시간을 명확하게 표현
  • 객체들 사이의 이동 경로를 시간 흐름으로 보려면 Sequence 다이어그램이 적절
  • 메시지(데이터)의 흐름을 보려면 통신 다이어그램이 적절

 

코드(암기): 데이터를 사용 목적에 따라 그룹으로 분류 및 나열하고 특정 자료의 선별 및 추출 작업을 용이하게 하기 위해 부여한 숫자, 문자 및 기호 체계이다.

3-3. 객체 지향 설계

디자인 패턴(암기)

: 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법.

 

 

<GoF 디자인 패턴 분류>

  1. 생성(Creational)패턴: 객체 생성에 관련된 패턴
    • 간단한 블록의 코드로 여러가지 다양한 객체를 생성
    • 실행 시간에 객체의 다양한 버전을 생성
    • 생성한 객체에 제한을 가함
  2. 구조(Structural)패턴: 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
    • 더 큰 구조를 형성하기 위하여 클래스와 객체를 어떻게 합성하는가?
    • 상속 기법 이용(인터페이스, 구현을 합성)
    • 구조화 패턴(새로운 기능을 위해 객체 구성, 런타임에 객체 구조 변경, 유연성 + 확장성)
  3. 행위(Behavioral)패턴: 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴
    • 반복적으로 일어나는 객체들의 상호작용을 패턴화해 놓은 것
    • 객체들 간의 알고리즘이나 역할 분담에 관련된 것

암기(생성, 구조 암기 그 이외에 것들은 행위)

 

 

 

 

 

4. 인터페이스 설계

 

4-1. 인터페이스 요구사항 확인 / 인터페이스 대상 식별

 <모델링 언어>

  1. 구조적 방법론: 자료흐름도(DFD), 자료사전(DD), 소단위 명세서
  2. 정보공학 방법론: 개체-관련 다이어그램(ERD, Entity-Relationship Diagram)
    • 개체
      • 관계 모델을 이용해 현실 세계를 개념적으로 모델링한 결과물을 그림으로 표현한 것
      • 사각형으로 표현하고 사각형 안에 이름을 표기
    • 속성
      • 개체나 관계가 가지고 있는 고유의 특성
      • 타원으로 표현하고 타원 안에 이름을 표기
    • 관계
      • 개체와 개체가 맺고 있는 의미 있는 연관성
      • 마름모로 표현
  3. 객체지향 방법론: UML, 유스케이스 다이어그램

 

<요구사항 문서화>

  • 비정형 명세기법
    • 자연어를 기반
    • 작성하기 쉬우나, 애매모호한 표현으로 달리 해석 위험
  • 정형 명세기법
    • 수학적 원리와 표기법
    • Z정형 명세 언어

 

<요구 사항 검증 방법> (암기)

(1) 요구 사항 검토(Requirements Review): 수작업 분석

암기

(2) 프로토타이핑(Prototyping)

: 개발할 시스템을 약식으로 개발하여 최종 사용자나 고객을 대상으로 시연하면서 요구사항을 확인

 

(3) 테스트 설계

: 테스트케이스를 생성하여 추후 요구 사항이 현실적으로 가능한지 검토

 

(4) CASE(Computer Aided Software Engineering) 도구 활용

  • 요구사항 변경 사항을 추적하고 분석 및 관리 용이
  • 분산된 환경에서 다양한 이해관계자가 공동작업 가능
  • 테스트 연계 및 결함 관리 등의 기능을 제공
    • HIPO(범위가 더 넓음. 기호와 도표 사용 하향식 소프트웨어 개발을 위한 문서화 도구)

 

 

인터페이스 대상 식별

<인터페이스 시스템>

: 시스템 인터페이스를 구성하는 시스템은 송신 시스템과 수신 시스템이 있고, 연계 방식에 따라 중계 서버를 둘 수 있다.

 

  • 송신 시스템
    • 연계할 데이터를 DB와 APP으로부터 연계 테이블 또는 파일 형태로 생성하여 송신
  • 수신 시스템
    • 수신한 연계 테이블 또는 파일의 데이터를 형식에 맞게 변환하여 DB에 저장하거나 APP에서 활용 가능하게 제공
  • 중계 서버
    • 송신 시스템과 수신 시스템 사이에서 데이터를 송수신하고 모니터링 한다. 
    • 보안 강화 및 다중 플랫폼 지원 

 

<소프트웨어 설계>

  • 상위 설계
    • 아키텍처 설계
    • 데이터 설계
    • 인터페이스 정의
    • 사용자 인터페이스 설계
  • 하위 설계
    • 모듈 설계
    • 자료구조 설계
    • 알고리즘 설계

 

 

4-2. 인터페이스 상세 설계

<내,외부 송 수신 연계방식>

  • 직접 연계 방식
    • 장점: 중간 매개체가 없어 연계 처리 속도가 빠르고, 구현이 단순하며 개발 비용과 개발 기간이 짧다.
    • 단점: 송신 시스템과 수신 시스템 간의 결합도가 높아서 시스템 변경에 민감하다.
               보안을 위한 암,복호화 처리와 비즈니스 로직 구현을 인터페이스별로 작성해야 한다.
               전사 시스템 인터페이스에 대한 통합 환경 구축이 어렵다.
  • 간접 연계 방식
    • 장점: 송수신 처리 및 현황을 모니터링하고 통제하는 연계 서버를 활용하는 방식으로 다양한 환경 갖는 시스템들을 연계하고 통합 관리할 수 있으며, 인터페이스 변경 시에도 유연하게 대처 가능, 보안이나 업무 처리 로직 반영 용이.
    • 단점: 인터페이스 아키텍처와 연계 절차가 복잡하고 연계 서버로 인한 성능 저하, 개발 및 테스트 기간이 오래 걸림.

 

 

<시스템 연계 기술>(암기)

 

 

 

<설계 기법 중 하향식 설계 방법과 상향식 설계 방법에 대한 비교 설명>

  • 하향식 설계
    • 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.
    • 레벨이 낮은 데이터 구조의 세부사항은 설계 초기 단계에서 필요하다.
    • 테스트 초기부터 사용자에게 시스템 구조 보여줄 수 있다.
    • 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
    • 모듈이 통합될 때마다 테스트 실시
  • 상향식 설계
    • 상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.
    • 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 방법