물론, 당연히 소재가 좋으면 가산점이다
그러나, 소재의 좋고 나쁘고를 교수 자신이 판단하긴 너무 주관적이기에,
그 소재를 어떻게 내게 흥미를 끌게 만들 것인지, 해당 소재를 어떻게 구현할 계획인지, 얼마나 꼼꼼히 시장 조사를 했는지, 구현을 위한 정보 조사를 얼마나 했는지가 더 중요하다
4월 8일까지 계획서를 제출하고 발표를 하셔야합니다.
계획서(워드)랑 피피티(발표)
유스케이스(Use Case)
사용사례들(기능들)을 정리해서 그림으로 표현하는 방식
요구 분석 과정
SDLC
현재 시스템에서 새로운 시스템으로 옮기는 과정
•
요구를 찾고
•
요구를 정리
요구 분석 과정 그림
요구 정리 - 모델링
실체를 축약해 표현하는 작업
3가지 관점이 존재
1.
기능적 모델
2.
정적(구조적) 모델
3.
동적 모델
UML Diagram
시스템의 모델링은,
기능적 관점, 구조적 관점, 동적 관점으로 구성
UML 다이어그램
모델링 과정
궁극적으로는, 클래스 다이어그램(설계도와 맞먹는 역할, 매우 디테일함)을 만들어내는거다
물론, 클래스 다이어그램을 표현하기 위해 다른 다이어그램들을 사용한다
여기부터는 UseCase와 관련된 내용을 하나씩 살펴볼게요
도메인 분석
설계 모델링에 필요한 여러 개념과 비즈니스 룰을 파악
응용 분야에 존재하는 개념을 잘 정의하고 분석하여
시스템에 존재하는 개념으로 정립하는 단계
도메인이란?
요구의 배경
도메인 분석의 예
유스케이스(사용사례)
도메인 분석과 모델링 사이의 관문
•
사용 사례 : 시스템을 사용하는 방식을 사용자가 특징적으로 나타낸 것
•
사용자와 시스템 사이의 다이얼로그를 사용자의 관점에서 나타낸 것
•
기능적 요구를 캡쳐한 것
도메인 분석의 결과를 액터, 사용사례, 관계들로 구성된 시스템 명세로 매핑하는 작업
장점
•
시스템 개발자와 고객 사이에 요구를 이해하는 수단
•
예외적 케이스를 개발자에게 인지시킴
•
대략적 계획을 위해 기능의 수준을 파악
용어
•
액터
◦
시스템과 상호작용하며 사용하는 사람
•
주 액터
◦
액션을 구동시키는 사람
•
목표
◦
주 액터가 달성하는 성과
요소
•
액터
•
시스템 범위
•
유스케이스
•
관계
유스케이스 분석과정
1.
액터 찾기
2.
유스케이스 찾기
3.
유스케이스 사이 관계 찾기
다이어그램
•
사용사례
◦
시스템 기능
•
액터 : 시스템과 상호작용 하는 것
◦
사용자, 시스템
시스템의 기능을 나타내기 위해서 사용자의 요구를 추출하고 분석하는데 사용
문제는 이런 식으로 나온다
문장을 문제로 주면, 알맞은 다이어그램으로 그림을 그려야한다
액터
•
시스템과 상호작용하는 외부 엔티티
•
구별되는 이름과 설명 필요
•
액터가 될 수 있는 것
◦
사용자가 맡은 일
◦
다른 시스템
유스케이스 사이의 관계
Extend: 확장관계 // Include: 포함관계
실선 : 일반적 관계 표현(무방향)
포함 및 확장 관계는 점선이고, 방향이 존재합니다. 시험때 조심할 거
방향 표시 : (포함되는 것 : 자식역할) → (포함하는 것 : 부모역할)
포함 관계 <<include>>
•
사용사례 사이의 중복 제거
•
공통 작업 빼내는 것
•
함수의 호출과 유사
확장 관계 <<extend>>
•
예외 사항을 나타내는 관계
•
이벤트를 추가해서 다른 사례로 확장
•
예외 시작 조건과 종료 조건 필요
◦
include는 조건이 필요하지 않지만,
extend는 조건을 충족하지 못하면 확장관계를 연결할 수 없음