구조적 프로그래밍 설계
구조적 프로그래밍 설계 구조 및 절차
구조화 프로그래밍이라고도 함.
절차적 프로그래밍 기반 아래 만들어진 프로그래밍 기법
설계 구조
(1) 순차 구조
(2) 선택 구조
(3) 반복구조
구조적 프로그래밍 언어 개발 절차
(1) 요구사항 분석
- 고객의 요구사항을 수집 명세화
(2) 구조적 분석
- 데이터 흐름도 작성, 프로세스를 하향식으로 분할하고 시각적으로 표현 (ERD, DFD)
(3) 구조적 설계
- 모듈 중심 설계, 재활용,결합도를 낮춰 독립성을 높인다.
(4) 구조적 프로그래밍
- 순차, 선택, 반속의 논리 구조로 구성하여 프로그램 복잡성을 최소화한다.
구조적 프로그래밍 설계서 구성요소 및 작성 방법
구조적 프로그램 구성요소
(1) 데이터 흐름도 DFD(Data Flow Diagram)
- 데이터 각 기능을 분할하여 표현한 구조도
(2)자료사전 DD(Data Dictionary)
- 자료의 의미나 자료의 단위 및 값에 대한 사항을 정의하는 도구
- DFD에 표현된 자료 저장소를 구체적으로 명시하기 위해 사용
(3) 상태 전이도 STD(State Transition Diagram)
- 다른 상태로 변경되는 과정 및 해당 과정의 프로세스 명세를 작성
(4) 소단위 명세 Minispec(Mini Specification)
- 나눌 수 없는 부분까지 기능을 분리하여 작성한 명세서. 구조 언어를 사용하거나 N-S Chart를 이용
DFD 기반 구조적 프로그래밍 설계 요소
(1) DFD 구성요소
(가) 프로세스
1) 데이터를 원하는 데이터로 변환하여 출력시키는 과정
2) 자체적으로 데이터 생성 불가
(나) 데이터 흐름(Data Flow)
- DFD의 구성요소들 간의 인터페이스
(다) 데이터 저장소(Data Store)
1) 저장되어 있는 정보 집합ㄷ
(라) 외부 엔티티(External Entity)
1) 데이터 흐름도를 주도하는 활성 객체
2) 데이터 흐름도의 입력과 출력에 붙는다.
3) 프로세스 처리 과정의 데이터 발생의 시작 및 종료를 나타낸다.
(2) DFD설계 방법
구조적 프로그래밍 언어 개요
1. 절차식 언어
2. 명령어 언어
3. 함수 중심 언어
구조적 프로그래밍 유형
1. C 언어
- 이식성이 좋고, 구조화 프로그램을 작성하기 용이한다.
- 고급언어와 저급언어의 특성을 통시에 가짐
2. 파스칼(Pascal)
- 문법이 간경하면서도 사용하기가 편리하고 프로그램의 이해가 쉬워 구조적 프로그램 언어로도 널리 이용된다.
3. 에이다(Ada)
- 높은 신뢰도를 갖고 장시간 운용 가능한(Long-Lived) 대규모 시스템(System in the Large)을 구성하기 위한 언어
주요 구현 언어 문법
1. 조건문
(1) if문
(2) if~else문
(3) switch 분기문
2. 반복문
(1) for 반복문
(2) while 반복문
(3) do-while 반복문
응집도
모듈 내부 요소들이 서로 연관되어 있는 정도를 나타내는 정도이다.
응집도가 강할수록 품질이 높고 응집도가 약할수록 품질이 낮다.
응집도는 기능적, 순차적, 교환적,절차적,시간적,논리적, 우연적 7가지가 있다.
7응집도 기 순 교 절 시 논 우
결합도
모듈간에 상호 의존하는 정도, 두 묘듈사이의 연관 관계를 말하고, 응집도와 반대로 결합도가 강할 수록
품질이 낮고, 결합도가 약할 수록 품질이 높다.
내용결합도, 공통결합도, 외부결합도, 제어결합도, 스탬프결합도, 자료결합도
6결합도 내공 외제스자
객체지향 프로그래밍 설계
2.객체 지향 설계 원칙
(1) 단일 책임 원칙
- 모든클래스는 각각 하나의 책임만 가져야 한다.그 책임을 완전히 캡슐화해야 함을 말한다.
(2) 개방 폐쇄 원칙
- 확장에는 열려있고 수정에는 닫혀 있어 기존 코드를 변경하지 않고 기능을 추가할 수 있도록 설계가 되어야 한다는 원칙
(3) 리스코프 치환 원칙
- 자식 클래스는 자신의 부모 클래스를 대체할 수 있다는 원칙.
- 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 만족한다.
(4) 인터페이스 분리 원칙
- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙이다.
- 하나의 평범한 인터페이스보다 여러 개의 구체적인 인터페이스가 좋다.
(5) 의존 역전 원칙
- 변화가 없는 것에 의존해야 한다는 원칙이다.
- 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺어야 하는 원칙.
UML의 이해
1. 유즈케이스 다이어그램
-개발자 간의 의사 소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다.
2. 클래스 다이어그램
- UML의 구조 다이어그램으로서 클래스 내부 구성요소 및 클래스간의 관계를 도식화하여 시스템의
특정 모듈이나 일부 또는 전체 구조를 나타낸다.
(1)속성
(2) 행동
3. 시퀸스 다이어그램
- 문제해결을 위한 객체를 정의하고 객체 간의 상호작용 메시지 시퀸스를 시간의 흐름에 따라 나타내는 다이어그램이다.
(1) 활성 객체
- 시스템내의 유효한 객체 라이프라인을 가진다.
(2) 메시지
- 서로 다른 객체 간의 상호작용 혹은 의사소통 통신을 정의하는 요소.
- 자신의 객체 라이프라인으로부터 다른 객체 라이프라인까지 선+화살표로 표시되며 메시지는 그 선의 위에 표시한다.
(3) 활성 박스
- 객체라이프라인 위에 그려지는 박스로 이 박스 위에서 객체의 호출이 이루어진다.
- 객체의 특정메소드 실행 혹은 정보처리가 실행되고 있거나 다른 객체의 메소드가 종료되기를 기다린다는 것을 나타낸다.
설계된 다이어그램을 분석
1. 유즈케이스 다이어그램을 분석
(1) 액터를 식별한다.
- 시스템과 작용하는 외부객체이다.
(가) 프라이머리 액터(Primary Actor)를 식별
- 시스템을 사용함으로써 이득을 얻는 액터로 보통 외부 객체가 사람일 때를 말하며 사람 모양을 이용해 표기
(나) 세컨더리 액터(Secondary Actor)을 식별
- 프라이머리액터가 이득을 얻기위해 도움을 주는 액터로 보통 외부시스템을 의미하며 박스에 <<actor>>을 입력하여 표기
2. 관계를 식별
(1) 포함 관계(필수적 관계)를 식별
- 여러 유즈케이스에서 중복되는 경우 분리하여 새로운 유즈케이스를 만드는 경우인 포함 관계. 상속관계로 구현
- <<include>>를 확인
(2) 일반 관계 식별
(3) 확장 관계를 식별
- 특정 조건을 만족하는 경우에만 실행되는 단계.
- <<extend>>를 확인
3. 클래스 다이어그램 분석
-클래스 네임(Class name)과 어트리뷰트 그리고 오퍼레이션으로 구성
(1) 속성확인
-명사형으로 많이 표현된다.
- 클래스의 멤버변수로 구현한다.
(2) 행동(오퍼레이션)을 확인
- 클래스 메소드( Class Method)로 구현할 수 있는 것을 확인
(3) 연관을 확인
-클래스 간의 논리적/물리적 관계를 나타낸다. 선과 선 끝의 머리 모양을 통해 관계를 구분한다.
(가) Dependency (연관)를 확인한다.
- 클래스가 다른 클래스와의 의존성을 가지고 있는 경우 의존 클래스의 상태 변화는 이를 참조하고 있는 클래스의 상태 변화(의존)를 의미한다.
(나) Association / Directed Association(연관) 을 확인한다.
- Association은 객체 간의 연관 관계를 나타낸다.
- Association 양방향성을 나타낸다.
- Directed Association 단방향성을 나타낸다.
- 객체 지향에서 Association은 보통 인스턴스 변수로의 참조를 의미한다.
- 즉 상대 클래스의 인스턴스를 어트리뷰트로 가질 떄 Association Relationship(연관 관계)이 있다고 한다.
(다) Aggregation(집합 연관)을 확인한다.
- Association 개념에서 조금 더 확장된 개념으로 전체와 부분의 관계를 나타낸다.
(라) Composition(합성 연관)을 확인한다.
- Aggregation처럼 전체와 부분의 관계를 띄고 있지만 부분에 해당하는 클래스의 라이프 사이클이 전체를 의미하는
클래스의 라이프 사이클과 동일하다는 점에서 차이가 있다.
(마) Generalization(일반화)을 확인한다.
-"is A" 관계를 가지는 두 클래스 간의 관계를 의미
- 객체 지향에서는 부모클래스와 자식 클래스간의 "상속" 관계로 해석된다.
(바) Realization(실체화)을 확인한다.
-객체 지향에서 Realization은 명세화된 혹은 정의만 된 오퍼레이션을 실체화 하는 것을 의미
-즉 인터페이스로 명세화된 기능을 실제 기능으로 구현하는 것을 말한다. Implement로 확인
4. 시퀸스 다이어그램을 분석한다.
(1) 활성 객체를 확인
(2) 메시지를 확인한다.
(3) 활성박스를 확인한다.
디자인패턴
- 디자인 패턴든 객체지향 프로그래밍 시 발생하는 여러 가지 문제에 대해 설계 사례를 분석하여 공통적으로 발생하는 문제를 해결하기 위한 방법론으로, 여러 설계들로 분류 하고, 각 문제 유형별로 가장 적합한 설계를 일반화 한 패턴이다.
(1) 콘텍스트(Context)
- 문제가 발생하는 여러 상황을 기술한다.
(2) 문제( Problem)
- 패턴이 적용되어 해결될 필요가 있는 여러 디자인 이슈를 기술한다.
(3) 해결(Solution)
- 문제를 해결하도록 설계를 구성하는 요소들과 그 요소들 사이의 책임 관계, 협력 관계를 기술한다.
- 해결은 다양한 상황에서 적용할 수 있는 일종의 템플릿이다.
디자인 패턴의 종류
(1) GoF 디자인 패턴
- GoF 디자인 패턴은 23가지의 디자인 패턴이 정리되어 있고, 구현 방식에 따라 생성(Creational), 구조(Structural),
행위(Behavioral) 3가지로 분류한다.
(2) GoF 디자인 패턴의 분류
객체지향 프로그래밍을 테스트한다.
(1) JUnit을 이용하여 테스트
- JUnit은 자바 프로그래밍 언어용 단위 테스트 도구로, 보이지 않고 숨겨진 단위 테스트를 끌어내어
정형화시켜 단위 테스트를 쉽게 해주는 테스트용 Framework이다.
(가) @Test 메소드가 호출할 때마다 새로운 인스턴스가 생성되어 독립적인 테스트가 가능하다.
(나) assert 문으로 테스트 케이스의 수행 결과를 판별할 수 있다.
(다) 성공(녹색), 실패(붉은색) 중 하나로 표시
(라) 최적화된 코드를 유추해내는 기능도 제공한다.
객체지향 예외처리를 한다.
프로그램 실행 중 발생할 수 있는 예외적인 상황을 대비한 코드를 미리 만들어두는 것으로 문제 발생 시 좀 더 안전 한 구조를 제공하며 문제 해경에 필요한 정보 등을 제공할 수 있다.
(1)예외 처리 유형을 고려한다.
(가) Checked Exception
- Exception 클래스를 상속받아 구현된 클래스로 컴파일러에 의해 강제로 예외 처리가 요구됨
(나) Uncehcked Exception
- RuntimeException 클래스를 상속 받아 구현된 클래스로 강제로 예외 처리가 요구되지는 않지만 필요에 따라 예외 처리가
가능한 Exception
객체지향을 리펙토링한다.
(1) 리팩토링 과정을 고민
(가) 문제를 찾는다.
(나) 문제의 특징을 정한다.
(다) 솔루션을 디자인한다.
(라) 코드를 수정한다.
(2) 리팩토링 기법을 적용한다.
(가) Rename - 이름 재설정
(나) Move Class - 클래스의 이동
(다) Extract Method - 메소드 추출
(라) Extract Superclass - 슈퍼클래스를 추출
(마) Replace Conditional with Polymorphism - 다형성을 조건으로 하는 것을 대체
스크립트언어 설계
-스크립트 언어는 응용소프트웨어를 제어하는 컴퓨터 프로그래밍 언어이다.
- 초창기 스크립트 언어는 배치 언어 또는 작업 제어 언어 라고도 불렸다.
스크립트 언어 특징
(1) 인터프리터 언어
- 코드를 작성함과 동시에 인터프리터가 기계어로 번역하고 실행한다.
(2) 단순한 구문
- 스크립트 언어는 타 프로그래밍 언어에 비해 단순한 구문과 의미를 내포한다.
(3) 컴파일 시간 소요
- 스크립트 언어는 컴파일된 프로그램보다 실행 시간이 오래 걸린다.
- 스크립트 언어는 모든 명령어가 기본 명령어 처리기에 의해 직접 처리되지 못하고, 다른 프로그램에 의해
전 처리가 필요하기 때문이다.
(4) 신속한 활용
- 일반적으로 스크립트 언어는 빠르게 배우고 작성하기 위해 고안된 언어이다.
스크립트 프로그래밍 원리
(1) 스크립트 코드 작성
(2) Byte Code 변환
(3) 기계어 변환
(4) CPU 코드 변환