Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
En vedette (20)
Similaire à 분석과 설계
Similaire à 분석과 설계 (20)
분석과 설계
- 1. 분석과 설계
- 3. 1980’s • Indi Developer • 4kB ROM, 48kB RAM 3
- 5. 2000’s • Developer • Process Engineer • Enterprise System Software Architect • Bank • Trading • Insurance • Telecom • Retail • Manufacture 5
- 6. 2010’s • Startup • 두나무 창업자 • 키몬 : 키보드 기반 리워드 서비스 (개발 중) 6
- 7. Books 7
- 8. 1. 개요
- 9. 9
- 10. 우리가 하는 일 10
- 11. 실체와 표현 11
- 12. 모델 12/100
- 13. 모델 13/100
- 14. 모델 14
- 15. 모델 15
- 16. 모델 16
- 17. 모델 17 • Models are not right or wrong; they are more or less useful. – Martin Fowler, Analysis Pattern
- 18. 모델 • 시스템의 현재 모습, 목표 모습을 가시화한다. • 시스템의 다양한 측면을 이해하게 한다. • 시스템의 구조, 특징, 동작을 설명한다. • 구성요소 • 구성요소끼리 관계 • 구성요소가 동작하는 방식 18
- 19. 모델 • 대상 하드웨어 시스템 소프트웨어 (OS, Tool, Middleware, …) 어플리케이션 소프트웨어프로그래밍 언어 하드웨어 시스템 소프트웨어 (OS, Tool, Middleware, …) 어플리케이션 소프트웨어프로그래밍 언어 네트워크/인터페이스 19
- 20. 모델 • 일관성 : 한 모델은 시스템의 한 측면만 설명한다. • 균질성 : 구성요소들의 추상화 수준이 균질해야 한다. • 적절성 : 구성요소 사이 응집도는 높아야 하고 결합도는 낮아야 한다. • 좋은 모듈을 만드는 과정 20
- 21. 모델 • 의존 관계 최소화 • 한 모듈은 한가지 책임 • 최대한 감추기 • 한 번 맺은 계약은 바꾸지 않기 21
- 22. 네 가지만 기억하세요 어떤 공정을 따를 것인가? 어떤 방식으로 표현할 것인가? 어떤 규범을 따를 것인가? 비즈니스 시스템 방법론 언어/기법/ 패러다임 표준 어떤 원칙을 따를 것인가? 아키텍처 22
- 24. 방법론 • 구성요소 24 단계 구조 단계 반복 작업 작업 흐름 역할 활동 산출물 1 1..* 1 9 1 1..* 1 1..* 1 1..*1..* 1..* 나눈다 수행한다 참여한다 실현된다 구성된다 책임진다 갱신한다 1..* 1..* 1..* 1..* 수행한다 작업 구조
- 25. 방법론 • RUP 25
- 26. 방법 26
- 27. 요구사항 정의 분석과 설계 구현 테스트 배치 환경 단계 작업 단계 별 이정표 요구사항 베이스라인 아키텍처 베이스라인 동작하는 시스템 인도/인수 확인 P1 P2 P3 P4 방법 • 반복 기반 방법 27/100
- 29. 방법 • 요구사항 정의 29/100 산출물 요구사항 정의 단계 작업 요구사항 베이스라인 P1 P2 P3 P4 주요 용어정의 용어사전 수정/보완/추가 비기능 요구사항 정의 비기능 요구사항 수정/보완/추가 주요 요구사항 정의 주요 요구사항 수정/보완 신규 요구사항 정의 신규 요구사항 정의 주요 유스케이스 정의 주요 요구사항 수정/보완 신규 유스케이스 정의 신규 유스케이스 정의 용어 사전 비기능 요구사항 정의서 기능 요구사항 정의서 유스케이스 모델 산출물 동기화
- 30. 방법 • 분석과 설계 30/100 아키텍처 베이스라인 분석과 설계 아키텍처 문서 산출물 아키텍처 요구사항 분석 아키텍처 정의 아키텍처 유지 유스케이스 실현 모델 유스케이스 실현모델링 신규 유스케이스 실현 모델링 신규 유스케이스 실현 모델링 화면유형 정의 논리 모델 소프트웨어설계 추가 설계 산출물 동기화 설계 수정/보완 배치 모델 HW/NW 배치설계 설계 수정/보완 애플리케이션배치설계 외부 인터페이스 설계 추가 설계 설계 수정/보완 추가 설계 외부 인터페이스 모델 추가 설계 데이터 모델 논리데이터모델링 물리 데이터 모델링 설계 수정/보완
- 31. 방법 • 구현 31/100 동작하는 시스템 구현 산출물 애플리케이션 소스 코드 구현 모델 골격시스템 구현 프로토타입 구현 애플리케이션구현 고객 피드백 반영 수정 생 성 생 성 생 성 생 성 애플리케이션 데이터베이스 빌 드 빌 드 빌 드 빌 드 빌 드 빌 드 빌 드 빌 드 빌 드 생성 유지/관리 데이터이전
- 32. 방법 • 테스트 32/100 테스트 산출물 테스트 계획서 테스트 결과서 인수테스 트 계획 인수 테스트 수행 시스템 테스트 계획 통합 테스트 계획 단위테스트 수행 통합 테스트 수행 시스템 테스트 수행 통합 테스트 수행
- 33. 방법 • 배치 33/100 산출물 배치 인도/인수 확인 사용자 지침작성 시스템 시스템 배치 시스템 배치 사용자 지침 인수 확인서 시스템 배치 인 수 확 인
- 34. 방법 • 환경 34/100 환경 산출물 환경 정의서 기본 환경 정의 설계 환경 정의 테스트 환경 정의 개발 환경 정의 개발 지침 개발 지침작성 기본 환경 구축 설계 환경 구축 개발 환경 구축 테스트 환경 구축 운영 지침 운영 환경 정의 운영 환경 구축 운영지침작성
- 35. 방법 • 산출물 관계 35 구성요소 모델링 요구사항 정의비즈니스 모델링 요구 정의 시스템 비전 정의 목표 비즈니스 정의서 비즈니스 용어집 비기능 요구사항 정의 요구사항 명세 현행 비즈니스 분석 현행 비즈니스 분석서 목표 비즈니스 정의 용어정의 용어집 분석과 설계 외부 인터페이스 모델링 배치모델링 아키텍처 정의 아키텍처 문서 데이터모델링 데이터 모델 배치 모델 논리모델링 논리 모델 인터페이스 모델 구현 구현모델링 구현모델 모델 빌드 생성 빌드 테스트 테스트 전략 수립 테스트 수행 테스트 전략 테스트 계획 테스트 설계 테스트 결과 배치 사용자 교육 사용자 지침 최종제품 전달 제 품 인수 확인서 유스케이스 실현 모델링 유스케이스 실현 모델
- 37. 아키텍처 37 구성요소 분석과 설계 구성요소 행위에 대한 분석과 설계 정보에 대한 분석과 설계 요구사항 유스케이스 화면 정의 용어사전요구사항 정의서 상위 요구사항 정의서 도메인 모델 개념 모델 논리 데이터 모델 행위 실현 논리 모델 데이터 모델 유스케이스 실현 모델 구성요소 식별 -구성요소 정제 -행위배분 -실현에 참가 행위 실현 대상 정의 아키텍처 아키텍처 구성요소 정의 (레이어, 시스템, 어플리케이션, 컴포넌트, …) 구성요소 사이 의존관계 규칙 정의 주요 행위 패턴 식별 행위 패턴 별 실현 방법 제시 구현 소스 외부 인터페이스 모델 배치 모델 아키텍처 구현 원칙 정의 (구현 기술, 구현 원칙, 동작 메커니즘, …) 데이터 설정 빌드 시스템
- 38. 표현- 패러다임 • 알고리즘 중심 • 데이터 처리 절차 • 효율성이 중요 • 기계 관점에서 설계 : 시스템이 정보를 높은 효율로 처리하도록 설계 • ASM, C • 32GB RAM 시대 • 통제 가능성 • 인간 관점 • 인간이 세상을 이해하는 방식대로 시스템을 분석 설계 • 객체 중심 • C++, Java 38
- 39. 표현 - 언어 • 언어는 추상화 수준을 강제한다. • 발달한 언어일 수록 섬세한 추상화 수준을 제공한다. • ASM/C • 자유 • 객체지향 언어 • 추상화 수준 : 데이터와 행위 • 함수형 언어 • 추상화 수준 : 제어구조(반복, 추출, 선택, …) 39
- 40. 분석 vs 설계 40
- 41. 분석 vs 설계 41
- 42. 분석 vs 설계 • 분석 • 문제 • 업무 정책과 처리를 모델링 • 설계 • 해결 • 업무 정책과 처리를 기술을 적용하여 시스템으로 만들기 위한 모델링 • 참고 • http://www.omg.org/news/meetings/workshops/presentations/eai_2001/ tutorial_monday/tockey_tutorial/2-Analysis_vs_Design.pdf • http://www.jot.fm/issues/issue_2009_01/column7.pdf 42
- 43. 2. 도구
- 44. UML • Unified Modeling Language 44
- 45. UML • 다이어그램 45
- 48. 클래스 다이어그램 • 목표 • 시스템을 구성하는 개념을 찾아 클래스로 식별한다. • 개념들 사이 관계를 찾는다. • 클래스의 행위는 유스케이스 실현 모델링을 통해 식별한다. • 결합도가 높은 클래스는 패키지로 묶는다. • 작업 별 추상화 수준 • 분석/설계 단계 : 개념과 정보의 관계를 찾는다. • 구현 단계 : 구현에 필요한 구성요소가 추가된다. 적용하는 프레임워크, 구현 패턴에 따라 다른 구성요소가 추가된다. (Spring, EJB, Rails, Node, …) 48
- 49. 클래스 다이어그램 49
- 50. 클래스 다이어그램 50 • 예제 • 고객은 개인고객과 법인고객으로 분류된다. • 고객은 주문을 한다. • 주문은 결제와 물품을 포함한다. • 다양한 물품을 묶어서 주문할 수 있다. • 포인트, 신용카드, 상품권으로 결제할 수 있다.
- 51. 배치 다이어그램 • 목표 • 시스템 동작에 필요한 하드웨어, 네트워크, 미들웨어, OS, DBMS, 어플 리케이션의 구성을 정의한다. 51
- 52. 유스케이스 다이어그램 • 목표 • 시스템 경계를 찾는다. • 시스템과 외부 사이 모든 상호작용을 찾는다. 이 상호작용이 시스템이 제공하는 기능이다. • 시스템이 이 기능을 제공하기 위해 처리하는 정보와 처리 순서를 찾는다. • 형태 • 유스케이스 다이어그램 • 유스케이스 기술서 • 사용자 스토리 • 화면 설명서 • 인터페이스 설명서 52
- 53. 유스케이스 다이어그램 53
- 54. 액티비티 다이어그램 • 목표 • 업무 흐름을 정의한다. • 복잡한 논리의 흐름을 정의한다. • 구성요소 • Action • Node • Object • Swimlane • Other Activity 54
- 55. 액티비티 다이어그램 55
- 56. 액티비티 다이어그램 • 로그인 액티비티 • 사용자가 앱을 실행한다. • 사용자 등록을 수행한 기록이 있으면 로그인을 요구한다. • 사용자 등록을 수행한 기록이 없으면 등록을 요구한다. • 등록을 마치면 로그인을 요구한다. • 사용자가 SNS로 로그인을 요청한다. • 앱에서 SNS로 로그인에 성공하면 서버에 인증토큰을 보낸다. • 서버는 SNS에 인증토큰 유효성을 요청한다. • 인증 토큰이 유효하면 로그인을 완료한다. • 인증 토큰이 유효하지 않으면 다시 로그인을 요구한다. 56
- 57. 시퀀스 다이어그램 • 목표 • 유스케이스 실현 방법을 정의한다. • 누락/중복/잉여 구성요소를 찾는다. (정보) • 구성요소들이 주고 받는 메시지를 찾는다. (행위) • 분석 작업 • 바운더리, 컨트롤, 엔터티 클래스를 찾는다. • 설계 작업 • 구현 기술을 적용하여 실재 클래스를 찾는다. 57
- 58. 시퀀스 다이어그램 58
- 59. 참고 • 도구 • 종이 • 화이트보드 • Star UML • http://startuml.io • 자료 • http://staruml.sourceforge.net/docs/user-guide%28ko%29/toc.html • http://agilemodeling.com/essays/umlDiagrams.htm • http://se.ce.pusan.ac.kr/xe/?module=file&act=procFileDownload&file_sr l=19115&sid=584954dacd4351b6b394e5c71df86f01 59
- 60. 3. 기법
- 61. 패턴 61 반복해서 나타나는 비슷한 문제들 반복되는 비슷한 해결책들 패턴! 새로운 해결책들
- 62. 아키텍처 패턴 • 시스템 기본 구조를 정의하는 패턴 62
- 63. #01 우리 시스템 식별 • 수준 : 아키텍처 • 입력 : 제안요청서, 제안서, 비전 기술서, 상위 요구사항, 기존 시 스템 63
- 64. #01 우리 시스템 식별 • 사례 64 OASIS SWIFT Alliance Core Bank eGIFT ATM MIS
- 65. #02 정보 유형에 따른 계 식별 • 수준 : 아키텍처 • 업무 처리 트랜잭션, 정보 수집/분석 트랜잭션, 외부 연동 트랜잭 션 65 . . . . , , , . . , .
- 66. #02 정보 유형에 따른 분할 • 사례 66 OASIS DB Report RMI- IIOP SCOKET FILE
- 67. #03 트랜잭션 유형에 따른 시스템 식별 • 수준 : 아키텍처 67
- 68. #03 트랜잭션 유형에 따른 시스템 식별 • 사례 68 OASIS (OIS) ATM (OAS) (OXS) (OBS) (OOS) (OMS) DB EJB Channel EJB Channel Socket DB EJB Channel EJB Channel DB EJB Channel JMS (OXA) EJB Channel EAI Socket EAI FTP FTP ControlM eXit DB
- 69. #04 시스템 구성요소 식별 • 수준 : 아키텍처 69 애플리케이션 구현체 서브시스템파티션 1 1..* 1 1..*1 1..*
- 70. #04 시스템 구성요소 식별 • 수준 : 아키텍처 70 : : UI BC Data UIUI BCBC DataData M1 M2 M3 M5 M6 M4 M7 M8
- 71. #04 시스템 구성요소 식별 • 사례 71 (AFW) (BFW)
- 72. #05 비즈니스 프레임워크 식별 • 모든 업무에서 공통으로 처리하는 업무를 비즈니스 프레임워클 식별하고 재사용한다. 72 (BFW) FX
- 73. #06 핵심 업무 유형 파악 • 핵심 업무 유형을 파악하여 필요한 구성요소와 처리 절차를 정의 한다. 73 1. 2. 7. Term & Condition 8. 9. 10. 13. 14. 15. 16. 3. 4. 6. ( ) 11. 12. 5.
- 74. #07 구현 레이어 식별 74
- 75. #08 구현 구성 요소 정의 • 적용 프레임워크가 제시하는 방식에 따라 구현 구성 요소를 정의 한다. 75
- 76. 분석 패턴 • 업무 요구사항을 분석하는 과정에서 반복해서 발견되는 구조 • https://www.google.co.kr/search?q=martin+fowler+apsupp 76
- 77. #01 Party • 의도 • 개인과 조직이 같은 방식으로 정보를 처리한다. • 동기 • 개인과 조직은 층위가 다르다. • 개인과 조직이 공통으로 가져야 하는 항목들이 있다. (연락처 등) • 개인의 항목과 조직의 항목을 분리하면 복잡성이 증가한다. (회사 전체 연락처 등) • 해법 • 개인과 조직의 슈퍼타입인 Party를 만든다. 77
- 78. #02 Account • 의도 • 시스템이 다루는 돈을 처리한다. • 동기 • 돈을 처리하고 그 내역까지 알고 싶다. • 해법 • 내역을 합산한 결과인 최종 잔고(balance) 항목을 가지는 계정을 만든다. 78
- 79. #03 Transaction • 의도 • 돈이 움직인 경로를 추적한다. • 동기 • 복식 부기 장부를 기록하고 싶다. • 돈이 들고 난 결과를 남기고 싶다. • 해법 • 트랜잭션이 발생할 때마다 차변/대변 내역을 남기고 해당 계정을 갱신하 다. 79
- 80. 설계 원칙 80
- 81. #01 SRP Single Responsibility Principle 한 객체는 한 책임을 맡고 한 책임은 한 객체에 모인다. 낮은 결합도, 높은 응집도 81
- 82. #02 OCP Open Closed Principle 확장엔 열려있고 변경엔 닫혀있다. 새로운 요구사항이 발생 • 감춰진 구현은 자유롭게 재구성할 수 있어야 한다. (Open) • 공개된 인터페이스는 변하지 않아야 한다. (Close) Open은 지키기 쉽지만 Closed는 지키기 어렵다. 82
- 83. #02 OCP 왜 나쁜 설계인가? 다른 도형을 추가하면? public void drawAll(Shape[] shapes) { for (int i = 0; i < shapes.length; i++) { Shape shape = shapes[i]; if (shape.shapeType() == Shape.CIRCLE) { ((Circle)shape).drawCircle(); } else if (shape.shapeType() == Shape.SQUARE) { ((Square)shape).drawSquare(); } } } 83
- 84. #03 LSP Liscov Substitution Principle 서브 클래스는 슈퍼 클래스를 대체할 수 있어야 한다. 완벽한 is-a 관계가 되도록 상속 구조를 정의해야 한다. • 슈퍼 클래스의 행위를 서브 클래스가 거부하면 안 된다. • 서브 클래스가 슈퍼 클래스를 대신하기 위해 뭔가 더 필요하면 안 된다. 84
- 85. #04 ISP Interface Segregation Principle 특화된 인터페이스가 통합된 범용 인터페이스보다 낫다. 클라이언트에게 용도가 명확한 인터페이스를 제공해야 한다. 85
- 86. #05 DIP Dependency Inversion Principle 클라이언트는 구체 클래스가 아닌 인터페이스에 의존한다. 바람직한 방향으로 의존성을 재설정 Fr amewor k User l ogi n Fr amewor k I Logi n Aut hor i zer User Pr of i l e Aut hor i zer l ogi n User User Pr of i l e 86
- 87. 설계 패턴 87
- 88. 두 가지만 기억하세요 88
- 89. 4. 실습
Notes de l'éditeur
- 내용 고민 소마에 맞게 시스템 전체를 바라보는 관점을 많이 넣었다.
- 분석과 설계 수업을 왜 듣는가? 무엇을 얻고 싶은가? 분석과 설계는 왜 하는가? 무엇을 얻는가?
- 질문 : 현재 표현하고자하는 비즈니스는 무엇인가? 어떤 문제를 다루는가? 누구를 위한 비즈니스인가? 누구를 위한 시스템인가?
- 하루는 피카소가 기차를 타고 어딘가로 가고 있었다. 그런 경우에 흔히 일어나는 일이지만 옆 좌석의 신사와 얘기를 나누게 되었다. 그 승객은 자신과 대화를 나누고 있는 상대가 누군지 알고 나자 현대예술이 실재를 왜곡하고 있다면서 불평을 늘어놓기 시작했다. 그러자 피카소는 그에게 실재라는 것의 믿을 만한 본보기가 있다면 그것을 보고 싶다고 했다. 승객은 지갑 크기의 사진을 한 장 꺼내며 이렇게 말했다. "이거요! 진짜 사진이죠. 내 아내와 정말 똑같은 사진이오." 피카소는 그 사진을 여러 각도에서 주의 깊게 들여다보았다. 위에서도 보고, 아래로도 보고, 옆에서도 보고 나서 피카소는 말했다. "당신 부인은 끔찍하게 작군요. 게다가 납작하고요." 아무리 노력해도 실체를 있는 그대로 표현할 수 없다.
- 지구? 아니다. 지구라는 실체를 한 눈에 파악할 수 있도록 추상화하여 가시화한 모델이다. 추상화를 통해 대상을 단순화한다. 목적에 맞게 추상화 수준, 추상화 대상, 가시화 방식이 달라질 수 있다. A는 우주에서 찍은 사진으로 지구가 우주에서 실재로 어떻게 보이는지 설명한다. 땅, 바다, 구름과 같이 보이는 모든 것을 표현한다. B는 땅의 모양에 초점을 맞췄다. 위도와 경도를 표시하여 상대 위치를 파악하게 했다 복잡한 대상일 수록 한 번에 이해하기 어렵다. 다양한 각도, 다양한 층위에서 파악해야 한다. 해결하려는 문제가 클 수록, 다루는 비즈니스가 복잡할수록 다양한 모델이 필요하다. 추상화 대상과 수준에 따라 다양한 모델을 만들어야 한다.
- 모델을 만들려면 실체에 목적에 맞는 투영 방식을 적용해야 한다. 항로가 직선으로 표시되는 지도는 항해에 꼭 필요하다. 그래서 지구를 원기둥에 투영하는 메르카토르 도법을 통해 우리가 흔히 아는 세계지도를 만들었다. 이 지도는 자신의 목적에 부합하면서 어느 정도 실체인 지구를 설명한다.
- 무엇을 추상화하느냐에 따라 실체의 특정 측면만 강조하고 다른 부분은 왜곡된 모델을 만들 수도 있다. 이 지도는 인터넷 인구와 보급율을 크기와 색으로 표현한 모델이다. 각 나라의 실제 영토 면적이 상당히 왜곡되었다. 우리가 흔히 보는 세계지도인 메르카토르 도법 지도는 어떤가? 왜곡이 없을까?
- 메르카토르 도법은 극지방으로 갈 수록 실제보다 면적이 넓게 왜곡되는 단점이 있다. 메르카토르 도법에서 아프리카는 그린란드보다 작아 보이지만 실재 크기는 그린랜드의 14배로 미국, 인도, 유럽, 일본, 중국을 합친 것 만큼 넓다. 북반구에 몰려있는 서구가 실재보다 훨씬 크게 보여서 식민통치를 정당화하는 데 일조했다는 설도 있다. 모델이 자기 목적에 맞게 쓰이면 문제가 없지만 왜곡된 부분을 강조하여 다른 목적으로 쓰이면 문제가 된다.
- 이 두 모델은 같은 대상을 다른 관점에서 바라본 것이다. 다양한 관점은 좀 더 깊은 이해를 제공한다. 항공사진으로는 파악할 수 없는 지형의 고저를 다른 모델로 파악할 수 있다. 항공사진과 고저도는 다른 목적으로 만들었다. 전혀 다른 모습이지만 같은 대상을 설명한다.
- 과학 이론은 사실 모델이다. 제시한 모델이 자연현상을 잘 설명하면 유효한 모델이다. 유효성은 항상 특정 컨텍스트에서 판단해야 한다. 뉴튼 역학과 아인슈타인 역학, 어느 이론이 맞나? 물체가 빛에 가까운 속도로 움직이는 극한 상황에서 아인슈타인 역학이 뉴튼 역학을 밀어냈지만 뉴튼 역학은 대부분 자연현상을 잘 설명하기 때문에 여전히 유효하다. 아인슈타인 역학이 더 정확하니까 게임에 필요한 물리 엔진을 아인슈타인 역학을 기초로 만들어야 할까? 아니다. 보통 게임이라는 컨텍스트에서 뉴튼 역학은 훌륭하게 동작한다. 모델은 맞냐 틀리냐가 아니다. 유용하가 아닌가 이다.
- 시스템이 어떤 구성요소로 이루어졌는가. 구성요소들은 어떤 관계를 맺는가. 구성요소들은 어떻게 동작하는가. 시스템을 만들기 위한 모델의 목적이다.
- 어떤 언어, 어떤 패러다임을 적용하더라도 원칙은 변하지 않는다. 좋은 시스템은 좋은 모듈로 구성된다. 언어/패러다임은 좋은 모듈화를 이루는 바탕을 제시하고 강제하는 역할을 한다.
- 좋은 시스템을 만들 때 필요한 네 가지 기본기다.
- 방법론은 소프트웨어 시스템 개발 프로젝트의 관리 방법, 개발 방법, 환경 운영 방법에 대한 일반 가이드를 제공한다. 시간의 흐름에 따른 단계와 산출물의 활동에 따른 작업이 두 축이고 그 매트릭스 안에서 필요한 산출물을 만들어 내는 과정이 개발이다. 단계와 작업이 원활히 진행되도록 이끄는 일이 관리다. 관리와 개발이 편리하게 이루어지도록 환경을 갖춘다.
- 엔터프라이즈 시스템 개발 프로젝트에 적용하는 방법론은 매우 방대하고 복잡하다.
- 프로세스 엔지니어가 하는 일
- 논리뷰/구현뷰 : 논리모델, 데이터모델, 클래스/오브젝트/컴포넌트/상태도 등 프로세스뷰 : 유스케이스 실현 모델 배치뷰 : 배치 모델
- 아키텍처는 모든 제약 사항을 고려한 모듈화/추상화 원칙을 제시한다. 분석, 설계 작업에 제시할 원칙 모듈 선정 기준 의존성 원칙 유스케이스 유형 유스케이스 유형 별 실현 방법 구현 작업에 제시할 원칙 모듈 구성 요소 언어/프레임워크/미들웨어/OS/DBMS 환경에 최적화된 구현 방법
- HW 제약은 점차 통제 가능해졌다. Apple ][ 시대에는 비싼 16kB RAM 카드를 장착하는 해법만 존재했다. 요즘은 개인도 시스템에 맞게 다양한 수준으로 HW를 마련할 수 있다. 제일 큰 제약은 돈
- 개발 조직의 역량이 언어를 선택하는 데 가장 큰 제약 사항이다.
- 요구사항 한 가지 의미로만 해석되고 달성했는지 못 했는지 명확하게 알 수 있고 고객이 돈을 내고 기꺼이 쓰거나 없으면 안 된다고 여기고
- 구성요소(things) 모듈 상자, 타원 관계(relations) 상호작용 선 다이어그램(diagram) 관점 구성요소 + 관계
- http://www.agilemodeling.com/essays/umlDiagrams.htm Class : 타입, 클래스처럼 시스템의 고정된 모습을 모델링하다. Object : 특정 시점에 구성요소들의 인스턴스의 상태와 상호자용를 모델링한다. Package : 관련성 높은 구성요소들을 패키지라는 논리 컨테이너로 나누고 상호작용을 모델링한다. 패키지는 UML 1.x에서 단순한 구성요소였지만 UML 2.0에 새롭게 패키지 다이어그램이 정의되었다. Component : 인터페이스와 클래스로 구성된 복잡 구조를 모델링한다. 컴포넌트는 재사용 가능한 배포 단위를 표현한다. 클래스 다이어그램을 추상화한다. Composite Structure : 내부 상세에 초점을 맞춰 구조화된 클래스(structured class)를 구성하는 요소들의 구조와 외부의 다른 파트와 상호작용점을 표현한다. 따라서, 컴포넌트나 클래스 같은 구조화된 클래스(structured class)의 내부 구조를 표현할 때 많이 쓰인다. 구조화된 클래스가 특정한 행위를 할 때 같이 협력하는 파트들의 관계와 구성도 표현한다. UML 2.0에 새롭게 정의되었다. Deployment : 실행 시점에 시스템이 동작하는 구조를 모델링한다. 하드웨어, 네트워크, 미들웨어, 어플리케이션이 어떻게 배치되는 지 모델링한다.
- Use Case : 시스템이 외부와 어떻게 상호작용하는지 모델링한다. 시나리오 형태로 행위, 요구사항, 제약조건을 정의한다. State Machine : 객체가 조건에 따라 상태가 변하는 과정을 모델링한다. Activity : 복잡한 유스케이스 흐름, 유스케이스끼리 상호작용하는 방식, 복잡한 업무 논리, 업무 프로세스와 같이 객체 사이에서 일어나는 일련의 활동을 모델링한다. Sequence : 구성요소들이 어떤 메시지를 어떤 순서로 주고 받는지 모델링한다. 메시지에 초점을 맞춰 모델링한다. 커뮤니케이션 다이어그램과 상호변환된다. Communication : 시퀀스 다이어그램과 같지만 구성요소 인스턴스에 조첨을 맞춰 모델링한다. Interaction Overview : 액티비티 다이어그램과 시퀀스 다이어그램이 합쳐진 형태로 상위 수준에서 제어 흐름을 모델링한다. Timing : 시간에 따라 객체의 상태가 변하는 모습을 모델링한다.
- 시스템이 제공하는 기능을 찾는 일이기 때문에 최대한 유연하게 접근할 필요가 있다. 조직이 편하게 느끼는 방식으로 접근하는 것이 맞다.
- 소프트웨어 유형에 따라 다양한 아키텍처 패턴 존재한다. 기업 시스템 중심으로 설명한다.
- 구조를 정하는 것 까지 아키텍처 수준 파티션, 서브시스템 구성요소를 정의하는 일은 분석 레이어 구성요소를 정의하는 일은 설계 구현체에서 분석과 설계/업무와 기술이 만남. 구현체를 구현하는 일에는 구현 패턴 저용
- https://www.google.co.kr/search?q=martin+fowler+apsupp
- 북치기 박치기만 알면 비트박스를 잘할까? 북치기 박치기를 기본으로 연습하고 연습해야 저 정도 경지에 이른다. 북치기 박치기는 기본이다. 원래 만렙을 찍으면 기본이 다시 보이고 더 중요하게 여겨진다.