12. 소프트웨어 모델링
12.1 소프트웨어공학과 소프트웨어 모델링의 관계
12.2 모델링의 정의
12.3 소프트웨어 모델링의 기본원리
12.4 소프트웨어 모델링의 3요소
12.5 소프트웨어 개발을 위해 필요한 모델링
12.6 모델링과 방법론의 관계
12.7 모델링과 컴퓨터의 발전 정리
12.8 정리
12.9 연습문제
12.1 소프트웨어공학과 소프트웨어 모델링의 관계
소프트웨어 공학은
- 소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반에 관련된 기술을
- 쳬계화함으로써,
- 소프트웨어에 관련된 분야를 서술적이며 정량적으로 다루는 학문입니다
소프트웨어공학이 필요한 이유는
- 대규모 소프트웨어를
- 오랜기간, 여러 개발자, 고객, 엔지니어, 임원, 아키텍터 등이 모여서
- 개발하는 과정 및 관리를 효과적으로 수행하기 위해 도입된 개념이다
소프트웨어 공학의 성공적인 적용을 위해서는
- 정보시스템의 기획, 설계, 개발, 운용에 관련된 수많은 사람들의
- 의사소통을 위해서는
- 공통적으로 이해하고, 사용할 수 있는 도구가 필요합니다.
- 이 도구 중에서 가장 많이 사용되는 것이 모델링(Modeling)이고,
- 모델링을 수행하는 절차와 과정, 결과를 실무에서 사용할 수 있도록 구체적으로 정의한 것이 방법론(Methodology)입니다.
12.2 모델링의 정의
모델
(Model)
모델은 대상을 원하는 관점을 기준으로 표현하는 것이다
(대부분의 모델은 편리성과 내용의 전달과 이해가 쉬운 그림의 형태로 표현한다)
(예) 소프트웨어 모델은
- 수행해야 하는 기능의 관점에서 소프트웨어를 표현한 것이다
- 소프트웨어 전체의 모습이 하나의 모델에 표현되지 않는다
모델은 관심분야가 아니거나 세부적인 것을 생략하고
, 관심 분야의 이해를 목적으로
필수적인 것만을 표현한다
(예) 서울시 교통흐름을 모델링하면,
- 도로, 각 도로의 차의 숫자, 붐비는 곳, 교통사고에 관심을 두게 되고,
- 차가 사용하는 타이어, 생산년도, 기종, 운전자 성별에 대한 것에는 관심을 가지지 않는다
모델을 만드는 것을 모델링
(Modeling)이라 하다
논리적
(Logical)
Model
Logical Model은 시스템은 무엇이며, 어떤 기능을 해야 하는가를 보여준다
이때
, 표현되는 모델은 구현과는 관계가 없고,기술적인 것을 고려하지 않는다
물리적
(Physical)
Model
Physical Model은 시스템은 무엇이며, 어떤 기능을 해야 하는가를 보여주지 않고,
시스템이 실제 어떻게 구현되어야 하는지를 보여준다
. 기술적인 면을 주로 고려한다
12.3 소프트웨어 모델링의 기본 원리
추상화의 원칙
(Principle of Abstract)
- 모델링의 대상을 관심이 있는 제한된 관점에서 바라보고 표현하는 것 전체를 표현하는 것이 아니다
정형화의 원칙
(Principle of Formality)
- 모델링의 표현이나 문서화, 절차를 표준화하는 것 결과의 공유를 위한 필수 단계
분할 정복의 원칙
(Principle of Divide and Conquer)
- 모델링의 대상은 매우 크다. 그러므로 큰 시스템을 작고 독립적인 시스템으로 Top Down 분할 한 후에
분할된 것을 대상으로 하나씩 모델링 작업을 수행하는 것
계층적 구조의 원칙
(Principle of Hierarchical Structure)
- 모델링의 대상을 독립적인 서브시스템으로 나누고, 이들을 상호 연관성이나 동작을 기준으로 계층적 구조를
이루도록 구성함으로써 전체 시스템을 표현하고 이해에 도움이 되도록 하는 것
( =Top Down 분할)
모형화 도구 사용의 원칙
(Principle of Using Modeling Tools)
- 모델링을 수행하고, 표현하고, 문서화하고, 공유하는 모든 작업을 표준 도구를 사용하여 진행하는 것
여러 사람이 동시에 표준 환경에서 작성
, 수정, 보관할 수 있고, 실시간으로 공유할 수 있다
12.4 소프트웨어 모델링의 3요소
소프트웨어 모델링울 포함한 모든 모델링은
3가지 요소로 구성된다
- 규약(Convention) : 모델링에 사용되는 요소의 정의
- 표현(Representation) : 규약을 이용하여 모델링된 결과
- 명세(Specification) : 표현된 모델에 대한 상세 내용을 서술하는 것
(예) 구조적 모델링에서는 모델링의 3 요소가 아래와 같이 구성된다
규약
표현
명세
시스템
/기능
파일
/데이터베이스
입력
/출력
데이터흐름
고객
구매
접수
구매
DB
구매접수 시스템
- 고객으로 부터 구매의뢰를 받는다
(ID, Product_ID, Date, Number)
- 받은 구매의뢰를 구매 DB에 저장한다
12.5 소프트웨어 개발을 위해 필요한 모델링 관점
소프트웨어 모델링을 위해서 필요한 관점은
3가지이다
기능관점
: 기능 모델링(Functional Modeling) : 어떤 기능이 필요한지를 모델링 하는 것이다
정보관점
: 정보 모델링(Information Modeling) : 어떤 데이터가 필요한지를 모델링 하는 것이다
동적관점
: 동적 모델링(Dynamic Modeling) : 어떤 업무가 어떤 순서로 처리되는 지를 모델링 하는 것이다
기능모델링
(경영진, 사용자)
정보 모델링
동적 모델링
12.5.1 소프트웨어 모델링의 관점별 방법론 정리
기능 모델링
구조적 방법론에서 프로그램이 수행해야 하는 기능을 중심으로 모델링을 수행한다
SADT(Structured Analysis and Design Technique)
PSL/PSA(Problem Statement Language/Problem Statement Analysis)
정보 모델링
정보공학 방법론에서 프로그램이 저장하고
/조회/수정해야 하는 공용 데이터를 중심으로
모델링을 수행한다
.
객체모델링
(Object Modeling),개념적 데이터모델링(Conceptual Data Modeling),
의미데이터모델링
(Semantic Data Modeling)으로 불린다
EER(Enhanced Entity-Relationship Model)이 사용된다
여기의 핵심 기법이
RDB에 적용되는 ER Modeling이다
동적 모델링
실시간 시스템을 말하며
, 여러 프로세스의 동시 수행과 처리 우선 순위가 있다
통신시스템
, 비행기 운행관리 시스템, 원자로 제어시스템 등
상태변화도
(State Transition Diagram : STD), SDL(Specification & Description Language),
프로세스 활성표
(Process Activation Table : PAT) 등이 있다
객체지향 모델링
객체지향 방법론에서는 프로그램 자체에서 취급하는 데이터와 데이터를 조작하는 함수를
사용자 정의 자료형으로 선언하며 모델링을 수행한다
대규모 소프트웨어의 개발에서 반드시 필요한 기법이다
.
12.6 모델링과 방법론의 관계
[ SADT 소개 ]
Structured Analysis and Design Technique의 약자
그래프 언어이며 요구사항 분석 설계를 위한 도구이다
하나의
SADT는 SA 도표의 순서 집합으로 구성된다
SA의 두가지 기본 유형은 “활동다이어그램(Actigram)”과 데이터다이어그램(Datagram)으로
구성된다
[SADT 표기법 예]
Activity/Data
( 활동/데이터)
입력
컨트롤
(처리기준, 방향)
메커니즘
(처리시스템, 처리조직)
출력
소프트웨어
Requirement 정형화 기술 연구
1986.12 한국전자통신연구소
12.6 모델링과 방법론의 관계
[ PSL/PSA 소개 ]
미시간 대학의 다니엘 타이초로우 교수가 미시간 대학의
ISDOS 프로젝트에서 개발한 요구사항
분석과 문서화 지원 시스템
Problem Statement Language/Problem Statement Analyzer의 약자
개발해야 하는 목적 시스템의 요구사항 명세서를
PSL로 기술하고, 이것을 PSA에 입력한다.
복잡하고
, 범용에 부적합하다
[PSL/PSA의 구조]
PSA
PSL
Statement
PSA
Command
Analyzer
Database
Report
&Message
소프트웨어
Requirement 정형화 기술 연구
1986.12 한국전자통신연구소
12.6 모델링과 방법론의 관계
[ 상태변화도 ]
시스템의 제어 흐름과 동작의 순서를 나타낸다
.
즉
, 시스템이 가지고 있는 값을 표시하는 상태와 상태에 가해지는 외부적인 사건을 표현한다.
상태변화도는 상태와 사건에 의해 시스템의 제어를 표현하는 것이다
.
[상태변화도의 예]
기체
(상태)
고체
(상태)
액체
(상태)
액화
승화
승화
기화
응고
융해
12.6 모델링과 방법론의 관계
주어진 절차대로
수행하던 시절
1980 ~ 1990
주어진 순서대로 처리하는
작업을 주로 하던 시절
(예) 성적처리, 인구조사
다른 순서는 다른 프로그램을
제작하여 처리한다
이때의
, 모델링은 처리절차에
중점을 두게 된다
구조적 방법론
처리절차에 중심이 있으므로
- 처리단위를 함수를 이용하여
묶어서 처리하게 하고
- GoTo문은 처리 순서를 복잡하게
하므로 금지시켰다
.
컴퓨터가 데이터를
조작하는 기능을 가진 시절
1990 ~ 2000
컴퓨터가 데이터를 입력
/수정
삭제는 물론 저장
/조작 기능을
수행하는 시절
(예) 은행, 금융기관
데이터의 일치성과 성능이
중요한 요소이다
이때의
, 모델링은 데이터베이스의
구성에 중점을 두고
, 컴퓨터가
기업의 중요 자산으로 인식된다
정보공학 방법론
데이터베이스를 구성하고
데이터의 입출력을 위한 프로그램을
제작하던 시절이므로
- 데이터 디자인이 중요하고(ER Modeling)
- 데이터일치성이 최고의 관심사이다
모든 분야에서
컴퓨터가 사용되는 시절
2000 ~ 현재
컴퓨터가 모든분야에서
24시간 사용되고
프로그램이 크고
, 다양한 종류가 있다
(예) 물류, 인사, 재무, 음악, 영화…..
프로그램의 효율적 개발외에도 확장성 및
24시간 운영이 중요한 요소이다
이때의
, 모델링은 프로그램 제작의 다양성,
복잡성
, 대형화에 중점을 두고 있다
객체 지향 방법론
데이터와 관련있는 메소들를 하나로
묶어서 사용자정의 자료형을 선언하고
이것을 활용하여 프로그램을 제작하므로
- 사용자 정의 자료형의 선언 및 활용이 중요하고
- 각각의 모듈이 독자적으로 작동하도록 프로그램을
작성하는 것이 중요하다
- 만들어진 프로그램의 확장이 다른 모듈에 영향을
주지 않아야 한다
동적모델링은 공통적으로 적용한다
12.7 모델링과 컴퓨터의 발전 정리
12.8 정리
모델링에서
- 구조적 모델링, 정보공학모델링, 객체지향 모델링은 별도의 장에서 설명하므로 별도로 설명하지
않는다
.
- 동적모델링은 상태변화도(State Transition Diagram : STD), SDL(Specification & Description Language),
프로세스 활성표
(Process Activation Table : PAT) 등이 있는데, 상태변화도에 대해서만 설명하고
나머지는 설명으르 생략한다
. 이유는 유사하고 많이 사용되지 않기 때문이다
