프로그래밍 방법론-퀵 가이드

재고 관리, 급여 처리, 학생 입학, 시험 결과 처리 등과 같은 실제 문제를 해결하기 위해 프로그램을 개발할 때는 거대하고 복잡한 경향이 있습니다. 이러한 복잡한 문제를 분석하고 소프트웨어 개발을 계획하고 개발 프로세스를 제어하는 접근 방식을programming methodology.

프로그래밍 방법론의 유형

소프트웨어 개발자들 사이에는 많은 유형의 프로그래밍 방법이 있습니다.

절차 적 프로그래밍

문제는 각각 하나의 작업을 수행하는 절차 또는 코드 블록으로 나뉩니다. 함께 취해진 모든 절차가 전체 프로그램을 구성합니다. 복잡성이 낮은 소규모 프로그램에만 적합합니다.

Example− 덧셈, 뺄셈, 곱셈, 나눗셈, 제곱근 및 비교를 수행하는 계산기 프로그램의 경우 이러한 각 연산을 별도의 절차로 개발할 수 있습니다. 기본 프로그램에서 각 절차는 사용자의 선택에 따라 호출됩니다.

객체 지향 프로그래밍

여기서 솔루션은 문제의 일부인 개체 또는 개체를 중심으로합니다. 이 솔루션은 엔터티와 관련된 데이터를 저장하는 방법, 엔터티가 작동하는 방식 및 응집력있는 솔루션을 제공하기 위해 서로 상호 작용하는 방식을 다룹니다.

Example − 급여 관리 시스템을 개발해야하는 경우 솔루션을 구축해야하는 직원, 급여 구조, 휴가 규칙 등과 같은 개체가 있습니다.

함수형 프로그래밍

여기서 문제 또는 원하는 솔루션은 기능 단위로 분류됩니다. 각 단위는 자체 작업을 수행하며 자급 자족합니다. 그런 다음 이러한 장치를 함께 연결하여 완전한 솔루션을 형성합니다.

Example − 급여 처리에는 직원 데이터 유지 관리, 기본 급여 계산, 총 급여 계산, 휴가 처리, 대출 상환 처리 등과 같은 기능 단위가있을 수 있습니다.

논리 프로그래밍

여기서 문제는 기능 단위가 아닌 논리 단위로 분류됩니다. Example:학교 관리 시스템에서 사용자는 담임 교사, 과목 교사, 연구실 조교, 코디네이터, 학업 담당자 등과 같이 매우 정의 된 역할을 가지고 있습니다. 따라서 소프트웨어는 사용자 역할에 따라 단위로 나눌 수 있습니다. 각 사용자는 다른 인터페이스, 권한 등을 가질 수 있습니다.

소프트웨어 개발자는 소프트웨어를 개발하기 위해 이러한 방법론 중 하나 또는 둘 이상의 조합을 선택할 수 있습니다. 논의 된 각 방법론에서 문제는 더 작은 단위로 분류되어야합니다. 이를 위해 개발자는 다음 두 가지 방법 중 하나를 사용합니다.

하향식 접근 방식
상향식 접근 방식

하향식 또는 모듈 식 접근 방식

문제는 더 작은 단위로 분류되며 더 작은 단위로 더 분할 될 수 있습니다. 각 단위는module. 각 모듈은 작업을 수행하는 데 필요한 모든 것을 갖춘 자급 자족 장치입니다.

다음 그림은 급여 처리 프로그램을 개발하는 동안 모듈 방식을 따라 다른 모듈을 만드는 방법의 예를 보여줍니다.

상향식 접근 방식

상향식 접근 방식에서 시스템 설계는 가장 낮은 수준의 구성 요소에서 시작하여 더 높은 수준의 구성 요소를 얻기 위해 상호 연결됩니다. 이 프로세스는 모든 시스템 구성 요소의 계층이 생성 될 때까지 계속됩니다. 그러나 실제 시나리오에서는 처음에 모든 최하위 구성 요소를 아는 것이 매우 어렵습니다. 따라서 상향식 접근 방식은 매우 간단한 문제에만 사용됩니다.

계산기 프로그램의 구성 요소를 살펴 보겠습니다.

일반적인 소프트웨어 개발 프로세스는 다음 단계를 따릅니다.

요구 사항 수집
문제 정의
시스템 디자인
Implementation
Testing
Documentation
교육 및 지원
Maintenance

처음 두 단계는 팀이 문제를 이해하는 데 도움이되며 해결책을 찾는 데 가장 중요한 첫 단계입니다. 요구 사항 수집, 문제 정의 및 시스템 설계를 담당하는 사람이 호출됩니다.system analyst.

요구 사항 수집

일반적으로 클라이언트 나 사용자는 문제 나 요구 사항을 명확하게 정의 할 수 없습니다. 그들은 자신이 원하는 것이 무엇인지 모호합니다. 따라서 시스템 개발자는 해결해야하는 문제 또는 제공해야하는 문제를 이해하기 위해 클라이언트 요구 사항을 수집해야합니다. 문제에 대한 자세한 이해는 솔루션이 개발되고있는 사업 영역을 먼저 이해해야 만 가능합니다. 비즈니스를 이해하는 데 도움이되는 몇 가지 주요 질문은 다음과 같습니다.

무엇을하고 있습니까?
어떻게 진행되고 있습니까?
작업의 빈도는 얼마입니까?
결정 또는 거래의 양은 얼마입니까?
어떤 문제가 발생합니까?

이 정보를 수집하는 데 도움이되는 몇 가지 기술은 다음과 같습니다.

Interviews
Questionnaires
기존 시스템 문서 연구
비즈니스 데이터 분석

시스템 분석가는 SMART (구체적, 측정 가능, 합의, 현실적 및 시간 기반) 요구 사항을 식별하기 위해 명확하고 간결하지만 철저한 요구 사항 문서를 작성해야합니다. 그렇게하지 않으면-

불완전한 문제 정의
잘못된 프로그램 목표
고객에게 필요한 결과를 제공하기위한 재 작업
비용 증가
지연된 배송

필요한 정보의 깊이로 인해 요구 사항 수집은 detailed investigation.

문제 정의

요구 사항을 수집하고 분석 한 후 문제 설명을 명확하게 설명해야합니다. 문제 정의는 어떤 문제를 해결해야하는지 모호하지 않아야합니다. 명확한 문제 진술이 필요합니다.

프로젝트 범위 정의
팀 집중 유지
프로젝트 진행
프로젝트 종료시 원하는 결과가 달성되었는지 확인

종종 코딩은 소프트웨어 개발 프로세스에서 가장 필수적인 부분으로 간주됩니다. 그러나 코딩은 프로세스의 일부일 뿐이며 시스템이 올바르게 설계된 경우 실제로 최소한의 시간이 걸릴 수 있습니다. 시스템을 설계하기 전에 당면한 문제에 대한 솔루션을 식별해야합니다.

시스템 설계에 대해 가장 먼저 주목해야 할 점은 처음에는 시스템 분석가가 둘 이상의 솔루션을 제시 할 수 있다는 것입니다. 그러나 최종 솔루션 또는 제품은 하나 일 수 있습니다. 요구 사항 수집 단계에서 수집 된 데이터에 대한 심층 분석은 고유 한 솔루션을 찾는 데 도움이 될 수 있습니다. 문제를 올바르게 정의하는 것도 해결책을 찾는 데 중요합니다.

여러 솔루션의 문제에 직면했을 때 분석가는 순서도, 데이터 흐름 다이어그램, 엔터티 관계 다이어그램 등과 같은 시각적 도구를 사용하여 각 솔루션을 심층적으로 이해합니다.

순서도

순서도는 기호와 다이어그램을 통해 시스템의 워크 플로와 데이터 흐름을 설명하는 프로세스입니다. 시스템 분석가가 문제에 대한 솔루션을 식별하는 데 도움이되는 중요한 도구입니다. 시스템의 구성 요소를 시각적으로 보여줍니다.

이것들은 순서도의 장점입니다-

시각적 표현은 프로그램 논리를 이해하는 데 도움이됩니다.
실제 프로그램 코딩을위한 청사진 역할을합니다.
순서도는 프로그램 문서화에 중요합니다.
순서도는 프로그램 유지 관리 중에 중요한 도움이됩니다.

이것들은 순서도의 단점입니다-

복잡한 논리는 순서도를 사용하여 묘사 할 수 없습니다.
로직 또는 데이터 / 워크 플로가 변경된 경우 플로차트를 완전히 다시 그려야합니다.

데이터 흐름 다이어그램

데이터 흐름 다이어그램 또는 DFD는 시스템 또는 하위 시스템을 통한 데이터 흐름의 그래픽 표현입니다. 각 프로세스에는 자체 데이터 흐름이 있으며 데이터 흐름 다이어그램 수준이 있습니다. 레벨 0은 전체 시스템에 대한 입력 및 출력 데이터를 보여줍니다. 그런 다음 시스템이 모듈로 분할되고 레벨 1 DFD는 각 모듈에 대한 데이터 흐름을 개별적으로 보여줍니다. 모듈은 필요한 경우 하위 모듈로 더 나눌 수 있으며 레벨 2 DFD가 그려집니다.

의사 코드

시스템이 설계되면 구현을 위해 프로젝트 관리자에게 전달됩니다 (예 : 코딩). 프로그램의 실제 코딩은 프로그래밍 언어로 이루어지며 해당 언어로 훈련 된 프로그래머 만 이해할 수 있습니다. 그러나 실제 코딩이 발생하기 전에 사용되는 프로그래밍 언어와 유사한 표기법을 사용하여 프로그램의 기본 작동 원리, 작업 흐름 및 데이터 흐름이 작성됩니다. 이러한 표기법을pseudocode.

다음은 C ++ 의사 코드의 예입니다. 프로그래머는 프로그램 코드를 얻기 위해 각 명령문을 C ++ 구문으로 변환하기 만하면됩니다.

수학적 연산 식별

컴퓨터에 대한 모든 명령은 최종적으로 기계 수준에서 산술 및 논리 연산으로 구현됩니다. 이러한 작업은 중요합니다.

메모리 공간을 차지
실행에 시간을 투자하십시오
소프트웨어 효율성 결정
전반적인 소프트웨어 성능에 영향

시스템 분석가는 당면한 문제에 대한 고유 한 솔루션을 식별하면서 모든 주요 수학 연산을 식별하려고합니다.

실제 문제는 복잡하고 큽니다. 모 놀리 식 솔루션이 개발되면 다음과 같은 문제가 발생합니다.

하나의 큰 프로그램을 작성, 테스트 및 구현하기 어려움
최종 제품 배송 후 수정이 거의 불가능합니다.
프로그램 유지 관리가 매우 어렵습니다.
하나의 오류로 전체 시스템이 중단 될 수 있습니다.

이러한 문제를 극복하기 위해 솔루션은 modules. 개발, 구현, 수정 및 유지 관리의 용이성을 위해 하나의 큰 솔루션을 더 작은 모듈로 나누는 기술을modular technique 프로그래밍 또는 소프트웨어 개발.

모듈 식 프로그래밍의 장점

모듈 식 프로그래밍은 다음과 같은 이점을 제공합니다.

각 모듈을 병렬로 개발할 수 있으므로 더 빠른 개발이 가능합니다.
모듈은 재사용 가능
각 모듈을 독립적으로 테스트해야하므로 테스트가 더 빠르고 강력합니다.
전체 프로그램의 디버깅 및 유지 관리가 더 쉽습니다.
모듈은 더 작고 복잡도가 낮아 이해하기 쉽습니다.

모듈 식별

소프트웨어에서 모듈을 식별하는 것은 올바른 방법이 하나도 없기 때문에 매우 어려운 작업입니다. 다음은 모듈 식별에 대한 몇 가지 지침입니다.

데이터가 시스템의 가장 중요한 요소 인 경우 관련 데이터를 처리하는 모듈을 만듭니다.
시스템에서 제공하는 서비스가 다양 할 경우 시스템을 기능 모듈로 분할합니다.
다른 모든 방법이 실패하면 요구 사항 수집 단계에서 시스템에 대한 이해에 따라 시스템을 논리 모듈로 분할합니다.

코딩을 위해 각 모듈은 프로그래밍의 용이성을 위해 더 작은 모듈로 다시 세분화되어야합니다. 이는 위에서 공유 한 세 가지 팁을 특정 프로그래밍 규칙과 결합하여 다시 수행 할 수 있습니다. 예를 들어, C ++ 및 Java와 같은 객체 지향 프로그래밍 언어의 경우 데이터 및 메서드가있는 각 클래스는 단일 모듈을 형성 할 수 있습니다.

단계별 솔루션

모듈을 구현하려면 각 모듈의 프로세스 흐름을 단계별로 설명해야합니다. 단계별 솔루션은 다음을 사용하여 개발할 수 있습니다.algorithms 또는 pseudocodes. 단계별 솔루션을 제공하면 다음과 같은 이점이 있습니다.

해결책을 읽는 사람은 누구나 문제와 해결책을 모두 이해할 수 있습니다.
프로그래머와 비 프로그래머 모두 똑같이 이해할 수 있습니다.
코딩 중에 각 명령문을 프로그램 명령문으로 변환하기 만하면됩니다.
문서의 일부가 될 수 있으며 프로그램 유지 관리를 지원할 수 있습니다.
식별자 이름, 필요한 작업 등과 같은 마이크로 수준 세부 정보가 자동으로 해결됩니다.

예를 살펴 보겠습니다.

제어 구조

위의 예에서 볼 수 있듯이 프로그램 로직이 실행될 필요는 없습니다. sequentially. 프로그래밍 언어에서control structures주어진 매개 변수를 기반으로 프로그램 흐름에 대한 결정을 내립니다. 이는 소프트웨어의 매우 중요한 요소이며 코딩이 시작되기 전에 식별되어야합니다.

알고리즘 및 pseudocodes 분석가와 프로그래머가 제어 구조가 필요한 위치를 식별하는 데 도움이됩니다.

제어 구조는 다음 세 가지 유형입니다.

의사 결정 제어 구조

의사 결정 제어 구조는 실행될 다음 단계가 기준에 따라 달라질 때 사용됩니다. 이 기준은 일반적으로 평가해야하는 하나 이상의 부울 표현식입니다. 부울 식은 항상 "true"또는 "false"로 평가됩니다. 기준이 "참"이면 한 세트의 문이 실행되고 기준이 "거짓"으로 평가되면 다른 세트가 실행됩니다. 예를 들어, if 문

선택 제어 구조

선택 제어 구조는 프로그램 순서가 특정 질문에 대한 대답에 의존 할 때 사용됩니다. 예를 들어, 프로그램에는 사용자를위한 많은 옵션이 있습니다. 다음에 실행할 문은 선택한 옵션에 따라 다릅니다. 예를 들면switch 성명서, case 성명서.

반복 / 루프 제어 구조

반복 제어 구조는 일련의 명령문이 여러 번 반복 될 때 사용됩니다. 반복 횟수는 시작하기 전에 알고 있거나 표현식 값에 따라 달라질 수 있습니다. 예를 들면for 성명서, while 성명서, do while 성명서 등

위 이미지에서 볼 수 있듯이 선택 구조와 의사 결정 구조는 모두 순서도에서 유사하게 구현됩니다. 선택 제어는 순차적으로 취해진 일련의 결정문 일뿐입니다.

다음은 이러한 명령문이 작동하는 방식을 보여주는 프로그램의 몇 가지 예입니다.

문제를 해결하기 위해 따라야하는 유한 한 일련의 단계를 algorithm. 알고리즘은 일반적으로 실제 코딩이 완료되기 전에 개발됩니다. 프로그래머가 아닌 사람도 쉽게 이해할 수 있도록 영어와 같은 언어로 작성되었습니다.

때때로 알고리즘은 pseudocodes, 즉 사용할 프로그래밍 언어와 유사한 언어. 문제 해결을위한 알고리즘 작성은 다음과 같은 이점을 제공합니다.

팀 구성원 간의 효과적인 의사 소통을 촉진합니다.
당면한 문제 분석 가능
코딩 청사진 역할
디버깅 지원
유지 관리 단계에서 나중에 참조 할 수 있도록 소프트웨어 설명서의 일부가됩니다.

이것들은 좋고 정확한 알고리즘의 특성입니다-

일련의 입력이 있습니다.
단계는 고유하게 정의됩니다.
제한된 수의 단계가 있습니다.
원하는 출력을 생성합니다.

예제 알고리즘

먼저 알고리즘 생성을위한 실제 상황의 예를 들어 보겠습니다. 다음은 펜을 구입하기 위해 시장에 나가는 알고리즘입니다.

이 알고리즘의 4 단계는 그 자체로 완전한 작업이며 별도의 알고리즘을 작성할 수 있습니다. 이제 숫자가 양수인지 음수인지 확인하는 알고리즘을 만들어 보겠습니다.

Flowchart프로그램의 논리적 단계 시퀀스를 도식적으로 표현한 것입니다. 순서도는 단순한 기하학적 모양을 사용하여 프로세스를 묘사하고 화살표를 사용하여 관계 및 프로세스 / 데이터 흐름을 표시합니다.

순서도 기호

다음은 순서도를 그리는 데 사용되는 몇 가지 일반적인 기호에 대한 차트입니다.

상징	기호 이름	목적
	시작 멈춤	프로그램의 시작과 끝을 표시하기 위해 알고리즘의 시작과 끝에서 사용됩니다.
	방법	수학적 연산과 같은 프로세스를 나타냅니다.
	입출력	프로그램 입력 및 출력을 표시하는 데 사용됩니다.
	결정	일반적으로 예 또는 아니오로 대답하는 프로그램의 결정문을 나타냅니다.
	화살	다른 모양 간의 관계를 보여줍니다.
	온 페이지 커넥터	동일한 페이지에있는 두 개 이상의 플로우 차트 부분을 연결합니다.
	페이지 외부 커넥터	서로 다른 페이지에 펼쳐진 순서도의 두 부분을 연결합니다.

순서도 개발 지침

다음은 순서도를 개발하는 동안 명심해야 할 몇 가지 사항입니다.

순서도에는 시작 및 중지 기호가 하나만있을 수 있습니다.
페이지상의 커넥터는 숫자를 사용하여 참조됩니다.
페이지 외부 커넥터는 알파벳을 사용하여 참조됩니다.
프로세스의 일반적인 흐름은 위에서 아래로 또는 왼쪽에서 오른쪽으로
화살표가 서로 교차해서는 안됩니다.

순서도 예

다음은 펜을 구입하기 위해 시장에 나가는 순서도입니다.

다음은 두 숫자의 평균을 계산하는 순서도입니다.

아시다시피, 컴퓨터에는 자체 지능이 없습니다. 그것은 단순히instructions 사용자가 제공합니다. Instructions컴퓨터 프로그램의 빌딩 블록이므로 소프트웨어입니다. 명확한 지침을 제공하는 것은 성공적인 프로그램을 구축하는 데 중요합니다. 프로그래머 또는 소프트웨어 개발자는 명확한 지침을 작성하는 습관을 가져야합니다. 이를 수행하는 두 가지 방법이 있습니다.

표현의 명확성

프로그램의 표현식은 산술 또는 논리 계산을 수행하는 일련의 연산자와 피연산자입니다. 다음은 유효한 표현식의 몇 가지 예입니다.

두 값 비교
변수, 개체 또는 클래스 정의
하나 이상의 변수를 사용한 산술 계산
데이터베이스에서 데이터 검색
데이터베이스의 값 업데이트

모호하지 않은 표현을 작성하는 것은 모든 프로그래머가 개발해야하는 기술입니다. 다음은 이러한 표현을 작성할 때 유의해야 할 몇 가지 사항입니다.

명확한 결과

식의 평가는 하나의 명확한 컷 결과를 제공해야합니다. 예를 들어 단항 연산자는주의해서 사용해야합니다.

복잡한 표현 피하기

한 번의 표현으로 많은 것을 성취하려고하지 마십시오. 일이 복잡해지기 시작하는 순간 두 개 이상의 표현으로 나누세요.

지침의 단순성

명확한 지침을 작성해야하는 것은 컴퓨터만을위한 것이 아닙니다. 나중에 프로그램을 읽는 사람은 누구나 (당신 자신도 !!) 명령이 달성하려는 것을 이해할 수 있어야합니다. 프로그래머가 일정 시간이 지난 후 다시 방문 할 때 자신의 프로그램에 익숙하지 않은 것은 매우 일반적입니다. 이것은 그러한 프로그램의 유지 및 수정이 매우 어려울 것임을 나타냅니다.

간단한 지침을 작성하면이 문제를 피하는 데 도움이됩니다. 다음은 간단한 지침을 작성하는 몇 가지 팁입니다.

Avoid clever instructions − 아무도 제대로 이해하지 못하면 영리한 지침이 나중에 그렇게 영리 해 보이지 않을 수 있습니다.
One instruction per task − 한 번에 한 가지 이상의 일을하려고하면 지침이 복잡해집니다.
Use standards− 모든 언어에는 표준이 있습니다. 프로젝트에서 혼자 작업하는 것이 아니라는 점을 기억하십시오. 코딩을위한 프로젝트 표준 및 지침을 따릅니다.

이 장에서는 좋은 프로그램을 작성하는 방법을 다룰 것입니다. 하지만 그 전에 좋은 프로그램의 특징이 무엇인지 살펴 보겠습니다.

Portable− 프로그램 또는 소프트웨어는 동일한 유형의 모든 컴퓨터에서 실행되어야합니다. 같은 유형이란 개인용 컴퓨터 용으로 개발 된 소프트웨어가 모든 PC에서 실행되어야 함을 의미합니다. 또는 태블릿 용으로 작성된 소프트웨어는 올바른 사양을 가진 모든 태블릿에서 실행되어야합니다.
Efficient− 할당 된 작업을 신속하게 수행하는 소프트웨어는 효율적이라고합니다. 코드 최적화 및 메모리 최적화는 프로그램 효율성을 높이는 방법 중 일부입니다.

Effective− 소프트웨어는 당면한 문제 해결을 지원해야합니다. 이를 수행하는 소프트웨어는 효과적이라고합니다.
Reliable − 프로그램은 동일한 입력 세트가 제공 될 때마다 동일한 출력을 제공해야합니다.
User friendly − 프로그램 인터페이스, 클릭 가능한 링크 및 아이콘 등은 사용자 친화적이어야합니다.
Self-documenting − 식별자 이름, 모듈 이름 등이 명시적인 이름 사용으로 인해 자신을 설명 할 수있는 모든 프로그램 또는 소프트웨어.

다음은 좋은 프로그램을 작성할 수있는 몇 가지 방법입니다.

적절한 식별자 이름

변수, 개체, 함수, 클래스 또는 메서드를 식별하는 이름을 identifier. 적절한 식별자 이름을 제공하면 프로그램이 자체 문서화됩니다. 이것은 객체의 이름이 그것이 무엇을하는지 또는 어떤 정보를 저장하는지 알려준다는 것을 의미합니다. 이 SQL 명령어의 예를 들어 보겠습니다.

10 행을보세요. 프로그램을 읽는 모든 사람에게 학생의 ID, 이름 및 롤 번호가 선택되어야 함을 알려줍니다. 변수의 이름은이를 자명하게 만듭니다. 다음은 적절한 식별자 이름을 만드는 몇 가지 팁입니다.

언어 지침 사용
명확성을 유지하기 위해 긴 이름을 지정하는 것을 부끄러워하지 마십시오.
대문자와 소문자 사용
언어가 허용하더라도 두 식별자에 동일한 이름을 지정하지 마십시오.
둘 이상의 식별자에 상호 배타적 인 범위가 있더라도 동일한 이름을 지정하지 마십시오.

코멘트

위 이미지에서 8 행을보십시오. 다음 코드 몇 행이 성적표를 생성 할 학생 목록을 검색 할 것임을 독자에게 알려줍니다. 이 줄은 코드의 일부가 아니라 프로그램을보다 사용자 친화적으로 만들기 위해서만 제공됩니다.

컴파일되지 않고 프로그래머를위한 메모 또는 설명으로 작성된 이러한 표현을 comment. 다음 프로그램 세그먼트의 설명을보십시오. 주석은 //로 시작합니다.

주석은 다음과 같이 삽입 할 수 있습니다.

프로그램의 목적을 설명하는 프롤로그
논리 또는 기능 블록의 시작 및 / 또는 끝
특별한 시나리오 또는 예외 사항에 대해 기록하십시오.

읽는 동안 코드 흐름을 끊음으로써 비생산적 일 수 있으므로 불필요한 주석을 추가하지 않아야합니다. 컴파일러는 주석과 들여 쓰기를 무시할 수 있지만 독자는 각각을 읽는 경향이 있습니다.

들여 쓰기

왼쪽 또는 오른쪽 여백에서 텍스트의 거리를 호출합니다. indent. 프로그램에서 들여 쓰기는 논리적으로 분리 된 코드 블록을 분리하는 데 사용됩니다. 다음은 들여 쓰기 된 프로그램 세그먼트의 예입니다.

보시다시피 들여 쓰기 된 프로그램이 더 이해하기 쉽습니다. 제어 흐름for loop ...에 if 그리고 다시 for매우 명확합니다. 들여 쓰기는 제어 구조의 경우 특히 유용합니다.

공백이나 줄을 삽입하는 것도 들여 쓰기의 일부입니다. 다음은 들여 쓰기를 사용할 수 있고 사용해야하는 몇 가지 상황입니다.

프로그램 내에서 논리적 또는 기능적 코드 블록 사이의 빈 줄
연산자 주변의 공백
새 제어 구조 시작 부분의 탭

프로그램이나 소프트웨어에서 오류를 식별하고 제거하는 것을 debugging. 디버깅은 이상적으로 테스트 프로세스의 일부이지만 실제로는 프로그래밍의 모든 단계에서 수행됩니다. 코더는 계속 진행하기 전에 가장 작은 모듈을 디버깅해야합니다. 이를 통해 테스트 단계에서 발생하는 오류 수를 줄이고 테스트 시간과 노력을 크게 줄일 수 있습니다. 프로그램에서 발생할 수있는 오류 유형을 살펴 보겠습니다.

구문 오류

Syntax errors프로그램의 문법 오류입니다. 모든 언어에는 프로그램 작성을위한 식별자 생성, 표현식 작성 등과 같은 고유 한 규칙 집합이 있습니다. 이러한 규칙을 위반하면 오류가 호출됩니다.syntax errors. 많은 현대integrated development environments프로그램을 입력 할 때 구문 오류를 식별 할 수 있습니다. 그렇지 않으면 프로그램을 컴파일 할 때 표시됩니다. 예를 들어 보겠습니다.

이 프로그램에서 prod 변수는 선언되지 않았으며 컴파일러에 의해 발생합니다.

의미 오류

Semantic errors 또한 불린다 logical errors. 명령문에는 구문 오류가 없으므로 올바르게 컴파일되고 실행됩니다. 그러나 논리가 올바르지 않기 때문에 원하는 출력을 제공하지 않습니다. 예를 들어 보겠습니다.

13 행을보십시오. 여기서 프로그래머는 0으로 나누는 것을 피하기 위해 제수가 0인지 확인하려고합니다. 그러나 비교 연산자 ==를 사용하는 대신 할당 연산자 =가 사용되었습니다. 이제 "if 표현식"이 참으로 평가 될 때마다 프로그램은 "0으로 나눌 수 없습니다"로 출력을 제공합니다. 의도 한 바가 확실히 아닙니다 !!

논리적 오류는 어떤 프로그램에서도 감지 할 수 없습니다. 원하는 출력을 얻지 못한 경우 프로그래머가 직접 식별해야합니다.

런타임 오류

런타임 오류는 프로그램을 실행하는 동안 발생하는 오류입니다. 이것은 프로그램에 구문 오류가 없음을 의미합니다. 프로그램에서 발생할 수있는 가장 일반적인 런타임 오류는 다음과 같습니다.

무한 루프
'0'으로 나누기
사용자가 입력 한 잘못된 값 (예 : 정수 대신 문자열)

코드 최적화

품질과 효율성을 향상시키기 위해 코드를 수정하는 모든 방법이 호출됩니다. code optimization. Code quality코드의 수명을 결정합니다. 코드를 장기간 사용 및 유지 관리 할 수 있고, 제품에서 제품으로 이월되면 품질이 높고 수명이 길어집니다. 반대로 코드 조각이 짧은 기간 (예 : 버전이 유효 할 때까지) 만 사용하고 유지 관리 할 수 있다면 품질이 낮고 수명이 짧은 것으로 간주됩니다.

코드의 신뢰성과 속도는 code efficiency. 코드 효율성은 소프트웨어의 고성능을 보장하는 데 중요한 요소입니다.

코드 최적화에는 두 가지 접근 방식이 있습니다.

Intuition based optimization (IBO)− 여기서 프로그래머는 자신의 기술과 경험을 바탕으로 프로그램을 최적화하려고합니다. 이것은 작은 프로그램에서 작동 할 수 있지만 프로그램의 복잡성이 증가함에 따라 비참하게 실패합니다.
Evidence based optimization (EBO)− 여기서 자동화 된 도구를 사용하여 성능 병목 현상을 파악한 다음 관련 부분이 그에 따라 최적화됩니다. 모든 프로그래밍 언어에는 고유 한 코드 최적화 도구 세트가 있습니다. 예를 들어 PMD, FindBug 및 Clover는 Java 코드를 최적화하는 데 사용됩니다.

시간이 부족하고 메모리가 비싸기 때문에 코드는 실행 시간과 메모리 소비에 최적화되어 있습니다. 둘 사이에 균형이 있어야합니다. 만약time optimization 메모리에 대한 부하를 증가 시키거나 memory optimization 코드를 느리게 만들고 최적화 목적을 잃게됩니다.

실행 시간 최적화

사용자에게 빠른 서비스를 제공하기 위해서는 실행 시간에 대한 코드 최적화가 필요합니다. 다음은 실행 시간 최적화를위한 몇 가지 팁입니다.

기본 제공 실행 시간 최적화가있는 명령 사용
if 조건 대신 스위치 사용
루프 구조 내에서 함수 호출 최소화
프로그램에서 사용되는 데이터 구조 최적화

메모리 최적화

아시다시피 데이터와 명령어는 메모리를 소모합니다. 데이터라고하면 표현의 결과 인 중간 데이터를 의미하기도합니다. 또한 최적화하려는 프로그램이나 모듈을 구성하는 명령어의 수를 추적해야합니다. 다음은 몇 가지 팁입니다.memory optimization −

내장 메모리 최적화가있는 명령 사용
레지스터에 저장해야하는 변수의 사용을 최소화하십시오.
여러 번 실행되는 루프 내에서 전역 변수를 선언하지 마십시오.
sqrt ()와 같은 CPU 집약적 기능을 사용하지 마십시오.

소프트웨어 또는 프로그램을 사용자에게 설명하는 모든 서면 텍스트, 일러스트레이션 또는 비디오를 program or software document. 사용자는 프로그래머, 시스템 분석가 및 관리자에서 최종 사용자까지 누구나 될 수 있습니다. 다양한 개발 단계에서 여러 사용자를 위해 여러 문서를 만들 수 있습니다. 사실로,software documentation 전체 소프트웨어 개발 프로세스에서 중요한 프로세스입니다.

모듈 식 프로그래밍에서 문서는 소프트웨어의 다른 모듈이 다른 팀에서 개발되기 때문에 더욱 중요합니다. 개발 팀 이외의 사람이 모듈을 이해하기를 원하거나 이해해야하는 경우 훌륭하고 상세한 문서를 통해 작업을 더 쉽게 수행 할 수 있습니다.

다음은 문서 작성을위한 몇 가지 지침입니다.

독자의 관점에서 문서화해야합니다.
문서는 명확해야합니다.
반복이 없어야합니다
산업 표준을 사용해야합니다.
문서는 항상 업데이트해야합니다.
오래된 문서는 단계적 중단을 기록한 후 단계적으로 제거해야합니다.

문서화의 장점

다음은 프로그램 문서를 제공하는 장점 중 일부입니다.

소프트웨어 또는 프로그램의 모든 부분을 추적합니다.
유지 관리가 더 쉽습니다.
개발자 이외의 프로그래머는 소프트웨어의 모든 측면을 이해할 수 있습니다.
소프트웨어의 전반적인 품질 향상
사용자 교육 지원
사람들이 갑자기 시스템을 떠나는 경우 지식 분산을 보장하고 비용과 노력을 절감합니다.

예제 문서

소프트웨어에는 관련된 여러 유형의 문서가있을 수 있습니다. 중요한 것 중 일부는 다음과 같습니다.

User manual − 최종 사용자가 소프트웨어의 다양한 기능을 사용하기위한 지침 및 절차를 설명합니다.
Operational manual − 수행중인 모든 작업과 상호 종속성을 나열하고 설명합니다.
Design Document− 소프트웨어 개요를 제공하고 설계 요소를 자세히 설명합니다. 다음과 같은 세부 정보를 문서화합니다.data flow diagrams, entity relationship diagrams등
Requirements Document− 시스템의 모든 요구 사항 목록과 요구 사항의 실행 가능성 분석이 있습니다. 사용자 사례, 실제 시나리오 등이있을 수 있습니다.
Technical Documentation − 알고리즘, 순서도, 프로그램 코드, 기능 모듈 등과 같은 실제 프로그래밍 구성 요소에 대한 문서입니다.
Testing Document − 테스트 계획, 테스트 사례, 검증 계획, 검증 계획, 테스트 결과 등을 기록합니다. 테스트는 집중적 인 문서화가 필요한 소프트웨어 개발의 한 단계입니다.
List of Known Bugs− 모든 소프트웨어에는 매우 늦게 발견되었거나 무해하거나 수정하는 데 필요한 것보다 더 많은 노력과 시간이 소요되기 때문에 제거 할 수없는 버그 또는 오류가 있습니다. 이러한 버그는 나중에 제거 될 수 있도록 프로그램 설명서와 함께 나열됩니다. 또한 버그가 활성화되면 사용자, 구현 자 및 유지 보수 담당자를 돕습니다.

Program maintenance 이러한 결과를 달성하기 위해 배송 후 소프트웨어 또는 프로그램을 수정하는 프로세스입니다.

오류 수정
성능 향상
기능 추가
쓸모없는 부분 제거

소프트웨어가 가동 된 후 발생하는 오류를 수정하려면 유지 관리가 필요하다는 일반적인 인식에도 불구하고 실제로 대부분의 유지 관리 작업에는 기존 모듈에 사소한 또는 주요 기능을 추가하는 작업이 포함됩니다. 예를 들어 일부 새로운 데이터가 보고서에 추가되고, 입력 양식에 새 필드가 추가되고, 변경된 정부 법률을 통합하기 위해 수정되는 코드 등이 있습니다.

유지 관리 유형

유지 보수 활동은 네 가지 제목으로 분류 할 수 있습니다.

Corrective maintenance− 여기에서 현장 구현 후 발생하는 오류가 수정되었습니다. 오류는 사용자가 직접 지적 할 수 있습니다.
Preventive maintenance − 향후 오류를 방지하기 위해 수행되는 수정을 예방 유지 보수라고합니다.
Adaptive maintenance− 작업 환경이 변경되면 소프트웨어를 수정해야하는 경우가 있습니다. 이를 적응 형 유지 관리라고합니다. 예를 들어, 정부 교육 정책이 변경되면 학교 관리 소프트웨어의 학생 결과 처리 모듈에서 해당 변경이 이루어져야합니다.
Perfective maintenance− 클라이언트의 새로운 요구 사항을 통합하기 위해 기존 소프트웨어에서 수행 한 변경을 완벽한 유지 관리라고합니다. 여기서 목표는 항상 최신 기술로 최신 상태를 유지하는 것입니다.

유지 관리 도구

소프트웨어 개발자와 프로그래머는 많은 도구를 사용하여 소프트웨어 유지 관리를 지원합니다. 다음은 가장 널리 사용되는 몇 가지입니다.

Program slicer − 변경의 영향을받는 프로그램의 일부를 선택합니다.
Data flow analyzer − 소프트웨어에서 가능한 모든 데이터 흐름을 추적합니다.
Dynamic analyzer − 프로그램 실행 경로 추적
Static analyzer − 프로그램을 일반적으로보고 요약 할 수 있습니다.
Dependency analyzer − 프로그램의 여러 부분에 대한 상호 의존성을 이해하고 분석하는 데 도움이됩니다.