티스토리 뷰
※ tutorialspoint의 OOAD 요약 (https://www.tutorialspoints.com/object_oriented_analysis_design/)
object-oriented analysis model 중 process 관점, 시스템이 해야 할 일 제공. Data Flow Diagram (DFD) 통해 시스템의 내부 프로세스의 function 정의. data value를 구하는 이유나 방법이 아닌, functional derivation 표현.
1. Data Flow Diagrams
Functional modeling은 DFD의 계층을 통해 표현. DFD는 입력, 처리, 출력 및 내부 데이터 저장을 그래픽으로 표현. object, system에 관해 처리된 일련의 변환, 계산과, 변환에 영향을 주는 external control, object를 표현.
주요 4개 항목
- process
- data flow
- actor
- data store
추가 2개 항목
- constraint
- control flow
2. Features of a DFD
Processes
data value를 변환하는 computational activity. 전체 시스템은 high-level process로 표현. process는 더 작은 component로 분할. 가장 낮은 레벨의 process는 simple function.
Representation in DFD: name을 갖는 ellipse로 표현하며, 고정된 개수의 input, output data value 포함.
Example: Compute_HCF_LCM process (2개의 integer를 input으로 받아서 HCF (highest common factor), LCM (lowest common multiple)을 output으로 내보냄.
Data Flows
2개 process간의 data flow 표현. actor와 process 사이 또는 data store와 process 사이일 수 있음. data flow는 computation의 특정 지점의 data item의 value 표현. 이것은 data flow에 의해 변경되지 않음.
Representation in DFD: 전달하는 data item name으로 라벨링한 directed arc (또는 arrow)로 표현. 위 그림에서 Integer_a, Integer_b는 프로세스에 대한 input data flow, L.C.M, H.C.F는 output data flow.
data flow는 2가지 케이스로 요약
-
ouput value가 여런 곳에 전송. output arrow가 동일 value를 보여주므로, 라벨링 되지 않음.
- aggregate value를 포함하며, 각 component는 각기 다른 곳으로 전송. 각 component는 라벨링.
Actors
시스템에 데이터를 input 또는 시스템에서 생산된 데이터를 consume 통한 시스템과 interaction하는 active object. actor는 data source, data sink 역할.
Representation in DFD: rectangle로 표현. input / output과 연결되며, DFD의 boundary에 위치.
Example: counter sales system 예제.
Data Stores
data repository 역할. operation 없음. data 저장, 저장된 data 읽기 목적으로 사용. data structure, disk file, DB table 나타냄.
Representation in DFD: 2개의 parallel line으로 표현하며, name을 가짐. 적어도 1개 이상의 process와 연결. input arrow는 저장된 content, output arrow는 읽어가는 정보 표현. 일부 정보만 읽는 경우, output arrow는 라벨링. 라벨링 되지 않은 arrow는 전체 정보 읽음을 의미. two-way arrow는 읽기, 쓰기를 의미.
Example: Sales_Record data store 예제. 모든 판매 정보 저장, input data는 item, billing amount, date 등으로 구성. 평균 판매량을 구하기 위하여, process는 판매 기록을 읽은 후 평균을 구한다.
Constraints
condition, restriction 정의. 새로운 rule 추가 또는 기존 rule 수정 가능. 3개 object-oriented analysis에서 등장.
-
in object modeling: object간의 관계 정의. object가 각각 다른 시기에 처리하는 각각 다른 value들 간의 관계 또한 정의.
- in dynamic modeling: 다른 object state, event 간의 관계 정의
- in functional modeling: transformation / computation에 대한 restriction 정의
Representation: brace 내의 string으로 표현
Example: 회사의 영업부서에게 인센티브를 제공하고, 인사부서에게 급여 인상을 제공하기로 한 회사의 직원 급여 계산을 위한 DFD 예제. {Dept:Sales}를 통해 영업부서 직원에게만 인센티브 계산을 하고, {Dept:HR}을 통해 인사부서 직원에게만 급여 인상을 계산하도록 한다.
Control Flows
process는 특정 boolean value와 관련되어, process에 대한 direct input은 아니지만 true일 때만 evaluation. 이러한 boolean value를 control flow.
Representation in DFD: boolean value를 생성하는 process에서 제어되는 process 방향으로 dotted arc로 표현.
Example: divisor가 non-zero인지 확인 후 OK이면 (0이 아니면), 후속 divide process는 quotient, remainder 계산.
3. Developing the DFD Model of a System
시스템의 DFD 모델 개발을 위해, DFD hierarchy 구성. 최상위 DFD는 single process와 actor간의 interaction으로 구성.
하위 계층의 DFD 모델은 위해, 세부 사항들이 점차적으로 포함. process는 sub-process들로 분해, sub-process간의 data flow 구성, control flow 결정, data store 정의. process 분해 중 process의 내부 또는 외부 data flow는 next DFD level data flow와 일치해야 한다.
Example: 도매점의 거래 자동화 소프트웨어. 가게는 bulk 제품을 판매하며 상인과 소매점을 고객으로 보유. 각 고객은 사용자 등록 통해 고객 코드 C_Code를 부여 받음. 판매가 되면, 도매점은 세부사항을 등록하고 상품을 발송. 매년 도매점은 크리스마스마다 총 매출 및 소유주 결정에 따라 금화 또는 은화로 된 선물을 고객에게 제공.
도매점 소프트웨어의 functional model은 다음과 같으며, 최상위 DFD는 아래 그림.
시스템의 actor는,
- customers
- salesperson
- proprietor
차상위 DFD에서는, 시스템의 메인 process들을 구분, data store 정의, process와 actor간의 interaction, data store 설정.
시스템은 3개 process 구분.
- register customers
- process sales
- ascertain gifts
data store 요구 사항은,
- customer details
- sales details
- gift details
아래 그림은 register customers process 표현. 이것은 3개의 process를 포함한다 - verify details, generate C_Code, update customer details. customer detail을 입력하면, 확인 가능. data가 맞으면, C_Code가 생성되고, customer details data store가 업데이트 된다.
다음은, ascertain gifts process. 2개의 process를 포함한다 - find total sales, decide type of gift coin. find total sales process는 고객별 연간 판매량 계산 / 저장. 이 기록과 소유주 결정을 입력하여, gift coin은 decide type of gifit coin process를 통해 할당.
4. Advantages and Disadvantages of DFD
Advantage DFD는 시스템 boundary를 기술하여, 외부 object와 system 내의 process간의 관계를 그리는데 효율적 사용자가 시스템에 관해 이해하는데 도움 개발자의 시스템 개발에 도움 (그래픽 표현) DFD는 시스템의 세부 정보 제공 시스템 documentation의 일부 |
Disadvantage DFD 작성에 오랜 시간이 걸려서, 실용적이지 않음 DFD는 time-dependent behavior 제공하지 않음 DFD 준비는 복잡하고 전문적인 과정 (비 전문가가 이해하기 어려움) 준비 방법은 주관적이고, 정확하지 않은 scope을 남기게 됨
|
5. Relationship between Object, Dynamic, and Functional Models
object model, dynamic model, functional model은 상호 보완.
-
object modeling: object 관점에서 소프트웨어 시스템의 static structure 구성. 시스템의 doers를 표현.
-
dynamic modeling: 외부 event에 대한 object의 temporal behavior 구성. object에 대한 operation sequence를 표현.
- functional modeling: 시스템이 무엇을 하는지에 대한 overview 제공.
Functional Model and Object Model
object model 관점에서 functional model의 주요 4개 part,
-
process: 구현해야 하는 object의 method
-
actors: object model의 object
-
data store: object model의 object 또는 attribute
- data flow: object에 의한 또는 object에 대한 operation. data store에 관한 data flow는 query / update로 표현
Functional Model and Dynamic Model
- dynamic model: operation이 처리되는 시기 기술. active object인 actor에 대해, action 시기 지정. data store는 passive object이고 update / query에만 응답하므로, dynamic model에서는 그 시기를 지정할 필요 없음.
- functional model: operation이 처리되는 방법과 필요한 argument 기술.
Object Model and Dynamic Model
- dynamic model: object status, event 발생 / 이후의 state change에 대해 처리되는 operation 표현
- object model: 변경의 결과로서의 object state 표현