객체지향 소프트웨어 모델링을 위한 표준 그래픽 언어
요구사항 표현
1. 사용사례 다이어그램(Use case diagram)
1) 설명
- 시스템과 외부와의 상호 작용을 묘사하는 다이어그램
2) 다이어그램 표시 요소
- 사용사례 : 시스템의 목적
- 액터 : 사용사례를 이용하는 사람이나 외부 시스템
- 관계: 액터와 사용사례간 관계
3) 관계 표현
- 확장(Extension) : 선택적인 인터랙션을 명시적으로 나타낼때 또는 예외적인 사례를 다룰때 사용(상속개념과 유사)
- 일반화(Generalization) : 여러 유사 사용사례로 일반화 함
- 포함(Inclusion) : 여러 사용사례의 공통적인 부분을 표현
4) 장점
- 시스템의 범위를 정하는데 도움이 됨
- 개발과정을 계획하는데 도움이 됨
- 요구를 개발하고 검증하는데 사용됨
- 테스트케이스를 정의하는데 기초가 됨
- 사용자 매뉴얼 구성하는데 사용될 수 있음
정적인 부분 표현
1. 클래스 다이어그램 (Class Diagram)
1) 설명
객체지향 시스템의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타내는 다이어그램
2) 다이어그램 표시 요소
- 클래스 : 자료 타입 그 자체를 나타냄
- 속성 : 객체의 상태 또는 성질
- 오퍼레이션 : 클래스와 그 인스턴스에 의하여 수행될 함수를 나타냄
- 연관관계 : 클래스 인스턴스 사이의 관계를 나타냄
부가설명)
- 추상 클래스 : 인스턴스가 없는 클래스
- 추상 오퍼레이션 : 구현이 없는 오퍼레이션
3) 가시성 표현
- '+' : public : 패키지 외부에서도 접근 가능
- '#' : protected : 하위 클래스로부터의 접근이 가능
- '-' : private : 클래스 내부에서만 접근이 가능
- '~' : package : 속한 동일 패키지 내에서만 가능
부가설명)
유도 속성 ( '/' : derived)
- 다른 속성에 의해 결정될 수 있는 속성
- 가시성과 속성의 이름 사이에 표시
4) 관계 표현
- '*' : 연관관계 끝에 다중도를 표시
- Aggregation : 전체와 부분의 관계를 나타냄 (is part of)
- Composition : 합성관계는 Aggregation보다 강한 관계로 집합이 소멸되면 부분도 소멸됨(is composed of)
- Propagation : 전체 개념의 오퍼레이션이 부분 개념의 오퍼레이션에 의하여 구현되는 현상
부가설명)
- 인터페이스 : 객체집합이 가지는 행위의 일부를 가시화 한 것으로 클래스와 유사하나 인스턴스 변수와 구현 메소드가 없음
2. 객체 다이어그램 (Object Diagram)
1) 설명
인스턴스들과 링크 파악, 객체들 사이의 관계 표현하는 다이어그램
- Data/Object 구조를 설명하고 Snapshot 구체화
- 분석과 설계단계에서 정의됨
참고)
클래스 다이어그램과 차이점 : 객체들의 이름 밑에 밑줄이 그어지며 연관된 모든 인스턴스들이 표현됨
3. 패키지 다이어그램 (Package Diagram)
1) 설명
관련된 클래스를 패키지로 묶어 의존도를 낮추기 위해 사용
2) 패키지
- 공통적인 특성을 가진 클래스들의 모임
- 재사용의 단위가 됨
3) 관계
- 점선 화살표는 의존관계를 나타냄
- 컴파일 타임에 바인딩
4. 컴포넌트 다이어그램 (Component Diagram)
1) 설명
구현에 대한 물리적인 컴포넌트 간의 구성과 의존 관계를 표현
5. 배치 다이어그램 (Deployment Diagram)
1) 설명
시스템의 소프트웨어와 하드웨어 컴포넌트 사이의 관계 표현, 물리적 단계와 응용 프로그램과의 네트워크 연결을 모델링
- 컴포넌트 분포의 구체화
- 성능상의 병목현상 파악
1. 순차 다이어그램 (Sequence Diagram)
1) 설명
객체 간의 메시지 전달을 시간적 흐름에서 표현하는 다이어그램
- 개체가 다이어그램에 수평으로 정렬됨
- 인터랙션을 구동하는 액터를 왼쪽에 표시
- 수직축은 시간의 흐름을 나타냄
- 객체마다 라이프 라인이라 불리는 수직 점선을 붙임
- 객체가 소멸된 후에는 라이프 라인이 중지되며 'x'로 표시
- 객체가 구동 중임을 표시하려면 라이프 라인에 액티베이션 박스를 그림
- 메시지는 송신자와 수신자의 액티베이션 박스 사이에 화살표로 표시
- 메시지 이름과 매개변수를 나타내는 레이블을 붙임
참고)
객체에 대한 반복 수행은 메시지 이름 앞에 '*'를 붙여 표시
2. 협동(협력) 다이어그램 (Collaboration Diagram)
1) 설명
객체와 객체가 주고받는 메시지를 중심으로 표현하는 다이어그램
- 협동 다이어그램은 객체가 노드인 네트워크임
- 객체들 사이에 커뮤니케이션 링크가 추가 됨
- 메시지가 링크에 추가
- 화살표에 메시지 이름을 붙임
- 메시지가 호출되는 순서는 메시지 앞에 숫자를 적어 표시
2) 커뮤니케이션 링크
- 객체에서 다른 객체로 메시지를 보내는 것은 항상 커뮤니케이션 링크로 표시
3) 메시지 교환이 발생하는 경우
- 두 객체의 클래스가 연관관계에 의하여 결합한 경우
- 메시지를 받는 객체가 보내는 객체의 로컬 변수로 저장된 경우
- 메시지를 받은 객체에 대한 레퍼런스가 보내진 이전 메시지의 매개변수가 되는 경우
- 받는 객체가 전역변수 인 경우
- 객체가 네트워크를 통하여 커뮤니케이션 되는 경우
참고)
순차, 협동 다이어그램 선택방법
- 순차 다이어그램
- 메시지의 순서를 드러내 보여주고 싶을때
- 사용사례의 시간 순서를 드러내 보이고 싶을때
- 사용사례로부터 인터랙션 모델을 구축할 차 다이어그램
- 메시지에 자세한 사항을 나타내고 싶을때
- 협동 다이어그램에서는 자세한 것을 나타낼 공간이 없음
- 협동 다이어그램
- 클래스 다이어그램의 투영
- 클래스 다이어그램을 검증할때 이용
3. 상태 다이어그램 (Statechart Diagram)
1) 설명
- 외부 자극에 대한 시스템의 동적 상태 변화를 나타냄.
- 외부 이벤트에 대하여 민감하게 상태를 변화시키는 객체를 모델링
- 시스템 전체, 일부, 개별 객체에 대한 동작을 나타냄
- 노드는 상태를 나태내며 아크는 트랜지션을 나타내는 방향성 있는 그래프
2) 상태
- 주어진 시점에 시스템은 어떤 상태에 있음
- 이벤트가 발생하여 상태를 변화시키기 전까지는 그 상태에 머물러 있음
- 상태는 둥근 사각형 안에 상태 이름을 표시하여 나타냄
참고)
특수상태
- 시작 상태는 검은 원으로 표시
- 종료 상태는 원이 둘려진 검은 점으로 표시
3) 트랜지션
- 이벤트에 대한 상태변화를 나타냄
- 트랜지션 위에는 상태변화를 일으키는 이벤트를 표시
4) 액티비티
- 시스템이 어떤 상태에 있을때 발생하는 것
- 일정 시간이 소비됨
- 어떤 상태에서 빠져 나오는 트랜지션이 이루어짐
5) 액션
- 시간의 경과 없이 바로 일어날 수 있는 것(감지할 수 없는 적은 시간을 소비)
- 특정 트랜지션이 이루어질 때
- 특정 상태로 진입할 때
- 특정 상태에서 빠져나올 때
4. 액티비티 다이어그램 (Activity Diagram)
1) 설명
업무의 흐름을 모델링하거나 객체의 생명주기를 표현하는 다이어그램
- 상태 다이어그램과 유사하나 대부분의 트랜지션이 내부 이벤트에 의해 이루어진다는 것이 다름
- 객체나 컴포넌트가 수행하는 작업의 흐름을 이해하는데 사용
- 다른 사용사례 사이의 관계나 상호작용을 가시화하는데 사용
2) 병행처리 표현
- fork는 단일 입구 트랜지션과 다수의 출구 트랜지션을 가짐
- 실행경로가 두개의 병행 스레드로 분할됨
- 모든 입구 트랜지션이 트리거되면 시스템의 모든 출구 트랜지션이 이루어짐
- 모든 입구 트랜지션이 이루어진 후 출그 트랜지션 발생
- 입구 트랜지션은 분리된 스레드에 의하여 트리거됨
- 먼저 이루어진 입구 트랜지션은 다른 입구 트랜지션이 이루어질 때까지 기다림
3) 스웜레인
액티비티 다이어그램은 대체러 여러 클래스와 관련되며 같은 스웜레인 안에 있는 액티비티들은 동일한 클래스와 관련된 것
참고)
UML Spec : http://www.omg.org/spec/UML/
소프트웨어 모델링이 필요한가?
모델링은 건축이나 토목처럼 실제 만들다가 잘못된 것이 발생했을때 고치기 어렵거나 비용이 많이 드는 분야에서 사전에 모델링하여 문제를 최대한 파악하기위해 사용되었다.
소프트웨어 개발에서 모델링은 건축이나 토목처럼 그리 효율적이지 못하다.
그러나 하드웨어와 소프트웨어가 함께 구성되고 복수의 소프트웨어가 연동되거나 복잡한 구조를 갖는 소프트웨어 개발에는 효과적일 것이다.
실제 구현하면서 문제를 바로잡는 비용 ? 모델로 설계하여 예측/검사 후 구현하는 비용?
개발자의 경험이나 협업의 정도에 따라 UML을 효과적으로 적용하여야 한다.
효과적인 모델링 적용을 위해 필요한것은?
UML은 프로젝트를 위한 협업, 의사소통의 수단일뿐 툴이나 형식에 의존하면 안됨.
핵심적인 부분은 상세화하고 그 외는 전체 시스템을 파악할 수 있는 형태로 작성.
설계를 위한 다이어그램은 코드 작성하다 꼭 필요한 경우에만 작성.
기타 활용
개발을 위한 사전 설계 외에 교육 및 유지, 관리에도 효과적.
댓글 없음:
댓글 쓰기