analysis modeling - hanyang1. 분석 모델은 문제 혹은 비지니스 도메인 내에서...

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Analysis Modeling

CSE4006 Software Engineering


Overview of Analysis Modeling

1. 요구사항 분석

2. 분석 모델링 접근법

3. 데이터 모델링 개념

4. 객체지향 분석

5. 시나리오 기반 모델링

6. 클래스 기반 모델링

7. 흐름 기반 모델링

8. 행동 모델링

!2


Requirement Analysis

• 기술적 관점에서 소프트웨어공학은 대상 시스템의 분석 모델을 만드는 것으로 시작

• 요구사항 분석 • 소프트웨어의 운영(Operational) 특성 명세 • 다른 시스템 요소와 소프트웨어의 인터페이스 기술 • 소프트웨어가 충족해야 하는 제약조건(constraints) 수립

• 목적 1. 고객의 요구가 무엇인지 표현

2. 소프트웨어 설계를 위한 토대 마련 3. 소프트웨어가 구축되면 검증할 수 있는 요구사항의 집합을 정의

!3


Requirement Analysis

• 소프트웨어 엔지니어는 요구사항 분석을 통해 다음을 수행 • 요구공학의 초기 작업에서 확립된 기초 요구사항을 구체화 • 다음을 나타내는 모델 생성

- 사용자 시나리오 (user scenarios) - 기능적 활동 (functional activities) - 문제 클래스와 그 관계 - 시스템 및 클래스 동작 - 데이터 변환 흐름

!4


A Bridge

!5


Elements of Analysis Model

!6


Rules of Thumb

1. 분석 모델은 문제 혹은 비지니스 도메인 내에서 가시적인 요구사항에 초첨을 두어야 함 • 추상화 수준은 상대적으로 높아야 함

2. 분석 모델의 각 구성요소는 • 소프트웨어 요구사항에 대한 전반적인 이해를 도움 • 아래에 대한 통찰을 제공

- 정보 도메인 (information domain) - 시스템의 기능 및 행동 (function and behavior of system)

3. 인프라 및 기타 비 기능 모델에 대한 고려는 설계단계까지 지연

4. 시스템 전반의 coupling은 최소화

5. 분석모델은 모든 이해관계자에게 가치를 제공

6. 모델은 가능한 단순하게 유지

!7


Domain Analysis• 소프트웨어 도메인 분석 (구조 분석)

• 애플리케이션 도메인의 여러 프로젝트에 재사용될 수 있도록 특정 애플리케이션 도메인에서 공통 요구사항을 식별, 분석, 명세

• 객체 지향 도메인 분석 • the identification, analysis, and specification of common, reusable

capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks . . .

• 특정 애플리케이션 도메인에서 공통성 및 재사용 가능성을 공통 객체, 클래스, 하위 어셈블리, 프레임워크 등으로 식별, 분석, 명세

- Donald Firesmith • 조사할 도메인 지정 • 도메인에서 대표적 애플리케이션 샘플 수집 • 샘플의 각 애플리케이션 분석 • 객체에 대한 분석 모델 개발

!8


Domain Analysis

!9

도메인분석

도메인 지식출처

도메인 분석 모델

요구사항

전문가 조언

고객 조사

기존 애플리케이션

기술적 지식 클래스 분류

재사용 표준

기능 모델

도메인 언어


Data Modeling• 분석 모델링은 종종 데이터 모델링에서 시작

• 처리(processing)과 독립적으로 데이터 객체 검사 • 데이터 도메인에 집중

• 데이터 객체 간의 연관성 표시 - 데이터 객체 간의 관계는 UML로 표현 가능

• 일반적 데이터 객체 • external entities : printer, user, sensor • things : reports, displays, signals • occurrences or events : interrupt, alarm • roles : manger, engineer, salesperson • organizational units : division, team • places : manufacturing floor • structure : employee record

!10


Data Modeling

• 데이터 객체, 속성, 관계 • 데이터 객체는 소프트웨어에 의해 처리되는 복합적 정보

(composite information)의 표현 • 데이터 객체는 데이터만 캡슐화 (encapsulate)

• Entity Relationship Diagram (ERD)

!11


Object-Oriented Concepts

• 분석 모델의 클래스 기반 요소(element)를 적용하기 위해 필수적인 개념

• 주요 개념 : • 클래스와 객체 • 속성 및 연산(operation) • 캡슐화 및 인스턴스화(instantiation) • 상속(inheritance)

!12


Classes

• superclass를 통해 클래스 계층구조 형성

• 특정 항목의 클래스가 정의되면, 클래스의 특정 인스턴스 식별 가능

!13

• 객체 지향적 사고는 클래스 정의로 시작 • 클래스는 종종 다음과 같이 정의 : 템플릿, 일반화된 설명, “청사진”

(유사 항목들의 집합을 기술)


Methods (Operations, Services)• 클래스 내에 캡슐화된 실행 가능 절차 (executable procedure) • 클래스 일부로 정의된 하나 혹은 하나 이상의 데이터 속성 (data

attributes)를 다루기 위함

!14


Encapsulation / Hiding• 객체는 데이터와 이를 다루는 논리적 절차 (logical procedure)를 함께 캡슐화 → 정보 은닉 (information hiding)

!15


Class Hierarchy

!16


How to Define All Classes

1. 기본적인 사용자 요구 사항은 고객과 소프트웨어 엔지니어간에 필수적으로 전달(communicate) 되어야 함

2. 클래스 식별 • 속석 및 메소드 정의

3. 클래스 계층 구조 정의

4. 객체 대 객체 관계 표현

5. 객체 행동 모델화

6. 모델이 완성될 때 까지 작업 1 ~ 6 반복

!17



!18


Scenario-based Modeling• Use-cases are amply an aid to defining what exists outside

the system (actors) and what should be performed by the system (use-cases)

• Use-cases는 시스템 외부에 존재하는 것 (actors)와 시스템에 의해 수행되어야 할 것 (use-cases)가 무엇인지를 정의하는데 큰 도움이 됨

- Ivar Jacobson

1. 어떻게 작성해야 하나 ?

2. 얼마나 작성해야 하나 ?

3. 얼마나 자세하게 설명해야 하나 ? 4. 설명들을 어떻게 구성해야 하나 ?

!19


Use-Cases• 시나리오는 시스템에 대한 사용 흐름 (thread of usage)를 묘사 • actor는 시스템 기능과 관련된 역할을 표현

• 사용자 (users)는 주어진 시나리오 상에서 다양한 역할을 할 수 있음

• use-case 개발 • actor가 행하는 주요 작업 또는 기능은 무엇인가 ? • actor가 취득, 생산, 변경하는 시스템 정보는 무엇인가 ? • actor가 시스템으로 부터 원하는 정보는 무엇인가 ?

!20


Use-Cases

!21


Activity Diagram• 절차 흐름 (procedural flow)을 도식화 하여 use-case를 보조

• Business Process modeling Notation (BPMN)과 함께 비지니스 모델링 기법으로 사용

!22

FillOrder

ShipOrder

SendInvoice

Accept

Payment

CloseOrder

Make Payment

[orderaccepted]

Invoice

ReceiveOrder

[order reject]


Swimlane Diagram

• use-case에 기술 된 활동의 흐름을 나타낼 수 있음 • 프로세스 흐름도의 하위 프로세스에 대한 책임 구분을 위함

!23


Activity & Swimlane Diagram

!24



!25


Class-based Modeling• 클래스 기반 모델링은 다음을 표현 :

• 시스템을 조작하게 될 객체들 (objects) • 조작에 영향을 주는 객체들에 대한 연산(operations: methods or services) • 객체들 사이의 관계 (일부 계층구조적) • 정의된 클래스 사이에 발생하는 협력 관계

• 클래스 기반 모델링의 구성요소 : • 클래스(classes), 객체(objects), 속성(attributes), 연산 (operations) • CRC 모델 • collaboration diagrams & packages

!26


Identifying Analysis Classes

• 요구사항 모델의 일부로 개발된 사용 시나리오를 검토하고 “문법적 구문 분석 (grammatical parse)” 시행 • 문제 정의를 검토하여 분석 클래스 (analysis class) 식별 • 각 클래스마다 속성 (attributes) 식별 • 속성을 조작하는 연산 (operations) 식별

!27


Analysis Classes• external entities : 정보를 생산하거나 소비하는 개체

• other systems, devices. people • things : 문제에 대한 정보 도메인의 일부

• reports, displays, letters, signals • occurrences or events : 시스템 작동/운영 상황 내에서 발생

• property transfer, completion of series of robot movement • roles : 시스템과 상호작용하는 사람에 의해 수행되는 역할

• manager, engineer, salesperson • organizational units : 애플리케이션과 관련된 조직 단위

• division, group, team • places : 해당 문제 상황(context)이나 전체적 기능이 만들어지는 위치

• manufacturing floor, loading dock • structures : 객체들의 클래스 또는 객체들의 연관된 클래스들을 정의

• sensors, four-wheeled vehicles, computers

!28


Selecting Classes - Criteria• 잠재적인 클래스 (potential classes) 중 실제 분석 클래스

(analysis classes)가 될수 있는지 판단 기준 : 1. retained information 2. needed service 3. multiple attributes 4. common attributes 5. common operations 6. essential requirements

• potential class는 이 기준을 모두(대부분) 만족해야 함

!29


Example : Potential SafeHome Classes

!30


Class Diagram

!31


CRC ModelsClass-Responsibility-Collaborator (CRC) 모델링

• 분석 클래스 (analysis classes)는 책임 (responsibility)을 가짐 • 책임이란 클래스에 캡슐화 된 속성과 연산들

• 분석 클래스 (analysis classes)는 서로 협력함 • 협력자 (collaborators)란 한 클래스가 책임을 완료하기 위해 필요한 정보를 제공해야하는 클래스들

• 일반적으로, 협력은 정보 요청 또는 행위 요청을 내포함

!32


CRC Models

CRC 카드

!33


Class Types in CRC Modeling• entity classes (model / business classes)

• 문제 기술서 (problem statement)로 부터 직접 추출됨 예) FloorPlan, Sensor

• boundary classes • 인터페이스 생성을 위해 사용됨 예) interactive screen, printed reports, CameraWindow

• controller classes - 다음을 관리 : • entity 객체의 생성 / 갱신 • boundary 객체의 인스턴스 생성 - entity 객체로부터 정보 얻음 • 객체 집합들 사이의 복잡한 통신 (communication) • 객체 사이 혹은 사용자와 애플리케이션 사이를 오가는 데이터의 검증

!34


Responsibilities in CRC Modeling

• 시스템 인텔리전스 (intelligence)는 문제의 요구 사항을 가장 잘 해결할 수 있도록 여러 클래스에 분산 • smart 클래스 vs. dumb 클래스

• 각 책임은 최대한 일반적 (generally)로 서술 (높은 재사용) • 연관 있는 정보(information)와 동작(behavior)은 같은 클래스에 존재 → 캡슐화 (encapsulation)의 원칙

• 한가지에 대한 정보는 단일 클래스로 현지화 (localized)• 여러 클래스로 분산되면 안됨 → 유지보수와 테스트 어려움

• 필요시, 책임은 관련 클래스들 사이에 공유

!35


Collaborators in CRC Modeling• 클래스가 책임을 완수하기 위한 2가지 방법 :

• 자신의 속성과 연산을 사용 • 다른 클래스들과 협력

• 협력은 클래스들 사이의 관계(relationships)를 식별 • 협력은 클래스가 각 책임을 스스로 완수할 수 있는지를 판단함으로써 식별 • 클래스 사이의 3가지 일반적 관계 :

• is-part-of 관계• has-knowledge-of 관계• depends-upon 관계

!36


Composite Aggregate Class

• is-part-of 관계 = UML에서는 aggregation

!37


Association & DependenciesUML에서는 :

• 연관관계 (association) • 두 분석 클래스 (analysis classes)가 종종 어떤 방식으로 서로 관련되어 있음 - 다중성 (multiplicity) (cardinality)

• 의존관계 (dependency) • 두 분석 클래스 (analysis classes)간에 client-server 관계가 존재

• client 클래스는 server 클래스에 의존적(종속적)

!38


Multiplicity

!39


Dependencies• 의존관계 (dependency)는 스테레오타입(stereotype)으로 정의

• 스테레오타입(stereotype)은 특수 모델링 요소의 의미를 사용자가 정의할 수 있도록 하는 UML의 확장 메커니즘

• 스테레오타입은 이중 꺽쇠 괄호(<< >>)로 표시

!40


Analysis Packages• 분석 모델의 여러 요소들 (use-case, analysis class)은 패키지로 분류되어 그룹화 • + (plus) : 분석 클래스(analysis class)의 공개된 가시성 • - (minus) : 다른 모든 패키지로부터 숨김 • # (sharp) : 제시된 패키지에 포함된 패키지에 대해서만 접근가능

!41


Reviewing the CRC Model• (CRC 모델) 리뷰의 모든 참여자는 CRC 모델 인텍스 카드의 일부(subset)을 받음

• 협력하는 카드는 분리 (한 검토자가 협력하는 두 카드를 가지면 안됨) • 모든 use-case scenario (해당 use-case diagram)를 카테고리로 구성 • 리뷰 리더는 use-case를 낭독

• 리뷰 리더가 이름이 붙여진 객체에 도다르면 해당 클래스 색인 카드를 가진 사람에게 토큰을 전달

• 토큰이 전달되면, 해당 클래스 카드 소지자는 카드에 적힌 책임을 설명 • 그룹은 책임 중 하나 (혹은 여럿)이 use-case 요구 사항을 충족하는지 판단

• 인덱스 카드에 언급된 책임과 협력이 use-case를 수용할 수 없는 경우 카드를 수정 • 신규 클래스 (해당 CRC 인덱스 카드 포함) 생성 • 신규 혹은 개정 된 책임 또는 협력을 기존 카드에 명세

!42



!43


Flow-oriented Modeling• 데이터 객체가 시스템을 통해 이동하면서 어떻게 변화하는지 표현

• 표기법 : Data Flow Diagram (DFD)

• 구조적 분석/설계의 전통적인 접근 방법

• 단일화된 시스템의 관점(데이터 흐름 및 처리)을 제공 • 다른 분석 모델 요소들에 대한 지원을 위해 주로 사용

!44


The Flow Model

• 모든 컴퓨터 시스템 = 정보 변환 과정

!45

자료원 자료도착지프로세스


The Flow Model Notation

• 처리 : 데이터 변환기 (입력을 출력으로 변환) 예) 세금 계산, 면적 계산, 보고서 작성, 그래프 생성 • 시스템의 기능 수행을 위해 데이터는 항상 어떤 방식으로든 처리되어야 함

• 단말 (external entity) : 데이터의 생산자(origin) 또는 소비자(sink) 예) 사람, 장치, 센서, 외부 시스템 • 데이터는 항상 어딘가에서 생산되어 무언가로 보내져야 함

!46

처리 (process)

단말 (external entity)


The Flow Model Notation

• 자료흐름 : 데이터는 시스템을 통해 입력에서 출력으로 변환되며 이동

• 자료 저장소 : 데이터는 나중에 사용하기 위해 저장되는 경우가 많음

!47

자료흐름 (Data Flow)

자료 저장소 (Data Store)


Data Flow Diagram Example : Bread Factory

• 빵 공장의 DFD

!48


Data Flow Diagram Example : Bread Factory

• 빵 만들기 프로세스 구체화 (하위 레벨 : 레벨 2)

!49


Data Flow Diagramming : Guidelines

• 모든 아이콘은 의미 있는 이름으로 레이블함 (labeling) • DFD는 여러 단계의 구체화를 통해 진화 • 항상 context level 다이어그램 (level 0)에서 시작

• 하향식 (top-down) 접근법 • 단말 (external entity)는 항상 level 0에서 나타냄 • 데이터 흐름을 표연하는 화살표는 항상 레이블함(labeling) • DFD가 final level에 도달하기 전까지는 절차 논리

(procedural logic)은 표현하지 않음

!50


Data Flow Diagramming : Guidelines• 명명 원칙

• 처리 이름은 동사형 명사와 단일 직접목적어 사용 • 어떤 경우에도 다 적용될 수 있는 포괄적 명칭은 피함 예) 부적절한 명명

• 변환된 데이터 흐름의 명명 • 데이터 흐름에서 처리를 거쳐 변환될 때 마다 새로운 이름으로

!51

가격 책정입력자료 출력자료

고객 관리

새로운 신용카드 고객상태

닦다 껍질을 벗기다

씨를 파내다

자르다사과

자른 사과

씨 파낸 사과

껍질 벗긴 사과

닦은 사과


Constructing a DFD• 데이터 모델 리뷰

• 데이터 객체 분리 • 연산 (operations)을 정하기 위해 문법적 구문분석 (grammatical

parse) 사용 • 단말 (external entity) 결정 : 데이터의 생산자와 소비자 • 먼저 level 0 DFD 작성

!52


Constructing a DFD• 변환을 묘사하는 스토리 (narrative) 작성

• 다름 레벨 변환을 결정하기 위해 문법적 구문분석 (grammatical parse) 사용 • 명사 (명사구) & 동사 (동사구)

• 흐름의 균형 (balance)을 이루어 데이터 흐름의 연속성 유지 • 다른 레벨의 입력과 출력 데이터의 흐름은 일관성이 있어야 함

• level 1 DFD 작성 (약 1:5 정도의 확장 비율 사용)

!53


Constructing a DFD Example : SafeHome

SafeHome processing narrative The SafeHome security function enables the homeowner to configure the security system when it its installed, monitors all sensors connected to the security system, and interacts with the homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number are input for dialing when a sensor event occurs.

!54



• [level 1] SafeHome 소프트웨어의 구체화 (refinement)

!55



• [level 2] Monitor sensors 처리의 구체화 (refinement)

!56


Flow Modeling Notes• 처리 (process)는 단 한가지 (one thing)을 표현할 때까지 구체화

• 확장 비율은 DFD 레벨이 증가할 때 마다 감소

• 단말 (external entity)는 항상 level 0에서 나타냄

• 적절한 흐름 모델 (flow model)은 3 ~ 7 레벨 사이

• 화살표로 표현되는 단일 데이터 흐름 항목은 레벨이 증가할 때 마다 확장 됨 • data dictionary를 통해 정보 제공

!57


Flow Model Components

!58

Data Flow Diagram Data Dictionary

Process Specification (Mini-Spec)


Data Dictionary

• 자료 흐름도에 나타나는 모든 자료에 대한 정의 • 자료 항목 (data item) = 자료 항목의 구성을 나타내는 수식

address = house no. + (street / area) + city + state course ID = course no. + name + level + grades

!59

= composed of

{ } repetition

( ) optional

+ and

[ / ] or


Process Specification (PSPEC)• 최종 level에 나타난 모든 흐름 모델 (flow model) 프로세스 기술

!60



!61


Behavioral Modeling• 행위 모델 (behavioral model)은 소프트웨어가 외부 이벤트 (events)나 자극 (stimuli)에 어떻게 반응하는지 표현는지 표현

• 행위 모델 작성 단계 : • 모든 use-cases를 평가하여 시스템 내부 상호작용 시퀀스

(interaction sequence)를 완전히 이해 • 상호작용 시퀀스를 주도하는 이벤트를 식별하고 이러한 이벤트가 특정 객체와 어떻게 관련 되었는지를 이해

• 각 use-case에 대한 시퀀스 생성 • 시스템의 상태 다이어그램 (state diagram) 작성 • 행동 모델 검토 - 정확성과 일관성 확인

!62


What are Events ?Event = a type of observable occurrence

• 상호작용 (interaction)은 인스턴스 (instances)사이에 일어나는 커뮤니케이션의 집합 • synchronous object operation invocation (call event) • asynchronous signal reception (signal event) • creation and destruction of instances

• occurrence of time instants (time event) • interval expiry • calendar/clock time

• change in value of some entity (change event)

!63


Behavioral Modeling• 상태 (states)의 두가지 특성화 (characterization) :

• 각 클래스는 시스템이 기능을 수행함에 따라 변하는 동작 (behavior)을 나타내는 상태를 가짐

• 시스템은 외부에서 관측 가능한 행동(behavior)을 표현하기 위한 상태를 가짐

• 시스템이 한 상태에서 다른 상태로 전이 (transition)하는지 나타냄 • 시스템 상태 변화 : 이벤트 및 동작(action)

• 상태 표현 • state / sequence 다이어그램

!64


State Diagram• 각 클래스의 활성 상태 (active state) 사이의 변화를 야기하는 이벤트들을 표현

!65


State Diagram Example• SafeHome control panel class

!66


Sequence Diagram

• 이벤트가 어떻게 객체에서 객체로 전이를 유발시기는지 표현

!67


Sequence Diagram Example• SafeHome

!68

analysis modeling - hanyang1. 분석 모델은 문제 혹은 비지니스 도메인 내에서...

Documents