임베디드 소프트웨어 설계

11

RTOS를 사용하여 임베디드 소프트웨어 프로그래밍을 시작하고 있으며 이미 데스크탑 응용 프로그램 개발자이기 때문에 활동 다이어그램, 시퀀스 다이어그램, 사용 사례 등과 같은 UML 다이어그램을 사용하여 임베디드 소프트웨어를 모델링하는 것이 어떤지 궁금합니다.

임베디드 소프트웨어는 데스크탑 애플리케이션과 동일한 방식으로 UML을 사용하여 설계 되었습니까? 최선의 선택입니까 아니면 더 좋은 선택입니까? 몇 가지 예를 들어 주시겠습니까?

이를 수행하는 특정 도구가 있습니까?

embedded software

— 카시오
소스

8

임베디드 응용 프로그램에 대한 구체적인 내용은 없습니다. 특별한 것은 자원 제한적 애플리케이션 이며, 이러한 제한 중 가장 일반적인 것은 타이밍 제한 (예 : 어려운 실시간 요구 사항)입니다. 신청 요건에 대해 더 자세히 알려 주시면 구체적인 답변을 드릴 수 없습니다.

— Wouter van Ooijen

3

리소스 제한 애플리케이션에 대한 @Wouter의 의견에 전적으로 동의하지만 RTOS 및 소프트 스케쥴 된 데스크톱 개발 환경을 사용하는 것과 관련된 특정 디자인의 뉘앙스가 있다고 생각합니다.

— HikeOnPast

1

임베디드 시스템을 과도하게 엔지니어링하지 않도록주의하십시오. "왕의 토스터"도 참조하십시오 ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl-동의하지 않습니다. 첫째, 공간을 갖춘 소프트웨어를 설계 할 때 너무 많은주의를 기울일 수 있다고 생각하지 않습니다 . 둘째, 킹의 토스터에 대한 엔지니어의 접근 방식은 빵이 너무 많이 태워지는 이유입니다. 대부분의 토스트기는 실제로 사소한 일에 비해 너무 단순합니다.

— Rocketmagnet

1

@Cassio : 저는 Wouter와 함께 있습니다. 문제를 직접 분석 한 다음 적절하다고 생각되는 시스템을 사용하여 중요한 부분을 매핑해야합니다. 문제를 분석하기 전에 표현을 선택할 때 발생하는 문제는 특정 방식으로 문제가 표시되는 것입니다. UML은 엔터프라이즈 소프트웨어에 뿌리를 둔 표현이며 엔터프라이즈 소프트웨어와 같은 임베디드 소프트웨어를 설계하는 것을 원치 않습니다.

— drxzcl

8

UML에 대한 실시간 확장 기능은 현재 이름에서 벗어나는 회사에 의해 대중화되었습니다. 몇 년 전에 논문을 작성했던 것을 기억합니다. Bruce Powell Douglass는 UML을 사용하여 임베디드 시스템을 모델링하는 주제에 대해 몇 권의 책을 썼지 만 그의 회사는 내가 생각하는 것이 아닙니다.

Wouter를 반향하기 위해 임베디드 소프트웨어 자체에는 특별한 것이 없습니다. 저는 펜티엄 급 프로세서에서 실행되는 시스템을 위해 매일 임베디드 소프트웨어를 작성합니다. UML이 적용 가능합니다. 또한 제어 소프트웨어의 많은 측면이 시간이 지남에 따라 UML에 추가되었다는 것을 기억하십시오. 시퀀스 다이어그램에는 응답 시간과 함께 동기 또는 비동기 이벤트를 지정하는 구문이 있으며, 활동 다이어그램에서 페트리 넷 유형 동작을 찾을 수 있으며, 상태 차트 모델 동작이 훨씬 우수합니다. 상태 다이어그램 등보다

OTOH는 많은 사람들이 Structured Design 및 Dataflow 개념을 사용하여 임베디드 소프트웨어를 모델링하는 것을 선호합니다. 설계하려는 시스템 유형과 가장 적합한 시스템에 관한 것입니다.

— 린든
소스

감사합니다 @lyndon. 그러나 매일 임베디드 소프트웨어를 어떻게 모델링합니까? 활동 다이어그램, 상태 머신 및 시퀀스 다이어그램이 트릭을 수행 할 것이라고 생각하십니까? 실제로 설계 대상에 대한 개념을 찾은 다음 임베디드 시스템에 대한 설계 문서가있는 경우 설계 문서에 삽입하기 위해 수행해야 할 회로도는 무엇입니까?

— Cassio

내가 볼 수있는 가장 빈번한 구성은 일상적인 사용을위한 상태 다이어그램 / 상태 차트 및 시퀀스 다이어그램입니다. 솔직히 우리는 클래스 다이어그램을 더 많이 활용할 수 있다고 생각하지만 사람들은 방대한 "신 (神) 객체"를 만드는 경향이 있다는 것을 알게되었습니다. 오, 내가 생각한 회사는 Artisan Software입니다. 이 링크는 정보 일 수 있습니다 werner.yellowcouch.org/Papers/rtuml/index.html#toc7을

— 린든

5

RTOS로 전환 할 때 일반적으로 각 마감 시간을 맞추거나 리소스를 안전하게 공유하기 위해 최적으로 예약해야하는 많은 동시 작업이있는 응용 프로그램을 처리합니다. 선택한 RTOS 프레임 워크는 작업 스케줄러를 구현하며, 작업 (일반적으로)은 이러한 개별 작업을 특정 속성 집합 (기간, 우선 순위 등)으로 작성한 다음 스케줄러로 전달하는 것입니다. 따라서 문서화의 경우 각 작업을 신중하게 문서화하는 것이 좋습니다.

대부분의 임베디드 소프트웨어와 내가 아는 한 대부분의 RTOS는 객체 지향 언어로 작성되지 않았으므로 클래스 다이어그램과 같은 것들에 맞춰진 많은 것들로부터 이익을 얻지 못할 수 있습니다.

그러나 RTOS 작업을 문서화 할 때 작업을 잘 설명하는 다이어그램이 큰 도움이됩니다. 각 작업의 시퀀스 다이어그램이 예를 들어 매우 도움이 될 수 있다고 생각합니다. 이와 함께 기간 / 빈도, 우선 순위, 사용할 수있는 공유 리소스, 선점 요구 사항 등과 같은 어려운 요구 사항을 지정할 수 있습니다. 또한 RTOS를 구성한 방법과 상태를 문서화하는 것이 중요 할 수 있습니다. 스케줄링 알고리즘의 기계.

그러나 여러분이 좋아하는이 조언 중 하나를 취하십시오. 저는 대학 시절 이래로 RTOS를 엉망으로 만들지 않았으며 실제로 그 작업을 "문서화"하지 않았습니다.

— 존 엘
소스

감사합니다 @JonL. 멋진 디자인 문서를 얻으려면 응용 프로그램과 관련된 작업을 디자인해야합니까? 또한 예약 알고리즘에 익숙하지 않으므로 처리 할 필요가 없습니다. RTEMS를 사용하고 있습니다.

— Cassio

@Cassio, 나는 당신에게 어떤 일을하라고 말하지 않고 있으며, 그것은 당신에게 달려 있습니다. 필요한 것을 해보십시오. RTOS에 익숙하지 않다면 먼저 RTOS를 시작하고 사용 방법을 시작하는 것이 좋습니다. 그런 다음 주변 작업을 디자인 할 수 있습니다.

— Jon L

예, 여전히 RTOS 기능에 익숙합니다. 그리고 제안 된 접근법에 감사드립니다! 할거야! 이전에 말했듯이 임베디드 소프트웨어를 처음 사용하므로 실제로 무엇이 필요한지 잘 모르겠습니다. 임베디드 소프트웨어 아키텍처 또는 디자인 문서가 있으면 좋을 것입니다. 그 중 하나를 원하십니까?

— Cassio

"대부분의 RTOS는 객체 지향 언어로 작성되지 않았습니다." 그러나 실시간 모델링 및 구현 과정에서는 C ++에서 단순 (비선 점형) RTOS를 사용합니다.

— Wouter van Ooijen

5

모델링은 모두

애플리케이션에서 어떤 측면이 어렵고 복잡한 지 알고
해당 측면에 적합한 모델링 도구 / 언어 / 추상 / 컨벤션 / 표기 찾기
그 측면을 디자인

따라서 모든 상황에 적합한 모델링 도구 / 접근법 등은 없습니다. 위성은 아마도 하나 이상의 프로세서를 가진 실시간 멀티 태스킹 시스템 일 것입니다. 작업 구조 다이어그램, STD 및 시퀀스 다이어그램은 아마도 유용 할 것입니다 (몇 가지 예를 들면). 프로젝트가 C에서 수행되면 클래스 다이어그램은 유용하지 않을 것입니다 (매우 유용하다고 판명되면 C 선택이 잘못되었을 수 있습니다). 나는 UseCases를 좋아하지 않으며 위성 an-sich에는 사용자가 없습니다. 비 기술 사용자와 시스템 요구 사항을 논의하려는 상황에서 사용 사례가 가장 적합합니다. 그것이 위성 프로젝트와 관련된 상황이라면 무언가 잘못되었습니다.

— Wouter van Ooijen
소스

감사합니다 @Wouter. 당신은 저에게 새로운 개념을 소개했습니다 : Task Structure Diagrams, nice! 따라서 C에 있습니다. UseCases가 아닌 경우 모든 요구 사항이 포함 된 문서에 대해 무엇을 원하십니까?

— Cassio

IMO는 테스트 사례를 기반으로 할 경우 식별 가능하고 거의 단일 용도 요구 사항의 목록이 필요합니다. 나에게 UseCases는 그러한 목록을 얻는 방법 일뿐입니다. 어떤 경우에는 좋은 방법입니다.

— Wouter van Ooijen

1

공간이 충분한 것을 설계하지 않았습니다. 그러나 저는 국방부 항공 우주 하청 업체에서 근무했으며 많은 설계가 비행 자격을 갖추 었습니다. 디자인에 대한 많은 문서가 필요하며 원하는 것을 정확하게 설명하는 DID (데이터 항목 설명)를 제공합니다.

DoD ASSIST 빠른 검색 을 사용하여 "제목의 단어"필드에 "소프트웨어"를 입력하고 제출을 클릭하면 필요할 수있는 문서에 대한 모든 DID를 볼 수 있습니다. (DoD 사이트가 인증서 보안 경고를 던지는 것이 재미 있다고 생각하지만 안전합니다.)

설계 문서에 대해 구체적으로 물어 보면 여기 SDD ( Software Design Description ) DID가 있습니다. 디자인의 각 부분을 설명하기 위해 단어 사용을 강조합니다. 그러나 UML, 상태 다이어그램, 플로우 차트, 의사 코드 등을 사용하여 디자인에 대한 이해를 향상시킬 수 있다면 물론 포함시켜야합니다.

다른 모델링에서 언급했듯이 어떤 모델링 방법을 선택 하느냐는 디자인에 달려 있습니다. 그러나 우주 항공 소프트웨어 용 DID를 보는 것은 프로젝트가 공간과 관련이 있기 때문에 설계 문서를 작성하는 데 도움이 될 수 있다고 생각했습니다.

— embed.kyle
소스