Appia의 IT세상

정규 표현식[Regular expression,Regexp] 002 - 특정 범위 문자 선택 또는 모든 문자 선택 앞선 표스팅에서는 문자의 위치와 이스케이프(escape)문자에 대해서 살펴봤습니다. 문자의 시작과 끝을 나타내는 기호등을 살펴봤고, 이러한 기호등을 문자로 인식하게 하기 위해서 이스케이프(escape)문자에 대해서 살펴봤습니다. 이에 더불어서, 이번 포스팅에서는 특정 문자의 범위에 포함된 문자를 선택하거나, 또는 모든 문자를 선택하는 방법에 대해서 이야기를 해보고자 합니다. 모든 문자 선택 방법(.) 모든 문자를 선택하는 방법으로 . 을 정규 표현식으로 사용하면 됩니다. 그럼 간단히 다음과 같은 예시를 살펴보겠습니다. 설정 텍스트 Hello, Appia 정규 표현식 . 매칭 텍스트 Hello..

정규 표현식[Regular expression,Regexp] 001 - 문자의 위치와 이스케이프 문자(Escape) 앞선 포스팅에서는 정규 표현식[Regular expression,Regexp]의 의미, 테스트 할 수 있는 사이트에 대해서 서두에서 살펴봤습니다. 그 뿐 아니라, 정규 표현식[Regular expression,Regexp]의 기본 표현 방법에 대해서 예시와 함께 간단히 살펴봤습니다. 그래서 이번 포스팅에서는 이 부분에 추가로, 특정 위치에 따른 특정 문자의 선별을 살펴보면서, 이스케이프(escape)문자에 대해서 같이 한번 살펴보도록 하겠습니다. 이스케이프(escape)문자의 의미 및 예시 먼저 이스케이프(escape)문자에 대해서 간단히 살펴보겠습니다. 정규식을 활용하다보면, 특정한 의미..

정규 표현식[Regular expression,Regexp] 000 - 정규 표현식 기본 / 테스트할 수 있는 사이트 이번 포스팅에서는 정규 표현식에 대해서 간단히 이야기를 해볼까 합니다. 정규 표현식[Regular expression,Regexp]의 의미 사전적으로는, 정규 표현식은 특정한 규칙을 가진 문자열의 집합을 표현하는 데 사용하는 형식언어입니다. 즉, 간단하게 특정한 패턴을 표현하기 위해 특정한 표준의 문법들을 의미합니다. 이와 같은 사전적인 의미가 아닌 실질적인 방법에서는 가장 간단하게, 특정 문자열에서 원하는 패턴을 가지는 문자들을 선별하거나, 관련 문자들을 가지고 데이터를 활용해야할 때 위와 같은 정규 표현식[Regular expression,Regexp]이 사용이 됩니다. 그래서 몇번의..

SDLC(Software Development Life Cycle) - 폭포수 모델(Waterfall Model)/개발 방법론 폭포수 모델(Waterfall Model)은 소프트웨어 개발에 사용된 최초의 SDLC(Software Development Life Cycle)입니다. 즉, 소프트웨어 공학에서 최초로 도입된 프로세스 적인 방법론이라고 생각하시면 됩니다. 조금 더 이해를 쉽게 하기 위해서 , 개발 전 과정을 각 단계로 구별하고 그 단계를 순차적으로 진행하는 개발 방식의 모델이라고 생각하시면 됩니다. 이전 단계에서는 별도의 방법론등이 존재하지 않고, 그냥 코드 작성 / Fix 형태로 진행이 되었습니다. 이런 폭포수 모델(Waterfall Model)이 적용되고 나서 처음으로 개발 방법론이 적용되었습..

SDLC(Software Development Life Cycle),소프트웨어공학 - 소프트웨어개발 라이프사이클(Software Development Life Cycle)란? 라이프사이클(Life Cycle)이라고 하면, 제품이 개발 및 생산에서부터 폐기까지의 전 과정을 나타내는 것을 의미합니다. 이런 라이프사이클(Life Cycle)에서 중점적으로 보는 것은 프로세스입니다. 즉, 제품의 요구사항 부터 개발, 검증, 향후 유지 보수 및 폐기까지의 전 과정을 프로세스화 하여 다루다고 생각하시면 됩니다. 그럼 이런 부분에 대해서 소프트웨어 개발에 적용한 것을 Software Development Life Cycle이라고 합니다. 불과 몇십년 전만해도 소프트웨어는 매우 간단하거나, 사이즈가 크지 않았습니다. ..

앞서 포스팅에서는 AUTOSAR VFB에 대해서 간단히 이야기 해봤습니다. 그 과정에서 Communication 기본 조건에 대해서 살펴봤습니다. 거기에서 통신의 주체인 swc에 대해서 오늘은 이야기를 해보고자 합니다. AUTOSAR의 Software Component에 대해서 이야기 할 때, 가장 많이 나오는 이야기가 기능에 대해서 표현하는 단위라는 이야기입니다. 하지만, 기능에 대해서 정의할 때 매우 어려운 이야기입니다. 그 이유는, 이 기능에 대한 구별은 바로 개발자가 하는 것이기 때문입니다. 따라서 저는 기능을 바탕으로 재사용을 하는 최소 단위라고 생각합니다. Atomic Software Component란? Atomic Software Component라는 말을 많이 사용합니다. Atomic란 ..

이전 AUTOSAR 관련 포스팅에서는 AUTOSAR(오토사)의 전체적인 구조에 대해서 포스팅을 진행했습니다. 이전 포스팅에서는 전체적인 AUTOSAR에 대한 구조에 대해 간략하게 이야기 했다면 이번 포스팅에서는 AUTOSAR의 컨셉 중 재사용성을 극대화 해주기 위한 컨셉인, VFB에 대해서 이야기를 해보고자 합니다. AUTOSAR에 대해서 공부를 시작하면서, RTE와 VFB에 많은 이야기를 합니다. 그만큼 AUTOSAR에서 VFB는 상당히 높은 비중이 있습니다. VFB는 Virtual Functional BUS의 약자입니다. 그럼 이 VFB는 무엇에 대한 것일까요? 흔히들 Virtual Functional Bus에 대해 묻는다면, 정확히 답을 하는 사람이 거의 없습니다. 즉 그만큼 중요하지만, 정확히 파..

저번 포스팅 [AUTOSAR 001] AUTOSAR(오토사)의 개념 및 배경 에서는 간단한 도입 배경 및 정의에 대해서 살펴 봤습니다. 그래서, 오늘은 AUTOSAR의 구조에 대해서 한번 살펴보고자 합니다. AUTOSAR의 구조는 다음 그림에서와 같이 크게 3가지 형태로 나타낼 수 있습니다. Application Layer , Runtime Environment 그리고 Basic Software 계층으로 나누어 집니다. 여기서 몇가지 혼란이 올 수 있습니다. 기존에는 Application에서 Firmware기반의 소스 코드를 직접 접근해서 사용했었습니다. 위와 같은 구조로 진행이 되면서, Application에서 Firmware기반의 코드를 드러내거나, 완벽히 분리해야하는 작업이 요구 되어 집니다. 물론..

오늘 포스팅은 AUTOSAR에 대해서 간단한 배경 및 개념에 대해서 이야기를 해보고자 합니다. AUTOSAR – AUTomotive Open System Architecture의 줄임말입니다. 말 그대로 해석해보면, 전장 개방형 시스템 아키텍처로 번역할 수 있습니다. 좀더 쉽게 이야기를 하면 자동차에서 사용되는 개방형 시스템 아키텍처라고 보시면 됩니다. 최근 몇 년 사이에 국내에서는 AUTOSAR에 대해서 참 많은 이야기가 있었습니다. 불과 6~7년 전만 하더라도 AUTOSAR는 선행 과제에서 도입하는 정도였지만, 현재에는 대부분 회사들이 양산에 적용 하는 것 같습니다. 물론 위의 시점은 국내 이야기입니다. 간단히 서론부터 이야기를 드리면, 자동차에 들어가는 기술들을 날이 갈수록 더욱 더 다양해 지고 있..

앞서 포스팅에서 모델 기반 개발에 관련해서 포스팅을 했습니다. 실제, 모델 기반 개발(Model Based Development / Model Based Design)은 유럽 및 선진 전장 개발 회사에서는 10년 넘게 유행을 해오던 개발 방식입니다. 물론 이러한 개발 방식에 가이드라인등에 방식 또한 많이 개발 되었습니다. 그 중 대표적인 것이 MISRA C입니다. 물론 MISRA C의 경우 코드 기반의 개발 방식에 적합합니다. 사람이 손으로 코딩을 하면서 행할 수 있는 많은 문제점들에 대해서 대비하고자, 상당히 엄격한 기준을 가지고 제약을 걸고 있습니다. Model Based Design의 경우 모델링에 따라서 코드에 패턴 및 생성되는 방식이 달라집니다. 따라서 Model based design에 몇가지..