토끼는 여행을 한다

1. 나선형 모형

1.1 특징

● Spiral Model 이라 하고, 점진적 모형 이다.
● 보헴 (Boehm)이 제안 했다.
● 개발 시 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.

1.2 개발 순서

● 계획 및 정의 -> 위험분석 -> 공학적 개발 -> 고객 평가 -> 계획 및 정의 
● 그림

1.3. 장점

● 가장 현실적인 모형으로 대규모 프로젝트나 큰 시스템에 적합
● 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가
● 유지보수 과정이 필요 없다.
● 위험 분석 단계에서 위험 요소들을 하나씩 제거해 나감으로써 완성도 높은 소프트웨어 만들 수 있다. 

1.4 단점

● 많은 비용과 시간을 투자하고도 실패로 끝날 수 있다.
● 위험성 평가에 크게 의존하므로 발견하지 못 하면 반드시 문제가 발생한다.
● 비교적 최신 기법으로 널리 사용되지 않는다.

5. 저자의 전화번호가 016으로 시작하는 책은?

6. 언어 책은?

10. 모든 정보를 출력하세요.

랩에 속한 학생들중 21 살 이상인 학생들의 학번은?
//*/@studentid[../@age >=21]

웹 관련 공부를 하고 있는 학생들의 학법

//Student[contains(Study, '웹')]/@studentid

정상인 컴퓨터는?

//computers/*[@stuatus="정상"]

//*[@status="정상" or status="정상

1. 소프트웨어공학

1.1 SE?

소프트웨어의 개발, 운영, 유지보수를 위해 체계적이고, 통제되며, 정량적인 접근방법을 적용하는 것. 즉, 소프트웨어에 공학을 적용하는 것. (The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software

1.2 SE 목적은?

양질의 소프트웨어를 제작하기 위함이다.

-양질 = 사용자요구기능/ 재사용에 의한 높은 생산성/ 용의한 유지보수/높은 성능/ 기타

1.3 SE 핵심주제 3가지는?

① 프로세스 : 제품생산을 위해 수행되는 순서화된 활동 (분석-설계-구현-테스팅-유지보수)

② 방법 : 구조적방법론/객체지향방법론/ Agile방법론

※ Agile : 요구변화에 빠르고, 유연한 반응

③ 도구:프로세스와 관련된 작업이나 방법을 지원하는 컴퓨터 시스템

CASE(Computer Aided Software Engineering) 도구

2. 소프트웨어 개발 프로세스

2.1 폭포수 모델과 반복점증 모델의 차이점을 쓰시오.

- 점증모델의 강점

낮은 프로젝트 실패율, 향상된 생산성, 낮은오류률, 높은 위험을 초기에 경감시킴

3. UP

3.1 UP 특징은?

● 반복점증 소프트웨어 개발 프로세스에서 유명하다. (도입, 정제, 구축, 전이)

● Unified Process (통합된 프로세스?)

● iterative-and incremental software development 방법론

● UML-based modeling 방법론

● Use-case driven 방법론

● UP는 다른 방법들로부터 다양한 개념 도입

test-driven development

refactoring and continuous integration

risk-driven iterative development

architecture-centric iterative development

Not having a solid core architecture is a common high risk.

programming in pairs

agile approach

‘Agile’ means rapid and flexible response to change

※ 비기능적인거에 영향을 많이 받는다.

3.2 반복점증 활동분야 3가지

비즈니스 모델링 : 애플리케이션 도메인에서 가치있는 개념을 시각화 하기 위한 모델 산출물

요구사항 : 기능적/ 비기능적 요구사항을 표현하기 위한 유즈케이스 모델 및 보충명세서

설계: 소프트웨어 객체를 설계하기 위한 설계모델 산출

3.3

※ 노력과 강조점은 시간이 지나면서 변한다.

3.4 크게 뽑아서 이해

3.5 UP Phases

● Inception phase의 목적은 시스템을 개발할 가능성이 있는지 개발 가치가 있는지 충분히 조사하여 결정 하는 단계

● 공동 비전(목적) 수립

● 상위 수준에서 프로젝트 범위 설정

● 상위 수준의 위험요소 파악

● 비즈니스 사례 생성

● 기본적인 요구조사 (10%)

● 기본적인 비기능 요구조사

● 주의점

- Inception phase는 요구분석 단계가 아니며, 대부분 주요 요구분석 활동은 elaboration phase(정제단계)에 서 수행

- 객체지향과 관계 없음

- 상대적으로 짧은 시간(1주)에 수행

- 약간의 프로그래밍 필요

- 중요한 기술적인 문제를 해결하기 위해,

- 불명확한 주요 요구를 명확하게 하기 위해 ‘proof of concept’ 프로토타입 개발

3.6 Inception Artifacts

● 비전 및 비즈니스 케이스 : 상위수준의 목표 및 제약사항, 비즈니스 케이스를 기술하고 행정적인 요약문서를 제공한다.

● 유즈케이스 모델 : 기능적요구사항을 기술한다 . 대략 10%정도의 유즈케이스는 상제한 수준에서 분석한다.

● 보충명세서 : 비기능적요구사항을 기술한다.

● 용어집 : 핵심이 되는 도메인 용어 및 데이터사전

3.7 Elaboration Pharse (정제단계)

● elaboration phase의 목적은 inception phase의 기본 요구들을 반복 정제하여 대부분의 요구를 파악하고 이러한 요구들이 안정화되는 단계

● 프로젝트의 주요 소프트웨어 구조를 반복적으로 구현하고 테스트

● 중요하고 기술적으로 위험한 요소 해결

● 대부분의 요구 파악

● 주의점

-Elaboration phase는 반복적(2-6주)으로 수행

-폭포수 모델에서의 설계단계가 아님

-폐기 프로토타입을 개발하는 것이 아니라 최종 시스템의 부분이 되는 increments 생성

-각 반복에서 객체지향 분석/설계 방법을 적용하는 주요 단계

3.8 정졔단계 산출물

● 도메인모델 : 도메인 개념을 가시화 한다. -정적정보모델과 유사한다.

● 설계 모델 : 로직설계를 설명하는 다이어그램의 집합이다. (클래스다이어그램, 객체인터렉션다이어그램, 패키지 다이어그램등을 포함한다.)

● 데이터모델 : 데이터스키마, 객체와 비객체 표현간의 매핑전략을 포함한다.

4. UML

4.1 UML 이란?

● Unified Modeling Language

● OO 시스템을 설계하고 묘사하는 것을 돕는 그래픽(다이어그램) 표기법

● 그래픽 모델링 언어

● 80-90년대 수많은 OO 그래픽 모델링 언어들의 통합 모델링 언어

4.2 UML 특징(UML표기법을 사용하여 모델링 하는 이유?)

● 시스템을 다양한 각도에서 볼 수 있는 시각적인 뷰(view) 제공 -> 시스템 이해 용이

● 다양한 시스템 유형(예, 정보, 내장, 실시간, 제어)에 대하여 모두 적용 가능

● 개발 방법론(구조적, 객체지향…)에 관계 없이 적용 가능

● UML이 표준이 된 이후 모든 CASE 도구는 UML 지원

● 단점 : 복잡함

4.3 UML을 적용하는 세가지 방법

● 스케치로서의 UML : 비정형적이고 완벽하지 않은 다이어그램

● 청사진으로서의 UML : 비교적 상세한 설계 다이어그램

● 프로그램 언어로서의 UML : S/W 시스템의 명세를 실행가능 수준까지 완성.

4.4 다이어그램에 따른 그림떠올리기.

4.5 (왕중요!) UML 시스템의 3가지 관점을 쓰세요.

6. Use Cases

6.1 요구란?

요구는 시스템이 수행해야 하는 능력(capabilities) 과 조건(conditions)

● 능력 = 기능요구(functional requirements)

● 조건 = 비기능요구(non-functional requirements)

6.2 요구의 종류란?

UP에서 요구들은 FURPS+ 모델에 의해 분류

● Functional(기능성) : features, capabilities, security (특징, 기능, 보안)

● Usability(사용성) : human factors, help, documentation (인적요소, 도움말, 문서)

● Reliability(신뢰성) : frequency of failure, recoverability, predictability (복구성, 예측성, 실패빈번도)

● Performance(성능) : response times, throughput(처리량), accuracy, availability, resource usage

(반응시간, 처리량, 정확성, 가용성, 자원사용성)

● Supportability(지원성) : Adaptability, maintainability, internationalization, configurability

(적응성, 유지보수성, 국제화, 구성력)

● FURPS+에서 ‘+’는 기타 요구를 가리킴

- Implementation : Language, tools, hardware, ….

- Interface : constraints by interfacing with external systems (외부시스템과의 연계에서 오는 제약사항)

- Operations : operational setting

- Packaging

- Legal : licensing

6.3 Requirements Artifacts in UP

● Use Case Model : 시나리오의 집합

● Supplementary Specification(보충명세) : 비기능적인 것들

● Glossary(용어사전)

● Vision

6.4 사용사례 (7)

● 기능요구를 발견하고 기록하기 위해 이용되는 다이어그램이 아닌 텍스트로 작성된 이야기

● 사용자 목적(goals)을 만족하기 위해 시스템을 이용하는 이야기

● 시스템 사용자와 시스템 사이의 상호작용 기술

● 시스템 기능에 대한 요구를 발견하고 정의하기 위해 적용되는 가장 핵심 방법

● 시스템 개발시 객체 지향과 관계 없으나, OOA/D에 입력되는 중요한 요구

● 사용자 요청에 대한 응답으로 시스템이 수행하는 활동

● 시스템이 제공하는 서비스를 표현

6.5 사용사례 서술

● 텍스트로 서술

● A use case includes a whole sequence of steps to complete the use case

(유즈케이스를 완성하기 위해 전체 시퀀스 스텝을 포함한다.)

● A use case is a set of scenarios (시나리오의 집합)

● A scenario is a particular sequence of steps within a use case  (시나리오는 UseCase 범위 이내의 집합)

● A use case might have several different scenarios

- Success(정상) scenarios

- Exception(예외) scenarios

● 서술에 대한 3가지 수준

- 간단(brief) : 일반적으로 주요 성공시나리오를 표현하는 간결한 한 문단의 요약

- 중간(intermediate)

- 완전(fully developed) : 모든 단계와 변형이 상세하게 작성된다.

6.6 Use case 작성지침

● UI를 고려하지 말고 Use-case작성

-사용자는 ID와 PW를 대화 창에 입력한다

사용자는 신원정보를 제공한다

● Black-box Use-case 작성

-시스템은 판매량을 데이터베이스에 기록한다

시스템은 판매량을 기록한다

● 사용사례의 크기 정도

-사용사례는 한 단계가 아닌 여러 단계를 포함하므로 분석할 가치가 있을 정도의 크기로 사용사례 결정

-보기 1

고객이름 입력 (너무작다)

고객정보입력 (분석에 적당)

고객처리 (너무크다)

-고객정보입력, 고객정보갱신, 고객정보삭제, 미납고객처리

6.7 Use Case 발견방법

① 시스템 범위 결정

② Actor 파악

-시스템의 서비스를 이용하여 그들의 목적을 만족시키는 행위자(역할에 의해) 파악

-(보기) POS 시스템에서 ‘고객’이 시스템을 이용하는가 ‘계산원’이 시스템을 이용하는가???

③ 각 Actor의 목적 파악

-actor에게 시스템을 사용하는 목적을 물음

-다음과 같은 문장 이용

“The order clerk(actor) uses the system to create a new order(use case)”

④ actor-goal 목록 작성

⑤ 사용사례 다이어그램 작성

-목적은 사용사례 이름이 됨

6.8 Use Case 다이어그램

● Use case는 텍스트 문서

● Use case 다이어그램은 외부 actors과 이러한 actors이 어떻게 시스템을 이용하는가를 간결하게

설명하는 시스템의 그래픽문맥 다이어그램

-문맥(context) 다이어그램 : 시스템의 범위를 보이는 다이어그램

6.9 include 관계

하나의 use case 가 공통 use case를 필요로 하는 경우

6.10 Use Case 작성을 위한 Activity 다이어그램 활용

● Activity 다이어그램은 작업흐름이나 비즈니스 흐름을 표현하는데 유용

● Use Case는 작업흐름이나 비즈니스 흐름을 포함하므로 use case를 텍스트로 작성하는 것에 대한

대안으로 이용될 수 있음

7. Inception (도입)

7.1 도입을 이해하지 못한 경우

도입단계에서 많은 시간을 소비하는 경우

도입단계에서 대부분의 요구를 정의하려고 시도하는 경우

신뢰할 수 있는 추정(estimates)이나 계획(plans)이 기대되는 경우

프로젝트에 대한 비즈니스 케이스나 비전을 정의하지 않는 경우

모든 사용사례(use-case)가 상세히 정의되는 경우

어떤 사용사례도 상세히 정의되지 않은 경우

-요구의 10-20%는 프로젝트를 이해하기 위해 상세히 작성되는 것이 필요

7.2 Inception Phase : 시작단계

● Inception phase의 목적은 시스템을 개발할 가능성이 있는지 개발 가치가 있는지 충분히 조사하여 결정 하는 단계

● 공동 비전(목적) 수립

● 상위 수준에서 프로젝트 범위 설정

● 상위 수준의 위험요소 파악

● 비즈니스 사례 생성

● 기본적인 요구조사 (10%)

기본적인 비기능 요구조사

● 주의점

-Inception phase는 요구분석 단계가 아니며, 대부분 주요 요구분석 활동은 elaboration phase(정제단계)에서 수행

-객체지향과 관계 없음

-상대적으로 짧은 시간(1주)에 수행

-약간의 프로그래밍 필요

중요한 기술적인 문제를 해결하기 위해,

불명확한 주요 요구를 명확하게 하기 위해 ‘proof of concept’ 프로토타입 개발

7.3 반복에서 요구노력

I -1 week : 상위수준의 유즈케이스 리스트에서 10% 정도를 선택하여 상세하게 분석하고 작성을 한다.

E -4 week : 유즈케이스의 30% 정도를 상세하게 완성

E2-4 week : 유즈케이스의 50% 정도를 상세하게 완성

E3-3 week : 반복하고 70%모든 usecase를 상세하게 완성

E4-3 week : 명확해지고 상세하게 작성한다.

8. Elaboration-Basics (ppt참고)

8.1 Elaboration Artifacts

● 도메인 모델 : 도메인의 개념을 가시화 한다. 도메인 개체들의 정적정보 모델과 유사

● 설계 모델 : 로직설계를 설명하는 다이어그램 집합 (클래스, 객체 인터렉션, 패키지 다이어그램)

● 소프트웨어 설계 문서 : 설게에서의 핵심 아키텍쳐문제와 그 해결방안을 요약하는 학습지원

● 데이터모델 : 데이터베이스 스키마, 객체와 비객체 표현간의 매핑전략을 포함한다.

※도메인 모델, Use case 모델, 설계 모델 차이점!!!

도메인 모델 : 어떤 도메인에서 중요한 개념들을 표현하는 모델 (=개념클래스)

9. Elaboration Domain Model

9.1 산출물의 예 (ppt 참조 그림참조)

9.2 도메인 모델 생성이유

● 도메인에서 사용되는 중요 개념과 어휘를 이해하기 위해

● 도메인 모델에서 객체(클래스) 이름은 디자인 모델에서 소프트웨어 객체(클래스)이름으로 이용되어

실 세계 모델과 소프트웨어 모델 사이의 차이가 낮아짐

9.3 “개념클래스” 발견 3가지 방법

● 존재하는 모델 재사용 : 이미 존재하는 정보 시스템 도메인 모델이나 데이터 모델 재사용

● 카테고리 목록 재사용 : 정보 시스템 도메인에서 공통으로 사용되는 개념 클래스 목록 사용

● 문장분석에 의한 명사 식별 :

도메인에 대한 텍스트 기술(사용사례)에서 명사나 명사구 식별하여 개념 클래스나 속성(attributes)으로 사용

10. SSD(시스템 시퀀스 다이어그램 ppt 참고)

11. Elaboration Logic Architecture

11.1 논리적 구조란?

● 전형적인 OO 시스템의 설계는 다양한 시스템 구조(architecture)에 기초

-클라이언트-서버 구조, 분산 구조, 계층 구조

● 논리적 구조(logical architecture)는 서로 밀접하게 관련되는 컴포넌트(클래스)들을 패키지, 서브시스템, 계층(layer) 그룹으로 구성하는 것

-UML 패키지 다이어그램에 의해 표현

11.2 계층구조

● 시스템을 계층으로 구성

● 일반적으로 하위계층은 하드웨어를 다루는 컴포넌트들로 구성하며, 하위계층은 상위계층이 이용할 수 있는 서비스 컴포넌트들을 정의

※p198(그림참조) : 논리적아키텍쳐는 보충명세에 의해 파악되는 제약사항과 비 기능적 요구사항에 영향을 받는다.

※p119(그림참조) : UI와 같은 상위 계층이 하위 계층이 제공하는 서비스를 호출하도록 구성.

11.3 UML 패키지 다이어그램

UML 패키지 다이어그램은 어떤 요소들을 그룹화 하는데 사용

11.4 P203 어플리케이션 계층 그림 해석;

11.5 계층구조 장점

● 결합도, 의존성, 복잡성 감소

● 응집력 개선

● 재사용, 명확성 증가

11.6 p207 도메인 계층과 도메인 모델은 어떤관계?

● 도메인 모델을 살펴 봄으로써 도메인 계층의 클래스 이름에 대한 영감을 얻을 수 있다.

● 도메인에 대한 인식과 실제 소프트웨어 구현간의 표현상의 차이가 줄어들게 된다.

11.7 SSD와 layer 사이의 연결 (ppt참고)

12. Elaboration Interaction Diagrams

12.1 상호작용 다이어그램이란?

● 객체들이 메세질르 통해 어떻게 상호작용하는지 표현하는 다이어그램

● 동적 OO 설계를 위해 이용

12.2 Sequence vs. Communication

● 두개의 다이어그램 모두 객체와 객체 사이의 상호작용 표현

● Sequence Diagram

-시퀀스 다이어그램의 주된 관점은 시간 축에 의한 메시지 교류의 순서

-시간에 중점, 메시지 호출 순서 강조

※장점

- 호출 흐름 순서에 의해 이해 용이

- 위에서 아래로

- 역공학 UML 도구로 부터 용이한 생성

※단점

- 객체 추가 시 계속 오른쪽으로 확장

● Communication Diagram

- 통신 다이어그램의 주된 관점은 객체 사이의 상호작용에 대한 관계

- 공간에 중점 , 객체 사이의 연결 강조

- UML 1.x에서 ‘collaboration’ diagram이라 부름

12.3 다이어 그램

12.4 기본표기법

메시지 종류

※동기(Synchronous) 메시지

보내는 객체가 수신 객체의 응답을 기다려야만 하는 메시지

―▶

※비동기(Asynchronous) 메시지

보내는 객체가 수신 객체의 응답을 기다릴 필요 없이 자신의 작업을 계속할 수 있는 메시지 

→


12.5 Frames

●UML은 조건이나 반복 구조를 지원하기 위해 frame 표기법 사용

●Frame은 다이어그램의 영역을 나타내며 연산자(예, loop)와 조건(guard)을 포함

용어

● SDLC (System Development Life Cycle) : the entire process of building, deploying, using, and updating an information system

● tool : automated or semi-automated support for the process and the methods

● UML : the unified notation of the many OO graphical modeling languages

● Use Case : an activity the system performs, usually in response to a request by a user

● class diagram : represent the static structural view of a system

● activity diagram: an effective technique to document the flow of activities for each use case scenario

● model : represent some aspects of the system being built

● analysis : define what users need and want without regard to specific technology

● scenario : a particular sequence of steps within a use case

● method : guidelines that help an analyst complete a system development activity

● design : how the system will satisfy that users want and need


이거 가지고 시험에 참고하면 큰일! 참고만!

이 과목 공부할때

Bruegge, "Object oriented software engineering :using UML, patterns, and Java", Prentice Hall, 2010. 

도움이 많이 된 책
물론 저기의 내용이 저 책안에 있으니까 ㅍ▽ㅍ

1. 오른쪽 마우스 클릭 방지

<script language=JavaScript>
 try {
 document.attachEvent('oncontextmenu', function () {
  return false;
 });
 } catch(e) {}
</script>

2. 드래그 금지 (Ctrl + C 금지)

<html>
<head>
<title></title>
<script>
<!--
 function dragno()
 {
       return false;
 }
 function defencespell()
 {
       eval('document.'+event.propertyName+'=dragno');
 }
//-->
</script>
</head>
<body onpropertychange="defencespell()" oncontextmenu="return false;" ondragstart="return false;" onselectstart="return false;">

</body>
</html>

펌 : http://jong970105.tistory.com/257

그래서 복사도 그림도 펌 금지 할때는

<html>
<head>
<title></title>
<script language=JavaScript>
 try {
 document.attachEvent('oncontextmenu', function () {
  return false;
 });
 } catch(e) {}
</script>
<script>
<!--
 function dragno()
 {
       return false;
 }
 function defencespell()
 {
       eval('document.'+event.propertyName+'=dragno');
 }
//-->
</script>
</head>
<body onpropertychange="defencespell()" oncontextmenu="return false;" ondragstart="return false;" onselectstart="return false;">

</body>
</html>

2010년 6월 7일

2010년 5월 24일

2010년 4월 26일

1. 임베디드 시스템 개요

(1)임베디드 시스템에서 주로 마이크로 컨트롤러를 사용하는 이유는?

➡ 단일 직접회로 내에 프로세서, 메모리, 일부 I/O 장치가 들어 있기 때문에 마이크로 컨트롤러를 사용한다.

(2)시스템 온칩에 대하여 설명하시오

➡ 각각 별개의 칩으로 존재하던 마이크로프로세서, 메모리, 입출력회로 등의 컴포넌트를 하나의 칩에 직접하는 것을 의미한다.

(3)임베디드 소프트웨어의 특징을 설명하시오.

➡ 실시간으로 처리한다. 고도의 신뢰성으로 오작동 및 작동 중지가 없어야 한다. 최적화 기술지원으로 경량화 저적력자원 자원이 효율적으로 관리 되어야 한다. 특정 목적 및 전용 소프트웨어를 개발해야한다. 네트워크 및 멀티미디어 처리기능을 지원해야 한다.

(4)임베디드 미들웨어에 대하여 설명하시오.

➡ 각기 분리된 2개의 프로그램 사이에서 매개 및 연결 역할을 하는 프로그램이다. 주로 복잡한 이기종 환경에서 응용프로그램과 운영체제 환경간에 원만한 통신을 이룰 수 있게 해주는 소프트웨어이다. 개발환경제공, 자원관리, 기기제어, 데이터 전송처리 등의 기능을 가지고 있다.

(5) 임베디드 운영체제의 분류에 대하여 설명하시오.

➡ 독립형 운영체제 / 전용 운영체제- 특정기능만 수행하도록 설계 되었다. 실시간 운영체제 - 실시간 동작을 운영한다. 범용 운영체제 - 응용프로그램을 작성하는 방법으로 다양한 목적과 기능을 가지는 경우에 사용한다.

2. 임베디드 시스템 개발과정

(1) 프로세서의 선정에 필요한 조건에 대하여 설명하시오.

● 필요한 인터페이스 : 프로세서는 외부와 연결되어 상호작용을 하므로 외부와의 인터페이스를 제어하고 데이터 처리 능력을 가지고 있어야 한다. 이것은 프로세서의 성능을 의미한다.

● 필요한 메모리 : 메모리 용량을 잘못한 경우 제작비용의 상승 또는 재설계 해야 하는 문제가 발생한다.

-RAM : Buffer, stack, FIFO 등의 크기를 포함한다.
-ROM : ROM의 크기는 프로그램 코드외 변환 테이블의 크기에 달려 있다.

● 필요한 입출력 : 외부 핀들은 입출력 용도로 사용될 수 있다. 따라서 시스템에서 상태 또는 센서의 입력, 제어 출력 등의 필요한 입출력 수에 따라 결정될 수 있다.

● 필요한 인터럽트 : 프로세서에서 외부장치와의 데이터 입출력은 주로 인터럽트로 수행된다.

● 실시간 처리 기능 : 프로세서의 처리속도와 밀접한 관련이 있으며, 인터럽트의 처리능력, 메모리 접근 속도 등도 고려되어야 한다.

● 개발환경 : 새로운 프로세서를 선택하는 것은 새로운 개별도구 및 환경을 구축하고 사용하는 것이다.

(2)운영체제를 선정할 때 고려해야 할 사항

➡ 프로세서, 실시간 성능, 예산에 대한 요구사항

(3)ICE(In-Circuit Emulator ) 란 무엇인가를 설명하시오.

➡ 프로세서와 나머지 시스템 간의 상호작용 정보를 가로채서 보여주는 장비이다.

(4)디버거에 있는 디버거 기능에 대하여 설명하시오.

➡ BDM 과 JTAG 디버거가 있는데 프로세서의 특별한 핀을 통해 프로세서 자체에 내장된 기능을 사용하는 디버깅 장치이다.

(5) 임베디드 시스템의 중요한 특징은?

➡ H/W 와 S/W 사이의 상호 밀접한 관련성을 가지므로 시스템 개발시 동시에 개발이 진행되어야 한다.

3. 임베디드 하드웨어

(1) 마이크로프로세서와 마이크로컨트롤러의 차이점에 대하여 설명하시오.

● 마이크로프로세서 : 일반적으로 프로세서를 한 개의 칩으로 구현된 것이며 데이터 처리 부분과 제어부분을 가진 코어를 의미한다. 명령어 처리 능력을 가진 부분만 구현하여 명령어를 최대한 빠르게 수행하는 것을 목적으로 개별 되었다.

● 마이크로컨트롤러 : 명령어를 처리하는 프로세서 코어 이외에 메모리, 입출력장치들 까지 한 칩에 되어 있으며, 코어의 기능 보다는 여러 응용분야에서 필요한 주변기기들이 칩내에 있으므로 개발에서 칩의 수를 줄일 수 있다.

(2)임베디드 시스템에서 마이크로컨트롤러를 쓰는 이유를 설명하시오.

① 하나의 부품으로 여러 부품을 대신할 수 있어 저비용 구현이 가능하다.

② 패키지화 가능하여 성능이 향상된다.

③ 신호들이 내부에서 동작하기 때문에 빠른 동작속도를 가진다.

④ 낮은 잡음신호 방출한다.

(3) RISC 구조 프로세서의 특징을 설명하시오.

 
(4)메모리를 사용할 때 고려되는 특성들에 대해서 설명하시오.

접근성, 쓰기용이성, 휘발성, 프로그램 가능성, 비트 당 가격

(5) SRAM과 DRAM의 차이점을 설명하시오.

(6) 플래시 메모리에 대한 특징을 설명하시오.

플래시 메모리에는 NOR형과 NAND형이 있다. NAND 형은 프로그램 소거가 빠르지만, 쓰기에서 바이트 단위 처리가 불가능하며, 일반메모리처럼 단순하게 데이터 버스와 어드레스 버스를 사용하여 읽을 수 없어 소프트웨어적인 작업을 수행해야 하므로 번거러울 뿐 아니라, 별도의 실행코드 저장용 메모리 영역을 필요로 한다.

NOR형은 읽기, 쓰기가 바이트 단위가 가능하지만, 쓰기/지우기가 느리다는 단점이 있다.

(7)가상메모리에 대해 설명하시오.

각 프로그램에서 실제 메모리 주소가 아닌 가상의 메모리 주소를 주는 방식을 말한다. 프로세서는 실행할 명령과 데이터를 읽기/쓰기를 위해 주소정보와 제어신호를 생성한다. MMU는 주소정보가 메모리 장치 영역인가를 검사하고 가능하면 물리주소로 변환하여 메모리제어기로 정보를 전달한다.메모리제어기는 주소정보를 이용하여 메모리장치를 선택하고 해당 메모리장치에 신호를 발생시킨다.

(8)입출력 인터페이스에 대해 설명하시오

다양한 물리적인 장치와 전자적인 장치의 동기화, 신호의 변환, 입출력장치와 프로세서의 처리속도차이, 데이터와 메모리의 워드형식차이등을 해결한다.

(9)입출력제어기기에 대해 설명하시오,

데이터의 버퍼링, 제어신호의 논리적변환, 제어신호의 물리적변환, 오류제어 등의 기능을 수행한다.

4. 임베디드 시스템 개발환경

(1) 교차 개발환경에 대해 설명하시오.

호스트 시스템과 타깃 시스템의 프로세서가 다른 경우에 소스 프로그램의 컴파일은 호스트 시스템에서 수행되므로 호스트시스템에는 타깃 시스템에서 실행되는 기계어 코드를 생성할 수 있는 개발환경을 말한다.

(2) 오브젝트 파일의 정보에 대하여 설명하시오.

● 배치 가능한 오브젝트 파일 : 링크를 쉽게 할 수 있는 2진코드와 데이터를 가지고 있으며, 실행 파일을 만들거나 공유 오브젝트파일을 생성하기 위하여 다른 오브젝트 파일과 결합될 수 있는 형태의 파일

● 실행 가능한 오브젝트 파일 : 실행 가능한 2진 코드와 데이터를 가지고 있으며, 메모리로 직접로드웨어 실행될 수 있는 형태의 파일

● 공유 오브젝트 파일 : 재배치 가능한 오브젝트 파일의 특별한 타입으로, 두 개의 환경에서 링크에 적합한 형태의 2진코드와 데이터를 가지고 있으며, 로드할 때나 실행할 때 동적으로 메모리로 로드되고 링크될 수 있는 파일

(3) 사용자 섹션을 정의 하여 메모리를 매핑하는 이유를 설명하시오.

모듈업그레이드 / 메모리크기 제한/ 데이터 보호를 위해 메모리에 매핑한다.

(4) 링커 명령파일에 대하여 설명하시오.

MEMORY 지시문 : 타깃 시스템의 메모리 맵을 나타낼 때 사용한다.

SECTION 지시문 : 심볼 해결 과정에 링커가 사용할 메모리 주소를 개발자가 원하는 곳으로 설정하는데 사용한다.

(5)개발과정에서 생성된 실행이미지를 전송하는 방법을 설명하시오.

ROM에 전체 이미지를 직접 프로그램 하는 방법

직렬 또는 네트워크 케이블 연결을 통하여 이미지를 다운로드하는 방법

JTAG 또는 BDM 인터페이스를 통하여 이미지를 다운로드 하는 방법

(6)임베디드 모니터에 대하여 설명하시오.

타깃 시스템 공급업자가 평가보드를 위하여 제공하는 응용프로그램이다. 초기화 작업을 한다. (주변장치 초기화, 메모리 초기화, 인터럽트 초기화 수행)

(7)ON CHIP 디버깅

반도체 칩 업체에서 제공하는 기능으로 고가 장비인 ICE 나 타깃 시스템 없이도 마이크로프로세서와 시스템 자원을 직접접근할 수 있는 것으로 BDM, JTAG을 가리킨다.

(8)부트로더에 대하여 설명하시오.

시스템 부트, 이미지 다운로드, 시스템 초기화를 수행하는 코드라 정의 할 수 있다.

부트스트랩의 과정 : 타깃 시스템에 전원이 들어오면 프로세서는 0번지에 들어있는 명령(리셋벡터)을 실행하면 0x00100h번지로 점프하게 되고 이곳에 있는 시작 촟기화 코드로 실행권한이 넘어간다.

(10) 초기화 화정에 대하여 설명하시오.

① 리셋벡터에서 수행을 시작

② 프로세서 레지스터에 적절한 값을 설정하여 안정한 상태로 유지

③ 인터럽트와 캐시를 비 활성화

④ 메모리 관련 사항을 초기화

5. 임베디드 운영체제

(2)마이크로커널의 특징

프로세스 관리와 메모리관리 기능을 분리시켜 나누어놓은 구조로 클라이언트-서버 운영체제라고도 한다. 추가의 기능이 동적으로 부가될 수 있으므로 규모가 크고 디버깅이 가능한 구조이다. 클라이언트와 서버 기능에 대하여 분리된 메모리 공간을 가지므로 보안성이 좋다.

(3) 임베디드 운영체제의 기술 동향

풍부한 네트워크 솔루션제공

임베디드 기기에 적합한 GUI 지원

멀티미디어의 기능의 확장

모바일 디바이스를 위한 저저력지원

풍부한 하드웨어 지원을 통한 빠른 적용성

원도우 GUI기반의 편리한 사용자 인터페이스를 제공하는 개발도구

특정제품에 대하여 하드웨어에서 응용까지 플랫폼 솔루션 제공

(4) 임베디드 시스템에서 리눅스를 적용하는 이유

-모든 소스가 공개된 운영체제 이다. 커널 및 전 계층에 대하여 프로그램 변경 및 수정이 가능하다.

-안정적이며 기능이 검증되어 있다.

-강력한 멀티태스킹, 네트워킹을 지원한다.

-최적화된 작고 안정된 운영체제를 만들어 사용할 수 있다.

-개발환경이 기본적으로 제공된다

-개발비용 및 사용료가 거의 들지 않는다

-다양한 장치를 사용하기 위해 드라이버가 제공된다.

(5)임베디드에서 기술적으로 해야할 연구과제는 무엇인가?

- 저전력시스템 개발

-효율적인 메모리관리 기술

-GUI 연구 및 개발

-안전적 시스템 소프트웨어 개발

-실시간 보안

-부분 시스템으로서의 임베디드 시스템

(6) 리눅스 커널의 구성에 대해서 설명하시오.

프로세스 관리

프로세스의 생성 및 소멸

프로세스 간의 통신

CPU 스케줄링 동기화

제한된 자원에 대한 다중 프로세서의 효율적인 관리 기법 제공