내 머리속 지우개

임베디드 소프트웨어 아키텍처에도 패턴이 적용될 수 있습니다.이번 포스팅에서는 임베디드 소프트웨어 아키텍처에적용될 수 있는 기본적인 패턴에 대해 알아 보겠습니다.   임베디드 소프트웨어 아키텍처 패턴 개요아키텍처 패턴은 좋은 설계 관행에 대한 추상적이고 스타일화된 설명으로, 시스템 아키텍처의 구조와 적용 시점, 장점 및 단점을 이해하는 데 중요한 정보를 제공합니다. 이러한 패턴은 단순히 일반적인 디자인을 인스턴스화하는 것이 아니라, 특정 아키텍처를 이해하고 이를 기반으로 자신만의 구체적인 설계를 만들기 위한 출발점으로 사용되어야 합니다. 임베디드 소프트웨어와 인터랙티브 소프트웨어의 차이로 인해, 임베디드 시스템에서는 프로세스 중심의 아키텍처 패턴이 사용됩니다. 여기서는 세 가지 일반적으로 사용되는 실시간 ..

소프트웨어 공학 관점에서는 임베디드 소프트웨어를 어떻게 볼 수 있을까요?임베디드 소프트웨어에는 몇가지 특징이 있기 때문에,이를 소프트웨어 공학점 관점에서는 고려해야 할 중요한 요소라 할 수 있습니다.이번 포스팅에서는 소프트웨어 공학 관점에서 임베디드 소프트웨어 모델링에 대해 알아 보겠습니다.      임베디드 소프트웨어 개요오늘날 컴퓨터는 단순한 가정용 기기부터 게임 컨트롤러, 자동차, 비행기, 그리고 대규모 제조 공장까지 다양한 시스템을 제어하는 데 활용됩니다. 이때 컴퓨터는 하드웨어와 직접 상호작용하며, 소프트웨어는 하드웨어에서 발생하는 이벤트에 반응해 적절한 제어 신호를 보내게 됩니다. 이러한 시스템에서 사용하는 소프트웨어를 임베디드 소프트웨어라고 하며, 주로 하드웨어에 내장된 형태로, 읽기 전용 ..

CBSE의 중요한 개념은 컴포지션입니다.컴포지션을 통해 또 다른 새로운 컴포넌트를 생성할 수 있어요.이번 포스팅에서는 컴포지션의 개념에 대해 살펴 보도록 할게요.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.  컴포넌트 컴포지션은 컴포넌트와 특별히 작성된 ’글루 코드(glue code)’를 서로 통합하여 시스템이나 다른 컴포넌트를 만드는 과정입니다. 컴포넌트 컴포지션 방법에는 여러 가지가 있으며, 다음 17.10에서 그 예를 보여주고 있습니다. 왼쪽에서 오른쪽으로 차례로 순차적 컴포지션, 계층적 컴포지션, 그리고 부가적 컴포지션성을 나타냅니다. 아래의 논의에서는 두 개의 컴포넌트(A와 B)를 결합하여 새로운 컴포넌트를 ..

컴포넌트 기반 소프트웨어 개발 방법론은소프트웨어 재사용이란 주제에서 출발한 개념인걸 아셨나요?이번 포스팅에서는 컴포넌트 기반 소프트웨어 공학, CBSE 개념에 대해 알아 보겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 1. 컴포넌트 기반 소프트웨어 공학 (Component-based Software Engineering)컴포넌트 기반 소프트웨어 공학(CBSE)은 1990년대 후반에 소프트웨어 컴포넌트의 재사용을 기반으로 한 소프트웨어 시스템 개발 접근 방식으로 등장했습니다. CBSE의 탄생은 객체 지향 개발이 처음 제안되었을 때 예상했던 광범위한 재사용으로 이어지지 않았다는 디자이너들의 좌절에서 비롯되었습니다...

소프트웨어 신뢰성에 대한 정의는 정의를 내리는 사람 또는 기관에 따라 약간씩 다르게 정의되고 있습니다.먼저 1992년 미국의 AIAA (American Institute of Aeronautics and Astronautics)의 정의에 따르면,"The ability of a system or component to perform its required functions under stated conditions for a specified period of time." (특정 시간 동안 정해진 환경 조건하에서 요구되는 기능을 수행하기 위한 시스템 또는 컴포넌트들의 능력) (by ANS/AIAA R-013-1992) 로 되어 있습니다. 최근 새롭게 정의된 개념은 소프트웨어 시험(테스팅)에 보다 중점을 둔..

목차  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.재사용 기반 소프트웨어 공학(Reuse-based software engineering)은 기존 소프트웨어를 재사용하는 것에 중점을 둔 소프트웨어 개발 전략입니다. 비록 재사용이 개발 전략으로 제안된 것은 40년 이상 전이었지만(McIlroy, 1968), 실제로 2000년 이후에야 ‘재사용을 통한 개발’이 새로운 비즈니스 시스템의 표준이 되었습니다. 재사용 기반 개발로의 전환은 소프트웨어 생산 및 유지보수 비용을 줄이고, 시스템을 더 빠르게 제공하며, 소프트웨어 품질을 향상시키려는 요구에 대응하기 위해 이루어졌습니다.  재사용 가능한 소프트웨어의 가용성은 과거에 비해 많..

요구사항을 추출하고 분석하는 것도 매우 어려운 일이지만,요구사항을 검증하고 관리하는 것 역시 쉽지 않습니다.이미 잘 알려진 내용이지만, 가볍게 한번 살펴 보겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.  요구사항 확인 (Requirements Validation)요구사항 확인은 요구사항이 실제로 고객이 원하는 시스템을 정의하고 있는지 확인하는 과정입니다. 이 과정은 요구사항 분석과 겹치는 부분이 있으며, 요구사항의 문제를 찾는 데 중점을 둡니다. 요구사항 문서에 오류가 있는 경우, 개발 중이나 시스템이 서비스에 들어간 후 문제가 발견되면 광범위한 재작업 비용이 발생할 수 있기 때문에 요구사항 검증은 매우 중요합..

요구사항 추출 및 분석은 소프트웨어 공학에서 아주 중요한 활동입니다.하지만 요구사항 추출 및 분석에 어떤 방법이 사용되는지 정리된 내용이 많이 부족합니다.이번 포스팅에서는 요구사항 추출 및 분석 방법에 대해 살펴 보겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 요구사항 추출 및 분석 (Requirements Elicitation and Analysis)요구 사항 추출 및 분석은 소프트웨어 엔지니어들이 고객 및 시스템 최종 사용자와 협력하여 애플리케이션 도메인, 시스템이 제공해야 하는 서비스, 시스템의 요구 성능, 하드웨어 제약 조건 등을 파악하는 활동입니다. 요구 사항 추출 및 분석에는 조직 내에서 다양한 사람..

이번 포스팅에서는 요구사항 문서화에 대해 알아 보려고 합니다.요구사항 문서화는 자연어, 다이어그램, 그리고 수학식과 같은 다양한 방법이 사용됩니다.결과적으로 문서화 역시 쉽지 않은 분야이며, 많은 노력이 요구되는 분야입니다.자세한 내용을 살펴 보도록 하겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 소프트웨어 요구사항 문서 (Software Requirements Document)소프트웨어 요구 사항 문서(종종 소프트웨어 요구 사항 명세서 또는 SRS(Software Requirements Specification)라고 불림)는 시스템 개발자가 구현해야 할 내용을 공식적으로 명시하는 문서입니다. 이 문서에는 시스..

대학 시절 배웠던 "소프트웨어 공학" 교재를 다시 한번 읽어보기로 했어요.천천히 정리하면서 중간중간 경험적 내용을 추가하면 아주 좋은 기록이 될거 같네요.이번 포스팅에서는 요구공학과 소프트웨어 요구사항에 대해 알아 볼게요.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.   1. 사용자 요구사항과 시스템 요구사항소프트웨어 시스템 요구 사항은 시스템이 수행해야 하는 작업, 제공해야 하는 서비스, 그리고 운영에 대한 제약 조건을 설명합니다.이러한 소프트웨어  시스템 요구 사항은 특정 목적을 수행하는 시스템을 원하는 고객의 요구를 반영합니다. 또한 요구공학(Requirements Engieering, RE)이란 이러한 서비스와 ..