천객만래 [千客萬來] (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패밀리

댓글을 달아 주세요

흥부전

 

고전소설은 무엇보다 시대상황을 적극반영하고 있다

소설은 역사적상황을 배경으로 하면서 적극적인 맛을 풍기기 위하여 비현실적인 내용을 가미시킨다

우리들이 알고있는 전래소설등은 실존한 인물은 아니나 그렇다고 전혀 허황한 인물이 아니다

 대부분 그시대상황에 있음직한 인물이거나 저자주변에서 활동했던 인물 또는 저자가 희구하던 인물인 경우가 많다

역사적인 상황을 축소판 처름 반영하고 있는 인물인것이다 "흥부전"은 부자형과 가난뱅이동생의 이야기이다

같은 형제이면서 성격이나 자식의 숫자등에 너무나 차이가 나는 케릭트이다

이처름 형제를 대비시켜 마음씨착한 사람은 결국 큰복을 받는다는 전통시대소설에 흔한 소제이다

흥부와 놀부가 한형제이면서 엄청난 경제력의 차이가 기본적원인은 바로 놀부는 장손으로 선영의 제사를

모시기때문에 호의호식하고 잘사는것이다

아들이나 딸중에 당연히 아들이 우선이요 아들중에서도 장자가 집안의종손으로 조상의 제사를 모시므로

최대한 대접을 해야한다는 전통적 가부장제사회와 이에 따르는 재산상속상의 차별 이것이 "흥부전"을 풀어보는 주요한 열쇠가 된다 고려시대나 조선전기까지는 장남 차남 그리고 딸까지도 차별되지 않았다

 조선전기인 15세기경에 완비된 "경국대전"의 재산분배와 재산상속때 본처소생인 장남에서 혼인한 딸까지 모두 똑같이 분급하도록하고 있으며 집안의 가계를 잇는 사람에게 1/5을 더 주도록 명시하고있다

 아들딸 구별없이 똑같이 분배했던 사회분위기속에서 흥부와 놀부처름 출생에서 이미 엄청난 경제력의

 차이가 나타나는 경우는 거의없었을것이다

그러나 조선후기 주자성리학이념이 강하게 정착되고 임진왜란과 병자호란같은 큰변란을 겪게 되면서

혈연공동체의식이 보다 강화되고 남자중심의 가족제도가 확산되었다

17세기에 작성된 "분재기"에는 딸의 상속재산은 1/3로 줄어들었는데 이유는 봉양과 제사가 재산상속의 주요한 기준으로

자리를 잡은것이다 흥부아내의 넋두리에서 보듯 "어떤사람은 팔자좋아 장손으로 태어나서 선영제사 모신다고 호의호식 잘 사는데 누구는 이리버둥대도 살기가 어려울까 차라리 나가서 콱 죽고싶소" 바로 장자중심 사회의 대표주자 놀부가 있게된다

조선후기에 부계중심의 혈통만 강조되었고 그중에서도 장자는 대가족구성원의 대표자로 우월적지위를 보장받게되었다

이러한 조선후기 가족제도의 변화라는 시대적상황에서 잘사는 형과 못사는 동생이 다수 탄생하게되며 이러한 사회상을 풍자와 해학을 이야기로 담아 형의 욕심과 동생의 순박함을 과장되게 대비시킨것이 "흥부전"의 형태로 나타났다고 볼수있다

 장자상속이라는 가족제도 상속제도의 변화와 함께 "흥부전"에서는 조선후기 사회경제적 변화상이 아주 사실적으로 반영되어있다

17세기이후 조선사회는 농업생산이 발달하고 상품경제가 확대되며 부익부 빈익빈 현상이 심화되어 나갔다

가난한 농민의 대표가 흥부라면 이러한 사회변동속에서 급부상한 신흥부자인 대표는 놀부라고 할수있다

 "흥부전"은 부자놀부와 가난뱅이흥부를 대비시켜 조선후기 사회경제적변화에따라 나타나는 빈부의 차이를 잘 묘사하고 있다 농업생산력의 증가 이에 따른 상업의 발달등으로 농민중에서도 부유한 농민이 나타나는가하면 자신의 경작지마저 잃고

임노동자로 전락하는 빈농층도 대량으로 나타났다 흥부는 바로 이러한 빈농으로서 임노동자로 전락하는 농민들을 대표하기도한다 특히 흥부가 부인에게 "우리 부부 품이나 팔러갑시다"라고한 대목은 자신의 날품을 팔수밖에 없는 어려운 농민들의 처지가 반영되었다 "흥부전의 하이라이트는 박을타는 장면으로 흥부의 박에서 쏟아져나오는 갖가지 귀중품과 풍성한 곡식괴 의복등은 당시 농민들이 가장 원했던것이 무엇인지 잘보여주고있다

더욱 박속에서 "동몽선습" "맹저""통감"등 책이 나오는 사실도 주목해보면 농민들이 공부를해서 신분상승을 추구하는 모습이 은근히 소설에 반영된것은 현대를 사는 우리들과도 같은 추구이리라

 한권의 전래소설로만 읽어온"흥부전"의 시대적 배경을 살펴볼 기회가 있어 간추려 본다

Posted by 사용자 SB패밀리

댓글을 달아 주세요

2003 SICAF 개막쇼



서울 국제만화 페스티벌(SICAF) 축하무대
 

 

 

 

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패밀리

댓글을 달아 주세요

군밤이 먹고 싶다면
가정에 있는 에어프라이어를 이용하거나
거리의 노점에서 사 드시면 됩니다.

집에서 구워 먹으면 원하는 만큼 굽고
거 큰 밤을 드실 수 있습니다.

어때요. 맛있어 보이나요?

Posted by 사용자 SB패밀리

댓글을 달아 주세요

이거 난데

카테고리 없음 2020. 1. 13. 02:14

이거 나야 나

넷플릭스
드물고 희귀한 책임감 있는 사람

Posted by 사용자 SB패밀리

댓글을 달아 주세요

필리핀 화산폭발

관관 등으로 현지에 계신 분들은 각별히 안던에 심경쓰시고 한국에 계신 가족 친지 분들도 서로 연락을 취해서 사상자가 없으시길 바랍니다.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

2020년 전기차보조금

2019년 전기차보조금, 2018년 전기차 보조금의 지급 추세를 살펴보면

꾸준히 전기차 보조금은 감소하는 추세이다.

 

전기차 활성화를 위한 예산이 줄어든다고 보면 된다.

반면에 수소차에 대한 보조금은 늘어났다.

 

2020년 중동 정세와 유가 상승에 따른 전기차에 대한 수요는 점차 늘어날 수 밖에 없다.

 

그럼, 환경부에서 알려주는 전기차 보조금은 얼마일까?

 

우선 보조금의 종류는 정부지원 국고보조금과 지자체 보조금 2종류로 나뉜다.

 

국고보조금은 얼마인지 살펴보자.

 

 

지자체 보조금도 알아보자.

2020년 지자체 보조금 예산이 확정이 되면 바로 알아보자.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

나쁜 피는 빼야 한다? 

일상생활에서 건강에 관련된 언급 중에 꽤 흔하게 듣는 이야기 중의 하나가 바로 나쁜 피, 즉 죽은 피는 빼버려야 좋다는 것입니다. 이 이야기의 근거는 의학지식으로는 잘 설명이 되지 않습니다. 피의 색깔에 따라 좋은 피, 나쁜 피를 구분하는 경우도 있는데 이는 더욱더 근거가 없습니다.

고여 있는 피도 나름대로의 역할을 한다

일반적으로 몸 안의 피는 계속 혈관을 따라 순환 하면서 산소 및 영양공급, 노폐물 제거 등 생명 유지의 핵심적 기능을 담당합니다. 따라서 주로 외상 등에 의한 모세혈관 등의 파열에 의해 특정 국소부위에 피가 고일 때, 이 피는 제 고유의 기능을 상실했다고 할 수 있습니다. 보통 이렇게 고여있는 피를 나쁜 피라고 지칭하는데, 이렇게 순환하지 않고 고여 있는 핏덩어리(의학적으로 혈종이라고 부른다)는 우리 몸에 해로운 것일까?

극히 예외적인 경우를 제외하고는 나름대로의 역할이 있습니다. 먼저 파열된 혈관을 막아 폐쇄시킴으로써 지혈작용을 하는 것입니다. 다음으로 손상된 조직을 재생하는 기질로서의 기능을 수행하며, 이후에 남는 영양소 등은 자라 들어오는 혈관을 따라 대식세포 등의 염증세포들이 모두 흡수하여 체내에서 재활용하게 됩니다. 멍든 부위(피하출혈)의 색깔이 시간이 경과함에 따라 차츰 엷어지는 것은 이런 흡수과정을 거치기 때문입니다. 

정형외과에서 골절이 있는 부위에 생기는 혈종은 골유합에 중요한 역할을 담당합니다. 골절 부위 혈종의 기질화가 골절 치유의 첫 단계이며, 혈종 내에 생긴 섬유소 골격에 복원세포들을 받아들이면서 세포이동, 증식 등이 활동이 시작되는 것입니다. 흔하게 골절 불유합의 원인이 되는 개방성 골절은 이러한 혈종이 상처를 통해 외부로 유출되어 버리기 때문에 골유합에 지장을 주는 것입니다. 

고여있는 피는 근막증후군을 일으키기도 한다

예외적으로 이러한 혈종이 악영향을 미치는 경우도 있는데, 대표적인 경우가 근막증후군 입니다. 이는 골절이나 혈관 손상 등에 의해 과도하게 혈종이 형성되어 특정 구획 내의 조직내압을 과도하게 상승시켜 발생하는데, 정형외과 응급질환으로 몇 시간 내에 조직내압을 감소시키지 않으면 근육괴사로 사지를 잃는 경우가 생깁니다. 이럴 때 고인 피는 어떤 의미로 나쁜 피라고 할 수 있는데, 이 경우에도 피자체의 성질이 나빠서가 아니라 너무 많은 양에 의한 기계적인 압력 때문입니다. 

초기 타박상엔 얼음찜질이 효과적

일상생활 속에서 외상 등에 의한 손상을 받을 때 연부조직이 붓고 출혈이 생기는 경우가 있습니다. 이 때 단순한 타박상인지, 골, 인대, 혈관 등의 다른 손상이 있는지 감별을 해야 하며, 초기에 진단을 못하게 되면 치료가 훨씬 힘들어지는 수가 많습니다. 단순한 타박상인 경우, 손상 후 약 2일간은 얼음을 넣은 비닐주머니 등으로 수회에 걸쳐 20~30분간 찬 찜질을 하면 지혈이나 종창을 줄이는데 도움이 되며, 그 이후로는 뜨거운 찜질이 좋습니다. 

따라서 보통의 경우, 혈종이 우리 몸에 해로운 경우는 없다고 할 수 있습니다. 또 피의 색깔에 따라 좋은 피, 나쁜 피를 구분하는 경우도 있는데 이는 더욱더 근거가 없습니다. 같은 피가 함유하는 물질이나 순환경로에 따라 색깔은 얼마든지 달라질 수가 있기 때문입니다. 즉, 나쁜 피가 폐를 거쳐 좋은 피가 되어 심장의 박동에 따라 전신으로 순환하는 것입니다. 


인제대학교 상계백병원 정형외과 

김동수 교수

Posted by 사용자 SB패밀리

댓글을 달아 주세요

콧등에 파스를 바르면 비염에 좋다? 


콧물이 나올 때 콧등에 파스를 붙이면 콧물이 멈춘다고 하는 것은 잘못된 상식입니다. 콧물의 원인을 잘 가려내어 그 질환에 적합한 치료를 받아야 합니다. 

최근 인터넷의 각종 건강상담 코너를 보면 여러 가지 건강상식과 나름대로의 비방에 대해 많은 것들이 등록되어 있습니다. 그 중에서 최근 콧물이 나는 경우 콧등에 파스를 붙여 콧물을 줄이는 것이 하나의 민간요법으로 소개되어 있습니다. 여러 인터넷 건강 사이트의 건강상식코너에서 읽고 꽤 의아하게 생각하던 중 외래로 방문하는 환자들의 질문이 증가되어 파스에 대해 다시 한번 생각해 보게 되었습니다.

전 세계적으로 널리 처방되는 소염진통제에 환자들이 소화불량과 헛배가 부르는 등의 소화기계통의 부작용을 호소하고 주사제제나 경구제제에 대한 불편함과 거부감을 나타내자, 보다 전신적인 부작용을 줄이고 좀더 편하게 직접적으로 환부에 약물을 투여하고자 개발된 것이 최초의 패취타입의 제제라 할 수 있습니다. 이후 소염진통제제 뿐만 아니라, 지속적인 약성분의 공급을 위해 멀미약, 진통제 등 여러 분야에 널리 쓰이고 있습니다. 특히 우리나라에서는 민간요법과 한방 등에서 여러 약제를 이용, 다양한 피부표면 부착방법이 널리 이용되고 있습니다. 먹는 약이나 주사제제에 대한 거부감이 있던 환자들도 붙이는 패취형 제제에 대해서는 큰 부담없이 널리 사용하고 있습니다. 



파스의 멘톨성분의 자극으로 시원하게 느껴지는 것일 뿐이다



흔히 사용되는 패취형의 파스류는 대개가 소염진통 효과를 가진 약물과, 시원한 느낌을 주기 위한 성분, 잘 떨어지지 않게 하는 접착제의 성분이 포함되어 있습니다. 환자들이 파스를 붙일 때 시원하게 느끼는 것은 그 소염 효과가 빨라서라기 보다는 시원하게 느낄 수 있는 성분이 포함되어 있기 때문입니다. 



파스류에 포함된 멘톨 성분이 코의 점막에 있는 추위를 감지하는 신경말단을 자극하여 실제적인 효과없이 시원한 느낌을 줍니다. 실제로 콧속의 공기가 잘 통하게 된 것이 아님에도 환자는 코가 시원하게 된 것으로 느끼게 되는 것입니다. 

적절한 진단없이 파스를 붙이는 것은 약물 오남용이다

이러한 시도와 구전되는 효과를 잘 살펴보면 좀 신중해야 할 점이 있습니다. 실제 염증을 줄이고 시원한 느낌을 주는 효과는 파스에 포함된 소염진통제에 의해 어느 정도 가능성은 있다고 할 수 있겠으나, 콧물이 나오는 경우 그 원인에 대한 적절한 진단없이 그냥 파스를 붙이는 것은 또 하나의 약물 오남용의 사례가 될 수 있습니다. 

증상에 대한 정확한 검사가 필요하다

콧물 증세가 있는 경우, 우선 콧물의 특성에 대해 자세히 조사해야 합니다. 콧물이 찐득찐득한지, 물과 같이 맑은지, 누렇거나 퍼렇지는 않은지, 피가 섞여있지는 않은지 확인하고, 그 빈도와 주로 출현하는 시간 등에 대한 조사가 필요합니다. 환경이 바뀌지는 않았는지, 특이한 냄새가 나거나 다른 냄새를 잘 맡는지에 대한 것도 알아야 합니다.

이를 바탕으로 전문의와의 상담에 코 내부검사를 통해 알레르기성 비염에 합당하다면 알레르기 검사가 필요합니다. 축농증이나 콧속의 염증, 양성 또는 악성 종양에 의한 것인지 자세한 검사와 각종 엑스레이 검사가 필요합니다. 


인제대학교 상계백병원 이비인후과 

윤자복 교수 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

신발속 숯 넣으면 발냄새 없애

한여름 낮에 바깥을 돌아다니다가 들어와서 신발을 벗어 놓으면 향기롭지 못한 냄새가 나는 경우가 많다. 이럴 때 숯을 사용하면 좋다.

숯은 악취를 없애주는 천연 탈취제이며 동시에 세균 번식을 억제하는 기능까지 갖고 있어 신발 속에 넣어두면 발냄새가 말끔히 없어지게 된다. 신발장 속에 숯을 넣어두어도 퀴퀴한 냄새가 없어지는 효과를 볼 수 있다. 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

아웃백(OutBack)이란?

 

1980년대말, 미국에서 크로커다일 던디 영화가 히트하여 호주붐이 일어났고, 미국인들에게 호주가 동경의 대상이 되었습니다. 

이에 호주 컨셉의 레스토랑을 만들게 되었고, 이름을 가장 호주스럽고 풍성한 대자연의 느낌이 살아나는 "아웃백"이라 정하게 되었습니다. 



OUTBACK이란 호주식 영어로 ‘오지(奧地)’ 란 뜻으로 캥거루, 부메랑, 코알라 등 호주의 야생 자연을 레스토랑 인테리어의 배경으로 하는 편안하고 목가적인 분위기의 정통 스테이크하우스입니다. 세계적인 경제 전문지가 리서치하는 레스토랑 고객 만족도에서 매년 “미국 최고의 레스토랑”으로 선정되는 OUTBACK STEAKHOUSE는 푸짐한 양과 신선하고 풍부한 맛을 통해 매일 새로운 감동을 창조하고자 합니다.



아웃백은 스테이크 전문 식당으로 기존 패밀리 레스토랑보다 한 단계 높은 차별화된 음식과 서비스를 제공하는 디너하우스로 10여 가지의 스테이크 외에 30여 가지의 다양한 메뉴를 제공하고 있습니다. 



OUTBACK STEAKHOUSE에서 제공되는 모든 스테이크는 곡물(grain)을 먹여 사육한 호주산 최상급 쇠고기를 사용하며, 아웃백 고유의 양념을 가미하여 그릴에 단시간 굽기 때문에 연하고 두툼하며 육즙이 많은 정통 스테이크의 참 맛을 즐길 수 있습니다. 







역사



OUTBACK STEAKHOUSE는 1987년 설립되어, 1988년 플로리다 템파시에 첫 레스토랑을 개점한 이후2002년 현재 820여개의 레스토랑과 총 매출 4조 5천억원을 달성하는 등 많은 레스토랑 특히 디너 하우스 부분에서 두각을 드러내고 있습니다. 



국내에는 aussie chung ltd. 를 통해 97년 4월말 공항점 1호점을 개점하고 강남점, 홍대점, 청담점, 삼성점, 종로점, 중계점, 양재점, 천호점, 부산해운대점, 목동점, 대구황금점, 부산 남포점, 부산 서면점, 일산점, 대구 동성로점, 명동점, 수원 권선점, 신촌점, 대구 죽전점, 분당 서현점, 울산 삼산점,사당점,이태원점, 둔산점, 충무로점, 분당미금점, 부천상동점,광주상무점, 부산 남천점 , 안산 고잔점 , 인천 구월점, 여의도점, 영등포점, 메트로점, 창원중앙점, 광주충장로점, 수원역사점, 태평로점 등 현재 39개의 영업점을 운영중에 있습니다.





1998년과 2000년,2001년 그리고 2002년 프랜차이저상을 4년 연속 수상하여

내/외적으로 충실히 성장하고 있습니다. 

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패밀리

댓글을 달아 주세요

 신용관리 10계명


1 주거래 은행을 만들어라!  

 주거래 은행이란 자신이 제일 많이 이용하는 은행을 말하는 것입니다. 주거래 은행에 거래를 집중해서 거래실적을 많이 쌓는 것이 좋습니다. 왜냐하면 고객의 신용을 평가할 때 해당 은행과의 거래실적이 중요하게 반영되기 때문입니다. 그러므로 카드대금결제, 공과금이체, 통신대금납부, 월급이체 등 금융거래를 한 은행에 집중/관리하는 것이 좋습니다. 



2 조회처 정보 발생을 줄여라! 

 금융회사의 CSS(Credit Scoring System)에서는 개인의 신용을 평가할 때, 조회처 정보가 반영되기 때문에 조회처 정보가 많으면 대출이나 카드발급이 거절될 수 있습니다. 

조회처 정보가 많아 신용점수가 떨어지는 이유는, 조회처정보가 갑자기 늘어난 사람의 경우 채권상환 등의 금융거래에 많은 문제가 발생했다는 통계적 결과치가 나타나기 때문입니다. 

즉, 단기간 안에 여러 금융회사를 돌아다니면서 대출을 받거나 카드를 발급받아 현금서비스를 이용하여 자취를 감추거나 이민을 가는 사례가 많아 금융회사의 피해가 많이 발생하기 떄문입니다.



따라서 단순히 대출가능여부가 궁금하여 여러 금융회사 홈페이지를 통해 대출을 신청하게 되면 조회처 정보가 늘어나 추후에 실질적인 대출을 받고자 할 때 조회처정보 과다로 불이익을 받을 수 있으므로 필요 없는 대출신청이나 카드발급신청을 해서 조회처정보를 늘리는 것은 바람직하지 못합니다.   크레딧뱅크에서는 이러한 문제점을 해결하기 위해, 은행에서 운영하는 CSS와 유사한 일반 CSS 서비스를 회원들에게 제공하고 있으니 이를 활용하여, 대출을 신청하기 전, 자신의 신용에 의해 어느정도의 대출금리와 대출금이 결정될지를 가능해보는 것이 필요합니다. 

그 이유는 자기 스스로가 본인의 신용정보를 조회하거나 당사의 일반 CSS 서비스를 무한정 이용해도 조회처정보에 전혀 남지 않기 떄문입니다.

 

3 내게 맞는 카드는 한장만 사용하라! 

 본인에게 혜택이 많이 주어지는 카드를 하나 선택하여 집중하여 사용하는 게 좋습니다. 

거래실적이 좋아 해당 카드사로부터 우량고객으로 평가 받게 되면, 보다 낮은 금리나 유리한 조건으로 대출이 가능하고 대출한도가 증가하는 등 다양한 이점을 누릴 수 있습니다. 

또한 관리가 용이하여 분실, 연체, 대금결제관리가 훨씬 간편해집니다. 



4 카드 대금을 연체하지 말자! 

 연체금액이 적거나 혹은 연체기간이 단 하루라도 개인의 신용은 저하됩니다.

이러한 연체정보는 카드사간에 공유하기 때문에 해당 연체가드의 사용이 정지되면 다른 카드의 사용도 제한받게 됩니다. 또한 연체를 자주하면 신용점수가 낮아져 대출한도가 줄어들거나 재발급이 어려울 수 있습니다. 
 

5 대출금의 만기일을 체크하라! 

 채무를 3개월 이상 연체하면 신용불량자로 등록되어 추가로 신용대출 받기가 어렵습니다.

그러므로 가능하면 연체를 발생시키지 않아야 하고 발생시키더라도 3개월이 넘으면 안 됩니다. 



6 보증시 대출한도, 기간등을 체크하라. 그리고 무분별한 보증은 금물! 

 최근 신용정보에는 보증인정보가 추가되어 금융회사에서도 보증선 내역을 조회할 수 있습니다.

신용거래정보, 불량정보, 조회처정보가 각각의 의미를 가지고 개인의 신용을 평가하는데 중요한 자료로 활용되듯이 앞으로 보증인 정보도 매우 중요하게 고려됩니다.   즉, 보증 선 금액만큼 본인의 신용대출한도가 감소하게 됩니다. 따라서 무분별한 보증은 자제해야 하며, 이미 보증을 섰다면 보증 기간을 체크해 두었다가 기간 만료시 본인 허락 없이 연장되지 않도록 관리해야 합니다. 



7 카드의 현금서비스 이용대금을 미리 갚을 능력이 있다면 선결제를 활용하라! 

 카드대금 연체중이거나 현금서비스를 받았다면 결제일까지 기다리지 말고 미리 결제 혹은 변제하게 되면 그만큼 이자가 감소하게 되고 연체기간도 줄어들게 됩니다. 


8 자동이체를 이용하라! 

 자동이체를 이용하면 자신의 부주의에 의해서 발생할 수 있는 연체를 방지할 수 있습니다. 또한 거래 은행의 경우, 자동이체 고객을 선호하므로 개인 신용을 높이는데 도움이 됩니다. 하지만 자동이체만 믿고 있다가 연체될 수 있으므로 통장잔액을 자주 확인해야 합니다. 


9 영수증을 반드시 보관하라! 

 물품 구입, 연체금 상환 등 후에는 영수증을 꼭 보관해 두어야 합니다. 신용거래취소, 물품 반환, 이중청구시 거래를 입증자료로 활용할 수 있으며 또한 연체금을 상환하였는데 해당 업체의 실수로 미결제로 처리되어 불량정보가 해제되지 않는 경우도 있는데 영수증은 이때 상환을 증명할 수 있는 자료가 됩니다.  



10 변경된 주소는 반드시 통보하라!  

 주소지가 변경되면 은행, 이동통신 등 대금결제 중인 해당 회사에 변경된 주소를 반드시 통보해야 합니다. 나중에 주소변경으로 연락이 되지 않으며, 대금결제 미해결로 연체자 및 신용불량자가 될수 있기 때문입니다. 

 


<출처: 삼성카드사>

Posted by 사용자 SB패밀리

댓글을 달아 주세요

자격증 vs 면허증

 

자격증은 사람이나 사물이 일정한 특성을 지니고 있음을 공식적으로 인정하거나 보장받는 것으로 등록이나 면허와는 차이가 있다. 특히 전문직의 법적 자격증은 그 자격증을 지닌 사람이 특정한 수준의 지식과 기술을 보유하고 있음을 보증하는 것으로 특별한 제한을 두고 있다.

 

면허증이 있는 분야의 경우, 없는 사람은 법적으로 그 일을 할 수 없으나, 자격증의 경우 그것이 없다고 해도 반드시 그 일을 법적으로 못한다는 것은 아니다. 일부의 경우 자격증 취득 후 해당 자격증에 따른 면허증을 별도로 발급받아야 업무 수행이 가능한 경우도 있다.

 

자격증은 거의 무자격자가 특정한 행위를 못하도록 제한하지는 않지만, 면허(license)는 제한을 가한다. 자격증은 흔히 등록(registration)보다는 통제가 강력하지만, 면허보다는 약한 것으로 인식되고 있다. 하지만 ‘자격이 있다’는 타이틀을 사용하지 못하게 법으로 제한을 한다. 전문가의 자격은 전문협회가 만들어져 자격에 필요한 정보나 인적교류를 하고 있다. 회비로 운영되며 회원들의 자격과 위상을 보증해 주고 있다.

 

 

 

면허

행정 기관이 어떤 사람에게 특정한 일이나 영업을 할 수 있도록 허가하는 문서

 

운전은 어디서 하든 면허 없이 하면 처벌받는다. 보건의료행위도 면허 없이, 누구에게 하든 면허가 없으면 처벌받는다. 원칙적으로 자기 스스로에게도 불법이다.

 

자격

각 분야에서 일정한 능력을 갖춘 사람에게 그 능력을 인정해 주는 증명서

 

자격증의 종류에는 크게 국가에서 발급하는 것과 민간에서 발급하는 것이 있으며, 국가에서 인정하는 자격으로 국가기술자격, 국가전문자격이 있으며 민간에서 발급하는 것은 민간자격증이라고 한다.

 

 

또, 대부분 국가에서 직접 실시하는 건 아니지만 민간업체, 혹은 공기업에서 실시하는 자격으로 법적으로 공인된 면허로 정부가 해당 면허에 대해 배타적인 권리를 부여했기 때문에 사실상 준한다고 해도 면허나 마찬가지이다. 예컨대 사서가 아닌 사람은 도서관 사서가 될 수 없고 변리사가 아니면 특허를 등록할 수 없으며 세무사가 아니면 기장대리를 할 수 없다.

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

부부관계 개선 방법

내가 사랑하는 사람이니깐 하면서 먼저 댓가없이 해주면 분위기가 현재의 딜레마를 깨서 한단계 업그레이드 됩니다. 근데 보통 이걸 못하죠 왜냐면 지 자존심과 지가 상대에게 먼저 해주는걸 싫어하고 댓가까지 바라거든요. 그래서 보편적인 초보부부들 삶이 딱 님네 집안과 같은 겁니다. 

그래서 남자 입장에선 "그래도 저 여자가 나 믿고 나한테 시집왔는데 내가 품어줘야지!" 라고 여자를 이끌어야 되고 여자는 "저 남자가 내가 뭐 그리 대단하다고 저렇게 나가서 돈 벌고 본인 자유 다 버리고 고생을 할까 밥이라도 잘 차려줘야지"라는 식으로 서로 접근을 해야 이게 시너지 효과가 팍!하면서 오르는 겁니다. 

대부분 부부사이가 안 좋은 집안 가보면 항상 시작과 과정이 똑 같습니다. 해주면 서로 손해보고 있다는 입장이거든요. 그러니 상대방보면 짜증부터 나는겁니다. 근데 부부사이가 좋은 집안가보면 뭐든지 자발적 입니다. 오히려 쉬라고 할정도로 내가 한다고 앞장서는 집안이지요. 
이러니 서로 신뢰가 쌓이고 서로 잘 할려고 하는 겁니다. 신뢰라는 건 이렇게 쌓이는 겁니다. 서로 잘 해 줄려고 하니 더 잘해 주고 싶은 겁니다.

근데 요즘(옛날옛적부터) 젊은 부부들 보면 대부분 자존심 싸움 뿐이에요. 누가 그러더군요. 

"사랑은 누구나 할 수 있다. 하지만 유지하는 건 아무도 가르쳐 주지 않는다."

이 글은 굉장히 심오하고 굉장한 해결사 노릇하는 키 역할을 하고 있는 내용입니다.

쉽게 읽고 넘기지 마시길.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

귀여울때 깨물고 싶은 이유 





Q:귀여우면 왜 깨물어주고 싶을까요? 

  

A:동물의 본능적인 행동이다. 인간이 동물로서 하는 본능적인 행동에는 여러가지가 있다.

 예를 들어 식사, 잠 등과 같은 것이다. 

귀여워 깨물거나 안아주고 싶은 것은 인간의 호르몬 분비에 의한 기본적인 본능이 

최대한 절제된 상태로 표출되는 것이라고 할 수 있다. 

특히 깨물어주고 싶다는 표현은 먹는 본능과 관련지어 나타난다.

 주위의 애완동물이 자식을 핥는 행동을 보이는 것과 비슷한 현상이다. 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

만리장성 실제론 6750리 
 

Q : 만리장성은 실제로 만리일까요? 

 

출처 : 사진 상단에 표시



A : 시작하는 부분부터 끝나는 부분의 길이만 따진다면 2,700㎞로 6,750리가 된다. 그러나 만리장성은 시작부터 끝까지 한줄로 돼 있지 않다. 중간중간에 짧게 가지를 쳐 나가는 부분이 있다. 이 부분까지 다 계산한다면 6,400㎞가 돼 1만6,000리가 된다. 어떤 기준에 따르는가에 따라 실제 길이는 차이가 날 수 있다. 



<야후!코리아 지식검색팀> 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

[속보]조국 구속영장 기각.."구속 필요성 인정 안돼"

 

2019.12.27.01:00

권 부장판사는



"이 사건 범죄 혐의는 소명된다. 현 시점에서 증거를 인멸할 염려 있다고 보기 어렵다. 이 사건 범행은 그 죄질이 좋지 않으나, 구속 전 피의자 심문 당시 피의자의 진술 내용과 태도, 피의자의 배우자가 최근 다른 사건으로 구속되어 재판을 받고 있는 점 등과 피의자를 구속하여야 할 정도로 범죄의 중대성이 인정된다고 보기는 어려운 점, 피의자의 주거가 일정한 점 등을 종합해보면 도망할 염려가 있다고 볼 수도 없다"

Posted by 사용자 SB패밀리

댓글을 달아 주세요