DS-L01

• toc {:toc}

Software Engineering

• 디자인, 생산, 유지보수에 대해 정해진, 시스템화된 접근 방식이 존재한다.
• 정해진 시간, 비용 내에 개발할 수 있도록 구성
• 크기와 복잡도를 다루는데 도움이 되는 도구를 사용한다. ex) OS, editors, compilers, debugging, …

Good Software

• Algorithm
  • 유한한 시간안에 주어진 문제를 해결하는 해결책을 나타내는 논리적 단계를 말한다.
• 좋은 소프트웨어의 목표

1. 작동한다.
2. 많은 시간과 노력이 들지 않아도 수정할 수 있어야 한다.
3. 재사용 가능하다.
4. 시간과 비용 안에 완성된다.

• 프로그램 명시
  • 프로그램이 무엇을 해야하는지 문서화된다.
  • 어떻게 동작하는지는 다루지 않는다.
• 추상화
• 시스템 사용자 관점에서 필수적인 사항만 포함한다.
• Information Hiding
• High-level vs Low-level
• Stepwise Refinement 단계별 접근 방식.
  • Top-down (큰문제 → 세분화)
  • Bottom-up (작은문제들을 서로 엮어가면서)
  • Functional decomposition (함수 분해)
  • Round-trip gestalt design

Procedural vs Object-oriented

• 절차 지향적 : 동사, 함수를 중요시한다. 동사를 먼저 만들고 명사를 만든다.
• 객체 지향적 : 명사, 함수를 행하는 주체를 중요시한다. 명사를 만들고 명사가 행할 동사를 만든다.
• Module 을 만드는 두 가지 접근 방식
• Functional decomposition
  • 함수 모듈로 만들 수 있을 때까지 문제를 더 쉽게 다룰 수 있는 소주제로 나눈다.
  • 과정에 집중한다.
  • 절차 지향적이며 순서에 민감하고, 서로 강하게 연결되어 있다.
  • 유지 보수하기 어렵다.
• Object-oriented design
  • 문제를 해결하는 것에 함께 사용될 수 있는 데이터와 동작으로 구성된 다양한 객체로 나눈다.
  • 데이터 객체에 집중한다.
  • 캡슐화, 상속 등 고려 요소가 많아 처음 프로그래밍하기 어렵다.
  • 절차 지향적 방식에 비해 크기가 크기 때문에 낮은 수행능력을 낸다.
  • 모든 클래스를 알고 있어야 하기 때문에 개발 측면에서는 비효율적이다.
• Test Case
  • 입력을 결정한다.
  • 프로그램의 예상 결과를 결정한다.
  • 프로그램을 실행하고 결과를 관찰한다.
  • 예상 결과와 실제 결과를 비교하고 수정한다.
• Verification vs Validation
• Verification - 개발자의 관점에서 과정과 절차, 로직이 올바른지를 판단하는 것이다.
• Validation - 사용자의 입장에서 출력이 올바른지, 작동이 잘 되는지를 판단하는 것이다.

Error

• 에러 검출이 프로그램을 만드는 과정 중 늦게 나올 수록 수정하는 비용이 증가한다.
• Controlling Errors
• Robustness : 에러로부터 프로그램이 회복하는 능력. 작동 환경에서 작동을 지속할 수 있는 능력
• Preconditions : Postconditions 가 보장되기 위해 작동에 들어가야 하는 가정
• Postconditions : Preconditions 가 참이라고 가정하면서 함수의 예상되는 출력을 서술한 구문