HYS

HYS

ㅇㅅㅇ

정보처리기사 정리 - SW 설계

SW 설계

아키텍쳐 패턴

  • Layer Pattern(계층) : 상하위 계층구조로 이루어진 패턴으로 위아래로만 상호작용 함
  • Client-Server Pattern : 1개의 Server와 여러개의 Client로 구성된 아키텍쳐 패턴
  • Pipe-filter Pattern : Sub 시스템이 입력받아 처리 후 다음 시스템으로 전송하는 패턴
  • MVC Pattern :
    • Model : 서브시스템의 핵심 기능과 데이터를 보관한다.
    • View : 사용자에게 정보를 표시한다.
    • Controler : 사용자로붙터 받은 입력을 처리한다.

디자인 패턴

디자인 패턴은 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

GOF(Gang of Four)

생성패턴 5개, 구조 패턴 7개, 행위 패턴 11개로 총 23개로 구성된다.

  • 생성 패턴(Creational Pattern) : 객체의 생성과 관련된 패턴
    • 추상 팩토리(Abtract Factory) : 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관 의존하는 객체들의 그룹으로 추상적으로 표현
    • 빌더(Builder) : 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성한다.
    • 팩토리 메소드(Factory Method) : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
    • 프로토타입(Prototype) : 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
    • 싱글톤(Singleton) : 하나의 객체를 생성하면 생선된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조는 안되는 디자인 패턴. 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화할 수 있다.
  • 구조 패턴(Structual Pattern) : 클래스나 객체를 조합하여 더 큰 구조로 만드는 패턴
    • 어댑터(adapter) : 호환성이 없는 ㅡ클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환하는 패턴
    • 브리지(Bridge) : 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구선한 패턴
    • 컴포지트(Composite) : 여러 객체를 가진 복합 객체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴
    • 데코레이터(Decorator) : 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
    • 파사드(Facade) : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
    • 플라이웨이트(Flyweight) : 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용해 메모리를 절약하는 패턴
    • 프록시(Proxy) : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 하는 패턴
  • 행위 패턴(Behavioral Pattern) : 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
    • 책임연쇄(Chain of Responsibility) : 요청을 처라할 수 있는 객체가 둘이상 존자해여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
    • 커멘드(Command) : 요청을 객체의 현태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청해 필요한 정보를 저장하거나 로그에 남기는 패턴
    • 인터프리터(Interpreter) : 언어의 문법 표현을 정의하는 패턴
    • 반복자(Iterator) : 자료구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
    • 중재자(Mediator) : 수많은 객체들 간의 복잡한 상효작용을 캡슐화하여 객체로 정의하는 패턴
    • 메멘토(Memento) : 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
    • 옵저버(Observer) : 한 객체의 상태가 변화하면 객체에 상속되어있는 다른 객체들에게 변화된 상태를 전달하는 패턴
    • 상태(State) : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
    • 전략(Strategy) : 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
    • 템플릿 메소드(Template Method) : 상위클래스에서 골격을 정의하고, 하위 클래스에서 세부처리를 구체화하는 구조의패턴
    • 방문자(Visitor) : 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴

모듈(Module)

모듈의 개요

  • 모듈화를 통해 분리된 시스템의 각 기능들로, 서브루틴, 서브시스템, SW 내의 프로그램, 작업 단위등과 같은 의미로 사용된다.
  • 단독으로 컴파일 가능하며 재사용할 수 있다.
  • 모듈의 독립성은 결합도(Coupling)와 응집도(Cohesion)에 의해 측정되며 독립성을 높이려면 모듈의 결합도는 약하게 응집도는 강하게 모듈의 크기는 작게 만들어야 한다.

결합도(Coupling)

  • 내공외제스자(강 -> 약)
  • 내용결합도, 공유결합도, 외부결합도, 제어결합도, 스템프결합도, 자료결합도

응집도(Cohesion)

  • 우논시절교순기(약 -> 강)
  • 우연적응집도, 논리적응집도, 시간적응집도, 절차적응집도, 교환적응집도, 순차적응집도, 기능적응집도

요구사항

요구사항 정의

요구사항은 SW가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 필요한 제약조건등을 나타낸다.

  • 요구사항 유형
    • 일반적 기술 내용
      • 기능 요구사항
      • 비기능 요구사항
    • 기술관점 및 대상의 범위
      • 사용자 요구사항
      • 시스템 요구사항
  • 요구사항 개발 프로세스!!
    • 타당성 조사
    • 도출 : 유스케이스, 프로토타이핑, 설문 인터뷰 등
    • 분석
    • 명세
    • 확인
  • 요구사항 확인과 검증
    • 확인(Validation) : 고객의 요구사항 만족
    • 검증(Verification) : 기능이 정확히 수행하는지 확인

요구사항 분석

개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위해 사용

  • 요구사항 분류
  • 개녕 모델링
  • 요구사항 할당
  • 요구사항 협상
  • 정형분석

요구사항 확인 기법

요구사항 개발과정을 거처 문서화된 요구사항 관련 내용 확인, 검증

  • 요구사항 검토
  • 프로토타이핑
  • 모델검증
  • 인수테스트

UML(Unitied Modeling Language)

시스템 분석 설계 구현등 시스템 개발 과정에서 시스템 개발자와 고객, 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

  • 사물 : 구조사물, 행동사물, 그룹사물, 주해사물

  • 관계 : 연관(Assosiation), 집합(Aggregation), 포함(Composition), 일반화(Generalizaiton), 의존(Depending), 실체화(Relization)

    UML Relation

  • 구조적 다이어그램 : 클래스, 객체, 컴포넌트, 배치, 복합체, 패키기
  • 행위 다이어그램 : 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용, 타이밍

클래스 다이어그램

  • 구성요소
    1. 클래스 : 각각의 객체들이 갖는 속성과 오퍼레이션
      • 클래스 이름
      • 속성 : 클래스의 상태 또는 정보
      • 오퍼레이션 : 연산, 클래스 수행할 수 있는 함수
    2. 제약조건
    3. 관계 : 연관, 집합, 포함, 일반화, 의존
  • 클래스의 접근 제어자
    1. Public +
    2. Private -
    3. Protected #
    4. Package ~
  • 관계
    • 1, n, 0..1, 0,,*, 1..*, n..*, n..m

유스케이스 다이어그램

사용자와 외부 시스템이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자 관점에서 표현

  • 구성요소
    1. 시스템/시스템 범위
    2. 액터(시스템과 상호작용하는 외부요소)
      • 주액터
      • 부액터
    3. 유스케이스(서비스 또는 기능)
    4. 관계
      • 포함관계 : 두개 이상의 유스케이스에 공통으로 적용하는 기능을 새로운 유스케이스로 만들 경우 («include»)
      • 확장관계 : 유스케이스의 기능이 확대 («extends»)
      • 일반화 : 유사한 유스케이스 또는 액터를 그룹으로 묶거나 일반적으로 만들 때

활동 다이어그램

자료 흐름도와 유사한 것으로 사용자 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현

  • 구성요소
    1. Action : 더 이상 분해할 수 없는 단일 작업
    2. Activity : 몇개의 액션으로 분리될 수 있는 작업
    3. 제어흐름 : 실행의 흐름, 화살표
    4. 시작노드 : 하나의 다이어그램에는 1개의 시작점(점)
    5. 종료노드 : Activity의 흐름 종료(◎)
    6. 조건노드 : 제어흐름(입력 1개 출력 여러개)
    7. 병합노드 : 여러경로를 합쳐 하나의 경로로 만듬(입력 여러개 출력 1개)
    8. 포크노드 : Activity의 흐름을 분리(입력1개 출력 여러개)
    9. 조인노드 : 분리된 Activity를 합침(입력 여러개, 출력 1개)
    10. 스웜레인 : Activity를 수행하는 주체

시퀀스 다이어그램

시스템이나 객체들이 메시지를 주고 받으며 시간의 흐름에 따라 상호작용하는 과정 표현

  • 구성요소
    1. Actor : 외부시스템, 사람
    2. 객체(Object) : 메시지 주고 받는 주체
    3. 라이프 라인 : 객체가 메모리에 존재하는 기간
    4. 활성상자 : 객체가 메시지를 주고 받으며 구동됨을 표시
    5. 메시지 : 동기, 비동기, 생성, 응답
    6. 객체 소멸
    7. 프레임

커뮤니케이션 다이어그램

시퀀스 다이어그램 처럼 메시지를 주고 받으며 시간의 흐름에 따라 상호작용 추가로, 객체를 연결하는 링크가 추가되어 객체 사이의 관계가 있다.

  • 구성요소
    1. Actor
    2. Object
    3. Link
    4. Message

상태 다이어그램

객체들 사이에 발생하는 이벤트에 의한 객체 들의 상태 변화 표시

럼바우(Rumbaugh)의 객체제향 분석

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

  • 객체 모델링
  • 동적 모델링
  • 기능 모델링

참고