소프트웨어 분석 및 설계 중간 정리

CH01. 모델링 개념

 

01. 시스템이란?

- 시스템: 비즈니스 문제를 해결하기 위한 목적으로 구성된 소프트웨어+하드웨어의 조합.

- 더 폭넓은 개념의 시스템: 컴퓨터 기반 솔루션 + 연관된 사람과 프로세스까지 포함.

 

이는 복잡성의 문제를 발생시킴.

 

! 소프트웨어 개발의 현실

- 정보시스템구축 프로세스인 Software Development Life Cycles(SDCL): IT시스템 및 개발과정을 이해하기 위해 중요.

시스템을 디자인하고, 구축하고, 유저들에게 인도하여 - 어떻게 정보 시스템이 비즈니스 요구를 충족시킬 수 있는지를 이해하는 절차.

 

- 성공적 시스템 개발은 '분석'으로부터 시작.

시스템 개발의 성패는 사용자의 비즈니스 목적 = 이윤창출에 얼마나 부합하는지로 결정된다.

 

! 소프트웨어 개발의 성공기준

On time, On budget, On target.

 

 

1. 시스템 개발 단계

1) 분석: 문제 영역의 요구사항이 무엇인지를 검증하기 위한 활동.

2) 설계: 요구를 만족시키는 솔루션 중 최적의 방법을 찾아가는 과정.

3) 구현: 설계에서 명시된 조건을 반영해 코딩, 테스팅 수행.

4) 테스트: 주어진 명세에 부합하는지를 자동, 수동으로 테스트.

다음의 4가지 단계는 밀접하게 관련, 순서대로 수행.

 

2. 소프트웨어개발생명주기 Software Developmet Life Cycle

계획 > 분석 > 설계 > 구현 > 테스트 > 인수설치.

 

3. 객체지향 개발단계의 활동

- 객체지향: 객체의 뷰로 보는 것을 의미.

1) 객체지향 분석: 문제영역problem domain을 구성하는 주요 개념+기능요구사항 정의.

2) 객체지향 설계: 시스템&서브시스템을 구성하는 객체와 클래스를 찾아내고, 이를 바탕으로 아키텍처 정의.

서로 어떻게 상호작용하는지를 설명.

3) 객체지향 코딩: 객체지향 언어를 사용해 구현.

 

4. 시스템을 보는 시각

- 정적인 측면

- 동적인 측면

- 기능적인 측면

각각의 측면은 독립적인 모형이고, 이 모형을 여러 형태로 표현, 분석한다.

 

1) 정적 구조: 데이터들의 관계를 보여주는 구조.

데이터들을 정의하고 + 그 관계를 분석한다.

2) 동적 구조: 시간의 흐름에 따른 시스템의 동작을 보여주는 구조.

각 객체의 상호작용을 구성하고 정의한다.

3) 기능 구조: 사용자의 시각에서 - 시스템의 작동, 서비스에 접근하는 정보를 보여주는 구조.

각 입장마다의 접근 정보.

 

 

CH02. 모델링

 

01. 모델이란?

1. 모델: 현실세계의 생각, 아이디어를 구체적으로 표현하기 위해 사용되는 방법.

 

2. 모델링: 해석하기 용이한 추상적인 디자인의 구축.

자체적으로 현상을 표현.

문제/솔루션의 표현에 대한 공통 이해를 가능하게 한다.

- 분석 기법: 모델을 대상으로 유용한 정보를 이끌어내기 위해 사용. 

 

- 모델의 구성자: 잘 정의된 구문/의미를 제공함으로 공통된 이해를 도움.

구성자인 모델링 언어) syntax: 4가지 파트로 분리되어 있음.

1) Name(Visivility)

2) Attributes: +Public, #Protected, -Private

3) Operations

4) Responsibilities 책임: 모든 오브젝트는 '무슨 일을 한다는 책임'이 질문되어야 함. 중요도의 기준. 필수 아님.

 

- 다양한 시각에서의 표현 가능.

- 사용자 시각/개발자 시각 공존.

 

3. 모델링의 주요 개념

1) 추상화

: 객체의 추상화 과정에서 속성/오퍼레이션을 구분.

상세함을 버리고 핵심적, 필수적 부분만을 추출.

 

- 추상화란?

불필요한 부분을 제거해가며 사물의 본질을 드러나게 하는 과정.

"하나만 제외하고" 모든 변수를 제거해 핵심적 의미를 발견하려 함.

 

2) 분류

관계 있는 개체들에 대한 그룹화 -> 대상의 특성을 이해.

 

- 이들은 왜 필요한가?

현실 객체는 데이터가 너무 많음. 시스템이 관심을 두어야 하는 데이터는 제한적.

 

 

02. 모델링 언어 UML

SW 모델을 표현하기 위한 시각적 언어. 다양한 시각 반영 가능. 일종의 의사소통 수단.

시스템의 구조/기능/행위 측면을 모델링 가능.

 

1. UML의 역사

세명이 그들의 방법론을 통합한 결과물.

 

2. UML의 능력과 한계

- 장점: 공통적인 개념 제공 -> 공통적 이해를 가능하게 함. 모델링 도구의 지원을 받음.

- 단점: 프로그래밍 언어가 아님(프로그래밍 불가능). 방법론이 아님(설계, 분석에 대한 구체적 절차 제시하지 않음). 구조적 분석에 적합하지 않음.

 

3. UML을 구성하는 모델 

1) 기능모델: 사용자 시각에서 시스템의 기능을 서술.

- 유스케이스 다이어그램 

2) 객체모델: 객체로 구성되는 시스템의 구조를 서술.

객체, 클래스, 속성, 오퍼레이션, 연관 등의 개념 사용. 

- 클래스 다이어그램.

3) 동적 모델: 시스템의 동적 행위를 모델링.

- 시퀀스 다이어그램, 활동 다이어그램, 상태 다이어그램.

 

! 다이어그램이 많은 이유: 시스템의 복잡성을 더 잘 이해하기 위해.

 

4. UML 의미론 - 4개의 레이어 모델

1) meta-metamodel: 메타 모델링을 정의함. 호환을 위해 사용.

2) metamodel (위의 모델): 모델의 구체적인 언어를 정의. Class, Attribute, Operation 등.

3) model: 메타모델의 예시. '정보 영역을 정의하기 위한 언어'를 정의. StockShare, askPrice 등.

4) usrer objects: 모델의 예시. 정보 영역을 구체적으로 정의. <Acme_SW_Share_98789>, 654.56 등.

 

 

03. 객체의 다양한 정의

 

1. 객체란?

객체는 잘 정의된 경계 내에서 보호되는 상태, 행위를 갖는다.

- 상태 state Attributes: 객체가 존재하도록 하는 여러 조건 중 하나.

속성에 관한 속성값, 다른 객체와의 연결로 구현.

- 행위 behavior Operations: 객체가 어떻게 행동하고, 반응하는지를 결정.

객체가 수행하는 오퍼레이션에 의해 표현.

 

2. 유일성

각 객체들은 고유의 식별자를 통해 독립적으로 식별.

- 객체의 식별이 필요한 이유: 고유성을 가지고 있어야만 개별적으로 접근 가능.

- 데이터와 객체의 차이점: 데이터는 그대로 존재. 객체는 접근할 수 있는 오퍼레이션이 묶여있는 상태.

 

3. 객체화

클래스: 객체를 생성하기 위한 템플릿 제공.

-> 클래스가 먼저 정의되어야 함. 클래스 = 일종의 데이터타입.

 

4. 클래스란?

: 객체에 대한 일반적인 정의, 표현물.

모든 객체는 클래스와 연관되어 있음.

 

! 구조체와 클래스

1) 프로그래밍 언어의 구조체와 클래스

구조체: 클래스와 유사한 구조(멤버필드, 멤버함수). 차이점은 멤버필드가 필드 연산자에 의해 직접 수정이 가능.

2) 구조체와 클래스의 차이

- 클래스 정의/구현을 분리 -> 재사용 편리.

- 멤버필드에 대한 안전한 접근 매커니즘 제공.

- 생성자, 소멸자, 멤버함수 등의 오퍼레이션 제공. (생성자, 소멸자의 역할은 객체 활용에서 정말 중요.)

 

 

 

CH03. 클래스 모델

 

01. Object behavior과 메서드

 

1. 행위: 객체가 어떻게 행동/반응하는지를 결정. 오퍼레이션을 통해 표현. 액션 <-> 리액션의 차이.

2. 메소드: 오브젝트의 행위를 구현. 오브젝트가 수행하는 액션.

1) 메세지는 메소드를 트리거하는 정보.

2) 메세지는 본질적으로 한 오브젝트에서 다른 오브젝트로 가는 기능.

= 타겟 객체에게 어떠한 액션을 요청하기 위해 전달.

 

3. 메세지 큐의 예시

메세지인 isEmpty()는 '촉발자'의 역할. 트리거이며 이벤트.

이벤트는 외부에서 전달되는 트리거를 말하기 때문에, 요청한 사람이 아니라 요청받은 사람의 operation/methods가 된다. 받은 사람이 실행하고 결과를 전달하기 때문.

= 요청을 받고 실행해 결과를 전달하는 것: interaction 객체의 행위.

 

 

02. 캡슐화

: 프로세스와 데이터를 하나로 결합하는 것.

 

1. 필요성

1) 속성에 대한 배타적인 접근: 속성을 오퍼레이션만을 통해 접근 가능하게 하는 것.

2) 멤버 데이터의 무결성을 보장하는 매커니즘. ex. 범위 밖을 제거하는 조건문 등.

 

 

03. 메세지 패싱: 객체들이 상호작용하는 방법으로 메세지 전송(= 데이터를 담은 오퍼레이션 호출)을 사용하는 것.

 

 

04. 클래스 구성요소

1) Class - meta-class

2) Object - Aggregation

3) Association - Generalization/Specialization

4) Multiplicity

 

 

05. 상속: 객체들 간의 공통적인 속성과 오퍼레이션을 분리. 개념의 재사용 단위.

1. 상속은 일반화/특수화 관계의 표현.

- 부모 클래스: 오브젝트들의 공통적인 속성들이 모여있는 클래스. 

- 자식 클래스: 속성들이 상속되고, 다른 클래스와 구분되는 클래스.

 

코딩에서는 재사용의 목적으로 사용되지만, 분석에서는 이해의 목적으로 사용된다.

- 특이한 매커니즘 Abstract Class: 부모 클래스의 변형 개념. 스스로는 오브젝트를 만들 개념이 없지만 자식 오브젝트를 만들 수 있다. 예외적.

 

 

06. 다형성

서로 다른 객체에서 동일한 이름의 오퍼레이션을 제공할 때, 동일한 이름이라 해도 작동 방식은 객체마다 다르다. 

 

- 구현하는 방식

1) 정적 바인딩: 이름은 동일해도 타입이 다르다면 구분되어진다. 아예 다른 함수로 구현된다.

2) 동적 바인딩: 실행시에 다르게 연결되기를 요구한다. 

 

 

07. 클래스 다이어그램의 연관

클래스는 수많은 관계들을 다른 클래스들과 가진다. 

 

1. 연관 Assosiation

1) 1:1로 연결된다. 두가지 이상의 관계로도 가능.

2) 존재하던 오브젝트들을 연결해 의미를 설정한다. 그 의미대로 이해해달라는 분석가의 시그널.

3) 다중성 Multiplicity: 1:1, 1:n, n:1, n:n - 0:n까지 가능하다.

 

2. 집합연관 Aggregation

1) 연관 중의 하나.

2) 1:n, 0:n의 관계를 말한다.

 

3. 복합연관 Composition

1) 한 객체와 연관된 객체와의 강한 관계. 중요점은 객체가 다른 객체와 복합연관된 객체로만 존재하는 것.

2) 불가분의 관계도 가능. 이게 집합연관과는 다르다.

 

4. 연관의 구분

일반적으로 다음의 포함관계 형성: Association > Aggregation > Composition

 

 

08. 의존 dependency: 메소드의 코드에 종속되는 경우.

두개의 클래스가 존재할 때, 하나의 구현이 변한다면 다른 클래스가 영향받는다면 의존관계이다.

 

 

09. 실체화: 상속과 유사하지만 다르다. 부모 클래스에게는 <interface>가 적혀있고, 속성이 없다. stero type라고 한다.

 

 

10. 표현

1. 클래스 표현

1) 클래스 다이어그램은 클래스명을 포함한다.

2) 클래스 집합을 패키지로 표현할 수 있다.

3) 클래스의 경로이름을 표현하는 경우 '::' 표기를 사용한다.

 

2. 속성의 표현

1) 속성은 클래스를 표현하는 중요 데이터 요소이다.

2) 객체의 경우, '속성:값'의 쌍으로 표현된다.

3) 경우에 따라 기본값이 부여될 수 있다.

 

3. 오퍼레이션의 표현

1) 오퍼레이션 명과 시그니쳐를 표현한다.

2) 시그니쳐는 함수 원형으로, 파라메터와 반환값 정보를 포함한다.

3) 스트레오 타입을 표기할 수 있다.

 

4. 어떻게 클래스를 찾아내는가?

문제에 대한 이해, 시스템 솔루션을 진행한다. 이해당사자와의 인터뷰를 통해 진행.

서술서를 작성한다.

 

 

 

CH04. 클래스 연관의 이해와 활용

 

01. 구조모델과 개념모델

: 실제 "비즈니스 문제"에 대해 반영하는 컨셉츄얼한 모델.

구조 모델의 초보적인 단계.

 

1. 구조 모델 - core elements

1) class

2) interface

3) component

4) node

 

1) association 연관

2) aggregation 복합연관

3) generalization 일반화

4) dependency 의존

 

2. 상속: 자식 클래스는 부모 클래스의 모든 것을 상속받으며, 거기에 자신의 유니크함을 더함.

1) 상속은 일반화에 가깝다.

! 일반화(대체가능성 존재) <-> 특수화.

2) 선택적 상속은 불가능하다.

3) 부모가 두 개 이상일 수 있다. 단일 상속/다중 상속으로 구분.

 

3. 클래스 상속

오브젝트를 생성하지 못하는 클래스가 이론적으로 존재할 수 있다. 이것을 aggregation(a-part-of) 연관관계로 이해 가능.

 

- 집합관계: 탄탄한 관계 <-> 느슨한 관계.

1) 복합연관: 탄탄한 관계.

(1) 하부 클래스는 상위 클래스에 종속적. 상위 객체 제거시 하위 객체도 제거된다.

(2) 상위 객체의 분해 관계로 이해 가능.

 

2) 집합연관: 느슨한 관계.

(1) 하나 이상의 클래스가 모여 새로운 클래스를 형성할 경우 표현.

(2) 복합연관과 유사하지만 느슨하다.

 

둘은 "상위 객체 삭제시"에 따라 분류된다.

 

5. 추상 클래스

1) 일반 클래스와 달리 객체를 생성하지 못함 - 생성자/소멸사 정의되지 않음.

2) 선언 존재, 구현 미존재.

3) 다른 클래스 정의시 규칙을 제시하는 용도로 사용된다.

 

-> 추상 클래스의 구현단계

- 추상 클래스의 코드는 C++에서 virtual로, Java에서는 abstract로 표현된다.

 

- 장점

(1) 확장성이 굉장히 뛰어나다.

(2) 컨트롤러 입장에서 디테일을 알아서 구현하되 공통점은 공유하기 때문에 - 편리하다.

 

 

02. 클래스 다이어그램 vs  객체 다이어그램

객체 다이어그램은 클래스 다이어그램에 기반하여 작성되지만 - 객체간 특정 상황을 묘사.

 

 

03. 인터페이스 클래스

1) 여러개의 클래스가 상호작용하는 경우 사용.

2) 이 경우 컴포넌트 단위로 포장되는 것이 일반적 - 컴포넌트 서비스를 담당하는 클래스를 인터페이스 클래스라 호칭.

3) 컴포넌트 클래스는 실체화가 요구된다.

 

- 속성이 없다. 창구를 만들고 그 창구를 통해 접근하는 목적.

 

1. 인터페이스의 표현

1) 인터페이스 클래스는 구현부/사용부 부분으로 구분되어 표현.

 

2. 인터페이스 실체화

- 컴포넌트 스펙 부분과 구현 부분을 분리.

-> 구현부의 변경이 발생해도 인터페이스 클래스를 사용하는 외부 클래스에 변경 미발생.

클래스의 유지보수에 도움을 주는 구조.

 

1) 인터페이스 클래스 구현시: 인터페이스 클래스는 다른 클래스 생성의 규약으로 사용. 이를 통해 다형성 지원, 코드의 유연성 증가.

 

 

 

CH05. 유스케이스 모델

 

01. 속성과 연관의 구분

두 클래스의 공통적인 특성이 있다면 속성 대신 관계를 설정한다.

 

1. 단방향 연관의 표현

방향성이 설정되었다는 것 = 방향을 주는 입장이 받는 입장의 정보를 attribute로 보유하고 있다는 것.

! 방향이 변했을 때는?

어느 관점에서 보느냐에 따라 달라진다. 

 

 

02. Use case

1. 유스케이스가 왜 중요한가?

1) 사용자들의 시각에서 시스템이 어떻게 보여지는지를 캐치하는 모델.

2) 유저들은 시스템이 어떻게 사용되도록 의도되어야 하는지 본인조차 모른다.

-> 아이디어에 사용자들을 초기부터 편입시켜, 피드백을 통해 원하는 것의 동의를 얻는다. 

3) 비즈니스 시스템이 어떻게 환경과 상호작용하는지를 알려주는 공식적인 자료.

 

2. "이해관계자"와 유스케이스

1) 이해관계자 관점의 유스케이스

- 이해관계자 중 일차 액터는 '어떤 목표를 달성하기 위해' 시스템과 상호작용한다.

- 일차 액터에 대한 시스템의 응답으로 '다양한 조건'하에 있는 시스템을 서술한다.

 

2) 시나리오는 이해관계자를 보는 창

: 특별한 요청과 조건에 따라 서로 다른 일련의 행위/시나리오가 전개된다.

- 시나리오는 특정 시각에서 기능을 바라보는 것.

- 목적을 달성하는 방법을 기능으로 본다.

 

3) 유스케이스는 외부 사용자 관점으로 시스템을 보는 것.

 

3. 유스케이스의 정의

: 특정 액터가 관찰할 수 있는 시스템의 수행 결과 값들을 생성하는 일련의 엑션을 명세한다.

1) 특정 액터: 개별 사람, 기계, 소프트웨어 등 - 액션을 유발하는 주체.

2) 관찰할 수 있는 결과값: 가장 중요한 항목 중 하나.

관리인이 점검버튼을 누른다 -> '누르면 시스템 버튼의 불이 들어온다.'

 

 

03. 분석 활동 관계

- 액터 찾기

- 시나리오 찾기

- 유스케이스 찾기

- 유스케이스 상세화

- 유스케이스 사이의 관계 찾기

 

1. 액터: 시스템과 상호작용하는 사람/어떤 것.

- 엑터의 세가지 종류

1) 사용자: 시스템 사용자

2) 다른 시스템/소프트웨어

3) 장치: 다양한 입출력장치.

 

2. 액터 파악 및 서술

1) 여러 질문을 통해 엑터에 대한 필요 정보를 얻는다.

2) 액터가 충족시켜야 할 행위의 종류가 있다.

 

3. 시나리오

- 시스템 사용시, 사용자가 무엇을 경험하는가를 글로 서술한다.

- 단일 엑터 관점에서 기능을 서술. 비정형적 서술.

- 매우 구체적인 사례를 서술.

- 정상적 경우 + 다양한 대안까지.

- 시나리오 = 유스케이스의 인스턴스.

 

4. 유스케이스의 작성

- 유스케이스를 시작하는 행위자

- 유스케이스 시작을 위한 선행 조건

- 시나리오 진행 단계

- 유스케이스 종룔를 위한 종료 조건

- 유스케이스 결과를 받는 행위자

 

5. 유스케이스 명세구성 요소

-> 기본 흐름

1) 요약 명세

2) 선조건

3) 후조건

4) 기본흐름 명세

 

-> 대안 흐름

--> 선택 흐름

1) 사용자 선택에 의한 흐름

2) 시스템 상태에 의한 흐름

3) 데이터 종류에 의한 흐름

 

--> 예외 흐름

1) 사용자의 오류 데이터 입력

2) 사용자 입력시간 초과

3) 시스템 처리시간 초과

4) 시스템 오류 발생

 

 

 

CH06. 유스케이스 모델2

 

01. 유스케이스의 파악

1) 분석가는 사용자들이 시스템을 통해 얻고자 하는 목적을 잘 알아내기 위한 질문을 해야 한다.

 

2) 유스케이스 파악을 위한 질문들

- 액터는 어떤 용도로 시스템을 사용하는지

- 액터가 시스템에 자료 입력/저장/변경/제거/참조를 하는지

- 액터는 외부 이벤트/변화를 시스템에 알려주는지

- 시스템은 액터에게 어떤 특정한 변화를 알려주는지

 

3) 유스케이스가 되기 위해서는 - '그것이 범위 안에 있는가?'의 질문을 통과해야 한다.

 

4) 기본 흐름의 파악을 위한 질문들

- 어떤 이벤트가 유스케이스를 시작시키는지

- 유스케이스는 어떻게 끝나는지

- 어떻게 유스케이스는 특정 행위를 반복하는지

 

5) 대안 흐름의 파악을 위한 질문들

- 유스케이스에 선택적인 상황이 존재하는지

- 특별한 케이스가 발생할 수 있는지

- 유스케이스에 변화가 가능한지

- 잘못될 수 있는지

- 예외 상황은 무엇인지

 

1. 엑터의 일반화

- 사용시점: 두 액터가 공통된 행위를 통해 커뮤니케이션 할 경우.

- 의미: 자식 액터는 부모 액터가 갖는 유스케이스와의 관계/역할을 그대로 상속.

잘 사용하지 않는다.

 

 

02. 유스케이스 다이어그램의 확장

1) 유스케이스 일반화: 더 일반적인 유스케이스와 더 특정한 유스케이스의 일반화 관계를 표현할때 사용.

2) 유스케이스 포함<<include>>: 다른 유스케이스의 행위를 자신의 유스케이스에 포함하고자 할 때 사용.

3) 유스케이스 확장 <<extend>>: 다른 유스케이스의 특정 부분을 자신의 유스케이스에 확장하고자 할 때 사용.

 

1. 유스케이스의 일반화

: 자식 유스케이스는 부모 유스케이스의 모든 특징을 상속받는다.

필요 부분을 추가할수는 있지만, 재정의는 제한적으로 허용된다.

 

1) 부모 클래스는 추상적인 부분에서 서술된다 - 모든 행동이 완성적일 필요는 없다.

2) 자식 클래스에서 구체적/완성적으로 서술되어야 한다.

 

2. 유스케이스 포함 <<include>>

: 재사용의 개념. 반복되어 서술되는 유스케이스가 있는 경우, 간결한 서술을 위해 사용.

포함을 사용하는 유스케이스는 클라이언트, 포함을 제공하는 유스케이스는 제공자 역할.

 

3. 유스케이스 확장 <<extend>>

: 기존의 유스케이스의 행위를 확장/추가시키는 용도로 사용.

기존의 유스케이스는 유스케이스가 포함될 지점을 의미하는 확장점을 제공.

 

 

03. 유스케이스 구성의 선행조건/종료조건

1) Pre-condition: 유스케이스를 시작할 때 충족되어 있어야 하는 조건.

항상 True가 되어있다고 가정된 상태에서 시작된다.

2) Post-condition: 조건이 충족되어야 올바른 결과라고 확인한다.

 

 

04. 유스케이스의 서술 형식

1. Basic 기본형

2. If 분기형

3. Alternative 분기형

4. For 루프형

5. While 루프형

6. 혼합형

7. 시나리오 분리형

 

 

 

CH07. 상태 모델

 

01. 상태 모델이란?

"시스템 내의 객체들은 사건/시간의 흐름에 따라 자신의 상태를 바꾼다."

 

- 상태: 시간의 흐름에 따라 변하는 객체의 값을 의미

1) 이를 표현할 수 있는 행위모델 필요.

2) 시스템의 변화를 모델링하는 수단이 상태 모델.

3) 시작, 상태전이, 끝이 있다.

4) 유한상태기계로도 표현.

 

- 객체의 상태는 속성의 값과 그 특정한 시간에 다른 객체로의 관계로 정의된다.

- 객체의 속성은 상태에 영향을 주지만, 모든 속성이 상태에 영향을 주는 것은 아니다.

- 이벤트라는 것은 특정한 시간에 발생하는 사건으로, 객체의 상태에 영향을 준다.

- transitiion은 한 상태 -> 다른 상태로의 객체의 변화를 묘사하는 관계이다.

 

1. 상태의 예시

1) 스위치를 킬 때마다 온/오프.

2) 리모컨 버튼을 누르면 채널이 변경.

3) 세탁기는 시간이 흐르면 세탁 -> 헹굼으로 변경.

 

UML 상태 다이어그램은 시스템의 변화를 잡아낸다.

 

2. 상태 모델의 구성

- 상태

- 시작 상태

- 끝 상태

- 이벤트

- 전송

 

3. 상태의 표현

1) 상태의 구성: 상태이름, 상태변수, 활동.

2) 상태변수: 상태 진행에 도움을 주는 데이터.

3) 활동: 사건과 동작으로 구성.

- Entry: 시스템이 상태로 들어갈 때 수행.

- Exit: 시스템이 상태에서 빠져나올 때 수행.

- Do: 상태에 남아있는 동안 수행.

 

4. 상태전이

1) 화살표로 전이가 일어나는 원인을 제공하는 사건을 표시. (촉발사건/동작)

2) 촉발없는 사건: 이벤트가 발생하지 않아도 전이가 일어나는 경우.

3) 전이조건: [ ]로 표시. 

 

5. 상태의 변화

: 복잡한 상태를 표현하는데 이용.

- 하위 상태의 종류: 순차적 하위상태/동시적 하위상태.

위의 둘, 중복 상태의 표현이 가능하다. 

 

6. 이력상태

: 이전 상태를 모두 기억하고 싶은 경우 사용.

- Deep history: 모든 이력을 기억.

- Shallow history: 바로 전 단계만 기억.

 

7. UML 2.0의 변화

연결포인트의 도입: 진입포인트/탈출포인트.

 

8. Transition table: 상태 모델을 테이블의 형태로 변환한 것.

명세/다이어그램/테이블은 모두 동일하며, 모델의 검증 - 시뮬레이션을 가능하게 한다.