소프트웨어 공학적인 개발 방법

애플리케이션 개발 순서

1. 요구사항 분석
   1. 뭐가 확장될 것 같은지, 아키텍쳐를 어떻게 설계할지 이 단계에서도 같이 생각 해보기
   2. 주어져야 하는 메시지를 보고, 어떠어떠한 도메인(객체)가 있는지 생각해보기. → Domain-Driven Design
   3. 안정적인 구조(확실한 도메인)가 확장성 높은 소프트웨어를 만든다.
2. 아키텍처 설계
   1. 도메인 탐색
   2. 도메인 별 정의 서술 (Documentation)
   3. 도메인 별 유스케이스 다이어그램 생성
   4. 유스케이스별 협력, 책임, 역할 다이어그램화
      • “기능 별”로 필요한 객체 다이어그램 설계 - 해당 기능을 구현하는 데 사용되는 객체들 생성하기
      • 다이어그램이 잘 안그려진다면 → 빼먹은 액터는 없는지, 단위기능이 너무 큰건 아닌지 분리해보기
   5. 필요한 책임에 따른 아키텍쳐 설계
   • 도메인의 역할, 책임(기능), 협력(메시지) 관계 생각해보기 → 적절한 디자인 패턴이 있다면 사용하기
3. 계약 작성
   1. 필요한 메소드 파악
   2. 사전조건 & 사후조건 설정
4. 테스트 코드 작성
   1. 계약 메소드들의 테스트 코드 작성
   2. 테스트 커버리지가 하방으로 내려가지 않으면서, 필요한 메소드들은 전부 테스트 하도록
5. 구현
6. 리팩토링

함수와 기능의 구조

• precondition
  • 함수의 입력값이 지켜야 하는 조건
    • 함수나 메서드가 제대로 동작하기 위해 보장해야하는 모든 것을 의미하며, 파라미터에 제공된 데이터 유효성 검사하는 계약이다.
    • 호출자에게 부과된 임무로, 클라이언트는 코드를 실행하기 위해 사전에 약속한 조건을 준수해야한다.
    • 사전 조건 검증에서 실패했다는 것은 클라이언트에 결함이 있다는 것이다.
• 기능
  • 함수의 기능
  • 내가 안에 들어가서 해당 기능을 수행한다는 상상을 하여 해당 기능을 구현하라
  • 특정 함수의 기능은 다른 어떤 함수의 precondition을 만족시켜야 할 수 있다.
• postcondition
  • 함수의 출력값의 조건과 형태
    • 메서드 또는 함수 반환값의 유효성을 검사하여 반환된 후의 상태를 강제하는 계약이다.
    • 컴포넌트는 클라이언트가 확인하고 강제할 수 있는 값을 보장해야하며, 사후검증을 통과한 클라이언트는 반환된 객체를 아무 문제없이 사용할 수 있어야한다.
    • 사후 조건 검증에서 실패했다는 것은 특정 모듈이나 제공 클래스 자체에 결함이 있다는 것이다.
  • 특정 함수의 postcondition 은 다른 어떤 함수의 precondition을 만족시켜야 할 수 있다
• 기능의 유기적 연결 → postcondition과 precondition의 연결!!!
• precondition 과 postcondition 을 코드로 작성하는것이 바로 TDD(테스트 주도 개발)!!!
  • precondition 과 postcondition으로 입력과 출력, 그리고 메시지를 검사한다!

역할, 책임, 협력의 관점에서 애플리케이션을 설계하는 세가지 기법

• DDD
  • 이해관계자가 요구하는 도메인을 바탕으로 각 객체들을 구성하여
  • 확장성 높은 안정적인 구조를 만든다
• Design Pattern
  • 객체지향 패러다임에서 반복되는 문제들을 모아놓은 패턴
  • 이를 이용해 안정적인 구조를 설계하는 시간을 단축시킨다.
• TDD
  • 객체 간 precondition 과 postcondition 을 기반으로
  • 안정적인 입/출력 을 만든다.
  • 기능과 구현을 분리한다.
  • 메시지에 집중하도록 한다.

Use Case 의 존재 이유

• 유스케이스는 설계 기법도, 객체지향 기법도 아니다.
• 도메인 모델에서 사용할 용어에 대한 힌트와
• 메시지에 대한 아이디어를 제공하는 용도