Rex Mundi

synergy: http://synergy-foss.org/ 뭐 이건 유명.

input director: http://www.inputdirector.com/ 시너지 버벅대서 다른거 찾아봄. 업데이트 된지 오래됨. 윈도우 only

mouse without bolders: http://www.microsoft.com/en-us/download/details.aspx?id=35460 역시 윈도우 only

공부 블로그에 올리는건 한달 1주일 좀 더 하다가 때려치우고...

2학기 한번 두고보자...내가 어떻게 하는지 ㅠㅠ 성실히 합시다

itistory-photo-1

오늘부터 기식 아침밥 먹을일 있으면 꼭 사진찍어 올리기로 결심.

이거 1800원. 근데 주말엔 같은 퀄리티로 2500원 정도일 때도 있으니...

일단 국은 떡국임.

IGRP(Iterior Gateway Routing Protocol)

계속...

Internet Routing Protocols

소개

- 인터넷 프로토콜은 인터넷을 운용하기 위해 필수적이다.

- 라우터들은 IP 데이터그램을 출발지에서 목적지까지 한 라우터에서 다른 라우터로 방향에 따라 보낸다. (위상기하학적 지식과 인터넷의 상태에 따라, 최저비용 기준)

- 라우터는 인터넷의 위상기하학적 개념을 가지고 있다. 인터넷 프로토콜은 이 정보는 공급한다.

자율 시스템(Autonomous System) = 라우팅 도메인(Routing Domain)

- 하나의, 명확히 정의된 외부 라우팅 정책을 가진 IP 네트워크들의 그룹.

- 관리적 측면에서 한 단체에 속하여 관리되고 제어됨으로써, 동일한 라우팅 정책을 사용하는 네트웍 또는 네트웍 그룹을 일컫는다. 한 자율시스템 내에서의 IP 네트웍은 라우팅 정보를 교환하기 위해 IGP를 사용하며, 타 자율시스템과의 라우팅 정보 교환을 위해서는 BGP를 사용한다. 과거에는 BGP 대신 EGP가 사용되었으며, 향후 BGP는 OSI 인터도메인 라우팅 프로토콜(Inter-Domain Routing Protocol)로 대체될 예정이다. (참조 : 텀즈 컴퓨터 용어사전)

라우팅과 포워딩

- 라우팅은 형성된 포워딩 테이블에 의한 처리과정이다. (정적 라우팅, 동적 라우팅)

- 라우팅은 네트워킹 역사를 통해 계속 발전되어온 복잡한 분산 알고리즘에 의존한다.

- 포워딩은 노드에서 지역적으로 수행되는 비교적 명확한 과정이다.

- 포워딩은 패킷을 이동시키고; 그 목적지 주소를 살피고; 테이블을 찾아보고; 그 테이블에 의해 결정된 경로로 패킷을 전송하는 것으로 이루어진다.

동적 라우팅 프로토콜

- 기능들 : 라우터들 간의 동적인 공유; 위상(topology)이 변화했을 때 자동적으로 라우팅 테이블을 업데이트; 목적지로의 최상의 경로를 결정

- 정적 라우팅과 비교해서, 관리상의 부담(overhead)이 적다.

- 동적 라우팅의 경비는 프로토콜 운용을 위한 라우터의 자원 부분에 들이고 있다.

동적 라우팅 프로토콜의 구성요소

- 데이터 구조 : 운용을 위한 테이블 and/or 데이터베이스 (RAM에 보관)

- 알고리즘 : 완료된 작업에 사용된 유한한 리스트; 용이한 라우팅 정보와 최적 경로 결정

- 라우팅 프로토콜 메시지 : 이웃을 발견하고 라우팅 정보를 교환하기 위해; 네트워크에 대한 정확한 정보를 습득하고 유지함

동적 라우팅 프로토콜 운용

- 모든 라우팅 프로토콜은 동일한 목적을 갖는다 : 원격 네트워크들을 습득하고 토폴로지가 변경되었을 때 빠르게 적응

- 일반적으로 동적 라우팅 프로토콜의 운용

* 인터페이스에서 라우팅 메시지를 주고받음

* 다른 라우터들과 라우팅 메시지와 라우팅 정보를 공유함

* 원격 네트워크를 습득하기 위해 라우팅 정보를 교환함

* 라우팅 프로토콜은 토폴로지 변화를 다른 라우터들에 알릴 수 있다. (다 거의 같은 말 아닌가?)

클래스화 라우팅 프로토콜

- 라우팅 프로토콜은 다른 것들과 연관되어 운용되도록 설계되지 않았다.

- 각각의 프로토콜은 다른 종류의 정보를 수집하고, 토폴로지 변화에 그 나름의 방법으로 반응한다.

- 라우팅 업데이트 통신은 각각의 프로토콜이 독립적으로 다른 방법으로 처리되어야 한다.

- 동적 라우팅 프로토콜은 특징에 따라 그룹화되어 있다.

- 라우팅 프로토콜의 타입

* IGP(Interior Gateway Protocol) : 내부 게이트웨이 프로토콜; 자율시스템내(內) 라우팅(intra-AS routing)

* EGP(Exterior Gateway Protocol) : 외부 게이트웨이 프로토콜; 자율시스템간(間) 라우팅(inter-AS routing)

(obsoleted in 2005 라는데 BGPv4가 폐기된건지 IDRP가 폐기된건지? 질문해볼 것)

결국 중요한건 [거리 벡터] [경로 상태] 라우팅의 차이와 [경로 벡터] 라우팅을 아는 것인 듯.

경로 벡터 라우팅은 AS 외부에서 유용하다는 것이 증명되었다고 한다. (참조)

라우팅 프로토콜 측정기준(Metrics)

대역폭 : 가장 높은 대역폭의 경로를 선호

비용 : 라우팅 선호도; IOS(Internetwork Operating System)이나 네트워크 관리자에 의해 결정됨.

딜레이 : 패킷이 경로를 가로지르는데 걸리는 시간

홉 카운트 : 패킷이 가로질러야하는 라우터 수

로드 : 어떤 연결의 통신량

신뢰도 : 연결 실패의 확률

* RIP는 홉 카운트가 적은 R2 -> R1 경로를 선택하고 OSPF는 빠른 T1 선을 경유해 R2 -> R3 -> R1 경로를 선택한다.

IRP(Interior Routing Protocol)

- AS 내에서 라우터들 간에 라우팅 정보를 전달한다.

- AS 외부에서 시행될 필요가 없다.

- 다른 연결된 AS 들과 다른 알고리즘과 라우팅 정보를 가지고 있을 수도 있다.

- 여타 연결된 AS들에게서 최소의 정보를 필요로 한다 : 대화해야할 최소 하나의 라우터; ERP를 사용한다.

- ex) Distance Vector Routing(거리 벡터 라우팅), Link State Routing(경로 상태 라우팅)

거리 벡터 라우팅

- 각 노드는 세가지 벡터를 유지한다 : 연결 비용, 거리 벡터, 다음 홉 벡터

- 각 노드는 이웃들과 정보를 교환한다. 같은 네트워크에 의해 직접적으로 연결되어 거리와 다음 홉 벡터를 업데이트함.

- RIP, IGRP, EIGRP

RIP의 역사

- Xerox PARC Universal Protocol(PUP)에 라우팅 프로토콜이 필요했다. (1980s)

* Xerox에서 GWINFO(Gateway Information Protocol)을 만듬.

* 나중에 RIP로 이름을 바꾸고 Xerox Network System(XNS) 프로토콜 스위트의 일부가 됨

- UC 버클리에서 RIP를 개조해 유닉스 운영체제의 BSD에 포함시킴

* RIP가 IRP의 산업 표준이 됨

* IETF(Internet Engineering Task Force)에서 RFC1058 인터넷 표준으로 명시함 (1988)

RIP 개요

- RIP 패킷은 UDP를 사용한다. (포트 넘버 520)

- RIP 요청 메시지는 특별한 상황에 보내진다.

- RIP 라우터는 타이머를 가지고 있다. (30초) : 타이머가 만료되면 자발적인 RIP 응답 메시지가 보내진다.

- 개별적 거리 벡터가 수신된 이후 테이블이 업데이트 된다.

* 새로운 목적지 네트워크를 추가한다.

* 존재하는 경로를 딜레이가 적은 것으로 덮어쓴다.

* 라우터 R이 업데이트 되면 모든 경로가 다음 홉으로 R을 사용하도록 업데이트 된다.

- 만약 한 라우터로부터 180초간 업데이트가 수신되지 않으면 유효하지 않는 라우터로 표시한다.

* 네트워크 연결이 불안정하거나 라우터가 고장난 것으로 본다.

* 거리값을 무한대로 설정한다. (실제값은 16)

RIP 테이블 프로세스

- RIP 라우팅 테이블은 어플리케이션 레벨 프로세스 routed (daemon)에 의해 운영된다.

- 주기적으로 반복해서 광고(advetisement)가 UDP 패킷으로 전송된다.

RIP 패킷

명령어 타입

- 1은 요청, 2는 응답

- 업데이트는 물어봤건 아니건 응답된다

- 초기화하는 노드는 요청을 브로드캐스트한다

- 요청은 즉시 응답된다

주소 체계(Address Family) : IP는 2

IP 주소 : 특정 네트워크의 식별자

측정기준(Metric)

- 이 라우터에서 네트워크까지 경로 거리

- 일반적으로 1이므로 metric이 곧 홉 카운트이다.

RIPv2

- 1993에 첫 개발, 1998에 마지막 표준화

- 비클래스형 주소지정을 지원, 서브넷 마스크 규격

- 다음 홉 규격

* 다음 홉 라우터로서 명시적 IP 주소 사용

* 네트워크를 향한 최적의 경로가 RIP를 실행하고있지 않은채 연결되어 있을 떄 유용하다. (이것도 질문해볼 것 : p26)

- 인증(authentification) : RIP 메시지를 수락하기 전에 라우터의 정체를 확인한다.

- 경로 태그(route tag) : 그 경로가 어떻게 얻어졌는지(내부적 혹은 외부적) AS를 확인한다.

- 멀티캐스팅 사용 : 자발적인 RIP 응답 메시지를 보내기 위해 브로드캐스트 대신 멀티캐스트를 사용한다.

RIPv2 다음 홉 규격 예제

다음 홉과 경로 태그를 어떤 식으로 사용하는가?

RIPv2 패킷 포맷

차이점 : 경로 태그, 서브넷 마스크, 다음 홉.

만약 인증이 사용되면 RTE들 중의 하나가 인증 정보를 포함한다.

RIPng (RIPv6)

- 비클래스형 주소지정을 지원, 서브넷 마스크 규격

- 다음 홉 규격 : 개별 라우팅 엔트리가 명시됨 (IPv6 주소의 큰 사이즈에 기인함)

- 인증 : 자체적 인증 매커니즘은 포함하고 있지 않음 (IPsec을 사용)

- 경로 태그 : RIPv2와 동일한 방식

- 멀티캐스트 사용 : 예약된 IPv6 멀티캐스트 주소 FF02:9

- RIPng는 RIPv1이나 RIPv2와 다른 포트 넘버를 사용한다 : 520 대신 521

RIPng 패킷 포맷

새로운 프로토콜 RIPng의 첫번째 버전이다.

RIP의 한계

- 측정기준 15를 초과하는 목적지는 닿을 수 없다 : 만약 더 큰 측정기준이 허용되면 수렴이 너무 길어진다.

- 단순한 측정기준은 차선의 라우팅 테이블로 이끈다 : 패킷이 느린 연결을 통해 전송된다.

- RIP 업데이트를 어떤 장비에서건 수락한다 : 잘못 구성된 장비가 전체 구성을 방해할 수 있다.

1. 아래는 Software engineering 에 대한 정의이다. 아래 정의 내에서 밑줄 친 engineering discipline, all aspects of software production 이라는 두 구문이 갖는 의미를 간단히 설명해 보시오.

Software engineering is an engineering discipline that is concerned with all aspects of software production.

2. 다음 세 가지 용어가 나타내는 의미의 차이점을 설명해 보시오.

1) Software Process Model

2) Software Process

3) Plan-Driven Process

3. Agile method 가 갖는 문제점을 두 가지만 설명해 보시오.

4. Requirement Engineering Process 를 spiral 관점에서 설명해 보시오.

5. System 에 대한 Model 중에서 해당 System 과 Environment 에 대한 모델로 Context Model 과 Interaction Model 이 있다. 이들 두 모델의 차이점을 모델의 형식 및 용도의 관점에서 설명해 보시오.

6. Software Architecture 에 대한 4+1 View Model 에서 Development View 와 Logical View 의 차이점에 대하여 간단히 설명해 보시오.

7. Configuration management 에서는 기본적으로 다음과 같은 Activity 들이 수행된다. Configuration management 도구가 아래의 Activity 들을 구체적으로 어떻게 지원하는 것인지 간단히 설명해 보시오.

1) Version management

2) System Integration

3) Problem Tracking

8. Test-driven development 의 장점을 설명해 보시오.

9. 특정 기능을 시스템의 개발 도중에 시스템에 추가하는 것보다 개발이 끝난 이후에 추가하는 것이 일반적으로 더 많은 비용이 든다. 그 이유를 간단히 설명해 보시오.

답은 나중에 추가.

1장

1.1. 전문적인 소프트웨어가 단순히 사용자를 위해 개발된 프로그램이 아닌 이유를 설명하라.

1.2. 일반적인 소프트웨어 제품 개발과 맞춤형 소프트웨어 개발의 가장 큰 차이점은 무엇인가? 이것은 일반적인 소프트웨어 제품의 사용자에게 실질적으로 무엇을 의미하는가?

1.3. 모든 전문적인 소프트웨어가 가져야할 네가지 중요한 속성은 무엇인가? 경우에 따라 중요할 수 있는 네가지 다른 속성들도 제시해보라.

1.4. 혼재성, 업무와 사회의 변화, 신뢰성과 보안 문제를 떠나서 21세기를 맞이하여 소프트웨어 공학에 도전하는 다른 문제들을 찾아보라. (힌트 : 환경에 대해 생각하라)

1.5. 1.1.2장에서 논의한 타입들 중에 몇몇 어플리케이션에 대한 당신이 가진 지식에 기초하여 왜 상이한 어플리케이션 타입을 개발하고 디자인하려면 다른 종류의 소프트웨어 공학적 기법이 필요한지 예를 들어 설명해보라.

1.6. 모든 종류의 소프트웨어 시스템에 적용되는 기반 사상들이 존재하는 이유를 설명하라.

1.7. 전세계적인 웹의 사용이 소프트웨어 시스템을 어떻게 변화시켰는지 설명하라.

1.8. 전문적인 엔지니어가 의사나 변호사처럼 공인받아야 하는지 논하라.

1.9. 도표 1.3에 보여준 ACM/IEEE 윤리강령의 각 항목에 대해 적절한 예를 제시하라.

1.10. 테러에 대응하기 위해, 많은 나라에서 다수의 시민들과 그들의 행동을 추적할 수 있는 컴퓨터 시스템을 이미 개발했거나 그렇게 할 계획이다. 이것은 명백하게 사생활 침해이다. 이런 종류의 시스템 개발에 착수하는데 대한 윤리적 관점을 논하라.

2장

2.1. 다음과 같은 시스템의 개발을 관리하기 위한 기본으로서 사용될 수 있는 가장 일반적인 소프트웨어 프로세스 모델이 무엇인지 제시하고 그 이유를 설명하라.

- 자동차 ABS를 제어하기 위한 시스템

- 소프트웨어 유지보수를 지원하기 위한 가상현실 시스템

- 현존하는 시스템을 대체하는 대학 회계 시스템

- 사용자가 환경적 영향을 최소한으로 받도록 여행을 계획할 수 있게 도와주는 상호작용 시스템

2.2. 왜 점진적 개발이 비지니스 소프트웨어 시스템을 개발하는데 가장 효율적인 접근법인지 설명하라. 왜 이 모델이 실시간 시스템 공학에는 덜 적절한가?

2.3. 도표 2.3에서 보여준 재사용 기반 프로세스 모델을 고려해보라. 왜 프로세스에 분리된 두가지 요구공학적 활동이 필요한지 설명하라.

2.4. 요구공학적 프로세스에서 사용자 요구사항과 개발 시스템 요구사항을 구별하는 것이 왜 중요한지 제시하라.

2.5. 소프트웨어 디자인 프로세스의 주요 활동과 그러한 활동의 결과물들을 서술하라. 다이어그램을 이용하여 이러한 결과물들의 가능한 연관성들을 보여라.

2.6. 복잡한 시스템에서 왜 변화가 불가피한지 설명하고, 변화를 예측하고 변화에 보다 탄력적으로 소프트웨어를 개발하게 돕는 소프트웨어 프로세스 활동의 예를 들어라. (프로토타이핑과 점진적 제공을 제외하고)

2.7. 왜 일반적으로 생산 시스템에서 프로토타이핑이 사용되지 않는지 설명하라.

2.8. 왜 보엠의 소용돌이 모델이 변화 회피와 변화 용인 둘 다 뒷받침 할 수 있는 적응성있는 모델인지 설명하라. 실제로, 이 모델은 널리 사용되지 않는다. 왜 그러한지 제시하라.

2.9. 소프트웨어 프로세스의 동적 및 정적인 관점을 RUP(Rational Unified Process)로 제공하는 것의 장점은 무엇인가?

2.10. 역사적으로 볼 때, 새로운 기술의 도입은 노동시장에 근본적인 변화를 가져왔으며, 적어도 일시적으로 사람들에게 일자리를 빼앗았다. 대규모의 공정 자동화가 소프트웨어 엔지니어에게도 같은 결과를 불러올 수 있는지를 논하라. 만약 그렇지 않을 것이라 생각한다면, 그 이유를 설명하라. 만약 일자리가 줄어들 것이라 생각한다면, 이러한 기술의 도입을 수동적으로 혹은 적극적으로 저항하는 것이 윤리적인가?

3장

3.1. 새 시스템의 빠른 제공과 배치가 왜 때때로 이 시스템들의 세세한 기능보다 업무상 더 중요한지 설명하라.

3.2. 애자일 방법론의 근본적인 원리들이 어떻게 소프트웨어의 개발과 배치의 가속으로 이어지는지 설명하라.

3.3. 어떨 때 소프트웨어 시스템을 개발하면서 애자일 방법론을 사용하지 않도록 권하겠는가?

3.4. 익스트림 프로그래밍은 사용자 요구사항을 스토리로 표현하며, 각각의 스토리는 카드에 쓰여진다. 이러한 접근법이 요구사항 서술에 가지는 장점과 단점들을 토의하라.

3.5. 왜 테스트 우선적 개발이 프로그래머가 시스템 요구사항을 더 잘 이해하게 돕는지 설명하라. 테스트 우선적 개발의 잠재적인 어려움은 무엇인가?

3.6. 왜 페어로 일하는 프로그래머의 생산성 비율이 따로 일하는 프로그래머들의 그것의 절반을 넘는지 네가지 이유를 제시하라. ※(절반을 넘는다고 많은게 아닌거 같은데 이런 관용구 밖에 없네...본문을 자세히 봐야할 듯) 나중에 체크

3.7. 챕터 23에서 논의된 것처럼, 관습적인 계획 기반의 접근법과 스크럼 접근법을 비교하고 대조하라. 대조점은 각각의 접근법이 프로젝트에 인원을 배치하는 것을 계획하고, 프로젝트의 비용을 추정하고, 팀 화합을 유지하고, 프로젝트 팀원의 변경을 처리하는데 얼마나 효율적인지에 기초해야 한다.

3.8. 당신은 회사에서 비행기를 위한 중요한 제어 시스템을 개발하는 소프트웨어 매니저이다. 당신은 소프트웨어 요구사항을 공식적인 소프트웨어 사양서(챕터 13에 논의됨)로 만드는 소프트웨어 디자인 지원 시스템의 개발을 책임지고 있다. 뒤에 언급될 개발 전략의 장점과 단점을 논평하라.

a. 그 시스템에 필요한 요구사항들을 소프트웨어 엔지니어들과 외부의 이해당사자들(규제 인증 기관과 같은)로부터 수집하고 절차중심적 접근법을 사용해 시스템을 개발한다.

b. 루비나 파이썬 같은 스크립팅 언어를 사용해 프로토타입을 개발하고, 소프트웨어 엔지니어들과 다른 이해당사자들과 함께 이것을 평가하고, 그 다음 시스템 요구사항을 검토한다. 최종 시스템은 자바로 재개발한다.

c. 개발팀에 사용자를 참여시키고 애자일 접근법을 사용하여 자바로 시스템을 개발한다.

3.9. 소프트웨어 개발팀에 가깝게 참여하는 사용자를 가질 때의 문제점 중 하나로 제시된 것은 '원주민화', 즉 개발팀의 관점을 고스란히 받아들이고 동료 사용자들의 필요를 보는 시야를 잃게되는 것이다. 어떻게 이러한 문제들을 회피할 수 있을지 세가지 방법을 제시하고 각각의 접근법들의 장점과 단점을 논하라.

3.10. 비용과 통근의 환경적 영향을 감소시키기 위해 당신의 회사는 몇개의 사무실을 폐쇄하고 직원들이 집에서 일할 수 있게 지원하기로 결정하였다. 그러나, 이러한 정책을 진행한 경영진은 소프트웨어가 클로즈 팀 워킹과 페어 프로그래밍에 의지하는 애자일 방법론을 사용해서 개발되고 있었음을 간과하였다. 이 새로운 정책이 초래할 어려움들과, 당신이라면 어떻게 이 문제들을 회복시킬수 있을지 논의하라.

<p7~p10 요약>

1.1.1 소프트웨어 공학

핵심구절

1. 공학 분야 : 엔지니어는 이론, 방법론, 도구들을 적절하게 적용한다. 그러나 그것을 선택적으로 사용하며 적절한 이론이나 방법이 없을 때에도 문제의 해법을 찾으려 노력한다. 엔지니어는 또한 조직적, 재정적인 재약에 맞추며 이러한 제약 안에서 해법을 찾는다.

2. 모든 형태의 소프트웨어 생산물 : 소프트웨어 엔지니어는 소프트웨어 개발의 기술적 프로세스만이 아니라 프로젝트 매니지먼트, 소프트웨어 생산을 지원하는 도구의 개발과 방법론, 이론을 포함하여 다룬다.

소프트웨어 공학은 두가지 이유에서 중요하다.

1. 개인과 사회는 갈수록 더 발전된 소프트웨어 시스템에 의존하고 있어, 경제적이고 빠르게 신뢰성있는 소프트웨어를 개발할 필요가 있다.

2. 많은 경우 그저 개발하는 것보다 소프트웨어 공학적 방법론을 적용하는 것이 긴 안목으로 봤을때 더 싸다. 대부분의 시스템에서 사용중인 시스템을 개비할 때 대부분의 비용이 발생한다.

소프트웨어 프로세스의 4단계.

1. 소프트웨어 사양서(specification) : 소비자와 엔지니어가 제공될 부분과 제약을 정의하는 단계

2. 소프트웨어 개발(development) : 디자인과 프로그램을 하는 단계

3. 소프트웨어 확인(validation) : 사용자의 필요가 충족되는지 체크하는 단계

4. 소프트웨어 발전(evolution) : 시장과 사용자의 요구의 변화를 반영해 소프트웨어를 수정하는 단계

소프트웨어 공학은 전산학과 시스템 공학과 연계되어 있다.

1. 전산학은 컴퓨터나 소프트웨어 시스템의 기반 지식을 다룬다. 물리학이 전자공학자에게 필수적이듯이 어떤 지식은 소프트웨어 공학자에게도 필수적이다. 그러나 작은 프로그램에 좀 더 잘 적용되며 크고 복잡한 문제들에도 항상 적용할 수는 없다.

2. 시스템 공학은 소프트웨어가 큰 역할을 하는 복잡한 시스템의 발전과 개발의 모든 부면을 다룬다. 시스템 공학자는 소프트웨어 공학만큼 하드웨어 개발, 정책 및 절차 디자인, 시스템 배치 역시 염두에 둔다.

소프트웨어 공학에 도전하는, 공통된 3가지 일반적인 이슈들.

1. 혼재성(Heterogeneity) : 시스템들은 갈수록 서로 다른 타입의 모바일 장비나 컴퓨터를 포함한 네트워크에 걸쳐 분산된 시스템으로 운용될 필요가 있다. 이러한 혼재성에 대응에 충분한 융통성을 가진 신뢰성있는 소프트웨어를 개발할 기술이 필요하다.

2. 업무와 사회 변화 : 업무와 사회의 변화는 사용중인 소프트웨어의 개비와 새로운 소프트웨어의 개발을 필요로 하지만, 많은 전통적 소프트웨어 공학적 기법들은 시간을 소모하고 새로운 시스템의 공급은 계획보다 오래걸린다. 시간을 단축할 필요가 있다.

3. 보안과 신뢰 : 소프트웨어는 우리 삶의 모든 부분과 밀접하게 관련되어 있기에 우리가 신뢰할 수 있어야 한다. 특히 웹을 통해 원격접속하는 경우 그러하다. 악의적인 사용자에게 공격받지 않고 정보보안이 갖춰져야 한다.

<p10~p12 요약>

1.1.2 소프트웨어 공학 다양성

어떠한 소프트웨어 공학적 방법론과 기법을 적용할 것인가를 결정하는 가장 중요한 요소는 어떤 종류의 소프트웨어를 개발하는가 하는 점일 것이다. 

1. 독립형(stand-alone) 어플리케이션 : PC 같은 로컬 컴퓨터에서 실행되며 네트워크에 연결될 필요가 없다. ex) CAD, 포토샵 등

2. 상호작용적 트랜젝션 기반 어플리케이션 : 사용자들의 PC가 단말이 되어 원격으로 실행된다. ex) 전자상거래, 클라우드, 메일, 사진 공유 등

3. 임베디드 콘트롤 시스템 : 하드웨어 장비를 제어, 운영하는 시스템. 산술적으로 다른 모든 시스템을 합친 것보다 임베디드 시스템이 더 많을 것이다. ex) 모바일폰, 자동차 ABS, 전자렌지 조리과정 제어 등

4. 일괄 처리 시스템 : 많은 숫자의 개별적 입력과 그에 해당하는 출력을 처리한다. ex) 전화 요금 납부나 봉급 지불과 같은 주기적 송금 시스템

5. 오락 시스템 : 사용자를 즐겁게 하기 위한 시스템이며 대개 게임이다. 사용자 상호작용이 가장 특징적인 개성이다.

6. 모델링, 시뮬레이션을 위한 시스템 : 다수의 독립적이고 상호작용하는 객체들을 포함하는 물리적 상황이나 과정을 모델링하기 위한 프로그램. 대개 계산성능에 집약적이며 고성능의 병렬 시스템을 필요로 하기도 한다.

7. 데이터 수집 시스템 : 센서와 상호연동하는 데이터 수집을 위한 시스템.

8. 시스템을 위한 시스템 : 다른 소프트웨어 시스템으로 구성되어 있다. 스프레드시트 프로그램 같은 일반적인 프로그램도 있고 각각의 환경을 위해 특별히 만들어진다.

모든 타입에 적용되는 소프트웨어 공학의 기본원리

1. 세심히 관리되고 인정된 과정을 통해 개발되어야 한다.무엇을 개발하고 언제 완료할 것인지 개발 과정을 계획해야 한다.

2. 신뢰성과 성능은 어떤 종류의 시스템이건 중요하다. 시스템은 실패 없이 기대한대로 동작해야 한다. 가능한한 외부의 공격으로부터 안전해야하고 효율적으로 동작하며 자원을 낭비해서는 안된다.

3. 소프트웨어 사양서와 요구사항을 잘 이해하고 처리하는 것은 중요하다. 서로 다른 요구를 기한과 예산 안에서 어떻게 충족시킬지 잘 다루어야 한다.

4. 존재하는 자원을 가능한한 효과적으로 사용해야 한다. 새롭게 만드는 것보다 이미 개발된 것을 재사용하는 것이 좋다.

<p12~p14 요약>

1.1.3 소프트웨어 공학과 웹

사용자의 PC가 아니라 웹 서버에 소프트웨어를 설치할 수 있게 되어 소프트웨어를 변경하거나 업그레이드하기 쉽게 되었고, 모든 PC에 소프트웨어를 설치할 필요가 없게 되었다. 그로 인해 단가가 낮아졌지만, 유저 인터페이스 개발은 특별히 비싸졌다. 많은 사업이 웹기반으로 넘어갔다.

다음 단계는 웹 서비스의 개념이다. 웹 서비스는 구체적이고 유용한 기능을 제공하며 웹을 통해 접근하는 소프트웨어 컴포넌트 들이다. 최근 수년간 '서비스로서의 소프트웨어' 라는 개념이 발달되었다. 이것은 로컬 컴퓨터에서 수행되는 것이 아니라 인터넷을 통해 '컴퓨팅 클라우드'에서 수행된다. 사용자들은 소프트웨어를 구매하지 않고 사용량에 따라 지불하거나 광고를 보는 대신 무료로 접근한다.

이러한 급격한 변화는 웹 기반 시스템의 공학적 변화를 이끌었다. 예를 들어 :

1. 소프트웨어 재사용이 웹 기반 시스템을 구성하는데 지배적인 접근법이 되었다.

2. 사전에 시스템의 모든 요구사항을 아는 것은 불가능하다는 점이 일반적으로 인식되었다. 웹 기반 시스템은 점진적으로 개발되고 제공되어야 한다.

3. 유저 인터페이스는 웹 브라우저의 역량에 의해 제한된다. AJAX 같은 기술도 있지만 여전히 사용하기 어렵다. 웹 기반 시스템의 인터페이스는 대개 특별히 디자인된 다른 프로그램에 비해 떨어진다.

<p14~p17 요약>

1.2 소프트웨어 공학 윤리

1. 비밀엄수(confidentiality) : 고용주나 고객의 비밀을 엄수해야 한다. 명시적으로 계약했건 그렇지 않건.

2. 숙련도(competence) : 자기 숙련도 수준을 오해하게 해서는 안된다. 알면서 능력 이상의 일을 맡지 말라.

3. 지적재산권(intellectual property rights) : 특허나 저작권 같은 지적재산권에 주의하라.

4. 컴퓨터 악용(computer misuse) : 사소한 것들(직장 PC로 게임하기)부터 심각한 것들(바이러스나 멀웨어 전파)까지 포함, 악용하지 말라.

윤리적 딜레마들 : 경영진의 정책과 맞지 않을 때;. 고용주가 비윤리적으로 행동할 때; 무기나 핵과 관련된 업무일 때 등.

이런 부분은 각자 판단해야할 문제들이며 절대적인 답은 없다.

이하 생략. ppt 참조 (차후에 하던가...)

<p17~p18>

1.3 사례 연구

<p18~p20>

1.3.1 인슐린 펌프 제어 시스템

<p20~p22>

1.3.2 정신 건강 관리를 위한 원무 정보 시스템

<p22~p23>

1.3.3 황야 기상대

Software Engineering 교재 번역 및 요약

<교재 p3>

1. 소프트웨어 공학 소개

목적

이 챕터의 목적은 소프트웨어 공학을 소개하고 책의 나머지 부분을 이해하기 위한 기초를 제공하는 것이다. 당신이 이 책을 읽었을 때 :

- 소프트웨어 공학이란 무엇이며 왜 그것이 중요한지 이해하고;

- 다른 종류의 소프트웨어 시스템을 개발하려면 대개 다른 소프트웨어 공학적 기술이 필요하다는 것을 이해하고;

- 소프트웨어 공학도들에게 중요한 윤리적이고 전문적인 쟁점들을 이해하고;

- 책 전체에 사용될 상이한 종류의 세 시스템들을 소개받을 것이다.

<교재 p4>

현 세상은 소프트웨어 없이는 돌아가지 않는다. 국가 기반시설들과 공공사업들은 컴퓨터 기반의 시스템에 의해 제어되며 대부분의 전기제품들은 컴퓨터와 제어 소프트웨어를 포함한다. 산업제조와 산업분포는 완전히 전산화되어 있으며, 금융 시스템도 마찬가지이다. 음악 산업, 컴퓨터 게임, 영화와 텔레비전을 포함한 오락도 소프트웨어 집약적이다. 그러므로 국가적 그리고 국제적 사회가 기능하는데 소프트웨어 공학이 필수적이다.

소프트웨어 시스템은 추상적이며 무형적이다. 재료의 성질에 구애되거나, 물리적 법칙 혹은 제조공정에 지배받지 않는다. 소프트웨어의 가능성에는 어떠한 천부적 한계도 없는바, 이것은 소프트웨어 공학을 간소화시킨다. 그러나 물리적 제약의 희박함으로 인해 소프트웨어 시스템은 빠르게 극도로 복잡해지고, 난해해졌으며, 변경하는데 큰 비용이 들게 되었다.

간단한 임베디드 시스템부터 복잡하고 전세계적인 정보 시스템이 이르기까지 다양한 종류의 소프트웨어 시스템들이 있다. 다른 종류의 소프트웨어는 다른 종류의 접근법이 필요하기에 소프트웨어 공학을 위한 보편적인 표기법이나 방법론, 기법을 구하는 것은 무의미하다. 조직적인 정보 시스템을 개발한다는 것은 과학기기 제어기를 개발하는 것과는 완전히 다르다. 두 시스템 중 어느 것도 그래픽 집약적인 컴퓨터 게임과는 그다지 공통점을 지니고 있지 않다. 이 모든 어플리케이션들이 소프트웨어 공학을 필요로 하지만, 모두 같은 소프트웨어 공학적 기법을 필요로 하지는 않는다.

여전히 잘못되거나 '실패작'이 된 소프트웨어 프로젝트에 대한 많은 보고들이 있다. 소프트웨어 공학은 최신 소프트웨어 개발에 불충분하다고 비판받는다. 그러나 내 관점에서 실패작이라 통칭되는 많은 경우는 두가지 요소의 결과이다 :

1. 수요의 증가 / 수요가 변화하면 새로운 소프트웨어 공학적 기법들이 더 크고 더 복잡한 시스템을 만들도록 돕는다. 시스템은 더욱 빠르게 건조되고 개발되어야 하며, 커지고 한층 더 복잡한 시스템을 필요로 하며, 이전에는 불가능한 것으로 여겨졌던 새로운 역량을 가져야 한다. 현존하는 소프트웨어 공학 방법론은 거기에 대처할 수 없으며 이러한 새로운 수요를 충족하기 위해 새로운 소프트웨어 공학적 기법이 개발되어야 한다.

2. 낮은 기대치 / 소프트웨어 공학적 방법론과 기법을 사용하지 않고 프로그램을 짜는 것은 비교적 쉽다. 많은 회사들이 그들의 상품과 서비스가 발달함에 따라 소프트웨어 개발에 나섰다. 그들이 매일의 업무에 소프트웨어 공학적 방법론을 사용하지는 않는다. 따라서 그들의 소프트웨어는 원래 그래야할 것보다 더욱 비싸고 덜 믿음직하다. 우리는 이 문제를 다루기 위해 더 좋은 소프트웨어 공학 교육과 훈련이 필요하다.

소프트웨어 공학자들은 마땅히 그들의 업적을 자랑스러워할 만하다. 물론 우리는 여전히 복잡한 소프트웨어를 개발하는게 문제들을 가지고 있지만, 소프트웨어 공학이 없었다면 우리는 아직 우주를 여행하지 못했을 것이며, 인터넷이나 최신 전기통신을 가지지 못했을 것이다. 모든 형태의 여행은 더욱 위험하고 비용이 들었을 것이다. 소프트웨어 공학은 이미 큰 기여를 했으며 나는 그러한 기여가 21세기에는 더욱 커질 것이라고 확신한다.

<p5 요약>

1.1 전문적 소프트웨어 개발

전문적 소프트웨어는 개인보다 팀에 의해 개발된다. 소프트웨어 공학은 개인적 개발보다 전문적 소프트웨어 개발을 지원한다. 많은 사람이 소프트웨어와 컴퓨터 프로그램을 동의어로 생각하지만, 그러나 소프트웨어는 프로그램 그 자체가 아니라 이러한 소프트웨어가 올바로 동작하게 만드는 문서, 상태 정보와 연관되어 있다.

도표 1.1 소프트웨어에 대한 FAQ

<p6~p7 요약>

두 종류의 소프트웨어 생산물이 있다. 그리고 두 제품 사이의 중요한 차이점은, 

1. 일반제품 : 소프트웨어를 개발하는 단체가 사양서를 조절한다.

2. 주문제품(혹은 맞춤제품) : 소프트웨어를 구입하는 단체가 사양서를 조절한다.

그러나 이 대조점은 점차 흐릿해져가고 있다. 점점 더 많은 시스템들이 일반 제품을 기본으로 하여 사용자에게 적합하게 조정되고 있다.

전문적인 소프트웨어의 품질을 논할 때, 개발자들 이외에 소프트웨어를 사용하고 변경하는 사람들을 고려에 넣지 않을 수 없다. 소프트웨어의 반응 시간이나 프로그램 코드의 이해의 용이성도 소프트웨어의 비기능적인 특성이다.

도표 1.2

IPv6 주소 통계 : 프린트하고는 다르게 United States가 21.6%이다. 일시적으로 오류가 있었거나 변동된 듯. (2013.04.18 현재)

IPv4와 IPv6 헤더 비교

이름이 바뀐 필드 (거의 같은 일을 하는 필드)

* 버전 : 4비트 필드 (4 대신 6이 들어있음)

* 트래픽 계층 : IPv4의 TOS 필드와 비슷한 8비트 필드. 패킷에 차별화된 서비스를 위한 트래픽 계층을 태그한다.

* 페이로드 길이 : IPv4의 전체 길이와 비슷한 역할. 기본 헤더 길이는 포함하지 않는다.

* 홉 제한 : TTL(Time To Live) 필드와 비슷

* 다음 헤더 : IPv4의 프로토콜 필드와 비슷. 어떤 종류의 정보가 뒤따라오는지 말해주는 값.

삭제된 필드

* 헤더 길이 : IPv6는 고정된 길이를 가지고 있다.

* 단편화 (파편 상쇄) : IPv6는 단편화를 하지 않음. IPv6 호스트는 데이터를 보내기 전에 경로 MTU를 감지한다.

* 식별자 : 단편화를 하지 않으므로 식별자가 필요없다.

* 체크섬 : Media Access Layer (Data Link Layer를 말하는 듯) 와 Transport Layer로 체크섬을 미룸으로 신속한 포워딩

추가된 필드

* 흐름 라벨(Flow Label)

- 특별한 QoS를 필요로 하는 특정 흐름을 식별하기 위한 20비트

- 각 출발지는 고유의 흐름 라벨 값을 선택한다.

- 특별한 QoS가 요청되지 않을 때는 0값

- 라우터들은 구분되는 흐름들을 식별하기 위해 (출발지 주소 + 흐름 라벨) 을 사용한다.

- 다른 버퍼 크기, 포워딩에 관한 다른 우선도 등의 라우터에서의 특별한 처방

- 어떤 특정한 흐름 라벨에 대해서도 특별한 중요도 차이는 없다.

- 특별한 취급방식은 다른 방법으로 선언되어야 한다. (예 : RSVP 같은 신호 프로토콜)

IPv6 확장 헤더

* 일반적으로 IPv6 목적지 주소 필드에 의해 식별된 노드에서만 처리된다 -> - IPv4 옵션 처리에 비해 오버헤드가 작아야만 한다. (예외 : 홉-바이-홉 옵션 헤더)

* IPv4 옵션에서의 40바이트 제한이 없어졌다.

* 현재 정의된 확장 헤더들:

– 홉-바이 홉 옵션 (0)

– 목적지 옵션 (60) <- 라우팅 헤더와 IPv6 목적지 주소 필드에 나타나는 모든 노드에서 처리되어야 하는 옵션

– 라우팅 (43)

– 파편 (44)

– 인증 (51)

– 암호화 (50)

– 목적지 옵션 (60) <- 오직 패킷의 최종 목적지에서만 처리되어야 하는 옵션

– 이동성 (135)

확장 헤더의 예

홉-바이-홉 옵션 헤더

* 전달 경로상의 모든 노드와 라우터에서 읽고 처리된다.

* 제시될 때는 기본 IPv6 패킷 헤더의 바로 다음에 따라온다.

* RSVP, 멀티캐스트 리스너 디스커버리, 액티브 네트워크 메시지와 같은 라우터 경고를 위해 사용

* 점보 페이로드 옵션은 IPv6 패킷 65,536에서 4,294,967,295 옥텟 사이 길이의 전송을 허용한다. (최대 페이로드 길이보다 크다. 페이로드 길이를 0으로 지정한다)

홉-바이-홉 옵션 처리

* 홉-바이-홉 확장 헤더는 반드시 모든 네트워크 장비에서 완전히 처리되어야 하는 유일한 확장 헤더이다.

* 네트워크 장비들을 단순히 트래픽을 포워딩 할 때는 어떤 다른 IPv6 확장 헤더들도 처리하도록 요구받지 않는다.

*홉-바이-홉 외에 하나 혹은 그 이상의 EH(확장 헤더)들과 함께한 IPv6 트래픽은 하드웨어 내에서 포워딩될 수 있다.

라우팅 헤더

* 라우팅 헤더는 중간단계 라우터들을 통해 라우팅하도록 강제한다.

* 다양한 라우팅 옵션을 가능하게하는 라우팅 타입 필드

- IPv6 스펙에는 라우팅 타입 0 만 정의되어 있다.

- 라우팅 타입 2는 모바일 IPv6에서 제안되었다. (RFC 3775)

* 라우팅 타입 0 : IPv4의 "루즈 소스 라우팅"과 비슷하다

* 라우팅 타입 2 : 모바일 노드의 홈 주소가 라우팅 헤더 데이터에 들어있다.

라우팅 헤더 처리 예제

IPv6 타입 0 헤더의 폐지예정

* 보안에 비추어 폐지예정 (RFC 5095)

- 하나의 RH0(라우팅 헤더 0)은 여러개의 중간단계 노드들의 주소를 포함하고 있으며, 같은 주소들이 RH0에 하나 이상 포함될 수 있다. 이것이 두 RH0 처리 호스트 사이를 여러번 오갈 것이며 공격자로부터의 패킷 흐름이 두 원격 라우터들 사이를 따라 증폭되는 것을 허용한다.

- 그것은 임의의 원격 경로를 따라 혼잡을 초래할 수 있으며 그에 따라 서비스 정지 공격 메커니즘으로 행동할 것이다.

파편화 헤더

* 패킷이 파편화되었을 때 출발지에서 사용된다.

* 파편 상쇄는 전체 패킷 내에서 특정 파편의 위치를 식별한다 : 목적지에서 패킷을 재조합하기 위해 사용된다.

* 식별증명(Identification)은 원본 패킷이 같은지 식별하기 위한 것이다.

* M 플래그 : 1 = 파편 더 있음; 0 = 마지막 파편

경로 MTU 탐색

* 경로 MTU : 출발지에서 목적지 사이의 링크 가운데 가장 작은 MTU

* 1280 옥텟보다 큰 패킷을 보내기 위해 경로 MTU를 행한다:

- 송신시스템에서 큰 크기의 IP 패킷을 Don't Fragment 플래그를 설정한 채 생성하여 전송하는 중에, 만약 중계시스템(라우터 등)이 수용하기에 더 큰 패킷이면 이를 거부하게 되며 이를 다시 더 작은 크기로 재전송하게 된다.

- 이 과정은 ICMP 의 Destination Unreacheable (Fragmentation Required but DF bit is set) 오류가 돌아오지 않을 때까지 반복하게되며, 최종적으로는 오류 메시지가 더 이상 돌아오지 않는 시점에서 MTU 값을 확정하게 되는 알고리즘을 말한다.

AH(Authentication Header; 인증 헤더)

* ESP 헤더와 최종 목적지를 대상으로 한 어떤 목적지 옵션 헤더보다 앞에 나타난다.

* 다음 헤더, 페이로드 길이, SPI(보안 매개변수 색인), 일련 번호, 인증 데이터를 포함하고 있다.

* 인증, 데이터 무결성, 재실행 방지를 제공한다.

* 출발지와 목적지만 알고있는 특별한 해쉬 알고리즘과 특정 키

- 출발지 장비는 ICV(Integrity Check Value)라고 불리는 계산 결과를 헤더에 넣는다.

- 목적지 장비는 키를 이용해서 같은 계산을 하여 두 장비가 공유한다.

* 데이터 기밀화는 제공하지 않는다.

인증 헤더 포맷

ESP(Encapsulating Security Payload; 캡슐화 보안 페이로드)

* 암호화 알고리즘이 데이터그램 내의 데이터와 키를 암호화된 형태로 변환한다.

- 캡슐화된 페이로드에 데이터 기밀성, 인증, 데이터 무결성, 재실행 방지를 제공한다.

- ESP 앞에 오는 확장헤더나 IPv6 헤더에는 보안을 제공할 수 없음

* ESP 필드

- ESP 헤더는 SPI와 일련 번호를 가진다.

- ESP 트레일러는 암호화된 데이터 다음에 위치하고 암호화된 데이터를 고정길이로 만드는 부가 데이터를 가진다.

- ESP 인증 데이터는 AH처럼 계산된 ICV를 가진다.

ESP 헤더를 가진 패킷

ESP 헤더 포맷

목적지 옵션 헤더 : 패킷의 목적지 주소를 특별히 타겟으로 한 옵션 정보를 옮긴다. 모바일 IPv6는 이 옵션을 모바일 노드와 홈 에이전트 사이에 등록 메시지를 교환하기 위해 사용한다.

ICMPv6 (Internet Control Message Protocol for IPv6)

* 에러 메시지

– Destination Unreachable Messages

– Packet Too Big Messages (Path MTU discovery)

– Time Exceeded Messages

– Parameter Problem Messages

* 정보 메시지

– Echo Request and Echo Reply Messages

– Router Advertisement and Router Solicitation Messages

– Neighbor Advertisement and Neighbor Solicitation Messages

– Redirect Messages

– Router Renumbering Messages

– Informational Message Options

* RS (Router Solicitations; 라우터 요청)

– Sent only at host start‐up, to solicit immediate router advertisement

– Sent to all‐routers multicast address (link scope)

* RA (Router Advertisement; 라우터 광고)

– Either periodically, or in response to a Router Solicitation message

– Contain prefixes that are used for on‐link determination and/or address configuration, a suggested hop limit value, etc

* 리다이렉트

– Used by routers to inform hosts of a better first hop for a destination

* NS (Neighbor Solicitations; 이웃 요청)

– For address resolution: sent to “solicited node” multicast address

– For unreachability detection: sent to neighbor’s unicast address

* NA (Neighbor Advertisements; 이웃 광고)

– For address resolution: sent to unicast address of solicitor

– For link‐layer address change: sent to all‐nodes multicast address

– Usable for proxy responses (detectable)

– Includes router/host flag

Solicited Multicast Node Address

* ff02:0:0:0:0:1:ff00::/104 + the last 24 bits of IPv6 address

Router Solicitations and Advertisement

* Router solicitations (RS) are sent by booting nodes to request RAs for configuring the interfaces

* Routers send periodic Router Advertisements (RA) to the allnodes multicast address

Neighbor Solicitation and Advertisement

Multicast Neighbor Solicitation

Multicast Neighbor Advertisement

Redirect

* Redirect is used by a router to signal the reroute of a packet to a better router

IPv6 Address Auto‐Configuration

* A mechanism for setting IP address of a node automatically

* Stateless address auto‐configuration (RFC 4862)

– Interface ID is configured by the node on its own, and prefix is notified by the network

* Stateless dynamic host configuration (RFC 3736)

– Sometimes called DHCPv6lite

– The DHCPv6 server does not assign addresses configuration parameters, such as DNS server

* Stateful configuration (RFC 3315)

– The DHCPv6 server assigns an (non‐temporary and/or temporary) address

* Prefix Delegation (RFC 3633)

- The DHCPv6 server delegates prefixes to the clients instead of leasing addresses

Stateless Address Auto‐configuration

• Router Solicitation (RS) message on the network using the link‐local address

• Router Advertisement (RA) message

– RA message is transmitted periodically

-> not necessary have to send RS message

– RA sender does not care to whom it sent information

• Global IPv6 address by combining prefix and interface ID

• A new node on the network generates link local address and allocates it to the interface

– Random number

– EUI‐64 expanded interface id

- Link local address format - fe80::W:X:Y:Z

• Duplicate Address Detection (DAD)

– To confirm that generated link local address is not already used on the same network

– A new node transmits Neighbor Solicitation (NS) message on the network

– If another node using the same address, this node sends NeighborAdvertisement (NA) message

-> the new node will terminates the interface

– If no NA message after a certain time, the new node will use the original link‐local address

• Use of link‐layer addresses inside the address space

• Auto‐configuration with “no collisions”

• Offers “plug and play”

Renumbering

• Networks can be renumbered by having routers specify an expiration interval for network prefixes

• The routers can send a new prefix to tell devices to regenerate their IP addresses

• Devices can actually maintain the old “deprecated” address for a while and then move over to the new address

IPv4 대 IPv6

시간이 없어서 뒷부분 번역은 일단 패스. 나중에.