소프트웨어 설계와 구현 실행 가능한 소프트웨어 시스템이 개발되는 소프트웨어 공학 프로세스 단계 간단한 시스템 소프트웨어 설계와 구현을 의미 다른 모든 소프트웨어 공학 활동들은 이 프로세스에 병합 큰 시스템 많은 소프트웨어 공학 프로세스들 중 하나 설계 고객의 요구사항을 기반으로 소프트웨어 컴포넌트들과 그들 간의 관계를 식별하는 창의적인 활동 구현 설계를 프로그램으로 실현하는 프로세스 설계 방식 때때로 분리된 설계 단계가 있어 설계가 모델링되고 문서화됨 프로그래머의 머리에 있거나 화이트보드나 종이에 개략적으로 스케치 → 항상 프로세스가 있는 것은 아님 설계 시 구현 이슈 설계 문서화를 위해 UML를 사용하는 것 객체 지향 언어로 프로그래밍 → 적절 동적 타입 언어 → 부적절 애자일 방법 사용 설계할 때 대..

애플리케이션 아키텍처 개발/도입 이유 비즈니스 또는 조직의 필요를 만족시키기 위해 비즈니스들은 해당 영역에 특화된 공통 애플리케이션 사용 → 이런 공통점으로 인해 아키텍처 도입 애플리케이션 아키텍처 시스템 클래스의 주요 특성 포함 예: 실시간 시스템 - 데이터 수집 시스템 또는 모니터링 시스템 같은 유형의 시스템을 개발 시 공통적인 아키텍처 구조를 재사용 비즈니스 시스템에서 애플리케이션 아키텍처 재사용을 함 애플리케이션 아키텍처 모델 사용법 아키텍처 설계 프로세스의 시작점 개발하는 애플리케이션 유형에 익숙하지 않은 경우에 해당 초기 설계를 일반 애플리케이션 아키텍처에 기반을 두고 시작 추후 개발할 특정 시스템을 위해 설계를 특화 설계 점검표 애플리케이션 시스템을 위한 설계가 일반적인 아키텍처와 일치하는지..

패턴과 아키텍처 패턴 패턴 소프트웨어 시스템에 대한 지식을 표현하고 공유하고 재사용하는 방법 객체지향 설계 패턴, 구조 설계를 위한 패턴, 사용성 패턴, 형상관리 패턴 등 아키텍처 패턴 서로 다른 시스템과 환경에서 시도되고 시험된 바람직한 사례를 양식화하고 추상화한 기술 설명 기술과 다이어그램을 섞어서 사용하는 표준 방법으로 기술 가능 패턴에 관련된 상세한 내용 포함 모델 뷰 제어기(MVC) 패턴의 구성 웹 기반 시스템에서 상호 작용 관리의 기반 대부분의 언어 프레임 워크에서 지원 예 : 런타임 시스템 아키텍처 아키텍처 설계의 기본 분리와 독립의 개념 변경에 의해 영향받는 범위를 작게 만듦 MVC 패턴 시스템의 요소들을 분리하여 독립적으로 변경될 수 있도록 함 계층 아키텍처 패턴 분리와 독립을 이루는 또..

아키텍처 설계 소프트웨어 설계 프로세스의 첫 단계 시스템의 전체 설계를 이해하는 것 주요 구조 컴포넌트들과 그들 간의 관계 식별 설계와 요구공학 사이의 중요한 연결 결과물 → 아키텍처 모델 시스템이 상호작용하는 컴포넌트들의 집합으로 어떻게 구성되었는지 설명 애자일 프로세스 아키텍처 설계 초기 단계에서 전체 시스템 아키텍처 설계에 초점 맞춤 아키텍처의 점진적 개발은 보통 성공적이지 않음 변화에 대응하여 컴포넌트를 리팩토리항 하는 것이 상대적으로 쉬움 시스템 아키텍처를 리팩터링 하는 것은 비용이 많이 듦 아키텍처 변화에 따라 시스템 컴포넌트들은 수정해야 함 아키텍처 설계의 현실적 측면 주요 아키텍처 컴포넌트들이 시스템의 상위 수준 특징 반영 → 컴포넌트 식별 필요 이상적으로는 시스템 명세에는 설계 정보가 포..

동작 모델 시스템이 실행될 때의 동적 행동에 대한 모델 시스템이 환경 자극에 반응할 때, 무엇이 일어나는지 또는 일어나도록 의도했는지 보여줌 자극의 종류 데이터 : 시스템이 처리해야 하는 데이터가 도착 이벤트 : 시스템 처리를 활성화하는 이벤트가 발생 시스템 동작 방식 데이터 처리 시스템 시스템에서 보낸 데이터를 처리(예 : 전화 과금 시스템) 실시간 시스템 이벤트가 시스템을 작동, 이벤트와 연관된 데이터가 있을 수 있음(필수 X)(예: 유선전화기) 데이터 주도 모델링 데이터 주도 모델 입력 데이터 처리와, 입력 처리와 연관된 출력 생성과 관련된 일련의 행동 (= 처음부터 끝까지 시스템의 처리 사항을 보여줌) 요구사항 분석 중에 사용될 수 있음 처음으로 사용된 그래픽 소프트웨어 모델 데이터 흐름 모델 특..

시스템 모델링 시스템의 추상 모델을 개발하는 프로세스 각 모델은 시스템의 서로 다른 뷰나 관점을 나타냄 UML 다이어그램 유형 기반 그래픽 표기법으로 나타냄 모델의 단계별 사용 요구공학 프로세스 : 시스템의 상세 요구사항을 이끌어내기 위해 사용 설계 프로세스 : 엔지니어들에게 시스템을 설명하기 위해 사용 구현 후 : 시스템의 구조와 동작을 문서화하기 위해 사용 기존 및 새 시스템의 모델 개발 요구공학 중에 사용됨 기존 시스템의 모델 기존 시스템이 무엇을 하는지 알려줌 이해당사자간 논의를 강점과 약점에 집중하는 데 사용 새 시스템의 모델 제안된 요구사항들을 다른 시스템 이해당사자들에게 설명하는 데 사용 엔지니어들은 이 모델들을 설계를 논의하고 시스템을 문서화하는 데 사용 시스템 모델 검토 중인 시스템의 추..

요구사항 검증 고객이 정말 원하는 시스템인가?를 점검 도출 및 분석과정과 겹침 요구사항에서 문제점을 찾는 것과 관련 요구사항 검증은 매우 중요한 과정 이후 단계에서 요구사항 문서상 오류가 발견될 경우 막대한 재작업 비용 필요 ← 주로 개발 중이나 서비스 시작 후에 문제점이 발견되기 때문 시스템 변경을 통해 요구사항 문제를 수정할 경우 높은 비용 발생 ← 시스템 설계와 구현 변경, 테스트 다시 수행 → 설계나 코드 오류보다 훨씬 높은 비용 요구사항 검증 시 점검해야 하는 사항들 유효성 점검 요구사항이 시스템 사용자의 실제 요구를 반영하는가? 일관성 점검 문서상의 요구 사항이 서로 상충되지 않는지 확인 → 모순되는 제약이나 같은 기능에 대한 다른 설명이 없는지 확인 완전성 점검 의도한 모든 기능과 제약이 정..

요구사항 명세 — 사용자 요구사항 및 시스템 요구사항을 문서로 작성하는 과정 이상적인 요구사항 작성 조건 대상 : 사용자 요구사항과 시스템 요구사항 모두 특징 : 명확하고, 모호하지 않으며, 이해하기 쉽고, 완전하고, 일관성 있어야 함 실제로 달성 어려움 ← 충돌이나 불일치 자주 발생 ← 이해당사자들 간의 다른 해석 사용자 요구사항 작성 단순한 표, 양식, 직관적 다이어그램을 가지고 자연어로 작성 기술적 지식이 없는 시스템 사용자가 이해할 수 있도록 기능적/비기능적 요구사항을 포함 시스템의 외부 동작에 대해서만 명세 시스템 아키텍처나 설계에 대한 상세한 내용 X 시스템 요구사항 작성 사용자 요구사항에 상세한 내용 추가 시스템의 외부 동작과 운영상의 제약에 대해서만 기술 시스템의 설계와 구현에 대해서는 다..