체계적인 프로그래밍 소개 – 3주차

Introduction to Systematic Program Design 3주차는 확실히 이전보다 훨씬 더 많은 비디오 콘텐츠였으며, 이미 4주차부터 비디오를 보기 시작했기 때문에 지금부터는 더 미쳐버릴 것이라고 자신 있게 말할 수 있습니다!

그래서 수업의 3주차는 주로 데이터를 설계하는 방법을 배우는 데 중점을 두었고 제가 할 수 있는 한 최선을 다해 배운 각 수업을 단계별로 안내해 드리겠습니다. 흥미롭게도, 저는 이러한 요약을 작성하는 것이 제 학습에도 도움이 된다는 것을 알게 되었기 때문에 제 급우인 여러분도 이 요약을 읽는 것이 비슷한 도움이 되기를 바랍니다!

학습 1: cond 표현식

이 수업에서 학생들은 데이터 설계가 프로그램 설계에서 지렛대 포인트라는 것을 분명히 합니다. 이는 우리 각자가 데이터를 설계할 때 나중에 해당 데이터에서 작동하는 모든 기능이 어떻게 작동할지에 대한 결정을 알거나 무의식적으로 내리기 때문입니다.

조건식 또는 cond 표현식을 사용하면 두 개 이상의 경우가 있을 때 조건부 동작을 프로그래밍할 수 있습니다. 이렇게 하면 cond 표현식을 "multi-armed conditionals"로 간주할 수 있습니다.

표준 원소 표현식 템플릿:

cond QA 표현식을 구성하려면:

여기서 식 1은 질문이고 식 2는 답변입니다.

cond 표현식 템플릿을 사용하여 cond 예제 만들기:

조건을 평가하는 규칙은 다음과 같습니다.

1. No Question/Answer pair? Signal an error.
2. 첫 번째 질문이 값이 아닌 경우 평가하고 해당 값으로 바꿉니다. 전체 cond를 첫 번째 Question이 해당 값으로 대체되는 새 cond로 바꿉니다.
3. 첫 번째 질문이 true로 평가되는 부울이거나 else로 평가되는 문인 경우 전체 cond를 첫 번째 답변으로 바꿉니다.
4. 첫 번째 질문이 거짓인 경우 첫 번째 질문/답변 쌍을 삭제하고 첫 번째 질문/답변 쌍이 없는 새 조건으로 교체합니다.
5. 1 ^번째 질문은 참 또는 거짓이 아니므로 오류를 알리십시오.

이 단원의 추가 참고 사항:

[]는 시각적 규칙입니다 – Dr. Racket은 ()와 []를 같은 방식으로 처리하지만 []를 사용하면 압도되지 않을 수 있습니다.

학습 2: 데이터 정의

이 단원에서는 무엇보다도 데이터 정의가 디자인 요소임을 설명합니다. 모든 프로그램에는 데이터뿐만 아니라 문제 도메인이 있습니다. 문제 도메인 내에 있는 정보를 가져와서 데이터로 표현하는 것이 데이터의 영역입니다. 기본적으로 데이터 정의는 프로그램에서 정보를 데이터로 표현하는 방법을 설명합니다. 이 레슨의 비디오를 보면서 Excel에서 만들 수 있는 색상 키가 생각났습니다 – 기호 또는 색상을 가져와서 사용자 또는 이 경우 컴퓨터에 의미하는 바를 정의하여 디자이너(나)가 의미하는 바를 해석할 수 있습니다.

다음은 Dr. Racket 데이터 정의의 예입니다.

Lesson 3: Atomic Non-Distinct Data Definitions

이 수업에서는 도시 이름을 나타내기 위해 데이터 정의를 설계한다는 전제를 사용하여 데이터 정의가 실제로 어떻게 작동하는지에 대한 직접적인 예를 제공했습니다.

기억해야 할 점:

1. 데이터 정의의 일부는 레시피 목록에 있습니다
2. 다양한 종류의 데이터 정의가 있습니다
3. 원자 적 (Atomic)은 당신이 그것을 분해 할 수 없으며 문제 정보의 스펙트럼에서 여전히 의미를 유지할 수 없다는 것을 의미합니다.

atomic non-distinct에 대한 데이터 정의의 예:

;; CityName is String
;; interp the name of a city
(define CN1 “Boston”)
(define CN2 “Vancouver”)

데이터 기반 템플릿은 다음 단원에서 다루었으며 이 동일한 예제에 대해 다음과 같이 계속합니다.

학습 4: 데이터 정의를 사용하는 HtDF

이 수업의 목적은 기본이 아닌 데이터를 사용하는 함수를 설계하는 방법을 가르치는 것이었습니다.

이 수업에서 제가 얻은 몇 가지 간단한 팁이 있었고 여러분과 공유하고 싶습니다.

1. 부울 표현식의 경우 조건자는 ?로 끝나야 합니다.
2. 데이터 정의를 사용하여 디자인할 때 예제를 지침으로 사용합니다.
3. 함수에 두 가지 경우가 있는 경우 템플릿 주위에 if 문을 래핑하여 템플릿을 구체화합니다
4. (가장 중요한 것은!!) 코드를 시작할 때 스텁을 주석 처리하는 것을 잊지 마세요!

Lesson 5: HtDF X 데이터 직교성의 구조

우선, 제가 이 수업의 제목을 보았을 때 저는 그것이 무엇에 관한 것인지 전혀 몰랐습니다 – 저는 꽤 괜찮은 영어 어휘에 자부심을 가지고 있지만, 직교성은 저에게 완전히 새로운 용어였습니다. 같은 배를 타고 계신 분들을 위해 설명하겠습니다: Orthogonal은 단순히 "대부분 독립적"을 의미합니다. 이 경우 HtDF 방법은 작업 중인 데이터 유형이 직교한다는 가정으로 구조화되어 있으므로 더 많은 유형의 데이터를 학습함에 따라 오류 없이 이전에 작성된 함수에서 구현할 수 있기 때문에 중요합니다. 나는이 이론을 시험하지 않았지만, 여기에 제공된 교훈을 기반으로 한 것으로 이해합니다!

이 강의의 나머지 부분은 이 데이터 유형 차트에 대한 설명을 기반으로 했는데, 실제로는 매우 깔끔하다고 생각합니다.

이 차트는 기본적으로 다양한 데이터 유형을 모두 안내하고 Interval, Enumeration 및 Itemization에 대해 설명하는 다음 수업을 준비합니다.

6단원: 간격 데이터 정의

간격 데이터 정의는 표시할 숫자가 특정 범위 내에 있을 때 사용됩니다. 이를 적절하게 표현하기 위한 핵심은 포용성과 배타성의 뉘앙스입니다. 예를 들어:

[1, 7]은 포함되며, 이는 간격에 포함된 숫자가 1, 2, 3, 4, 5, 6, 7임을 의미합니다.

그러나 [1, 7)은 배타적이므로 이 간격에 포함되는 숫자는 1, 2, 3, 4, 5, 6입니다.

cond 표현식과 반대로, 간격 데이터 정의의 경우 [] 및 () 는 다른 결과를 생성합니다.

또한 간격 데이터 정의를 사용할 때 다음 두 가지 규칙을 활용하는 것이 중요합니다.

1. 데이터 차트 사용하여 가장 적합한 레시피를 찾으십시오. 가장 구체적인 것으로 이동합니다.
2. Data Definitions Templates Page를 사용하여 템플릿을 찾으십시오!

Lesson 7: 열거형 데이터 정의

열거형은 고정된 수의 두 개 이상의 고유 값에 대한 도메인 정보가 있는 함수/프로그램을 만들 때 사용됩니다. 좀 더 현실적인 예로, 저는 이러한 것을 선호하기 때문에 추적 성적의 차이를 문자 값으로 생각하거나 백분율로 간주합니다. 문자 값은 더 적고 정확하게 정의된다는 점에서 표현하기가 훨씬 쉽습니다. 그러나 백분율은 정확하지 않으므로 열거형으로 정의할 수 없습니다.

열거형으로 작업할 때 염두에 두어야 할 주요 사항은 열거형이 데이터 정의에서 "one of" 구문을 사용하며 "one of" 섹션 내에서 들여쓰기된 이러한 항목을 하위 클래스라고 한다는 것입니다. 또한 예제는 문자 그대로 정의 자체를 반복하기 때문에 열거형에서 완전히 중복됩니다.

Lesson 8: Itemization Data Definitions

항목화 데이터 정의는 다양한 상태와 다양한 값 및 유형을 가진 범주가 기능/프로그램에 필요할 때 사용됩니다. 2개 이상의 서브 클래스가 있어야 하며, 그 중 적어도 하나는 하나의 고유한 값이 아닙니다.

혼합 데이터 항목화로 작업 할 때 함수를 실행할 수 있도록 하위 클래스를 적절하게 보호해야한다는 점에 유의하는 것이 매우 중요합니다. 이것은 불리언 인 서브 클래스가 Natural과 같은 방식으로 평가 될 수 없기 때문에 필요하므로 프로그램에게보고있는 데이터의 종류를 확인하도록 지시하지 않으면 혼란스러워지고 프로그램이 고장날 수 있습니다. 이렇게 하려면 "가드"를 설정합니다. 예를 들어, 숫자를 보호하는 경우 실제 평가 표현식 앞에 (number? c)를 넣습니다.

이것은 Dr. Racket에서 더 고급 언어의 컴파일러가 자연스럽게 들어가서 데이터 유형을 확인하는 것과 같은 방식으로 사용됩니다. 그러나 Dr. Racket에서는 이 작업을 수동으로 수행해야 합니다.

과정 9: 간격이 있는 HtDF

Interval Data Definitions를 사용할 때 테스트하는 것은 지금까지 과정에서 check-expects를 작성하는 방법을 이전에 배운 것보다 약간 더 복잡합니다. Intervals의 경우, Interval의 경계와 중간점을 모두 테스트하는 것이 이 섹션에서 배포하는 가장 중요한 교훈입니다.

Lesson 10: 열거형을 사용한 HtDF

열거형을 사용하여 테스트하는 한, 여기서 핵심은 최소한 하위 클래스가 있는 만큼의 check-expects를 테스트하는 것입니다. 그렇지 않으면 모든 가능성을 커버하지 못하는 것입니다!

또한 이 단원에서 언급할 점은 동일한 프로그램에 있는 경우 별도의 함수에 대해 별도의 데이터 정의가 필요하지 않다는 것입니다. 데이터 정의를 재사용할 수 있습니다!

Lesson 11: 항목화를 사용한 HtDF

아이템화 테스트의 경우 불행히도 기반을 다지기 위해 조금 더 생각해야 합니다. 항목화에서 모든 분산 지점을 테스트하고 인접한 정의의 경계를 확인하여 해당 동작이 예상대로 작동하는지 확인하는 것이 중요합니다. 프로그램을 완성하고 사용자에게 보낸 다음 테스트하기에 "너무 바빠서" 발견한 것을 소급하여 수정해야 하는 것과는 대조적으로 철저하게 테스트하고 생각할 수 있는 모든 코너 케이스를 포함하는 것이 훨씬 좋습니다!

Lesson 12: 정보 흐름의 구조

정보의 구조를 식별하는 것은 프로그램 설계의 핵심 단계인데, 그 이유는 이번 주 노트의 시작 부분에서 말했듯이 데이터를 만드는 방법에 대한 선택은 궁극적으로 전체 함수/프로그램의 코드를 만들 때 선택할 수 있는 옵션에 영향을 미치기 때문입니다.

3주차 마무리

그래서 학급 포럼에서 많은 사람들이 이번 주가 수업이 "진짜"가 되는 시간이라고 말했습니다. 솔직히 저는 동의하지 않습니다. 많은 MOOC에서 3주 차는 꽤 가파른 하락세가 있는 시기라고 생각하는데, 그 이유는 제시되는 내용이 일반적인 지식에서 벗어나 약간 더 깊이 있게 되기 때문입니다. 하지만, 다시 말씀드렸듯이, 저는 4주 차부터 영상을 보기 시작했고, 4주 차가 "현실이 될 것"이라고 자신 있게 말할 수 있습니다. 인터랙티브 프로그램? 그건 제가 흥분할 수 있는 부분이에요.

다음 주를 계속 지켜봐 주시면 제가 여전히 수업에 참여하고 있는지 확인할 수 있습니다! 비디오 콘텐츠가 두 배로 늘어났고 숙제가 치열할 거라고 확신합니다!