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

TFT(Task Force Team)과 CFT(Cross Functional Team)이란?
□ Task Force 조직의 개념
ㅇ Task Force조직은 특정
과업(Task)을 완수하기 위해 다양한 부서에서 사람을 착출해 한시적으로 일정 기간동안 조직을 운영하는 것을 말합니다.
ㅇ Task Force조직은 직급에 상관없이 경험과 능력을 보유한 구성원이 리더십을 발휘하며, 단계별 일의 특성에 따라 리더를 교대하면서 일을 추진하기도 합니다.

□ Task Force조직의 유형
ㅇ Task Force조직의 유형에는 사업부를 초월하여 조직을 구성하는 <Cross Business Task Force조직>과 특정 사업부 내에서 각 부서의 경계를 초월해 조직을 구성하는 <Cross Functional Task Force조직>의 유형이 있음

즉 CFT는 TFT의 한 유형인거죠.
삼성경제연구소의 ‘열린시대 열린 경영’이라는 책을 보면, CFT(Cross Functional Team)를 수직적 경영방식을 타파한다는 의미가 강하다고 여겨 ‘기능횡단팀’으로 번역되었는데요,, 한 팀이 여러 가지 기능을 복합적으로 수행하는 팀을 말합니다. 최근 들어 팀제가 크게 유행하고 있는데 가장 큰 이유는 환경이 급변함에 따라 유연한 조직의 필요성이 갈수록 커지고 있기 때문입니다. 업무의 성격도 예전에 비해 훨씬 복잡해지고 있어 단일부서에서만 처리하기 곤란하다는 이유도 있구요, 또한 팀제를 도입함으로써 부서의 장벽을 넘어 뛰어난 인재들을 고루 활용해서 성과를 만들어 내는 것이 가능하다고 생각되기

Posted by 사용자 SB패밀리
TAG CFT, MDT, tft, 조직

댓글을 달아 주세요

예전에 대학교에서 배웠던 데이터베이스 과정은 수박 겉핥기 였다면

회사생활하면서 개발할 때 경험한 데이터베이스 수행 능력 또한 깊지 않았다.

데이터베이스 설계니 제어니 세팅이니 하는 건 

제대로 배운 것 같지 않다. SI 개발을 한 10년 가까이 안하다 보니

기억도 가물가물하다.

그래서 이론이 부족하고 깊이가 부족한 것을 채우려고 데이터 모델링, SQL 튜닝 도서를 보고 있다.

확실히 SQL문 작성할 때도 '이 방법이 좋구나'. 또는 '이렇게 해야 동작하구나' 하면서 

지나갔던 일들인데 도서를 보고 이론을 공부해 보니, 부족함을 느끼게 되었다.

대학생, 석사과정, 박사과정, 교수의 지식 수준을 깨닫는 유머가 있는데

그 이야기를 또 한 번 공감하게 된다.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

프론트오피스, 백오피스, 프론트엔드, 백엔드

먼저, 비즈니스 관점에서 살펴보면,

프론트오피스란 서비스의 소비층인 고객이 사용하는 페이지를 말합니다. 쇼핑몰을 예로 들면, 쇼핑몰에서 상품을 보고 장바구니에 담고 결제하고 상품평도 쓰는 등의 서비스를 제공하는 측입니다.

백오피스란 서비스의 일련을 제공하기 위하여 상품을 등록하고 마케팅을 설정하고 결제와 매출, 수익 등을 관리하는 서비스를 제공하는 페이지 입니다. 다른 말로는 어드민이라고 부르기도 하지만 어드민이 아닌 경우도 있기 때문에 백오피스라고 하는 편이 낫습니다.

 

기술적 접근으로 살펴보면,

프론트엔드란 서비스를 개발하는 기술적인 측면에서 뷰, 프리젠테이션 레이어를 말합니다. 백엔드로부터 데이터와 기능을 제공받아서 사용자가 직접 화면(페이지)를 보고 개발할 수 있는 인터페이스를 개발합니다. 앱 스토어에서 구매한 디바이스에 설치해서 사용하는 앱이나 브라우저에서 접속한 페이지를 구현하는 측입니다. 

백엔드란 프레젠테이션 레이어에 서비스를 제공하기 위하여 서버, 미들웨어, WAS, DBMS, RestfulAPI등을 개발하는 측을 말합니다.

그림과 함께 보시면 이해가 쉬울 것으로 생각이 됩니다.

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

디버깅의 6단계

IT-개발 2020. 6. 16. 00:00

디버깅의 6단계

나 또한 코더 프로그래머 개발자를 거치면서
이런 단계를 겪었었다.
그런데 지금은 이런 개발자들을
상대하고 있다. 가끔 고집이 있는 개발자도 있다

Posted by 사용자 SB패밀리

댓글을 달아 주세요

MIDAS에 관하여

IT-개발 2020. 5. 3. 01:01

여러분 분산 처리 기술에 대해서 이번 기회에 확실히(??) 알아보도록 하죠...

요즘 기업체 동향인 분산 시스템 환경에서는 사용자가 그 위치와 무관하게
신뢰성 있고 빠른 서비스를 받을 수 있도록 하는 방법으로 다계층(Multi-Tier)
환경 구축 방법의 하나로 MIDAS(Multi-Tier Distributed Application Service)를
사용하기도 하죠...

이 MIDAS에 대하여 함께 공부하기로 하는 것입니다.
우선, MIDAS를 구체적으로 다루기 전에 다계층 응용프로그램 구조에 대해 간단히
살펴보면....

다계층 클라이언트/서버 응용프로그램은 인터넷 또는 LAN상에서 비즈니스로직이
구현이 서버 응용프로그램과 프리젠테이션 로직이 구현된 클라이언트 프로그램이
서로 통신하면서 원하는 서비스를 구현하는 것을 말합니다.

다계층 응용 프로그램의 모델 중 가장 간단한 형태인 3-계층은 클라이언트
응용프로그램, 응용프로그램 서버, 리모트 데이터베이스 서버로 구성되어
있습니다...

이에 대한 기능과 장점을 알아보도록 하죠.  

◇ 클라이언트 응용프로그램

  사용자 시스템에 사용자 인터페이스를 제공하죠.

◇ 응용프로그램 서버(서버 프로그램)

  모든 사용자가 접근 할 수 있는 중앙 네트워크에 위치하며,

  흔히, 데이터 서비스를 제공하는 기능을 갖습니다.

◇ 리모트 데이터베이스 서버

  관계형 데이터베이스 시스템을 제공합니다.


◆ 다계층(Multi-Tier) 응용 프로그램의 장점

☞ 응용프로그램 서버에 통합적으로 비즈니스 로직을 구현함으로써

   여러개의 각 클라이언트 응용프로그램마다 중복된 비즈니스

   로직을 구현할 필요가 없으므로 유지보수 비용이 적게 든다.

☞ 가벼운 클라이언트 응용프로그램은 인스톨, 환경설정이 용이하다.

☞ 몇 개의 시스템에 응용프로그램 서버를 분산시킴으로써 Load

   Balancing 기능을 수행하며, 한 시스템이 다운되어도 여유 시스템이

   가동되므로 Fail Over기능을 구현할 수 있다.

☞ 다계층 각 계층별로 보안단계를 분류하여 서로 접근 권한을 달리

   부여함으로써 보안 기능을 강화 할 수 있다.


- MIDAS기술과 특징 #1

MIDAS는 앞의 다계층 응용 프로그램의 장점을 지니면서 클라이언트 응용프로그램과
응용프로그램 서버 사이에 데이터베이스 정보를 통신하는 메커니즘을 제공합니다.

MIDAS기술을 자세히 살펴보면 빠르고 쉽게 개발할 수 있도록 디자인되었으며,
최고의 개발 속도와 호환성을 높이기 위해 MIDAS는 서버용 데이터베이스에 접근
가능하며, 비즈니스 룰과 데이터 Constraint를 지원합니다.

클라이언트 단에 데이터 Constraint가 정의되면 자동으로 서버 단에서
클라이언트 단으로 Constraint가 전달됩니다.

이것은 네트워크의 프래픽을 줄여 효율을 증진시키게 되며, 에러 처리 부하를
감소시켜주는 효과가 있습니다. 또한 사용자의 응용프로그램 속도를 높여주는
효과도 있습니다.

MIDAS는 다계층의 특성상 비즈니스 룰이 서버에 위치함으로써 가벼운
클라이언트를 유지하고 클라이언트 단에 환경설정이 거의 필요없으므로 배포 후
유지보주 또한 쉽고 비용이 적게 듭니다.

이는 요즘 추세인 사용자의 위치 이동이 잦은 응용프로그램에 매우 적합한
기술입니다. 또한, Load Balancing 기능이 있어 높은 서버 이용률과 Fail-Over
기능으로 시스템을 안정적으로 운영할 수 있도록 하여 줍니다.

- Remote DataBroker

Remote DataBroker를 쉽게 말하면 Cliente Program과 Server Program을
상호연결해주는 기반 기술이라고 합니다.

이것을 이용하게 되면 클라이언트 프로그램의 덩치나 작업량이 가볍게 줄일 수
있습니다. 즉, 클라이언트 시스템에서 프로그램의 크기가 작아진다는 의미입니다.

Remote DataBroker를 사용할 때는 140kbyte짜리인 하나의 DLL만 사용하고 배포
방법으로 델파이의 웹을 이용한다면 수동으로 설치하거나 환경설정을 할 필요성이
없어져 배포가 매우 용이해집니다.

클라이언트 프로그램은 단순히 인터페이스만을 구현하고 비즈니스 로직을 가지고
있지 않아 프로그램의 소스 대부분이 GUI(Graphic User Interface)에 해당됩니다.

클라이언트 프로그램이 작아지는 이유는 2-계층 프로그램처럼 비즈니스 로직을
따로 구현하지 않고 사용자 인터페이스 부분만을 구현하는 것 외에도 다른 것이
있습니다.

이는 3-계층 프로그램을 구축할 때에는 클라이언트 시스템에 프로그램 이외에
데이터베이스 연결을 위한 미들웨어 (델파이 SQL Link 또는 각종 벤더사들이
제공하는 ODBC 드라이버)와 각 데이터베이스 벤더에서 제공하는 클라이언트
모듈(인포믹스의 I-NET, 오라클의 SQL*NET)이 따로 필요하지 않다는 것입니다.

결국 가볍고 사용자 인터페이스 위주의 클라이언트 응용프로그램을 사용하게
되어 클라이언트측으로의 설치, 설정, 유지 보수 작업이 거의 없어지게 되는
장점을 지니고 있습니다.


- ConstraintBroker

데이터베이스와 관련된 응용프로그램에서 가장 중요한 것은 사용하고 있는
데이터가 정말 유효한 데이터인가 하는 것입니다. 만약 데이터베이스
응용프로그램에서 사용자가 잘못된 데이터를 가지고 수정하려고 할 때 어떤
순서로 어떤 작업을 하는 것일까요. 다음과 같은 순서로 작업을 처리할 것입니다.

1. 클라이언트 응용프로그램이 서버에 데이터를 전송한다.
2. 트랜잭션을 시작한다.
3. 데이터 수정을 시도한다.
4. 잘못된 데이터이므로 수정이 불가능하다.
5. 트랜잭션을 취소한다.
6. 데이터베이스 서버는 클라이언트 응용프로그램으로 에러 메시지를 전송한다.
7. 사용자는 정확한 데이터를 재전송한다.

이 과정을 살펴보게 되면, 데이터 무결성을 위해서 항상 유효한 데이터만이
데이터베이스 서버에서 적용된다는 것을 알 수 있습니다.

그러나, 이 메커니즘은 유효하지 않은 데이터는 처리되지 않으므로 비효율적으로
네트워크에 의하여 전송만 되고 처리되지 않습니다.

결국, 네트워크의 트래픽만을 증가시키게 되고, 사용자는 기다린 보람이 없이
그냥 시간이 흐른 뒤 에러 메시지만을 보게 될 것입니다.

이러한 단점을 보완하기 위한 일반적인 방법은 개발자가 데이터 무결성에 관련된
룰을 클라이언트 응용프로그램에서 구현하는 것입니다.

이렇게 하게 되면, 유효한 데이터만이 네트워크를 통해서 데이터베이스 서버에
전송되고 될 것입니다. 따라서 최종 사용자는 잘못된 자료에 대한 반응 시간이
빨라져서 작업의 효율이 높아지게 될 것입니다.

그러나, 무결성에 관련된 룰을 클라이언트에서 재 구현하는 것은 개발자의
노력이 필요하게 되고 데이터베이스가 변경될 때마다 룰을 가진 클라이언트측의
모든 응용프로그램이 수정되고 재배포되어야 하는 불편함을 가지게 됩니다.

이에 비해서 ConstraintBroker 기술은 개발자가 데이터 무결성 룰을 하나의
위치에서 관리할 수 있도록 해주면서 네트워크 트래픽은 최소화시키는 효율성
높은 응용프로그램을 생성할 수 있도록 해주는 뛰어난 솔루션입니다.

ConstraintBroker는 Remote DataBroker와 함께 운영되는데, 그 방법을 살펴보게
되면 Remote DataBroker는 클라이언트 요청을 받아서 데이터베이스로 자료를
질의하고, 다시 클라이언트로 되돌려 주게 됩니다.

이 때, ConstraintBroker가 작동되면 Remote DataBroker는 제약사항을 검색하기
위해 데이터 딕셔너리(Data Dictionary)로 추가 질의를 보내게 됩니다.
데이터 딕셔너리는 자료의 무결성에 대한 정보를 포함하는 테이블입니다.
이 테이블은 BDE(Borland Database Engine:ODBC보다 빠르다고 평가되어
있습니다)가 지원하는 어떤 종류의 데이터베이스에도 저장될 수 있습니다.

ConstraintBroker는 개발가에게 무결성 룰의 배포를 간단하고 자동화된 방법으로
제공합니다. 룰의 배포를 동적으로 할 수 있게 되면 개발자들이 많은
애플리케이션을 보다 쉽게 관리하여 유지할 수 있게 됩니다.

예를 들어, 데이터베이스에서 룰이 수정되면 개발자는 데이터 딕셔너리를
수정해야 할 필요가 발생합니다. 데이터 딕셔너리가 수정된 후에 Remote
DataBroker는 내부적으로 수정을 위해 하나의 함수를 호출할 수 있게 되는데
클라이언트가 그 데이터를 요청하게 되면, 재프로그래밍, 재컴파일, 재배포,
재설정 등의 과정이 필요없이 새로운 룰이 클라이언트로 전달됩니다.
예를 들어, ConstraintBroker가 구현되어 있는 곳에서 잘못된 데이터를 가지고
수정하려고 한다면 이제는 다음과 같은 순서로 작업이 처리됩니다.

1. 클라이언트 응용프로그램이 데이터베이스 서버로 자료를 전송합니다.
2. 클라이언트 단계에서 즉시 에러가 발생되어 유효하지 않은 데이터임
  을 사용자에게 알려줍니다.
3. 사용자는 정확한 데이터 재전송을 합니다.

여기에서 사용자는 잘못된 데이터 입력에 대해 빠르게 반응을 하여 대처할 수
있게 됩니다. 이것은 네트워크나 데이터베이스 서버가 데이터의 검증을 위해
전혀 관여하지 않기 때문입니다.

정확한 데이터 입력으로 Constraint가 통과되면 데이터베이스 서버로 레코드가
전송될 것입니다.

데이터 딕셔너리는 사용자 Constraint와 사용자 정의 에러 메시지를 추가하는
기능을 포함하고 있습니다. 이것은 응용 프로그램에 트정 룰을 추가하는 기능을
의미합니다. 예를 들어, 데이터 무결성 룰은 값이 0보다 큰 경우에만 입력되도록
하기 위한 것인 경우입니다.

인프라이즈에서 제공하는 툴에서 데이터 딕셔너리의 수정, 관리를 위해 사용하는
뛰어난 툴로 SQL 익스플로러가 있습니다. SQL 익스플로러를 이용하여 테이블,
앨리어스, 스토어드 프로시져, 트리거, 무결성 룰의 생성과 수정을 관리할 수
있으며, 또한 손쉽게 각 데이터베이스를 관리할 수 있게 합니다.

오라클, 인터베이스, 사이베이스, 인포믹스, DB2, MS SQL 서버 등의 스키마
정보를 나타내 주며, SQL 익스플로러에서 개발자는 SQL문을 사용하여 자료를
보거나 편집할 수 있습니다.


- Business ObjectBroker

Business ObjectBroker 기능을 이용하기 위해서는 델파이에서 제공하는 툴인
OLEnterprise를 인스톨하여 사용해야 하는데, OLEenterprise은 클라이언트와
서버 시스템 사이에 Remote Procedure Calls(RPCs) 프로토콜을 이용하여
오토메이션 마샬링을 호출하거나, 상호통신을 하는데 관여한다. Business
ObjectBroker기능과 서비스하던 서버가 갑자기 다운되었을 때 다른 정상
서버로 서비스를 받도록 하는 Fail-Over기능을 제공한다. 앞에서 설명한
Remote DataBroker는 DCOM(Distributed Common Object Model)을 기반으로 하여
설계되었으며, 이러한 DCOM은 위와 같은 기능을 제공하기 어렵다.

Business ObjectBroker와 OLEnterprise는 OLE 자동화 서버(OLE Automation
Server, COM 서버)나 DCE/RPC 서버가 Load Balancing과 Fail-Over 기능을 가질
수 있도록 해준다. 다시 말해 이러한 기능을 제공하기 위한 조건은
응용프로그램이 OLE자동화 서버나 DCE/RPC서버 기능이 있어야 한다는 말이다.

Business ObjectBroker는 비즈니스 오브젝트브로커(Business ObjectBroker),
오브젝트 팩토리(Object Factory), 오브젝트 에이전트(Object Agent),
오브젝트 익스플로러(Object Explorer)등 다시 4가지 요소로 구성된다.


~ 비지니스 오브젝트브로커

비즈니스 오브젝트브로커는 클라이언트에서 요청한 서버 응용프로그램이
설치되고 등록된 서버 시스템 중에서 하나를 클라이언트에 연결시켜 주는
역할을 한다. 이를 위해 서버 응용프로그램은 그것의 레지스트리 항목을
만들고자 하는 곳에서 글로벌 레지스트리를 제공한다. 이것은 클라이언트
응용프로그램이 네트워크상의 응용프로그램 서버 중의 하나로 연결할 때
참조할 수 있는 유일한 정보이다.


~ 오브젝트 팩토리

서버에 의해 사용되는 오브젝트 팩토리는 RPC 서버이면서 OLE 자동화
클라이언트이다. OLE 자동화 클라이언트로 행동할 때에는 원거리 OLE
요청(Remote OLE Request)이 발생할 때 클라이언트 시스템상의 오브젝트
에이전트에 의해 RPC(Remote Procedure Call)통신으로 오브젝트 팩토리에
전달된다. 그러면 오브젝트 팩토리는 원격 클라이언트 응용프로그램을 대신하여
OLE 요청을 다시 발생시킨다. 또한, RPC 서버로의 원격지 요청은 오브젝트
팩토리를 통하지 않고 오브젝트 에이전트가 RPC 오브젝트와 직접 통신한다.


~ 오브젝트 에이전트

클라이언트에서 사용되는 것으로 OLE 자동화 서버이면서 RPC 클라이언트이다.
이것은 원격지 서버를 대신하여 OLE 자동화 서버처럼 작동한다. 원격 요청은
오브젝트 에이전트를 통해 전달된다. 원격 OLE 오브젝트를 위한 요청은
오브젝트 에이전트가 그 요청을 서버 시스템의 오브젝트 팩토리로 RPC를
사용하여 전달하고, 원격 RPC 오브젝트를 위한 요청은 오브젝트 에이전트가
레지스트리로부터 인터페이스 정의를 읽어 동적으로 RPC 요청을 만들고 그것을
서버로 보낸다.


~ 오브젝트 익스플로러

사용자가 기업 내 환경을 탐색할 수 있도록 오브젝트들과 각종 서비스 내용을
동적으로 볼 수 있는 유틸리티이다. 오브젝트 익스프로러는 클라이언트에서
오브젝트를 공유하고 재사용할 수 있도록 불러오기(Import)/내보내기(Export)
기능을 제공한다. 오브젝트를 개발하는 개발자는 오브젝트를 사용할 수 있도록
하기 위해 오브젝트 익스프로러를 사용한다. 익스플로러는 기업내의 각종
오브젝트에 대한 로컬, 원격, 글로벌 레지스트리를 검색할 수 있다. 하나의
오브젝트가 선택되면 익스플로러는 자동적으로 오브젝트에 대한 접근을
가능하게 하기 위해 요구되는 모든 정보를 가져와서 사용자 로컬 레지스트리에
등록시킨다.


지금까지는 클라이언트가 연결할 서버를 결정하는 방법은 무작위 선택(Random)
알고리즘에 따르고 있다. 그러나 인프라이즈(Inprise)사는 앞으로 이것을
서버의 CPU 사용도, I/O등과 물리적인 거리를 고려하여 좀더 논리적으로
구성하기 위한 기술을 개발하고 있다고 한다.

지금까지 개략적으로 MIDAS의 기반 기술인 Remote DataBroker, ConstraintBroker,
Business ObjectBroker에 대해서 살펴보았다.

개념적으로 살펴본 것이기 때문에 바로 직접 시험해 보기에는 다소 설명의
부족이 보이는 것 같아 안타까운 생각이 든다. 다음에 기회가 된다면 더욱
상세히 설명을 할 것을 약속하면서 이만 MIDAS에 대한 개략적인 내용은
줄일까 한다.

2009년 글

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

프론트오피스, 백오피스, 프론트엔드, 백엔드  (0) 2020.06.22
디버깅의 6단계  (0) 2020.06.16
MIDAS에 관하여  (0) 2020.05.03
Data Integrity(데이터 무결성) 에 관하여  (0) 2020.04.12
마크다운(markdown) 알아보자.  (0) 2020.04.02
About Angular 9 Release  (0) 2020.01.22
Posted by 사용자 SB패밀리

댓글을 달아 주세요

● Data Integrity(데이터 무결성)
1) 데이터 무결성을 지키기 위한 종류와 방법
- 실체(Entity) 무결성
a. 중복된 데이터 방지
b. Primary key, Unique

- 영역(Domain) 무결성
a. 범위 -> 내가 정해놓은 범위의 데이터만 사용될 수 있게 방지
b. Check

- 참조(Refereance) 무결성
a. 참조 -> 참조 당하는 테이블을(부모테이블) , 참조 하려는 테이블을(자식테이블)
데이터 값이 맞는지 다른테이블에 확인할 때 참조한다.
b. Foreign Key

Constraint(제약) : Primary key, Unique, Check, Foreign key
-> 잘못된 데이터가 들어올때 제약을 걸어주는 역할을 한다.

2) 컬럼의 속성
- NN(Not Null) 속성 : Null값을 거부할수있는 속성을 가짐
a. Primary key = not null + unique가 합쳐진 기능
b. not null
- ND(Not Duplicate) 속성 : 중복된 값을 거부할수 있는 속성을 가짐
a. Primary key
b. Unique
- NC(No change) 속성 : 수정하는 것을 거부할수 있는 속성을 가짐
a. foreign key

 

 

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

디버깅의 6단계  (0) 2020.06.16
MIDAS에 관하여  (0) 2020.05.03
Data Integrity(데이터 무결성) 에 관하여  (0) 2020.04.12
마크다운(markdown) 알아보자.  (0) 2020.04.02
About Angular 9 Release  (0) 2020.01.22
IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
Posted by 사용자 SB패밀리

댓글을 달아 주세요

마크다운(markdown) 설명과 예제가 간단하게 잘 되어 있는 사이트

https://bj25.tistory.com/10?category=836194

Markdown은 일반 텍스트 문서의 양식을 편집하는 문법으로서 존그루버에 의해 2004년에 만들어졌습니다. Markdown의 목표는 플레인 텍스트 포맷을 사용하여 사용자들이 보다 쉽고 편리하게 텍스트 문서를 작성할 수 있도록하고, XHTML 이나 HTML로 선택적 변환이 가능하게 하는 것입니다. 대표적인 마크다운 문법으로 작성된 텍스트 문서는 Github의 README.md 파일입니다.

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

MIDAS에 관하여  (0) 2020.05.03
Data Integrity(데이터 무결성) 에 관하여  (0) 2020.04.12
마크다운(markdown) 알아보자.  (0) 2020.04.02
About Angular 9 Release  (0) 2020.01.22
IntelliJ Golang 연동할 때 에러  (0) 2020.01.17
프로젝트 3요소  (0) 2020.01.15
Posted by 사용자 SB패밀리

댓글을 달아 주세요

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-개발' 카테고리의 다른 글

Data Integrity(데이터 무결성) 에 관하여  (0) 2020.04.12
마크다운(markdown) 알아보자.  (0) 2020.04.02
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
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-개발' 카테고리의 다른 글

마크다운(markdown) 알아보자.  (0) 2020.04.02
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
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패밀리

댓글을 달아 주세요