Post

정보처리기사 1과목 소프트웨어 설계 핵심노트

시스템의 구성요소

  • 입력 (Input)
    처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
  • 처리 (Process)
    입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
  • 출력 (Output)
    처리된 결과를 시스템에서 산출하는 것
  • 제어 (Control)
    자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
  • 피드백 (Feedback)
    출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것

시스템 연계 기술

  • DB링크
    • 데이터베이스에서 제공하는 DB링크 객체를 이용한다.
    • 수신측에서 DB링크를 생성하고 송신측에서 해당 DB링크를 직접 참조하는 방식이다.
  • DB 커넥션
    • 수신측의 WAS에서 송신측 데이터베이스로 연결하는 DB Connection Pool을 생성한다.
  • API/OpenAPI
    • 송신측의 데이터베이스에서 데이터를 가져와 제공하는 응용 프래그래밍 인터페이스 프로그램이다.
  • JDBC
    • 수신측의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 데이터베이스와 연결한다.
    • DBMS 유형, DBMS 서버 IP와 Port, DB Instance 정보가 필요하다.
  • 하이퍼링크
    • 웹 응용에서 하이퍼링크(Hyper Link)를 이용한다.
  • 소켓
    • 서버는 통신을 위한 Socket을 생성하여 Port를 할당한다.
    • 클라이언트의 통신 요청 시 클라이언트와 연결하고 통신하는 네트워크 기술이다.

검토 회의

  • 워크 스루
    요구사항 명세서를 미리 배포하여 사전 검토 오류 초기 검출
  • 동료 검토
    2-3명의 리뷰형태, 작성자가 설명하고 이해관계자들이 설명을 들음
  • 인스펙션
    명세서 작성자를 제외한 다른 검토 전문가들이 확인하며 결함 발견

요구사항 개발 프로세스

요구사항을 도출해야 분석하고, 분석해야 자세히 쓸 수 있고(명세), 명세를 검토해야 한다.

  1. 도출 (Elicitation)
  2. 분석 (Analysis)
  3. 명세 (Specification)
  4. 확인 (Validation)

코드 설계

  • 연상코드 (Mnemonic Code)
    명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용
  • 블록코드 (Block Code)
    공통성이 있는 것끼리 블록으로 구분
  • 순차코드 (Sequence Code)
    순차적으로 일련번호를 부여
  • 표의 숫자 코드 (Significant Digit Code)
    길이 넓이 부피 등 항목의 성질의 물리적인 수치를 그대로 코드에 적용
  • 그룹 분류 코드 (Group Classification Code)
    구분 코드를 대분류, 중분류, 소분류 세분화
  • 10진 코드 (Decimal Classification Code)
    십진수 한 자리씩 구분
  • 약자 코드 (Letter Code)
    단위의 약자를 사용
  • 끝자리 분류 코드 (Final Digit Code)
    다른 종류의 코드와 조합, 코드의 끝에 붙여 표현

데이터 흐름도 (Data Flow Diagram)

버블 (Bubble) 차트라고도 한다.

구조적 분석 기법에 이용된다.

요소는 화살표, 원, 사각형, 직선(단선/이중선) 으로 표시된다.

  • 프로세스 (Process) →
  • 자료 흐름 (Flow) → 화살표
  • 자료 저장소 (Data Store) → 평행선
  • 단말 (Terminal) → 사각형

GoF(Gang of Four)

  • 생성 패턴

    객체 인스턴스를 생성하는 패턴

    • 추상 팩토리 (Abstract Factory)
      • 구체적인 클래스를 지정하지 않고 인터페이스를 통해 서로 연관되는 객체들을 그룹으로 표현한다.
    • 빌더 (Builder)
      • 복합 객체의 생성과 표현을 분리하여 동일한 생성 절차에서도 다른 표현 결과를 만들어낼 수 있다.
    • 팩토리 메서드 (Factory Method)
      • 객체 생성을 서브클래스로 위임하여 캡슐화한다.
    • 프로토타입 (Prototype)
      • 원본 객체를 복사함으로써 객체를 생성한다.
    • 싱글톤 (Singleton)
      • 어떤 클래스의 인스턴스는 하나임을 보장하고 어디서든 참조할 수 있도록 한다.
  • 구조 패턴

    클래스와 객체를 조합해 더 큰 구조로 만들 수 있게 해주는 패턴

    • 어댑터 (Adapter)
      • 클래스의 인터페이스를 다른 인터페이스로 변환하여 다른 클래스가 이용할 수 있도록 한다.
    • 브릿지 (Bridge)
      • 구현부에서 추상층을 분리하여 각자 독립적으로 확장할 수 있게 한다.
    • 컴포지트 (Composite)
      • 객체들의 관계를 트리 구조로 구성하여 복합 객체와 단일 객체를 구분없이 다룬다.
    • 데코레이터 (Decorator)
      • 주어진 상황 및 용도에 따라 어떤 객체에 다른 객체를 덧붙이는 방식
    • 퍼싸드 (Facade)
      • 서브시스템에 있는 인터페이스 집합에 대해 하나의 통합된 인터페이스 제공
    • 플라이웨이트 (Flyweight)
      • 크기가 작은 여러 개의 객체를 매번 생성하지 않고 가능한 공유할 수 있도록하여 메모리를 절약한다.
    • 프록시 (Proxy)
      • 접근이 어려운 객체로의 접근을 제어하기 위해 객체의 SurrogatePlaceholder를 제공한다.
  • 행위 패턴

    클래스와 객체들이 상호작용하는 방법과 역할을 분담하는 방법을 다루는 패턴

    • 책임 연쇄 (Chain of Responsibility)
      • 요청을 받는 객체를 연쇄적으로 묶어 요청을 처리하는 객체를 만날때까지 객체 Chain을 따라 요청을 전달한다.
    • 커맨드 (Command)
      • 요청을 객체의 형태로 캡슐화하여 재사용하거나 취소할 수 있도록 저장한다.
    • 인터프리터 (Interpreter)
      • 특정 언어의 문법 표현을 정의한다.
    • 반복자 (Iterator)
      • 내부를 노출하지 않고 접근이 잦은 어떤 객체의 원소를 순차적으로 접근할 수 있는 동일한 인터페이스를 제공한다.
    • 중재자 (Mediator)
      • 한 집합에 속해있는 객체들의 상호작용을 캡슐화하여 새로운 객체로 정의한다.
    • 메멘토 (Memento)
      • 객체가 특정 상태로 다시 되돌아올 수 있도록 내부 상태를 실체화한다.
    • 옵저버 (Observer)
      • 객체 상태가 변할 때 관련 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 한다.
    • 상태 (State)
      • 객체의 상태에 따라 동일한 동작을 다르게 처리해야할 때 사용한다.
    • 전략 (Strategy)
      • 동일 계열의 알고리즘군을 정의하고 캡슐화하여 상호교환이 가능하도록 한다.
    • 템플릿 메소드 (Template Method)
      • 상위클래스는 알고리즘의 골격만을 작성하고 구체적인 처리는 서브클래스로 위임한다.
    • 방문자 (Visitor)
      • 객체의 원소에 대해 수행할 연산을 분리하여 별도의 클래스로 구성한다.

자료사전 표기법

기호 (Symbol)의미 (Meaning)
=정의
+연결
( )생략
[ ]선택
{ }반복
**설명(주석)

사용자 인터페이스 (UI)

UI 구분

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

UI 설계 원칙

  • 직관성
    누구나 쉽게 이용하고 쉽게 사용할 수 있어야 함
  • 유효성
    정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작
  • 학습성
    초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작
  • 유연성
    사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작

미들웨어

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

미들웨어 솔루션의 유형

  • WAS (Web Application Server)

    웹 애플리케이션 서버

    • 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리한다.
    • 웹 환경을 구현하기 위한 미들웨어
  • MOM (Message Oriented Middleware)

    메시지 지향 미들웨어

    • 비동기형 메시지를 전달하는 방식의 미들웨어
    • 온라인 업무보다 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용된다.
    • 다소 느리고 안정적인 응답을 필요로 하는 경우에 많이 사용된다.
    • 송신측과 수신측의 연결 시 메시지 큐를 활용하는 방법이 있다.
  • TP-Monitor (Transaction Processing Monitor)
    • 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션을 처리 및 감시하는 미들웨어
    • 사용자 수가 증가하더라도 빠른 응답속도를 유지해야 할 경우 주로 사용된다.
  • DB (DataBase)
    • 데이터베이스 벤더에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어
    • DB를 사용해 시스템을 구축하는 경우 보통 2-Tier 아키텍쳐라고 한다.
  • RPC (Remote Procedure Call)
    • 응용 프로그램이 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 미들웨어
  • ORB (Object Request Broker)
    • 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한다.
    • 최근에는 TP-Monitor 의 장점인 트랜잭션 처리와 모니터링 등을 추가로 재현한 제품도 있다.

협약에 의한 설계 (Design by Contract)

클래스에 대한 여러 가정을 공유하도록 명세한 것

  • 선행조건 (precondition)
  • 결과조건 (postcondition)
  • 불변조건 (invariant)

UML (Unified Modeling Language)

UML 이란?

  • 시스템 개발 과정 중 상호 간의 원활한 의사소통을 위한 표준화된 객체지향 모델링 언어
  • Rumbaugh (OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합한 모델링 언어
  • OMG (Object Management Group) 에서 표준으로 지정되었다.
  • 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있다.

UML 도입효과

  • 개발 기획과 산출물에 대한 확인
  • 프로그램 개발이라는 행위에 대해 전문가와 비전문가가 서로 대화할 수 있는 도구

UML 관계

  • 연관 관계 (Association)
    • 2개 이상의 사물이 서로 관련되어 있음을 뜻함
    다중도의미
    11개의 객체와 연관
    nn개의 객체와 연관
    0..1없거나 1개
    0..* or *없거나 다수
    1..*적어도 1개
    n..*적어도 n개
    n..mn개에서 m개
  • 집합 관계 (Aggregation)
    • 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현
      • 포함하는쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적
      • 포함되는쪽에서 포함하는 쪽으로 속이 빈 마름모꼴로 표현한다.
  • 포함 관계 (Composition)
    • 포함하는 사물의 변화포함되는 사물에게 영향을 미치는 관계표현
      • 포함하는쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적일 수 없고 생명주기를 함께한다.
      • 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모꼴로 표현한다.
  • 일반화 관계 (Generalization)
    • 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
      • 예시로 사람은 남자와 여자보다 더 일반적인 표현, 반대의 경우는 구체적인 표현
      • 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표로 표현한다.
  • 의존 관계 (Dependency)
    • 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간동안만 연관을 유지하는 관계
      • 소유관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미친다.
      • 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타난다.
      • 영향을 받는(제공자) 쪽으로 점선 화살표로 연결하여 표현한다.
  • 실체화 관계 (Realization)
    • 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
      • 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
      • 사물에서 기능 쪽으로 속이 빈 점선 화살표로 표현한다.

UML 구성요소

  • 사물 (Things)
    • 모델을 구성하는 가장 중요한 기본 요소
  • 관계 (Relationships)
    • 사물과 사물 사이의 연관성을 표현하는 것
  • 다이어그램 (Diagrams)
    • 사물과 관계를 도형으로 표현
    • 정적 모델링은 구조적 다이어그램 (Structural Diagram)

      다이어그램내용
      래스 다이어그램
      (Class Diagram)
      - 클래스와 클래스가 가지고 있는 속성, 클래스 사이의 관계를 표현함
      - 시스템 구조를 파악하고 문제점 도출 가능
      체 다이어그램
      (Object Diagram)
      - 클래스에 속한 사물들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
      - 럼바우 객체지향 분석 기법 에서 객체 모델링에 활용
      포넌트 다이어그램
      (Component Diagram)
      - 실제 구현 모델인 컴포넌트 간의 관계, 인터페이스 를 표현
      - 구현 단계 에서 사용
      치 다이어그램
      (Deployment Diagram)
      - 결과물, 프로세스, 컴포넌트물리적 요소 들의 위치를 표현
      - 노드와 의사소통 (통신) 경로를 표현 « 구현 단계 에서 사용
      합체 구조 다이어그램
      (Composite Structure Diagram)
      - 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
      키지 다이어그램
      (Package Diagram)
      - 유스케이스나 클래스 등의 모델 요소들을 그룹화 한 패키지들의 관계를 표현
    • 동적 모델링은 행위 다이어그램 (Behavioral Diagram)

      다이어그램내용
      스케이스 다이어그램
      (Use Case Diagram)
      - 사용자의 요구 분석, 기능 모델링 작업에 사용
      - 사용자와 사용 사례로 구성 (여러 형태의 관계로 이루어짐)
      퀀스 다이어그램
      (Sequence Diagram)
      - 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
      뮤니케이션 다이어그램
      (Communication Diagram)
      - 순차 다이어그램과 동일하지만 객체들 간의 연관까지 표현
      태 다이어그램
      (State Diagram)
      - 변화 혹은 상호작용에 따라 객체가 어떻게 변화하는지 표현
      - 럼바우 객체지향 분석 기법 에서 동적 모델링 에 활용
      동 다이어그램
      (Activity Diagram)
      - 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른처리의 흐름을 순서에 따라 표현
      이밍 다이어그램
      (Timing Diagram)
      - 객체상태 변화시간 제약 을 명시적으로 표현

주요 UML 다이어그램

  1. 유스케이스 다이어그램 (사용사례 다이어그램)

    유스케이스 다이어그램 이란?

    • 사용자의 관점(View) 에서 표현하는 다이어그램이다. 기능 모델링 작업에 사용된다.
    • 외부 요소와 시스템 간의 상호 작용을 확인할 수 있다.
    • 사용자의 요구사항을 분석하기 위한 도구로 사용된다.
    • 사용자의 범위를 파악할 수 있다.
    • 액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안된다.

    유스케이스 다이어그램의 구성요소

    • 시스템 (System)
      • 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현함
    • 액터 (Actor)
      • 시스템과 상호작용을 하는 모든 외부요소로, 사람이나 외부시스템을 의미한다.
      • 외부요소 이므로 시스템 밖에 표현한다.
      • 액터는 주액터와 부액터가 있다
        • 주액터(사용자 액터): 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당함
        • 부액터(시스템 액터): 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관 등이 될 수 있음
    • 유스케이스 (Usecase)
      • 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것
    • 관계 (Relation)
      • 유스케이스 다이어그램에서의 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있다.
      • 종류는 연관관계(Association), 의존관계(Dependency), 일반화관계(Generalization) 가 있다.
      • 의존관계는 포함(Include), 확장(Extend) 로 나눠진다.

      연관관계(Association): 유스케이스와 액터간의 상호작용이 있음을 표현
      포함관계(Include): 시스템의 기능이 별도의 기능을 포함
      확장관계(Extend): 기본 Usecase 수행 시 특별한 조건을 만족할 때 수행할 Usecase
      일반화관계(Generalization): 하위 Usecase와 Action이 상위 Usecase와 Actor에게 기능 및 역할을 상속받음

  2. 시퀀스 다이어그램

    시퀀스 다이어그램 이란?

    • 객체 간의 동적 상호작용을 메시지 흐름으로 표현(시간 개념을 중심으로 모델링) 한 다이어그램
    • 일반적으로 다이어그램의 수직 방향이 시간의 흐름을 나타낸다.
    • 회귀 메시지(Self-Message), 제어블록(Statement block) 등으로 구성된다.

    시퀀스 다이어그램의 구성요소

    • 액터 (Actor)
      시스템으로부터 서비스를 요청하는 외부요소
    • 객체 (Object)
      메세지를 주고받는 주체
    • 생명선 (Lifeline)
      객체가 메모리에 존재하는 기간, 객체 아래쪽에 점선을 그어 표현
    • 메세지 (Message)
      객체가 상호 작용을 위해 주고받는 메세지
    • 실행 상자 (Active Box)
      객체가 메세지를 주고받으며 구동되고 있음을 표현
  3. 클래스 다이어그램

    클래스 다이어그램 이란?

    • 객체지향 모델링 시 구성요소간 정적인 관계를 표현한 다이어그램이다.

    클래스 다이어그램의 구성요소

    • 클래스 이름 (Class Name)
    • 속성 (Attribute)
    • 연산 (Operation)
    • 접근 제어자 (접근 제한자)

      -클래스 내부 접근만 허용 (Private)
      +클래스 외부 접근을 허용 (Public)
      #동일 패키지, 파생 클래스에서 접근 가능 (Protected)
      ~동일 패키지 클래스에서 접근 가능 (Default)

UML 확장 모델 기호

UML의 기본적 요소 이외에 새로운 요소를 만들어 내기 위한 확장 매커니즘

  • << >> 스테레오 타입 객체

애자일 방법론

  • 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론
  • 적은 규모의 개발 프로젝트에 적용하기 좋다.
  • XP (eXtreme Programming) 과 SCRUM 이 제일 많이 통용됨

애자일의 기본원칙

  • 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시한다.
  • 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.
  • 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다.
  • 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시한다.

애자일 방법론의 종류

  • 익스트림 프로그래밍
  • 스크럼
  • 크리스털 패밀리
  • 기능중심 개발

익스트림 프로그래밍이란?

XP (eXtreme Programming)

  • 대표적인 애자일 방법론 중 하나
  • 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접했을 때 적절한 방법
  • 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리경험을 최대한 끌어 올리는 것
  • 개발 문서보다는 소스코드에 중점을 둔다.

익스트림 프로그래밍의 5가지 가치

  • 용기 (Courage)
  • 단순성 (Simplicity)
  • 커뮤니케이션 (Communication)
  • 피드백 (Feedback)
  • 존중 (Respect)

스크럼 (Scrum) 관련 용어

  • 스크럼 마스터 (Scrum Master)
    • 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡는다.
  • 제품 백로그 (Product Backlog)
    • 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍쳐 정의 등이 포함될 수 있다.
  • 스프린트 (Sprint)
    • 실제 개발을 2~4주간 하는 과정
    • 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당 개발자에게 할당한다.
    • Task는 할 일, 진행중, 완료의 상태로 구성된다.
  • 속도 (Velocity)
    • 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

요구사항 분석 (requirements analysis)

  • 비용과 일정에 대한 제약설정
  • 타당성 조사
  • 요구사항 정의 문서화

기능적 (Functional) 요구사항

  • 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항

비기능적 (Nonfunctional) 요구사항

  • 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 실제 수행에 보조적인 요구사항

요구사항 명세기법

정형 명세기법

  • 수학적 기호, 정형화된 표기법으로 작성
  • 정확하고 간결하게 표현할 수 있지만 표기법이 어려워 사용자가 이해하기 어렵다.
  • 일관성이 있다.
  • Z, VDM, Petri-Net(모형기반)

비정형 명세기법

  • 일반 명사, 동사 등의 자연어를 기반으로 작성한다.
  • 이해가 쉽다.
  • 일관성이 떨어진다.
  • FSM, Decision Table, ER모델링, State chart(SADT), UseCase

HIPO (Hierarchy Input Process Output)

  • 하향식 소프트웨어
  • 차트 종류에는 가시적 도표, 총체적 도표, 세부적 도표 가 있다.
  • 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
  • 보기 쉽고 이해하기 쉽다.

객체지향 프로그래밍 (OOP)

객체지향이란?

  • 현실 세계를 그대로 모형화
  • 소프트웨어 개발 시 객체들을 조립해 작성 가능
  • 소프트웨어 재사용 및 확장을 용이, 유지보수가 쉬움

객체지향의 주요 요소

  • 객체
    • 기억, 판단, 행위 능력을 갖는 단위 시스템
  • 속성
    • 객체가 가지고 있는 특성, 현재 상태(오브젝트 상태) 를 의미한다.
  • 클래스
    • 데이터를 추상화하는 단위
    • 공통된 속성과 연산(행위) 를 갖는 객체의 집합
    • 인스턴스는 클래스에 속한 각 객체를 의미한다.
  • 메시지

    객체 간의 통신

    • 객체들 간의 상호작용을 하는데 사용되는 수단
    • 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구사항
  • 메소드

    객체의 행위

    • 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행한다.

객체지향의 주요 개념

  • 캡슐화 (Encapsulation)
    • 데이터와 데이터를 처리하는 함수를 하나로 묶은 것이다
    • 캡슐화된 객체의 세부 내용이 은폐되어 변경이 발생해도 오류의 파급효과가 적다
    • 캡슐화된 객체들은 재사용이 용이하다.
    • 인터페이스가 단순해지고 객체간의 결합도가 낮아진다.
  • 상속성 (Inheritance)
    • 이미 정의된 상위 클래스(부모 클래스) 의 모든 속성과 연산을 하위 클래스(자식 클래스) 가 물려받는 것
    • 소프트웨어의 재사용 을 높이는 중요한 개념

    다중상속성
    한개의 클래스가 2개 이상의 클래스로부터 속성과 연산을 상속받는 것

  • 다형성 (Polymorphism)
    • 하나의 메세지에 대해 각 객체가 갖고 있는 고유한 방법대로 응답하는 것을 의미한다.
    • 하나의 클래스나 메소드가 다양한 방식으로 동작이 가능한 것을 의미한다.
    • 오버로딩
      • 한 클래스 내에서 메서드의 이름은 동일하지만 매개변수의 수나 타입을 다르게 하여 중복정의 및 재정의 하는것
    • 오버라이딩
      • 상속관계에서만 발생
      • 슈퍼클래스의 메서드를 서브클래스에서도 동일한 메서드를 재정의 하는것
  • 정보은닉 (Information Hiding)
    • 캡슐화에서 가장 중요한 개념으로 다른 객체에 자신의 정보를 숨기는 것
    • 연산만을 통해 접근을 허용한다.
    • 각 객체의 수정이 다른 객체에 주는 Side Effect를 최소화하는 기술
  • 추상화 (Abstraction)
    • 불필요한 부분을 생략, 객체 속성 중 가장 중요한 것에 중점을 두어 모델화하는 것
    • 완전한 시스템 구축 전, 그 시스템과 유사한 모델을 만들어 여러 요인들을 테스트할 수 있다.

객체지향 기법

  • 집단화 (is part of / part-whole)
    • 클래스 간의 구조적인 집약 관계
    • “클래스 A는 클래스 B와 클래스 C로 구성된다”

    part 가 들어가면 집단화

  • 일반화 (is a)
    • 클래스들 간의 개념적인 포함 관계
    • “자식 클래스 A는 부모 클래스 B의 일종이다”
  • 추상화
    • 공통 성질을 추출하여 수퍼클래스 구성

객체지향 분석 방법론

  • Coad 와 Yourdon
    • E-R 다이어그램 사용
    • 객체 행위 모델링, 객체 구조 식별, 주체 속성 및 관계 서비스 정의
  • Booch
    • 클래스와 객체 식별 및 의미 관계 식별
    • 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석방법
  • Rumbaugh
    • 소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델링
    • 체 모델링
      • 가장 선행, 객체 다이어그램(객체 관계) 으로 표시

      [Keywords]

      정보 모델링, 시스템에서 요구

    • 적 모델링
      • 시간의 흐름에 따른 제어흐름, 상호작용, 동작순서 표현
      • 상태 다이어그램

      [Keywords]

      제어, 흐름, 동작

    • 능 모델링
      • 다수의 프로세스들 간의 자료 흐름 중심, 자료 흐름도(DFD) 이용

      [Keywords]

      DFD

  • Jacobson
    • Use Case를 강조하여 사용하는 분석방법
  • Wirfs Brock
    • 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

객체지향 설계 원칙

  • 단일 책임 원칙

    SRP (Single Responsibility Principle)

    • 객체는 단 하나의 책임만 가져야 한다.
  • 개방 - 폐쇄의 원칙

    OCP (Open Closed Principle)

    • 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계 되어야 한다.
  • 리스코프 치환 원칙

    LSP (Liskov Substitution Principle)

    • 일반화 관계, 자식 클래스는 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다.
  • 인터페이스 분리 원칙

    IPS (Interface Segregation Principle)

    • 인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙이다.
  • 의존 역전 원칙

    DIP (Dependency Inversion Principle)

    • 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다 변화하기 어려운 것, 거의 변화가 없는 것에 의존해야 한다는 설계 원칙이다.

CASE (Computer Aided Software Engineering)

소프트웨어 개발의 자동화

시스템 개발 방법론들의 자동화를 지원하는 소프트웨어 도구를 제공하여 반복 작업을 줄인다.

CASE 주요 기능

  • 소프트웨어 생명 주기 전반적인 단계의 연결
  • 시스템 문서화 및 명세화를 위한 그래픽 지원
  • 다양한 소프트웨어 개발 모형지원

    • 상위 CASE 주요 기능
      • 모델들 사이의 모순검사
      • 모델의 오류검증
      • 자료흐름도(DFD) 등 다이어그램 작성
    • 하위 CASE 주요 기능
      • 생명 주기 하반부에 사용
      • 코드를 작성하고 테스트하며 문서화하는 과정을 지원
    • 통합 CASE 주요 기능
      • 생명 주기에 포함되는 전체 과정을 지원
      • 공통의 정보 저장소와 통일된 사용자 인터페이스를 사용하여 도구들을 통합

CASE 원천 기술

  • 구조적 기법 (Structured Technique)
    복잡한 시스템을 여러 개의 작은 부분으로 분할하여 문제를 해결하는 방법으로, 설계 및 개발 과정을 구조화한다.
  • 프로토타이핑 기술 (Prototyping Technique)
    초기 단계에서 사용자와 시스템 간의 상호 작용을 모방한 모형을 생성하여 시스템 요구사항을 더 잘 이해하는데 도움이 된다.
  • 정보 저장소 기술 (Information Repository Technique)
    시스템의 모든 정보를 중앙에 모아 시스템의 모든 관련 정보를 쉽게 액세스하고 업데이트할 수 있도록 하는 방법

CASE 장점

  • 소프트웨어 개발 기간을 단축하고 개발 비용을 절감할 수 있다.
  • 자동화된 기법을 통해 소프트웨어 품질이 향상된다.
  • 소프트웨어의 유지보수를 간편하게 수행할 수 있다.
  • 소프트웨어의 생산성이 향상되고 생산, 운용 활동을 효과적으로 관리 및 통제할 수 있다.
  • 품질과 일관성을 효과적으로 제어한다.
  • 소프트웨어 개발의 모든 단계에 걸친 표준을 확립
  • 소프트웨어 모듈의 재사용성이 향상된다.

❗️정보저장소

  • 소프트웨어를 개발하는 과정 동안에 모아진 정보를 보관하여 관리하는 곳
  • CASE 정보 저장소, CASE 데이터베이스, 요구사항 사전, 저장소라고도 한다.
  • 일반적으로 정보 저장소는 도구들과 생명 주기 활동, 사용자들, 응용 소프트웨어들 사이의 통신과 소프트웨어 시스템 정보의 공유를 향상한다.
  • 도구들의 통합, 소프트웨어 시스템의 표준화, 소프트웨어 시스템 정보의 공유, 소프트웨어 재사용성의 기본이 된다.
  • 소프트웨어 시스템 구성 요소들과 시스템 정보가 정보 저장소에 의해 관리되므로 유지 보수성이 향상된다.

소프트웨어 설계

  • 상위 설계
    아키텍쳐, 데이터, 시스템 분할, 인터페이스(UI) 정의/설계
  • 하위 설계
    모듈 설계, 인터페이스 작성

모듈 간의 결합도가 약할수록 응집도는 강할수록 좋다.


소프트웨어 아키텍쳐

소프트웨어의 구조

  • 계층 패턴 (Layer Pattern)
    시스템을 계층으로 구분하여 구성
    ex) OSI 참조 모델
  • 클라이언트-서버 패턴 (Client-Server Pattern)
    하나의 서버 컴포넌트와 다수의 클라이언트 컴포턴트로 구성되는 패턴
  • 파이프-필터 패턴 (Pipe-Filter Pattern)
    데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
    ex) UNIX의 SHELL
  • 모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern)
    서버시스템을 3개의 부분으로 구조화하는 패턴

    제어(Controller) 는 뷰(View) 와 모델(Model) 사이에서 전달자 역할을 수행한다.


DBMS (DataBase Management System) 분석 시 고려사항

데이터베이스 관리 시스템

  1. 가용성
  2. 성능
  3. 기술 지원
  4. 상호 호환성
  5. 구축 비용