블로그 이미지
SITD

카테고리

분류 전체보기 (34)
1.DB (4)
2.OS (3)
3.PROGRAMMING (14)
4.학업 (0)
5.영어 (0)
6.KSIT (5)
7.증권 (1)
8.EXCEL (0)
9.Graduate (2)
기타 (5)
Total60,285
Today0
Yesterday25

달력

« » 2019.11
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

공지사항

태그목록

UML 3일차

6.KSIT / 2012.04.18 22:14

1. 개념모델

1.1 구현보단 인터페이스와 관계가 깊다.

1.2 도메인 모델 : NOT 데이터 모델. UP. 목표는 실세계의 표기이다.

1.3 역할 별로 객체를 분류시킬 수 있다.

1.4 유비쿼터스 = 어디서든지 통용될 수 있다 = 비즈니스 기반.

1.5 정적 다이어그램 :

1.5.1 클래스 다이어그램 - 클래스간의 관계, 인터페이스와 클래스와의 관계 등.

구성 = Property(분석단계 추출) + Operation(설계단계 추출)

!!.좋은 클래스? 1)책임 2)역할 3)협력

Property : attribute(컬럼) + association(연결선. 비즈니스 or 시스템적으로 가치가 있을 

                                                                               때 사용)

CRC : 담당자A를 찾아서 담당자A가 요구하는 업무의 담당자B를 다시 찾는 방식의 반복.

NOTE : 일관성을 위해, 일관성에 문제가 생긴경우 주석다는 것처럼 사용하자.

의존성 : 설계시점에서 표현하기 힘들다. A->B이고, B->C이더라도 A->C라고 볼 수 없 

                                                                            다.(이행관계없음)

집합과 복합의 차이는 결합도의 차이. public A a(B b) 이런게 강결합.

의존성과 위임의 차이. 위임은 추상클래스(즉 다형성)

Provides(제공자 인터페이스. List등) VS Required(요청자 인터페이스. Order 등)

연관관계에서 연관보단 역할이 중요하다. 연관은 너무 복잡해 질 우려가 있다.

용어 : 리얼라이제이션(언어의 임플리먼트)

!!. 되도록이면 사람은 나누지 않는다.

1.5.2 객체 다이어그램 - 클래스 다이어그램 설명용(=예제 = 스냅샷).

파티복합구조 : 트리를 재귀적으로 표현한다.





UML과 소프트웨어개발(3일차)_1.0.pdf


1차UseCase분석.txt


UML03.txt


경기정보관리시스템.zip



Test.eap



'6.KSIT' 카테고리의 다른 글

UML 5일차  (0) 2012.04.20
UML 4일차  (0) 2012.04.19
UML 3일차  (0) 2012.04.18
UML 2일차  (0) 2012.04.17
UML 1일차  (0) 2012.04.16
Posted by SITD

댓글을 달아 주세요

UML 2일차

6.KSIT / 2012.04.17 22:16

1. SW 개발과정

1.1 요구사항 정의 ★ Our Focus

: 기능적(사용자 요구사항) + 비기능적(성능 = 품질속성. 아키텍트가 비기능 명세를 정의한다.)


1.2 유스케이스 : 기능적인 요구사항 획득 및 서술 


2. 유스케이스

2.1 모델과 명세(명세에 집중) 모두 필요하다.

2.2 시나리오 집합 : 스텝을 반드시 넣어야 한다.(추후 대안 흐름 때문)

2.3 (사용자)목표의 집합.

2.4 액터 : 사용자 혹은 타 시스템이 현 시스템에서 수행하는 역할(!=권한)

2.5 내용(!=다이어그램)

2.6 애자일 진영에서 비판을 많이 받는다.(요구사항에 대한 빠른 피드백을 방해를 하기 때문)

2.7 강점 : 초기 커뮤니케이션에 도움을 많이 주기 때문에 초기에 분석 및 설계된 부분이 추후 요구사항 변경시에도 위력을 발휘.

2.8 기능적 요구사항을 주로 획득된다.

2.9 내용

2.9.1 주 성공시나리오 : 심플. 분기나 대안 조차 없다.

액터(주체) 반드시 표기

UI 서술금지

액터의 의도를 표시.

2.9.2 확장 : 대안흐름(major 대안, minor 예외 or 오류)

스텝을 기록하는 이유.

#* or *# : 트리거. 언제든지 수행가능.(애스터리스크 위치가 언제든지 가능하단 뜻)

2.9.3 액터 : 시스템과 상호작용하므로, 처리의 핵심.

2.9.3.1 일차액터 :요구사항을 내는 액터. 이해관계자 ex) 고객

2.9.3.2 지원액터 :시스템과 통신하는 액터. 실제 시스템 사용. ★인터페이스간 프로토콜 식별에 도움이 됨 ex) 교환원

2.9.3.3 액터찾기 : 질문들 확인

2.9.3.4 추가항목 : 사전조건 - ex) log-in

보증 - 종료시 보장되어야 하는 사항. 유스케이스 자체가 보증을 말하는 것이므로 별도 

                                                                           기입하는 경우가 적다. 성공보증 or 최소보증

트리거 - 시작되도록 하는 이벤트

간략하게 - 가독성을 위해


3. 유스케이스 다이어그램

3.1 표기법 : 최대한 적게. 유스케이스와 연관관계만 써라. 간단하게 해야 명세도 간단하게 나온다. 단방향 관계를 추천.

3.2 다이어그램은 최대한 간단하게, 명세에 집중할 것. 명세를 써봐야지 다이어그램의정 확성을 알 수 있다.

3.3 일반적인 형태 : 일차액터 - 바운더리 - 이차액터



4. 유스케이스 수준

4.1 수준개요

4.1.1 요약목표

4.1.2 사용자 목표

4.1.3 하위 기능


4.2 요소 비즈니스 프로세스 : 5~10스텝 사이. 비즈니스 적 가치가 있어야 한다. 비즈니스 적으로 자료의 소스(DB등)는 비즈니스에 

                                                중요치 않다. 대부분 블랙박스로 할 것.(화이트 박스의 최소화)


4.3 목표수준

4.3.1 높이기(왜) / 낮추기(어떻게). 

4.3.2 이후 명세서 작성시 5~10단계 안에 끝나면 적당한 수준으로 판단해도 된다. 최상(3~8단계), 최고(11단계). 단, UI 등 낮

                        은 수준의 명세는 제외. 총 2페이지.

4.4 크기

4.4.1 가장 바깥쪽 : 레이아웃. 

4.4.2 사용자 목표수준 : 가이드라인 : 20개를 대규모로 볼 수 있을까 의문이 든다. 숫자에 얽매이지 않는게 맞을 것 같다.


4.5 분리

4.5.1 대안흐름이 중요한 이유. 확장(extend)하여 복잡성을 줄인다.

4.5.2 고려사항 : 유스케이스가 많아지면 관리비용이 많아진다고 한다.

팁) 언더바(데이터), 볼드(유스케이스) 등등


4.6 특이 유스케이스

4.6.1 Startup : 유스케이스 간엔 일반적으로 선후 관계는 없으나 이 유스케이스는 시작관계가 존재한다.

4.6.2 CRUD : 하나로 표현할 것. 노트 사용 추천.


4.7 작성양식

4.7.1 후조건 : 되도록 사용하지 말자. 오용의 위험이 큼. 대신 보증을 쓰자.

4.7.1 기본흐름 자체가 의미를 가지므로, 기본흐름과 외부의 넘버링으로 연관시킬 필요없다. 기본흐름은 그냥 1,2,3으로 사용.


!!. 인클루드 : A -> B. 절대적. 반드시 수행. A -> B -> A로 돌아온다.

   익스텐드 : A <- B. 선택적. 특정지점에서 확장. A의 확장점일 때 B가 A에 들어온다고 보면된다.

   

 



도서관리시스템.zip



UML과 소프트웨어개발(2일차)_1.0.pdf



UML02.txt


'6.KSIT' 카테고리의 다른 글

UML 5일차  (0) 2012.04.20
UML 4일차  (0) 2012.04.19
UML 3일차  (0) 2012.04.18
UML 2일차  (0) 2012.04.17
UML 1일차  (0) 2012.04.16
Posted by SITD

댓글을 달아 주세요

UML 1일차

6.KSIT / 2012.04.16 19:16

1. UML 개요
 -> 시스템 관점에서, 운용 때도 관리를 하자.


2. UML 소개
 2.1 사용법
  - 스케치 : 의사소통용, 단순. -> 개념적 관점
  - 청사진 : 코딩직전, 복잡  -> 명세 관점
  - 프로그래밍 언어     -> 구현관점

 2.2  MDA(Model Driven Architecture) : 사용 가능한 툴이 없다. 개념적인 것만 알아둬도 무방.
  - 컴퓨터 독립적 모델 : 시스템과 별개로, 현업끼리 대화에 사용하는 문서 등을 의미한다.
  - 플랫폼 독립 모델  : 분석 + 설계 단계. 기술과 독립.
  - 플랫폼 종속 모델  : 구현 단계. 특정 환경에 종속. 리버스 엔지니어링을 사용하면 되므로 잘 사용하지 않는다.
  => PIM -> PSM = UML -> 프로그래밍 언어

  !!. UML = 로테이션
  !!. 설계중심에서 분석중심으로


3. UML 다이어그램 분류

 3.1 구조 다이어그램
  3.1.1 클래스    : 핵심. 이것만으로 기본적인 흐름 파악은 가능하다. 70% 정도의 비중
  3.1.2 오브젝트   : 클래스에 비해 상대적으로 비중이 적다. 클래스의 보조라고 보면 된다.
  3.1.3 복합구조   : UML2.0 때 추가된 기능으로, 사용빈도는 적다. 실행시간에 클래스 분할과 관련된다.
  3.1.4 배치    : 산출물의 노드(=일반적으로 하드웨어)로의 배치. 분석/설계 단계에선 필요치 않다. 아키텍트 들이 주로 사용한다.
           (= 시스템을 비즈니스와 아키텍쳐 단위로 나눈다고 쳤을 때, 아키텍쳐에 포함된다.)
  3.1.5 컴포넌트  : 객체지향이 아닌 컴포넌트 기반으로 설계시 사용한다.
  3.1.6 패키지   : 시스템 규모가 너무 클 때, 시스템 분할의 단위(=서브 시스템 수준으로)로 설계시 사용.
           ex) 영업/상품기획 등의 큰 단위에 사용.
  

 3.2 행위 다이어그램(+상호작용 다이어그램)
  3.2.1 액티비티    : 절차/병렬적 행위로 비정규적 산출물.
             비추천. 이유 : 비즈니스/내부 로직 그릴 때 사용되기 때문에 중복된다. BPID를 더 추천. 현업이 작성한 파워포인트 순서도가 더 낫다..
  3.2.2 유즈케이스   : 사용자 - 시스템 간의 상호작용. Lotation. 요구사항 정의용. 사용 빈도가 크다.
  3.2.3 상태기계     : 이벤트 동안의 객체 생명주기 표현. 설계 단계. 1개의 객체에 대해 그린다. 필요성이 낮다. 일반적으로 비정규 산출물.
  3.2.4 상호작용 인터뷰 : 아래 참조.
  3.2.5 시퀀스      : 흐름에 중점을 둠. 클래스 다이어그램 이후로 가장 많이 쓴다. 20% 정도의 비중
  3.2.6 커뮤니케이션   : 객체의 구조에 중점. 시퀀스와 내용이 동일하며 표기법만 상이하다. 로즈에선 시퀀스 생성시 자동 생성 가능. 전 콜레보레이션 다이어그램
  3.2.7 타이밍     : 사용빈도 적다. 특정 시점의 객체 상호작용.


4. 표기법
 4.1 합법적인 UML
  4.1.1 규범적인(prescriptive) 규칙
  4.1.2 서술적인(descriptive) 규칙 ★ Martin's 추천.

 4.2 불완전성
  4.2.1 모든 것을 표현할 순 없다. 다른 툴을 사용해도 됨.
 
 4.3 아키텍쳐
  4.3.1 4 + 1
   4 : 설계 뷰    -
     프로세스 뷰  -
     구현 뷰    - 형상관리 포함.
     배치 뷰    - H/W 반영
   1 : 유스케이스 뷰 - 상단 4개의 뷰에 모두 영향을 미친다. 요구사항 정의이므로 테스트 담당자에게도 제공된다.
             (즉, 원칙적으론 유스케이스로 테스트가 되어야 한다. 실제론 요구사항이 중간에 변경되기 때문에 테스트케이스는 별도로 만들긴 한다.)


5. 개발 프로세스 개요
 -> 상황에 따라 가변적이므로 합의에 도달 못함.

 5.1   방법론     VS    프로세스
   관리 + 개발 프로세스      개발 프로세스만 존재
 
 5.2   반복      VS    폭포수    => 폭포수 안엔 반복이 N개 들어있다.
   
 5.3 예측계획법과 적응계획법
    : 실제론 예측이 불가능.

 5.4 기민한(Agile) 프로세스
  5.4.1 XP가 가장 유명함. 최고의 가치는 소프트웨어(문서보다. 때문에 한국에 적용이 어렵다.)
  5.4.2 사람 중심이다. 대화가 필수이므로 팀원과 팀워크에 따라 성패 좌우.
          주 40시간 근무를 필수로 한다.
          소스 코드 1 : 1 테스트 코드
  5.4.3. Scrum : 관리 관점으로 최근 주목. 1달 단위로 반복. 추가 요구사항은 1달 후에 반영. 자기조직화(= 개개인의 능력 향상을 위한 배려)
      

 5.5 RUP - 이하 모두 RUP
  5.5.1 개발 + 관리 방법론.
  5.5.2 도입 -> 발단 -> 구축 -> 전이(transit = delivery)
  5.5.3 하나의 프로세스로 모든 프로젝트를 해결할 순 없으므로, 여러가질 사용. ex)RUP 중심에 필요할 경우에만 애자일 사용하는 방법 추천.


6. UML 맞춤
 6.1 요구사항분석 : 유스케이스 + 클래스
 6.2 설계    : 클래스 + 시퀀스
 6.3 문서화    :
 6.4 레거시 코드  : UML을 역공학해서 클래스 관계를 파악할 수 있다.


7. UML  개발 생명주기
 7.1 UML은 원칙적으로 개발 Process에 독립적이다.
 7.2 도입 -> 발단 -> 구축 -> 전이
 7.3 특이사항
  7.3.1 비즈니스 유스케이스 모델링이 생략되었다. 원인불명.
  7.3.2 비전문서 : ex) 스마트폰 도입 = 아침에 일어나서 바로 업무 확인 가능
  7.3.3 UI도 분석 단계에 해야 한다.
  7.3.4 관리자가 개발자와 현업 사이에서 커뮤니케이션을 차단하는 것도 일종의 위험관리. 실제로 위험관리는 미비한 경우가 많다.

 

 

 

 

UML01.txt


 

UML과 소프트웨어개발 실습(요구사항)_1.0.pdf

 

UML과 소프트웨어개발(1일차)_1.0.pdf

 

UML과 소프트웨어개발(2일차)_1.0.pdf

 

UML과 소프트웨어개발(3일차)_1.0.pdf

 

UML과 소프트웨어개발(4일차)_1.0.pdf

 

UML과 소프트웨어개발(5일차)_1.0.pdf

'6.KSIT' 카테고리의 다른 글

UML 5일차  (0) 2012.04.20
UML 4일차  (0) 2012.04.19
UML 3일차  (0) 2012.04.18
UML 2일차  (0) 2012.04.17
UML 1일차  (0) 2012.04.16
Posted by SITD

댓글을 달아 주세요

최근에 달린 댓글

글 보관함