Software Magic !

2006, 02/28 der Dienstag, Tuesday, Mardi

1. Semantic Networks <- S/W Modeling.

1.1 Requirement level diagram.

UML에서 Use-Case등에 해당된다. 이것이 Model에 어떤 의미가 있을까?
Textual Form으로 기술할 수도 있다.
System 사용 시나리오를 UseCase 등으로 표현할 수도 있다.
(실제 Code Synthesis에는 별 도움이 안된다.)

1.2 Data-flow diagram.

이 모델에서는 시스템을 데이터의 변환 과정으로 보고, 시스템을 모델링한다.

이 다이어그램에서는 두 가지 Entity가 존재한다. 하나는 데이터이고, 다른 하나는
그 데이터를 처리하는 데이터 프로세서이다.

데이터는 자료 저장 공간과 그 자료에 접근하기 위한 각종 서비스들로 구성된다.
이 서비스들은 Method들로 구성되며, 데이터에 정보를 추가/삭제/가공하는 역할을
한다. 하지만, 데이터 변환 작업은 수행하지 않는다.

데이터 프로세서는 어떤 데이터를 다른 형태의 데이터로 변환하는 일종의 변환기
(Translator? Transformer?)로 생각할 수 있다. Method들의 집합으로 구성된다.

** S/W Architecture는 Data Flow Model로 표시할 수도 있고, Component간의
Relationship으로 표시할 수도 있다.

1.3 Component Model.

S/W의 구조를 표현하는 모델중 가장 Abstract된 모델이다. 이 모델은 Component와
Component간의 Relationship으로 표현된다. Component는 데이터와 데이터 프로세서의
집합체로서, 기능적으로 연관된 Class/Object들이 모여서 구성된다. 즉, S/W의 기능을
크게 나누었을때 각 부분에 해당하는 것이 Component이다.

각 Component들은 다른 Component들에 데이터를 전달하기도 하고, 데이터를 받기도
하며, 기능 수행을 요청하기도 하는 등 많은 연관성을 형성한다. 이러한 연관성은
Component 간의 Relationship으로 모델링된다.

** Data Flow Model과 Component Model을 자세하게 비교할 필요가 있다. Data Flow
Model은 자료의 흐름에 중점을 둔 것이고, Component Model은 S/W의 구조에 초점을
맞춘 것이다.

1.4 Object/Class Model.

Data Flow Model이나 Component Model을 구성하는 각 부분들(Data, Data Processor
Component)들은 다시 Class/Object Model로 표시할 수 있다. 이 모델은 S/W의 구조를
기술하는 것으로, Class/Object 수준에서 S/W의 구조를 모델링한다.

Class의 구성이 명시되고, Class 간의 관계(상속, Use, 등등)가 이 모델에서 정의
된다.

1.5 Activity Model.

S/W의 Control Flow에 초점을 맞춘 모델이다. 이 모델을 이용하면, 실행 시 어떤
과정을 따르는지를 알 수 있다.


** Software Modeling

1. Static Architecture Modeling
Component Diagram,
Class/Object Diagram,

2. Dynamic Modeling
Sequence Diagram,
Activity Diagram,
UseCase Scenario,
Data Flow Diagram,

3. Design Patterns can provide some insights on S/W modeling and synthesis.
Code synthesis by using code template(Design Pattern, Design Reuse).