실기_1과목_소프트웨어개발의 기초

2018. 8. 27. 23:38정보처리기사

1과목] 실무 알고리즘 응용

1장] 소프트웨어개발의 기초


Section01. 객체지향 기법의 개요


- 객체지향 기법

현실세계의 개체를 하나의 객체로 만들어 소프트웨어 개발 시 이 객체들을 조립하여 작성할 수 있도록 하는 기법


-> 소프트웨어 위기의 해결책

-> 소프트웨어의 재사용 성 및 확장 용이 -> 고품질 소프트웨어 개발 및 유지보수 굿

-> 복잡한 구조 -> 단계/ 계층적 표현

-> 멀티미디어 데이터 및 병렬처리 지원

-> 사용자 개발자 쉽게 이해 가능

-> 객체, 클래스, 메세지로 구성되어 있음


1. 객체 (Object)

: 데이터와 메서드를 묶어 놓은 하나의 소프트웨어 모듈.

데이터 : 객체가 가지고 있는 정보로 속성이나 상태등을 나타낸다. (= 속성, 상태, 변수, 상수, 자료구조)

메서드 : 객체가 수행하는 기능, 데이터를 처리함. (= 함수, 서비스, 동작operation)


2. 클래스 (Class)

: 공통된 속성과 연산을 갖는 객체의 집합. 객체의 일반적인 타입

클래스에 속한 각각의 객체를 인스턴스 Instance라고 하며, 새로운 객체를 생성하는 것을 인스턴스화 instantiation라고 한다.


3. 메세지 (Message)

: 객체들간의 상호작용을 하는데 사용되는 수단. 

  객체에게 어떤 행위를 하도록 지시하는 명령.

 메세지 수신자, 객체가 수행할 메서드 명, 메서드 수행 시 필요한 인자 로 구성되어 있다.



Section02. 객체지향 기법의 기본 원칙


 캡슐화, 상속성, 다형성은 객체지향 기법만이 갖는 원칙이다.


- 캡슐화 (Encapsulation)

: 데이터와 메서드를 하나로 묶는 것. -> 세부내용이 정보은닉되어 변경이 발생 할 때 오류의 영향이 적다.

  재사용에 용이

  인터페이스가 단순해지고 결합도가 낮아진다.


- 정보은닉 (Information Hiding)

: 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근 허용

  객체의 수정이 다른 객체에게 최대한 영향 덜 주자


- 추상화 (Abstraction)

 : 불필요한 부분 생략, 객체의 속성 중 중요한 부분만 모델화

  인간이 복잡한 문제 다룰 때 사용 -> 약도

  최소의 비용으로 실제상황에 대처 및 가시적으로 구조 확인 가능


- 상속성 (Inheritance)

정의되어 있는 상위클래스의 모든 속성과 연산을 하위클래스가 물려받는것.

소프트웨어 재사용성 증대

다중상속성은 위험쓰


- 다형성 (Polymorphism)

: 메세지에 의해 객체가 연산을 수행하게 될 때 하나의 메세지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력




Section03. 객체지향 기법의 생명 주기


- 객체지향 기법의 생명 주기


                  [  계획 및 분석 -> 설계 -> 구현 -> 테스트 및 검증  ]


 * 꼭 이 순서대로 이뤄지지는 않는다. 

 * 개발 전과정에 걸쳐 동일한 방법론과 표현기법이 적용된다는 장점이 있다.

    (객체, 클래스, 메소드, 속성등이 동일한 개념으로 사용됨)



1. 객체지향 분석 (OOA : Object Oriented Analysis)

 사용자의 요구사항을 분석하여 그에 알맞게 모든 클래스, 연산, 관계등을 정의하여 모델링하는 작업.

 객체는 클래스로부터 인스턴스화하고 이 클래스를 식별하는 것이 객체지향 분석의 주요한 목적

 방법론 : 럼바우(Rumbaugh)방법, Booch(부치) 방법, Jacobson 방법, Coad와 Yourdon 방법, Wirfs-Brock 방법


2. 객체지향 설계 (OOD : Object Oriented Design )

 분석 단계에서 생성한 분석 모델을 설계 모델로 변환하는 작업.

 시스템 설계와 객체 설계 수행한다.

 최근 소프트웨어 제품의 전형적인 타입인 사용자 중심, 대화식 프로그램의 개발에 적합.

 *시스템을 구성하는 객체와 속성, 연산을 인식하는 것이 가장 중요 !

 *모듈화가 가장 중요한 설계 개념

 * 럼바우의 객체지향 설계가 가장 많이 사용됨.


[  문제정의 -> 요구 명세화 -> 객체 연산자 정의 -> 객체 인터페이스 결정 -> 객체 구현  ]


3. 객체지향 구현 

 설계 단계에서 생성된 설계 모델과 명세서를 기반으로 코딩하는 단계. real ~

 순차적 혹은 동시적 

 

-> 객체지향 프로그래밍(OOP : Object Oriented Programming)

     : 객체 (모듈 단위이이)를 중심으로 프로그램 개발하는 기법.

       현실 세계와 가까운 방식 -> 이해하기 쉽고 조작도 보다 쉬움.

       유지보수가 쉽고 재사용성이 높음.

     

     ; 객체지향 프로그래밍 언어의 종류 

       1) 객체 기반 언어 :  객체의 개념만 지원. Ada, Actor

       2) 클래스 기반 언어 : 객체와 클래스의 개념 지원. Clu

       3) 객체 지향성 언어 : 객체, 클래스ㅡ 상속의 개념을 모두 지원. Sumula, Smalltalk, C++, Objective C, Java


4. 객체지향 테스트 

 1) 클래스 테스트 : 캡슐화된 클래스나 객체를 검사하는 것. 구조적 기법에서 단위 테스트와 같은 개념. 

 2) 통합 테스트 : 여러 객체들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사.

                          - 스레드 기반 테스트 : 각각의 스레드가 통합되고 (= 클래스들을 통합한 후) 개별적으로 테스트 됨. 

                          - 사용 기반 테스트 : 독립 클래스를 테스트 한 후 독립 클래스를 사용하는 종속 클래스 테스트.

 3) 확인 테스트 : 사용자 요구사항에 대한 만족 여부 검사.

 4) 시스템 테스트 : 모든 요소들이 적합하게 통합되고 올바른 기능을 수행하는지 검사.






Section04. 아키텍처 스타일

- 아키텍처 스타일 : 개발자가 아닌 다른 사람이 유지보수하면서 생기는 어려움을 해결하기 위해

                             신뢰있는 기관에서 검증된 보편적인 설계 방법의 양식들 

- 아키텍처 모델 : 아키텍처 스타일에 있는 여러 설계 방식들 , = 애플리케이션 개발 모델



1) IEEE 1471 

소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 요소와 내용들, 이들간의 관계를 규정하고 있는 국제 표준. 

ANSI / IEEE 1471-2000의 약어. 

특징 : 표준화, 중립성, 유연성, 의사소통



2) 저장소 구조 (Repository Architecture)

중앙자료구조와 독립된 컴포넌트로 구성된 아키텍처. 큰 데이터 공유 및 이동에 적합. 

컴포넌트 간 통신 X

   + ) 큰 데이터 저장에 효율적 / 컴포넌트 추가, 삭제에 용이 / 데이터 관리 용이, 보안 굳 (중앙 집중화 때문)

   - ) 저장소 오류 -> 시스템 전체 문제 발생 / 데이터 분산이 어려움



3) MVC 구조 (Model /View / Controller Architecture)

상호작용 애플리케이션을 모델, 뷰, 컨트롤러의 세 개의 컴포넌트로 구분하는 아키텍처.

UI나 비즈니스로직들을 서로 분리하여 개발하는 방법

   모델 ) 애플리케이션의 핵심 기능을 포함, 상태 변화 시 뷰나 컨트롤러에 전달

   뷰 ) 정보 표시 관리, 모델로부터 정보 수신

   컨트롤러 ) 사용자로부터 입력받아 모델과 뷰에게 명령 전달.  


  + ) 동일한 모델에 다양한 뷰 제공 / 효율적인 모듈화 / UX에 대한 요구사항 적용시키는데 용이

  - )  간단한 애플리케이션에 부적합 / 모델이 자주 변경되는 경우 부적합


4) 클라이언트 / 서버 구조 

클라이언트와 서버로 나뉘는 아키텍처.

 (클라이언트 : 사용자로부터 입력받고 서버에 요청 

 (서버 : 수신된 요청을 수행, 데이터의 일관성 유지


하나의 서버에 다수의 클라이언트가 접속사는 일대다 관계로 구성. 

서버는 하나의 중앙 서버 or 분산된 여러개의 서버


새로운 서버의 추가 및 업글 용이

데이터 관리 용이, 보안 굳 (데이터가 서버에 집중되어 있기 때문)

서버에 트래픽과 데이터 집중 -> 처리비용 급증할 수 있음


5) 계층 구조 (Layered Architecture)

계층적으로 조직화가 가능한 애플리케이션에 적합한 아키텍처.


ex) OSI 7계층 !!!!!!!


각 계층이 특정 측면만을 전문적으로 다루기 때문에 응집력있는 설계가 가능

상위계층은 하위계층의 서비스 제공자, 하위계층은 상위계층의 클라이언트의 입장

복잡한 문제를 순차적으로 분할 구현

인접계층사이에서만 요청과 응답이 이루어짐 -> 원할한 변경 수행

구축 시 레이어의 적절한 개수나 규모를 결정짓는데 어렵다.



6) 파이프 필터 구조 (Pipes and Filter Architecture)

프로세싱을 위한 시스템이 각 필터에 캡슐화되어 있음. 데이터는 인접 필터 사이의 파이프를 통해 전달.

데이터의 흐름을 점진적으로 처리하는 시스템을 위한 아키텍처.


각 필터들은 상호 독립적. 서로의 정보를 알 수 없다. 


  + ) 설계자가 쉽게 사용 가능 및 쉬운 이해 / 새로운 필터 추가/ 통합 가능 / 효율적인 동시수행 / 재사용성 굳 / 응답성이나 데드락 지원

  - )  상태정보 공유의 어려움 /  각 필터간 공통된 특성이 적음 -> 전송받은 데이터를 다시 분석 및 해부하는 과정(파싱 parsing)이 필요할 때가 있음.








* 구조적기법

프로시저에 근간을 두고 하나의 커다란 작업을 여러개의 작은 작업으로 분할하고, 분할된 각각의 소작업을 수행하는 모듈을 작성한 다음 이들을 한 곳에 모아 큰 작업을 수행하는 하나의 완벽한 프로그램으로 작성하는 기법... 이라고 책에 나와 있는데 문장이 길어서 뭔말인지 모를뻔했다.

내 해석 : 큰 작업을 작은 기능들로 나눠 이를 수행할 수 있는 모듈을 작성한다. 이 모듈들을 한 곳에 모아서 작업 -> 큰 작업 수행 !



구조적기법에서....       프로그램 = 데이터 + 함수

객체지향기법에서....    프로그램 = 객체 + 객체   ( 객체 = 데이터 + 함수 )