* 1. 설계 방법론
1.UP방법론
Inception- Elaboration- Construction-Transision phase별로
business modeling-requrements- analysis and design- implementation- test- deployment를 반복적으로 수행
각 단계별 집중하는 disciplines(분야)이 있음. agile과 유사하나 UP는 설계에 중점, agile은 개발에 중점
elaboration단계 이후에 만들어지는 baseline architecture(매우중요, 크게 변하지 않음)
중간중간에 milestone을 둠.
특징 : use case driven, architecture centric, controlled iterative model, incremental build model
2. ADD방법론
Design Strategies
- development paradigms : 생산성 , 어떤 구조의 프로그램방식선택?
- principle : GRASP(general responsibility Assignment Software Patterns), 낮은결합도/높은응집도/전문가/생성자/controller/don't talk to stranger
- tactic : 기반 디자인 기술, availability--> 이중화(tatic), 자극/환경/반응
- Style : 자주일어나는 문제해결을 위해 시스템이 구조적으로 답을 줌
- RA(reference architecture) : 도메인내 존재하는 blue print - architectural styles:도메인독립적, RA(도메인 종속적), WebApplication RA, Mobile App RA
- external component : buy/ build, Product, Framework, platform, 선정유의사항(problem tha it address, cost, type of licese, support, learning curve)
- practical examples :
Architectural Drivers
- Design Purpose : business goal, 성숙된도메인/신규도메인
- Quality attributes : 비기능 요구사항, 측정가능성 테스트가능속성,
- Primary Functionality : business goal달성을 위한 동인,
- Architectural Concerns(노하우) : domain에 대한 기존 노하우, 로깅, configuration, 예외처리, 캐싱
- Constraints : architect가 control할수 없는 영역, 법규, 데드라인,backward compatibility, other system, mandated technologies, 개발자역량
3. ADD Mothod: SW설계를 위해 시스템적으로 재귀적 분해하는 과정 ADD(잘라감, recursive, 품질요구사항) vs UP(완성함, Iterative, 기능요구사항)
recursive(Plan,do,check)
1)review input
2)Establish iteration goal by selecting Drivers
3)choose on or more elements of the system to refine
4)choose one or more design concepts that satisfy the selected drivers
5)instantiate architectural elements allocate responsibilities and define interfaces
6)sketch views and record design decisions
7)perform analysis of current design and review iteration goal and achievement of design Purpose
4. ADD 수행단계
1) 분해할 모듈을 선택한다.
2) 선택한 모듈을 분해하고 정제한다.
아키텍처 동인선택- 아키텍처스타일선택-모듈을 실체화하고 기능할당(logical/deployment view작성)- 하위모듈의 인터페이스정의-유즈게이스와 품질속성을 정제하고 검증을 하여 하위모듈 제약사항을 만듬
3) 모듈분해가 필요없을때까지 반복한다.
단계가 끝나면 골격시스템이 나온다(architecture baseline)- platform, framework/toolkit, 주요기능
elaboration단계 끝나면 안정화 되어야 함. 기능/품질요구사항을 아키텍처에 반영하는 설계방법
'T-prj > 1.SW공학' 카테고리의 다른 글
아키텍처평가검증 (0) | 2017.09.05 |
---|---|
Architecture Style 유형과 품질속성 (0) | 2017.09.01 |
99회 결과 (0) | 2013.03.29 |
Recent Comment