역사를 통틀어 사람들은 새로운 특징이나 새로운 기술을 통합함으로써 제품이 더 복잡해진다는 느낌을 받아왔다. 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을 반환할 것이다. 또한 "" 견적 마크를 사용하여 단일 인수를 그룹화할 수 있다. 이는 많은 매개 변수를 예상하지만 공백(예: 파일 위치, 파일 이름, 전체 이름 등)을 포함해야 하는 경우 특히 유용하다.