Transcript 임베디드 시스템을 위한 C프로그래밍 기법

임베디드 시스템을 위한
C프로그래밍 기법
2.1~2.3장
2014. 01. 17
권영완
목차
• C언어의 일반적인 특징과 포인트
• 품질을 높이려면? 품질의 다양한 측면을 알자
• 품질을 높이려면? 견고한 설계를 하자
C언어의 일반적인 특징과 포인트
• 저 레벨의 처리를 기술할 수 있는 고급언
어
• 프리 포맷
– 연속된 공백이나 개행은 의미 없음
if (value1 == 1) {
value2 = 2;
}
if
(value1 == 1)
{value2 = 2;}
if(value1==1){value2
=2;}
C언어의 일반적인 특징과 포인트
– 타이핑 실수에 의해 의미가 다른 코드
if (a == b) {
/* 처리 */
}
if (a>b) y = 1;
a = 1;
if (a = b) {
/* 처리 */
}
if (a>b); y=1;
a == 1;
• 선행처리기
– 잘 사용하면 가독성이 좋은 코드
– 그렇지 않으면 버그의 원인
C언어의 일반적인 특징과 포인트
• 데이터의 형변환
– 암묵적 형변환이 허용되기 때문에 유연성이
부여됨
– 의도하지 않은 형변환이 발생할 수 있음
명시적 형변환
암묵적 형변환
int iparam;
double dparam;
dparam = (double)iparam;
int iparam;
double dparam;
dparam = iparam;
C언어의 일반적인 특징과 포인트
• 연산자의 우선순위
– 우선순위와 결합방향이 규정되어 있음
– 문법적으로 틀리지 않았지만 의도와 다른 결과가
나올 수 있음
• if (value & 0x06 == 0x04)
• 독자적인 확장
– ANSI 표준사항이 정해져 있음
– 컴파일러에 따라서 독자적인 언어 사양으로 확장
품질을 높이려면?
품질의 다양한 측면을 알자
• 품질이란?
– 대부분 신뢰성 품질을 뜻함
– 하지만 좋은 소프트웨어를 만들기 위해서는
다음을 고려해야 함
ISO/IEC 9126(JIS X 0129-1)
품질 특성
프로그래밍에 의해 품질이 크게 좌우된다
기능성(functionality)
O (주요 원인은 아니지만 영향이 크다)
효율성(efficiency)
O
신뢰성(reliability)
O
유지보수성(maintainability)
O
사용성(usability)
이식성(portability)
O
품질을 높이려면?
품질의 다양한 측면을 알자
• 기능성 품질
– 사양에서 정한 제품의 가동조건, 즉 ‘지정된 조건’
에서 기능, 조작, 속도, 반응 등에 대해 사용자가
요구하는 기능을 만족시키고 있다.
– 기능 실현에 모순점이 없다.
– 다른 관련된 시스템과 문제없이 접속시킬 수 있다.
– 표준 규격에 적합하다.
– 필요 충분한 보안 레벨을 가지고 있다.
– 필요할 때면 언제든지 제품 사양상의 기능이나 성
능을 얻을 수 있다.
(언제든지 기대한 동작을 한다. 틀린 동작을 하지 않는다.)
품질을 높이려면?
품질의 다양한 측면을 알자
• 효율성 품질
– 실행 시간이 짧다.
– CPU 클록을 낭비하지 않는다.
– 소비 전력을 줄인다.
– 메모리를 낭비하지 않는다.
품질을 높이려면?
품질의 다양한 측면을 알자
• 신뢰성 품질
– 프로그램의 오류 발생률이 낮다.
– 프로그램에 잠재하고 있는 오류가 적다.
– 이상한 조작을 하거나 예상 외의 데이터가 주어져도
망가지지 않는다. 망가진다 해도 최소한의 범위에서
멈춘다.
– 제품 사양 범위 내의 어떠한 상황이나 조작에 의해서
도 조작자를 포함한 사람, 임베디드 기기가 다루는 물
건, 임베디드 기기가 내부적으로 가지고 있는 데이터,
임베디드 기기에 접속되어 있는 주변 기기에 나쁜 영
향을 미치지 않는다.
– 결함이 원인인 고장이 발생한 경우에 쉽게 복구할 수
있다.
품질을 높이려면?
품질의 다양한 측면을 알자
• 유지보수성 품질/이식성 품질
– 리뷰하기 쉽다. 구현 실수나 논리 실수, 데이
터 설계 실수 등을 찾아내기 쉽니다
– 수정해야 하는 부분, 기능을 추가해야 하는 부
분을 쉽게 알 수 있다. 수정 누락을 일으키기
어렵다.
– 테스트하기 쉽다. 테스트 누락을 일으키기 어
렵다.
품질을 높이려면?
품질의 다양한 측면을 알자
• 유지보수
– 프로그램의 기능을 파악하기 쉬울 것
• 모듈의 기능이 단순하다.
• 모듈에 대한 인터페이스가 간단하여 다른 경로가 만들어질 여지
가 없다.
– 프로그램의 논리 구조를 파악하기 쉬울 것
• 들여쓰기, 공백, 중괄호를 적절히 사용
– 연산의 논리구조를 파악하기 쉬울 것
• 괄호를 적절히 사용
– 프로그램 길이가 적당할 것
• A4용지 한 장 정도가 이상적
– 적절한 주석이 있을 것
• 적절한 위치에, 적절한 양의 주석
– 데이터 구조를 파악하기 쉬울 것
품질을 높이려면?
품질의 다양한 측면을 알자
• 이식성이 문제가 되는 예
– 차세대 제품에 자료형이 다른 마이컴을 사용
하게 되어 int의 비트 길이가 달라졌기 때문에
모든 코드를 수정했다.
– 비슷한 제품에 소스 코드를 재사용하려고 했
지만, 소스 코드의 여기저기에서 하드웨어 의
존형 코드가 발견되어 결국 거의 대부분을 새
로 작성하게 되었다.
품질을 높이려면?
품질의 다양한 측면을 알자
• 사용성 품질
– 사용하기 쉽거나 배우기 쉬울 것
– 사용하기 쉽거나 배우기 쉬운 점이 매력적일
것
– 제품 기획이나 그 직후의 상위 공정의 설계에
의존함
• 소프트웨어의 구조 설계나 프로그래밍에서 확보
불가
품질을 높이려면?
견고한 설계를 하자
• 모듈간 구조를 설계하자
– 좋은 모듈들의 집합으로 분할 하고 그들의 호출 구조를 정
의
– 모듈의 기능과 입출력이 확정되면 모듈의 내부 처리를 기
술
• 구조도를 작성하는 목적
–
–
–
–
–
명확하게 정의된 기능을 실행한다.
내용을 이해하기 쉽다.
테스트하기 쉽다.
유지보수하기 쉽다.
재사용하기 쉽다.
• 범용성이 높다
품질을 높이려면?
견고한 설계를 하자
• 모듈 응집도를 생각하자
– 모듈(함수)의 기능이 얼마나 단순한가에 대한
지표
– 함수의 기능을 ‘~을 ~한다.’라고 단순하게 정
의할 수 있으면 응집도가 높은 함수
– 너무 작은 단위로 분할하지 말 것
• 실행 속도가 저하되는 부작용
• 한곳에서만 호출된다면 그곳으로 흡수
• 여러 곳에서 호출되는 1~2줄 짜리 함수는 매크로
함수로
품질을 높이려면?
견고한 설계를 하자
• 모듈 결합도를 생각하자
– 인터페이스의 관점에서 모듈(함수)을 평가하
는 지표
• 모듈의 기능을 수행하는데 필요 충분하면서도 영
향 범위가 한정된 단순한 데이터나 플래그를 주고
받는지 여부
– 전역 변수는 편리하지만 모듈 결합도의 관점
에서 보면 사용하지 않는 것이 좋음
품질을 높이려면?
견고한 설계를 하자
• 모듈 분할의 지침을 의식하자
– 조직이나 프로젝트 별로 모듈 분할에 대한 지침을 정
리
• 설계 시간을 절약
• 설계의 품질을 일정하게 유지
• 모듈 분할 시 고려할 항목
– 추상도가 높은 처리를 상위 층으로
– 하드웨어나 데이터 저장과 같이 시스템 자원을 사용
하는 처리를 하위층으로
– 테스트 항목도 미리 고려
• 모듈의 스펙을 근거로 제어 경로 테스트나 경계값 테스트 설
계
품질을 높이려면?
견고한 설계를 하자
• 함수명/함수의 내용에 관한 체크 항목 예
– 복수의 모듈에서 같은 기능을 정의하고 있지는 않는
가?
– 함수의 기능을 ‘~을 ~한다.’라고 단순하게 말할 수 있
는가?
– 함수로의 입력 파라미터는 필요 충분한가?
• 여분의 파라미터나 값을 주고받고 있지는 않은가?
• 불필요한 제어 플래그를 주고받고 있지는 않은가?
–
–
–
–
함수로의 입력 파라미터는 명확하게 정의되어 있는가?
함수의 반환값은 명확하게 정의되어 있는가?
전역 변수로의 참조는 존재하지 않는가?
함수의 처리 내용이 적절한가?(프로그램으로서 적절
한 행(Line)수인가?)
품질을 높이려면?
견고한 설계를 하자
• 함수 상호간의 연관성에 관한 체크 항목
예
– 하드웨어로의 액세스가 일부의 함수에 한정되
어 있는가? (사양 변경이나 하드웨어의 변경에
대해서 쉽게 대응할 수 있는가?)
– 함수간 인터페이스에 부정합(Mismatching)은
없는가?
품질을 높이려면?
견고한 설계를 하자
• 인클루드 파일 분할의 지침을 의식하자
– 함수와 마찬가지로 응집도와 결합도를 고려해
분할
품질을 높이려면?
견고한 설계를 하자
• 인클루드 파일에 관한 체크 항목 예
– 인클루드 파일 내용이 ‘~을 ~하기 위한 정의 그룹’
이라고 단순하게 표현할 수 있을것
– 함수 내에서 참조하는 항목으로 필요 충분할 것
• 여분의 파라미터나 매크로의 정의가 없을 것
• 불필요한 제어 플래그의 정의가 없을 것
• 부족이 없을 것
– 계층 구조가 되어 있는 경우 하위 계층의 인클루
드 파일이 다른 함수로부터 독립적으로 호출받는
구조를 가지지 않을 것
품질을 높이려면?
견고한 설계를 하자
• 모듈 내부 구조를 단순하게 설계하자
– 모듈의 정의가 단순해도 내부 처리가 복잡해지면 테스트의
용이성이나 유지 보수성이 저하
• 모듈 스펙을 작성하고 필요 이상으로 복잡해지면 모듈 분할로
돌아가서 모듈의 역할과 관련 구조를 수정
• 사양서 작성시 참고
– 함수의 인터페이스(인수, 반환값, 외부 참조)를 명시한다.
– 내부의 논리 구조를 알 수 있게끔 작성한다.
– 자신의 함수명이나 호출하는 함수명에 대해서는 영어명을
함께 적으면 좋다.(???)
– 프로그램 한 줄 한 줄에 해당하는 것은 작성하지 않는다.
(이것을 작성할 정도이면 프로그램을 작성하는 편이 났다.)
• 감사합니다.