*주* 스토어

*주*

개인

팔로워0 팔로우

소개

등록된 소개글이 없습니다.

전문분야 등록된 전문분야가 없습니다.

판매자 정보

학교정보

입력된 정보가 없습니다.

직장정보

입력된 정보가 없습니다.

자격증

입력된 정보가 없습니다.

판매지수

판매중 자료수

6개
전체 판매량

8개
최근 3개월 판매량

0개
자료후기 점수

평균A+
자료문의 응답률

100%

전체자료 6개

데이터베이스 프로젝트용 보험시스템 프로그램 소스

데이터베이스 프로젝트용 보험설계시스템의 MFC 프로그램 소스관련 PT자료는 따로 올려져 있음DB생성파일이 빠져있었습니다. 다음은 DB생성 SQL입니다.CREATE DATABASE DBPROJECT;/* STAFF와 INSUREDPERSON의 부모에 해당하는 공통인적사항에 관한 테이블*/CREATE TABLE PERSONALINFO(SerialNochar(13,0)NOT NULL,PersonNamechar(25)NOT NULL,Addresschar(300)NULL,HomePhonechar(13)NULL,MobilePhonechar(13)NULL,OfficePhonechar(13)NULL,Emailchar(100)NULL,Faxchar(13)NULL,CONSTRAINTPersonalInfoPKPRIMARY KEY(SerialNo),);/*INSUREDPERSON에 할당되는 담당직원에 관한 테이블*/CREATE TABLE STAFF(SerialNochar(13,0)NOT NULL,BranchAreachar(30)NULL,BranchStorechar(30)NULL,StorePhonechar(13)NULL,CONSTRAINTStaffPK PRIMARY KEY(SerialNo),CONSTRAINTStaffFKFOREIGN KEY(SerialNo) REFERENCES PERSONALINFO(SerialNo)ON DELETE CASCADE ON UPDATE CASCADE);/*차량의 제조사에 관한 테이블*/CREATE TABLE MAKERS(MakerSerialNointNOT NULLIDENTITY(1,1),MakerNamechar(30)NOT NULL,CarNamechar(30)NOT NULL,ModelNamechar(30)NOT NULL,IsAutobitNOT NULLDEFAULT 0,PremiumintNOT NULL,MakedYearnumeric(4,0)NULL,CONSTRAINTMakersPKPRIMARY KEY(MakerSerialNo),CONSTRAINT MakerAK UNIQUE(CarName,ModelName,MakedYear,IsAuto));/*개개의 차량 인스턴스에 관한 테이블*/CREATE TABLE CARS(CarSerialNochar(15)NOT NULL,MakerSerialNointNOT NULL,CONSTRAINTCarsPKPRIMARY KEY(CarSerialNo),CONSTRAINTCarsFKFOREIGN KEY(MakerSerialNo)REFERENCES MAKERS(MakerSerialNo)ON DELETE NO ACTIONON UPDATE CASCADE);/*직업의 종류에 관한 테이블*/CREATE TABLE JOBS(JobCodeintNOT NULLIDENTITY(1,1),JobNamechar(30)NOT NULL,RiskRateintNOT NULLDEFAULT 0,CONSTRAINTJobsPKPRIMARY KEY(JobCode),CONSTRAINT JobsAK UNIQUE(JobName));/*피보험자에 관한 테이블*/CREATE TABLE INSUREDPERSON(SerialNochar(13,0)NOT NULL,CareerintNULLDEFAULT0,TrafficViolationRateintNULLDEFAULT100,DiscountExtraRateintNULLDEFAULT100,EngagedJobintNULL,ChargeStaffchar(13,0)NOT NULL,OwnerCarchar(15)NOT NULL,CONSTRAINTInsuredPersonPK PRIMARY KEY(SerialNo),CONSTRAINTInsuredPersonFKFOREIGN KEY(SerialNo) REFERENCES PERSONALINFO(SerialNo)ON DELETE NO ACTION ON UPDATE CASCADE,CONSTRAINTInsuredPerson_StaffFKFOREIGN KEY(ChargeStaff)REFERENCES STAFF(SerialNo)ON DELETE NO ACTIONON UPDATE CASCADE,CONSTRAINTInsuredPersonAKUNIQUE(OwnerCar),CONSTRAINTInsuredPerson_CarFKFOREIGN KEY(OwnerCar)REFERENCES CARS(CarSerialNo)ON DELETE NO ACTIONON UPDATE CASCADE,CONSTRAINTInsuredPerson_JobFKFOREIGN KEY(EngagedJob)REFERENCES JOBS(JobCode)ON DELETE NO ACTIONON UPDATE CASCADE);/*보험상품에 관한 테이블*/CREATE TABLE PRODUCT(ProductIDintNOT NULLIDENTITY(1,1),ProductNamechar(30)NOT NULL,PackageProductIDintNULL,CONSTRAINTProductPKPRIMARY KEY(ProductID),CONSTRAINTProductFKFOREIGN KEY(PackageProductID)REFERENCES PRODUCT(ProductID)ON DELETE NO ACTIONON UPDATE NO ACTION,CONSTRAINTProductAKUNIQUE(ProductName));/*상품의 구성요소중 담보부품들*/CREATE TABLE WARRANTY(WarrantyIDintNOT NULLIDENTITY(1,1),WarrantyNamechar(60)NOT NULL,WarrantyRateintNULL,WarrantyFeeintNOT NULL,WarrantyPriceintNULL,CONSTRAINTWarrantyPKPRIMARY KEY(WarrantyID),CONSTRAINTWarrantyAKUNIQUE(WarrantyName));/*상품의 구성요소중 특약부품들*/CREATE TABLE SPECIALCONTRACT(SpecialContractIDintNOT NULLIDENTITY(1,1),SpecialContractNamechar(60)NOT NULL,SpecialContractRateintNULL,SpecialContractFeeintNOT NULL,SpecialContractPriceintNULL,ApplyAgreementtextNULL,CONSTRAINTSpecialContractPKPRIMARY KEY(SpecialContractID),CONSTRAINTSpecialContractAKUNIQUE(SpecialContractName));CREATE TABLE PRODUCTWARRANTY(ProductIDintNOT NULL,WarrantyIDintNOT NULL,CONSTRAINTProductWarrantyPKPRIMARY KEY(ProductID, WarrantyID),CONSTRAINTProductWarranty_ProductFKFOREIGN KEY(ProductID)REFERENCES PRODUCT(ProductID)ON DELETE NO ACTIONON UPDATE CASCADE,CONSTRAINTProductWarranty_WarrantyFKFOREIGN KEY(WarrantyID)REFERENCES WARRANTY(WarrantyID)ON DELETE NO ACTIONON UPDATE CASCADE);CREATE TABLE PRODUCTSC(ProductIDintNOT NULL,SCIDintNOT NULL,CONSTRAINTProductSCPKPRIMARY KEY(ProductID, SCID),CONSTRAINTProductSC_ProductFKFOREIGN KEY(ProductID)REFERENCES PRODUCT(ProductID)ON DELETE NO ACTIONON UPDATE CASCADE,CONSTRAINTProductSC_SCFKFOREIGN KEY(SCID)REFERENCES SPECIALCONTRACT(SpecialContractID)ON DELETE NO ACTIONON UPDATE CASCADE);CREATE TABLE CONTRACT(ContractIDintNOT NULLIDENTITY(1,1),InsureStartDatedatetimeNOT NULL,InsureEndDatedatetimeNOT NULL,InsureFeeintNOT NULL,PayMethodintNOT NULLDEFAULT 0,ContractStatusbitNOT NULLDEFAULT 0,InsuredPersonIDchar(13,0) NOT NULL,ProductIDintNOT NULL,CONSTRAINTContractPKPRIMARY KEY(ContractID),CONSTRAINTContract_PersonFKFOREIGN KEY(InsuredPersonID)REFERENCES INSUREDPERSON(SerialNO)ON DELETE NO ACTIONON UPDATE CASCADE,CONSTRAINTContract_ProductFKFOREIGN KEY(ProductID)REFERENCES PRODUCT(ProductID)ON DELETE NO ACTIONON UPDATE CASCADE);

프로그램소스| 2006.09.18| 3,000원| 조회(1,172)

데이터베이스, 프로젝트, DB, 보험설계, Carinsure

미리보기

닫기
CORBA 서비스에 관한 조사

EventServiceEvent ServiceEvent Service는 객체들간의 통신을 분리한다. Event Service는 개체들을 이벤트 데이터를 생산하는 Supplier들과 이벤트 데이터를 처리하는 Consumer들, 이렇게 2개의 역할로 정의한다.이벤트 데이터는 표준 CORBA Request들을 보냄에 의해 Supplier들과 Consumer들 간에 통신이 된다. Supplier들과 Consumer들간의 이벤트 통신을 시작하는 접근은 Push Model과 Pull Model이라 불리는 2가지 방법이 있다.Push Model은 Supplier들이 Consumer들에 이벤트 데이터의 전송을 시작하게 된다.Pull Model은 Consumer들이 Supplier들에 이벤트 데이터의 전송을 시작하게 된다.Event Service는 변경알림(Change Notification)을 제공하는데 사용된다. 객체가 변경 또는 상태가 변화되면, 이벤트는 생성되고 모든 관심을 가지는 파티들에 전파되어진다.여기사 변화될 수 있는 객체는 Supplier로서 행동하고, 변경알림에 관심이 있는 파티들은 Consumer로서 행동한다. 이들 각각에 Push 또는 Pull Model이 사용될 수 있다. 그리고 이들 사이에 Event Channel이 끼어있을 수 있는데 Event Channel은 여러 Supplier들과 여러 Consumer들 간의 비동기적 통신을 할 수 있게 하는 객체이다.[그림 1-1] Consumer와 Supplier, Event Channel간의 관계[그림 1-2] Push Model – Notifier[그림 1-3] Pull Model - Procurer[그림 1-4] Hybrid Push/Pull Model – Queue[그림 1-5] Hybrid Push/Pull Model - Agent[그림 1-6] Event Service Interfaces and ClassesThe ACE(Adaptive Communication Environment) ORB : TAO’s RT Event Service Architecture[그림 1-7] TAO’s RT Event Service ArchitectureNaming ServiceNaming Service객체와 이름과의 연관관계는 Name Binding이라 불린다. Name Binding은 항상 관련된 Naming Context로 정의된다. Naming Context는 각각 유일한 이름을 가진 Naming Binding들의 집합을 포함하는 객체이다. 다른 이름들이 같은 혹은 다른 컨텍스트의 객체에 바인딩될 수 있다. 모든 객체들은 꼭 이름을 가져야한다.이름을 결정(resolve)하는 것은 주어진 컨텍스트내의 이름으로 연관된 객체를 결정하는 것이다. 이름을 바인딩하는 것은 주어진 컨텍스트를 바인딩 하는 이름을 생성하는 것이다. 이름은 항상 절대적인 이름들이 아니고 컨텍스트와 연관되어 결정된다.컨텍스트 또한 다른 객체와 유사하기 때문에 컨텍스트 또한 Naming Context내의 이름으로 바인딩 될 수 있다. 다른 컨텍스트들에 컨텍스트를 바인딩 하는 것은 Naming Graph를 생성한다. Naming Graph로 컨텍스트가 주어지면, 이름들의 순서로 어떤 객체를 참조할 수 있다.[그림 2-1] Naming Graph의 예[그림 2-2] CORBA의 Name과 NamingContext의 PIM 모델Lifecycle ServiceLifecycle Service다음의 분산된 객체의 Lifecycle의 문제를 해결하기 위한 서비스이다.분산 환경에 객체를 생성분산 환경에 객체를 삭제분산 환경에 객체를 복사하거나 이동분산된 객체의 연관관계를 유지한 상태에서의 운영클라이언트의 객체 생성을 위한 모델클라이언트의 Lifecycle 모델은 Factories라 불리는 객체로 구현된다.Factories는 다른 객체들을 생성하는 객체이다.Factories 객체는 잘 정의된 IDL 인터페이스를 갖게 되며, 어떤 프로그래밍 언어로 구현된다. Factories를 위한 표준화된 인터페이스는 없으며, 새로운 객체를 생성하고, 초기화하는 등의 특화된 오퍼레이션을 제공한다.클라이언트의 객체 삭제를 위한 모델목적 객체들이 LifeCycleObject 인터페이스를 제공함에 의해 구현된다.클라이언트는 목적 객체의 LifeCycleObject의 remove 요청을 통해 객체를 삭제한다.클라이언트의 객체 복사 또는 이동을 위한 모델목적 객체를 특정 위치에 복사 또는 이동하는 것은 목적 객체가 제공하는 LifeCycleObject와 복사 또는 이동을 할 위치를 가지고 있는 FactoryFinder를 통하여 구현된다.LifeCycleObject 인터페이스는 객체를 이동, 복사를 하기 위한 오퍼레이션을 정의한다.FactoryFinder는 복사 및 이동할 위치를 나타낸다.클라이언트는 FactoryFinder의 범위 내에 있는 Factory를 사용하여 목적 객체의 move 또는 copy를 요청한다.FactoryFinderFactoryFinder는 하나이상의 Factories를 찾아주는 오퍼레이션을 제공한다.클라이언트가 호출한 move 또는 copy 오퍼레이션은 전달된 FactoryFinder의 Factories를 찾는 메소드를 호출하게된다.FactoryFInder는 다음의 예와 같은 위치를 표시한다.work group의 로컬 네트워크상의 어떤 곳.X 머신상의 A 저장장치어떤 컴퓨터GenericFactory InterfaceGenericFactory 인터페이스는 객체 생성 시간에 객체에 할당되어지는 자원들을 관리해야 하는 환경을 위해 제공되어진다.Factories에 대한 표준 인터페이스는 없지만, GenericFactory 인터페이스는 create_object라는 generic creation 오퍼레이션을 정의한다. 그리고 이런 GenericFactory는 자원정책과 다중위치들의 표현에 대해 구현할 수 있다.이는 자원의 집합을 관리하는 것이 중요한 환경에서 특히 유용하다.RMIRMIRMI는 자바의 분산객체 표준 인터페이스이다. RMI 시스템은 JVM이라는 동종의 환경을 가정으로 하고 있으며, 그러므로 시스템은 자바 플렛폼의 객체 모델이 갖는 이점들을 포함하게 된다.RMI는 자체 고유의 아키텍쳐와 TCP 기반의 전송계층을 가지고 있지만, 최근에는 OMG가 RMI의 전송계층을 IIOP로 채택하는 것을 자바에서의 분산컴퓨팅 표준으로 인증함으로써 RMI는 CORBA 시스템과의 연동이 가능하게 되었다.RMI 아키텍처RMI는 기본적으로는 클라이언트/서버 모델을 기본으로 하고 있으며, 위 그림과 같이 세 계층으로 나눠진다.Stub / Skeleton Layer - 클라이언트와 서버간의 Remote Object 인터페이스에 대한 처리를 담당한다.Remote Reference Layer(RRL) - Remote Object의 생성/소멸(liveliness)을 관리한다. 또한 클라이언트/서버와 VM간의 Remote Object에 대한 커뮤니케이션(threading, garbage collection 등)을 관리한다.Transport Layer – 실질적인 클라이언트와 서버간의 정보 전송을 위한 TCP/IP 네트워크 및 통신을 담당한다.RMI Communication ProcessClient는 먼저 Server의 Remote Object의 메소드를 호출하기 위해 Remote Object의 Reference를 얻어와야 한다. Client가 Remote Object의 Reference를 얻을 수 있는 방법으로 두 가지가 있다. 첫 번째 방법은 RMI 애플리케이션은 RMI의 네이밍 요소인 rmiregistry에 Remote Object를 등록할 수 있다. 두 번째 방법은 보통의 오퍼레이션의 일부로 Remote Object의 Reference를 전달하거나 리턴할 수 있다.RMI의 Client는 이제 얻어온 Remote Object의 Reference를 통해 Remote Object의 Method를 호출 할 수 있다. Client가 Remote Object의 메소드를 호출하게 되면, 내부적으로는 Stub 객체의 메소드를 호출하게 된다. Stub은 메소드의 파라미터들은 마샬링(Marshaling)이라는 과정을 거쳐 서버로 전송하게 된다. 마샬링(Marshaling)은 파라미터/리턴 객체들을 직렬화하고 Remote Object를 호출하기 위해 필요한 정보(객체ID, 호출할 메소드)를 덧붙여 TCP/IP 네트워크로 전송가능한 형태로 변환하는 과정을 말한다.서버로 전송된 파라미터 데이터는 Skeleton에 의해 언마샬링(UnMarshaling)이라는 과정을 거쳐 실제 Remote Object의 메소드를 호출한다. 언마샬링(UnMarshaling)은 마샬링된 정보를 해석하고, 직렬화된 객체들을 복원하는 과정이다.서버의 Remote Object의 메소드가 수행 된 후 리턴 값은 다시 Skeleton에 의해 마샬링(Marshaling)되어 클라이언트에 전송된다. 클라이언트는 전송된 리턴 값을 언마샬링(UnMarshaling)하여 Remote Object의 메소드를 호출한 곳으로 반환한다.

공학/기술| 2006.09.17| 9페이지| 1,000원| 조회(269)

코바, corba, service, RMI, ORB

미리보기

닫기
핸드폰 Usecase(유즈케이스) 분석 평가A+최고예요

전체 Use caseUse case Diagram전원 기능 Use caseUse case diagramUse case ScenarioUse Case Name전원 켜기Actors사용자Pre Condition시스템은 전원이 꺼진 상태이어야 한다.Post ConditionRelated Use Case모든 Use caseBasic CourseActorSystem1. 사용자는 전원 켜기를 실행한다.2. 시스템은 전원을 가동한다.3. 시스템은 초기화 과정을 실행한 뒤, 사용자가 미리 지정한 초기 화면을 표시한다.4. 시스템은 현재 남은 배터리 용량을 검사한다. 만약 남은 배터리 용량이 부족하면 [A-1]로 이동한다.Alternative Course[A-1] 시스템은 남은 배터리 용량이 부족하다는 메시지를 표시한 후, 시스템 전원을 차단한다Use Case Name전원 끄기Actors사용자Pre Condition시스템은 전원이 켜져 있는 상태이어야 한다.Post Condition시스템은 전원이 꺼진 상태가 된다.Related Use Case전원 켜기Basic CourseActorSystem1. 사용자는 전원 끄기를 실행한다.2. 시스템은 현재 모든 상황을 저장한다.3. 시스템은 전원을 차단한다.Alternative CourseUse Case Name배터리 부족 경고ActorsPre Condition시스템은 전원이 켜진 상태이어야 한다.Post ConditionRelated Use Case전원 켜기Basic CourseActorSystem1. 시스템은 현재 남은 배터리 용량이 부족하다는 메시지를 표시한다.Alternative Course통화 기능 Use caseUse case diagramUse case ScenarioUse Case Name번호 입력으로 전화 걸기Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.Post ConditionRelated Use Case전원다.Use Case NameCMF로 전화 걸기Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.Post ConditionRelated Use Case전원 켜기, 잠금 설정, 잠금 해제Basic CourseActorSystem1. 사용자는 통화를 원하는 전화번호를 입력한 후, CMF 통화를 선택한다.2. 시스템은 전화 걸기를 시도한다. 만약 전화 걸기에 실패하면, [A-1]로 이동한다.3. 시스템은 통화 대기음을 출력한다.Alternative Course[A-1] 시스템은 전화 걸기에 실패했다는 메시지를 표시한 후, Use case를 종료한다.Use Case Name자동응답으로 전화 받기Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.시스템은 자동응답이 설정된 상태이어야 한다.Post ConditionRelated Use Case전원 켜기, 잠금 설정, 잠금 해제, 자동응답 설정Basic CourseActorSystem1. 시스템은 제한된 횟수만큼 수신음을 출력한다.2. 시스템은 사용자가 입력해 놓은 음성 메시지를 이동통신회사에 보낸다.Alternative CourseUse Case Name직접 전화 받기Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.Post ConditionRelated Use Case전원 켜기, 잠금 설정, 잠금 해제Basic CourseActorSystem2. 사용자는 통화를 원할 경우 전화 받기를 실행한다.1. 시스템은 수신음을 출력한다.Alternative CourseUse Case Name수신 거절 하기Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어 새로운 그룹을 저장한다.Related Use Case그룹 조회Basic CourseActorSystem1. 사용자는 그룹 추가를 선택한다.3. 사용자는 그룹 정보를 입력한다.2. 시스템은 새로운 그룹의 정보를 입력할 수 있는 화면을 표시한다.4. 시스템은 그룹 이름이 누락되었는지 검사한다. 만약 누락되었다면, 누락되었다는 메시지를 화면에 표시한 후, 3번으로 이동한다.5. 시스템은 그룹 정보가 입력되었다는 메시지를 화면에 표시한다.Alternative CourseUse Case Name그룹 정보 수정Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.사용자 그룹 조회를 실행한 상태이어야 한다.Post Condition그룹 정보가 수정된다.Related Use Case그룹 조회Basic CourseActorSystem1. 사용자는 수정을 원하는 그룹을 선택한 후, 그룹 정보 수정을 선택한다.3. 사용자는 정보를 수정한 후, 확인을 선택한다.2. 시스템은 그룹 정보를 입력할 수 있는 화면을 표시한다. 그룹 정보에는 기존에 입력된 정보가 표시된다.4. 시스템은 사용자 입력한 정보를 저장한다.Alternative CourseUse Case Name그룹 삭제Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.사용자는 그룹 조회를 실행한 상태이어야 한다.Post Condition그룹 정보가 삭제된다.Related Use Case그룹 조회Basic CourseActorSystem1. 사용자는 목록에서 삭제를 원하는 그룹을 선택한 후, 그룹 삭제를 선택한다.3. 사용자는 확인을 선택한다. 만약 취소를 선택하면 Use case를 종료한다.2. 시스템은 삭제 여부를 묻는 메시지를 화면에 표시한다.4. 시스템은 선택된 그룹 정보를 삭제한 후, 그룹 정보가 삭제되었다는 메seActorSystem1. 사용자는 알람 설정을 선택한다.2. 시스템은 기존에 등록된 알람 목록을 화면에 표시한다.Alternative CourseUse Case Name알람 삭제Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.사용자는 알람 설정을 실행한 상태이어야 한다.Post Condition시스템은 알람을 설정한다.Related Use Case알람 설정Basic CourseActorSystem1. 사용자는 알람 목록에서 삭제를 원하는 알람을 선택한 뒤, 삭제를 선택한다.2. 시스템은 알람을 삭제한다.Alternative CourseUse Case Name알람 추가Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.사용자는 알람 설정을 실행한 상태이어야 한다.Post ConditionRelated Use Case알람 설정Basic CourseActorSystem1. 사용자는 알람 추가를 선택한다.3. 사용자는 알람 정보를 입력한다.2. 시스템은 알람 정보를 입력할 수 있는 화면을 표시한다.4. 시스템은 알람 시간이 누락되었는지 검사한다. 만약 누락되었으면 2번으로 이동한다.5. 시스템은 새로 저장된 알람 정보를 적용한 알람 목록을 보여준다.Alternative Course카메라 기능 Use caseUse case DiagramUse case ScenarioUse Case Name사진 촬영Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.Post ConditionRelated Use Case사진 / 동영상 보기Basic CourseActorSystem1. 사용자는 사진 촬영을 선택한다.4. 사용자는 원하는 화면에서 촬영을 선택한다.2. 시스용자는 인터넷 접속을 선택한다.2. 시스템은 인터넷 접속을 시도 한다. 만약인터넷 접속에 실패하면, [A-1]로 이동한다.Alternative Course[A-1] 시스템은 인터넷 접속에 실패 했다는 메시지를 표시한 후 Use case를 종료한다.Use Case Name이메일 확인Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.Post ConditionRelated Use CaseBasic CourseActorSystem1. 사용자는 이메일 확인을 선택한다.4. 사용자는 원하는 항목을 선택한다.2. 시스템은 인터넷에 접속하여 이메일을 받아온다. 만약 인터넷에 접속할 수 없다면 [A-1]을 실행한다.3. 시스템은 이메일 보관함 관리화면을 표시한다.5. 시스템은 사용자가 선택한 항목의 내용을표시한다.Alternative Course[A-1] 시스템은 인터넷 접속에 실패 했다는 메시지를 표시한 후 Use case를 종료한다.Use Case Name이메일 보내기Actors사용자Pre Condition시스템은 전원이 켜진 상태이어야 한다.시스템은 초기 화면을 표시한 상태이어야 한다.시스템은 잠금 상태가 아니어야 한다.Post ConditionRelated Use Case전원 켜기, 잠금 설정, 잠금 해제Basic CourseActorSystem1. 사용자는 이메일 보내기를 선택한다.3. 사용자는 보낼 내용을 입력한다.4. 사용자는 보내기를 선택한다.2. 시스템은 이메일 보내기 화면을 표시한다.5. 시스템은 이메일을 보낸다. 만약 이메일 보내기 실패하면, [A-1]로 이동한다.Alternative Course[A-1] 시스템은 이메일 보내기에 실패 했다는 메시지를 표시한 후 Use case를 종료한다.메시지 기능 Use caseUse case DiagramUse case ScenarioUse Case Name메시지 함 확인Actors사용자Pre Condition시se

공학/기술| 2006.12.04| 52페이지| 3,000원| 조회(1,041)

핸드폰, 유즈케이스, Usecase, MobilePhone, UML 분석

미리보기

닫기
[공학]네트워크 서비스 기법 비교

Network Systems Design- Homework -객체지향 연구실박사 3학기 김주원1. GPS(Generalized Processor Sharing)GPS는 모든 큐를 라운드 로빈 형태로 가중치에 따라 극히 작은 량으로 서비스하는 fluid model 기반의 이상적인 모델이다. Fluid model은 패킷은 무한히 나눌 수 있으며 모든 크기가 같은 패킷 출발 링크를 똑같이 공유하는 2개의 흐름을 가지고 있고 두 패킷이 동시에 서비스 받을 수 있다고 가정한다. 실세계에서는 서비스 단위를 패킷단위로 하기에 극한의 소량으로 서비스하는 방식인 GPS는 실현 불가능한 기법이다. 서비스되는 양은 다음 식과 같다.2, WFQ(Weighted Fair Queuing)GPS를 간략화한 방법 중 하나로 패킷 단위로 서비스한다. WFQ는 GPS에 의해 패킷을 비트단위로 서비스 했을 경우, 각 패킷이 전송 완료되는 종료시간을 계산하고, 패킷의 순서는 가상 종료 시간에 따라서 이루어 지는데, 선택된 패킷을 전송하는 도중 더 빨리 종료될 수 있는 패킷이 도착하지 않는다는 가정하에 종료 시간이 가장 빠른 패킷을 우선적으로 서비스한다. 시간 t에 플로우 i의 l번째 패킷이 도착했고, 이 패킷의 길이를 P(i,l,t)라 가정하면 이 때 패킷의 종료시간F(i,l,t)는F(i, l, t) = max( F(i, l-1, t), v(t) ) + P(i, l, t)/φ(i) 이다.φ(i)는 플로우 i의 전송 가중치를 의미하고, v(t)는 가상시간을 의미한다.WFQ는 가장 종료시간이 빠른 패킷을 선택하기 위해 패킷을 종료시간 순서대로 정렬해 두어야하므로, 힙(Heap) 자료구조를 사용한다.이는 연결 수 N에 대하여 복잡도 O(logN)를 가지고 있어 연결수가 많고 빠른 고속 통신망 구현에는 약점을 가진다.3. WRR(Weight Round Robin)Starvation 상태를 피하기 위해 전체 큐들의 집합을 순서대로 나열하고, 한 큐를 서비스한 후 다음 큐를 서비스하는 방식으로 전체 큐들을 공평하게 서비스 한다. 서비스시 패킷을 하나(또는 같은 개수)씩 서비스 하는 기본적인 Round Robin 방식에 서비스의 가중치가 다를 경우에도 적용할 수 있도록 개선한 방식이다.예를 들어, 3개의 큐가 있다 가정하고 이들 가중치가 0.25, 0.25, 0.5라 가정하면, 이의 normalize값은 1:1:2이다. 따라서, 매 라운드마다 큐1, 큐2는 패킷을 하나씩 서비스받고 Q3은 2개를 서비스 받는다.만일, 패킷의 평균 길이가 서로 다르다면, WRR은 평균 패킷 길이를 고려하여 표준화된 가중치를 구한다. 위 예에서 평균 패킷 길이가 10, 20, 10이라 가정하면, 0.25/10, 0.25/20, 0.5/10가 평균 패킷 길이를 고려한 가중치이며, normalize값은 2:1:4이다. 따라서 각 라운드마다 2개, 1개, 4개의 패킷을 서비스하게 된다.WRR은 공평성을 가지고 있으나 성능은 보장하지 못한다. 각 패킷의 평균 길이를 미리 알고 있을 때에만 적용할 수 있다.4. SDWRR(Smoothed Deficit Weighted Round Robin)SDWRR은 0-3까지의 번호가 매겨진 4개의 FIFO 리스트들의 집합을 사용한다. 하드웨어 서비스는 Round Robin방식으로 FIFO0을 서비스 후, FIFO1의 순서로 계속 순환하며 서비스를 한다. 각 FIFO에 대해 backlog된 패킷이 더 이상 없을 때까지 서비스한다.어떤 큐를 서비스 할 때, SDWRR은 큐로부터 전송된 비트의 양을 명세하는 expense라 불리는 카운터를 유지한다. 각 큐의 expense는 해당 큐에서 패킷을 전송할 때, 패킷의 크기를 더한다.균등하게 서비스를 제공하기 위해 SDWRR은 각 큐에는 3개의 limit들이 할당되어진다.limit1 ≤ limit2≤ limit3각 큐에 대한 expense는 limit와 비교하여 만약 expense가 3개의 limit들 전체보다 작을 경우, 큐는 현재 FIFO 리스트에 남고 가능한 한 서비스될 리스트상의 다른 아이템들을 다시 서비스할 것이다. 만일 expense가 limit를 초과할 경우, 큐는 다음의 FIFO1 리스트로 이동되어 진다. 또한, 만일 expense가 limit2보다 클 경우, 큐는 FIFO2 리스트로 이동하며, expense가 limit3보다 클 경우 FIFO3 리스트로 이동한다. 큐가 이동됨에 따라 expense는 대응되는 limit까지 감소된다.5. RED(Random Early Detection)가장 간단한 큐 및 패킷 관리 알고리즘은 버퍼에 가능한 많은 패킷을 저장하고 있다가 더 이상 여유공간이 없을 때, 나중에 도착하는 패킷을 무조건 버리는 tail drop 방법이다. 이 방식은 버퍼가 가득차는 경우가 빈번히 발생되면, 그에 따른 클로벌 동기화가 발생하는 원인이 된다.RED는 이러한 문제점을 해결하기 위해, 큐의 평균 크기를 감시하면서 통계적 확률에 의해 패킷을 탈락시킨다. 버퍼가 거의 비어있을 경우에는, 모든 패킷을 받아들이지만, 큐가 점점 차게 되면 들어오는 패킷이 탈락할 확률도 함께 증가한다. 확률이 1에 도달하면, 모든 패킷을 탈락시킨다. RED는 최소 임계치(Min Threshold)와 최대 임계치(Max Threshold) 값이 사용되며, 큐의 평큔 크기가 임계치 값을 초과할 때, 각 패킷은 확률에 따라 탈락된다.RED는 많은 패킷을 전송한 호스트이 패킷 탈락 가능성이 더 커지기 때문에 tail drop보다 좀더 공평하다.

공학/기술| 2006.09.18| 3페이지| 1,000원| 조회(327)

gps, red, WFQ, WRR, SDWRR

미리보기

닫기
[컴퓨터]리눅스의 장단점

목 차 TOC o "1-3" h z u HYPERLINK l "_Toc87785994" 1Linux의 역사 PAGEREF _Toc87785994 h 3 HYPERLINK l "_Toc87785995" 2Linux의 장점 PAGEREF _Toc87785995 h 4 HYPERLINK l "_Toc87785996" 2.1경제성 PAGEREF _Toc87785996 h 4 HYPERLINK l "_Toc87785997" 2.2이식성 PAGEREF _Toc87785997 h 4 HYPERLINK l "_Toc87785998" 2.3보안성 PAGEREF _Toc87785998 h 4 HYPERLINK l "_Toc87785999" 2.4신뢰성 PAGEREF _Toc87785999 h 4 HYPERLINK l "_Toc87786000" 2.5안정성 PAGEREF _Toc87786000 h 4 HYPERLINK l "_Toc87786001" 2.6기능성 PAGEREF _Toc87786001 h 4 HYPERLINK l "_Toc87786002" 2.7성장성 PAGEREF _Toc87786002 h 4 HYPERLINK l "_Toc87786003" 3Linux의 단점 PAGEREF _Toc87786003 h 5 HYPERLINK l "_Toc87786004" 3.1보안성의 문제 PAGEREF _Toc87786004 h 5 HYPERLINK l "_Toc87786005" 3.2보상 및 서비스 PAGEREF _Toc87786005 h 5 HYPERLINK l "_Toc87786006" 3.3변화성 PAGEREF _Toc87786006 h 5 HYPERLINK l "_Toc87786007" 3.4인식부족 PAGEREF _Toc87786007 h 5 HYPERLINK l "_Toc87786008" 3.5대형 시스템에 대한 신뢰성 PAGEREF _Toc87786008 h 5Linux의 역사리눅스는 1991년 Linus B. Torvalds에 의해 커널 버전 0.01이 만들어지고 0.02버전이 인터넷에 공개되었다. 그후 Richard M. Stallman이 만든 FSF(Free Software Foundation)의 GNU(Gun is Not Unix)프로젝트가 합세하면서 1994년 리눅스 커널 버전 1.0이 발표된 후, 현재 커널 버전 2.6이 발표되어 있다.Linux의 장점경제성리눅스는 사용자 단위 라이센스나 사용료가 없어 무료 운영체제인 데다가 유지보수 비용 또한 낮고, 다른 운영체제와 비교하여 높은 성능을 가진다. 또한 저사양 시스템에서도 운용에 무리가 없다.이식성대부분의 개방형 시스템 사양들이 어느 정도의 UNIX 형식을 취하는 Portable Operating System Interface(POSIX)를 따르도록 요구합니다. 현재 Linux가 바로 이 표준을 충족하고 있습니다. 사실 Linux는 소스 코드 이식성을 위해 고안된 것이므로, 한 가지의 UNIX 버전으로 실행되는 회사 프로그램을 갖고 있다면 비교적 빠르게 해당 시스템을 Linux실행 시스템으로 이식할 수 있어야 합니다.보안성리눅스는 사용자가 커널 수준에서 직접 코드를 작성하여 운영체제 내부에서 칩입자를 차단할 수 있는 커널 수준의 보안을 제공한다. 또한 보안 상의 약점이 발견되는 즉시 그 내용이 공개되고 또한 수정되어진다. (윈도우 계열의 경우, 패치의 제공 시간에 비에 빠른 수정)신뢰성리눅스는 수백만의 개발자들이 참여하여 패치와 코드작업을 수행하는 개발 방법으로 충분한 테스트와 디버깅 과정을 거치게 되며, 버그의 발견시 단 시간에 해결책이 나올 수 있는 운영체제이다.안정성리눅스는 보호메모리, 선제 MutilTasking등의 기능을 통해 시스템에서 실행중인 어플리케이션에서 오류나 병목현상이 발생하더라도 운영체제는 전혀 영향을 받지 않는다.기능성리눅스는 유닉스와 완벽하게 호환 가능하고 대부분의 기능 또한 지원하며 특히 네트워크 관련 기능은 강력하게 제공하고 있다. 인터넷에서 개발되고 성장한 운영체제의 특징으로 인터넷과 네트워크의 기능을 강력하게 제공한다.성장성현재 가장 빠르게 성장하고 있는 운영체제의 하나로서 오픈소스의 장점에 의해 앞으로도 더욱 발전할 가능성이 높은 운영체제이다.Linux의 단점보안성의 문제mi2g가 2003년 11월부터 2004년 10월까지 235,907개의 인터넷에 연결된 컴퓨터에 대한 침입 사례를 일반 가정과 작은 사무실의 개인용 컴퓨터부터 대형 기업 컴퓨터로의 침투도 포함한 조사결과에 따르면, 234,907건의 침투 사례에서 65.6%에 해당되는 154,846건은 리눅스 기반의 시스템에 대해서 행해진 것이었으며 윈도우 기반의 컴퓨터는 25.19%를 기록했다. 한편 맥 OS X, BSD 기반의 컴퓨터의 경우 전체 4.82%를 기록했다.각 OS의 보급율을 감안하면 이 결과가 맥 OS X, BSD 기반의 컴퓨터가 보안성이 가장 뛰어나다고 말할 수는 없다. 하지만, 리눅스 기반의 시스템이 외부에서 침입을 하려는 시도가 가장 많을 수 있다는 결과는 보여줄 수 있다.보상 및 서비스공개운영체제이기 때문에 문제점의 발생시 보상이나 서비스를 받을 수 없다. (배포판 판매사를 통한 운영체제 사용시에는 가능)변화성리눅스는 공개운영체제이므로 현재도 계속 개발되고 발전되고 있다. 계속되는 커널 업그레이드와 다양한 커스텀마이징을 통해 매우 다양한 리눅스가 출연하고 있어서 리눅스의 선택과 잦은 업그레이드 등의 관리상의 문제점이 발생될 수 있다.인식부족계속적으로 시장성의 성장에 의해 인식이 바뀌고는 있으나 아직도 무료운영체제라는 인식이 낮은 성능과 신뢰성, 안정성을 의심하는 경우를 발생시킨다.대형 시스템에 대한 신뢰성리눅스는 소형시스템에서 각광을 받으며 발전을 하였고(시작이 미니유닉스에서 시작), 점차 중대형시스템의 적용으로 확산되고 있기는 하지만 아직까지는 UNIX의 안정성과 신뢰성을 넘지는 못하여 대형시스템에 대한 레퍼런스가 부족하다. 특히 은행권 등의 높은 신뢰성과 보안성을 요구하는 시스템에서는 더욱 부족하다. (공공기관, 대기업 등으로 도입 추진이 확산되고 있는 추세이기는 하다.)어플리케이션의 부족(개인용PC부분)아직까지는 개인용컴퓨터에서 사용할 안정적이고 신뢰할 사무/개인용 어플리케이션이 많이 부족한 실정이다. TITLE * MERGEFORMAT Document Format Template SUBJECT * MERGEFORMAT OOS-001-00001 PAGE 2 / NUMPAGES 4

공학/기술| 2006.09.17| 4페이지| 1,000원| 조회(894)

리눅스, Linux, 리눅스의 장단점, 리눅스의 역사

미리보기

닫기