데이터베이스 관리 시스템(DBMS)은 복잡하고 임무 중대한 소프트웨어입니다. 오늘날의 DBMS는 수십 년에 걸친 학술 및 산업 연구와 집중적인 기업 소프트웨어 개발에 바탕을 두고 있다. 데이터베이스 시스템은 가장 초기에 널리 구축된 온라인 서버 시스템 중 하나였으며, 이처럼 데이터 관리뿐만 아니라 애플리케이션, 운영 체제 및 네트워크 서비스에 이르는 설계 문제를 개척하였다. 초기 DBMS는 컴퓨터 과학에서 가장 영향력 있는 소프트웨어 시스템 중 하나이다. 불행하게도, 고급 데이터베이스 시스템에 구현된 많은 아키텍처 혁신들은 학계 및 소프트웨어 산업의 다른 분야 모두에서 정기적으로 재창조된다. 데이터베이스 시스템 아키텍처의 교훈이 널리 알려지지 않은 데에는 여러 가지 이유가 있다. 첫째, 적용된 데이터베이스 시스템 커뮤니티는 상당히 작다. 시장 지배력이 높은 곳에서 소수의 경쟁자만 지원하기 때문에 상업적 수준의 DBMS 구현은 극히 일부에 불과하다. 데이터베이스 시스템의 설계와 구현에 관련된 사람들의 공동체는 빠듯하다. 많은 사람이 같은 학교에 다녔고, 같은 영향력 있는 연구 프로젝트에 참여했으며, 같은 상업용 제품에 협력했다. 둘째, 데이터베이스 시스템의 학문적 처리는 종종 구조적 문제를 무시해 왔다. 데이터베이스 시스템의 교과서적인 프레젠테이션은 전통적으로 시스템 아키텍처에 대한 전면적인 논이 없이 가르치고 연구하고 시험하는 것이 자연스러운 알고리즘 및 이론적 문제에 초점을 맞추고 있다. 요컨대, 데이터베이스 시스템을 구축하는 방법에 대해서는 많은 통설이 있지만, 그중 상당 부분은 기록되지 않았거나 널리 전달되지 않았다. 이 논문에서는 고급 주제에 대한 논의를 통해 현대 데이터베이스 시스템의 주요 아키텍처 측면을 포착하고자 한다. 이들 중 일부는 문헌에 나타나며, 우리는 적절한 경우에 참고자료를 제공한다. 다른 이슈들은 제품 설명서에 묻혀있고, 어떤 이슈들은 지역사회의 구전 전통의 일부분일 뿐이다. 여기서 우리의 목표는 특정 구성요소의 구현 세부사항을 만족하게 하는 것이 아니다. 대신, 우리는 전반적인 시스템 설계와 교과서에서 일반적으로 논의되지 않는 스트레스 문제에 초점을 맞춘다. 코코센티의 경우, 이 논문은 완전히 친숙해야 하며, 어쩌면 단순한 것일 수도 있다. 그러나 우리의 희망은 많은 독자에게 이 논문이 표준 문학의 알고리즘과 기법에 유용한 맥락을 제공해주기를 바란다. 우리는 독자가 교과서 데이터베이스 시스템 재료(예: [53] 또는 [61])와 Solaris, Linux 또는 Windows와 같은 현대 운영 체제의 기본 시설에 익숙하다고 가정한다.

프로덕션에서 가장 성숙한 데이터베이스 시스템은 은행, 항공사 예약, 의료 기록, 인적 자원, 급여, 전화, 고객 관계 관리 및 공급체인 관리를 포함한 인프라 애플리케이션의 중추 역할을 하는 관계형 데이터베이스 관리 시스템(RDBMS)이다. 웹 기반 인터페이스의 출현으로 관계 시스템 사용의 양과 범위가 증가했을 뿐이며, 이는 본질에서 모든 온라인 상거래 뒤에 숨겨진 기록의 저장소 역할을 한다. 오늘날 매우 중요한 소프트웨어 인프라일 뿐만 아니라 관계형 데이터베이스 시스템은 미래에 발생할 수 있는 데이터베이스 시스템의 새로운 확장 및 혁명에 대해 잘 이해되는 기준점 역할을 한다. 이 논문에서 우리는 핵심 관계형 특징을 지원하기 위한 구조적 기초에 초점을 맞출 것이며, 현대의 RDBMS에 존재하는 많은 확장에 대한 논의를 우회할 것이다. 많은 사람은 상업적 관계 시스템이 이제 복잡한 데이터 유형에 대한 지원, 여러 프로그래밍 언어들을 실행하면서 거대한 기능 집합을 포함한다는 것을 알지 못한다. o 시스템 외부 및 내부, 다양한 외부 데이터 소스에 대한 게이트웨이 등. (현재 SQL 표준 사양은 인쇄된 용지를 작은 유형으로 여러 인치까지 쌓는다!) 여기서는 논의를 관리 가능한 상태로 유지하기 위해 이러한 기능 대부분을 얼버무릴 것이다. 특히 복잡한 코드(저장된 절차, 사용자 정의 기능, Java Virtual Machine, 방아쇠, 재귀 질의 등)와 데이터 유형(추상 데이터 유형, 복잡한 개체, XML 등)을 지원하기 위한 시스템 확장에 대해서는 논의하지 않을 것이다. 그림 1과 같이 일반적인 데이터베이스 시스템에는 4가지 주요 요소가 있다. 시스템 내의 다양한 작업을 캡슐화 및 스케줄링하는 프로세스 관리자, 시간별 질의 처리 엔진, 스토리지, 버퍼 관리, 동시성 제어 및 복구, 공유 트랜잭션 스토리지 서브시스템, 공유 공유 스토리지 서브시스템이 있다. d 메모리 관리, 디스크 공간 관리, 복제 및 관리에 사용되는 다양한 배치 유틸리티를 포함한 유틸리티.

다중 사용자 서버를 구축할 때 시스템의 프로세스 구성에 관한 결정을 조기에 내려야 한다. 이러한 결정은 시스템의 소프트웨어 아키텍처와 운영 체제 전반에 걸친 성능, 확장성 및 이식성에 지대한 영향을 미친다 1. 이 부문에서는 DBMS 프로세스 모델에 대한 여러 가지 옵션을 조사한다. 우리는 단일 프로세서 아키텍처에서 경량 스레드에 대한 우수한 운영 체제 지원의 가용성을 가정하여 단순화된 구조로 시작한다. 그런 다음 우리는 DBMS가 어떻게 자체 스레드를 구현하고 이를 OS 설비에 대응하고 멀티프로세서 구성을 관리하는지에 대한 현실을 다루기 위해 이 간단한 논의를 확장한다.

지난 20년 동안 기계학습은 정보기술의 주요 분야 중 하나가 되었고, 그 덕분에 비록 보통 숨겨져 있긴 하지만, 우리 삶의 일부분인 다소 중심적인 것이 되었다. 점점 더 많은 양의 데이터를 이용할 수 있게 되면서, 스마트 데이터 분석이 기술 발전에 필요한 요소로 훨씬 더 널리 보급될 것이라고 믿을 만한 충분한 이유가 있다. 이 장의 목적은 독자들에게 기계 학습 문제를 가지고 있는 광범위한 응용 분야에 대한 개요를 제공하고 문제의 동물원에 어느 정도 질서를 가져다주는 것이다. 그 후에, 우리는 통계와 확률 이론에서 나온 몇 가지 기본적인 도구에 대해 논의할 것이다. 왜냐하면 많은 기계 학습 문제들이 해결이 쉽도록 표현되어야 하는 언어를 형성하기 때문이다. 마지막으로, 우리는 중요한 문제, 즉 분류의 문제를 해결하기 위해 상당히 기본적이지만 효과적인 알고리즘 집합의 개요를 설명할 것이다. 더욱 정교한 도구, 더욱 일반적인 문제에 대한 논의 및 상세한 분석은 이 책의 후반부에서 뒤따를 것이다.

기계학습은 많은 기구에서 나타날 수 있다. 우리는 이제 그들이 다루는 많은 응용 프로그램, 데이터의 종류에 관해 토론하고, 마지막으로 우리는 문제를 좀 더 양식화된 방식으로 공식화한다. 후자는 우리가 모든 새로운 적용에 대해 바퀴의 재조명을 피하기를 원한다면 핵심이다. 대신에, 기계 학습의 많은 기술은 상당히 이질적인 문제들의 범위를 상당히 좁은 프로토타입으로 줄이는 것이다. 기계학습의 많은 과학은 그때 그러한 문제들을 해결하고 해결책에 대한 좋은 보증을 제공하는 것이다.

다소 관련성이 있는 애플리케이션은 협업 필터링이다. 아마존과 같은 인터넷 서점이나 넷플릭스 같은 비디오 대여 사이트들은 사용자들이 추가 상품을 구매하도록 유혹하기 위해 이 정보를 광범위하게 사용한다. 그 문제는 웹 페이지 순위 중 하나와 상당히 비슷하다. 이전과 같이 (이 경우 기사의 경우) 분류된 목록을 얻고자 한다. 중요한 차이점은 명시적인 질의가 빠져 있고 대신 우리는 사용자의 과거 구매와 시청 결정만을 사용하여 미래의 시청과 구매 습관을 예측할 수 있다는 것이다. 여기서 중요한 측면 정보는 유사한 사용자가 내린 결정이며, 따라서 프로세스의 협업적 성격이다. 예는 그림 1.2를 참조하십시오. 이 문제를 해결하기 위한 자동 시스템을 갖는 것이 분명히 바람직하며, 따라서 추측과 시간을 피할 수 있다[BK07]. 똑같이 정의되지 않은 문제는 문서의 자동 번역이다. 한 극단에서, 우리는 우리가 번역하고 싶은 두 언어에 정통한 계산 언어학자가 고안한 조작된 규칙 집합을 사용하여 번역하기 전에 한 텍스트를 완전히 이해하는 것을 목표로 삼을 수 있었다. 특히 텍스트가 항상 문법적으로 정확하지 않고, 문서 이해 자체가 사소한 것이 아니라는 점을 고려할 때 이것은 다소 고된 작업이다. 대신, 우리는 캐나다 의회나 다른 다국어 기구(유엔, 유럽 연합, 스위스)의 절차와 같은 번역된 문서의 예를 사용하여 두 언어 사이의 번역 방법을 배울 수 있었다. 다시 말해서, 우리는 번역의 예를 사용하여 번역하는 법을 배울 수 있었다. 이 기계 학습 접근은 꽤 성공적이었다.

예를 들어 접근 제어를 위한 많은 보안 애플리케이션은 얼굴 인식을 그 구성요소 중 하나로 사용한다. 즉, 사람의 사진(또는 영상녹화)을 볼 때 이 사람이 누구인지 알아본다. 즉, 시스템은 얼굴을 많은 범주(앨리스, 밥, 찰리….) 중 하나로 분류하거나 알 수 없는 얼굴이라고 결정할 필요가 있다. 유사하지만 개념적으로 상당히 다른 문제는 검증이다. 여기서 목표는 문제의 인물이 자신이 주장하는 인물인지를 검증하는 것이다. 이전과 다르게, 이것은 이제 예/아니요. 다른 조명 조건, 표정, 안경 착용 여부, 머리 모양 등을 다루기 위해서는 어떤 특징이 사람을 식별하는 데 적합한지 학습하는 시스템을 갖추는 것이 바람직하다.

학습의 이점을 활용하는 다른 응용 프로그램으로는 음성 인식(마이크로소프트 비스타를 사용한 시스템 배송과 같은 텍스트로 오디오 절차 알림), 필기 인식(텍스트로 스트로크 절차 알림, 많은 PDA에 공통적인 기능), 컴퓨터 트랙패드(예: 이러한 패드의 주요 제조업체인 시냅틱스) 등이 있다.Es 그것의 이름은 신경 네트워크의 시냅스로부터, 제트 엔진의 고장 감지, 컴퓨터 게임에서의 아바타 행동(예: 흑백), 직접 마케팅(회사들은 당신이 더 많이 구매할 의향이 있는지를 추정하기 위해 과거의 구매 행동을 사용한다), 바닥 청소 로봇(Irobot's Roomba와 같은)이다. 학습 문제의 가장 중요한 주제는 일부 관측치 사이에 비차리적 의존성이 존재한다는 것인데, 일반적으로 x와 y라고 부르는데, 이것은 단순한 결정론적 규칙 집합을 알 수 없다. 학습을 이용하여 우리는 체계적인 방법으로 x와 y 사이의 의존성을 유추할 수 있다.

CSS(Cascading Style Sheet)는 웹 페이지에 HTML 요소를 표시하는 방법을 결정하는 외부 텍스트 파일의 규칙이다. CSS에는 특정 마크업 페이지에서 사용되는 글꼴, 색상 및 구문 요소를 정의할 수 있는 형식 지정 지침이 포함되어 있다. 사이트의 모든 페이지가 동일한 외부 스타일 시트에 연결되어 있는 경우 스타일 시트를 한 번 간단히 변경하면 사이트 전체의 모든 요소가 변경된다. 그런 다음 이러한 지침(예: 문서 머리글 크기)을 변경하려면 모든 페이지를 수동으로 변경할 필요가 없다. 스타일 시트 파일의 선만 변경하면 모든 헤딩이 스타일 시트에 맞게 모양만 변경된다. 이 기술은 많은 개발 및 유지 보수 시간을 절약할 수 있을 뿐만 아니라, 보다 일관되고 접근 가능한 인터페이스를 만들 수 있다.

당신은 HTML을 만들기 위해 특별한 편집기 어플리케이션을 사용할 필요가 없다. 당신은 간단한 텍스트 편집기를 사용할 수 있다. 텍스트 편집기는 간단한 텍스트를 입력하고 편집할 수 있는 모든 프로그램(Microsoft Notepad, WordPad) 또는 Vi, Pico와 같은 UNIX 기반 프로그램이다. 그러나 코드 파일을 일반 텍스트로 저장해야 한다. 예를 들어 워드 프로세싱 프로그램에 의해 파일에 포함된 모든 포맷 지침은 파일이 제대로 작동하지 못하게 할 수 있다. 웹 페이지 코드를 텍스트 파일로 저장한 후에는 .htm 또는 .html 파일 이름 확장명으로 저장해야 한다. 많은 운영 체제와 웹 브라우저는 이러한 확장명으로 파일을 자동으로 처리하도록 MIME(Multipurpose Internet Mail Extensions)로 구성되어 있다. 그림 1-1은 HTML 코드가 있는 텍스트 편집기를 보여준다. 이 과정의 첫 부분에서는 메모장을 HTML 텍스트 편집기로 사용하십시오. 그런 다음 과정 후반부에 간단한 GUI 기반 편집기 응용 프로그램을 사용하십시오.

인텔의 하이퍼스레딩 기술은 인텔 아키텍처에 동시 멀티스레딩 개념을 도입한다. Hyper-Threading Technology는 단일 물리적 프로세서를 두 개의 논리적 프로세서로 보이게 한다. 즉, 물리적 실행 리소스는 공유되고 아키텍처 상태는 두 논리 프로세서에 대해 복제된다. 소프트웨어 또는 아키텍처의 관점에서, 이는 운영 체제와 사용자 프로그램이 여러 물리적 프로세서에서처럼 논리 프로세서에 대한 프로세스나 스레드를 스케줄링할 수 있다는 것을 의미한다. 마이크로아키텍처 관점에서, 이것은 두 논리 프로세서의 명령이 공유 실행 자원에서 동시에 지속되고 실행된다는 것을 의미한다. 이 문서에서는 하이퍼스레딩 기술 아키텍처를 설명하고 Intel Xeon 프로세서 제품군에 대한 Intel의 첫 구현에 대한 마이크로 아키텍처 세부사항에 대해 논의한다. 하이퍼스레딩 기술은 인텔의 엔터프라이즈 제품군에 중요한 추가 제품으로, 다양한 제품으로 통합될 것이다.

인터넷과 통신의 놀라운 성장은 점점 더 높은 수준의 프로세서 성능을 요구하는 더 빠른 시스템에 의해 추진된다. 이러한 요구를 충족시키기 위해 프로세서 설계에 대한 기존의 접근방식에 전적으로 의존할 수는 없다. 과거의 프로세서 성능 향상(슈퍼파이프라이닝, 분기 예측, 슈퍼스케일러 실행, 주문 이탈 실행, 캐시)을 달성하는 데 사용되는 마이크로아키텍처 기술은 마이크로프로세서를 점점 더 복잡하게 만들고 트랜지스터를 더 많이 사용하며 더 많은 전력을 소비하게 만들었다. 사실, 트랜지스터 수와 전력은 프로세서 성능보다 더 높은 속도로 증가하고 있다. 따라서 프로세서 설계자는 트랜지스터 수 및 전력 소산보다 더 높은 비율로 성능을 개선할 수 있는 방법을 찾고 있다. 인텔의 하이퍼스레딩 기술은 하나의 솔루션이다.

프로세서 설계에 대한 기존의 접근 방식은 더 높은 클럭 속도, 명령 수준 병렬 처리(ILP) 및 캐시에 초점을 맞추고 있다. 더 높은 클럭 속도를 달성하는 기법은 마이크로 아키텍처를 보다 세밀한 세분화(초파이프라이닝이라고도 함)로 파이프라잉하는 것을 포함한다. 클럭 주파수가 높으면 초당 실행할 수 있는 명령의 수를 증가시켜 성능을 크게 향상시킬 수 있다. 슈퍼파이프라인 마이크로아키텍처에서는 훨씬 더 많은 지침이 비행 중이기 때문에, 캐쉬 누락, 인터럽트 및 분기 예측 오류와 같은 파이프라인을 교란하는 이벤트의 처리에는 비용이 많이 들 수 있다.

하드웨어 추상화 계층(HAL)은 실제 하드웨어 세부사항과 무관하게 하드웨어 지향적 운영을 할 수 있는 상위 계층(예: Application Framework, 고객 애플리케이션, et cetera)에 기능 API 기반 서비스를 제공한다. 이 문서는 하드웨어 추상화 계층, 해당 아키텍처, 구성요소 및 사용 모델에 대한 자세한 설명을 제공한다.

하드웨어 추상화 계층의 현재 구현은 16비트 장치 제품군, 특히 dsPIC33E 제품군과 함께 작동하도록 설계되었다. ADC, DMA, PWM, QEI 및 시스템 시계와 같은 기기 주변기기 아키텍처는 16비트 장치 제품군에 따라 달라지는 경향이 있다. 따라서 다른 16비트 장치 제품군은 문제가 되는 특정 장치의 특징 및 주변 구조에 따라 다양한 익스텐트에 대한 하드웨어 추상화 계층 구현과 호환된다. 이 구현 하드웨어 추상화 계층은 8비트 및 32비트 장치 제품군과 함께 작업할 목적으로 설계되지 않았다. 또한 이 하드웨어 추상화 계층 구현에 사용되는 정적 기능 드라이버 접근방식은 8비트 장치 제품군에서는 매우 잘 작동하지만 동적 드라이버 접근방식이 더 적합한 32비트 장치 제품군에서는 비효율적이다. 그럼에도 불구하고 하드웨어 추상화 계층의 모듈형 구조는 이론적으로 32비트 장치 제품군과 작업하는 동안 현재의 주변 장치 드라이버 세트를 플리브로 대체할 수 있게 할 것이다.

하드웨어 추상화 계층의 핵심 요소인 주변 드라이버는 다른 16비트 장치 제품군의 일반적인 목적의 주변 드라이버로부터 개발되었다. 따라서 하드웨어 추상화 계층 내의 주변 드라이버는 일반적인 일반 용도 애플리케이션 대부분과 완전히 호환된다. 이와 별도로, 하드웨어 추상화 계층의 다른 두 가지 구성요소인 보드 지원 패키지 및 하드웨어 접근 기능은 일반적인 모터 제어 애플리케이션의 요구에 적합하도록 특별히 설계되었다. 그럼에도 불구하고, 이 두 요소의 기본 구조는 일반목적 인터페이스의 추가를 방해하지 않는다. 해당 애플리케이션의 세부사항에 따라, 일반 목적 애플리케이션을 지원하기 전에 하드웨어 추상화 계층에 추가 인터페이스를 추가해야 할 수 있다.

경제와 산업은 소프트웨어와 서비스 기반 사업으로 변모하고 있다. 현대 제품 및 서비스는 점점 더 소프트웨어를 내장하거나 소프트웨어를 사용하여 사용자 정의, 최적화 또는 관리한다(예: 보건, 운송 및 유틸리티 포함). 따라서 소프트웨어 엔지니어링은 많은 산업들의 대응성, 품질 및 보안에 점점 더 중요한 핵심 역할을 하고 있다. 고급 소프트웨어 엔지니어링 기술, 방법 및 도구를 통해 소프트웨어 과제를 마스터하는 것은 소프트웨어 집약적인 모든 산업 부문이 자사 제품과 서비스로 경쟁력을 유지하려면 필수적이다. 예를 들어, 클라우드 환경을 이용하고 소프트웨어 개발 및 소프트웨어 라이프사이클에 빅 데이터 접근 방식을 적용하여 시장 수요의 가속화에 보조를 맞출 필요가 있다. 또 다른 예로, 사이버 물리 시스템이나 대규모 분산 서비스에 의해 촉발되는 소프트웨어 시스템의 증가하는 복잡성을 처리할 수 있다는 것은 소프트웨어 엔지니어링에서 근본적으로 새로운 모델과 접근법을 필요로 한다. 본 백서에서, 유럽 기술 플랫폼 NESSI(Networked European Software and Services Initiative)는 유럽이 경쟁적이고 혁신적이기 위해 EU 소프트웨어 엔지니어링 연구 및 혁신 프로그램의 지속적이고 심지어 증가된 필요성에 대한 인식을 제고하기 위해 노력한다. 이를 위해, 본 백서는 다가올 Horizon 2020 작업 프로그램(ICT/LEIT WP2016-2017)에 대한 NESSI의 의견을 반영한다. 구체적으로는 중요한 연구 과제와 권고사항을 파악하여 소프트웨어 엔지니어링 연구 및 혁신에 관한 NESSI의 관점을 기술한다. 본 백서에서는 3대 주요 기술 분야의 미래 소프트웨어 집약적 시스템에 대해 소프트웨어 엔지니어링에서 직면하고 있는 관련 소프트웨어 엔지니어링 연구 과제를 설명한다. 클라우드 내부 및 클라우드용 소프트웨어 엔지니어링 사이버 물리 시스템을 위한 소프트웨어 엔지니어링.

이 흰 종이와 빅 데이터의 소프트웨어 공학 또한 어떻게 그 구체적인 소프트웨어 제품과 서비스 혁신 기간 중에 발표되어야 하는지에 권고 사항을 제공한다. 또 기술 및 역량 건물에 대한 권고만 제대로 훈련 받은 산업 인력에게 필요한를 제공한다. 마지막으로, 이것은 소프트웨어 공학 연구와 혁신 프로젝트 수업 지난 FP7프로젝트에서 배우게 되는 것에 근거한 영향을 극대화를 위한 권고안을 배달한다. 그리고 이 하얀 종이 내내 보여 통사론으로서, 소프트웨어 공학 원리, 기술, 방법과 툴을 진화하고 소설들 주문에 부쳐진 될 것을 필요가 있다.급변하는 기술, 사회 변화에 대응하고 따라서 새로운 도전에 대처할 수 있습니다. 증가하는 복잡성과 multi-disciplinarity 때문에, 소프트웨어 공학적 해법이 고립에서 기업과 연구 기관에 의해 고안될 수 없다. 다른 공학 분야와 유사하게, 소프트웨어 공학 연구와 혁신 산업계와 학계의 일치된 노력을 실질적으로 중요한 관련 해결책을 제공하는 데 필요로 한다. 이industry-near 연구 현실 세계의 소프트웨어 공학 사건을 수행해야 한다. 들어 유럽 경쟁력 있는, 이는 기회와 그러한 공동 연구와 혁신 노력에 대해 특정한 요구 지속이 되어야 합니다. 이상적으로, 심지어 증가를 의미한다. 게다가, 유럽에 대해 좀 더 공적과 영향력 지난 연구 과제들이 이미 존재하는 결과 재사용하도록 노력해야 한다. 함께 그러한 활동이 위험이 유럽과, 결과적으로, 강하게 소프트웨어 기술에 의존할 것이다 소프트웨어와software-intensive 시스템에 경쟁 입지가 좁아질 것을 줄일 것이다.비유럽 국가들도 바람직한 일보다 높은 수준까지 기술. NESSI은 소프트웨어 공학 자금이 현재 업무 프로그램의 완만한 출발점에서 최고의(WP2014-2015 – LEIT/ICT-9)사용할 수 있다고 생각한다. 소프트웨어 공학 연구와 혁신 프로그램 만약 유럽 왔고 미래 ICT트렌드가 기회를 보고 싶어 해 강화할 필요가 있다.

소프트웨어의 연관성

소프트웨어는 현대의 디지털 세계에서 보편적으로 이루어지고 있다. 소프트웨어현대 제품과 우리의 주변 환경의 서비스의 거의 모든 종류에 모두 담겨 있다. 견해의 사회적인 관점에서, 소프트웨어 모든 복잡한 시스템과 우리의 지원과 장악을 다른 핵심 인프라 장비에 유연성, 지능과 보안을 제공한다.사회:교통, 통신, 에너지, 산업, 사업, 국정, 의료, 오락 등 소프트웨어에는 우리들의 사회 생활에 현저한 영향, 가장 어떻게 우리가, 그리고,interoperate고 우리의 전문가에 둘 다 협력 상호 작용 의사 소통 방식을 변경한 방식에서 가시적을 가지고 있다.개인 디지털 산다. 소프트웨어 또한 관리, 예를 들고 성장한 새로운 도전적인 사회적 요구를 변화시킬 때이다., 그 서비스의 건강 복지 안에 만나는 쪽으로 공급, 공공 부문 활성화할 것이다.점차 많아지고 있어도 공공 부문 서비스와 자녀 교육 제공을 짓고 인구 고령화 문제 해결. 경제적인 관점에서, 소프트웨어는 유럽 경제의 주요 원인 중. 소프트웨어 모든 사업 활동에서:생산성과 경쟁력을 증가시킬 산업, 상업, 서비스, 금융 등 소프트웨어 및 소프트웨어를 양육하는 파격적인 아이디어softwareintensive 제품과 서비스에 의가 지배적인 선도적인 예를 들어, 업계 경쟁 부문과 성장 혁신할 수 있습니다.시장 소프트웨어는 디지털 경제에 중요한 역할을 한다. 게다가, 소프트웨어의 오늘 하는 핵심 요소 기술 혁신이 성장과 고용에 경제의 거의 모든 분야에서 사용하는 다수 안에 내제 되어 있다. 모든 현대 사회 관점, 소프트웨어 및 하드웨어에 전통적인 분열시켜 그들의 각각의 사업 모델의 과학 기술의 관점에서의 소프트웨어가 된 신경 중추.사라지다 로 가치 창출은 기술 스택에 위로 올라가고 있는 하드웨어에서 소프트웨어에 강한 변화다. 이것은 우리가 매우 그 both하드웨어와product-based을 수립 비용으로 혁신과 개발 산업에 대하여 집중적인 것에서 수직 업종 교체가 본다는 것을 의미한다.비용은 더 많은 시장 상품 서비스의 개념이 지배적인 요소들이 있다. 소프트웨어 점점 더 서비스 단말기(혹은 집단, 고정 또는 모바일 개인적인)와 컴퓨터를 점진적으로 네트워크에 의해 대체될 넓은 범위에서 접속을 제공할 계획이다. 이것은 우리가, 단일 플랫폼(예:smartphones)과 인터넷(예를 들어, 클라우드 기반 서비스),을 통해 소프트웨어 기반 솔루션과 서비스의 가용성과 가용성을 본다는 것을 의미한다.그리고 독립형 정지 상태에서 및 상호 연결된 모바일 사용 패턴에 가는 것, 언제 어디서나 –. 요약하자면, 소프트웨어는 디지털 세계에서 지난 15에 20년 동안 계속되는 변형에 대한 추진력이 두드러진 역할을 했다. 혁신기 위한 소프트웨어는 핵심 요소이다. 그것은, 너무 짧은 회복 시간과 시장에 높은 속도로 하고 있는 differentiating 기능과 서비스 제공하는데 허용한다. 결과적으로 혁신에, 소프트웨어가 주요 산업하고 기본. 그것은 단순히 거기는 자신의 권리지만 다른 R&D단위 및 도메인과 긴밀한 협력으로 개발되어야 하는 핵심 요소로서의 역할을 하고 있다. 소프트웨어는 대부분의 현대 제품과 서비스를 작동하게 만드는 것이다.

소프트웨어 공학의 중요성

비비안 레딩 커미셔너는 이미 2007년 11월 트뤼플 100 회의에서 한 연설에서 "소프트웨어 생산 능력은 전략적인 경제 능력이다"라고 지적한 바 있다. 이는 "소프트웨어의 개발, 운용, 유지보수 및 폐기에 대한 시스템적 접근법", 즉 소프트웨어 공학(Software Engineering)의 핵심적 역할이 유럽 수준에서 잘 이해된다는 것을 의미한다. 그 이후로, 이 견해는 많은 다른 그룹들에 의해 강조되었다. 소프트웨어 공학의 중요성은 계속 유지되고 심지어 증가할 것이며 따라서 현재의 EU 작업 프로그램을 넘어 앞으로 있을 연구와 혁신 노력에서도 지속되고 강화될 필요가 있다. 소프트웨어 엔지니어링은 단순한 프로그래밍이 아니라는 점을 강조해야 한다. 은유적으로 말하면, 소프트웨어 공학은 빌딩 설계가 벽돌을 쌓는 것과 관련이 있는 방식으로 프로그래밍과 관련이 있다. "소프트웨어 엔지니어링은 소프트웨어의 개발, 운용 및 유지보수에 대해 체계적이고, 규율적이며, 수량화할 수 있는 접근법의 적용, 즉 소프트웨어에 대한 엔지니어링의 적용이다." 소프트웨어 엔지니어링은 따라서 유럽 산업에 필수적인 능력을 구성하며, 높은 품질을 제공한다. 소프트웨어는 경쟁 우위로 변할 수 있다. 소프트웨어 엔지니어링 연구와 혁신은 소프트웨어 생산과 엔지니어링 자체를 발전시키는 새로운 방법, 기술, 메커니즘, 언어 및 도구를 제공한다. 따라서 소프트웨어 엔지니어링 연구는 신뢰성 있는 품질 보증(보안, 안전, 프라이버시, 성능 및 신뢰 등)과 사용자와 사업주들의 기대 충족을 통해 소프트웨어 시스템을 효율적이고 효과적으로 구축하는 방법을 설명하는 원칙, 기법, 방법 및 도구를 제공한다. 소프트웨어 엔지니어링 연구 및 혁신은 유럽 산업이 숙련되고, 능력 있고, 복잡한 상태를 유지할 수 있도록 보장한다.

역사를 통틀어 사람들은 새로운 특징이나 새로운 기술을 통합함으로써 제품이 더 복잡해진다는 느낌을 받아왔다. 20세기 중반까지 대부분의 제품들은 한 사람이 디자인할 수 있을 정도로 간단했다. 이제 가장 단순한 제품을 제외한 모든 제품은 다른 기술과 전문 지식을 가진 사람들의 팀에 의해 디자인된다. 현대 제품은 기계 및 전기 요소와 이를 제어하기 위한 소프트웨어를 통합한 전통적인 공학 분야 범위에 걸쳐 있다. 현재 우리가 항공기, 자동차, 기차와 같이 복잡한 제품이라고 생각하는 많은 제품들은 기계적인 시스템으로 시작되었지만, 지금은 전자 및 소프트웨어 시스템의 개발에 있어 더 크지는 않더라도 비슷한 노력을 필요로 한다. 그들의 20세기 이전 모델들은 시스템의 많은 부분을 지나치게 설계함으로써 많은 상황을 견뎌내도록 설계되었고, 반면에 시스템의 다른 부분들은 자주 교체되어야 했다. 제품 및 설계 비용뿐만 아니라 제품과 관련된 위험을 최소화하기 위해, 회사들은 가능한 많은 서브시스템이나 구성요소를 재사용하여 모든 제품이 구 요소와 새로운 요소가 혼합되도록 한다. 현대 제품은 특정 용도에 맞게 훨씬 더 크게 최적화되고 맞춤화되며, 전체적으로는 의도한 수명 동안 훨씬 더 신뢰성이 높다. 이제 제품은 제품 수명 주기 동안 제품을 지원하고 안전을 보장하는 서비스 및 유지보수 프로세스와 함께 설계된다. 이러한 서비스와의 통합은 많은 회사들이 현재 제품보다는 기능을 판매하고 있으며, 제품의 수명 기간 동안 그 제품을 회사 내에 유지시키고 있다. 이러한 모든 문제는 제품 개발 프로세스 초기부터 고려할 필요가 있는데, 초기 결정으로 제품 및 서비스 개발이 제한되고 제품 수명 주기에 걸쳐 많은 비용이 결정되기 때문이다. 이것은 많은 회사들에서 시스템 아키텍처 설계에 대한 관심을 증가시켰다. 시스템 아키텍처는 "기능 요소를 물리적 블록으로 배열"을 결정한다(Ulrich & Eppinger, 1995). 여기에는 기능 요소의 배치, 기능 요소에서 물리적 구성요소로 매핑, 상호작용하는 물리적 구성요소 사이의 인터페이스 규격(Ulrich & Eppinger, 1995) 및 주변 컨텍스트와의 인터페이스 규격이 포함된다(Crawley, 2007). 시스템 아키텍처는 제품의 전체와 수명주기 전반에 걸쳐 그리고 많은 요구사항과 제약조건이 아직 알려지지 않은 프로세스에서 제품의 사용을 이해해야 한다.

이는 상충되는 제약조건과 요구사항 사이의 많은 절충 결정을 수반하며, 시스템 내에서는 많은 세부사항에 대한 서로 다른 해결 원칙이다. 시스템 아키텍처는 동시에 이러한 불확실성의 영향을 받지만, 실행 중인 결정을 통해 불확실성이 제품에 영향을 미치는 것을 결정한다. 제품이 더 단순할 때, 개별 엔지니어는 전체 제품의 개요를 유지했고(Flanagan 등, 2007 참조), 그들은 시스템의 다른 부분들 간의 근본적인 절충을 마음 속에 수행할 수 있었다. 많은 고도로 복잡한 제품들은 이제 매우 복잡하고 다원적인 수준에 도달하여 매우 적은 수의 엔지니어들만이 제품과 그것의 라이프 사이클 전체를 훨씬 더 피상적으로 이해할 수 있는 지식을 가지고 있다. 따라서 기업들은 설계 프로세스의 초기 단계와 시스템 아키텍처 단계의 전문가를 지원할 수 있는 도구의 교육을 학계에 요구하고 있다. 이 특별한 이슈는 시스템 아키텍처 설계에 대한 현재의 사고와 연구를 통합하려고 시도함으로써 이러한 요구에 대응하고 있다. 시스템 아키텍처 설계에 대한 연구는 여러 지역사회에 분산되어 있다. 아이디어 생성 및 설계 초기 단계에 대한 설계 및 제품 개발 커뮤니티에 대한 관심은 근본적인 의사결정이 이루어지는 시점(예: Wyatt et al., 2012)에서 복잡한 제품의 시스템 아키텍처를 다루는 것으로 커졌다. 새로운 시스템 아키텍처들은 거의 처음부터 설계되지 않는다. 많은 이들이 이전 세대로부터 시스템 아키텍처를 물려받으므로, 비록 원래의 아키텍처를 이끈 기능적 요구사항이 더 이상 존재하지 않더라도, 아키텍처들은 제품 세대에 걸쳐 현저하게 유사할 수 있다. 구성요소나 서브시스템의 재사용은 또한 전체적인 아키텍처와 서브시스템의 아키텍처 모두 아키텍처의 지속성을 가져온다. 많은 제품들은 이전 디자인뿐만 아니라 제품군이나 제조사가 제공하는 다른 제품들과도 구성요소를 공유한다. 이로 인해 제품군 전체에서 요소의 공통성을 최적화하려는 제품 플랫폼 설계에 대한 연구가 이루어졌다(예: Simpson 등, 2001 참조).

학제간 접근방식으로서의 시스템 엔지니어링 및 성공적인 시스템의 실현을 가능하게 하는 수단. 개발 주기 초기에 고객의 요구와 필요한 기능성을 정의하고, 요구사항을 문서화한 다음, 설계 종합 및 시스템 검증을 진행하는 데 초점을 맞춘다. Systems Engineering은 개념에서 생산, 운영에 이르는 구조화된 개발 프로세스를 형성하는 팀 내 노력에 모든 부문과 전문 그룹을 통합한다. 시스템 엔지니어링은 사용자 요구에 맞는 양질의 제품을 제공하는 것을 목표로 모든 고객의 비즈니스와 기술적 요구를 모두 고려한다. 시스템 아키텍처 설계는 동일한 원리에 따라 도출되지만 시스템의 기능, 구조 및 예측된 동작의 모델링 및 매핑에 초점을 맞춘 하위 프로세스다. 시스템 아키텍처 수준에서 이루어지는 선택은 제품과 설계 비용을 모두 유의적으로 결정한다. 시스템 아키텍처는 여러 분야에서 발생하므로 임베디드 시스템과 사이버 물리적 시스템에서 비롯된 상당한 문헌과 작업이 있다(Lee, 2014). 일부 연구는 또한 그들의 연구에 사업과 프로세스 관련 매개변수를 통합하고 있다. 대부분의 복잡한 제품은 기계 시스템, 소프트웨어 및 전자 장치의 통합을 요구하는 학제간이지만, 많은 시스템 아키텍처 프로세스와 방법론은 주어진 제품 진화를 따라온 징계 전통에서 비롯된다. 어려운 점은 그 분야들이 그들만의 디자인 방법론의 전통을 가지고 있다는 것이다. 특히 소프트웨어 엔지니어링은 SySML(Friendentalet al., 2009년)과 같은 자체적인 체계적인 방법으로 시스템 아키텍처의 오랜 전통을 가지고 있다. 지금까지 서로 다른 분야의 학술문헌은 수렴되지 않았고 특별호는 이들 공동체로부터 제출을 받지 못했다. 시스템 아키텍처를 이해하고 지원할 수 있는 방법은 제품과 조직 특성에서 발생하는 많은 요인에 달려 있다. 마리자 얀코비치와 클라우디아 에커트는 이 특별 이슈와 독립적으로 검토되었지만 시스템 아키텍처의 맥락을 잡기 위해 여기에 포함된 "복합 제품에 대한 다른 제품 클래스의 아키텍처 결정"이라는 기사에서 이러한 요인들을 탐구하고 있다. 그들은 시스템 아키텍처 설계에 관한 일부 문헌을 검토하고, 시스템 아키텍처는 시스템 수준의 혁신 정도, 구성요소 및 서브시스템의 재사용 정도, 다른 제품의 통합 정도, 수명주기 전반에 걸친 수정 정도 등에 의해 크게 영향을 받는다고 주장한다. 이를 통해 시스템 아키텍처의 매우 다른 고려사항인 다섯 가지 설계 클래스를 구분한다. 즉, ab initio 설계, 증분 설계, 대부분의 구성요소가 재사용되는 경우, 상세한 구성요소는 다르지만 아키텍처 또는 일부가 재사용되는 경우, 제품 플랫폼. 여기에는 적어도 일부분은 그룹으로서 설계되고 미래 업그레이드와 미래의 유연성을 염두에 두고 만들어진 설계가 포함된다.

그들은 시스템 아키텍처에 대한 연구가 의도된 범위와 애플리케이션 문제를 명확하게 기술할 필요가 있다고 제안한다. 설정 기반 설계가 시스템 아키텍처 설계에 미치는 영향은 "설정 기반 설계로 제품 개발: 설계 타당성 확립을 위한 아이디어 포트폴리오 및 팀 조직 설정 방법" 기업들이 시스템 아키텍처 대안의 수를 결정하는 방법과 기업이 이러한 대안에 설계팀을 할당하는 방법에 초점을 맞춘 설정 기반 원칙에 근거하여 초기 설계를 구성하는 이점을 이해하기 위해 여러 산업 간 사례를 조사했다. 사례 연구의 분석은 시스템 아키텍처 대안들의 수가 비용-효익 계산에 의해 결정되는 것이 아니라 초기에 제안된 아이디어의 수에 의해 결정된다는 것을 강조한다. 자원 배분에 대해서는 일반적으로 각 대안에 1개 팀이 배정되거나 1개 팀이 모든 대안을 추구한다. 이는 제품의 복잡성, 혁신성 및 출시 시점의 중요성에 크게 의존한다. 이 논문은 또한 시스템 아키텍처 설계, 설계 프로세스 및 설계 조직 간의 관계를 조사한다. 마리 리즈 물레크, 마리자 얀코비치, 클라우디아 에커트의 논문 "시스템 아키텍처 선택: 단일 산업 실험이 선정 기준을 선택할 때 피할 수 있는 트랩에 대해 우리에게 말해 줄 수 있는 것"은 회사 환경에서 시스템 아키텍처를 선택하는 방법과 이 프로세스의 제약조건이 무엇인지를 조사한다. 특히, 선택과정에 있어서의 시스템 아키텍처 기준의 영향을 강조한다. 두 가지 특성이 이 과정에 강하게 영향을 미친다. 즉, 선택 기준의 상호의존성과 광범위한 기준의 정의를 제공하는 정보의 부족이다. 결론은 시스템 아키텍처와 관련된 결정의 온톨로지뿐만 아니라 다른 제품 개발 단계에 따라 달라질 수 있는 관련 기준을 식별해야 할 필요성을 강조한다. 두 논문은 시스템 아키텍처 설계 중에 다운스트림 문제를 고려하는 것의 중요성에 초점을 맞추고 있다. Bo Yu, Tomonori Honda, Syed Zubair, Mostafa H. Sharqawy, Maria C의 "유지관리-포커스 방식"을 참조하십시오.

Yang은 시스템 아키텍처 설계를 통해 영향을 받을 수 있는 복잡한 제품의 수명 주기 동안 유지보수가 주요 비용 요소라고 지적한다. 이들은 설계자가 최소 비용으로 불확실한 조건에서 제품을 작동할 수 있는 시스템 아키텍처와 유지보수 전략을 함께 선택할 수 있도록 유지보수 전략과 시스템 수준 설계 매개변수의 상호작용을 포착하는 프레임워크를 제안한다. 줄리아 린든, 울프 kk그렌, 앤더스 소 ̈더버그는 '모델 기반 신뢰성 분석'에 관한 논문에서 시스템의 신뢰성은 명시적인 기술적 요건과 인간공학 및 의사소통 필요와 같은 주관적 요건이라는 두 가지 측면을 가지고 있다고 주장한다. 어느 쪽이든 실패하면 고객 불만족으로 이어질 수 있다. 그들은 제품의 시스템 아키텍처 단계에서 이러한 문제를 고려하기 위해 나무와 설계 구조 매트릭스의 조합을 통해 시스템의 사회기술적 인터페이스를 명시적으로 모델링하는 방법을 제안한다. 업계의 상당한 관심에도 불구하고, 이 분야의 학술 연구는 아직 초기 단계에 있으며, 많은 연구가 연구자들이 특별한 이슈에 맞춰 논문을 제출할 수 있다고 느끼지 않고 진행 중이다. 이것은 또한 시스템 아키텍처가 연구의 주요 초점이 되는 경우는 드물지만, 다른 영역이 다루어질 때 관련성이 된다는 사실을 반영하는 것이다. 그러나 시스템 아키텍처에 대한 구체적인 지원과 이해는 꼭 필요하다.

논문개요

스탠더드 템플릿 라이브러리(STL)는 캘리포니아 팔로 알토의 휴렛 팩커드 연구소에서 알렉산더 스테파노프와 멍 리가 개발한 C++ 프로그래밍 라이브러리다. 이 프로그램은 C++ 프로그래머가 일반적인 프로그래밍을 할 수 있도록 설계되었으며, 파라메트리라이즈 유형이라고도 불리는 템플릿의 광범위한 사용에 기초하고 있다. 본 논문은 STL 프로그래밍 패러다임에 대한 종합적이고 완전한 조사를 시도하며, C++와 객체 지향 패러다임에 대한 기본 지식을 가진 STL 신입사원에게 단계별 튜토리얼 역할을 한다.

개요

70년대 후반에 알렉산더 스테파노프는 어떤 알고리즘은 데이터 구조의 어떤 특정한 구현에 의존하지 않고 구조의 몇 가지 기본적인 의미 속성에만 의존한다는 것을 처음 관찰했다. 그러한 특성은 예를 들어 데이터 구조의 한 요소에서 다음 요소까지, 그리고 구조물의 처음부터 끝까지 요소를 통과할 수 있는 능력일 수 있다. 정렬 알고리즘의 경우 정렬할 요소가 배열, 링크된 목록 등에 저장되는 경우 반드시 필요하지 않다. 스테파노프는 여러 알고리즘을 조사하여 그 중 대부분은 특정 구현에서 추상화될 수 있으며, 이 추상화는 효율성이 상실되지 않는 방식으로 이루어질 수 있다는 것을 알아냈다. 효율성은 스테파노프가 강조하는 필수 포인트로, 그것을 다시 인스턴스화함으로써 비효율적으로 되는 알고리즘을 사용하는 사람은 아무도 없을 것이라고 확신하고 있다.

STL의 역사

지금까지 소프트웨어 개발에 큰 영향을 미치지 않았던 스테파노프의 통찰력은 미래에 새로운 프로그래밍 패러다임으로 이어질 것이다. 그래서 그 발견자의 희망이다. 1985년 스테파노프는 일반 아다 도서관을 개발하여 C++에서도 이것을 할 수 있는지 질문을 받았다. 그러나 1987년 템플릿(섹션 2.3 참조)에서는 이러한 프로그래밍 방식의 필수 기술인 C++에서 구현되지 않아 그의 작업이 지연되었다. 1988년 스테파노프는 HP 연구소로 옮겼고 1992년에는 알고리즘 프로젝트의 책임자로 임명되었다. 이 프로젝트에서 알렉산더 스테파노프와 멍 리는 효율을 잃지 않고 알고리즘을 가능한 한 일반적으로 정의할 수 있다는 것을 보여주기 위해 거대한 도서관인 스탠더드 템플릿 라이브러리(STL)를 썼다.

STL 및 ANSI/ISO C++ 초안 표준

STL의 중요성은 생성이나 존재에 기초할 뿐만 아니라, 1994년 7월 14일 ANSI/ISO C++ 표준 위원회 회의에서 STL이 표준 초안에 채택되었다. 그것은 만약 지금까지 일어나지 않았다면, 컴파일러 판매업자들은 곧 STL을 그들의 제품에 통합할 것이라는 것을 의미한다. STL의 광범위한 가용성과 일반적인 프로그래밍 아이디어는 이 새로운 프로그래밍 패러다임에게 소프트웨어 개발에 긍정적인 영향을 미칠 수 있는 기회를 준다. 따라서 프로그래머들은 낮은 수준의 알고리즘과 데이터 구조를 작성하는 대신에 코드를 더 빨리 쓰고 문제 해결책에 더 집중하면서 코드를 더 적게 쓸 수 있다.

클래스

C를 C++로 발전시킨 한 가지 이유는 프로그래머가 객체 지향 패러다임을 사용할 수 있도록 하고 장려하기 위해서였다. C++의 아버지인 Bjarne Stroustrup은 [...]에서 "C++ 클래스 개념[...]의 목적은 프로그래머에게 내장형만큼 편리하게 사용할 수 있는 새로운 유형을 만드는 도구를 제공하는 것"이라고 말한다. 클래스는 사용자 정의 유형이라고 명시되어 있다.

클래스 형태를 확인하는 법

키워드 클래스는 사용자 정의 유형의 정의를 시작한다. 키워드 private는 x_pos, y_pos, color라는 이름은 멤버 기능(클래스 정의 안에서 정의된 기능)에서만 사용할 수 있다는 것을 의미한다. 키워드 공개는 클래스의 객체에 대한 인터페이스를 구성하는 공개 섹션을 시작하는데, 즉, 이 섹션의 이름 및 멤버 기능은 객체의 사용자가 접근할 수 있다는 것을 의미한다. 특성은 비공개적이기 때문에, 클래스는 적절한 값을 얻고 설정할 수 있는 공용 멤버 기능을 가지고 있다. 이러한 멤버 기능은 인터페이스에 속한다. 클래스는 추상적인 반면 클래스의 인스턴스화는 개체로 이어져 사용 및 수정할 수 있다는 점에 유의하십시오.

씨샵 언어

C#는 C 프로그래밍 언어에서 파생된 것이지만, 초보자가 C나 C++보다 더 빨리 C#에 능숙해질 수 있도록 하는 쓰레기 수거 등의 특징을 가지고 있다. 자바와 유사하게 객체지향적이며, 광범위한 클래스 라이브러리를 갖추고 있으며, 예외 취급, 다형성, 구현과의 인터페이스 분리를 지원한다. 이러한 특징들은 강력한 개발 도구, 다중 플랫폼 지원 및 일반화와 결합되어 C#를 빠른 응용 프로그램 개발 프로젝트, 개인 또는 큰 팀 또는 작은 팀들에 의해 구현된 프로젝트, 인터넷 애플리케이션 및 엄격한 신뢰성 요건을 갖춘 프로젝트 등 여러 유형의 소프트웨어 개발 프로젝트에 좋은 선택으로 만든다. NUnit와 같은 시험 프레임워크는 C#를 시험 주도의 개발에 사용할 수 있게 하여 XP(익스트림 프로그래밍)와 함께 사용하기에 좋은 언어로 만든다. 그것의 강력한 타이핑은 약하게 입력된 언어에서 흔한 많은 프로그래밍 오류를 방지하는데 도움을 준다.

C#의 힘의 큰 부분(다른 것과 마찬가지로).넷 언어)는 공통과 함께 온다.암호화를 위한 클래스, TCP/IP 소켓 프로그래밍 및 그래픽을 포함한 대규모 클래스를 제공하는 NET Framework API. 따라서 개발자들은 애플리케이션의 일부를 C#에, 또 다른 부분에 쓸 수 있다.NET 언어(예: VB).NET), 도구, 라이브러리 유지.자바뿐만 아니라 C#과 C 언어군의 유사성 때문에 C++와 같은 객체 지향 언어의 배경을 가진 개발자는 C# 구조와 구문을 직관적으로 발견할 수 있다.

표준

마이크로소프트는 앤더스 헤즐스버그를 수석 엔지니어로 두고 C#를 그들의 일부로 만들었다.NET 이니셔티브를 취한 후 ECMA를 통해 사양을 열었다. 그러므로, 언어는 다른 당사자들에 의해 구현될 수 있다. 다른 구현으로는 Mono와 DotGNU. C# 등이 있다.NET 언어는 마이크로소프트 CLR(Common Language Runtime)과 같이 공용 언어 인프라에 지정된 가상 머신의 구현에 의존한다. 이 가상 시스템은 메모리를 관리하고, 개체 참조를 처리하며, 공통 중간 언어 코드의 JIT(Just-In-Time) 컴파일 작업을 수행한다. 가상 머신은 자신의 메모리를 관리해야 하는 프로그램보다 C# 프로그램을 더 안전하게 만들고 그 이유 중 하나이다.NET 언어 코드를 관리 코드라고 한다. C와 C++보다는 Java와 더 유사하게, C#는 포인터를 명시적으로 사용하지 못하게 하고, 그렇지 않으면 소프트웨어 버그가 시스템 메모리를 손상시키고, 운영체제가 설명되지 않은 오류 메시지와 함께 프로그램을 강제로 중지하도록 할 수 있다.

출력방법

그 텍스트는 시스템을 사용하여 출력된다.콘솔 클래스. 맨 위에 있는 사용 문장을 사용하면 컴파일러는 콘솔 클래스를 사용할 때마다 시스템 네임스페이스를 지정하지 않고도 콘솔 클래스를 찾을 수 있다.중간 선은 자동으로 새 선을 만들지 않는 쓰기() 방법을 사용한다. 새 라인을 지정하려면 백슬래시-n 시퀀스(\n )를 사용하십시오. 어떤 이유로든 대신 \n 문자를 보여주고 싶다면 두 번째 백슬래시(\\n )를 추가한다. 백슬래시는 정상적인 문자로 취급되지 않기 때문에 C#에서는 탈출 캐릭터로 알려져 있지만, 특정 특수 문자(새로운 선 문자처럼)를 인코딩할 수 있다.

입력방법

입력 데이터 같은 시스템의 Read()과ReadLine 메서드를 사용하여 outputing에 비슷한 방식에서 수집될 수 있다.Console클래스:위의 프로그램 요청이 사용자의 이름과 다시 표시합니다. 마지막 Console.Read() 기다립니다 사용자가 프로그램을 폐기하기 전에 키를 입력합니다.

에러

오류 출력은 오류 특정 메시지를 콘솔로 전환하기 위해 사용된다. 초보 사용자에게 이것은 상당히 무의미하게 보일 수 있다. 왜냐하면 이것은 (상기와 같이) 출력물과 같은 것을 성취하기 때문이다. 다른 응용 프로그램(예: 스케줄러)을 실행하는 응용 프로그램을 작성하기로 결정한 경우, 해당 프로그램의 출력을 모니터링하기를 원할 수 있으며, 더 구체적으로 말하면 발생하는 오류에 대해서만 통지받기를 원할 수 있다. 콘솔에 쓸 프로그램을 코드화한 경우.오류가 발생할 때마다 오류 스트림이 발생하면 스케줄러 프로그램에 이 스트림을 모니터링하도록 지시하고 전송되는 모든 정보에 피드백을 제공할 수 있다. 오류 메시지와 함께 콘솔이 나타나는 대신 프로그램에서 이를 파일에 기록하려고 할 수 있다.당신은 Streams를 공부한 후에 그리고 Process 클래스에 대해 배운 후에 이것을 다시 방문하고 싶을 것이다.

명령줄 인자

명령줄 인수는 실행 전에 콘솔 프로그램에 전달되는 값이다. 예를 들어 윈도우즈 명령 프롬프트에는 두 개의 명령줄 인수를 사용하는 복사 명령이 포함되어 있다. 첫 번째 인수는 원본 파일이고 두 번째 인수는 새 사본의 위치 또는 이름이다. 사용자 지정 콘솔 애플리케이션에도 인수가 있을 수 있다.위의 프로그램이 사용자 이름이라는 프로그램으로 컴파일된 경우.명령줄에서 "빌"과 "게이트"와 같은 두 개의 인수를 사용하여 실행할 수 있다. 위의 Main() 메서드에 문자열 배열 매개 변수가 있는 방법을 확인하십시오. 그 프로그램은 두 개의 논쟁이 있을 것이라고 가정한다. 그 가정은 그 프로그램을 불안정하게 만든다. 예상된 수의 명령줄 인수 없이 실행되면 누락된 인수에 액세스하려고 할 때 충돌한다. 프로그램을 보다 견고하게 만들기 위해, 우리는 사용자가 모든 필요한 인수를 입력했는지 확인할 수 있도록 한다. 이름을 입력하거나 이름을 전혀 입력하지 않고 프로그램을 실행해 보십시오. 끈.길이 속성은 총 인수 수를 반환한다. 만약 어떤 논쟁도 주어지지 않는다면, 그것은 0을 반환할 것이다. 또한 "" 견적 마크를 사용하여 단일 인수를 그룹화할 수 있다. 이는 많은 매개 변수를 예상하지만 공백(예: 파일 위치, 파일 이름, 전체 이름 등)을 포함해야 하는 경우 특히 유용하다.

Visual Studio 2017에서는 프로젝트 생성 시, 마법사를 이용하면 SDL을 끌 수 있었다.

하지만 Visual Studio 2019에서는 프로젝트를 생성한 뒤, 속성에서 SDL을 꺼 주어야 한다.

방법을 알아보자.

프로젝트를 생성하고 소스파일을 만들었다고 치자. 프로젝트의 이름은 PS이다.

위에 빨간 곳에 마우스를 올리고 오른쪽 클릭을 하자.

하단의 속성을 누르자.

그리고 좌측 탭에서 C/C++ -> 일반으로 간 뒤, SDL검사에 아니요를 골른 뒤, 확인 및 적용을 해주면

이제 scanf를 사용할 때 scanf_s를 사용하라니 #define CRT_SECURE_NO_WARNING을 사용하라니 하는 귀찮은 잔소리는 듣지 않아도 된다.

끗!