Jan 4, 2018 - POP_part10

사상 - 프로그래밍 이데올로기

아키텍처 기본 기법

변경 용이성

소프트웨어에 수명은 의외로 길다. 그래서 변경 용이성을 해야 된다.

  • 보수성 - 오류가 발생한 코드 수정이 용이
  • 확장성 - 신규 기능 추가, 모듈 교체, 모듈의 제거 작업의 용이함
  • 재구축 - 모듈의 구현에는 영향을 미치지 않고 유연하게 배치할수있는 구조
  • 이식성 - 하드웨어 종속성을 고려하면서 소프트웨어를 설계할 이유가 있다.

소프트웨어 에이징

소프트웨어도 나이를 먹는다 이유는 여러가지이다 노후도를 늦출수 있는 방법도 있다 잘생각해서 아키텍쳐를 구현해야 된다.

참조


Jan 3, 2018 - POP_part9

사상 - 프로그래밍 이데올로기

아키텍처 기본 기법

충족성 완전성 프리미티브성

  • 충족성 - 추상이 그것을 전하기 충분한지(remove가 있는데 add가 없으면 불충분)
  • 완전성 - 추상이 모든 특성을 가지고 있는지(콜렉션인데 size 구하는게 없으면 안됨)
  • 프리미티브성 - 추상이 순수한지 아닌지(add가 있는데 add10은 필요 없다.)

정책과 구현의 분리

  • 정책 모듈 - 해당 소프트웨어 전체에 종속되는 비지니스 로직이나 그 밖의 모듈에 대한 파라미터를 선택하는부분
  • 구현 모듈 - 해당 소프트웨어 전체에 종속되지 않는 독립된 로직

구현은 안정적이지만 정책은 불안정맨날 바뀜

참조


Jan 3, 2018 - POP_part8

사상 - 프로그래밍 이데올로기

아키텍처 기본 기법

인터페이스와 구현의 분리

  • 인터페이스 - 기능 정의 및 모듈 사용 방법 정의(?)
  • 구현 - 실제 기능을 실현하는 코드

클라이언트는 인터페이스만 알면 되서 기능이 바껴도 코드를 수정할일이 없다. ‘구현이 아닌 인터페이스에 맞춰 프로그래밍 하라’

참조의 단일성

모듈의 요소에 관한 선언과 정의는 1회로 제한한다.

참조투과성

  • 호출결과가 파라미터에만 종속된다.
  • 호출이 다른 기능의 동작에 영향을 주지 않는다.

나는 call by reference를 활용해 코딩한적이 많은데 고민을 해봐야 겠다.

분할정복

커다란 문제는 작게 나눈다.

  • 전체를 설계할때 독립해서 설계할수 있는 부분을 나눈다음 착수한다.
  • 책임과 책무라는 관점에서 모듈을 분할
  • 알고리즘을 설계할때 병합 정렬처럼 상향식으로 분할하고 나서 문제를 해결할 수 없는지 검토
  • 대량의 데이터를 처리하는 설계를 할때 MapReduce 처럼 계삭을 작은 단위로 분할 해서 분산 처리 할수없는지 검토해야됨

아키텍쳐의 비기능 요구사항

  • 변경 용이성
  • 상호 운영성
  • 효율성
  • 신뢰성
  • 테스트 용이성
  • 재사용성

비기능 요구사항은 배포후에 큰 영향 개발 초기 부터 고려되야 됨 아키텍쳐 설계시에 고려해야 하는 요소임 기능테스트와 마찬가지로 비기능 테스트도 중요함 품질 측정기준을 정한후 구체적으로 설정하여테스트 해야됨

보안 비기능 요구사항

정보 보안의 3대 요소

  • 기밀성 - 허가되지 않은 사람이 사용하지 못하게 하는것
  • 무결성 - 정보 조작이 되지 않도록 하는것
  • 가용성 - 중요 정보를 백업하거나 이중화해서 가용성을 확보한다.

참조