임베디드 시스템을 위한 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) 은 없는가 ?


• 인클루드 파일 분할의 지침을 의식하자–함수와 마찬가지로 응집도와 결합도를 고려해

분할


• 인클루드 파일에 관한 체크 항목 예– 인클루드 파일 내용이 ‘ ~ 을 ~ 하기 위한 정의

그룹’이라고 단순하게 표현할 수 있을것– 함수 내에서 참조하는 항목으로 필요 충분할 것

• 여분의 파라미터나 매크로의 정의가 없을 것• 불필요한 제어 플래그의 정의가 없을 것• 부족이 없을 것

– 계층 구조가 되어 있는 경우 하위 계층의 인클루드 파일이 다른 함수로부터 독립적으로 호출받는 구조를 가지지 않을 것


• 모듈 내부 구조를 단순하게 설계하자– 모듈의 정의가 단순해도 내부 처리가 복잡해지면 테스트의

용이성이나 유지 보수성이 저하• 모듈 스펙을 작성하고 필요 이상으로 복잡해지면 모듈 분할로 돌아가서

모듈의 역할과 관련 구조를 수정

• 사양서 작성시 참고– 함수의 인터페이스 ( 인수 , 반환값 , 외부 참조 ) 를 명시한다 .– 내부의 논리 구조를 알 수 있게끔 작성한다 .– 자신의 함수명이나 호출하는 함수명에 대해서는 영어명을 함께

적으면 좋다 .(???)– 프로그램 한 줄 한 줄에 해당하는 것은 작성하지 않는다 . ( 이것을 작성할 정도이면 프로그램을 작성하는 편이 났다 .)

• 감사합니다 .

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

Documents