설문, 인터뷰, JPR (Joint requirement planning) 등을 이용하여 이해 관련자로부터 수집, 용어집으로 용어 표준화
기능적 요구사항(유스케이스 다이어그램)
문제 해결을 위해 시스템이 제공해야 할 서비스
비기능적 요구사항 (부가사항 명세서)
시스템 품질: 신뢰성, 가용성, 성능, 편의성, 접근성, 보안성
제약사항
설계,구현/하드웨어/인터페이스 등의 제약사항
국제 (표준) 구격
요구사항 검증 기준
명확성: 일치된 해석
완전성: 모든 정보 기술
일관성
요구사항 간의 모순이 없어야 함
실현할 수 없을 정도의 많은 제약사항 회피
추적가능성: 추적할 수 있도록 각 요구사항에 id 부여
검증가능성: 정량화, 명확한 계량적 기준
사용자 관점 (WHAT o HOW x)
사용/구현 기술보다 비즈니스 도메인에 중점
누가 어떤 목적으로 시스템을 사용하는지 파악
분석
개발자 관점에서 유스케이스 실체화
클래스 다이어그램
클래스 후보(유스케이스 중 명사)와 속성 추출
객체 책임(연산) 식별
클래스 간의 논리적 관계 식별
시퀀스 다이어그램
유스케이스에 대한 정상적인 작업흐름, 대안흐름 시나리오 작성, 객체 간의 상호작용 식별
설계, 구현 기술/방식을 고려
분석 결과는 설계 및 구현 기술/방식의 선정 기반
설계
UI/영속성 등을 고려하여 기존 클래스 보완
기능, 품질 속성을 고려하여 아키텍쳐 설계
상위 수준에서 software를 설계하는 기본 틀 제공
외부 자원/오픈 소스 등 활용
아키텍쳐 스타일
계층 아키텍쳐
파이프 & 필터
블랙보드
MVC 등
계층 아키텍쳐
수행하는 책임/관심에 따라 계층으로 나누어 설계
계층 내에서는 협업, 계층 간에는 결합도 최소화
서비스 제공 관계: 하위 계층 -> 상위 계층
3 계층 아키텍쳐(PL > BLL > DAL)
프레젠테이션 계층
UI(화면 조작, 입출력)
비즈니스 로직 계층
애플리케이션 로직 실행, 비즈니스 도메인 기능
데이터 접근 계층
비즈니스 로직 수행에 필요한 정보 조회 및 저장파이프 & 필터
파이프 & 필터
예시: cat test | sort | grep "shell"
필터: 시스템을 구성하는 컴포넌트
입력 데이터를 받아 출력 데이터 생성 (변환기)
파이프: 필터 간의 연결 관계
이전 필터의 출력을 다음 필터의 입력으로 전달
필터 설계 시 고려사항
필터 상호 간에 상태정보 공유하지 않을 것
현재 필터는 앞, 뒤 필터에 대한 정보를 모름
병렬적으로 수행, 파이프를 통해 동기화
someValue.map.filter.reduce 이런느낌?
블랙보드
시스템의 현재 상태를 저장하는 중앙 자료 저장소
컴포넌트 간에는 블랙보드를 통해 상호작용
컴포넌트 간 결합도 낮음 -> 재사용/추가 용이
자료 저장소의 상태 변화 시 모든 컴포넌트에 알림
자료 저장소와 컴포넌트 간 결합도 높음
컴포넌트가 조금만 많아져도 대왕 블랙 보드가 되겠는데
MVC(Model-View-Controller)
모델: 데이터와 기능 제공
뷰: UI, 모델로부터 입력 받아 화면 표시
컨트롤러: 사용자/시스템과 상호작용
사용자 요청을 처리하여 모델 생성, 뷰 선정
모델과 뷰 간의 결합관계를 약화시킴
Massive ViewController ?!Apple의 MVC 아키텍쳐
N-티어 시스템
N은 논리적인 계층의 수를 의미
클라이언트 - 서버 가 몇단계로 쪼개지는지
1-tier 아키텍쳐: 클라이언트 - DB (손쉬운 구성 but 확장성, 이식성 결여)2-tier 아키텍쳐: 클라이언트 - 서버 - DB (DB Server 공유 but 성능 부하)3-tier 아키텍쳐: 클라이언트 - 서버 - WAS - DB (보안, 성능, 확장성 우수 라고합니다) 로드밸런싱, 장애대응, 로그취합 등을 WAS에서 처리해줌
![[소프트웨어 공학] 객체지향 개발 프로세스](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FmMm03%2FbtrMyiGkR0j%2FKNo9KQDIXdf5SPC4MPLmb0%2Fimg.png)
