2015년 1월 3일 토요일

프리랜서 계약시 확인 해야 할 것들


데브페이 에서 좋은글이 있어 퍼왔습니다. 좋은글 감사합니다.
http://devpay.org/home/bbs/board.php?bo_table=B16&wr_id=61

출처 : okjsp
글쓴이 : 성냥
 
제목이 좀 거창하게 나가버렸네요;;;
 
오늘 주말 강의가 시험전이라 풀 자습이라...
 
두번째 프리랜서 프로젝트를 구하면서 정리해보았습니다.
저 역시, 이곳 옥히 선배님들께서 올려주시는 의견등을 참고하고 구직하였습니다.
 
경력도 짧고(이제 겨우 3년차입니다), 아직 모르는것 투성이지만,
 
정직에서 프리로 전환을 생각하시는분들이나,
새 프리자리를 구하기가 막연하게 어려운 저와 같은 
초급 개발자분들께서 함께 고민해보면 좋을것 같아 올려봅니다.
 

1. 한달 정도는 구직하겠다 생각하고 미리미리 준비하자.
 
- 저는 첫 프리 프로젝트 구할때도 거의 3주 정도 걸렸습니다.
 사람을 구하는 곳은 굉장히 많지만,
 자기가 원하는 프로젝트 찾기는 쉽지는 않은것 같습니다.
 여유있게 한달정도는 잡는게 좋은것 같습니다.
 미리 갑측에 상의를 해두어 면접볼 일이 있다는 것을 
 상기시켜주는것도 괜찮은것 같습니다.
 
 요번에 프리 구하면서 가장 중요시했던것들은
 
 1) 출퇴근 거리
 2) 업무 환경 (개발자가 무시당하지 않고, 개발에만 열중할수 있는)
 3) 배우고 싶은 (배울만한 것이 있는, 내가 얻어갈만한것이 있는) 프로젝트
 4) 급여 및 개발자 처우
 (순위가 아니라 가장 중요시했던 4가지 입니다 ㅎ)
 
 이걸 다 맞추려고 하다보니, 시간이 꽤 걸리더라구요.
 요번에 한달동안 면접만 20번을 넘게 보았습니다.
 결국 최종적으로 '아 여기 가야겠다' 라고 느껴지는 프로젝트를 찾은건
 정말 한달 동안 구직한 시기의 막바지 였습니다.
 

2. 회사에 대해 가능하면 세심하게 살펴보자.
 
  요건 늘 선배님들께서도 말씀해주시는 부분인데요.
  제 경우도 초급이지만 일단 잡한국 이나 people인에 
  프리랜서 구직희망 이력서를 오픈하면 하루에 메일이나 전화가 몇통씩 옵니다.
  이때 반드시 계약할 회사명을 알아둡니다.
  그후에
 
  1) 잡한국, people인에서 업체명을 검색
   - 사람이 너무 적거나, 자본금이 너무 적으면 패스
   (정직 50명에 자본금 15억인데도 있고, 정직 30~40 에 자본금 3천도 있더라구요)
  
  2) 일터Q&A 및 Java서비스넷 채용정보 등을 적극 활용
   - 의외로 연락오는 업체중 악덕업체로 이름난 업체들이 버젓히
    영업하고 있는곳 많습니다. 잘 찾아서 피해가야할것 같습니다.
   - 임금 체불, 급여일, 회사 분위기 등등 많은것을 세심하게 찾아봐야합니다.
   - 꼭 이전에 올라와있는 업체뿐만 아니라 직접 일터Q&A 같은곳에
    업체 어떤지, 프로젝트가 어떤지 질문글 올리면
    의외로 좋은 성과(?)를 얻을수도 있습니다.
    (XXX 거긴 원체 악평으로 소문난 곳이라 안가는게 좋습니다 같은 덧글등)
 
   3) 원청과 몇차 협렵업체인지 (을별정 그 이하인건지)
    - 프로젝트와 나 사이에 업체가 많이 낄수록
     급여 차이가 많이 나더라구요.
     어떤 SM 경우 동일한 프로젝트를 여러 업체에서 연락이 왔는데
     중간에 업체 몇개 끼었냐 따라 80만원 까지 차이었났습니다.
 

3. 연락이 오기만을 기다리지 말고 적극적으로 알아보자.
  이력서 오픈 하자마자 연락오는 곳들은 시원찮은 곳이 많습니다.
  당장 사람이 너무 급하기 때문에, 아니면 회사 돈 몇푼이 아쉽기 때문 등등
  이런 업체는 정말 이력서 오픈한지 1시간도 안되서 메일/전화 오는것 같습니다. (다는 아니겠지만;)
 
  진득허니 기다리고, 직접 알아보다가 좋은곳을 발견했을때
  오히려 제쪽에서 가고 싶은데 업체가 느긋한 곳도 많았습니다.
  그만큼 여유가 있는거겠죠. 보통 그런 업체는 회사규모도 있고 평도 괜찮고
  프로젝트도 조금 여유를 두고 진행하는것 같습니다.
  프로젝트 직접 따서 하는 중견 정도의 업체가 그런 경향이 있는것 같아요 (대기업은 아님;)
 
  그러니 이력서 오픈후, 연락 많이 온다고 뿌듯해하지 말고,
  직접 좋은 프로젝트를 찾는 노력도 있어야 할것 같습니다.
 

4. 계약이 성사될것 같을때 계약할 회사의 반응을 잘 살피자.
 
  실제 계약을 할 것 같은 분위기가 되었을때,
  계약할 회사에서 본심을 드러낼때가 꽤 있습니다.
  제 경우는,
 
  1) 단가를 깍으려고 함.
   - 가장 짜증나는 경우인데요.
     저는 그럼 애초에 얘기하셨던거랑 다르다며 안한다고 합니다.
     신뢰가 안 가게되는것이죠 이런 업체는...
 
    단가 후려치기의 진행이
    a) 처음 만족스러운 단가 제시
    b) 계약이 될 것 같으면 그정도는 어렵다고 깎을려고 함
      (이때 경력이 어떻고 학벌이 어떻고 얘기가 처음 나오죠)
    c) 실제 계약서 쓸때 다시 깎으려고 함
    d) 실제 급여줄때 더 깎음
 
    뭐 이런식으로 여러번에 걸쳐 조금씩 깎는다고 하던데
    저는 일단 b) 까지는 정말 굉장히 많이 겪었습니다.
    처음 제시한 금액 범위중 최소 수준에도 못미치는 금액으로 계약을 하려하면
    아예 안가는게 좋은것 같습니다.
    (저는 금액 깎아서 안간다고 하니 원래 불렀던거보다 50만원 이상 더 준다는 곳도 있더라구요)
 
  2) 계약서 쓸때가 되가니 반말을 하기 시작함
   - 저는 이게 굉장히 기분이 나쁘던데요.
    어쨌든 계약이라는 것이 상호 이익을 위해 하는것인데
    계약 할때즈음 되면 꼭 부하직원 부리듯이 내 덕에 니가 돈버는거인양
    말씀이 가벼워지기시작하는 업체가 있더군요
    (슬프지만 대다수가 그렇습니다)
   
   3) 근무 시간이 늘어남
    - 첨엔 9시 ~ 18시 근무였는데 오전이나 오후에 30분이 더 붙는다고 말하면
     저는 처음에 얘기한거랑 근무시간이 다르니 안한다고 합니다.
     이 부분 역시 금액처럼 신뢰에 문제인것 같습니다.
   대부분 저렇게 계약할때되서 태도 돌변하는 업체 치고
   개발자 대우해주는 업체 없는것 같습니다.
 

5. 급여 지급이 익월 말에 가까운 업체와는 계약하지 말자
 
 - 보통 이렇게 얘기합니다
  '회사 내규가 이러이러 저러저러 해서
   우리는 급여일이 이렇다 그러니까 당신도 이거에 따라야한다'
  
  그러면 저는 내가 당신네 회사 입사하는게 아니라
  회사 대 나(프리랜서)로 계약을 하는거니까 내가 당신네 회사 내규를 따를 필요는 없다.
  익월 5일내 지급 안되면 난 다른 프로젝트 알아보겠다 라고 합니다. 
  (이런식으로 하면 꼭 5일에 맞춰주더라구요 ㅎ 1일이나 2일에 맞춰주지...)
 
  애초에 익월 말일에 급여 지급이 말도 안되는 거고
  (알바를 해도 그렇게는 안 받죠)
  돈 나갈껀 최대한 늦게 나가야한다 라는 마인드를 가진 회사는
  나중에 돈 때문에 피곤해질 여지가 많은것 같습니다.
 

6. 금액은 자기가 생각하는 금액을 자신있게 부르고 협의할 수준도 안되면 과감히 버리자
 
 - 연락온 업체로부터 가장 자주 들은 말이
  '지금 얼마 받으시나요? 아니면 원하시는 금액이 있으신가요?'
  이렇게 많이 물어보십니다.
  용팔이 같더라구요. '얼마까지 알아보고 오셨어요?'
  그러면 저는 얼마까지 줄수 있는지를 되물어봅니다.
  (용팔이에게 '얼마까지 알아보고 오면 되는데요?' 라고 물었다던 유머처럼요)
 
  금액이 턱없이 적으면
  (저는 SM 270 부르는곳에서도 전화왔었습니다)
  지금 나는 얼마를 받고 있다. 근데 이 금액은 너무 적으니 난 못한다.
  (제 경우, 여기서 얼마를 받는다라고 말한 금액은 실제 제가 받고 있는 금액이 아니라
  제가 원하는 금액 액수이거나, 한 20만원 정도 더 올린 금액입니다).
 
  그러면 '아이구 많이 받으시네요' 하고는 
  우리는 그 정도는 못준다, 혹은 그럼 이정도는 어떻겠냐 하고 딜이 시작됩니다.
 
  먼저 자기가 금액을 낮춰부르면 업체는 신나합니다. 
  마치 아량을 배풀듯 그 금액에 맞춰주겠다고 하지요.
  애초에 자신이 생각했던 금액에 터무니 없는 금액을 제시하는 곳은
  업체자체 능력이 떨어지거나 (정 이하업체), 개발자를 호구로 보는 곳인거 같습니다.
 
  예전에 어디 책에선가 읽었는데,
  협상을 할때 금액을 먼저 부르는 사람이 지기 마련이라고...
  받고 싶은만큼, 나는 이정도 받을만하다 싶은 금액을 자신있게 부르고
  협상의 여지도 없는 수준이라면 과감히 잘라내버리는게 속편하것 같습니다.
 

7. 프로젝트 담당자 면접시 최대한 꼼꼼하게 많은 정보를 챙기자
 
 - 보통 계약할 업체와 실제 프로젝트 담당 업체는 전혀 상관없는 업체인 경우가 많은데요.
  결국 프로젝트의 분위기나 상세내역을 아는 분들은
  실제 프로젝트를 같이 뛸 PL PM 분들이시죠.
 
  제 경우 프로젝트 PL PM 면접 없이 계약업체와
  계약만하고 들어가는 프로젝트는 쳐다도보지 않습니다.
  들어갔다가 무슨 상황이 일어날지 모르니까요.
 
  프로젝트 실무자 면접시 제 경우
 
  1) 출퇴근 시간 (업무시간)
  2) 복장 (정장, 캐쥬얼이면 어느선까지 용인되는지)
  3) 업무범위
  4) 전화응대 유무
  5) 고객 회의/협의 찹가 유무
  6) 문서 작성 범위
  7) 주말 출근 유무
  8) 야근 유무, 발생시기, 일주일 혹은 한달 몇번정도 일어나는지
  9) 외주 개발자에 대한 처우 (차별이라던가 그런것이 있는지)
  10) 야근식대, 교통비 지급 유무
  11) 회식 혹은 술자리 횟수
  12) 보안에 따른 사용제한 유무(인터넷, USB, 보안프로그램 등)
  13) 불법 Software 사용 가능한지 (토드등) 안된다면 업체에서 지원 가능한 라이센스가 있는지
  14) 사수 or 기술/업무지원 가능한 사람이 있는지 (이건 제가 초급이라서 물어봅니다)
  15) 프로젝트 정확한 시작은 언제고 현재 어느 단계인지, 딜레이가 된 프로젝트인지
     (그리고 프로젝트 일정에 대한 전반적인 사항)
  16) 원청 과 나(개발자) 사이의 업체 수 (많을수록 안 좋으니까요)
  17) 강제 출퇴근 유무 (공공 프로젝트 경우는 빈번하더라구요)
  18) 개발, 배포, 반영, 명세 등등 역할이 나누어진 팀이 따로 있는지 (디자이너, 웹퍼블리셔가 있는지) 
      아니면 내가 다 해야하는지
  19) 프레임워크 및 툴은 뭘 써야하는지
  20) 왜 프리를 고용하게 된건지
     (요 부분을 잘 알아내면, 프로젝트 분위기가 보이더라구요)
  21) PL/PM 혹은 내 윗사람이 개발자 인지, 개발자 '출신' 인지, 관리자인지
  22) 월차가 가능한지
     (여름이 끼어있으면 여름휴가, 요번에는 설날 출근 있는지 물어봤습니다)
 
  
8. 이미 유명한 곳은 이유가 있으니 쳐다도 보지 말자
 - 3대 악성으로 유명한 농X, K트, 한X 등등
  보통 이런곳은 연락오자마자 '거기랑은 일 안합니다' 라고 자르는데
  
  그 외에 유명한 곳들도 면접을 실제로 보면
  '아 정말 소문이 괜히 나는게 아니구나' 싶어집니다.
  한 사람에게 몇사람이 해도 무리가갈 분량의 일들이 떨어지고, 돈은 더 안줄려고 하고...
 
  개발자 귀한줄 모르는 프로젝트/업체는 그냥 다 안가버리는게 좋은것 같습니다.
  연락왔던 분이 거기랑은 일안한다 하니
  '요즘 농X의 N만 들어가도 개발자들이 안하신다고 하네요' 하면서 한숨을 쉬시더라구요.

대충 요정도 생각하면서 알아보았습니다 ㅎㅎ
행여나 좀 불쾌하거나 건방져보이는 문구나 표현은
지적해주시면 수정하겠습니다.
 
선배님들께서 보시기에 좀 더 추가할만한 사항이 있으면 
또 알려주시면 감사하겠습니다 ㅎ
 
친구녀석이 정말 매일 밤새가며 주말출근 계속하고,
그러면서 혼자 사이트 몇개를 맡아서 일하고 있는데...
프리 권유를 술사줘가면서 몇달째 해도, 결단을 못내리더라구요.
월급도 시원찮고, 재경비 유류비도 잘 안나오는데도...
 
막연한 두려움도 있는것 같고...
'내가 과연 지금 프리랜서를 할만한 실력인가' 로 고민도 하는것같구...
정작 회사 나와서 정말 프로젝트를 구할수 있을까 하는 생각도 있는것 같더라구요...
 
그 막연한 두려움이 아마도 구직활동을 할때
뭘 어떻게 해야 할지 막막해서 그런걸지도 모른다는 생각에
친구랑 술먹으면서 프리권유하면서 
'야 그냥 이렇게 하면되' 하면서 
제가 프리 구하면서 궁리했던 얘기들을 정리해보았습니다.
 
사실 다 여기서 보고 듣고 알게 된것들인데요 ㅎㅎ
장문인데 읽어주셔서 감사합니다.
KOSA 등급제 폐지로 말이 많을것 같은데
제대로된 대우 받으면서 일하시는 개발자분들이 많아졌음 좋겠네요!
 
아 수업시간 다 지났습니다 흐흐
월요일에 뵙겠습니다~ 주말 마무리 잘 하십쇼~~

2014년 12월 28일 일요일

변수와 메소드 네이밍에 관한 15가지 모범 사례

http://www.mimul.com/pebble/default/2013/05/04/1367639300999.html 에서 퍼왔습니다.  소중한글 감사합니다.


코딩 스타일을 좋게 하는 방법 중에 하나가 네이밍을 일관되게 사용하는 것이다. 그래서 관련된 좋은 아티클, "15 Best Practices of Variable & Method Naming"에 대해서 소개한다. 

간략하게 정리해 보면..

1. 범위별로 충분히 짧게, 혹은 충분히 긴 변수 이름을 사용한다. 일반적으로 루프 카운터에는 하나의 문자로, 조건이나 루프 변수는 한 단어로, 메소드는 한/두단어로, 클래스에는 두/세 단어로, 전역 변수는 서/너 단어를 사용한다.

2. 구체적인 변수 이름을 사용한다. 예를 들어, "value", "equals", "data" 같은 변수 이름은 어떠한 경우에도 유효하지 않다.

3. 의미있는 변수 이름을 사용한다. 변수 이름은 저장되는 값을 정확하게 설명할 수 있어야 한다.

4. 변수 이름은 "o_", "obj_", "m_"등으로 시작하지 않는다. 변수 이름에 자신이 변수라고 자기 자신을 언급하는 태그는 필요 없다.

5. 변수에 관련된 회사의 네이밍 규칙을 따르고, 어플리케이션 내에서도 일관된 변수 이름에 쓴다. 예를 들어, txtUserName, lblUserName, cmbSchoolType 등과 같이. 그렇지 않으면, 가독성이 떨어지고 검색/바꾸기 툴 사용 측면에서 사용할 수 없게 된다.

6. 프로그래밍 언어의 표준을 따르자. 그리고 대/소문자 문자들을 일관되지 않게 사용하지 않는다. 예를 들어, userName, UserName, USER_NAME, m_userName, username 등에서 처럼 비 일관되게 사용하지 않는다. 
  - Java의 예로 올바른 네이밍은.
  • Camel Case(aka Upper Camel Case)를 클래스에 사용한다. VelocityResponseWriter
  • Lower Case(Lower Camel Case)를 패키지에 사용한다. com.company.project.ui
  • Mixed Case(aka Lower Camel Case)을 변수 로 사용한다. studentName
  • Upper Case를 상수로 사용한다. MAX_PARAMETER_COUNT = 100
  • Camel Case를 enum클래스에 사용하고 Upper Case를 enum 값으로 사용한다.
  • '_'는 상수와 enum값 이외의 어떠한 곳에서도 사용하지 않는다.(이들은 상수이다.)
7. 다른 컨텍스트에서는 동일 클래스내에서 동일 변수를 사용하지 않는다. 예를 들어, 메소드및 생성자, 클래스 등이다. 이렇게 하면 더 간단하게 이해하기 쉽고 관리하기 용이하게 할 수 있다.

8. 메소드및 조건 등에서 다른 목적이라면 동일 변수를 사용하지 않는다. 대신 새로 다른 이름의 변수를 준비한다. 이것은 이해하기 쉬움과 유지 보수의 용이성도 중요하다.

9. 변수 이름에 ASCII가 아닌 문자를 사용하지 않는다. 그들은 당신의 플랫폼에서 작동 할지도 모르지만, 다른 플랫폼에서 작동하지 않을 수 있다.

10. 너무 긴 변수 이름을 사용하지(예로, 50자 길이). 너무 긴 이름은 추잡하고, 읽기 어려운 코드이다. 게다가, 어떤 컴파일러는 최대 길이(character limit)에 의해 작동되지 않는다.

11. 네이밍을 위해 자연 언어를 하나로 정하고 그것을 사용한다. 예를 들어, 영어와 독일어가 혼합 된 이름은 비 일관적이고 읽기 힘들 것이다.

12. 메소드를 위해서도 의미 있는 네이밍을 사용한다. 이름은 메소드의 정확한 동작(action)을 구체적으로 나타내고, 대부분의 경우 동사로 시작(createPasswordHash 등)한다.

13. 메소드에 대해서도 회사의 네이밍 규칙에 따르고, 어플리케이션 내에서 일관되게 메소드 이름을 쓴다. 예를 들어, getTxtUserName(), getLblUserName(), isStudentApproved() 등이다. 그렇지 않으면, 가독성이 떨어지고, 검색/바꾸기 툴의 사용 측면에서 유효하지 않게 된다.

14. 프로그래밍 언어의 표준에 따라 대/소문자 문자열을 일되관하지 않는 상태로 사용하지 않는다. 예를 들어, getUserName, GetUserName, getusername 등의 혼합 말이다. 
- Java 의 예로 올바른 경우는.
  • Mixed Case를 메소드 이름으로 사용한다. getStudentSchoolType
  • Mixed Case를 메소드 매개 변수에 사용한다. setSchoolName (String schoolName)
15. 의미있는 이름을 메소드의 매개 변수로 사용한다. 그렇게 되면, 문서가 없는 경우에도 코드 자체가 문서 역할을 하게 된다.

2014년 4월 13일 일요일

SPRING3 세팅시 Unable to read TLD "META-INF/c.tld" from JAR file 오류 발생시

Unable to read TLD "META-INF/c.tld" from JAR file

해결방법
1. pom.xml 의 dependency를 찾아간다.
2.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
이부분 주석처리 한다.


2014년 3월 24일 월요일

SPRING3_ERROR Aspect weaving(weaver) 오류 수정

sts로 하면 자동 세팅되서 좋아했는데 이런 것들이 하나씩 빠져있네..

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'perfomanceTraceAdvice'
defined in class path resource [myframework/spring/aspect-context.xml]: BeanPostProcessor before instantiation
of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.aop.aspectj.AspectJPointcutAdvisor#0':
Cannot create inner bean '(inner bean)' of type [org.springframework.aop.aspectj.AspectJAroundAdvice]
while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name '(inner bean)':
Cannot resolve reference to bean 'publicMethod' while setting constructor argument;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'publicMethod': Instantiation of bean failed;
nested exception is java.lang.NoClassDefFoundError: org/aspectj/weaver/BCException


오류속에 답이 있었다.
NoClassDefFoundError가 뜨지 않는가

weaving 관련 오류 떠서 상당히 해멨다 ㅜㅜ

maven을 사용할 경우 추가하자
maven 사이트가면 최신 정보 있다.

<!-- asoect weaver -->
<dependency>
    <groupId>aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
    <version>1.5.3</version>
</dependency>

2014년 3월 20일 목요일

centos(64bit) apache6 + tomcat + ssl 1차 설치

1. 기본 자바설치
2. yum install apache
3. yum install tomcat
4. yum install mod_ssl


회원가입 밸리데이션 체크

퍼가기가 안되서 보고 직접 썻습니다. -_-
http://tibang.tistory.com/entry/JSP-%EC%A0%95%EA%B7%9C%ED%99%94-%ED%91%9C%ED%98%84%EC%8B%9D


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>정규화 표현식</title>

<script type="text/javascript">

String.prototype.trim=function(){

var TRIM_PATTERN=/(^\s*)|(\s*$)/g; //  \s => 요게 공백. /(^\s*)|(\s*$)/g : 앞의 공백과 뒤의 공백을 제거하라

return this.replace(TRIM_PATTERN,"");

}




function send(){

var f=document.forms[0];



var a="           우리   나라    ";

a=a.trim();

alert(":"+a+":");



// 이름

if(! /^[\uac00-\ud7a3]*$/g.test(f.name.value)){ //g: 완전일치, ^앞 $뒤 *0개이상, uac00~ud7a3은 한글 코드값  , gi대소문자 구분없이 완전일치

alert("이름을 제대로 입력하쇼");

f.name.focus();

return;

}



// 아이디

if(! /^[a-z][a-z0-9_$@#]{4,9}$/i.test(f.id.value)){ // ^ : 앞에만 검사, $ : 뒤에만 검사, i 대소문자 구분 안함(없으면 소문자만 가능하다)

alert("아이디 첫문자는 영문자이고 5~10자만 가능");

f.id.focus();

return;

}




//패스워드검사(영문자와 1자 이상의 숫자특수문자. 5~10)

if(! /^(?=.*[a-z])(?=.*[_!@#$%^&*]|.*[0-9]).{4,9}$/i.test(f.pwd.value)){

alert("패드워드는 특수문자가 필요 ");

f.pwd.focus();

return;

}




// 날짜 형식 검사

if(! /[12][0-9]{3}-[0-9]{2}-[0-9]{2}/.test(f.birth.value)){ // 검사방법 / ~ / 슬러시와 슬러시 사이. [12][0-9]{3} => 첫글자는 1이나 2가 와야한다. 그다음에는 0~9가 3번와야한다.

alert("생년월일은 yyyy-mm-dd 형식으로 입력해야 함!!!");

f.birth.focus();

return;

}



//나이 형식 검사

if(! /^[0-9]*$/.test(f.age.value)){ // * : 0개이상(제한을 두지 않는다)

alert("나이는 숫자만 가능");

f.age.focus();

return;

}



//이미지 파일만

if(! /(\.gif|\.png|\.jpg|\.jpeg)$/i.test(f.upload.value)){ // 뒷글자만 검사하면 되기때문에 $

alert("그림만..............")

f.upload.focus();

return;

}



// 메모에는 SELECT, INSERT 등의 sql 삽입금지

var p=/SELECT|INSERT|UPDATE|DELETE|ALTER|DROP/gi;

if(p.test(f.memo.value)){

alert("SELECT, INSERT, UPDATE, DELETE, ALTER,DROP 등 sql문 사용 금지");

f.memo.focus();

return;

}



alert("성공!!!");

}




</script>

</head>

<body>




<form action="">

이름 : <input type="text" name="name"><br/>

아이디 : <input type="text" name="id"><br/>

패스워드 : <input type="text" name="pwd"><br/>

나이 : <input type="text" name="age"><br/>

생녀월일: <input type="text" name="birth"><br/>

파일 : <input type="file" name="upload"><br/>

메모: <textarea rows="10" cols="60" name="memo"></textarea><br/>

<input type="button" value="보내기" onclick="send();">

</form>




</body>

</html>

CBD 개발 방법론 - 방법론 단계에 따른 UML 분류

작성자가 검색을 허용한 카페 글입니다. 도움말
CBD 개발 방법론 - UML 다이어그램|프로젝트관리
0/2008.05.27 16:41

퍼스나콘/아이디 영역
soju_glass
카페매니저 1:1대화
--------------------------------------------------------------------------------------------------
제목 : UML 다이어그램
참고자료 : 객체지향 CBD 개발 Bible - 한빛미디어

작성자 : 윤영욱
작성일 : 2008.5.27
--------------------------------------------------------------------------------------------------

1. 다이어 그램의 이점

다음과 같은 문장을 이해해 보자

한 회사에는 여러 팀이 잇다. 각 팀에 대해서 해당 팀을 관리하는 하나의 팀이 있으며, 한 팀은 다른 여러 팀을 관리 할 수 있다.

한 회사는 여러 사무실을 가지고 잇으며 한 팀은 하나 이상의 사무실에 위치할 수 잇고 반대로 한 사무실에 여러팀이 작업할

수 있다.






UML 은 다음과 같은 9개의 다이어그램을 가지고 있다.

1. 클래스 다이어그램
2. 오브젝트(객체) 다이어 그램
3. 컴포넌트 다이어 그램
4. 배치 다이어그램
5. 유스케이스 다이어 그램
6. 시퀀스 다이어 그램
7. 콜레보레이션(협력) 다이어 그램
8. 상태 차트 다이어 그램
9. 액티비티 다이어 그램


그러나 프로젝트 마다 9 가지 다이어그램을 모두 산출 해야 하는 것은 아니다.

프로젝트의 특성에 맞게 필요한 다이어그램을 작성하면 된다.


2. 4+1 관점

1) 유스케이스 관점

사용자가 인식할 수 있는 시스템이 제공할 기능 파악에 초점을 둔다.

사용자가 시스템으로 부터 원하는 기능이 무엇인지 정의하는 것으로

유스케이스관점에서 파악된 유스케이스에 따라서 다른 4가지 관점의 내용이 달라지기 때문에 다른 4가지 관점을

유도하는 중심적 역할을 한다.


2) 설계관점

유스케이스에서 정의된 기능을 시스템이 제공하기 위해서는 어떤 클래스/컴포넌트가 필요하고 이들 클래스/컴포넌트들이

서로를 어떻게 이용/호출 하는지에 초점을 맞춘다.


즉 시스템 내부의 클래스/ 컴포넌트를 파악하고 기술하는 것이다.

정적인 측면과 동적인 측면으로 구분 된다.

 구분관심사항 이용되는 다이어그램 
 정적인 측면클래스 및 클래스들 사이의 관계  클래스 다이어그램 
 동적인 측면클래스 내의 동작상태차트 다이어 그램 
클래스 간의 상호작용시퀀스 다이어 그램
콜레보레이션 다이어그램 
클래스의 연산동작액티비티 다이어 그램




3) 프로세스 관점

클래스와 클래스 간의 그리고 클래스의 행동 및 클래스 간의 상호작용에 초점을 맞춘다.

모든 클래스에 대해 관심을 가지는 것이 아니고 독자적으로 제어 스레드나 프로세스를 가지고 있는 클래스들에 대하여

클래스 다이어그램을 작성한다.



4) 구현관점

물리적 요소, 즉 파일과 파일들간의 의존관계에 초점을 둔다.




5) 배치관점

시스템의 처리장치(컴퓨터) 와 통신방법에 초점을 둔다.

배치 다이어 그램으로 표현된다.




3. 개발활동과 관점






[시스템 유형별 UML 다이어그램 활용]

 관점UML 다이어그램 간단한 시스템 반응적 시스템 복잡한분산 시스템 
 유스 케이스 관점유스케이스 다이어그램 Y Y Y
 설계관점클래스 다이어그램  Y Y Y
상호작용 다이어그램 Y Y Y
상태차트 다이어그램 Y Y
 프로세스관점클래스 다이어그램 Y
상호작용 다이어 그램 Y
 구현관점컴포넌트 다이어그램  Y
 배치관점배치 다이어그램 Y



* 반응적인 시스템 : 객체 내부의 상태에 따른 복잡한 행동을 보이는 시스템

예를 들어 수강신청를 보자

취소라는 기능을 해야 하는데, 수강신청 기간인지 정정 기간인지 교육중인지 완료 후 인지에 따라

취소 가능 불가능 과 환불 조치에 대한 일련의 기능들이 달라진다.

수강과정의 상태에 따라서 말이다.


* 복잡한 분산 시스템

시스템의 기능이 분산된 여러 시스템에 의해 제공되는 시스템



[웹 기반 정보 시스템]

 관점UML 다이어그램 사용여부 
 유스케이스 관점 유스케이스 다이어그램  Y
 시퀀스 다이어 그램 Y
 액티비티 다이어 그램 Y
 설계관점 클래스 다이어 그램  Y
 상호작용 다이어 그램 Y
 상태차트 다이어그램
 프로세스 관점 클래스 다이어 그램 
 상호작용 다이어 그램
 구현관점 컴포넌트 다이어 그램 Y
 배치관점 배치 다이어 그램 Y



다른 시스템과 웹기반 시스템의 차이점을 확실히 기억하자 붕어같은 머리라 할지라도 !!!