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

1. 임베디드 시스템을 위한C프로그래밍 기법 2.1~2.3장 2014. 01. 17 권영완

2. 목차 • C언어의 일반적인 특징과 포인트 • 품질을 높이려면? 품질의 다양한 측면을 알자 • 품질을 높이려면? 견고한 설계를 하자

3. C언어의 일반적인 특징과 포인트 • 저 레벨의 처리를 기술할 수 있는 고급언어 • 프리 포맷 • 연속된 공백이나 개행은 의미 없음

4. C언어의 일반적인 특징과 포인트 • 타이핑 실수에 의해 의미가 다른 코드 • 선행처리기 • 잘 사용하면 가독성이 좋은 코드 • 그렇지 않으면 버그의 원인

5. C언어의 일반적인 특징과 포인트 • 데이터의 형변환 • 암묵적형변환이 허용되기 때문에 유연성이 부여됨 • 의도하지 않은 형변환이 발생할 수 있음

6. C언어의 일반적인 특징과 포인트 • 연산자의 우선순위 • 우선순위와 결합방향이 규정되어 있음 • 문법적으로 틀리지 않았지만 의도와 다른 결과가 나올 수 있음 • if (value & 0x06 == 0x04) • 독자적인 확장 • ANSI 표준사항이 정해져 있음 • 컴파일러에 따라서 독자적인 언어 사양으로 확장

7. 품질을 높이려면?품질의 다양한 측면을 알자 • 품질이란? • 대부분 신뢰성 품질을 뜻함 • 하지만 좋은 소프트웨어를 만들기 위해서는 다음을 고려해야 함 ISO/IEC 9126(JIS X 0129-1)

8. 품질을 높이려면?품질의 다양한 측면을 알자 • 기능성 품질 • 사양에서정한 제품의 가동조건, 즉 ‘지정된 조건’에서 기능, 조작, 속도, 반응등에 대해 사용자가 요구하는 기능을 만족시키고 있다. • 기능 실현에 모순점이 없다. • 다른 관련된 시스템과 문제없이 접속시킬 수 있다. • 표준 규격에 적합하다. • 필요 충분한 보안레벨을 가지고 있다. • 필요할 때면 언제든지 제품 사양상의 기능이나 성능을 얻을 수 있다. (언제든지 기대한 동작을 한다. 틀린 동작을 하지 않는다.)

9. 품질을 높이려면?품질의 다양한 측면을 알자 • 효율성 품질 • 실행 시간이 짧다. • CPU 클록을 낭비하지 않는다. • 소비 전력을 줄인다. • 메모리를 낭비하지 않는다.

10. 품질을 높이려면?품질의 다양한 측면을 알자 • 신뢰성 품질 • 프로그램의 오류 발생률이 낮다. • 프로그램에 잠재하고 있는 오류가 적다. • 이상한 조작을 하거나 예상 외의 데이터가 주어져도 망가지지 않는다. 망가진다 해도 최소한의 범위에서 멈춘다. • 제품 사양 범위 내의 어떠한 상황이나 조작에 의해서도 조작자를 포함한 사람, 임베디드 기기가 다루는 물건, 임베디드 기기가 내부적으로 가지고 있는 데이터, 임베디드 기기에 접속되어 있는 주변 기기에 나쁜 영향을 미치지 않는다. • 결함이 원인인 고장이 발생한 경우에 쉽게 복구할 수 있다.

11. 품질을 높이려면?품질의 다양한 측면을 알자 • 유지보수성 품질/이식성 품질 • 리뷰하기 쉽다. 구현 실수나 논리 실수, 데이터 설계 실수 등을 찾아내기 쉽니다 • 수정해야 하는 부분, 기능을 추가해야 하는 부분을 쉽게 알 수 있다. 수정 누락을 일으키기 어렵다. • 테스트하기 쉽다. 테스트 누락을 일으키기 어렵다.

12. 품질을 높이려면?품질의 다양한 측면을 알자 • 유지보수 • 프로그램의 기능을 파악하기 쉬울 것 • 모듈의 기능이 단순하다. • 모듈에 대한 인터페이스가 간단하여 다른 경로가 만들어질 여지가 없다. • 프로그램의 논리 구조를 파악하기 쉬울 것 • 들여쓰기, 공백, 중괄호를 적절히 사용 • 연산의 논리구조를 파악하기 쉬울 것 • 괄호를 적절히 사용 • 프로그램 길이가 적당할 것 • A4용지 한 장 정도가 이상적 • 적절한 주석이 있을 것 • 적절한 위치에, 적절한 양의 주석 • 데이터 구조를 파악하기 쉬울 것

13. 품질을 높이려면?품질의 다양한 측면을 알자 • 이식성이 문제가 되는 예 • 차세대 제품에 자료형이 다른 마이컴을 사용하게 되어 int의 비트 길이가 달라졌기 때문에 모든 코드를 수정했다. • 비슷한 제품에 소스 코드를 재사용하려고 했지만, 소스 코드의 여기저기에서 하드웨어 의존형 코드가 발견되어 결국 거의 대부분을 새로 작성하게 되었다.

14. 품질을 높이려면?품질의 다양한 측면을 알자 • 사용성 품질 • 사용하기 쉽거나 배우기 쉬울 것 • 사용하기 쉽거나 배우기 쉬운 점이 매력적일 것 • 제품 기획이나 그 직후의 상위 공정의 설계에 의존함 • 소프트웨어의 구조 설계나 프로그래밍에서 확보 불가

15. 품질을 높이려면?견고한 설계를 하자 • 모듈간 구조를 설계하자 • 좋은 모듈들의 집합으로 분할 하고 그들의 호출 구조를 정의 • 모듈의 기능과 입출력이 확정되면 모듈의 내부 처리를 기술 • 구조도를 작성하는 목적 • 명확하게 정의된 기능을 실행한다. • 내용을 이해하기 쉽다. • 테스트하기 쉽다. • 유지보수하기 쉽다. • 재사용하기 쉽다. • 범용성이 높다

16. 품질을 높이려면?견고한 설계를 하자 • 모듈응집도를 생각하자 • 모듈(함수)의 기능이 얼마나 단순한가에 대한 지표 • 함수의 기능을 ‘~을 ~한다.’라고 단순하게 정의할 수 있으면 응집도가 높은 함수 • 너무 작은 단위로 분할하지 말 것 • 실행 속도가 저하되는 부작용 • 한곳에서만 호출된다면 그곳으로 흡수 • 여러 곳에서 호출되는 1~2줄 짜리 함수는 매크로함수로

17. 품질을 높이려면?견고한 설계를 하자 • 모듈결합도를 생각하자 • 인터페이스의 관점에서 모듈(함수)을 평가하는 지표 • 모듈의 기능을 수행하는데 필요 충분하면서도 영향 범위가 한정된 단순한 데이터나 플래그를 주고 받는지 여부 • 전역 변수는 편리하지만 모듈 결합도의 관점에서 보면 사용하지 않는 것이 좋음

18. 품질을 높이려면?견고한 설계를 하자 • 모듈분할의 지침을 의식하자 • 조직이나 프로젝트 별로 모듈 분할에 대한 지침을 정리 • 설계 시간을 절약 • 설계의 품질을 일정하게 유지 • 모듈 분할 시 고려할 항목 • 추상도가 높은 처리를 상위 층으로 • 하드웨어나 데이터 저장과 같이 시스템 자원을 사용하는 처리를 하위층으로 • 테스트 항목도 미리 고려 • 모듈의 스펙을 근거로 제어 경로 테스트나 경계값 테스트 설계

19. 품질을 높이려면?견고한 설계를 하자 • 함수명/함수의 내용에 관한 체크 항목 예 • 복수의 모듈에서 같은 기능을 정의하고 있지는 않는가? • 함수의 기능을 ‘~을 ~한다.’라고 단순하게 말할 수 있는가? • 함수로의 입력 파라미터는필요 충분한가? • 여분의 파라미터나 값을 주고받고 있지는 않은가? • 불필요한 제어 플래그를 주고받고 있지는 않은가? • 함수로의 입력 파라미터는 명확하게 정의되어 있는가? • 함수의 반환값은 명확하게 정의되어 있는가? • 전역 변수로의 참조는 존재하지 않는가? • 함수의 처리 내용이 적절한가?(프로그램으로서 적절한 행(Line)수인가?)

20. 품질을 높이려면?견고한 설계를 하자 • 함수 상호간의 연관성에 관한 체크 항목 예 • 하드웨어로의 액세스가 일부의 함수에 한정되어 있는가? (사양 변경이나 하드웨어의 변경에 대해서 쉽게 대응할 수 있는가?) • 함수간 인터페이스에 부정합(Mismatching)은 없는가?

21. 품질을 높이려면?견고한 설계를 하자 • 인클루드 파일분할의 지침을 의식하자 • 함수와 마찬가지로 응집도와결합도를 고려해 분할

22. 품질을 높이려면?견고한 설계를 하자 • 인클루드 파일에 관한 체크 항목 예 • 인클루드 파일 내용이 ‘~을 ~하기 위한 정의 그룹’이라고 단순하게 표현할 수 있을것 • 함수 내에서 참조하는 항목으로 필요 충분할 것 • 여분의 파라미터나 매크로의 정의가 없을 것 • 불필요한 제어 플래그의 정의가 없을 것 • 부족이 없을 것 • 계층 구조가 되어 있는 경우 하위 계층의 인클루드 파일이 다른 함수로부터 독립적으로 호출받는 구조를 가지지 않을 것

23. 품질을 높이려면?견고한 설계를 하자 • 모듈내부 구조를 단순하게 설계하자 • 모듈의 정의가 단순해도 내부 처리가 복잡해지면 테스트의 용이성이나 유지 보수성이 저하 • 모듈 스펙을 작성하고 필요 이상으로 복잡해지면 모듈 분할로 돌아가서 모듈의 역할과 관련 구조를 수정 • 사양서 작성시 참고 • 함수의 인터페이스(인수, 반환값, 외부 참조)를 명시한다. • 내부의 논리 구조를 알 수 있게끔 작성한다. • 자신의 함수명이나 호출하는 함수명에 대해서는 영어명을 함께 적으면 좋다.(???) • 프로그램 한 줄 한 줄에 해당하는 것은 작성하지 않는다. (이것을 작성할 정도이면 프로그램을 작성하는 편이 났다.)

24. 감사합니다.