[소프트웨어공학] 시스템 모델링1
시스템 모델링
시스템 모델링은 시스템의 추상 모델을 개발하는 프로세스이며 각 모델은 해당 시스템의 다른 보기 또는 관점을 나타낸다.
시스템 모델링은 거의 항상 UML(Unified Modeling Language)의 표기법을 기반으로 하는 일종의 그래픽 표기법을 사용하여 시스템을 나타내는 것을 의미하게 되었다.
시스템 모델링은 분석가가 시스템의 기능을 이해하는 데 도움이 되며 모델은 고객과 통신하는 데 사용된다.
기존 및 계획된 시스템
기존 시스템의 모델은 요구사항 엔지니어링 중에 사용된다.
새 시스템의 모델은 다른 시스템 이해 관계자에게 제안된 요구 사항을 설명하는 데 도움이 되도록 요구 사항 엔지니어링 중에 사용된다.
시스템 관점
서로 다른 관점에서 시스템을 표현하기 위하여 서로 다른 모델들을 개발할 수 있다. 예를 들면,
-
시스템의 컨텍스트나 환경을 모델링하는 외부 관점
-
시스템과 그 환경 사이의 상호 작용을 모델링하는 상호 작용 관점
-
시스템의 구성이나 시스템에 의해 처리되는 데이터의 구조를 모델링하는 구조 관점
-
시스템의 동적인 행동을 모델링하는 동작 관점
그래픽 모델 사용방법/목적 (중요!)
-
기존 또는 제안된 시스템에 대한 토론을 자극하고 초점을 맞추기 위한 방법으로서, 모델의 목적은 시스템 개발에 관여하는 소프트웨어 엔지니어들 간의 토론을 자극하고 초점을 맞추기 위한 것이다. 모델은 불완전할 수 있으며 모델링 표기법을 약식으로 사용할 수 있다.
-
기존의 시스템을 문서화하는 방법으로서 문서로서 사용될 때 모델이 완전할 필요는 없으며, 모델을 사용하여 시스템의 일부분을 문서화하면 된다. 그러나 이 모델은 정확해야 한다.
-
시스템 구현을 생성하는 데 사용될 수 있는 상세 시스템 설명으로서 모델기반 개발프로세스의 일부로 모델이 사용되는 경우, 시스템 모델은 완전하고 정확해야 한다.
UML 다이어그램 유형
-
액티비티 다이어그램: 프로세스나 데이터 처리와 관련된 액티비티들을 보여준다.
-
유스케이스 다이어그램: 시스템과 그 환경 간의 상호 작용을 보여준다.
-
시퀀스 다이어그램: 액터와 시스템 간, 시스템 컴포넌트들 간의 상호 작용을 보여준다.
-
클래스 다이어그램: 시스템의 객체 클래스들과 클래스들 간의 연관을 보여준다.
-
상태 다이어그램: 시스템이 내부 또는 외부 이벤트에 대해 어떻게 반응하는지 보여준다.
컨텍스트 모델
- 컨텍스트 모델은 시스템의 운영 컨텍스트를 설명하는 데 사용된다. 사회적 및 조직적 관심은 시스템 경계를 배치할 위치에 대한 결정에 영향을 미칠 수 있다.
- 아키텍처 모델은 시스템 및 다른 시스템과의 관계를 보여준다.
시스템 경계
시스템 경계는 시스템 내부와 시스템 외부를 정의하기 위해 설정된다.
- 사용되거나 개발 중인 시스템에 의존하는 다른 시스템을 보여줌
시스템 경계의 위치는 시스템 요구 사항에 큰 영향을 미친다.
시스템 경계를 정의하는 것은 정치적 판단입니다.
- 조직의 서로 다른 부분의 영향력 또는 작업량을 늘리거나 줄이는 시스템 경계를 개발해야 한다는 압력이 있을 수 있다.
프로세스 관점
-
컨텍스트 모델은 개발 중인 시스템이 해당 환경에서 어떻게 사용되는지가 아니라 단순히 환경의 다른 시스템을 보여준다.
-
프로세스 모델은 개발 중인 시스템이 더 광범위한 비즈니스 프로세스에서 어떻게 사용되는지 보여준다.
-
UML 활동 다이어그램은 비즈니스 프로세스 모델을 정의하는 데 사용될 수 있다.
상호 작용 모델
사용자 상호 작용 모델링은 사용자 요구 사항을 식별하는 데 도움이 되므로 중요하다. 시스템 간 상호 작용 모델링은 발생할 수 있는 통신 문제를 강조하며, 구성 요소 상호 작용을 모델링하면 제안된 시스템 구조가 필요한 시스템 성능과 의존성을 제공할 가능성이 있는지 이해하는데 도움이 된다.
유스케이스 다이어그램 및 시퀀스 다이어그램은 상호 작용 모델링에 사용될 수 있다.
-
유스케이스 모델링 시스템과 외부 에이전트(사람 사용자나 다른 시스템들)와의 상호 작용을 모델링하는 데 주로 사용된다.
-
시퀀스 다이어그램: 시스템 컴포넌트들 간의 상호 작용을 모델링하는 데 사용되지만 외부 에이전트도 상호 작용에 포함될 수 있다.
유스케이스
-
유스케이스는 원래 요구 사항 추출을 지원하기 위해 개발되었으며 현재 UML에 통합되었다.
-
각 유스케이스는 시스템과의 외부 상호 작용을 포함하는 개별 작업을 나타낸다.
-
유스 케이스의 액터는 사람 또는 다른 시스템일 수 있다.
-
유스케이스에 대한 개요를 제공하기 위해 다이어그램으로 표시되고 더 자세한 텍스트 형식으로 표시된다.
액터
- 액터는 시스템 외부에 존재하며 시스템과 상호작용을 하는 모든 것을 표현함
- 시스템을 사용하게 될 사람은 물론이고, 다른 외부에 있는 시스템도 포함할 수 있음
- 시스템과 상호 작용하는 외부 개체가 사람이라면 막대 인간모양으로 표현하고 시스템이라면 박스에 «actor» 표기함(StarUML에서는 동일하게 표현)
주 액터 : 시스템의 서비스를 필요로 하는 액터
부 액터 : 시스템에 서비스를 제공하는 외부 개체를 의미함
유스케이스
유스케이스는 타원형으로 표시하고 시스템과 액터 간에 수행하는 일련의 상호작용을 표현한다.
관계
관계는 액터와 유스케이스, 유스케이스들 사이의 관계로 실선으로 연결한다. 관계는 3가지 유형이 있다.
- 포함관계(include)
- 필수적인 관계(반드시 수행)
- 여러 유스케이스에서 중복되는 단계가 있는 경우, 새로운 유스케이스 생성(재사용 가능)
Ex. A를 하면 B가 자동으로 실행됨 or A를 하기위해서는 B가 필요함
- 확장관계(Extend)
- 특정 조건이 만족되는 경우에만 유스케이스가 실행되는 옵션 관계
- 기준 유스케이스에 부가적으로 추가된 기능을 표현하기 위해 사용한다.
- 화살표의 방향이 포함관계와 반대다.
- 일반화 관계(상속)
- 액터들이 유스케이스와 중복하여 관계가 나타나면 액터들을 통합하여 일반화 관계로 표현
- 추상적인 액터와 더 구체적인 액터 사이에 관계를 연결함
- 연관관계(Association) : 액터와 정보를 주고받는 유스케이스를 설정해 실선으로 표시
유스케이스 모델링 단계
1단계: 시스템 상황 분석
- 시스템 상황을 분석하여 문제 기술서를 작성
2단계: 액터 식별
- 행위자와 그들의 책임을 확인
- 다음 질문으로 찾을 수 있음
- 시스템의 주요기능을 사용하는 사람이 누구인가?
- 시스템을 지원하기 위해 필요한 사람은 누구인가?
- 시스템을 유지하고 관리하는 사람은 누구인가?
- 시스템에 필요한 하드웨어 장치는 무엇인가?
- 시스템과 상호작용하는 다른 시스템은 무엇인가?
- 시스템의 처리결과에 연결되는 사람 또는 사물은 무엇인가?
3단계: 유스케이스 식별
- 액터 관점에서 시스템의 기능을 확인
4단계: 유스케이스 다이어그램 작성
- 액터와 유스케이스 관계를 설정
- 유스케이스에서 «include» 의존성이 있는지 평가
- 유스케이스에서 «extend» 의존성이 있는지 평가
- 액터의 일반화 관계를 찾음
5단계: 유스케이스 명세서작성
- 유스케이스명, 액터명 및 개요를 기술
- 사전 및 사후조건과 제약사항들을 식별
- 작업(정상, 대치, 예외) 흐름과 시나리오를 도출
- 유스케이스 흐름에서 포함이나 확장 유스케이스로 구조화
6단계: 유스케이스 실체화
- 구현 시스템의 논리적 구성요소인 클래스를 식별하고 통신관계를 파악하는데 중점
댓글남기기