728x90
반응형
SMALL
구조적 방법론 (1970년대)
| 구분 | 설명 |
| 정의 | - 구조적 프로그래밍이란 코드가 계층적인 형식과 제한된 구조로, 작성된 순서 대로 순차적으로 실행함. - 알고리즘을 기술하는 데는 순차,선택,반복 구조면 충분하다. (NS차트) - 단일입구/단일출구의 처리구조를 가짐. |
| 등장배경 | GOTO문을 쓰지말자라는 주장이 호응을 얻으면서 분석과 설계도 구조적으로 하자라는 의견으로 확대대면서 구조적 방법론의 틀이 완성. |
| 특징 | - 데이터 흐름지향. 즉 프로세스 위주의 분석과 설계방식 (DFD/ERD) - 모듈의 분할과 정복에 의한 하향식(TopDown) 설계방식 - 모듈의 구조화를 통한 재사용/유지보수성 제고 - SDLC 구조를 가진 폭포수 모델이 기본 |
| 중점 | - 기능중심 |
| 단점 | - 어플리케이션은 여전히 기능적 설계 - 기능의 유지보수, 재사용은 낮음. - 데이터의 구성에 대한 설계 방안이 부족 - 프로젝트의 관리 및 조직,역할등 방법론적 다른 요소들의 정의가 없음. - 이것들은 단순한 소프트웨어 개발을 목표로 한다는 점에게 기인 -> 정보공학적 개발 방법론 등장. - 데이터가 정보 은닉이 안됨. - 유지보수, 재사용성 낮음 |
정보공학적 방법론 (1980년대)
| 구분 | 설명 |
| 정의 | 기업정보시스템에 공학적 기법을 적용하여 시스템의 계획,분석,설계 및 구축을 하는 데이터 중심의 방법론 |
| 등장배경 | 정보시스템은 소프트웨어 개발과는 달리 하드웨어, 네트워크 등 여려 소프트웨어와 복잡하게 연결되는 대규모시스템이기 때문에 이러한 시스템을 개발하기 위해서는 장기간, 많은 인력이 소요되므로 철저한 계획,팀워크에 따른 프로젝트 관리, 이의 진행을 위한 잘 짜여진 방법론이 필요 |
| 특징 | - 일반적인 소프트웨어 개발이 아닌 기업의 Biz전략에 따라 수립된 ISP에 따라 정보시스템 통합에 그 초점이 맞추어짐. - 따라서 ISP수립 -> 업무영역분석 -> 업무시스템설계 -> 업무시스템구축 순서를 가진다. - Process는 변하지만 Data는 불변이기 때문에 프로그램 로직은 데이터 구조에 종속(CRUD)적이며 데이터 안정성을 추구하기 위한 데이터 구조에 중점을 둔다. - 기본적으로 정보공학은 공학적 개발방법론이며 자동화도구,CASE Tool을 이용하여 코드의 자동생성을 목표 |
| 중점 | 데이터 구조 (자료구조) |
| 단점 | - 어플리케이션은 여전히 기능적 설계 - 기능의 유지보수, 재사용은 낮음. |
객체지향 방법론 (1990년대)
| 항목 | 설명 |
| 정의 | - 복잡한 현실세계를 모델링 - 추상화,캡슐화,상속,정보은닉 등 객체를 중심으로 프로그래밍 구조를 단순화하고 재사용성을 강화 |
| 등장배경 | - 구조적 방법론이나 정보공학 방법론 모두 프로세스와 데이터를 분리 하여 처리한다는 단점은 이를 통합하여 처리하는 객체지향의 등장에 가장 큰 배경 * 구조적,정보공학 - Process 와 Data분리 객체지향 - Process 와 Data 통합 -> Class |
| 특징 | - 재사용이 강점 (Whitebox 재사용) - 추상화,상속성,다형성,캡슐화 - 상속이 많으면 상속은 저하되는 단점. - 다형성이 많으면 유지보수가 어려워진다. - 분석 설계간 Gap 없음. - 고도의 모듈화 - 데이터와 로직을 통합 (객체) |
| 중점 | 객체중심 |
| 단점 | - 전문가 부족 - 기본 SW기술 필요 |
| 예 | RUP |
| 원리 | 개념 | 역할 | 특징 |
| 추상화 (Abstraction) |
현실세계의 사실을 그대로 객 체로 표현하기 보다는 문제의 중요한 측면을 주목하여 상세 내역을 없애 나가는 과정임. |
복잡한 프로그램 을 간단하게 해주고 분석의 초점을 명확히 함 |
클래스를 이용함으로써 데이터와 프로세스를 함께 추상화구조에 넣 어 보다 완벽한 추상화 를 실현함 |
| 캡슐화 (encapsulation) |
객체의 상세한 내용을 객체 외부에 숨기고 단순히 메시지 만으로 객체와의 상호작용을 하게 하는 것. |
객체의 내부구조와 실체를 분리함으로써 내부의 변경이 프로그램에 미치는 영향을 최 소화하여 유지보수 용이하게 함 |
Public과 Private |
| 상속성 (Inheritance) |
수퍼클래스가 갖는 성질을 서브클래스에 자동으로 부여 하는 것. |
프로그램을 쉽게 확장할 수 있도록 해주는 강력한 수단. | |
| 다형성 (polymorphism) |
하나의 인터페이스를 이용하 여 서로 다른 구현 방법을 제공하는 것. |
특정지식을 최소화한 관련된 클래스들을 위한 일관된 매개체를 개발 하는 수단을 제공 | 특정지식을 최소화한 관련된 클래스들을 위한 일관된 매개체 를 개발 하는 수단을 제공 |
CBD 방법론 (2000년대)
- 재사용이 가능한 Component의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션 개발
| 항목 | 설명 | |
| 특징 | - BlackBox 재사용 : 인터페이스를 이용해서 재사용 - 추상화,캡슐화 - Input과 Output만 있음. - 표준화된 UML을 통한 모델링 및 산출물 작성 - 반복 점진적 개발 프로세스 제공 - 표준화된 산출물 작서잋 컴포넌트 제작 기법을 통한 재사용성 향상. |
|
| 중점 | - 컴포넌트 중심 | |
| 컴포넌트 구성요소 |
1. 컴포넌트 | Context - 컴포넌트 기능과 역할 Interface - 기능을 외부에 제공 |
| 2. 컨데이너 | 컴포넌트를 구현하기 위한 서비스 런타임 환경 컴포넌트 생성 및 소멸 관리 |
|
| 3. 어플리케이션 서버 | ||
| 개발순서 | 도메인 분석 -> 도메인 설계 -> 컴포넌트 추출 -> 컴포넌트 설계 -> 컴포넌트 구현 | |
| 컴포넌트 방법론 품질 측정 지료 |
1. 기능에 대한 이해의 용이성 2. 변경에 대한 용이성 3. 컴포넌트들 간의 결합도 (응집도는 이미 고려되어 컴포넌트가 만들어진 상태임) |
|
728x90
반응형
LIST
'소프트웨어공학' 카테고리의 다른 글
| 함수 종속에 대한 추론규칙 (암스트롱의 공리) (0) | 2019.10.30 |
|---|---|
| 정보시스템 감리기준 (행정안전부 고시 제2017-1호) (0) | 2019.10.28 |
| 소프트웨어 개발 방법론 (2/3) (0) | 2019.10.23 |
| 소프트웨어 개발 방법론 (1/3) (0) | 2019.10.22 |
| 소프트웨어 안전성 분석 기법 - FTA , FMEA, HAZOP (0) | 2019.10.20 |
