천객만래 [千客萬來] (It has an interminable succession of visitors)

About Angular 9 Release

IT-개발 2020. 1. 22. 14:10

Angular 9 이 2019년 출시 예정이었으나 연기되어서 

곧 일정이 발표될 예정입니다.

 

2019년 1월 8일 Angular 9에 대한 약간의 스포일러가 있습니다.

 

대략 9개 정도의 큰 변화가 있을 예정입니다.

 

그 중 하나인 Ivy rendering은 이전에는 opt-in 에서 default redering engine이 될 것입니다.

 

Angular 9 이 곧 출시 됩니다.

 

Default Ivy

Angular Core Type-Safe Changes

ModuleWithProviders Support

Changes with Angular Forms

Dependency Injection Changes in Core

Enhancement of Language Service

Service Worker Updates

i18n Improvements

API Extractor Updates

Angular Component Updates

Updating to Angular Version 9

Updating CLI Apps

 

'IT-개발' 카테고리의 다른 글

About Angular 9 Release  (0) 2020.01.22
IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
프로젝트 3요소  (0) 2020.01.15
ICONIX Process  (0) 2019.12.30
프로그래머로서 나의 발전 단계  (0) 2019.12.18
자바스크립트에서 ==., ===  (0) 2019.06.16
Posted by 사용자 SB패밀리

댓글을 달아 주세요

IntelliJ Golang 연동할 때 에러

 

 

# trouble occured

GOROOT=/Users/baegyeonghwan/sdk/go1.14beta1 #gosetup
GOPATH=/Users/baegyeonghwan/go #gosetup
/Users/baegyeonghwan/sdk/go1.14beta1/bin/go list -m -json all #gosetup
go: github.com/appleboy/gin-jwt/v2@v2.6.2 requires
github.com/appleboy/gofight/v2@v2.1.1 requires
github.com/astaxie/beego@v1.11.1 requires
github.com/belogik/goes@v0.0.0-20151229125003-e54d722c3aff: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /Users/baegyeonghwan/go/pkg/mod/cache/vcs/0c31a160b38443d5e33ca2a5e60e51734d83293b66dc3d9b0c12699f8d2b5cec: exit status 128:
fatal: could not read Username for 'https://github.com': terminal prompts disabled


# solution:

1. go 메뉴에서 go SDK를 go root와 go path, 그리고 go modules(vgo) integration에서 해제.
2. 터미널에서 아래 명령어 실행

$ go get github.com/appleboy/gin-jwt/v2 

3. go menu에서 go SDK를 go root와 go path, 그리고 go modules(vgo) integration에서 설정. 

'IT-개발' 카테고리의 다른 글

About Angular 9 Release  (0) 2020.01.22
IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
프로젝트 3요소  (0) 2020.01.15
ICONIX Process  (0) 2019.12.30
프로그래머로서 나의 발전 단계  (0) 2019.12.18
자바스크립트에서 ==., ===  (0) 2019.06.16
Posted by 사용자 SB패밀리

댓글을 달아 주세요

프로젝트 3요소

IT-개발 2020. 1. 15. 16:08

 

프로젝트 관리 3요소

 

 

프로젝트 방법론 3요소

'IT-개발' 카테고리의 다른 글

About Angular 9 Release  (0) 2020.01.22
IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
프로젝트 3요소  (0) 2020.01.15
ICONIX Process  (0) 2019.12.30
프로그래머로서 나의 발전 단계  (0) 2019.12.18
자바스크립트에서 ==., ===  (0) 2019.06.16
Posted by 사용자 SB패밀리

댓글을 달아 주세요

ICONIX Process

IT-개발 2019. 12. 30. 09:35

ICONIX Process

 

ICONIX 프로세스는 사용하기 쉬운 개방형 개체 모델링 프로세스입니다. 최소한의 사용 사례 중심이며 민첩합니다. 이 프로세스는 사용 사례와 코드 사이의 영역에 중점을 둡니다. 시작하는 라이프 사이클의 시점에서 어떤 일이 발생해야하는지에 중점을두고 있습니다. 일부 사용 사례가 시작되었으므로 이제는 우수한 분석 및 설계가 필요합니다.

 

GUI 스토리보드가 먼저 시작되는 것을 볼 수 있다.

 

 

 

간단히 말해서 ICONIX 프로세스

이 섹션에서는 프로세스 자체에 대해 설명합니다. 간단히 말해서, ICONIX 프로세스는 가능한 적은 단계로 유스 케이스에서 코드로 안정적으로 전환하는 방법을 설명합니다.

그림 3-3 은 ICONIX 프로세스의 여러 활동이 어떻게 결합되는지 보여줍니다.


그림 3-3 : ICONIX 프로세스

ICONIX 프로세스는 다음 단계로 나눌 수 있습니다 ( 굵게 표시된 항목 은 각 단계에서 수행하는 구체적 모델링 활동입니다).

  • 1 단계 : 실제 도메인 개체 식별 ( 도메인 모델링 )

  • 2 단계 : 행동 요구 사항 정의 ( 사용 사례 )

  • 3 단계 : 견고성 분석  수행 하여 사용 사례를 명확하게하고 도메인 모델의 차이를 식별합니다.

  • 4 단계 : 객체에 동작을 할당합니다 ( 시퀀스 다이어그램 ).

  • 5 단계 : 정적 모델을 완료하십시오 ( 클래스 다이어그램 ).

  • 6 단계 : 코드 작성 / 생성 ( 소스 코드 )

  • 7 단계 : 시스템 및 사용자 수락 테스트를 수행합니다.

이 프로세스를 분석 및 설계 모델링 활동에 대한 서신으로 보내면 프로젝트가 고객의 요구 사항을 충족하고 합리적인 시간 내에이를 수행 할 수있는 좋은 기회가됩니다.

다음 섹션에서 이러한 각 단계를 자세히 살펴보면 프로젝트 계획에서보기 좋게 나타나는 4 가지 주요 이정표에 주목할 것입니다.이 계획은 유용한 계획 체크 포인트이기도합니다. "이 XYZ 작업이 완료되었으므로 이제 다음 단계로 넘어갑니다"라고 말하고 설명하십시오.

  • 이정표 1 : 요구 사항 검토

  • 이정표 2 : 예비 설계 검토

  • 이정표 3 : 상세 / 중요한 설계 검토

  • 이정표 4 : 배달

1 단계 : 실제 도메인 객체 식별

이 단계를 올바르게 수행하는 것은 전체 프로젝트에서 가장 중요한 부분 일 것입니다. 프로젝트의 다른 모든 것 (요구 사항, 디자인, 코드 등)이 절대적으로 구축되는 견고한 기반을 구축하기 때문입니다.

이 단계는 다음 단계로 세분 될 수 있습니다.

  1. 실제 도메인 개체와 이러한 개체 간의 일반화 및 집계 관계를 식별하십시오. 높은 수준의 클래스 다이어그램을 그리기 시작하십시오.

  2. 가능하다면 제안 된 시스템을 신속하게 프로토 타이핑하거나 리엔지니어링 할 레거시 시스템에 대한 실질적인 정보를 수집하십시오.

이 단계를 마치면 프로젝트의 모든 사용자 (고객, 프로그래머, 분석가, 테스터 및 최종 사용자)가 공통 어휘로 공유하고 사용할 수있는 합리적으로 올바른 도메인 모델이 있어야합니다. 도메인 모델은 프로젝트가 진행됨에 따라 계속 발전하고 성장할 것입니다 (그리고 비즈니스 영역을 캡처하는 더 간단한 것으로 변경 될 수 있기를 바랍니다).

도메인 모델은 문제 영역 엔터티 클래스를 기반으로하는 정적 모델 (클래스 다이어그램)을 솔루션 공간이 아닌 예비 추측입니다. 클래스에는 속성이나 작업이 표시되지 않습니다.

도메인 모델에는 시스템이 해결하도록 설계된 문제와 관련된 실제 사물과 개념이 포함되어 있습니다. 우리는 도메인 모델을 만들 때 비즈니스를 형성하는 개체와 행동의 표현을 만들고 프로젝트가 해결하려는 문제에 중점을 둡니다. 프로젝트에 대해 생성 한 초기 도메인 모델은 완벽하지 않습니다. 문제 영역에 대한 이해가 발전함에 따라 프로젝트 전체에서 발전 할 것입니다.

실제로 도메인 모델로 갈 개체를 어떻게 식별합니까? 여러 가지 기술이 있으며 그중 가장 중요한 것은 단순히 자신의 경험과 판단을 사용하는 것입니다. 그러나 실제로 고착 된 경우 문법 검사 기술 을 사용하는 것이 좋습니다 . [ 6. ] 사용 가능한 관련 자료 (요구 사항, 비즈니스 용어집 등)를 빠르게 통과하면서 명사와 동사를 강조 표시합니다. . 관련 자료에는 고객 및 시스템의 최종 사용자와의 자체 인터뷰도 포함되어야합니다. 이러한 토론은 종종 모호성을 해결하고 추가 도메인 객체를 식별하는 데 도움이됩니다.

작업이 진행됨에 따라 목록을 수정 한 후

  • 명사와 명사구는 클래스와 속성이됩니다.

  • 동사와 동사구는 연산과 연관이됩니다.

  • 소유 어구는 명사가 클래스가 아닌 속성이어야 함을 나타냅니다.

물론 이러한 항목은 일반적인 규칙 만 나타냅니다 (단, 유용한 규칙이지만). 예를 들어, 일부 동사는 결국 조작이 아닌 객체가됩니다 (특히 비즈니스 프로세스를 모델링하거나 관리자 또는 컨트롤러, 클래스를 식별 한 경우).

도메인 모델을 계속 반복하고 세분화해야하지만 이것이 명사와 동사를 무기한으로 계속 연마해야한다는 의미는 아닙니다. 목표는 사용 사례 텍스트 내에서 적절하게 명사 역할을 할 오브젝트 이름 용어집을 작성하는 것 입니다.

초기 도메인 모델을 구축하기위한 시간 예산을 설정하는 것이 좋습니다 (예를 들어, 아침이나 몇 시간까지 걸리는 공동 작업장으로 제한). 도메인 모델은 중요하지만 프로젝트의 나머지 부분이 시작되는 것을 방지하기를 원하지 않습니다! 일반적으로 몇 시간 내에 도메인 클래스의 가장 중요한 80 %를 찾을 수 있습니다. 사용 사례를 진행하면서 나머지 클래스를 발견하므로 완벽하게 얻을 필요는 없습니다.

2 단계 : 행동 요구 사항 정의

지금까지 수집 한 것처럼 ICONIX 프로젝트의 동작 요구 사항은 사용 사례에 의해 정의됩니다. 사용 사례는 높은 수준의 요구 사항 (이전 단계에서 논의 됨)을 확장하고 사용자 상호 작용 측면에서 시스템의 동작 방식을 정의합니다. 이 책의 뒷부분에서 설명 하겠지만,이 단계는 세부적인 상호 작용 디자인 (특히 페르소나 분석, 12 장 참조)으로 보강되는 것이 좋습니다.

이 단계는 다음 단계로 세분 될 수 있습니다.

  1. 사용 사례 다이어그램을 사용하여 사용 사례를 식별하십시오.

  2. 사용 사례를 그룹으로 구성하십시오. 이 조직을 패키지 다이어그램으로 캡처하십시오.

  3. 기능 요구 사항을 사용 사례 및 도메인 오브젝트에 할당하십시오. (이 단계는 프로젝트의 형식에 따라 선택 사항입니다.)

  4. 사용 사례에 대한 설명을 작성하십시오 (즉, 이동 빈도가 적은 경로 및 오류 조건에 대한 주류 및 대체 과정을 나타내는 기본 행동 과정).

유스 케이스 모델링을 완료 한 시점을 어떻게 알 수 있습니까? 다음을 달성하면 개발 프로세스의 다음 단계로 넘어갈 준비가되었습니다.

  • 시스템의 원하는 기능  모두 설명하는 사용 사례를 구축했습니다 .

  • 각 사용 사례에 대해 적절한 대체 조치 과정과 함께 기본 조치 과정에 대한 명확하고 간결한 설명을 작성했습니다.

  • 앞선을 사용하고 구문 (또는 일반적으로 선호하는 구문)을 사용하여 둘 이상의 사용 사례에 공통적 인 시나리오를 제외했습니다.

이정표 1 : 요구 사항 검토

3 단계 : 도메인 모델에서 사용 사례를 명확하게하고 간격을 식별하기 위해 견고성 분석 수행

이것이 프로젝트의 최종 분석 단계입니다. 이 장의 뒷부분에서 볼 수 있듯이 견고성 분석은 ICONIX 프로세스에서 중요한 역할을합니다. 핵심은 견고성 다이어그램입니다 ( 그림 3-4 참조 ).


그림 3-4 : 견고성 다이어그램 예

견고성 분석에는 유스 케이스의 텍스트를 통해 작업하며, 지금까지 발견 한 오브젝트를 사용하여 특정 유스 케이스를 구현하기 위해 일부 소프트웨어를 설계하는 방법을 미리 살펴 봅니다. 이 액티비티의 주요 목적 중 하나는 필요한 객체가 모두없는 경우를 찾아 클래스 다이어그램에 추가하는 것입니다.

견고성 분석 단계는 다음 단계로 세분됩니다.

  1. 견고성 다이어그램을 그립니다. 각 사용 사례

    1. 명시된 시나리오를 수행하는 첫 번째 컷 개체를 식별하십시오. UML Objectory 스테레오 타입을 사용하십시오 ( 그림 3-5 참조 ).


      그림 3-5 : 견고성 분석 고정 관념

    2. 발견 할 때 새 오브젝트 및 속성으로 도메인 모델 클래스 다이어그램을 업데이트하십시오.

    3. 견고성 다이어그램과 일치하도록 유스 케이스 텍스트를 업데이트하십시오.

  1. 프로젝트의 분석 단계 완료를 반영하도록 클래스 다이어그램 업데이트를 완료하십시오.

이정표 2 : 예비 설계 검토

Ivar Jacobson 은 1991 년 OO의 세계  견고성 분석 개념을 도입 했습니다. 견고성 분석에는 각 사용 사례의 설명 텍스트를 분석하고 사용 사례에 참여할 첫 번째 추측 개체 집합을 식별 한 다음이를 분류합니다. 다음 세 가지 객체 유형으로

  • 경계 객체- 액터가 시스템과 통신하는 데 사용합니다.

  • 엔티티 객체 (이라고도 실체 보통), 도메인 모델 객체.

  • 경계 객체와 엔티티 객체 사이의 "접착제"역할을하는 제어 객체 ( 컨트롤러 라고도 함 ). 때때로 이들은 실제 Control 객체이지만 대부분은 단순히 함수에 대한 동사 자리 표시자를 나타냅니다.

이 간단하지만 매우 유용한 기술은 (분석 사이의 중요한 링크 역할을 무엇 )과 디자인합니다 ( 방법 ). 이 책의 뒷부분에서 견고성 분석의 몇 가지 예를 살펴 보겠습니다.

이 세 가지 객체 유형은 MVC (Model-View-Controller) 디자인 패턴으로 잘 변환되며 [ 7. ] 클라이언트-서버 및 GUI 개발에 많이 사용됩니다. 엔터티 개체는 Model에 의해 전달되고 경계 개체는 View 에서 구성되며 Control 개체는 Controller에서 구성 됩니다. 예를 들어, 3 계층 웹 응용 프로그램에서 경계 (또는보기) 개체는 JSP 페이지 일 수 있습니다 (때로는 프레젠테이션 계층 이라고도 함 ). 엔티티 (즉, 데이터)는 데이터베이스, 일반적으로 비즈니스 오브젝트 계층을 통해 제공됩니다. 전체 엔칠 라다를 하나로 묶는 Control 객체는 애플리케이션 서버에 내장 된 비즈니스 로직 계층에 의해 제공됩니다.

리치 클라이언트 GUI 애플리케이션에서 경계 (또는보기) 오브젝트는 테이블 또는 콤보 상자 컴포넌트 (예 : Java Swing, JTable 또는 JComboBox) 일 수 있으며 Model 오브젝트는 다음과 같은 데이터 모델 (예 : DefaultTableModel)입니다. 구성 요소가 표시 할 엔티티를 제공하고 제어 코드는 UI 이벤트 (예 : 테이블을 위아래로 스크롤)를 처리하여 모델에서보기를 표시해야하는 데이터를 판별합니다.

프로젝트의 기능이 향상됨에 따라 (또는 배포 된 시스템에 동시에 액세스하는 사용자 수와 같은 다른 방식으로) 과제를 충족하도록 아키텍처를 확장해야합니다. 이는 종종 기능을 별도의 계층으로 분할 한보다 복잡한 아키텍처로 이어집니다 (예 : 애플리케이션 로직의 다른 영역이 다른 계층으로 분리 될 수 있음). 이것은 BCE (Boundary-Control-Entity) 아키텍처 (또는 MVC 아키텍처)의 확장으로 볼 수 있으므로 ICONIX 프로세스는 여전히보다 복잡한 아키텍처에 쉽게 적용 할 수 있습니다 (즉, 프로세스는 프로젝트).

4 단계 : 객체에 동작 할당

이 단계는 프로젝트의 디자인 단계가 시작되는 곳입니다. 이 단계에서 선택한 주요 다이어그램은 시퀀스 다이어그램 ( 그림 3-6 참조 )이지만 추가 다이어그램 및 활동 (예 : 상태 다이어그램, 활동 다이어그램 또는 엄격한 테스트 중심 방법론에 따른 단위 테스트)을 사용할 수도 있습니다. 제 12 장)


그림 3-6 : 예제 시퀀스 다이어그램

이 단계는 각 사용 사례에 대해 다음 단계로 세분화됩니다.

  1. 호출 할 오브젝트와 연관된 메소드간에 전달해야하는 메시지를 식별하십시오.

  2. 사용 사례 텍스트가 왼쪽으로 내려 가고 시퀀스 정보가 오른쪽에있는 시퀀스 다이어그램을 그립니다.

  3. 클래스 다이어그램을 찾은대로 속성 및 조작으로 계속 업데이트하십시오.

시퀀스 다이어그램에서 클래스에 작업을 할당하지 않으면 인생의 주요 임무는 무시하는 것입니다.

각 사용 사례마다 하나의 시퀀스 다이어그램을 만듭니다. 기억해야 할 중요한 점은 단일 유스 케이스에서 상호 작용을 맵핑하기 위해 많은 다이어그램으로 혼란에 빠지는 것을 원하지 않기 때문입니다. 그렇게하면 분석 마비가 심해지므로 사용 사례에 대해 여러 가지 대안 시나리오가 있더라도 모든 것을 하나의 시퀀스 다이어그램에 배치하십시오.

이것이 유스 케이스 텍스트에 대한 두 단락 규칙의 이유입니다. 모든 것을 하나의 시퀀스 다이어그램에 맞출 수 있습니다. 이 접근법의 결과는 다이어그램이 너무 조각화되는 것을 방지한다는 것입니다. 즉, 단일 다이어그램을 읽으면 전체 사용 사례를 해결했는지 확인할 수 있습니다. 조각이 너무 많으면 모든 사용 사례를 확보하기가 어렵습니다.

5 단계 : 정적 모델 완료

이 단계의 제목에서 알 수 있듯이 여기서 핵심 설계 아티팩트는 하나 이상의 클래스 다이어그램으로 구성된 정적 모델입니다 ( 그림 3-7 참조 ).


그림 3-7 : Part 2에 제시된 맵렛 프로젝트에 대한 예제 클래스 다이어그램

이 단계는 다음 단계로 세분됩니다.

  1. 자세한 설계 정보 (예 : 가시성 값 및 패턴)를 추가하십시오.

  2. 디자인이 식별 한 모든 요구 사항을 충족하는지 팀과 확인하십시오.

이정표 3 : 상세 / 중요한 설계 검토

정적 모델은 도메인 모델의 더 거칠고 상세한 버전이며 더 자세한 구현 정보가 포함되어 있습니다. 정적 모델에는 매우 상세한 추상화 수준에 있고 시퀀스 다이어그램과 일치하는 자세한 클래스 다이어그램 (아마도 소스 코드에서 리버스 엔지니어링 될 수도 있지만 반드시 필요한 것은 아님)이 있습니다.

모델링 질문 : 정식 모델을 가질 때까지 메인 모델 다이어그램을 재사용하고 간단하게 추가해야합니까?

프로젝트가 하나의 릴리스 (또는 최대 두 개의 릴리스) 만 거치는 것을 알고 있다면이 접근법이 잘 작동합니다. 그러나 짧은 릴리스가 많고 각 릴리스가 시작될 때 도메인 모델링 활동이있는 민첩한 프로젝트에서는 도메인 모델과 클래스 다이어그램에 대해 별도의 다이어그램을 유지해야합니다. 클래스 다이어그램은 여전히 ​​원래 도메인 모델에서 성장하고 발전하지만 (이 접근 방식은 ICONIX 프로세스의 기본), 다이어그램은 별도로 유지됩니다.

도메인 모델은 비즈니스 도메인에 대한 현재의 이해 (예 : 분석 수준 아티팩트)를 반영하는 반면, fleshed out 클래스 다이어그램 (여러 개가있을 수 있음)은 집합 적으로 세부적인 디자인 아티팩트입니다. 비즈니스 도메인에 대한 이해가 발전함에 따라 이전 단계의 설계 세부 사항 (적어도 아직은 아님)을 고려하여 속도 저하없이 도메인 모델을 신속하게 업데이트하고 리팩토링 할 수 있어야합니다. 디자인 단계).

물론 이것은 업데이트 할 추가 다이어그램이 있다는 것을 의미하지만, 절충안입니다. 이점은 도메인 모델을 최신 상태로 유지하는 것이 훨씬 쉽고 읽기가 더 쉽다는 것입니다 (디자인 세부 사항 및 디자인 결정 기록에 의해 혼란 스럽기 때문).

도메인 모델과 클래스 다이어그램이 동일한 다이어그램 인 경우 새로운 비즈니스 이해에 비추어 도메인 모델을 업데이트하기가 더 어렵습니다. 모든 중간 단계를 거치지 않고 세부 설계를 효과적으로 수정하기 때문입니다 ( 견고성 분석, 시퀀스 다이어그램 등).

6 단계 : 코드 작성 / 생성

물론이 단계는 프로그래머가 디자인을 취하고 코드를 작성하기 시작하는 단계입니다. 프로그래머는 모든 설계 단계 (이상적으로는 디자이너도 프로그래머이기도 함)에 참여해야 디자인이 시스템이 구현 될 기술의 현실에 어느 정도 근거가 있어야합니다.

이 단계는 다음 단계로 세분됩니다.

  1. 코드를 작성 / 생성하십시오.

  2. 단위 및 통합 테스트를 수행하십시오.

ICONIX 프로세스를 테스트 중심 접근 방식 (12 장 참조)과 결합하면 단위 테스트가 코드 전에 작성됩니다. 여기서 중요한 점은 프로그래머가 통합 테스트를 포함하여 자체 테스트를 수행하고 있다는 것입니다.

7 단계 : 시스템 및 사용자 수락 테스트 수행

이 단계에서는 프로그래밍 팀과 다른 그룹 (이상적으로는 QA 팀)이 유스 케이스를 후자의 블랙 박스 테스트 케이스로 사용하여 시스템 및 사용자 승인 테스트를 수행합니다.

이정표 4 : 배달

[ 6. ] Kurt Derr, OMT 적용 : 객체 모델링 기법 사용에 대한 실용적인 단계별 가이드 (New York : Cambridge University Press, 1995).

[ 7. ] http://java.sun.com/blueprints/patterns/MVC.html을 참조하십시오 .

출처: http://users.nagafix.co.uk/~mark/025.html

ICONIX Process in a Nutshell

In this section, we describe the process itself. In a nutshell, ICONIX Process describes how to get from use cases to code reliably, in as few steps as possible.

Figure 3-3 shows how the different activities in ICONIX Process fit together.


Figure 3-3: ICONIX Process

ICONIX Process can be broken down into the following steps (the items in bold are the concrete modeling activities that you perform at each step):

  • Step 1: Identify your real-world domain objects (domain modeling).

  • Step 2: Define the behavioral requirements (use cases).

  • Step 3: Perform robustness analysis to disambiguate the use cases and identify gaps in the domain model.

  • Step 4: Allocate behavior to your objects (sequence diagrams).

  • Step 5: Finish the static model (class diagram).

  • Step 6: Write/generate the code (source code).

  • Step 7: Perform system and user-acceptance testing.

If you follow this process to the letter for your analysis and design modeling activities, then your project will stand a good chance of meeting the customer’s requirements—and doing so within a reasonable time frame.

As we walk through each of these steps in detail in the sections that follow, we’ll note four key milestones that tend to look good on a project plan (they’re also useful planning checkpoints, as they provide key stages where you can both say and demonstrate that “this XYZ work is done, so now we’re moving on to the next stage”).

  • Milestone 1: Requirements Review

  • Milestone 2: Preliminary Design Review

  • Milestone 3: Detailed/Critical Design Review

  • Milestone 4: Delivery

Step 1: Identify Your Real-World Domain Objects

Getting this step right is possibly the most important part of the whole project, because it establishes a solid foundation upon which absolutely everything else in the project (requirements, design, code, and so forth) is built.

This step can be further subdivided into the following steps:

  1. Identify your real-world domain objects and the generalization and aggregation relationships among those objects. Start drawing a high-level class diagram.

  2. If it’s feasible, do some rapid prototyping of the proposed system, or gather whatever substantive information you have about the legacy system you’re reengineering.

When this step is finished, you should have a reasonably correct domain model, which everyone on the project (the customer, the programmers, the analysts, the testers, and even the end users) can share and use as a common vocabulary. The domain model will continue to evolve and grow (and hopefully be whittled down to something simpler that still captures the business domain) as the project progresses.

The domain model is a preliminary guess at the static model (class diagrams) based strictly on problem-domain entity classes—no solution-space stuff. No attributes or operations are shown on the classes.

The domain model contains real-world things and concepts related to the problem that the system is being designed to solve. When we create a domain model, we’re creating a representation of the objects and actions that form the business and are focused on the problem that the project is attempting to solve. The initial domain model that you create for any project will never be perfect. It will evolve throughout the project as your understanding of the problem domain evolves.

How do you actually identify objects to go in the domain model? There are a number of techniques, the most important of which is simply to use your own experience and judgment. A good starting point if you’re really stuck, however, is to use the grammatical inspection technique:[6.] quickly pass through the available relevant material (requirements, business glossaries, and so forth), highlighting nouns and verbs as you go. Note that the relevant material should also include your own interviews with the customer and end users of the system. Often these discussions help more than anything else to resolve ambiguities and identify further domain objects.

After refining the lists as work progresses, you should find that

  • Nouns and noun phrases become classes and attributes.

  • Verbs and verb phrases become operations and associations.

  • Possessive phrases indicate that nouns should be attributes rather than classes.

These items represent only a general rule, of course (though a darned useful one). You might well find, for example, that some verbs eventually become objects rather than operations (particularly if you’re modeling a business process, or if you’ve identified a manager, or controller, class).

You should continue to iterate and refine the domain model, but this doesn’t mean that you should keep grinding nouns and verbs indefinitely. The goal is to build a glossary of object names that will serve as the nouns, as appropriate, within your use case text.

It’s worth establishing a time budget for building your initial domain model (e.g., restrict it to a collaborative workshop taking no more than a morning, or even just a couple of hours). The domain model is important, but you don’t want it to prevent the remainder of the project from ever getting started! You can generally find the most important 80% of your domain classes within a couple of hours—and that’s good enough to get going. You don’t have to get it perfect, because you’ll discover the remaining classes as you work through the use cases.

Step 2: Define the Behavioral Requirements

As you’ve probably gathered by now, the behavioral requirements in an ICONIX project are defined by use cases. The use cases expand on the high-level requirements (discussed in the previous step) and define how the system will behave in terms of user interactions. As we’ll discuss later in this book, this step benefits from being augmented with detailed interaction design (especially persona analysis; see Chapter 12).

This step can be further subdivided into the following steps:

  1. Identify your use cases using use case diagrams.

  2. Organize the use cases into groups. Capture this organization in a package diagram.

  3. Allocate functional requirements to the use cases and domain objects. (This step is optional depending on the formality of the project.)

  4. Write descriptions of the use cases (i.e., basic courses of action that represent the mainstream and alternative courses for less frequently traveled paths and error conditions).

How do you know when you’ve finished use case modeling? You’re ready to move to the next phases of the development process when you’ve achieved the following:

  • You’ve built use cases that together account for all of the system’s desired functionality.

  • You’ve produced clear and concise written descriptions of the basic course of action, along with appropriate alternative courses of action, for each use case.

  • You’ve factored out scenarios common to more than one use case, using the precedes and invokes constructs (or whichever constructs you generally prefer using).

Milestone 1: Requirements Review

Step 3: Perform Robustness Analysis to Disambiguate the Use Cases and Identify Gaps in the Domain Model

This is the final analysis step in the project. As you’ll see later in this chapter, robustness analysis plays a key role in ICONIX Process. At its core is the robustness diagram (see Figure 3-4).


Figure 3-4: Example robustness diagram

Robustness analysis involves working through the text of a use case and taking a preliminary peek at how you might design some software to implement a given use case, using the objects you’ve discovered up to this point. One of the main purposes of this activity is to discover when you don’t have all the objects you need, and then add them to your class diagram.

The robustness analysis step is further subdivided into the following steps:

  1. Draw robustness diagrams. For each use case

    1. Identify a first cut of objects that accomplish the stated scenario. Use the UML Objectory stereotypes (see Figure 3-5).


      Figure 3-5: Robustness analysis stereotypes

    2. Update your domain model class diagram with new objects and attributes as you discover them.

    3. Update (disambiguate) the use case text so that it matches the robustness diagram.

  1. Finish updating the class diagram so that it reflects the completion of the analysis phase of the project.

Milestone 2: Preliminary Design Review

Ivar Jacobson introduced the concept of robustness analysis to the world of OO in 1991. Robustness analysis involves analyzing the narrative text of each of your use cases and identifying a first-guess set of objects that will participate in the use case, and then classifying these objects into the following three object types:

  • Boundary objects, which actors use in communicating with the system.

  • Entity objects (also referred to as entities), which are usually objects from the domain model.

  • Control objects (also referred to as controllers), which serve as the “glue” between Boundary objects and Entity objects. Sometimes these are real Control objects, but most of the time they simply represent verb placeholders for functions.

This simple but highly useful technique serves as a crucial link between analysis (the what) and design (the how). We’ll walk through several examples of robustness analysis later in this book.

These three object types translate well into the Model-View-Controller (MVC) design pattern,[7.] which is used heavily in both client-server and GUI development. Entity objects are delivered by the Model, Boundary objects form the View, and Control objects form the Controller. For example, in a three-tier web application, a Boundary (or View) object could be a JSP page (sometimes also referred to as the presentation layer); the entities (i.e., the data) would be served up by a database, usually via a business object layer; and the Control object that binds the whole enchilada together would be provided by a business logic layer housed in an application server.

In a rich-client GUI application, a Boundary (or View) object could be a table or combo box component (e.g., in Java Swing, a JTable or JComboBox), the Model object would be the data model (e.g., DefaultTableModel) that serves up the entities to be displayed by the component, and the Control code would handle the UI events (e.g., scrolling up and down through the table) to determine which data from the model the view needs to display.

As projects grow in functionality (or in other ways, such as the number of users accessing the deployed system concurrently), the architecture must scale up to meet the challenge. This often leads to a more complex architecture, typically with functionality divided into separate layers (e.g., different areas of application logic might be separated out into different layers). This can be viewed as an extension of the Boundary-Control-Entity (BCE) architecture (or the MVC architecture), so ICONIX Process can still readily be applied to more complex architectures (i.e., the process can scale up to meet the demands of your project).

Step 4: Allocate Behavior to Your Objects

This step is where the design phase of the project begins. Our main diagram of choice for this step is the sequence diagram (see Figure 3-6), although you might also use additional diagrams and activities (such as state diagrams, activity diagrams, or unit tests following a strict test-driven methodology; see Chapters 12) as you see fit.


Figure 3-6: Example sequence diagram

This step is further subdivided into the following steps for each use case:

  1. Identify the messages that need to be passed between objects and the associated methods to be invoked.

  2. Draw a sequence diagram with use case text running down the left side and design information on the right.

  3. Continue to update the class diagram(s) with attributes and operations as you find them.

If you’re not allocating operations to classes on the sequence diagram, you’re ignoring its primary mission in life.

For each use case, you create one sequence diagram. This is an important point to remember, because you don’t want to end up getting bogged down with many diagrams just to map out the interaction in a single use case. Doing so would give you a nasty case of analysis paralysis so, even if you have multiple alternative scenarios on your use cases, put everything on the one sequence diagram.

This is the reason for the two-paragraph rule on use case text: you can fit the whole thing on one sequence diagram. The net result of this approach is that it prevents the diagrams from becoming too fragmented. It means you can validate that you’ve addressed the whole use case by reading a single diagram. Too many fragments make it hard to be sure you got all of the use case.

Step 5: Finish the Static Model

As the title of this step suggests, the key design artifact here is the static model, which is made up of one or more class diagrams (see Figure 3-7).


Figure 3-7: Example class diagram for the mapplet project presented in Part 2

This step is further subdivided into the following steps:

  1. Add detailed design information (e.g., visibility values and patterns).

  2. Verify with your team that your design satisfies all the requirements you’ve identified.

Milestone 3: Detailed/Critical Design Review

The static model is the grittier, more detailed version of the domain model, and it contains more implementation details. The static model has detailed class diagrams (perhaps even reverse engineered from the source code, but not necessarily) that are at a very detailed abstraction level and match the sequence diagrams.

MODELING QUESTION: SHOULD WE REUSE THE DOMAIN MODEL DIAGRAM AND SIMPLY KEEP ADDING TO IT UNTIL WE HAVE OUR STATIC MODEL?

If you know that your project is going to go through only one release (or a couple of releases at most), this approach serves nicely. However, in an agile project with lots of short releases and with domain modeling activities at the start of each release, it pays to keep separate diagrams for the domain model and class diagrams. The class diagram still grows and evolves from the original domain model (this approach is fundamental to ICONIX Process), but the diagrams are kept separate.

The domain model reflects our current understanding of the business domain (i.e., it’s an analysis-level artifact), whereas the fleshed-out class diagrams (there may be several) are collectively a detailed design artifact. As our understanding of the business domain evolves, we need to be able to quickly update and maybe also refactor the domain model, without getting slowed down by having to consider design details from previous iterations (at least not yet—that comes when we get to the design stage).

Of course, this means that you have an extra diagram to update, but it’s a trade-off. The benefit is that it’s much easier to keep the domain model up to date, and it’s easier to read (because it’s uncluttered by design details and records of design decisions).

If the domain model and the class diagram are the same diagram, it’s also more difficult to update the domain model in light of new business understanding, because you’re in effect modifying the detailed design without going through all the intermediate steps to get there (robustness analysis, sequence diagrams, and so forth).

Step 6: Write/Generate the Code

This step is, of course, where the programmers take the design and start to code from it. The programmers should have been involved in all the design steps (ideally the designers are also the programmers), so that the design has some grounding in the reality of the technologies in which the system will be implemented.

This step is subdivided into the following steps:

  1. Write/generate the code.

  2. Perform unit and integration testing.

If you are combining ICONIX Process with a test-driven approach (see Chapter 12), then the unit tests will be written before the code. An important point here is that the programmers are doing their own testing, including integration testing.

Step 7: Perform System and User-Acceptance Testing

For this stage, a different group from the programming team (ideally a separate QA team) performs system and user-acceptance testing, using the use cases as black-box test cases for the latter.

Milestone 4: Delivery

[6.]Kurt Derr, Applying OMT: A Practical Step-By-Step Guide to Using the Object Modeling Technique, (New York: Cambridge University Press, 1995).

[7.]See http://java.sun.com/blueprints/patterns/MVC.html.

 

 

'IT-개발' 카테고리의 다른 글

IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
프로젝트 3요소  (0) 2020.01.15
ICONIX Process  (0) 2019.12.30
프로그래머로서 나의 발전 단계  (0) 2019.12.18
자바스크립트에서 ==., ===  (0) 2019.06.16
How to disable "Submit" button and multiple submissions?  (0) 2019.05.25
Posted by 사용자 SB패밀리

댓글을 달아 주세요

프로그래머의 발전 단계

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

1. 자바스크립트에서  ==., ===

 

==는 loose equality할때 사용한다. 또한 ==은 형변환을 수행한다.

형변환 후에 오직 두개의 값 비교만 수행한다는 의미이다.

(Type coercion means that two values are compared only after attempting to convert them into a common type.)

 

=== strict equality 할때 사용한다.

타입(type)과 값(value) 모두 비교했을때 같아야 한다.

 

 

Falsy Value Comparison(거짓값 비교)

 

거짓값은 false, 0, "", null, undefined, NaN으로 총 6가지이다.

1. false — boolean false

2. 0 — number zero

3. “” — empty string

4. null

5. undefined

6. NaN — Not A Number

Posted by 사용자 SB패밀리

댓글을 달아 주세요

Having problems with a ticket being submitted multiple times?

This article will show you how to disable the Submit button after it has been click and change the text label to Submitting, please wait...
 

  1. Make a backup copy of your existing index.php file.
     

  2. Open file index.php in a plain text editor, such as Notepad.
     

  3. Inside index.php find the first two occurrences of this code:

    <input type="submit"
     

  4. After this code add:

    onclick="this.disabled=true;this.value='Sending, please wait...';this.form.submit();"

    Remember, do this twice - the first two times you find code in step 3.

    The final code should look like this:

    <input type="submit" onclick="this.disabled=true;this.value='Sending, please wait...';this.form.submit();" 
     

  5. Save changes, upload the index.php file to your server and test it.
     

That's it! Now, when your visitors click the "Submit" button when submitting a ticket, the button will be be disabled with the Sending, please wait message until the post is complete.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

Conditional operators

You have already seen the conditional operator is, however CoffeeScript offers a range of operators to match those present in JavaScript.

COFFEESCRIPT vs JAVASCRIPT

COFFEESCRIPT JAVASCRIPT
is ===
isnt !==
not !
and &&
or ||
true, yes, off true
false, no, off false

Now you can successfully use if, else and unless with conditional operators to create a basic program! In the next part we will explore functions and their unique syntax.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

git 계정 변경

IT-개발 2019. 4. 1. 09:37

git 계정 변경

    1. 방법 $ git config --global user.name "이름"
    2. 방법 $ git config --global user.email "이메일"

git 로컬 계정 변경

  1. 방법 $ git config --local user.name "이름"
  2. 방법 $ git config --local user.email "이메일"
Posted by 사용자 SB패밀리

댓글을 달아 주세요

 

 

Referencing issues in commit messages

When fetched from the repositories, commit messages are scanned for referenced or fixed issue IDs.
These options lets you define keywords that can be used in commit message to reference or fix issues automatically, and the status to apply to fixed issues.

Default keywords are:

  • for referencing issues: refs, references, IssueID
  • for fixing issues: fixes, closes

There's no default status defined for fixed issue. You'll have to specify it if you want to enable auto closure of issues.
If you want to reference issues without using keywords, enter a single star: * in the Referencing keywords (Administration/Repository) setting. In this case, any issue ID found in the message will be linked to the changeset.

Example of a working commit message using default keywords:

This commit refs #1, #2 and fixes #3

This message would reference issues 1 and 2 and automatically fix issue 3.
After a keyword issue IDs can be separated with a space, a comma or &.

The keywords are caseinsensitive and at least one blankspace or colon is needed between the keyword and the first hash to produce 
a match. More examples that will produce the same result as the example above:

This commit refs:#1, #2 and fixes #3 This commit Refs #1, #2 and fixes #3 This commit REFS: #1, #2 and fixes #3

Enable time logging

Allows time logging directly from commit messages. This only makes sense if you activated the "Time tracking" module in said project. In this case, you can add special words in your commit message to indicate the time you spent on an issue.

The basic syntax for doing that is : @<time>, where time consists in a number of hours or minutes.

Here's a list of many valid commit messages that would work if you want to say you spent N hours on issue 1234:

Implement feature #1234 @2 Implement feature #1234 @2h Implement feature #1234 @2hours Implement feature #1234 @15m Implement feature #1234 @15min Implement feature #1234 @3h15 Implement feature #1234 @3h15m Implement feature #1234 @3:15 Implement feature #1234 @3.25 Implement feature #1234 @3.25h Implement feature #1234 @3,25 Implement feature #1234 @3,25h

Activity for logged time

This is the type of activity that should be used when detecting there's a log time in a commit message (see above).

 

 

 

http://www.redmine.org/projects/redmine/wiki/RedmineSettings#Referencing-issues-in-commit-messages

Posted by 사용자 SB패밀리

댓글을 달아 주세요

Adobe CS3 문제

IT-개발 2019. 2. 10. 09:56

Adobe CS3 불청객



'IT-개발' 카테고리의 다른 글

git 계정 변경  (0) 2019.04.01
commit messages in Git, Redmine Sync  (0) 2019.04.01
Adobe CS3 문제  (0) 2019.02.10
AWS와 함께 하는 클라우드 컴퓨팅  (0) 2019.02.02
AWS가 제안하는 서버리스 아키텍처  (0) 2019.01.24
RAD Studio 버전  (0) 2019.01.10
Posted by 사용자 SB패밀리

댓글을 달아 주세요

Amazon


AWS와 함께 하는 클라우드 컴퓨팅 - 홍민우 AWS 매니저



https://www.slideshare.net/awskorea/aws-aws-90606807



'IT-개발' 카테고리의 다른 글

commit messages in Git, Redmine Sync  (0) 2019.04.01
Adobe CS3 문제  (0) 2019.02.10
AWS와 함께 하는 클라우드 컴퓨팅  (0) 2019.02.02
AWS가 제안하는 서버리스 아키텍처  (0) 2019.01.24
RAD Studio 버전  (0) 2019.01.10
문자 인식  (0) 2018.12.18
Posted by 사용자 SB패밀리

댓글을 달아 주세요

AWS가 제안하는 서버리스 아키텍처





출처: 판교 개발자 데이 – Aws가 제안하는 서버리스 아키텍처 – 김필중

'IT-개발' 카테고리의 다른 글

Adobe CS3 문제  (0) 2019.02.10
AWS와 함께 하는 클라우드 컴퓨팅  (0) 2019.02.02
AWS가 제안하는 서버리스 아키텍처  (0) 2019.01.24
RAD Studio 버전  (0) 2019.01.10
문자 인식  (0) 2018.12.18
API, 라이브러리, SDK, 프레임워크, 플랫폼 - 관한여  (0) 2018.12.16
Posted by 사용자 SB패밀리

댓글을 달아 주세요

RAD Studio 버전

IT-개발 2019. 1. 10. 14:44

RAD Studio에는 Professional, Enterprise Architect의 3 가지 버전이 있습니다. 

각 에디션의 차이, 기능 자세한 내용은 RAD Studio 제품 버전 및기능 목록 을 참조하십시오.



Posted by 사용자 SB패밀리

댓글을 달아 주세요

문자 인식

IT-개발 2018. 12. 18. 22:55

문자 인식

  1. 개요
    • 문자의 개념
    • 필기 도구와 사람의 필기 운동의 물리적인 작용에 의해 구체적인 형태로 기록되어, 그것을 읽는 사람에게 정보를 전하는 것.

    • 문자 인식
    • 문자를 인식하여 하나의 개념에 대응시키는 작용

    • 문자인식의 대상

    • 문자 인식
      온라인 문자 인식오프라인 문자인식
      제약된 필기자유로운 필기인쇄체필기체
        특수활자체단일
      활자체
      다중
      활자체
      제약된 필기체자유로운 필기체
        바코드자기 잉크문자 

    • 문자 인식의 과정

    • 입력
      패턴
      -->전처리-->특징
      추출
      -->분류-->후처리-->인식결과 
      출력

  2. 문자 인식의 어려움
    • 질적인 문제
    • 인식 대상이 단일 활자체의 인쇄체 문자에서 다양한 활자체의 인쇄체 문자, 제약이 가해진 필기체 문자, 더 나아가 무제약 필기체 문자로 바뀜에 따라 증가.

    • 양적인 문제
    • 인식 대상이 숫자(10종)에서 영문자(52종), 한글(11,172종), 더 나아가 한자(약 50,000여 종)로 바뀜에 따라 증가.

  3. 온라인 문자 인식과 오프라인 문자 인식
    • 온라인 문자 인식
      • 사용자가 필기하는 동안에 인식기가 필기 문자를 인식하는 것.
      • 장점 : 획수, 획순, 각 획에 대한 필기 방향과 각 획 내에서의 필기 속도 등 필기의 시간적, 공간적인 동적 정보를 얻을 수 있다. (인식률이 높다.)
      • 단점 : 온라인 데이터(문자)를 사용자가 필기하는 순간에만 얻을 수 있고, 문자 입력을 위해 특수한 장치인 전자 펜(또는 스타일러스)과 태블릿(또는 디지타이저)을 사용해야 한다.

    • 오프라인 문자 인식
      • 이미 작성된 인쇄체 문자 혹은 필기체 문자를 인식하는 것.
      • 장점 : 글을 쓴 이후에는 언제라도 데이터를 얻을 수 있다.
      • 단점 : 동적 정보를 얻을 수 없다. (인식률이 낮다.)
  4. 문자 인식의 응용 분야
  5. 우편물 자동 분류를 위한 우편 번호 인식, 산업 현장에서의 제품 검사나 분류, 문서 인식, 도면 인식, 팩시밀리를 통해 전달받은 영상에서의 문자 인식, 워드 프로세서 OCR, 금융 기간에서의 전표 또는 수표의 자동 입력 등 여러 분야에 걸쳐 실용화되어 실생활에 효과적으로 사용.



자료출처 : 배경환


'IT-개발' 카테고리의 다른 글

AWS가 제안하는 서버리스 아키텍처  (0) 2019.01.24
RAD Studio 버전  (0) 2019.01.10
문자 인식  (0) 2018.12.18
API, 라이브러리, SDK, 프레임워크, 플랫폼 - 관한여  (0) 2018.12.16
Windows 7 에서 델파이 도움말 사용하기  (0) 2018.10.29
PI System  (0) 2018.10.13
Posted by 사용자 SB패밀리

댓글을 달아 주세요

API, 라이브러리, SDK, 프레임워크, 플랫폼


 용 어

 개 념

API

 Application Program Interface로 인터페이스를 의미하며, 서로 다른 목적으로 개발된 software의 특정 기능을 호출하기 위해서 software나 library 기능을 사용할 수 있도록 기능 호출을 하도록 하는 것이다.

대표적인 예로 MS runtime API, java API, google API, facebook API 등이 있다.

SDK

 Android SDK, iOS SDK, Windows SDK, 특정 제품의 SDK 등의 서비스를 제공하기 위한 것이며, 모두 대상이 되는 운영체제나 서비스 기반이 있다.

Library 

필요한 특정 모듈을 호출하여 사용하는 개념이다. 

대표적인 예로 Rad Studio 컨포넌트 라이브러리 등이 있다. 

Framework 

 프레임워크는 소프트웨어를 개발할 때 사용할 수 있는 인터페이스 기반 패키지로 말할 수 있다. 인터페이스란 개발의 basement가 되는 구조와 코드/알고리즘/암호화/데이터베이스 연동 방식의 집합체라고 할 수 있다.

대표적인 프레임워크는 마이크로소프트 사의 MFC, 닷넷(.NET) 프레임워크와 자바의 스프링, 전자정부, 앵귤라 프레임워크, TMSSoftware TMS Package 등이 있다.

 Platform

 특정 장치나 시스템, 서비스 등에서 이를 구성하는 기반이 되는 하드웨어나 소프트웨어 환경, 더 크게는 틀이나 골결을 지칭한다. 또, 서드파티에 의해 개발된 것이 사용자들에 의해 사용/유통될 수 있는 환경/기술 등을 의미한다.

대표적인 플랫폼으로는 Windows, MacOS, Linux와 같은 운영체제, 모바일 안드로이드나 iOS, 엠바카데로 사의 파이어몽키(FireMonkey), 인터넷 포털 서비스의 소셜네트워크 서비스 또는 카카오톡, 라인 등이 있다.

 Docker

 


컴포넌트란 인터페이스를 기본적으로 구현하고 응용 프로그램간의 개체 공유를 가능하게 하는 독립적인 기능을 수행하는 소프트웨어 모듈이다.

컴포넌트(Component, VCL)는 CBD(Component based Development) 개발방법론. 

기업들은 쇼핑바구니, 사용자 인증, 검색엔진, 카탈로그 등 상업적으로 이용 가능한 컴포넌트를 결합하여 그들의 전자상거래 응용프로그램을 개발하는 컴포넌트 기반 개발을 사용한다.



'IT-개발' 카테고리의 다른 글

RAD Studio 버전  (0) 2019.01.10
문자 인식  (0) 2018.12.18
API, 라이브러리, SDK, 프레임워크, 플랫폼 - 관한여  (0) 2018.12.16
Windows 7 에서 델파이 도움말 사용하기  (0) 2018.10.29
PI System  (0) 2018.10.13
DAS, NAS, SAN 개념  (0) 2018.09.27
Posted by 사용자 SB패밀리

댓글을 달아 주세요

Windows 7 에서 델파이 도움말 사용하기


ARCHITECTURE에 따라 x86 (32bits)    x64 (64bits) 설치


Windows6.1-KB917607-x64.msu

Windows6.1-KB917607-x86.msu



'IT-개발' 카테고리의 다른 글

문자 인식  (0) 2018.12.18
API, 라이브러리, SDK, 프레임워크, 플랫폼 - 관한여  (0) 2018.12.16
Windows 7 에서 델파이 도움말 사용하기  (0) 2018.10.29
PI System  (0) 2018.10.13
DAS, NAS, SAN 개념  (0) 2018.09.27
IaaS PaaS SaaS  (0) 2018.09.19
Posted by 사용자 SB패밀리

댓글을 달아 주세요

PI System

IT-개발 2018. 10. 13. 19:45


PI System







아래 블로그도 참고가 될 수 있겠다.

http://blackhunydev.tistory.com/category/4%EC%B0%A8%EC%82%B0%EC%97%85%ED%98%81%EB%AA%85/PI%20System

'IT-개발' 카테고리의 다른 글

API, 라이브러리, SDK, 프레임워크, 플랫폼 - 관한여  (0) 2018.12.16
Windows 7 에서 델파이 도움말 사용하기  (0) 2018.10.29
PI System  (0) 2018.10.13
DAS, NAS, SAN 개념  (0) 2018.09.27
IaaS PaaS SaaS  (0) 2018.09.19
SQL Server Express Edition DB 용량 제한  (0) 2018.06.14
Posted by 사용자 SB패밀리

댓글을 달아 주세요

DAS, NAS, SAN 개념

IT-개발 2018. 9. 27. 11:55

DAS, NAS, SAN 개념


 구 분

설 명

DAS

(Direct Attached Storage)

- 서버가 채널(SCSI 또는 Fiber Channel)을 통해 저장 장치에 직접 연결하여 사용하는 방식. 

- 서버에 직접 외장 저장 장치를 추가하므로 속도는 빠르고 확장은 쉽지만, 연결 수에 한계가 있다. 각 서버는 자신이 직접 파일 시스템을 관리한다.

NAS

(Network Attached Storage)

- 서버와 저장 장치가 이더넷 등의 LAN 방식의 네트워크에 연결된 방식이다. LAN 은 TCP/IP 프로토콜 기반이고 저장장치는 SCSI를 사용하므로 이들 간의 통신을 위해 중계 역할을 하는 파일 서버가 필요하다.

* 장점 
- DAS와 달리 Port 수에 제한없어 확장성과 유연성이 뛰어남
- 경제적이며 설치와 유지보수가 용이함

* 단점
- 접속 증가시 성능 저하
- 파일 전송 속도는 DAS보다 느림
- 파일 시스템을 공유하기 때문에 높은 수준의 보안을 요구하는 곳에서는 문제가 될 수 있음

SAN

(Storage-Area Network)

- 서버와 저장 장치를 Fiber Channel Switch로 연결한 고속 데이터 네트워크
- 저장 장치를 향상시켜 장치가 로컬 연결 장치로 서버의 운영 체제에 표시되게 한다
- SAN 구성에 확장성, 유연성, 가용성이 우수함

소형은 DAS, 중규모는 NAS, 대규모는 SAN 이 적합함

- 전통적인 Storage 접속 방법 : DAS(Direct Attached Storage)

- 네트워크 Storage 접속 방법 : SAN(Storage Area Network), NAS(Network Attached Storage)




'IT-개발' 카테고리의 다른 글

Windows 7 에서 델파이 도움말 사용하기  (0) 2018.10.29
PI System  (0) 2018.10.13
DAS, NAS, SAN 개념  (0) 2018.09.27
IaaS PaaS SaaS  (0) 2018.09.19
SQL Server Express Edition DB 용량 제한  (0) 2018.06.14
[웹] 웹퍼블리셔(Web Publisher)란  (0) 2017.12.17
Posted by 사용자 SB패밀리

댓글을 달아 주세요

IaaS PaaS SaaS

IT-개발 2018. 9. 19. 17:54

Infrastructure as a Service
Platform as a Service
Software as a Service

각 백엔드 서비스에 대해서 간단히 설명할 수 있고
예제를 알고 있어야 한다.

인프라스트럭처 : 닷넷 프레임워크, JDK​


플랫폼 : 가상머신, 데이터베이스 서버


소프트웨어 : 컨데이터, AWS



'IT-개발' 카테고리의 다른 글

PI System  (0) 2018.10.13
DAS, NAS, SAN 개념  (0) 2018.09.27
IaaS PaaS SaaS  (0) 2018.09.19
SQL Server Express Edition DB 용량 제한  (0) 2018.06.14
[웹] 웹퍼블리셔(Web Publisher)란  (0) 2017.12.17
[개발/VC++] error C3861: '_bstr_t' : 식별자를 찾을 수 없습니다.  (0) 2017.11.03
Posted by 사용자 SB패밀리

댓글을 달아 주세요