IT/Architecture4 SOLID Principle SRP (Single Responsibility Principle)단일 책임 원칙은 쉽게 접할 수 있는 원칙이다.그렇지만 반대로 쉽게 접할 수 있다고 해서 쉽게 적용 할 수 있는 부분도 아니다. 그 이유는 바로 "책임" 이라는 의미가 엄청 모호하다는 것이다. 상황, 시점 등등에 따라 사람이든 다른 무엇이든 해야하는 것이 다르기 때문이다.그렇다면 소프트웨어 설계 관점에서 책임은 무엇일까. 고민해보면 역시 소프트웨어 요구사항을 생각할 수 밖에 없는 것 같다.즉, 소프트웨어 자체가 요구 사항에 기반하여 객체, 메소드가 만들어 지기 때문에 시나리오를 책정하고 그에 따라 구분되는 각 구성 요소의 역할들이 "책임" 이지 않나 싶다. 하지만 SRP의 더 큰 문제라 할 수 있는 지점은 나름대로 책임을 구분하여 분리하였.. 2019. 11. 17. Software Requirement - Part 2 Functional Requirement Vs Non-Functional Requirement Functional Requirement소프트웨어는 동작을 위해서는 Input, Behavior, Output와 같은 3가지 구성이 필수적이다. (코드를 작성할 때 항상 Input, Output 그리고 내부 동작한 로직인 Behavior를 생각하는 것처럼) 때문에 "기능적 요구사항" 은 간단히 소프트웨어를 동작시키기 위한 필수 요소를 정의하는 것이다. 간단히 예를 살펴보면,- 고객들이 산 물품에 대해 기록해야 한다.- 배경화면은 RGB 코드의 0x000FF이어야 한다. 등등과 같이 해당 소프트웨어에서 동작시켜야 하는 필수 요구사항이다. Non-Functional Requirement기능적 요구사항과 달리 소프트.. 2019. 10. 27. Software Requirement - Part 1 Software Requirement에 대해 차근차근이 알아보려고 한다. (공부할겸..) 프로젝트를 시작할 때, 가장 중요한 것은 "무엇을 만드냐" 이다. 물론 토이 프로젝트로서 재미삼아 만들어 볼 순 있지만 그건 개인에 한정된 부분인 것이고 회사로 넘어가게 되면 프로젝트 하나하나가 큰 시간과 비용을 소모하는 일이기에 프로젝트를 명세하고 진행하는 것이 중요하다.때문에 무엇을 만들어야하는지 명세하기 위해 Requirement 즉, 요구 사항을 수집하고 정의하는 것이 필수적이다.위 그림을 보면 프로젝트 요구사항을 피라미드 형태로 구분되어있다. 즉, Top-Down 형태로 아래로 내려갈수록 좀 더 세부적인 요구사항을 정의하게 된다. (잠깐, 위 그림은 Business, User, System 3가지로 구분되어.. 2019. 10. 20. 기본 소프트웨어 시스템 설계 관점 스터디를 위한 자료로 "데이터 중심 애플리케이션 설계" 책을 읽고 정리한 것이다. Q. 시스템(현재 서비스 되고 있는)에서 가장 크게 부하를 주는 요소는 무엇일까?Q. 소프트웨어의 3가지 요소(신뢰성, 확장성, 유지보수성)을 고려하고 있는가? (고려 했는가?)Q. 내부 시스템 요소(데이터베이스 등)를 잘 이해하고 사용하고 있는가? 시스템은 기술 숙련도, 조직 구성과 같은 외부적인 요인과 시스템 간의 의존성, 응답 시간과 같은 내부적인 요인들이 설계에 많은 영향을 끼친다. (현실은 항상 Clear하지 않으므로)그러나 이런 상황에서도 시스템은 항상 신뢰성, 확장성, 유지보수성에 대한 기준을 가지고 고려되어야 한다. (그렇게 하려고 최소한 노력해야 한다.)때문에 소프트웨어 시스템에서 중요하게 여기는 3가지 관.. 2019. 6. 24. 이전 1 다음
