달력

12

« 2019/12 »

  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
  •  


 

 

실행 방식에 따른 분류

구분

설명

명령형 언어

·       컴퓨터에 저장된 명령어들이 순차적으로 실행되는 프로그래밍 방식입니다.

·       FORTRAN, COBOL, PASCAL, C 등이 명령형 언어에 속합니다.

함수형 언어

·       수학적 수식과 같은 함수들로 프로그램을 구성하여 호출하는 방식입니다.

·       LISP 등의 프로그래밍 언어가 함수형 언어에 속합니다.

논리형 언어

·       규칙에 대한 활성화 조건이 만족되면 연관된 규칙이 실행되는 구조로, 추론과 관계 규칙에 의해 원하는 결과를 얻어 내는 방식입니다.

·       PROLOG 등이 논리형 언어에 속합니다.

객체 지향 언어

·       객체 간의 메시지 통신을 이용하여 프로그래밍 하는 방식입니다.

·       JAVA C++ 등이 객체 지향 언어에 속합니다.

 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

프로그래밍 언어의 발전

·       프로그래밍 언어는 1940년대 컴퓨터의 발전과 함께 발전하였습니다.

·       세계 최초의 프로그램은 내장 방식의 프로그램으로, 이후에 현재까지 지속적으로 발전해오고 있습니다.

·       프로그래밍 언어는 컴퓨터 시스템의 역사와 함께하고 있으며 프로그래밍 언어가 개발된 시대적인 패러다임에 따라 유사한 특성을 가지고 있습니다.

 

년도별 언어

설명

이전

·       기계어

·       진공관

·       군사용, 연구용

1950년대

·       Assembly, FORTRAN, LISP 개발

·       트렌지스터

·       프로그래밍 언어 발전의 이정표가

·       상업용

1960년대

·       과학기술용으로 개발된 FORTRAN 더욱 발전시킨 고급 언어와 사무처리용 고급 언어 출현

·       대표적인 사무처리용 언어 COBOL, PL/I, BASIC

·       반도체

·       메인프레임, 서버

1970년대

·       PASCAL, C, SMALLTALK, PROLOG

·       반도체

·       PC

1980년대

·       단말 시스템을 이용한 분산 처리 개념이 확산

·       BASIC 언어 등장 (학생들과 컴퓨터 초보자에게 적합한 교육용 언어가 요구)

·       ADA, C++

1990년대

·       1990년대에는 객체 지향 언어가 본격적으로 등장

·       RUBY, JAVA, Javascript, C#, Python 등의 객체 지향 언어 등장

2000년대 이후

·       파워빌더, 델파이, 각종 쿼리 전용 언어 소위 4세대라 불리는 언어 등장

·       소프트웨어 컴포넌트 기술 발전

·       객체 지향 기술과 웹의 결합을 통해 다양한 정보를 제공하는 기법도 발전

최근

·       5세대 언어라 불리는 인공지능 기능을 이용해 자연 언어로 직접 처리하는 기법에 대한 연구가 진행되고 있습니다.

 

 

'Development > Software Engineering' 카테고리의 다른 글

1단계:성능 및 용량산정의 적정성  (0) 2019.06.04
실행 방식에 따른 분류  (0) 2019.05.31
프로그래밍 언어의 발전  (0) 2019.05.29
Command 패턴  (0) 2019.05.24
Adapter Pattern(적응자 패턴; 어댑터 패턴)  (0) 2019.05.21
Design Patterns  (0) 2019.05.20
Posted by codedragon codedragon

댓글을 달아 주세요


 

 

Command 패턴

·         명령 패턴 커맨드 패턴

·         요청을 객체로 캡슐화하여 서로 다른 사용자의 매개 변수화, 요청 저장 혹은 로깅, 연산의 취소를 지원하게 만듭니다.

·         명령을 클래스로 표현하는 구조, 요청을 객체의 형태로 캡슐화하는 디자인 패턴ㅇ비니다.

·         여러가지 요청(Command) 들에 대해 이를 처리해야 하는 클라이언트의 부담을 줄이고 추가/삭제를 용이하게 하기 위해 요청과 요청을 처리할 객체를 중계하기 위한 클래스 상속구조

·         Command 클래스는 요청을 처리할 객체를 내부적으로 미리 저장관리하고 요청이 들어오면 요청을 처리할 객체의 멤버 함수를 불러주는 역할

 

·         미리 map<string, ICommand*>  같이 명령문자열과실제 이를 처리할 클래스(ICommand인터페이스 상속받음) 생성관리해야 한다

·         클라이언트는 명령이 들어올 경우 명령을 자동 연결 처리할 클래스에게 바로 위임시킬 있다.

 

 

 

http://bit.ly/2G7HGQE

https://en.wikipedia.org/wiki/Command_pattern

http://wiki.c2.com/?CommandPattern

http://bit.ly/2GdszF8


 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

Adapter Pattern

·         적응자 패턴 어댑터 패턴

·         Wrapper Pattern 랩퍼 패턴

·         클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴

·         호환성이 없는 인터페이스 때문에 함께 동작할 없는 클래스들이 함께 작동하도록 해주는 패턴

·         기존 클래스 상속구조와 틀린 인터페이스를 가진 클래스가 신규 추가될 경우 클래스를 기존 상속에 묶기 위해 Adapter 클래스로 추가된 클래스를 Wrapping 하는 방법입니다.

·         기존 클래스를 재사용하려고 하나 인터페이스가 원하는 것과 동일하지 않을 사용합니다.

·         클라이언트는 새로 추가된 클래스가 기존과 다른 인터페이스를 가지고 있더라도 Adapter  인해기존 클래스와 동일한 인터페이스를 통해 제어 가능합니다.

·         Adapter 패턴에는 객체를 참조하는 방식인 Object Adapter  다중 상속을 통한 방법인 Class Adapter  습니다.

 

 

http://bit.ly/2IfOi31

http://bit.ly/2Z8EaxX

https://en.wikipedia.org/wiki/Adapter_pattern

http://wiki.c2.com/?AdapterPattern

 

 


 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

Design Patterns

Software Design Pattern들과 Sample Code 확인할 있습니다.

 

https://sourcemaking.com/design_patterns


 

 

 


 

 

페이지하단으로 이동하면 해당 소프트웨어 디자인 패턴의 샘플 코드를 확인할 있습니다.


 

 


 


Posted by codedragon codedragon

댓글을 달아 주세요



 

 

데이터 아키텍처(Data Architecture)

·         최상위의 단계에서부터 데이터베이스 단계까지 데이터에 관한 모든 구조를 통합하여 연계시킨 아키텍처입니다.

·         프로젝트 전체의 데이터베이스, 데이터 구조를 도식화

·         기능, 프로세스, 애플리케이션에 활용될 핵심 데이터

·         정보를 명확히 정의

·         데이터의 주제 영역, 개념 모델을 정의

·         데이터 통합 분산 방안을 정의

·         데이터 표준과 설계 원칙 정의

 

 

 

Data Architecture Reference Model 도식도

데이터 기반으로 시스템의 관계를 보여줄 데이터를 어디에 저장하고 어떤 역할을 하는 데이터를 어디에 위치시킬지를 기술하게됩니다.


 

http://bit.ly/2IuH8Hs

http://bit.ly/2P5mLBL

 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

2단계:시스템 상호 운용성

·       상호 운용성(interoperability)이란 다른 목적을 지닌 2 이상 시스템들이 상호 정보 서비스를 교환하면서 효과적으로 운용될 있는 시스템의 능력을 의미한다(한국전산원 2004).

·       요구사항중에서 목표 시스템이 조직 내외 시스템과의 연동을 요구하는 경우, 상호 운용이 가능한지 여부를 판단해야 한다.

 

 

상호 운용성(interoperability)

상호 운용성은 시스템 또는 제품이, 고객 측의 특별한 노력 없이 다른 시스템이나 제품과 함께 동작하기 위한 능력입니다.

 

http://www.terms.co.kr/interoperability.htm

http://bit.ly/2Vg6VtC

https://en.wikipedia.org/wiki/Interoperability

 

 

 

 

 

 

 

 

검토대상 산출물

·       제안요청서 / 제안서 / 계약서 / 사업수행계획서

·       사용자 요구사항 정의서 / 사용자 요구사항 추적서

·       아키텍처 분석 설계서(추후 도출 명세서)

 

 

 

 

 

 

 

시스템 유연성 확인 절차

시스템의 확장/ 변경/ 교체 응용시스템이 변경되지 않도록 유연성을 고려하여 요구사항이 도출되었는지 검토

·       제안요청서, 제안서, 계약서, 사업수행계획서 회의록에 명시된 시스템 유연성에 관련된 요구사항 충분히 도출

·       요구사항 정의서에 반영되어 있으며 추적관리가 되는지 검토

 

·       제안요청서, 제안서, 계약서, 사업수행계획서 회의록 등을 검토하여 하드웨어의 추가, 변경, 교체 등이 발생 경우 응용 시스템에 미치는 영향을 최소화하도록 요구사항이 도출되어 요구사항 정의서에 반영되어 있으며 추적관리가 되는지 검토

 

 

 

하드웨어 패키지가 특정 공급자에 종속적이지 않고 독립적으로 시스템을 구성할 있도록 요구사항이 도출되었는지 검토

 

·       요구사항 정의서 아키텍처 설계서에 상호 운용성을 위반하는 요소가 포함되었는지 검토

·       특정 하드웨어 패키지가 공급자에 종속적인 구성으로 시스템의 확장, 변경 교체 유연성을 해치는 요소 포함되었는지 검토

 

 

 

기타 검토사항

·       제품공급자가 제공하는 제품사양서, 설명서 등의 검토를 통해서 프로젝트에 적용된 기술 가이드라인을 수용하는지 검토할 있음

·       특별한 사유에 의해 공급자가 유일 하드웨어 또는 패키지를 선정할 경우 선택 사유가 객관적으로 타당성 있는지 검토, 상호 운용성의 준수 제품 공급자의 지속적인 지원 가능성 검토

·       업무 특성상 유일한 기능 또는 성능을 제공하는 제품을 선정하여야 하는 경우 상호 운용성의 준수 여부와 제품공급자가 지속적으로 유지보수 업그레이드 지원할 있는지 확인

·       도입되는 제품은 특정 벤더에 종속되지 않는 표준을 준수할 필요

 

 

 

 

 

 

시스템 상호 운용성 검토사항

·       시스템의 유연성 측면에서 요구사항이 충분히 도출되었는지 확인

·       서로 다른 시스템간 상호 정보 서비스 교환 가능성 검토

·       제안요청서, 제안서 등에 명시된 시스템 유연성에 관한 요구사항이 적정하게 도출되었는지 확인하는 것이 목적

·       시스템의 확장, 변경, 교체 시스템 구성 환경의 변화에 대하여 응용시스템이 유연하게 적응할 있는지 검토

·       하드웨어 패키지의 공급자에 대한 종속성을 최소화하여 환경 변화에 신속히 대응할 있는지 검토

 

 

 




Posted by codedragon codedragon

댓글을 달아 주세요


 

 

 

기술 환경 정의 자료 수집

·         자료 존재 유무 파악

·         자료 조사

·         조사 자료 분석

 

 

 

 

 

자료 존재 유무 파악

·         수집할 자료의 목록 정해야 합니다.

·         현행 시스템 담당자가 제시한 자료와 면담 기록에 필요 자료의 존재 여부 파악합니다.

 

 

 

[온라인 트랜잭션 처리(OLTP: OnLine Transaction Processing) 위한 기초 자료 조사 항목]

항목

설명

시스템 구축 형태

단독 시스템(Single System), 고가용성 시스템(HA System), 병렬 구성 여부

사용자

전체 사용자 , 동시 사용자 비율, 동시 사용자당 평균 질의 (1), 가동 시간 피크타임의 시간, 연간 사용자 증가율

트랜잭션

연간 트랜잭션 , 1 평균 트랜잭션 , 피크타임 트랜잭션 , 예상 연간 트랜잭션 증가율, 온라인 업무 검색, 갱신, 삽입, 삭제 레코드 크기 전체 건수

배치 업무

온라인 업무에 대한 배치 업무 비중, 배치 업무 구분, 대량 배치 기준으로 데이터 건수 길이

데이터베이스

데이터 크기(초기, 1 , 2 , 3 이후 데이터 증가율), 데이터 이미지, 사운드, 텍스트 파일의 비율, 인덱스 테이블의 초기 크기 3 크기, 가장 테이블의 레코드 건수, 데이터베이스 크기

데이터 백업

데이터 백업, 데이터 백업 서버의 운영 여부, 백업 장치의 접속 패턴, 백업

데이터의

운영 시간

운영 시간 7x24 여부

 

 

 

 

 

자료 조사

·         시스템 사용 현황 파악을 위하여 자료를 조사합니다.

·         기초 자료 조사 항목 중에서 현업 담당자 면담 기록에 존재하는 부분만 발췌하여 시스템 용량산정에 활용합니다.

·         만일 존재하지 않는 항목에는 기본 값을 적용합니다.

 

 

[WEB / WAS 위한 기초 자료 조사 항목]

항목

설명

시스템 용도

서비스 형태

페이지만 제공, 트랜잭션이 빈번하지 않은 서비스

(데이터베이스 연계), 트랜잭션이 빈번한 서비스(데이터베이스 연계)

시스템의 구성 형태

1계층, 2계층, 3계층

접속자

평균 접속자 (24시간 기준), 최고 접속자 (1시간), 연간 접속자 증가율

사용률

동시 사용자 , 사용자당 오퍼레이션 , 이미지 파일과 사운드 파일의 크기, 페이지 크기, 허용 응답 시간

업무 중요도 긴급도

중요도(상ㆍ중ㆍ하), 긴급도(상ㆍ중ㆍ하)

엔드 상호 작용 형태

읽기 전용(Read Only), 업데이트(Update), 온라인 트랜잭션 처리(OLTP)

SSL 사용 여부

안전한 통신이 필요한지 여부

 

 

 

 

 

조사 자료 분석

조사한 자료를 이용하여 운영체제, DBMS, 애플리케이션 서버 (WAS : Web Application Server) 등을 결정합니다.

 

 

[WEB / WAS 위한 기초 자료 조사 항목]

항목

설명

운영체제

·         시스템 구축 예산이 적은 경우( ex:2천만원이하 )에는 유닉스(UNIX) 도입하기 어려움

·         리눅스(Linux) 비용이 저렴하나 유지 관리를 위한 기술 인력을 보유하거나 별도의 계약을 체결해야

·         유닉스(UNIX) 안정적이고 대량의 처리가 가능하며 기술 지원이

·         용이하나 비용이 많이 소요됨

·         윈도우(Windows) 유지 관리 기술 인력 확보가 용이하고 유닉스(UNIX) 비해 상대적으로 비용이 저렴하나, 대부분의 대용량 처리 서버에 설치할 없음

DBMS

·         상용 DBMS 경우 안정적이며 확장성이 뛰어나고 기술 지원을 받기 용이하나 비용이 많이 소요됨

·         오픈 소스 DBMS 경우 비용이 저렴하나, 관련 기술을 자체적으로 확보할 필요가 있음

·         일반적으로 많이 사용되고 있는 DBMS(상용 또는 오픈 소스) 선택하면 관련 기술 인력 기술 자료를 확보하기 용이하고 문제 해결이 용이함

애플리케이션 서버

(WAS)

·         표준 규격을 준수하는 애플리케이션 서버(WAS) 경우 개발용과 운영용을 구분하여 사용할 있음

·         개발용은 가볍고 빠른 오픈 소스 애플리케이션 서버(WAS) 선택할 있음

·         상용 애플리케이션 서버(WAS) 경우에는 안정적이며, 대량 처리가 검증되어 있고 기술지원을 받기가 용이함

·         오픈 소스 애플리케이션 서버(WAS) 경우 일반적으로 널리 사용하는 애플리케이션 서버(WAS) 선택하는 것이 바람직함

 

 


Posted by codedragon codedragon

댓글을 달아 주세요


 

 

기능 현황

단위 업무 시스템이 현재 제공하고 있는 기능 기술한 것이다.

 

 

 

기능 현황 작성 고려 사항

단위 업무 시스템에서 제공하는 기능들을 주요 기능과 하부 기능으로 구분하여 계층형으로 표시해야 합니다.

 

 

 

 



Posted by codedragon codedragon

댓글을 달아 주세요



 

3단계:IT 시장 성숙도 트렌드 부합성

·       기술적 위험 분석

·       IT 시장 성숙도 및 트렌드 부합성 검토사항

 

 

 

 

기술적 위험 분석

·       요구사항을 만족시키기 위하여 적용한 기술의 복잡성, 검증 여부, 의존성 등에 대하여 위험 발생 가능성 영향도 파악

·       기술의 특성 고려하여 기술적 위험 분석

 

기술의 특성

내용

복잡성

기술의 안정성, 시장성, 개방성을 저해하는 모든 요소

하드웨어, 소프트웨어, 솔루션의 적용이 아키텍처와 불일치

검증여부

적용 기술에 대한 조직 무경험

외부 지원 불가능

의존성

특허 라이선스에 따른 문제

특정 업체 기술에 대한 의존

 

 

 

 

 

IT 시장 성숙도 및 트렌드 부합성 검토사항

·       시스템 구축 요구되는 영역별 정보 기술들의 시장 성숙도 발전 방향 파악

·       도출된 요구사항이 IT 시장 성숙도 트렌드에 부합하는지 판단

·       시장 성숙도가 낮거나 발전 방향에 부합되지 않는 기술들은 향후 이상 사용되지 않을 가능성이 높음

·       시스템의 유지보수가 어려운 상황 발생할 가능성이 높음

·       IT 관련자는 평소 IT 기술동향 스터디 꾸준히 수행하여야

 


Posted by codedragon codedragon

댓글을 달아 주세요