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
Test.eap