때찌네

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

소프트웨어구조

건축 설계사들은 집에 대한 자세한 설계를 하기 전에 집의 전반적인 모습과 구조의 틀을 잡는다.

다시 말해 앞으로의 설계와 시공에 대한 가이드가 될 큰 밑그림을 그리는 셈이다. 일관적인 모양과 조화를 위한 스타일을 정하는 작업이라고 할 수도 있다.

이러한 스타일이라는 개념을 소프트웨어 구조에도 적용할 수 있다. 소프트웨어 시스템이 더욱 복잡해지면서 시스템의 구조 문제는 더욱 중요해졌다. 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않다. 대부분의 서브시스템에 대한 인터페이스를 변경하여야 하기 때문이다.

이런 문제의 중요성을 인식하여 소프트웨어 구조(software architecture)란 개념이 출현한 것이다. 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류처리 방침, 서브시스템 간의 통신 프로토콜을 포함한다.

 

저장소 구조

저장소 구조(repository architecture)는 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경한다. 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화한다. 제어 흐름은 중앙 저장소에서 올 수도 있고 서브시스템에서 올 수도 있다.

저장소 구조는 급여 시스템이나 은행 시스템과 같은 데이터베이스 관리 시스템에서 대표적으로 볼 수 있다. 데이터가 중앙에 위치하여 서브시스템 사이의 병렬처리와 통합 문제를 더 잘 다룰 수 있다. 컴파일러나 소프트웨어 개발 환경들도 아래와 같은 저장소 구조를 따르고 있다. 컴파일러의 여러 서브시스템들이 파싱 트리와 심볼 테이블을 접근하고 변경한다. 디버거와 구문 편집기도 심볼 테이블을 사용한다.

저장소는 단지 동시에 요청된 접근이 순서대로 실행되도록 하면 된다. 역으로 말하면 저장소는 내부 상태를 기초로 서브시스템을 호출한다. 이런 시스템을 블랙보드 시스템이라 한다.

MVC 구조

MVC(Model/View/controller) 구조는 모델, 뷰, 제어구조라는 세 가지 다른 서브시스템으로 구성되어 있다.

모델 서브시스템은 도메인의 자식을 저장보관하고 있고 뷰 서브시스템은 이를 사용자에게 보여주며 제어 서브 시스템은 사용자와의 상호 작용을 관리한다.

모델 서브시스템은 뷰 서브시스템과 제어 서브시스템에 관련 없이 개발된다.]

MVC구조는 저장소 구조의 특수한 경우로 모델은 중앙 데이터 구조이며 제어 객체가 제어 흐름을 지시한다.

모델, 뷰, 제어로 분리하는 이유는 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문이다.

 

클라이언트/서버 구조

클라이언트/서버 구조에서 서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공한다. 클라이언트는 사용자와 대화하여야 한다.

클라이언트는 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집한다.

서버 시스템은 저장소 구조의 특수한 형태이다.

저장소 구조의 중앙 데이터 구조는 한 프로세스에 의하여 관리되지만 클라이언트 서버 시스템에서는 제한이 없다. 웹에서와 같이 단일 클라이언트가 수천 개의 서버로부터 데이터를 받을 수 있다.

 

계층 구조

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용하도록 구성된다.

상위층은 클라이언트가 되며 하위층이 서버처럼 작동한다.

시스템에 따라 바로 아래층이 제공하는 서비스만 접근할 수 있도록 폐쇄적인 구조를 취할 수도 있고 더 깊은 계층의 서비스도 자유롭게 접근하게 할 수도 있다.

계층형 구조는 추상화의 성질을 잘 이용한 구조이다.

계층형 구조의 장점은 층과 층 사이의 인터페이스 제약만 어기지 않으면 각 층을 필요에 따라 쉽게 변경할 수 있다는 점이다. 도한 연결된 층의 인터페이스만 맞추어주면 특정 계층을 쉽게 재사용할 수 있다.

단점

• 각 서브시스템 사이에 복잡하게 관계를 맺고 있어 이를 독립적인 층으로 분리 추상화하기 어렵다.
• 과다한 계층 분할은 시스템 사이의 인터페이스가 오히려 성능 저하를 가져온다.

 

파이프 필터 구조

파이프 필터 구조는 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복된다.

서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 한다.

각 필터는 입력 파이프에 받은 데이터의 내용과 형식만을 알고 그것을 생성한 필터에 대하여는 모른다.

파이프와 필터 구조는 변경 가능하다. 필터는 다른 필터와 교환 될 수 있고 다른 목적으로 재구성될 수 있다.

파이프 필터 구조의 대표적인 예는 Unix 쉘이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

자료 흐름도의 작성은 시스템 경계의 입출력 식별로부터 시작된다. 최상위 단계의 입출력은 시스템의 경계를 정의하는 것으로 분석의 대상이 무엇인가를 결정하는 일이다. 시스템 경계 밖에 위치하는 것은 개발 과정의 관심 밖에 있는 실체들이며 구조적 분석에서는 경계 내부의 작성에 집중한다.

구조적 분석에서 중점을 두어야 하는 것은 자료의 흐름이다. 주요 자료가 어떤 주요 과정을 거쳐 변형하는가를 파악한다. 주요 처리 과정은 하향식으로 분할하여 세부 처리 과정으로 표현한다.

자료의 흐름과 프로세스의 이름을 붙이는 것이 중요하다. 프로세스에는 고유한 이름을 부여한다. 이는 실체를 명확히 나타내는 이름이야 한다. 자료 흐름의 주요 명칭은 주로 명사형의 단어로 표현한다. ‘자료’ 또는 ‘정보’ 등과 같은 일반적인 의미의 단어는 피하고 ‘검증된 주민등록번호’같이 자료의 특성을 잘 나타낸 정확한 이름을 부여하여야 한다. 프로세스의 이름도 구체적이며 정확해야 한다. 프로세스의 이름은 대체로 동사형 명사와 단일 직접 목적어를 사용한다. 두 개의 동사가 필요하다면 프로세스를 분할하는 것이 좋다. ‘처리’, ‘조작’과 같은 포괄적인 명칭은 피하고 구체적인 처리를 나타내는 이름을 붙인다.

자료 흐름도가 너무 커져서 한 장에 그릴 수 없다면 프로세스를 그룹화하여 단계적으로 표현한다. 한 장의 분석서에 한 계층의 자료 흐름도만 그리되 프로세스는 일곱 개 전후의 프로세스만 포함되도록 한다. 이렇게 하면 자료 흐름도의 이해가 쉽고 작업이 용이하다.

최하위 단계의 결정은 프로세스의 내용이 분석서 한 면에 기술할 수 있는 분량으로 한다. 한 면을 초과하는 것은 더 분할될 수 있다는 것을 의미한다. 또 다른 기준은 입출력 자료가 더 이상 분할되지 않으며 한 계층이 하나의 입력 자료 흐름이나 하나의 출력 자료만을 가질 때 분할을 멈춘다.

시스템 프로세스의 분할은 균형 있게 이루어지는 것이 좋다. 즉, 상위층의 프로세스가 구체화되어 하향식 분할이 어디까지 이루어졌는가를 조사한다. 하향식으로 분할된 단계의 수는 비슷한 것이 바람직한 분할이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

480개의 ASCII 글자 블록의 전송에 대하여 시작펄스와 정지펄스를 각각 1비트씩 사용하는 비동기식 전송 효율은?

480 * 8비트 = 3840비트
480 * 2비트 = 960비트
=>전송된 전체량 = 4800비트이며, 전송효율은 3840 / 4800 * 100 = 80.0 %

220개의 ASCII 글자 블록의 전송에 대하여 3개의 SYN 글자를 이용하는 동기식 전송 효율은?
동기식 전송인 경우 정보비트의 양
220 * 8 = 1760
220 * 8 + 24 = 1784
1760 / 17840 * 100 = 98.7 %

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

프로세스 모형(소프트웨어 생명주기 모형)

 

COCOMO 모델

비용 예측 방법으로 B. Boehm이 제안한 원시 프로그램의 규모에 의한 방법이 COCOMO(Constructive Cost Model) 모델이다. 먼저 완성될 시스템 규모(lines of code)를 추정하고 이를 준비된 식에 대입하여 소요 인월/월을 예측한다. 1981년에 제안된 초기 모델은 소프트웨어 공학 기술이 발전되면서 1995년 COCOMO II로 확장되었다.

COCOMO

소프트웨어 개발 프로젝트에 대하여 3가지로 구분하고 프로그램 규모(kilo delivered source instruction)와 이를 개발하는 데 소요되는 프로그래머 인원/월(programmer man/month)의 관계를 추출

프로젝트 유형	공 식	유형 해설
단순형(Organic)	PM = 2.4 * (KSDI)1.05	소규모 팀이 개발하는 잘 알려진 응용 시스템
중간형(Semi-detached)	PM = 3.0 * (KSDI)1.12	단순형과 임베디드의 중간형으로 트랜잭션 처리 시스템,운영체제, DBMS
임베디드형(Embedded)	PM = 3.6 * (KSDI)1.20	하드웨어가 포함된 실시간 시스템. 미사일 유도, 신호기 제어 시스템

 

Organic

• 기관 내에서 개발된 중소 규모의 소프트웨어
• 일괄 자료 처리, 과학 기술 계산용, 비지니스 자료 처리용 등
• 5만 라인 이하의 소프트웨어를 개발하는 유형

Semi-detached

• 트랜잭션 처리 시스템, 운영체제, DBMS 등
• 30만 라인 이하의 소프트웨어를 개발하는 유형

Embedded

• 최대 규모의 하드웨어가 포함된 실시간 처리 시스템
• 미사일 유도 시스템, 도시 가스 제어 시스템 등

원시코드의 크기를 바탕으로 하는 대부분의 비용 예측 방법

• PM inital = c * KLOC^k
• 결과 MM은 원시 코드의 라인수에 비례
  • 상수 K는 1보다 큰 값
  • 따라서 비선형적으로 비례
  • 따라서 비선형적으로 비례

비용 승수 요소

프로토타이핑 모형의 장단점

정의

프로토타이핑이란 시스템의 일부 혹은 시스템의 모형이 될 만한 것을 만드는 과정이다.

프로토타이핑 모형은 요구 분석 단계로부터 시작한다. 발주자나 사용자는 한 번에 완전한 요구를 낼 수 없기 때문에 프로토타입이 설계된다. 프로토타입이 구현된 후에 발주자와 개발자는 이를 평가하여 요구를 수정한다. 새로운 요구에 다라 프로토타입을 수정하거나 보완하고 확장하면 시스템이 구현되는 것이다.

장점

• 발주자가 완성된 시스템의 모습을 먼저 볼 수 있고, 이를 보고 요구를 수정할 수도 있다.
• 발주자나 개발자에게 공동의 참조모델을 제공한다.
• 발주자는 프로토타입으로 인하여 소프트웨어 개발에 더 관심을 가지고 참여할 수 있다.
• 개발자는 프로토타입을 통하여 사용자의 요구를 자세하게 도출할 수 있다.
• 프로토타이핑으로 소프트웨어 개발이 제대로 되고 있는지 확인할 수 있다.

단점

• 두 차례에 걸쳐 개발할 기회가 있으므로 잘못된 부분을 고칠 기회가 많다.
• 발주자가 프로토타입이 최종 결과라 믿고 곧 소프트웨어 개발이 완성되리라고 오해한다.
• 발주자가 개발 일정 단축을 요구하므로 소프트웨어 품질을 저하시킬 우려도 있다.
• 프로토타입이 과대 선전되어 발주자로 하여금 개발하여 인수해야 할 시스템보다 더 많은 기능을 기대하는 심리를 유발시킬 수 있다.
• 개발

기능점수방법

기능점수는 소프트웨어 시스템이 가지는 기능을 정량화한 것이다. 원시 코드가 아직 작성되지 않은 상태이므로 정확한 라인수의 예측은 불가능하다. 따라서 일반적인 소프트웨어가 갖는 기능(예를 들면, 입력, 출력, 절의, 파일, 인터페이스)의 개수로 소프트웨어의 규모와 복잡도를 나타내고 이를 시스템 개발에 필요한 기간과 소요 인력 계산의 기초로 삼는 방법이다. 이 방법은 경험 중심적이며 여러 가지 실험 결과에 의하면 비즈니스 응용 분야의 소프트웨어 개발비용 산정에 정확하다고 한다. 기능 점수를 이용하여 비용을 산정하려면 생산성 메트릭이 있어야 한다. 즉, 단위 시간당 프로그래머의 생산성을 기능 점수로 표현한 자료가 있어야 한다.

자료흐름도

구조도

설계원리

모든 소프트웨어 개발 방법에는 근간을 이루는 개념과 원리가 있다. 방법은 상황에 맞게 개념과 원리를 적용하는 것이다. 따라서 기술의 발전이나 경영 관리 상황, 개인들의 관심에 따라 방법론은 달라질 수 있다. 구조적 설계는 구조적 분석의 ‘형식은 기능을 따른다’는 원리를 일관되게 적용한다. 자료 흐름도의 프로세스 패턴이 시스템의 구조를 결정한다. 분할과 정복, 즉 큰 일을 작게 나누고 작은 일을 하나씩 해결하는 과정을 반복한다. 프로세스를 모듈로 분할하는 원리는 아래 그림과 같다. 자료 흐름도를 크게 입력, 프로세스, 출력 부분으로 나눈다면 구조도에는 입력, 프로세스, 출력 부분을 표시하고 그 위에 제어부분을 붙인다.

추상화란 자세한 사항을 접어두고 근본적인 본질에 집중하는 것을 말한다. 즉, 자세한 사항을 처음부터 다루지 않고 전체적이고 포괄적인 개념으로부터 차례로 자세하게 세분화함으로써 구체화시켜 나가는 방법이다. 구체화하는 과정의 설계단계에서는 소프트웨어의 구조를 이루는 계층을 파악할 수 있고, 각 구성 요소도 선택할 수 있다. 추상화는 ‘어떤 결과가 얻어져야 하는가?’라는 명세화 관점을 ‘어떻게 달성할 것인가?’라는 구현에 대한 관점과는 별개로 생각함으로써 설계 작업에 집중할 수 있게 한다.

정보 은닉 원리에 의하여 설계된 각 모듈은 자세한 처리 내용이 시스템의 다른 부분으로부터 감추어져 있어야 한다는 것이다. 모듈 안의 내용을 부여주지 않고 잘 정의된 인터페이스를 통하여 메시지를 전달하도록 하는 개념이다. 즉, 설계상의 결정 사항들이 각 모듈 안에 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 한다.

이와 같은 정보 은닉은 모듈화의 기준으로 사용할 수도 있다. 즉, 모듈이 외부로부터 얼마나 은폐되었는가를 분석한 후에 가능하면 모든 사항이 모듈 안에 감추어지도록 모듈의 설계를 고쳐 나간다. 정보 은닉을 따른 모듈 설계는 모듈의 구현을 독립적으로 맡길 수 있고, 설계 과정에서 하나의 모듈이 변경되더라고 다른 모듈의 설계에 영향을 주지 않는다. 또한 모듈의 이해도를 높일 수 있는 장점도 있다.

단계적 분해는 문제를 상위 개념부터 더 구체적인 단계로 하향식으로 분할하는 기법이다. N. Wirth에 의하여 제안된 개념으로 다음과 같은 과정으로 구성된다.

1. 문제를 기본 단위로 나눈다.
2. 독립된 문제로 구별한다.
3. 구분된 문제의 자세한 내용은 가능한 한 뒤로 미룬다.
4. 구체화 작업이 계속 점증적으로 일어난다는 것을 보인다.

소프트웨어구조

건축 설계사들은 집에 대한 자세한 설계를 하기 전에 집의 전반적인 모습과 구조의 틀을 잡는다.

다시 말해 앞으로의 설계와 시공에 대한 가이드가 될 큰 밑그림을 그리는 셈이다. 일관적인 모양과 조화를 위한 스타일을 정하는 작업이라고 할 수도 있다.

이러한 스타일이라는 개념을 소프트웨어 구조에도 적용할 수 있다. 소프트웨어 시스템이 더욱 복잡해지면서 시스템의 구조 문제는 더욱 중요해졌다. 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않다. 대부분의 서브시스템에 대한 인터페이스를 변경하여야 하기 때문이다.

이런 문제의 중요성을 인식하여 소프트웨어 구조(software architecture)란 개념이 출현한 것이다. 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류처리 방침, 서브시스템 간의 통신 프로토콜을 포함한다.

 

저장소 구조

저장소 구조(repository architecture)는 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경한다. 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화한다. 제어 흐름은 중앙 저장소에서 올 수도 있고 서브시스템에서 올 수도 있다.

저장소 구조는 급여 시스템이나 은행 시스템과 같은 데이터베이스 관리 시스템에서 대표적으로 볼 수 있다. 데이터가 중앙에 위치하여 서브시스템 사이의 병렬처리와 통합 문제를 더 잘 다룰 수 있다. 컴파일러나 소프트웨어 개발 환경들도 아래와 같은 저장소 구조를 따르고 있다. 컴파일러의 여러 서브시스템들이 파싱 트리와 심볼 테이블을 접근하고 변경한다. 디버거와 구문 편집기도 심볼 테이블을 사용한다.

저장소는 단지 동시에 요청된 접근이 순서대로 실행되도록 하면 된다. 역으로 말하면 저장소는 내부 상태를 기초로 서브시스템을 호출한다. 이런 시스템을 블랙보드 시스템이라 한다.

MVC 구조

MVC(Model/View/controller) 구조는 모델, 뷰, 제어구조라는 세 가지 다른 서브시스템으로 구성되어 있다.

모델 서브시스템은 도메인의 자식을 저장보관하고 있고 뷰 서브시스템은 이를 사용자에게 보여주며 제어 서브 시스템은 사용자와의 상호 작용을 관리한다.

모델 서스시스템은 뷰 서브시스템과 제어 서브시스템에 관련 없이 개발된다.]

MVC구조는 저장소 구조의 특수한 경우로 모델은 중앙 데이터 구조이며 제어 객체가 제어 흐름을 지시한다.

모델, 뷰, 제어로 분리하는 이유는 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문이다.

 

클라이언트/서버 구조

클라이언트/서버 구조에서 서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공한다. 클라이언트는 사용자와 대화하여야 한다.

클라이언트는 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집한다.

서버 시스템은 저장소 구조의 특수한 형태이다.

저장소 구조의 중앙 데이터 구조는 한 프로세스에 의하여 관리되지만 클라이언트 서버 시스템에서는 제한이 없다. 웹에서와 같이 단일 클라이언트가 수천 개의 서버로부터 데이터를 받을 수 있다.

 

계층 구조

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용하도록 구성된다.

상위층은 클라이언트가 되며 하위층이 서버처럼 적동한다.

시스템에 따라 바로 아래층이 제공하는 서비스만 접근할 수 있도록 폐쇄적인 구조를 취할 수도 있고 더 깊은 계층의 서비스도 자유롭게 접근하게 할 수도 있다.

계층형 구조는 추상화의 성질을 잘 이용한 구조이다.

계층형 구조의 장점은 층과 층 사이의 인터페이스 제약만 어기지 않으면 각 층을 필요에 따라 쉽게 변경할 수 있다는 점이다. 도한 연결된 층의 인터페이스만 맞추어주면 특정 계층을 쉽게 재사용할 수 있다.

단점

• 각 서브시스템 사이에 복잡하게 관계를 맺고 있어 이를 독립적인 층으로 분리 추상화하기 어렵다.
• 과다한 계층 분할은 시스템 사이의 인터페이스가 오히려 성능 저하를 가져온다.

 

파이프 필터 구조

파이프 필터 구조는 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복된다.

서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 한다.

각 필터는 입력 파이프에 받은 데이터의 내용과 형식만을 알고 그것을 생성한 필터에 대하여는 모른다.

파이프와 필터 구조는 변경 가능하다. 필터는 다른 필터와 교환 될 수 있고 다른 목적으로 재구성될 수 있다.

파이프 필터 구조의 대표적인 예는 Unix 쉘이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

1. 1
2. 3
3. 4
4. 4
5. 2
6. 3
7. 2
8. 1
9. 4
10. 3
11. 2
12. 4
13. 3
14. 4
15. 1

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

데이터베이스

1. PROJECT=>Cartesian Product
2. SELECT
3. 동등(Equi)=>세타(Theta)
4. 삼각형 옆으로
5. 자연(Natural)

업무프로세스

1. BSC=>FORCE
2. SSR=>Shared Value
3. 6,000,000,000
4. 현금흐름표

전산영어

1. Computer Network
2. LAN
3. Topology
4. Protocol
5. MODEL=>Node

알고리즘

1. N - i
2. A(J + 1)
3. A(J) = A(i)=>A(J) = A(J+1)
4. A(K)
5. A(L) - AVG

배열

5

6

3

1

2

4

 

1회전

5

3

1

2

4

6

2회전

3

1

2

4

5

6

3회전

1

2

3

4

5

6

디버깅

SUM	STN	i	J	A(J)	A(J+1)	TEMP	K	AVG
0	0
		1	1	5	6
			2	6	3	6
				3	6
			3	6	1	6
				1	6
			4	6	2	6
				2	6
			5	6	4	6
				4	6
		2	1	5	3	5
				3	5
		…	…	…	…	…
		3
2							2
5							3
…							…
14							5
								14/4
SUM		L				TEMP		AVG
14		2				2

신기술 동향

1. Femtocell
2. Telepresence=>VoIP
3. MIMO=>SaaS
4. MIMO=>IMS
5. VLC=>Telepresence

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

알고리즘

1. N = N + 1
2. CHA = 77 – GK(N)
3. CHA = GK(N) - 77
4. COMP = CHA
5. GK(N)

80

90

60

75

100

-75

COMP	N	GK(N)	CHA	FGK
500	0
3	1	80	3	80
	2	90	7
	3	60	17

 

신기술동향

1. Virtual Advertisement
2. UCC 가이드라인
3. u-헬스 케어
4. DAB=>One Seg
5. RSS

 

데이터베이스

1. 기본키
2. 1:1
3. 1:N
4. 후보키
5. 유일성

 

전산영어

1. Hardware
2. Sftware
3. 3=>Operating System
4. Multitasking
5. Debug

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

신기술 동향

1. ISP=>EA
2. BPR=>SCORM
3. CTTH
4. SOA
5. E-PASSPORT=>POSTNET

알고리즘

1. I+1
2. COST(I) = COST(J)
3. COST(K)
4. K = K + 1=>L = L + 1
5. L = L + 1=>K = K + 1

K	L	MIN_TOT	I	J	COST(I)	COST(J)	TEMP	CYCLE(K)
1	1	0

데이터베이스

1. 기본키
2. 1NF=>2NF
3. 3NF
4. 개체 무결성
5. 후보키

전산영어

1. 1=>MULTIMEDIA
2. 2=>TEXT
3. 3=>IMAGE
4. 4=>AUDIO
5. CODEC=>ANIMATION

업무프로세스

1. EAI=>SEM
2. BSC
3. 기업인수자
4. 일반투자자

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.