- toc {:toc}
Software Engineering
- 디자인, 생산, 유지보수에 대해 정해진, 시스템화된 접근 방식이 존재한다.
- 정해진 시간, 비용 내에 개발할 수 있도록 구성
- 크기와 복잡도를 다루는데 도움이 되는 도구를 사용한다. ex) OS, editors, compilers, debugging, …
Good Software
-
Algorithm
- 유한한 시간안에 주어진 문제를 해결하는 해결책을 나타내는 논리적 단계를 말한다.
-
좋은 소프트웨어의 목표
- 작동한다.
- 많은 시간과 노력이 들지 않아도 수정할 수 있어야 한다.
- 재사용 가능하다.
- 시간과 비용 안에 완성된다.
-
프로그램 명시
- 프로그램이 무엇을 해야하는지 문서화된다.
- 어떻게 동작하는지는 다루지 않는다.
-
추상화
-
시스템 사용자 관점에서 필수적인 사항만 포함한다.
-
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가 참이라고 가정하면서 함수의 예상되는 출력을 서술한 구문