[정보처리기사 올인원] 1-4-1.공통 모듈 설계

https://youtu.be/3PDORvb5yI8?si=x7jGAS3sqE7O-9dH

1. 애플리케이션 설계

1-1. 소프트웨어 설계의 개요
- 소프트웨어 설계, 알고리즘과 자료 구조 설계를 포괄적으로 포함함
- 소프트웨어 설계의 주요 단계는 데이터 설계, 아키텍처 설계, 인터페이스 설계, 절차 설계 순으로 진행됨
- 상위와 하위 설계로 나누어 볼 수 있음
- (중요) 데이터, 아키텍처, 인터페이스, 절차의 순서는 절대적인 것이 아님
- 데이터를 설계한 후, 아키텍처와 인터페이스 설계, 절차 설계를 순차적으로 진행하거나, 상위와 하위 설계를 나누어 진행할 수 있음

1-2. 소프트웨어 설계 모델과 추상화
- 소프트웨어 설계 모델은 데이터, 아키텍처, 인터페이스, 절차로 구성될 수 있음
- 추상화는 상세 설계 전 대략적인 표현을 통해 효율적으로 구현하기 위함임
- 추상화 기법은 제어 과정, 과정, 자료 세부 속성에 대한 대략적 표현으로 이루어짐
- 바람직한 설계 기준은 모든 내용을 구현해야 하고, 결함과 기능 추적 가능, 유지보수가 쉬워야 함
- (중요) 좋은 소프트웨어 설계는 각 기능이 확실하고 분명하게 분리되어야 함

1-3. 모듈과 재사용
- 모듈은 프로그램을 효율적으로 관리하고, 통합과 재사용을 용이하게 하는 분해된 부품임
- 모듈 개수가 많을수록 비용은 상승하지만, 통합 비용은 하락함
- 모듈을 조립할 때는 통합 비용을 고려하여 적절한 모듈을 선택해야 함
- 재사용은 이미 검증된 기능을 다시 사용하는 것으로, 함수, 객체, 컴포넌트, 애플리케이션 범위로 나뉨
- 재사용의 기본 기술은 생성 중심과 합성 중심임

2. 소프트웨어 공통 모듈 개발

2-1. 소프트웨어 개발 방법론 이해
- 소프트웨어 개발 방법론은 모듈 개발의 흐름을 이해함
- 모듈 개발은 재사용, 재공학, 역공학의 원리로 진행됨
- 재사용은 소프트웨어의 코드를 재구성하여 품질을 향상시키는 것을 의미함
- 재공학은 외계인 코드로부터 소스 코드를 복구하여 분석하는 작업임
- 역공학은 외계인 코드를 복구해서 문서화하고 설명하는 작업임

2-2. 모듈 개발 절차
- 모듈 개발의 첫 단계는 모듈의 업무 기능을 분석하고 표준화하는 것임
- 다음 단계는 유스 케이스를 분석하여 공통 기능이 적용 가능한지 검토함
- (중요) 회의를 진행하여 선정된 기능을 상세하게 문서화하고, 통합함
- 모듈을 관리하는 프로세스를 정리하여 문서화함
- 문서화되지 않은 경우, 외계인 코드를 생성하지 않음

2-3. 모듈 품질 개선
- 모듈 내부의 요소들이 얼마나 관련이 있는지를 나타내는 것이 응집도임
- 응집도가 높을수록 모듈의 독립성이 높아지고, 내부 요소들이 서로 많음
- 응집도가 낮을수록 모듈의 독립성이 낮아지고, 내부 요소들이 서로 적음
- (중요) 기능적 응집도는 하나의 문제를 해결하기 위해 모든 기능 요소들이 뭉쳐 있는 경우임
- 순차적 응집도는 하나의 출력 결과를 다른 모듈의 입력값으로 사용하는 경우임

3. 모듈 설계와 응집도 및 결합도 이해

3-1. 응집도와 결합도의 개념과 종류
- 응집도는 모듈 간의 관련성을 나타내며, 결합도는 모듈 내부의 연관성을 나타냄
- 응집도와 결합도는 서로 다른 특성들을 가짐
- (중요) 응집도의 종류에는 절차 응집도, 순차 응집도 등이 있음
- (중요) 결합도는 모듈 간의 응집 또는 모듈 내부의 연관성을 나타냄
- 결합도는 주로 '있다', '없다' 등의 개념을 통해 표현됨

3-2. 응집도와 결합도의 계산과 이해
- 응집도와 결합도를 계산할 때는 모듈의 결과를 입력으로 사용하고, 절차를 사용
- 응집도는 모듈 간 연관성을, 결합도는 모듈 내부의 연관성을 나타냄
- 응집도와 결합도는 모듈 설계 시 중점적으로 고려해야 할 요소임
- 각 모듈의 응집도와 결합도를 통해 다른 모듈이 나눠져 있는지, 서로 의존하는지 등을 파악할 수 있음

3-3. 결함요소와 응집도 및 결합도의 해결책
- 결함요소는 모듈 설계 시 고려해야 할 요소로, 오류 발생 시 중점적으로 관리해야 함
- 제어도를 단순화시켜서 불필요한 업무 로직을 줄일 수 있음
- 공유도와 제어도를 동시에 높이는 것이 이상적이나, 실제로는 한 모듈의 공유도를 높이고, 다른 모듈의 제어도를 낮추는 방향으로 설계하는 것이 이상적임
- (중요) 설계 단계에서 모듈 간 공유도와 제어도를 고려하는 것이 중요함

00:01
1과목 네 번째 챕터입니다. 애플리케이션 설계인데요. 어려운 내용도 많고 출제 비중도 높습니다. 공부를 조금 집중해 주셔야 될 것 같아요. 첫 번째 섹션 공통 모듈 설계입니다. 이 공통 모듈 설계를 배우기에 앞서서 일단 소프트웨어 설계가 어떻게 진행되는지를 간단하게 먼저 보겠습니다. 일단은 소프트웨어설계가 뭐냐 알고리즘 설계하고 자료 구조 설계하는 거 이게 소프트웨어 설계입니다. 일단 어떤 데이터들이 있을 거고요. 그 데이터들을 구조화시키고 그다음 이 데이터를 어떻게 처리할 건지를 알고리즘을 설계하는 거죠. 이 두 가지를 소프트웨어 설계라고 볼 수가 있는데, 대표적인 방식이 두 가지가 있어요. 이 두 가지가 발전 방식이 아니라 차이점입니다. 절차 지향은 속도가 빠르지만 유지 보수가 좀 어려운 편이고요.

01:00
객체 지향은 난이도가 높은데 느린 편이지만 살짝 느려요 코드의 재활용이랑 유지 보수가 쉬워요 2가지 절차 지향과 객체 지향의 차이점을 구분을 해두실 필요가 있어요. 자 소프트웨어 설계와 관련된 모델 데이터 설계 아키텍처 설계 인터페이스 설계 절차 설계 순으로 이 순서대로 구성이 된다고 되어 있는 건데 앞에서도 잠깐 봤지만 데이터를 일단 설계를 하고요. 그다음에 아키텍처 소프트웨어 큰 구조를 설계하고 그다음에 인터페이스 이 소프트웨어와 상호작용하는 할 수 있는 매개체를 설계하고 그다음에 마지막 절차 설계를 들어간다 뭐 이렇게 들어가고 있죠. 근데 요게 항상 절대적인 건 아니구요. 이 설계 단계를 상위와 하위로 나눌 수도 있다고 되어 있어요.

01:59
그래서 이제 소프트웨어 설계 모델이 아닌 것은 해서 데이터 아키텍처 인터페이스 절차 요 중에 3개가 나온다고 하면 그중에 맞지 않은 하나를 찾을 수 있어야 되고요. 또는 상위 설계나 하위 설계가 아닌 것을 문제로 출제를 할 수도 있습니다. 그래서 이 2가지로 구분이 된다. 상위 하위 또는 아키텍처 뭐 데이터 인터페이스 이렇게 구성이 될 수 있다. 이렇게 두 가지로 구분해서 공부를 해주시면, 좋을 것 같아요. 넘어갈게요 자 추상화라는 단어도 앞에서 자주 나왔었죠. 소프트웨어 상세 설계하기 전에 대략적으로 포괄적으로 구상을 하는 요걸 추상화라고 이야기를 합니다. 추상화를 하는 이유는 조금 더 구체화를 효율적으로 수행할 수 있기 때문이에요. 이 추상화 기법이 세 가지가 나옵니다. 제어 과정 자료예요.

02:53
말 그대로 제어 메커니즘이 상세화되기 전에 포괄적인 표현을 해보는 거고요. 과정은 수행 과정이 상세화 되기 전에 전반적인 흐름을 비슷한 의미죠 포괄적이랑 그다음에 자료는 데이터의 세부적인 속성이랑 표현 방법을 정하기 전에 대략적인 대표적인 표현을 통해서 추상화를 시킨 다음에 나중에 상세화시킨다는 거죠. 이렇게까지 추상화를 보시면 되겠습니다. 그리고 아래 바람직한 설계 기준 나와 있는데, 상식적으로 생각해보면 이것도 마찬가지 그렇게 어려운 내용은 아니에요. 모든 내용을 구현해야 된다. 이거는 뒤쪽에서 나오겠지만, 9가지를 잘해도 1가지가 구현이 안 되어 있으면은 이건 클라이언트가 원하는 소프트웨어라고 볼 수가 없어요. 그 부분을 이야기하는 거고, 그다음에 결함과 기능 추적을 할 수 있어야 된다.

03:53
유지보수할 때 용이해야 된다. 요런 것들을 만족을 해야 된다라는 거죠. 좋은 소프트웨어 설계라는 거는 각 기능들이 확실하고 분명하게 분리되어 있어야 된다 라고 써있어요. 복잡하게 얽히고 설키는 게 아니라 각각 독립적으로 구성이 되어 있는 게 좋은 소프트웨어 설계다라는 거죠. 독립적인 기능을 가진 모듈 절차와 자료 구조에 대한 명확한 표현 모듈의 효과적 제어를 위해 계층적으로 구성되어 있어야 된다. 3가지 요소를 만족을 해야 만족을 할수록 좋은 설계라고 볼 수 있다라는 거죠. 그렇기 때문에 이 독립적인 기능을 가진 모듈을 분리해서 구성하기 위해서 우리가 공통 모듈이라는 걸 배운다라는 거예요. 자 그래서 공통 모듈에 대해서 보도록 합시다. 자 공통 모듈에서 모듈을 먼저 알아야겠죠.

04:48
앞에서 잠깐 이야기했지만, 자 프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화하는 기법을 모듈화라고 한다고 써 있습니다. 이 모듈화를 통해서 뭘 해요. 성능이 좋아지고 수정 재사용 유지관리가 용이해진다고 되어 있어요. 긍정적인 효과적 긍정적 이렇게 기억을 하고 계시면 될 것 같구요. 어쨌든 모듈이라는 거는 부품화라고 저번에 영상에서 이야기를 했죠. 그렇기 때문에 여러 개로 쪼개다 그러면 그걸 다시 합칠 때도 많은 시간하고 비용이 들 수 있어요. 자 그래서 적절하게 선택을 해야 됩니다. 글로 정리를 해놨죠 모듈의 개수가 많으면 당연히 크기가 작아지겠죠. 대신 얘네들을 조립하는 여기선 통합이라고 되어 있죠. 이 비용이 상승해요.

05:45
반면에 개수가 적은 경우에는 당연히 크기가 커지겠죠. 프로그램 자체가 바뀌는 건 아니니까요? 대신에 통합 비용은 하락합니다. 자 그래서 요거 갭을 잘 맞춰줘야 되는데 요걸 그래프로 제가 표현을 해놨어요. 자 이렇게 노력 비용과 모듈 개수 뭐 이런 게 나와 있는데요. 모듈 개수가 많아질수록 자 비용이 여기 통합 비용이죠. 통합 비용이 이만큼 올라가고요. 모듈 개수가 적을수록 통합 비용은 줄어드는데 노력 비용이 올라가죠 이런 그래프가 나올 수 있는데, 어찌 됐건 이 그래프 안에서 최소 비용 영역은 요 정도에 해당한다는 거죠. 이 구간을 잘 찾을 수 있어야 된다라는 얘기입니다. 요것까지 보고 넘어가시면 될 것 같습니다. 이 표 자체를 해석한다기보다 이 개념을 이해하시는 데 활용을 하시는 게 좋아요.

06:41
자 그래서 모듈화가 이런 건데 이제 드디어 공통 모듈 나옵니다. 자 그러면 공통 모듈은 무엇이냐 공통적으로 사용할 수 있는 모듈이에요. 당연한 얘기죠 공통적으로 사용할 수 있는 모듈이니까. 당연히 누구나 쓸 수 있게끔 사용법 같은 게 공개되어 있어야 되고 유지보수가 편해야 됩니다. 다 같이 쓸 수 있어야 되니까요? 그리고 이 공통 모듈 공부하면서 가장 중요한 문장입니다. 별표를 3개 정도 해볼까요? 공유도와 응집도라는 게 나중에 나와요. 자 요것들을 높여야 됩니다. 그다음에 제어도와 결합도는 낮춰야 돼요. 이 문장이 핵심입니다. 요 문장을 반드시 기억을 하고 계세요. 어쨌든 요런 것들이 있습니다. 이건 나중에 조금 이따가 천천히 배우도록 할게요 자 어쨌든 이게 재사용할 수 있는 공통적으로 계속 사용할 수 있는 그런 것들인데 이 모듈은 당연히 재사용 개념이 들어가겠죠.

07:41
앞에서도 잠깐 언급을 했던 건데요. 자 재사용이라는 거는 이미 검증이 완료된 기능을 다시 사용하는 거예요. 말 그대로 재사용이죠. 자 그럼 이 재사용을 어디 부분까지 할 거냐라는 게 세 가지로 나뉩니다. 함수와 객체 컴포넌트 애플리케이션 범위로 나뉜다 함수와 객체를 재사용하냐? 컴포넌트 단위로 재사용을 하는 거냐 아니면 애플리케이션 자체를 재사용할 수 있는 거냐 이 개념이라고 보는 거죠. 세 가지의 재사용 범위가 있다. 규모가 있다 라고 보시면 되고 재사용의 기본 기술은 앞에서도 잠깐 나왔었죠. 생성 중심과 합성 중심이 있습니다. 같은 개념이에요. 앞으로도 한번 나왔던 개념이 다시 나온다든지 약간 다른 설명을 통해서 나온다든지 이런 개념은 계속 있을 겁니다. 의미 파악이 중요해요. 어쨌든 요 두 가지가 있다. 정도 파악하고 넘어가도록 하죠. 자 이번에는 재사용이 아니라 재공학이죠.

08:40
재사용은 말 그대로 어떤 하나의 개념 같은 거고요. 재공학은 이런 재사용 같은 여러 가지 범위가 포함되어 있는 학문 뭐 이렇게 보시면 됩니다. 재공학 기존의 시스템을 이용해서 보다 나은 시스템을 구축하는 거 그래서 재공학이에요. 자 규모가 커지면서 발생한 소프트웨어 위기가 뭔지 나와 있고요. 개발이 아닌 유지보수의 측면으로 해결을 할려고 하는 거 새로운 개발이 아니라 기존 걸 활용하는 형태로 이러한 위기를 극복하려고 했다라는 얘기고요. 그 방법이 이런 것들이 있다고 되어 있어요. 거기서 요 4가지를 아래에서 볼 겁니다. 처음엔 분석이죠. 명세를 통해 문서를 통해서 재공학을 할 건지 말 건지를 판단하는 거예요. 기존 소프트웨어의 문서를 통해서 이걸 다시 쓸 수 있겠네 없겠네 이 부분을 써야겠네 이 부분을 판단한다는 거죠.

09:38
그다음에 재구성은 기능이나 외적인 동작은 바꾸지 않고 설계만 재구성하는 거예요. 소프트웨어의 코드를 재구성한다는 건 설계도를 바꾼다는 뜻이에요. 코드를 재구성해서 품질을 향상시키는 것 이게 재구성 그다음에 역공학은 외계인 코드로부터 소스 코드를 복구하는 겁니다. 복구를 하면 다시 이 분석을 할 수가 있겠죠. 외계인 코드가 뭔지는 그럼 설명이 나와 있어야겠죠. 외계인 코드 문제 나옵니다. 아주 오래되거나 참고 문서 개발자 이런 사람들이 없어서 유지 보수 작업이 어려운 거예요. 왜 어렵냐면 분석이 안 되기 때문이에요. 코드가 엄청 복잡할 텐데 소프트웨어 구현을 위한 코드는 변수라든지 여러 가지 요소가 있을 텐데 그 요소들이 어떤 의미로 쓰였는지 실제 개발자라든지 개발 문서가 없으면 판단하기가 굉장히 어렵습니다. 그렇기 때문에 당연히 유지보수가 어려운 거죠.

10:36
그래서 이 외계인 코드를 다시 복구해서 문서화하고 설명하고 다시 구조를 잡는 걸 역공학이라고 하는 겁니다. 아시겠죠. 넘어가서 이번엔 이 식 이 식은 변환이에요. 이 시스템에서 이 시스템으로 코드를 넘기는데 시스템이 서로 다르잖아요. 그래서 변환을 해서 넘기는 거예요. 이거를 이식이라고 합니다. 어려운 개념은 아니고요. 자 그리고 하나 더해서 자 재사용 역공학 제공학의 앞 글자를 묶어서 3r이라고도 한다. 이것까지 체크를 해두시면 좋겠습니다. 자 그래서 어쨌든 공통 모듈에 대해서 공부를 하기 위해서 앞에서 이론 2가지를 했고요. 재사용 재공학까지 이야기를 했고요. 자 요런 것들을 이용해서 이제 공통 모듈을 식별하는 절차에 대해서 좀 보겠습니다. 개념만 이해하시면 돼요. 자 일단 단위 업무 기능을 분석한다고 되어 있죠.

11:35
업무 기능을 표준화하고 누락이나 중복되는 기능이 있는지 검토한다. 그러니까 기능을 식별하는 거예요. 식별 하나씩 하면서 어 이거는 중복됐네 또는 얘네 두 개는 같은 기능이네 이런 식으로 정지하는 거죠. 자 요거를 이제 첫 번째 업무 기능 분석이라고 합니다. 이쪽에 본인 인증과 본인 확인을 보면 둘 다 본인 인증을 하는 기능이에요. 자 그런데 얘는 이름이 다르죠 그래서 얘를 본인 인증으로 표준을 하는 거예요. 지금은 제가 예시를 들기 위해서 문장을 바꿨지만 실제로 문장이 바뀌고 그러는 건 아닙니다. 어쨌든 이런 식으로 공통 기능을 표준화시키는 개념이다 라고 개념적으로 이해를 하시면 됩니다. 그 다음은 유스 케이스 분석이죠.

12:23
다이어그램의 포함 관계를 분석해서 이거 확장 관계였죠 유스 케이스의 분석해서 공통 기능으로 적용 가능한지 검토하는 단계다 요게 반드시 포함되는 포함 관계였잖아요. 어떤 유스 케이스랑 어떤 유스 케이스가 있을 때 여기에도 포함되고 여기에도 포함되는 걸 별도로 뽑은 거 요놈이에요. 요놈을 공통 모듈로 공통 기능으로 적용을 할 수 있는지 실제로 판단을 해보자는 거죠. 다음 검토 회의를 진행합니다. 위에서 여러 가지 뭐 이런 모듈에서 이런 기능들을 이제 하나씩 하나씩 도출해 봤고 이 도출한 기능들을 실제로 적용할 건지 말 건지를 회의를 하는 거예요. 자 그래서 회의를 해서 선정이 됐어요. 그러면 이 선정된 기능을 상세하게 문서화시키는 겁니다. 그다음에 이 기능을 통합을 시키고요.

13:16
공통 기능을 통합을 시키고 그다음에 이걸 어떻게 관리할 건지 프로세스를 정리를 해서 또 문서화를 하겠죠. 이런 문서가 없으면 뭐라 그랬죠 외계인 코드라고 그랬죠 외계인 코드를 만들지 않기 위해서 여러 가지 문서를 남기는 겁니다. 유지보수를 용이하게 하기 위해서 자 그런데 어쨌든 이 단계가 논리적으로 생각해보면 그렇게 암기를 할 정도로 복잡한 내용은 아니에요. 제가 이 비밀 노트에도 기록을 해놨지만 논리적으로 접근하면 충분히 할 수 있어요. 상세 기능을 명세한 다음에 회의를 진행하면 예를 들어서 회의에서 적용이 불가능하다고 판단이 될 수 있잖아요. 그러면 상세 기능을 분석하고 명세한 게 발전 헛수고가 되겠죠.

14:10
생각해보면 상식적으로 그렇죠. 그래서 회의를 먼저 하는 게 맞죠. 이렇게 순서를 생각해 보면 그렇게 어려운 단계는 아닐 거예요. 공통 모듈의 명세 원칙입니다. 공통 모듈의 명세 문서화죠 문서와 자 이 문서와 왜 한다. 그랬죠 의사소통 때문에 하는 거예요. 자 의사소통을 할 수 없는 코드는 외계인 코드라고 했죠. 결국에 핵심은 이거예요. 이거 개발을 하면서 서로 의사소통을 할 수 있게끔 나중에라도 오해가 없을 수 있게끔 원활한 의사소통이죠. 오해와 뭐 여러 가지 이해가 어려운 이런 부분이 없게끔 하는 게 이 명세의 목적이에요.

15:08
그렇기 때문에 명세 원칙도 이거와 궤를 같이 합니다. 정확해야 되고요. 명확해야 되고요. 일관성이 있어야 되고요. 추적이 가능해야 돼요. 유지보수를 해야 되니까요? 자 그렇기 때문에 이 5가지가 있다라는 거죠. 그래서 이 5가지는 오해와 충돌이 없게끔 하는 게 핵심이다라는 거죠. 문제가 살짝 애매하더라도 요 개념을 머릿속에 넣고 분석을 하다 보면은 분명히 다른 부분이 하나가 보일 거예요. 보기가 그거를 맞출 수 있으면 되겠습니다. 자 여기서부터는 기출문제 파트입니다. 굉장히 중요한 부분이에요. 모듈의 품질을 개선하기 위해서 아까 빨간 줄 기억나시나요? 이거 빨간 형광펜 공유도와 응집도는 높이고 제어도와 결합된 낮춰서 설계되어야 한다. 이 부분은 지금 할 거예요. 이제부터 자 응집도부터 하나씩 볼게요 모듈 내부 하나의 모듈 내부의 요소들이 얼마나 관련이 서로 있는지를 나타내는 정도예요.

16:06
응집도가 강할수록 필요한 요소들로만 구성되어 있는 겁니다. 그러니까 독립성이 높아지죠 현재 기능에 필요 없는 요소가 있다고 하면 이 요소는 다른 데서 쓰이는 거죠. 그러면 다른 모듈과의 연관성이 생길 수밖에 없어요. 이걸 나중에 좀 어려운 말로 쓰는데 어쨌든 그렇기 때문에 그러면 독립성이 낮아집니다. 그렇기 때문에 응집도가 강하다라는 거는 안에서 으샤으시작 모든 걸 해결할 수 있다. 그러니까 우리끼리도 할 수 있어 독립성이 높아진다는 거죠. 자 그래서 응집도가 여기 아래 보면 7가지나 있죠. 이렇게 있는데, 이게 가장 응집도가 높고요. 강하고요. 그다음에 얘가 가장 응집도가 낮다 약하다 이렇게 보시면 됩니다. 이 순서도 기억을 하고 계셔야 돼요.

17:02
하나씩 보도록 할게요 실제로는 이제 코드로 예를 드는 게 제일 좋겠지만, 코드 자체가 이해가 어려울 수 있죠. 그렇기 때문에 코드가 아니라 이미지로 개념을 잡아볼 거예요. 일단은 가장 높은 게 기능적 응집도죠 하나의 문제를 해결하기 위해서 모든 기능 요소들이 뭉쳐있는 경우예요. 그래서 하나의 모듈은 딱 그 문제를 해결하기 위해서만 존재하는 경우죠 이걸 기능적 응집도라고 합니다. 어려운 개념이 아니죠. 그다음 순차적 응집도라고 되어 있어요. 모듈의 기능 수행으로 인한 출력 결과를 다른 모듈의 입력값으로 사용한다고 써 있죠. 자 여기 보시면 돼요. 이렇게 데이터가 들어왔어요. 이 데이터로 합계를 계산합니다. 그러면 합계 결과가 나오겠죠. 이 결과가 평균을 계산하는 모듈로 들어가는 겁니다.

17:58
요걸 순차적 응집도라고 해요. 순차적으로 계산한다는 얘기죠 이 계산 결과를 가지고 순차적으로 자 그 다음에 통신적 응집도예요. 동일한 입력을 기반으로 수행된 기능의 출력 결과를 그러니까 하나의 출력 결과를 이라는 뜻이에요. 서로 다른 기능을 수행하는 경우 이 결과를 여기다도 집어넣고 여기다도 집어넣어서 두 개의 기능을 수행할 수 있는지 수행할 수 있다라는 개념이죠. 이걸 통신적 응집도라고 합니다. 절차적 응집도 하나의 문제를 해결하기 위해서 여러 모듈들이 순차적으로 수행되는 경우라고 되어 있어요. 이게 단어가 좀 헷갈릴 수 있습니다. 위에서 보면 순차적 응집도라는 게 있죠. 그다음에 얘는 절차적 응집도예요. 무슨 차이인지 구분을 잘 하셔야 돼요.

18:54
자 순차적으로 어때요 기존에 있던 결과를 입력으로 쓴다고 되어 있잖아요. 합계 다음에 평균을 계산하는 건 맞아요. 여기도 마찬가지죠 요거 다음에 요거 다음에 요거를 수행하는 건 맞는데 차이점은 뭡니까? 결과를 입력으로 사용한다는 거예요. 얘는 결과를 입력으로 사용하지 않아요. 그냥 이거 다음에 이걸 할 뿐이죠. 그래서 이거는 절차라고 표현을 하는 거고, 이거는 순차라고 표현을 하는 겁니다. 2개의 차이점을 잘 구분하셔야 돼요. 그다음에 시간적 응집도 각 기능들의 연관성은 없지만, 특정 시기에 함께 수행되어야 하는 경우예요. 그러니까 꼭 절차적으로 이거 다음에 이걸 할 필요는 없어요. 이거 다음에 이거 하고 이걸 해도 돼요. 이거는 문제가 안 돼요. 항상 이 시기에 수행이 되어야 한다라는 게 특징입니다.

19:50
자 여기까지 그다음에 아래쪽 논리적 응집 또는 유사한 성격이나 형태를 가진 기능을 모아놓은 거예요. 서로 사실 상관은 없지만, 계산하는 형태가 다 같은 거죠. 여기 아래쪽에 보면 수학과 관련되어 있는 거잖아요. 근데 제곱근하고 절댓값 이거 두 개는 사실 구하는 데 서로 영향을 끼치는 건 아니거든요. 하지만 한 군데 모아놨다는 거죠. 논리적으로 이 부분이고요. 그다음에 마지막으로, 우연적 응집도입니다. 그러니까 말 그대로 의도하게 모아놓은 게 아니라 그냥 알아서 우연찮게 모였다는 거죠. 아무런 관련이 없는 경우예요. 모듈화의 이점이 전혀 없는 경우 당연히 다시 설계를 해보는 게 좋겠죠. 여기까지가 응집도구요. 다음은 결합도입니다. 오른쪽에 난리 났죠. 기출 파트예요. 결합도는 모듈과 모듈 간이에요.

20:46
응집 또는 모듈 안에서 얘기하는 거였죠 얘는 모듈 간 관련성이 의존성이 얼마나 깊은지를 나타내는 겁니다. 그러니까 결합도가 약해야 돼요. 그럼 서로 독립적이라는 뜻이니까. 그게 품질이 높다라고 판단할 수 있는 겁니다. 중요해요. 자 마찬가지 이것도 코드를 통해서 보면은 이해가 더 어려울 수 있기 때문에 이미지화 시킨 겁니다. 한번 볼게요 먼저 자료 결합도입니다. 자료 결합도 인수와 매개변수를 통해서만 상호작용이 일어나는 경우 요거를 자료 결합도라고 합니다. 자료만 왔다 갔다 한다는 거죠. 그래서 여기 보면은 인수랑 매개변수라는 개념이 나와 있죠. 아마 프로그래밍을 조금이라도 공부한 분들은 이게 무슨 뜻인지는 알 거예요. 데이터를 전달하고 전달받으면서만 서로 관련이 생긴다는 거죠.

21:42
여기 보면 도서대여 대여 요금 계산 요 2가지 모듈에서 서로 권수랑 대여 기간 대여 요금만 데이터로 주고받는 이런 형태예요. 현재 이상적인 형태죠 자 그다음은 스탬프 결합도예요. 스탬프라는 거는 동일한 자료 구조를 공유한다고 되어 있어요. 코드로 보면은 전달을 한다라는 표현이 사실 맞는데 어쨌든 동일한 자료 구조를 공유한다. 그래서 여기 보면 회원 등급이 추가됐죠 자 그래서 회원 등급을 예를 들어서 추가해서 서로 공유를 하고 있는데, 도서 대여를 많이 하면 등급이 오르잖아요. 그럼 여기서 예를 들어 등급을 상승시켰다고 생각을 해볼게요 골드 등급으로 상승을 시켰어요. 골드 상승을 시켰어요. 그리고 인제 요 권수랑 대여 기간을 이렇게 보냈습니다.

22:32
그럼 대여 요금 계산할 때 또 뭐가 있냐면은 등급별로 회원 등급별로 예를 들어서 요금이 좀 저렴하다든지 그럴 수 있잖아요. 요 계산 방식이 바뀌는 거예요. 이 하나의 요놈 때문에 그래서 여기서 변화시켰을 때 관련 있는 여기에서도 그 영향을 끼친다는 거죠. 이게 핵심입니다. 그래서 동일한 자료 구조를 공유하는 형태 변수를 공유하는 게 아니에요. 자료 구조를 공유하는 겁니다. 스탬프 거민이라고도 하는데 어쨌든 제어 결합도 위에랑 약간 비슷한 개념인데 여기서는 제어 요소라는 개념이 필요해요.

23:17
데이터만 전달하는 게 아니라 제어 요소도 함께 전달하는 경우다 제어 요소에 따라 대상 모듈의 처리 절차가 달라진다 라고 되어 있어요. 그래서 예를 들어서 어떤 도서를 대여한다고 하면 이 도서 재고 현황이라는 개념을 판단을 해서 재고가 있으면 1 재고가 없으면 0 이런 식으로 데이터를 주는 거예요. 그럼 이 0과 1은 실제 0과 1이 아니라 재고가 없다는 개념 또는 재고가 있다는 개념이죠. 재고가 있음 없음이 있다고 하면 있음 없음이라는 문자를 보내는 게 아니라 있으면 1 없으면 0 이렇게 보내는 거예요. 그러면 1을 확인했을 때 받은 애가 1을 확인했을 때 아 그러면 재고가 있으니까 도서를 대여할 수 있는 루틴을 실행하겠죠. 그런데 0을 전달받으면 재고가 없다라는 걸 알리는 루틴을 실행할 거예요.

24:17
그러니까 이 0과 1에 의해서 처리 절차 자체가 달라지는 거죠. 요걸 제어 결합도라고 합니다. 자 외부 결합도에요. 이번에는 인수의 전달이 없이 다른 모듈의 내부 데이터를 참조하는 경우예요. 원래 데이터를 넘겨줘야 되는데 그렇지 않고 그냥 직접 가서 외부에 있는 외부 모듈의 데이터를 참조하는 거 이게 외부 결합도고요. 그다음에 공유 결합도는 모듈 외부에 선언된 변수를 참조하는 거예요. 그래서 모듈이 있고 모듈이 있으면은 요 내부에 있는 걸 참조하는 게 아니라 이쪽에 있는 겁니다. 얘를 건드리는 거예요. 이걸 공유 결합도라고 하는 겁니다. 자 얘는 다른 모듈이 이렇게 있으면 마찬가지 여기에 접근할 수 있어요.

25:17
왜냐하면, 얘는 최상위 외부에 있는 거기 때문에 외부에 있는 걸 이렇게 건드릴 수 있기 때문에 여기 써 있어요. 관련 없는 모듈도 접근할 수 있기 때문에 문제가 발생할 가능성이 굉장히 커요 좋지 않은 거죠. 그 다음에 마지막으로, 다른 모듈의 내부 기능과 데이터를 다 직접 사용하는 경우예요. 가장 좋지 않고 의미가 없죠 서로 떨어뜨리는 의미가 여기저기 막 들락날락하는 거니까요? 다시 설계를 하는 게 좋다라고 되어 있습니다. 요것까지가 응집도 결합도에 대한 내용이에요. 문제 정말 자주 나옵니다. 그다음에 이제 복잡도에 보면 공유도와 제어도라는 게 나오죠. 이거 조금 헷갈릴 수 있어요. 내용이 많진 않지만 요것까지 좀 볼게요 공유도는 pen in이라고 되어 있죠. 인 자신을 호출하는 모듈의 수를 나타내는 거예요.

26:16
예를 들어서 a라는 모듈이 있다고 하면 아래쪽에 자세히 나오겠지만, 어떤 모듈이 호출 신호를 이렇게 보내는 거예요. 야 너 좀 쓰자 이렇게 생각을 하는 거죠. 그래서 이렇게 뭔가 신호가 들어온다고 해서 제어 신호가 들어온다고 해서 pene입니다. 공유도가 높은 경우에는 공통 모듈화 측면에서는 잘 설계되었다고 할 수 있다고 써있죠. 이모듈도 얘를 쓰고 이모듈도 얘를 쓰고 이 모듈도 얘를 쓴다고 하면 공통 모듈이 잘 설계가 된 거잖아요. 얘와 얘와 얘와 얘의 공통 기능이 모여 있는 거니까요? 그런데 실패하게 되면 예를 들어 a가 잘못 설계되면은 요 4가지 모듈을 다 못 쓰는 거죠. 그렇기 때문에 중점 관리가 필요하고요. 많은 테스트를 통해서 검증을 해야 돼요.

27:11
잘 만들어진 거지만 문제 단일 실패 지점 그러니까 이거 하나를 통해서 여러 가지가 다 오류가 날 수 있기 때문에 중점 관리가 필요하다 그 얘기고요. 그다음에 제어도라는 거는 아웃이죠. 이 반대예요. 어떤 모듈 b라고 하면요 b가 굉장히 화살표를 이걸로 할까요? 이렇게 요렇게 이렇게 또 하나 더 요렇게 많은 호출을 불러들인다는 거예요. 자 그래서 이렇게 되어 있을 때는 불필요한 업무 로직을 좀 단순화시킬 방법을 찾아봐야 돼요. 너무 뻗어나가기 때문에 자 그래서 위에는 중점 관리 아래는 단순화시켜야 된다. 이렇게 보면 됩니다. 대신에 어쨌든 공유도가 높은 게 사실 맞는 거죠. 공통 모듈화 측면에서는 그쵸. 요거가 포인트예요.

28:06
자 그래서 이거를 실제로 문제 나온다고 하면 이런 식으로 문제가 나올 거예요. 요렇게 이미지라든지 이런 느낌으로 주고 그다음에 특정 모듈의 공유도는 얼마인가 또는 제어도는 얼마인가 이렇게 물어봅니다. 이랬을 때 해석이 되어야 한다라는 거죠. 여기서 그러면 a를 기준으로 볼까요? 이 a의 공유도를 보자는 거죠. 공유도 공유도는 들어오는 거예요. 제어 신호가 들어오는 거 호출 신호가 들어오는 거 근데 들어오는 게 하나도 없죠 그러니까 0인 거고요. 얘가 호출 신호를 보내는 거 이렇게 이렇게 이렇게 세 개를 보내고 있잖아요. 그래서 3인 겁니다. b 모듈 c 모듈 d 모듈을 호출하고 있죠. a가 자 그래서 고렇게 들어가는 겁니다.

28:54
이런 식으로 해석을 하는 건데 실제로는 공유도가 몇인가 제어도가 몇인가 이렇게 물어봤을 때 빨리 계산하는 방법은 그냥 화살표를 보시면 돼요. 공유도 펜 인 들어오는 화살표가 몇 개냐 그다음에 펜아웃 나가는 화살표가 몇 개냐 이렇게 해석을 하시면 돼요. 그러면 0하고 3이 바로 나오죠. 이 정도로 해석이 가능하면 이해가 된 거다 라는 거죠. 아래쪽에도 제가 하이라이팅을 해놨습니다.