1강
소프트웨어 모델링은 개발 프로세스의 필수적인 부분
- 시스템에 대한 더 나은 이해는 다양한 관점, 요구모델, 정적모델, 동적 모델 등을 고려해야 함
UML
- 표준화된 그래픽 언어
- 객체지향 모델을 설명하기 위한 표기법
- 객체지향적인 분석 및 설계 방법과 같이 사용
use case 다이어그램
- 시스템 기능적 요구사항은 사용사례 측면에서 정의
정적 모델링(static 모델링)
- 시스템의 구조적인 뷰(structural view)를 제공
- 클래스는 클래스의 속성과 다른 클래스의 관계에 의해 정의됩니다.
동적 모델링(dynamic 모델링)
- 시스템의 동작을 확인
- use case는 참여 객체간의 상호작용을 보여주기 위해 구현됨
소프트웨어 아키텍처 설계
소프트웨어 아키텍처란 : 소프트웨어 요소, 요소들의 외부적으로 보이는 속성, 그들 사이의 관계를 구성하는 시스템의 구조
high level의 경우
- 소프트웨어 시스템을 서브시스템으로 분해하는 것을 설명 가능
low level
- 서브시스템을 모듈이나 컴포넌트로 분해하는 것을 설명 가능
comet
소프트웨어 개발 수명 주기의 요구사항, 분석 및 설계 모델링 단계를 다루는 반복적인 사용 사례 기반 및 객체지향 소프트웨어 개발 방법
2장
사용사례 다이어그램의 표기법
객체와 클래스에 대한 uml 표기법
클래스 다이어그램
연관관계 (association)
- 둘 이상의 클래스 사이의 정적인 구조적 관계
연관 관계의 다중도 (the multiplicity of an assocation)
- 한 클래스의 인스텀스가 다른 클래스의 단일 인스턴스와 관련 될 수 있는 갯수를 지정
집계 및 합성 계층(Aggregation and compsition hierarchies)
- 전체/부분 관계
- compsition 관계가 더 강한 형태의 전체/부분 관계
Interaction 다이어그램의 종류(상호작용 다이어그램)
커뮤니케이션 다이어그램
협력하는 개체가 서로 메시지를 주고 받으면서 동적으로 상호작용하는 방법을 보여줌
시퀀스 다이어그램
- 객체간의 상호작용을 설명하는 다른 방법
- 시간 순서대로 배열된 객체의 상호작용을 묘사
state machine 다이어그램
state transition 다이어그램(상태 전이 다이어그램)
시스템 또는 객체의 제어 및 시퀀싱 뷰를 모델링하는데 사용
- real time 시스템의 경우 매우 state-dependent(상태 의존적)이다.
시스템의 동작은 입력 뿐만이 아닌 시스템에서 이전에 발생한 일에 따라 달라짐 - state transition 기게를 정의하는데 사용되는 주석은 state transition 다이어그램, state chart, state transition 테이블이 있다.
- 상태 의존성이 높은 시스템에서 이러한 표기법은 시스템의 복잡성을 이해하는데 통찰력을 제공
event, condition, action
- 상태전환 시 Event [condition]/ Action 이라는 주석을 사용
- 상태 전환(state transition)은 이벤트를 발생시키는 원인
- 상태 전환이 발생하려면 boolean 조건이 true여야 함
- optional action은 전환의 결과를 나태냄
두개중 하나의 상태를 가진다.
- 상태가 입력되었을 때 수행되는 진입(entry) 액션
- 상태가 완료되었을때 수행되는 종료(exit) 액션
패키지
- uml에서 패키지는 모델 요소의 그룹화로 표현됨
- 클래스, 객체 또는 사용사례(class, object, use case)를 포함하는데 사용할 수 있다.
Concurrent Communication 다이어그램
- active 객체(concurrent object)에는 고유의 제어 스레드가 존재하며,
다른 객체와 동시에 실행될 수 있음 - passive 객체는 별도의 제어 스레드가 없으며, 다른 개체가 자신의 작업 중 하나를 호출 할 떄만 실행됨
- ada, 자바 같은 일부 객체지향 언어와 메소드는 actice 객체를 지원
sequential application(순차적 응용 프로그램)
- 순차적 응용 프로그램은 수동 객체로 구성되며, 제어 스레드가 하나뿐인 순차 프로그램
- 객체가 다른 객체에서 작업을 호출하면 제어권이 전달이 됨
- 순차적 응용 프로그램에서는 synchronous(동기식) 메시지 통신(procedure call-절차 호출, method invocation-메서드 호출)만 지원
Concurrent application(동시 응용 프로그램)
- 여러개의 동시 개체가 존재
- 비동기 메시지 통신을 지원
- Asynchronous(비동기식) 객체가 Asynchronous 객체를 대상으로 메시지를 송신 할 경우,
대상 객체의 메시지 수신 여부와 관계 없이 계속 실행가능.
asynchronous(비동기식) 메시지 표기법 : loosely coupled
synchronous(동기식) 메시지 표기법 : tightly coupled
deployment 다이어그램
노드간의 물리적 연결 측면에서 시스템의 물리적 구성(ex : 네트워크 구성)
UML Extension Mechanisms (uml 확장 메커니즘)
Stereotypes (고정관념)
-
기존 빌딩 블록(building block)으로부터 파생된 새로운 빌딩 블록을 정의
-
uml에는 몇몇 스테리오 타입을 정의하는 방법이 있음
-
<< 스테리오 타입 정의법 >>
Tagged Values (태그 부착)
- uml 빌딩 블록의 속성을 확장
ConstraintsPage (제약조건)
- 참이어야 하는 조건을 지정
5장
COMET 이란 use case를 기반으로 한 소프트웨어 라이프사이클 모델
- 사용사례를 기반으로 하는 반복되는 소프트웨어 개발 프로세스
- 시스템의 기능적 요구사항은 액터와 사용사례의 관점에서 기술됨
- analysis 모델에서 사용사례는 사용사레에 참가하는 객체간의 상호작용을 묘사하기 위해 작성됨
- design 모델에서 소프트웨어 아키텍터는 구성요소와 그 인터페이스를 기술하기 위해 개발됨
COMET의 use case 기반의 소프트웨어 라이프 사이클
요구사항 모델링(requirements 모델링)
- requirements 모델은 시스템의 기능적 요구사항을 액터 및 사용사례 측면에서 설명하는 요구사항 모델
- 각 사용사례에 대한 서술형 설명이 전개됨
- 요구사항을 잘 이해하지 못한 경우, 임시로 프로토타입을 구현하여 요구사항을 명확히 하는데 도움을 줄 수 있음
analysis modeling
- 시스템의 정적/동적인 모델을 개발
- 정적 모델의 경우
-> problem 도메인 클래스 간의 구조적 간의 관계를 정의
(클래스와 클래스간 관계는 클래스 다이어그램에 작성) - 동적 모델인 경우
-> use case에 참여하는 개체와 개체간 상호작용하는 방식을 보여주기 위해 use cse 모델의 사용사례를 구현
(개체와 개체의 상호작용은 커뮤니케이션/시퀀스 다이어그램으로 표시)
design 모델링
- 시스템의 소프트웨어 아키텍처를 설계
-> 분석 모델의 경우 운영환경에 매핑됨( which the analysis model is mapped to an operational environment) - 시스템을 서브시스템으로 구조화 하기 위한 Subsystem structuring criteria(서브시스템 구조기준)이 제공됨
Incremental(점층적) 소프트웨어 구조
- 하위집합의 클래스의 상세 설계, 코딩 , 단위 테스트로 구성
- 전체 시스템이 구축 될때 까지 소프트웨어가 점진적으로 구축되고 통합되는 단계
- 각 소프트웨어를 점층적으로 통합 테스트를 수행
- use case 별로 통합 테스트 사례를 개발
-> 통합 테스트는 white box 테스트의 한 형태로, 각 use case에 참여하는 개체 간 인터페이스를 테스트 - 소프트웨어의 규모가 커질 수록 점층적인 프로토타입이 형성됨
- 어느정도 소프트웨어의 규모가 커졌을 때, 1~3번을 반복하여 소프트웨어를 구축하고 통합한다.
4.1. 문제가 발견될 경우, 요구사항/분석/설계 모델링 단계를 반복해야 할 수도 있음
System testing
- 시스템 테스트에는 시스템의 기능 테스트가 포함됨
-> 시스템의 기능적 요구사항에 대한 테스트 - 블랙박스 테스트로써, 블랙박스 사용사례를 기반으로 한
-> 따라서 블랙박스 사용사례 별로 기능 테스트 케이스를 구축해야 함 - 고객에게 제공되는 소프트웨어가 증가하면 시스템 테스트 단계를 거쳐야 함.
comet과 다른 소프트웨어 개발프로세스 같이 사용하기
comet의 경우
- analysis는 문제를 분해하는 것
- design은 해결방안을 합치는 것
으로 정의 함
requirements 모델링의 활동들
use case 모델링
- 시스템의 기능적 요구사항을 사용사레 및 액터 측면에서 설명
비기능적 요구사항
- 비기능적 요구사항을 해결하기 위해 use case 모델링 접근법을 사용할 수 있음
- uml에선 이것을 다루지 않음
analysis 모델링의 활동들
정적 모델링
-
문제별 정적 모델(problem-specific 모델)을 정의
-
정적 모델은 시스템에게 제공되는 정보의 구조적인 뷰
-
클래스는 다른 클래스와의 관계 뿐만이 아닌, 속성도 같이 정의 됨
-> operation은 설계 모델에서 정의됨객체 구조
-
각 사용사례에 참여하는 개체를 결정
-
object structurig criteria(객체 구조 기준)은 entity 객체, boundary 객체, control 객체, application logic 객체가 될 수 있는'시스템의 소프트웨어 객체'를 결정할 수 있게 제공됨
동적 상호작용 모델링(Dynamic interation modeling)
- use case는 각 사용사례에 참여하는 객체간 상호작용을 나타내도록 구현
- 커뮤니케이션/시퀀스 다이어그램은 use case를 실행하기 위해 객체가 서로 통신하는 방법을 보여주기 위해 개발됨
동적 상태 기계 모델링(Dynamic state machine modeling)
- 시스템의 상태-의존 뷰(state-dependent view)는 계층적 상태 차트(hierarchical statechart)를 사용하여 정의 됨
design 모델링의 활동들
소프트웨어 아키텍처를 설계하기 위해 다음과 같은 활동을 수행합니다:
- 객체 커뮤니케이션 모델 통합 (13장)
- 서브시스템 구조 및 인터페이스에 대한 의사결정 (13장)
- 소프트웨어 아키텍처에서 사용할 소프트웨어 아키텍처 및 설계 패턴 결정(12장, 15장, 16장, 17장 및 18장)
- 클래스 인터페이스, 특히 순차적 소프트웨어 아키텍처에 대한 의사결정(14장)
- 분산 애플리케이션을 분산 서브시스템으로 구조화하는 방법에 대한 의사결정(13장, 15장, 16장 및 17장)
- 사물의 특성, 특히 능동적인지 수동적인지에 대한 판단(18장)
- 메시지의 특성, 특히 비동기적인지 동기적인지 여부를 결정합니다(12장, 13장, 15장, 16장, 17장, 18장)
소프트웨어 아키텍처
- 소프트웨어 설계 모델링 중에 소프트웨어 아키텍처의 특성과 관련된 설계 결정이 내려집니다
- 이 교과서의 설계 모델링 부분의 장은 소프트웨어 아키텍처의 다양한 종류의 설계에 대해 설명합니다. • 객체 지향 소프트웨어 아키텍처(14장)• 클라이언트/서버 소프트웨어 아키텍처(15장)• 서비스 지향 아키텍처(16장)• 분산 컴포넌트 기반 소프트웨어 아키텍처(17장)• 실시간 소프트웨어 아키텍처(18장)• 소프트웨어 제품군 아키텍처(19장)
6장
use case 모델링
- 시스템의 기능적 요구사항을 설명하기위한 접근 방식
요구사항 모델링
요구사항 분석
- 사용자를 인터뷰
- 기존 시스템 분석
요구사항 명세
요구사항 명세서
- 이후의 설계 및 개발의 출발점이기 때문에, 사용자와 개발자 모두가 동의해야 하는 문서
기능적/비기능적 요구사항
- 기능적 요구사항 : 시스템의 목적을 위해 시스템이 갖추어야 할 기능을 설명
- 비기능적(품질) 요구사항 : 시스템이 달성해야 하는 서비스 품질 목표
Good Software Requirements Specifications(SRS)
- IEEE가 권장하는 요구사항 명세서
use case
- 하나 또는 다수의 액터 사이의 상호작용하는 시퀀스를 정의
- 일반적으로 목표를 달성하기 위한 역할과 시스템 간 상호작용을 정의하는 단계의 목록
요구사항 단계에서 use case 모델이란
- 액터와 시스템간의 상호작용을 사용자 입력과 시스템 응답으로 구성하여 서술
- 액터 및 use case 측면에서 시스템의 기능적 요구사항을 설명
- 시스템을 블랙박스로 취급
-> 사용자의 입력에 따라 수행하는 작업이 정해짐
액터와 use case
- 액터는 시스템에 요청하면 시스템은 응답을 제공
- 일반적인 use case는 여러가지 상호작용으로 구성
- 두개 이상의 액터가 포함될 수 있음
use case의 구성
- 사용사례의 이름
- 액터의 이름
- 사용사례 요약
- 메인 이벤트 시퀀스에 대한 설명
- 메인 시퀀스의 대안에 대한 설명
actor
시스템과 상호작용하는 유일한 외부 개체
(인간, 외부 시스템, I/O 장치, 타이머 등)
- 시스템의 일부가 아닌, 외부에 존재
- 동일한 유형의 모든 사용자가 수행하는 역할을 나타냄
- 졸라맨을 이용해 표현
주요/서브 액터(Primary and secondary 액터)
- 주요 액터가 use case를 개시
-> use case는 주요 액터의 입력으로 시작됨 - 서브 액터(다른 액터들)도 use case에 참여 가능
- use case의 주요 액터도 다른 use case의 서브 액터로 참여 가능
액터의 일반화 - 구체화
사용사례 파악
시스템의 use case를 확인
- 액터와 시스템의 상호작용을 고려
-> 시스템의 기능적 요구사항을 use case 측면에서 기술 - use case를 개발할 땐 몇가지 작은 use case가 시스템의 작은 개별 기능을 설명하는 기능적 분해(functional decomposition)를 피하는 것이 좋다
use case의 메인 시퀀스
- 액터와 시스템 간의 가장 일반적인 상호작용 순서를 ㅅ러명
대체 시퀀스(alternative sequances)는 특정 상황에서만 작동함
-> ex) 비번이 틀린 경우
시나리오
- use case를 사용한 각 시퀀스
- 한 사용사례의 처음부터 끝까지 보여주는 메인 시퀀스와 서브 시퀀스의 조합
use case relation ship
- 사용사례가 너무 복잡해지면 사용사례간 의존성이 높아질 수 있음
- 확장성을 늘리고 활용사례를 재사용하는 것
include relationship(포함 사용사레)
포함 사용사례(inclusion relationship)
- 여러개의 사용사례에서 공통 시퀀스를 추출하여, 새로운 사용사례를 만든 것
base use case
- 공통 시퀀스를 포함 사용사례로 분리하면, 그 사용사례는 재사용이 가능
- 이 경우, 공통 시퀀스가 제거 되었으므로 이전 사용사례 다이어그램은 더 간결하게 정의 가능
- 이 간결해진 예전 사용사례를 (포함 사용사례를 포함하여) base use case 라고 함
장기 사용사례의 구조화(structuring a lengthy use case)
- 포함 사용사례는 장기 사용사례의 구조화에도 사용가능
- base use case는 하이레벨 시퀀스 상호작용을,
- inclusion use case는 로우 레벨 시퀀스 상호작용을 제공
확장관계
확장관계(extend relationship)
- 상호작용의 선택적, 예외적, 대안 시퀀스가 많아지면 use case가 너무 복잡해 질수 있음
- 이 경우 대안, 선택적 상호작용 시퀀스를 별도의 사용사례로 분리해야 함
- 확장된 use case는 base use case, 확장을 수행하는 use case를 확장 사용사례(extension use case)라고 함
다음과 같은 상황에 사용된다
- 특정 상황에만 실행되는 base use case의 조건부 부분을 보여줄때
- 복잡한 경로, 또는 대안 경로를 모델링 하는 경우
extension point(확장점)
- 확장이 가능한 경우, base use case에서 정확한 위치를 지정할 때 사용
insertion segment
- 확장 사용사례의 경우, 확장점에 대한 삽입 세그먼트(insertion segment)가 존재
- 세그먼트는 확장 지점에 도달시 실행할 동작 시퀀스를 정의
- use case의 인스턴스가 실행되어, base use case에서 확장점에 도달한 후, 특정 조건을 만족할 경우 insertion segment로 실행이 이전됨
use case structuring 가이드라인
너무 작은 기능의 경우, 별도의 사용사례로 작성하는 것은 기능적 분해(unctional decomposition)가 발생
-> 지나치게 복잡한 사용사례 모델이 될 수 있다
use case package
- 대규모 시스템의 경우 사용사례 모델에서 수많은 사용사례를 처리해야 하는 경우가 자주 발생한다
- use case package를 사용하여 관련된 사용사례를 그룹화 하는 것이 좋다
- 사용사례 패키지는 시스템 기능의 주요 하위 집합을 다루는 높은 수준의 요구사항을 나타낼 수 있다
activity 다이어그램
- workflow 모델링에서 주로 사용
- 활동의 순서, 의사결정 노드, 루프 및 동시 활동(concurrent activities)도 표현 가능
- 메인시퀀스와 모든 대체 시퀀스를 포함한 use case의 순차적인 단계를 나타내기 위해 activity 다이어그램을 사용할 수 있다
- 액티비티 다이어그램을 통해 사용사례관 시퀀스를 나타낼 수도 있다.
7장 정적모델링
- 시스템의 클래스와 클래스의 속성을 정의
- 클래스 간의 관계와 클래스의 오퍼레이션을 정의
association
- 두개 이상의 클래스 간의 관계
- 클래스 간의 정적인 구조적 관계를 표현
commet에서의 클래스 다이어 그램 표기법
연관관계의 다중성
- 인스턴스가 다른 클래스의 인스턴스와 관련될 수 있는 갯수
self association
한 클래스 안의 인스턴스와 다른 인스턴스의 연관관계
association class
- 두개 이상의 클래스 사이의 복잡한 연관관계에서 볼 수 있는, 속성을 가지는 연관관계
- 연관관계의 속성 == 연관관계 클래스 속성
- 다대다 연관관계에서 자주 발생
composition과 aggregation
연관관계의 특별한 형태
전체부분관계(whole/part relation ship)
합성
- 집합보다 더 강한 관계
- 부분 객체는 전체와 함께 생성되고 삭제됨
- 부분 객체는 하나의 전체에만 속할 수 있음
집합
- 일반적인 연관관계보다 강한 관계
- 약한 전체부분관계
- 부분 객체를 추가 또는 제거할 수 있음
general/specialzation 계층구조
- 공통 속성을 가진 경우 제너럴 클래스로 추상화됨 -> 수퍼 클래스라고도 함
- 공통되지 않은 속성들은 구체화됨 -> 서브 클래스라고 함
제약조건(constraint)
- 반드시 참이어야 하거나, 구체적인 조건을 지정
- 제약조건은 텍스트 언어로 표현
- uml에선 제약을 표현할 수 있도록 OCL을 제공
- 속성이 가질 수 있는 값과 연관관계에 대한 제약 두가지가 존재
개념 정적 모델(conceptual static model)
- comet에선 문제 영역을 모델링하고 이해를 돕기 위해 사용되는 개념적 정적 모델을 분석 단계 초기에 가지는 것
problem domain의 정적 모델링
- 물리적 클래스와 엔티티 클래스를 모델링 하는 것이 우선
물리적 클래스(physical class)
- 물리적 특징을 가진 클래스
-> 실제로 보고 만질 수 있음 - 물리적 장치, 사용자, 외부 시스템 등
- 여러 물리적 장치가 있는 임베디드 시스템에서 클래스 다이어그램은 물리적 장치 모델링에 도움을 줄 수 있음
엔티티 클래스
- 개념적인 데이터 집약적(data-intensive)인 클래스로 long-living 특성을 가짐
context 모델링
- 시스템 내부와 외부를 명시적으로 식별
- 전체적인 시스템(total system)이나 소프트웨어 시스템 레벨에서 사용
uml과 스테리오 타입
<<entity>>로 표기comet에서 유사한 특징을 가진 클래스를 그룹화하는 것을 권장함
uml의 스테리오 타입은 다양한 종류의 클래스를 구분하기 위해 사용
External 클래스(외부 클래스 모델링)
외부 계층의 분류
- 스테리오 타입은 다양한 종류의 외부 계층을 구분하기 위해 사용
- external user class, an «external device» class, an «external system» class, or an «external timer»로 구분됨
- 외부 사용자가 표준 I/O(키보드, 마우스 등)를 통해 소프트웨어 시스템과상호작용하는 경우, 'external user'로 표현
- 어플리케이션 별 I/O 디바이스(application I/O device)를 통해 상호작용하는 경우, external I/O device로 표현
- 시스템이 데이터를 송수신하기 위해 다른 시스템과 접근할 때, external system로 표현
- 응용 프로그램이 시간을 파악해야 하거나, 외부 타이머 이벤트가 필요한 경우, external timer로 표현
엔티티 클래스
- 개념적인 데이터 집약적인 클래스
-> 데이터를 저장하고 엑세스를 제공하는 것이 주된 목적
problem 도메인을 정적모델링 하는경우
- comet에선 문제에 정의된 엔티티 클래스의 속성 및 관계를 정의 하는 것
객체지향 정적 모델링과 개체-관계 모델링(object-oriented)의 차이점
- 둘다 모델 클래스, 클래스의속성, 클래스의 관계에 접근하나,
개체-관계 모델링은 클래스의 오퍼레이션을 구체화 할 수 있다
