Software Architect (25) 썸네일형 리스트형 [Software Architect] GRASP GRASP란 General Responsibility Assignment Software Patterns Craig Larman's 9 principles Object-Oriented 디자인의 핵심은 각 객체에 책임을 부여하는 것 책임을 부여하는 원칙을 말하고 있는 패턴 1. Information Expert 책임을 수행할 수 있는 데이터를 가지고 있는 객체에 책임을 부여하는 것 (객체는 데이터와 처리 로직이 함께 묶이는 것) 한 가지 객체에 너무 많은 Responsibility를 할당하는 것은 복잡도를 향상시켜 유지보수에 좋지 않다. Responsibility를 할당할 때에는 설계 모델에서 적합한 클래스를 탐색, 없을 경우 도메인 모델에서 적절한 도메인에서 찾아 할당한다. 정보은닉을 통해서 자신의 데이.. [Software Architecture] SOLID Reference : https://dev-momo.tistory.com/entry/SOLID-%EC%9B%90%EC%B9%99 SOLID 원칙 프로그래밍 설계를 하다보면 객체지향 5대원칙 또는 SOLID 원칙이란 단어를 들어본 적이 있을 것이다. 당시에 구글링을 하여 찾아보았지만 프로그래밍 내공이 부족하여 잘 이해가 되지 않았다. dev-momo.tistory.com 객체 지향 5대 원칙이란 SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙), LSP(리스코프 치환 원칙), DIP(의존 역전 원칙), ISP(인터페이스 분리 원칙)을 말하며, 앞자를 따서 SOILD 원칙이라고 부른다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 소프트웨어를 만드는데 이 원칙들을 적용할 수 있다. 1. Single.. [Software Architecture] Pattern 에 대해서 패턴 구현, 설계하는 도구 (업계에서 통용되는 언어) 패턴은 Interface + Concrete class 형태로 구성되어 있음 이런 패턴들이 여러가지가 있어 -> 생성시 사용되면 Factory pattern 등 여러개의 패턴이 뭉쳐서 움직인다 팀 내 의사 소통의 수단이 되기 위해선, 팀원들의 이해가 필요한다 패턴의 남용 리소스 제약이 심한 시스템에 유연성 추가하기? -> 성능상에 문제가 발생하는 경우 패턴의 Side-effect가 굉장히 크기 때문에 이에 대한 부분을 확인을 해야 함 추천 알기쉬운 디자인 패턴 Head First Design Pattern Java 언어로 배우는 디자인 패턴 입문 POSA 1 거대한 구조를 잡을 때 쓰는 패턴 Layer, Pipe & Filter, Broker, Mas.. [Software Architecture] 아키텍처 설계 품질속성 이해 SW아키텍처가 만족시키고자 하는 품질 요구사항 시스템 품질속성 비즈니스 품질속성 시장적시성 (Time to Market) - 빠르게 개발하는 것 비용과 이익 (Cost and benefit) 시스템의 프로젝트 생명주기 - 정책적으로 SW를 어떻게 할 것인지 - 요금정책 (기능추가, Update 추가할때마다 사용료 받을지) 목표시장 (Targeted market) 신규발매일정 노후 시스템과의 통합 아키텍처 품질속성 실무에서의 핵심 비지니스 적인 속성을 얼마나 만족시켜 주느냐? 비기능적 품질속성, 비기능적 요구사항으로 도출됨 -> 여기에 집중 해야 함 개발업무에서 중요한 부분 시스템 품질 속성 QA 시나리오 (품질속성 시나리오) 요구사항을 명세 (개발자가 이해하기 쉽게 쓰는 것 -> 의사소통 .. [Software Architecture] Requirement Engineering - 2 Use Case Analysis 개요 A means for capturing the desired behavior for the system under development Communication 방법 모든 요구사항이 도출되었는지 확인할 수 있는 방법 Benefit 이해하기/읽기 쉬움 Customer와 합의 이루는데 도움 구성 (Use Case = Use Case Diagram + Texture) Actor 같은 특성을 모아서 표현 (Sam, Ivan -> Student) 역할이 다르면 쪼개기도 함 시스템에 직접 interface 하는 개체가 Actor가 될 수 있음 - use the system - get information from this system - provide information to.. [Software Architecture] Requirement Engineering - 1 Requirement Engineering 개요 System services Constraints Requirement = 시스템 서비스(System service) + 제약사항 (Constraint) - System service = Functional requirements - Constraint = Non-Functional requirements RE process Development process에 따라서 빈도/시점 등은 달라질 수 있음 ex) - Waterfall : 초반에 가능한 많은 Requirement를 정의 - Incremental : 초반에 가능한 많은 Requirement 정의 후 개발은 쪼개서 진행 (Release 1,2,3 등) - Spiral : risk analysis, r.. [Software Architecture] SA Framework 개요 Software Architecture Framework - Based on IEEE 1471-2000, IEEE (2000) Viewpoint Models - ISO RM-ODP - ISO(1994) - Siemens Four View Model - Soni, D. et al (1995) - 4 + 1 View Model - Kruchten, P. (1997) - SEI View Model, Clements, P. et al. (2002b) IEEE 1471 Framework 아키텍처는 유연하고 확장성을 가져야 하며 이러한 아키텍처를 개발하기 위해서 아키텍처 프레임워크가 필요 중요성 - 관련된 용어와 개념을 통일 - 정해진 모델링 언어, 특정 방법론을 제시하지 않기 때문에 기술적 중립성을 가지고 .. [Software Architecture] Architecture Decisions 개요 시스템의 비기능적 특성에 영향을 준다 각 아키텍처 결정은 몇 가지 잠재적 솔루션이 존재 의사결정 결과에 대한 디자인 근거를 제공 - 아키텍처 결정에서 다루는 품질 속성 중 하나 이상을 참조하고 - 디자인 및 option 선택에 대한 "이유" 질문에 대한 답을 하므로써 디자인 근거를 제공함 아키텍처 결정은 SW 시스템 전체 또는 이러한 시스템의 핵심 구성 요오 중 하나 이상과 관련됨 Decision Management Step First Step : Decision Identification (결정 식별) 결정을 내리기 전에 결정의 필요성을 분명히 해야 함 Architectural Decision이 얼마나 긴급하고 얼마나 중요한가? 지금 만들어야 하나 아니면 구축중인 요구사항 및 시스템에 대한 정보가.. 이전 1 2 3 4 다음
