마인드 맵 갤러리 정보시스템 분석 및 디자인 마인드 매핑
시스템 분석 및 설계 개요, 시스템 요구 사항 조사, 유스 케이스, 도메인 모델 등을 포함한 정보 시스템 분석 및 설계에 대한 마인드 맵입니다.
2023-11-14 10:01:51에 편집됨정보 시스템 분석 및 설계
chap01 시스템 분석 및 설계 개요
소개
이것은 정보 시스템 개발을 돕기 위한 일련의 사양, 지침입니다.
1.1 소프트웨어 개발과 시스템 분석 및 설계
컴퓨터 응용 프로그램
컴퓨팅 장치에서 특정 기능 세트를 수행하는 컴퓨터 소프트웨어 프로그램
중간 범위의 적용
"애플리케이션"(앱)이라고도 함
정보시스템
비즈니스 작업을 완료하는 데 필요한 정보를 수집, 처리, 저장 및 제공하는 상호 연관된 구성 요소 집합
"응용 프로그램"보다 더 넓은 범위
소프트웨어, 데이터베이스 및 관련 수동 프로세스가 포함됩니다.
시스템 분석
사람들이 정보 시스템이 달성해야 하는 것을 이해하고 구체화할 수 있도록 하는 활동
시스템 디자인
요구사항을 해결하는 시스템을 세부적으로 정의하고 설명할 수 있는 활동
시스템 분석은 청사진을 그리는 것과 같고 시스템 설계는 세부 계획입니다.
1.2 시스템 개발 수명주기
프로젝트
시작과 끝이 있고 일정한 결과를 가져오는 계획된 작업
정보 시스템 개발을 위한
시스템 분석, 시스템 설계 도구 및 기술에 대한 지식이 필요합니다.
SDLC(System Development Life Cycle), 즉 시스템 개발 수명주기
시스템 개발 라이프사이클은 정보 시스템을 구축, 출시 및 유지하는 데 필요한 모든 활동을 포함하는 전체 프로세스를 식별합니다.
모든 활동에는 시스템 분석, 시스템 설계, 프로그래밍, 테스트, 시스템 유지 관리가 포함됩니다.
6가지 핵심 프로세스
문제나 요구사항을 파악하고 승인을 받으세요.
프로젝트 계획 및 모니터링
문제나 요구 사항의 세부 사항을 발견하고 이해합니다.
문제를 해결하거나 요구 사항을 충족하는 시스템 구성 요소 설계
시스템 구성 요소 구축, 테스트 및 통합
시스템 테스트를 완료한 후 솔루션 배포
정보시스템 개발 과정
시스템 테스트를 완료한 후 솔루션을 배포하여 특정 정보 시스템(일명: 방법론)을 개발하는 실용적인 접근 방식
예를 들어
통합 프로세스(UP)
익스트림 프로그래밍(XP)
반복적인 증분 소프트웨어 개발 프로세스 스크럼
이제 대부분의 프로세스/방법은 민첩하고 반복적인 개발을 사용합니다.
애자일 개발애자일 개발
개발 중 새로운 요구 사항을 예측하는 유연성을 강조하는 정보 시스템 개발 프로세스
변화에 빠르게 반응합니다.
사용자나 팀 구성원 모두 새 시스템의 문제와 복잡성을 완전히 이해하지 못하므로 프로젝트 계획 및 실행에서는 예상치 못한 문제를 고려해야 합니다.
반복 개발반복 개발
여러 번의 반복을 통해 시스템이 점진적으로 "성장"하는 시스템 개발 접근 방식
시스템의 작은 부분(미니 프로젝트)을 완성한 다음, 다듬고 추가하는 과정을 반복하고, 완성될 때까지 다듬고 더 추가하는 과정을 반복합니다.
이점
1. 시스템의 일부를 신속하게 배포할 수 있습니다.
2. 먼저 개발할 작은 부분을 꺼내어 프로젝트에서 어려운 문제를 가능한 한 빨리 찾을 수 있도록 하십시오.
프로젝트 반복을 위한 6가지 핵심 프로세스
원의 면적은 이 프로세스에서 해당 반복의 작업량을 나타냅니다.
각 반복은 서로 다른 초점을 가진 여러 프로세스를 수행합니다.
1.5 RMO 거래 시스템을 예로 들어 개발 프로세스를 소개합니다.
1.5.1 준비
문제 식별 및 시스템 목표 문서화(핵심 프로세스 1)
예비 조사
결과를 시스템 비전 문서(SVD)로 변환
프로젝트 시작 승인 받기 (핵심 프로세스 1)
경영진을 포함한 주요 이해관계자와의 만남
경영진을 포함한 주요 이해관계자와 만나 결정을 내리고 계획과 예산을 승인합니다.
SVD(시스템 비전 문서)
시스템 비전 문서는 회사에 도움이 될 기능과 시스템에 포함될 기능을 식별하는 데 사용됩니다.
두 단계로 수행하세요.
초기 혜택 설명 개발
자세한 수익 및 비용 추정 추가
일반적으로 세 부분으로 구성됩니다.
문제 설명
시스템 성능
비즈니스 혜택
1.5.2 첫날 활동
핵심 프로세스 2: 프로젝트 계획
필요한 주요 구성 요소(기능 영역) 식별
시스템을 하위 시스템이나 구성 요소로 나누기
하위 시스템은 전체 시스템의 일부입니다.
반복을 정의하고 각 기능 영역을 반복에 할당
단일 반복 계획
반복에 필요한 작업 결정
식별된 작업은 작업분류체계(WBS)라는 목록으로 컴파일되고 구성됩니다.
예
WBS 내용(작업 휴식 구조)
분해기준(명칭)
분해의 기초는 다음 네 가지 핵심 프로세스에 따라 달라집니다.
소요시간
실행 순서
필요한 시간과 실행 순서를 측정하면 후속 작업 네트워크 구축 및 중요 경로(PERT) 계산에 도움이 될 수 있습니다.
핵심 경로는 전체 네트워크에서 가장 긴 경로이며, 다른 경로의 프로세스는 엄격하게 실행되어야 합니다.
이러한 작업을 날짜별로 정리하고 유지하세요.
WBS를 일정으로 변환
개별 반복을 계획하는 것의 장점은 일정이 비공식적이고 예상치 못한 상황에 맞게 조정될 수 있다는 것입니다.
초안 작업 순서 개발
초안 작업 주문의 이점
1. 팀워크를 체계화하는 데 도움
2. 반복이 계획대로 진행되고 있는지에 대한 척도를 제공합니다.
3. 이 일정에 따라 프로젝트가 다소 시간이 걸릴 경우, 프로젝트 리더는 프로그래밍에 더 많은 시간과 자원이 필요할 수 있음을 확인하고 프로젝트의 이 부분을 돕기 위해 자원을 조기에 구성할 수 있습니다.
필요한 자원(사람)을 파악하고 해당 업무를 수행할 인력을 배치합니다.
팀 구성원 및 책임 식별
1.5.3 둘째날 활동
요구 사항을 이해하기 위해 예비 사실 조사 작업을 수행합니다. (핵심 프로세스 3)
2장에서 자세히 설명하겠습니다.
사용 사례의 예비 목록과 사용 사례 다이어그램을 개발합니다. (핵심 프로세스 3)
사용 사례
사용 사례는 단일 사용자가 트리거한 비즈니스 이벤트와 해당 이벤트에 대한 시스템의 응답을 기록합니다.
유스케이스(Use Case)는 시스템 사용의 예나 상황을 말한다.
예: 구매 대리인은 "공급업체에 문의"하기 위해 이 시스템을 "사용"합니다.
사용 사례는 일반적으로 요구 사항/기능에 해당하는 동사입니다.
사용 사례 목록 예
사용 사례 다이어그램 예
예비 수업 목록과 수업 다이어그램을 개발합니다. (핵심 프로세스 3)
객체 클래스
객체 클래스 식별 시스템은 현실 세계에서 이러한 것들을 이해하고 추적해야 합니다.
객체 클래스는 시스템에 정보를 저장해야 합니다.
수업 목록 예시
클래스 다이어그램 예
예비 클래스 다이어그램이므로 속성(정적 기능)만 있습니다.
디자인 클래스 다이어그램에는 속성 데이터 유형과 클래스 메소드 등이 있습니다.
위 다이어그램은 Unified Modeling Language UML을 사용하여 개발되었습니다.
1.5.4 셋째날 활동
자세한 사실을 알아보기 위해 심층적인 사실 조사를 수행합니다. (핵심 프로세스 3)
각 사용 사례에 대한 자세한 워크플로를 이해하고 문서화합니다. (핵심 프로세스 3)
사용 사례 설명 및 워크플로 다이어그램 개발
사용 사례 세부 정보를 문서화하는 두 가지 방법은 다음과 같습니다.
워크플로 다이어그램을 개발하려면 UML의 다이어그램인 활동 다이어그램을 사용해야 합니다.
워크플로 다이어그램 예
그림의 타원은 작업을 나타내고, 다이아몬드는 결정 지점을 나타내고, 화살표는 시퀀스 흐름을 나타내고, 중심선을 가로지르는 화살표는 사용자와 시스템 간의 상호 작용을 나타냅니다.
화면과 보고서를 통해 사용자 경험을 정의합니다. (핵심 프로세스 3, 4)
화면 레이아웃 정의
1.5.5 넷째 날 활동
데이터베이스 구조(스키마)를 디자인합니다. (핵심 프로세스 4)
테이블 디자인
키워드 및 색인 식별자
부동산 유형
참조 무결성
데이터베이스 스키마 예
시스템의 상위 수준 구조를 설계합니다. (핵심 프로세스 4)
전반적인 건축 디자인
예비 디자인 클래스 다이어그램 정의
예비 설계 클래스 다이어그램 예
디자인 클래스에는 클래스에 필요한 클래스 수준 변수가 포함되어 있으며, 여기에는 각 클래스의 중요한 메서드 이름도 표시됩니다. 디자인 클래스 다이어그램의 마지막 요소는 화살표로, 어떤 클래스가 다른 클래스의 메서드에 액세스할 수 있는지 보여줍니다.
하위 시스템 아키텍처 설계
1.5.6 5일차 활동
세부 설계 계속(CP4)
프로그래밍 및 개별 테스트 수행(CP5)
디자인과 프로그래밍은 전체를 디자인하고 프로그래밍하는 것이 아니라, 부품을 디자인하고, 프로그래밍하고, 부품을 디자인하고, 다시 프로그래밍하는 것입니다.
1.5.7 6일차 활동
전체 시스템 테스트(CP6)
전체 시스템 기능 테스트
사용자 승인 테스트
부분 시스템 구축 가능(CP6)
1.5.8 첫 번째 반복 검토
1.6 후속 콘텐츠 소개
1.6.1 1부 시스템 개발 소개
제1장
1.6.2 Part 2 시스템 분석 활동
2장, 3장, 4장, 5장
1.6.3 3부 시스템 설계 활동
6장과 7장
1.6.4 4부 프로젝트 및 프로젝트 관리
8장과 9장
1.6.5 5부 고급 개념 및 배포 개념
10장, 11장, 12장
chap02 시스템 요구사항 설문조사
2.1 소개
이 장에서는 더 넓은 범위의 개념, 도구 및 기술을 다루기 위해 SDLC 프로세스의 범위와 세부 사항을 확장하기 시작합니다. 이 장에서는 시스템 분석 활동(나열된 세 번째 핵심 프로세스)에 중점을 두고 있지만 다음 장에서는 이러한 시스템 분석 활동 중에 개발된 모델을 자세히 논의합니다. 후속 장에서는 다른 핵심 SDLC 프로세스에 대한 논의를 확장합니다.
2.2RMO를 위한 CSMS(종합 영업 및 마케팅 시스템)
2.2.1RMO의 기존 정보시스템 및 아키텍처
아키텍처는 두 가지 유형으로 나뉩니다.
기술 아키텍처 기술 아키텍처
기술 아키텍처는 조직에서 사용하는 컴퓨팅 하드웨어, 네트워크 하드웨어 및 토폴로지, 시스템 소프트웨어(예: 운영 체제 및 데이터베이스 관리 시스템) 세트를 설명합니다.
애플리케이션 아키텍처 애플리케이션 아키텍처
응용 프로그램 아키텍처는 조직의 정보 시스템을 구현하기 위해 소프트웨어 리소스를 구성하고 구조화하는 방법을 설명합니다. 지원 기술(예: 프로그래밍 언어 및 개발 환경), 아키텍처 접근 방식(예: 서비스 지향 아키텍처) 및 사용자 인터페이스 기술(예: 모바일 컴퓨팅 디스플레이, 터치 스크린)을 포함하여 소프트웨어를 모듈 및 하위 시스템으로 구성하는 방법을 설명합니다. 기술 및 음성 인식).
2.1.2 새로운 CSMS
새로운 통합 영업 및 마케팅 시스템에는 4개의 하위 시스템이 있습니다.
판매 하위 시스템
주문 구현 하위 시스템
고객 계정 하위 시스템
마케팅 하위 시스템
2.3 시스템 분석 활동
다섯 가지 주요 부분이 있습니다
2.3.1 상세정보 수집
인터뷰, 설문지, 문서화, 비즈니스 프로세스 관찰, 공급업체 조사, 의견 및 제안
2.3.2 요구사항 정의
기능적 및 비기능적 요구사항 모델링
2.3.3 요구사항의 우선순위 지정
2.3.4 사용자 인터페이스 대화 상자 개발
사용자와 시스템 간의 상호작용 프로세스
2.3.5 사용자와 함께 요구 사항 평가
사용자 참여, 피드백, 변화에 대한 적응
2.4 수요란 무엇인가
시스템 요구 사항은 새 시스템이 수행하거나 지원해야 하는 모든 활동과 새 시스템이 충족해야 하는 제약 조건입니다.
시스템 요구 사항은 다음과 같이 구분됩니다.
기능 요구 사항
기능적 요구사항은 시스템이 수행해야 하는 활동(예: 시스템이 적용될 비즈니스)입니다.
사용자가 실행해야 함
비기능적 요구사항
비기능적 요구사항은 시스템이 수행하거나 지원해야 하는 활동 이상의 특성입니다.
성과지표, 제약사항(개발도구, 데이터 형식 등) 등
FURPS를 사용하여 간단히 요구 사항을 나눌 수 있습니다.
기능적 기능성
유용성 가용성
신뢰할 수 있음
성능
보안
기타 제한 조건 등
비기능적 요구사항
2.5 모델과 모델링
모델
모델은 구축 중인 시스템의 일부 측면을 표현한 것입니다.
모델 유형
텍스트 모델
보고서, 문서
그래픽 모델
개략도
수학적 모델
공식
모델링 언어
많은 그래픽 모델의 개발은 UML(Undefine Modeling Language)을 통해 구현됩니다.
UML은 비영리 조직인 Object Management Group에서 정의한 표준 모델 구성 및 기호 집합입니다.
2.6 이해관계자
이해관계자는 시스템의 성공적인 구현에 관심이 있는 모든 사람입니다.
이해관계자 분류
내부 이해관계자
내부 이해관계자는 시스템과 상호 작용하거나 시스템 운영이나 성공에 상당한 관심을 갖고 있는 조직 내 사람들입니다.
외부 이해관계자
외부 이해관계자는 조직의 통제와 영향력 밖에 있는 사람들입니다.
운영 이해관계자
운영 이해관계자는 업무나 생활에서 시스템과 자주 상호 작용하는 사람들입니다.
예를 들어 회계 또는 청구 시스템과 상호 작용하는 회계 담당자, 생산 일정 시스템과 상호 작용하는 공장 작업자, 인터넷 매장과 상호 작용하는 고객, 의료 웹 사이트, Facebook 페이지 또는 Twitter 뉴스 피드와 상호 작용하는 환자 등이 있습니다.
이해관계자 관리
경영 이해관계자는 시스템과 직접 상호작용하지 않지만 시스템에서 생성된 정보를 사용하거나 시스템 운영 및 성공에 상당한 재정적 또는 기타 이해관계가 있는 사람들입니다.
예: 조직의 고위 경영진, 이사회, 규제 기관, 세무 당국.
두 가지 유형의 중요한 이해관계자
고객 : 재정적 지원을 제공하는 사람
시스템 기술지원 인력
2.7 정보 수집 기술
정보 수집 기술에는 다음이 포함됩니다.
2.7.1 사용자 및 기타 이해관계자와의 인터뷰 실시
시스템 분석가가 필요합니다
상세한 질문을 준비하세요
질문의 주제
비즈니스 프로세스는 어떠해야 합니까?
비즈니스 프로세스의 작동 방식
어떤 정보가 필요합니까?
질문 유형
공개 질문
닫힌 질문
질문 대상: 기존 시스템 또는 새 시스템
개별 사용자 또는 사용자 그룹을 만나보세요
질문에 대한 답변을 얻고 토론하세요
답변을 녹음하다
향후 인터뷰에 사용할 정보에 대한 후속 조치
2.7.2 설문지 배포 및 수집
세 가지 유형의 질문
닫힌 질문
형식 문제를 살펴보세요.
공개 질문
2.7.3 입력, 출력 및 프로세스 확인
입력, 출력, 프로세스의 두 가지 소스가 있습니다.
조직 내 비즈니스 기록 및 프로세스 설명
조직 외부에서 – 전문 조직 및 업계 전반의 기타 회사
기존 처리 문서 확인
2.7.4 비즈니스 프로세스 관찰 및 기록
이는 비즈니스의 기능을 이해하는 데 도움이 됩니다.
2.7.5 조사 공급자 솔루션
세 가지 이점과 한 가지 위험
1. 이러한 솔루션을 연구하면 사용자가 비즈니스 기능을 더 잘 실행하는 방법에 대해 더 잘 생각하는 데 도움이 될 수 있습니다.
2. 일부 솔루션은 이미 최고 수준이어서 연구 없이는 트렌드를 따라가기가 어렵습니다.
3. 솔루션을 구입하는 것이 솔루션을 연구하는 것보다 위험이 적고 저렴합니다.
위험: 시스템 요구 사항을 모두 조사하지 않고 서둘러 솔루션을 구입하는 것
2.7.6 활성 사용자 댓글 수집
2.8 활동 다이어그램을 사용하여 작업 흐름 기록
작업 흐름
워크플로는 비즈니스 트랜잭션이나 고객 요청을 완벽하게 처리하는 일련의 처리 단계입니다.
활동 다이어그램
활동 다이어그램은 다양한 사용자(또는 시스템) 활동, 각 활동을 수행하는 사람 및 해당 활동의 순차적 흐름을 설명합니다.
기호 및 설명
타원은 워크플로의 다양한 활동을 나타냅니다. 연결 화살표는 활동 간의 순서를 나타냅니다. 검은색 원은 워크플로의 시작과 끝을 나타냅니다. 다이아몬드는 프로세스가 하나의 경로 또는 다른 경로를 따르게 되는 결정 지점입니다. 굵은 실선은 경로를 여러 동시 경로로 분할하거나 동시 경로를 재결합할 수 있는 동기화 막대입니다. 수영 레인 제목은 활동을 수행하는 에이전트를 나타냅니다. 일반적으로 워크플로 프로세스의 다양한 단계를 수행하는 워크플로에는 다양한 에이전트(예: 사람)가 있기 때문에 스윔 레인 기호는 워크플로 활동을 그룹으로 나누어 어떤 에이전트가 어떤 활동을 수행하는지 보여줍니다.
chap03 사용 사례
3.1 소개
4장과 5장과 마찬가지로 이 장에서도 다양한 모델을 생성하여 기능적 요구 사항을 문서화하는 기술을 소개합니다.
유스 케이스는 일반적으로 사용자의 요청에 응답하여 시스템이 수행하는 활동입니다.
사용 사례는 기능적 요구 사항을 정의합니다.
분석가는 시스템을 일련의 사용 사례로 분해합니다(기능 분해).
사용 사례는 일반적으로 동사나 동명사의 이름을 따서 명명됩니다.
3.2 사용 사례 및 사용자 목표
사용 사례를 정의하는 한 가지 기술은 사용자에게 새 시스템이나 업데이트된 시스템을 사용하기 위한 목표를 설명하도록 요청하는 사용자 목표 기술입니다.
8단계로 나누어져 있어요
새로운 시스템의 모든 잠재적 사용자를 식별합니다.
기능적 역할(예: 운송, 마케팅, 판매)을 기준으로 잠재 사용자를 분류합니다.
잠재 사용자를 조직 수준(예: 운영, 관리, 임원)별로 추가로 분류합니다.
각 유형의 사용자에 대해 해당 사용자를 방문하여 새 시스템을 사용할 때 갖게 될 구체적인 목표 목록을 찾으십시오(현재 목표 및 가치를 추가하는 혁신적인 기능).
사용자 유형별로 정리된 사용 사례의 예비 목록을 만듭니다.
유사한 사용 사례 이름을 가진 복사본을 찾고 불일치를 해결합니다.
다양한 유형의 사용자가 동일한 사용 사례를 필요로 하는 위치 결정
각 유형의 사용자 및 관심 있는 이해관계자와 함께 완성된 목록을 검토합니다.
일반적으로 기능적 요구사항이 있는 이벤트만 고려됩니다.
사용자 타겟팅 기술은 간단하지만 일반적으로 사용됩니다.
3.3 사용 사례 및 이벤트 분해
이벤트 분해 기술은 유스 케이스 식별을 위한 가장 포괄적인 기술입니다.
이벤트 분해 기술은 먼저 정보 시스템이 응답하도록 하는 모든 비즈니스 이벤트를 결정하고 각 이벤트는 사용 사례로 이어집니다. 비즈니스 이벤트를 시작하면 분석가는 적절한 세부 수준에서 각 사용 사례를 정의하는 데 도움이 됩니다.
사용 사례에 대한 적절한 세부 정보 수준을 결정하는 데 사용되는 것은 필수 비즈니스 프로세스(EBP)입니다.
EBP는 비즈니스 이벤트에 대응하고 측정 가능한 비즈니스 가치를 추가하며 시스템과 데이터를 안정적이고 일관된 상태로 만들기 위해 한 사람이 한 장소에서 수행하는 작업입니다.
각 EBP는 비즈니스 이벤트가 발생할 때 이에 응답합니다.
3.3.1 이벤트 분해 기술
이벤트
이벤트는 특정 시간과 장소에서 발생하고 설명할 수 있으며 시스템에 의해 기억되어야 합니다.
3.3.2 이벤트 유형
외부 이벤트
외부 이벤트는 시스템 외부에서 발생하는 이벤트로, 일반적으로 외부 에이전트나 행위자에 의해 시작됩니다.
외부 에이전트(또는 행위자)는 시스템에 데이터를 제공하거나 수신하는 개인 또는 조직 단위입니다.
예를 들어
사용자 주문 등 다양한 비즈니스 프로세스
외부 이벤트는 일반적으로 사용자(행위자) 요청에 응답하는 데 사용되며 인간-컴퓨터 상호 작용 환경에서 발생합니다.
시간 제한 이벤트/임시 시간
특정 시점에 도달한 결과 발생하는 이벤트.
예를 들어
정기적으로 통계보고서 등을 발송합니다.
시스템 내에서 일시적인 이벤트가 발생합니다.
상태 이벤트
상태 이벤트는 처리 요구 사항을 트리거하는 시스템 내에서 이벤트가 발생할 때 발생합니다.
상태가 변경될 때 발생
일반적으로 이는 비기능적 요구사항이므로 자주 고려되지 않습니다.
3.3.3 이벤트 정의
이벤트/전제조건/응답
분석가는 일련의 이벤트를 고려한 다음 실제로 시스템에 영향을 미치는 이벤트를 식별해야 합니다.
사건의 연속
특정 외부 개체나 행위자에게 발생한 일련의 이벤트를 추적하는 데 유용합니다.
기술 의존성 이벤트 및 시스템 제어
때때로 분석가는 시스템에 중요하지만 사용자나 트랜잭션과 직접적인 관련이 없는 이벤트에 관심을 갖습니다. 이러한 이벤트에는 일반적으로 설계 선택이나 시스템 제어가 포함됩니다. 분석가는 분석 중에 이러한 이벤트를 일시적으로 무시해야 합니다.
시스템 통제는 시스템의 무결성을 보호하기 위해 설계된 점검 또는 보안 절차입니다.
데이터 백업, 로그인 등
분석 단계에서는 이상적인 기술적 가정을 사용합니다.
완벽한 기술 가설은 시스템이 완벽한 조건(예: 장치가 절대 고장나지 않고, 처리 및 저장 능력이 무제한이며, 시스템을 운영하는 사람들이 완전히 정직하고 절대 실수하지 않는 경우) 하에서 반응해야 할 때만 이벤트가 발생해야 한다고 말합니다. 분석 과정에 포함됩니다.
3.3.4 이벤트 분해 기술 사용
1. 시스템 응답이 필요한 시스템 환경의 외부 이벤트 고려
2. 각 외부 이벤트에 대해 시스템에서 요구하는 사용 사례를 식별하고 이름을 지정합니다.
3. 체크리스트를 사용하여 시스템 응답이 필요한 시간 이벤트를 고려하십시오.
4. 각 시간 이벤트에 대해 시스템에서 요구하는 사용 사례를 식별하고 이름을 지정한 다음 사용 사례를 트리거하는 시점을 설정합니다.
5. 시스템이 응답할 수 있는 상태 이벤트를 고려하십시오. 특히 장치 또는 내부 상태 변경으로 인해 사용 사례가 트리거되는 실시간 시스템인 경우 더욱 그렇습니다.
6. 각 상태 이벤트에 대해 시스템에 필요한 사용 사례를 식별하고 이름을 지정한 다음 상태 변경을 정의합니다.
7. 이벤트 및 사용 사례를 정의한 후 완벽한 기술적 가정이 필요한지 확인합니다. 로그인, 로그아웃, 비밀번호 변경, 데이터베이스 백업 또는 복구와 같은 시스템 제어와 관련된 이벤트는 시스템 제어로 배치되므로 포함하지 마십시오.
3.4 사용 사례 및 CRUD
사용 사례를 검증하고 개선하는 또 다른 중요한 기술은 CRUD 기술입니다.
CRUD는 다음을 의미합니다.
만들다
읽고 또 읽어라
업데이트, 업데이트
삭제하다, 삭제하다
데이터베이스 관리와 관련된 작업입니다.
CRUD 기술은 교차 점검으로 사용자 타겟팅 기술과 함께 사용할 때 가장 유용합니다. 유스 케이스를 식별하는 방법으로 직접 사용하는 대신 유스 케이스가 비즈니스 프로세스를 잘 추적하지 못하게 될 수 있습니다.
누락된 사용 사례 유형이 있는지 확인할 수 있습니다.
CRUD 기술 단계
1. 새로운 시스템과 관련된 모든 데이터 엔터티 또는 도메인 클래스를 식별합니다.
2. 각 데이터 유형(데이터 엔터티 또는 도메인 클래스)에 대해 새 인스턴스 생성, 기존 인스턴스 업데이트, 인스턴스 값 읽기 또는 보고, 인스턴스 삭제(보관)에 대한 사용 사례를 식별했는지 확인합니다.
3. 필수 사용 사례가 무시되면 새 사용 사례를 추가하고 이해관계자를 식별합니다.
4. 통합 애플리케이션의 경우 어떤 애플리케이션이 데이터 추가 및 유지 관리를 담당하고 어떤 시스템이 데이터만 사용하는지 명확히 해야 합니다.
3.6 사용 사례 다이어그램
유스 케이스 다이어그램은 유스 케이스와 사용자와의 관계를 그래픽으로 표시하는 데 사용되는 UML 모델입니다.
3.6.1 사용 사례, 행위자 및 기호
대부분의 사용 사례에서 암묵적으로는 시스템을 사용하는 사람들(지금까지 사용자라고 지칭함)이 있습니다. UML에서는 이 사람을 액터(actor)라고 합니다. 액터는 자동화 경계 밖에 있는 경우가 많습니다.
유스케이스 다이어그램에서 사람 기호는 액터를 나타내고, 타원은 유스케이스를 나타내고, 직사각형 테두리는 자동화 경계를 나타내며, 유스케이스와 액터 사이의 연결은 어떤 액터가 어떤 유스케이스에 참여하는지를 나타냅니다.
예
유스 케이스와 액터 사이에 관계가 있을 뿐만 아니라 유스 케이스 사이에도 관계가 있을 수 있습니다.
이는 두 가지 형태로 제공되는 사용 사례 간의 종속성입니다. 점선 화살표와 << >>를 사용하여 나타냅니다.
<<포함>>
이는 하나의 유스케이스를 다른 유스케이스에서 사용하는 것을 의미하는 사용관계로 이해될 수 있습니다. 화살표로 표시된 유스케이스는 사용된 유스케이스(종속)입니다. 이 관계에서는 하나의 사용 사례가 다른 사용 사례에서 사용되어야 함을 요구합니다.
<<확장>>
이 관계는 하나의 사용 사례가 다른 사용 사례를 사용할 수 있음을 나타냅니다. 이 관계에는 확장 지점이라는 것이 있습니다. 예를 들어, 도서관 관리 시스템에서 책을 반납하는 경우 벌금(시간 초과 등)이 발생할 수 있습니다.
둘 사이의 연결은 둘 다 사용 사례 사이의 관계이며 둘 다 하나의 사용 사례에서 다른 사용 사례를 사용한다는 것을 의미합니다. 둘 사이의 차이점은 포함은 다른 UC가 확실히 사용된다는 것을 의미하는 반면 확장은 확장을 판단해야 한다는 것입니다. 사용 여부를 결정하기 전의 포인트
chap04 도메인 모델
4.1 소개
핵심 개념: 시스템 사용자 문제 영역에 있는 것들
4.2 문제 영역에 있는 것들
문제 도메인은 새로운 시스템에 포함되는 사용자 비즈니스의 특정 영역을 의미합니다.
도메인 클래스 또는 엔터티는 최종 사용자가 스튜디오에서 작업하는 데 필요한 것입니다. 시스템 문제 도메인에서는 이를 종종 "사물"이라고 합니다.
예를 들어
제품, 주문, 고객
4.2.1 문제 영역의 사물을 정의하는 방법 1 - 브레인스토밍 방법
1. 사용자와 사용 사례 세트를 식별합니다.
2. 유스 케이스 실행과 관련된 사항, 즉 시스템이 정보를 캡처해야 하는 사항을 식별하기 위해 사용자와 브레인스토밍합니다.
3. 사물 유형(범주)을 사용하여 잠재적인 사물에 대해 체계적으로 질문합니다. 예: 유형의 사물에 대한 정보를 저장합니까? 관련 장소가 있나요? 누구의 역할을 기억해야 합니까?
4. 브레인스토밍 목록을 확장하기 위해 다양한 사용자 및 이해관계자와 계속 협력합니다.
5. 결과를 결합하고 중복 항목을 제거한 후 초기 목록을 작성합니다.
4.2.2 문제 영역의 사물을 정의하는 방법 2 - 명사 기술
사용자가 언급한 모든 명사를 나열합니다. 이벤트, 사용 사례 또는 행위자를 설명하는 데 사용되는 명사는 잠재적인 것입니다.
단계
1. 사용 사례, 행위자 및 시스템에 대한 기타 정보(입력 및 출력 포함)를 사용하여 모든 명사를 식별합니다.
2. 기존 시스템, 현재 절차, 현재 보고서나 양식의 기타 정보를 사용하여 필요한 정보의 항목이나 범주를 추가합니다. 이러한 항목 중 일부는 추가 항목일 수 있고 일부는 이미 식별한 항목에 대한 보다 구체적인 정보(속성이라고 함)일 수 있습니다. 목록을 구체화한 다음 탐색하려는 가설이나 질문을 기록하세요.
3. 이 명사 목록이 작성되면 이를 구체화해야 합니다.
각 명사에 대해 다음 질문을 하면 해당 명사가 포함되어야 하는지 결정하는 데 도움이 됩니다.
시스템이 알아야 할 고유한 것이 있습니까?
내가 개발 중인 시스템의 범위 내에 있습니까?
시스템이 위 항목 중 두 개 이상을 기억해야 합니까?
각 명사에 대해 다음 질문을 통해 제외 여부를 결정하세요.
내가 확인한 다른 것과 정말 동의어인가요?
내가 식별한 다른 정보를 기반으로 한 시스템 출력일까요?
그것은 실제로 내가 식별한 다른 정보를 기록하는 입력에 불과합니까?
각 명사에 대해 다음 질문을 하여 해당 명사를 연구해야 할지 결정하세요.
내가 확인한 다른 것들에 대한 구체적인 정보(재산)일 가능성이 있나요?
가정이 바뀌면 필요할 수도 있나요?
4. 식별된 모든 명사의 마스터 목록을 만든 다음 각 명사를 포함, 제외 또는 추가 연구해야 하는지 여부를 나타냅니다.
5. 사용자, 이해관계자 및 팀 구성원과 함께 목록을 검토한 후 문제 영역의 항목 목록을 구체화합니다.
예
4.2.3 사물의 속성
대부분의 시스템은 속성이라는 트랜잭션에 대한 특정 정보를 저장합니다.
무언가를 고유하게 식별하는 속성을 식별자 또는 키워드(키/코드)라고 합니다.
복합 속성은 주소, 성명 등과 같은 여러 관련 속성으로 구성됩니다.
4.2.4 사물 간의 관계
연관이란 특정 사물 사이에서 자연적으로 발생하는 관계를 말합니다.
UML에는 대략 4가지 유형의 사물 간 관계가 있습니다.
협회
세대 일반화
의존성 의존성
구현하다
관련 세부정보
이름이 있어요
방향이 있고 화살표가 가리키는 것은 다른 것을 볼 수 없다.
예를 들어 A->B를 A가 B에 종속된다고 합니다.
연합은 다중성, 즉 한 가지와 다른 것 사이의 양적 관계입니다.
예
연결 간에는 카디널리티 제한이 있습니다.
관련 요소
협회는 여러 가지 유형의 사물로 구성되며 이러한 사물의 수는 협회의 개수입니다.
고객과 주문, 이진 관계
비슷한 것들끼리의 연관, 하나의 요소
세 가지 이상의 서로 다른 유형의 사물이 관련되어 있습니다.
4.3 엔터티-연락처 다이어그램
데이터베이스 모델링을 위한 모델입니다.
직사각형은 엔터티를 나타내고, 직사각형을 연결하는 선은 엔터티 간의 연결을 나타냅니다.
상징적 표현
수직선만 잘려서 하나만 있음을 나타냅니다.
수직선이 잘려져 원으로 표시되어 0 또는 1을 나타냅니다.
십자선이 있는 원은 0 이상을 나타냅니다.
수직선이 잘리고 분기된 선은 하나 이상을 나타냅니다.
숫자에 해당하는 방향은 unsigned에서 signed로 입니다.
엔터티의 속성 중 첫 번째 줄에는 기본코드(식별자)가 들어가고, PK가 표시되어 기본코드임을 나타냅니다.
예
한 고객은 0부터 여러 주문에 해당하고, 한 주문은 단 한 명의 고객에 해당합니다.
4.4 도메인 모델 클래스 다이어그램
문제의 클래스를 도메인 클래스라고 합니다.
UML에서는 클래스 다이어그램을 사용하여 시스템의 객체 클래스를 표시합니다.
도메인 모델 클래스 다이어그램
사용자의 문제 영역에 있는 내용을 표시하는 데 사용됩니다.
디자인 클래스 다이어그램
디자인을 위해
상징적 표현
클래스 다이어그램에서 직사각형은 클래스를 나타내고, 직사각형을 연결하는 직선은 클래스 간의 관계를 나타냅니다.
직사각형은 두 부분으로 구성됩니다(도메인 모델 클래스 다이어그램, 디자인 클래스 다이어그램은 클래스 이름, 속성, 메서드의 세 부분으로 구성됨). 위쪽은 클래스 이름이고 아래쪽은 클래스의 특성입니다.
클래스 이름과 속성 이름은 카멜 케이스 명명을 사용합니다. 클래스 이름의 첫 글자는 대문자로, 속성 이름의 첫 글자는 소문자로 표시됩니다.
4.4.1 도메인 모델 클래스 다이어그램 표기법
다중성 기호
엔터티 관계 다이어그램의 다중성과 유사하게 클래스 인스턴스 간의 관계 수를 나타냅니다.
예
여기서의 다중성은 엔터티 관계 다이어그램의 매핑 카디널리티와 유사합니다.
특정 도메인 클래스 다이어그램 응용 프로그램
이것은 학생 코스 선택을 위한 도메인 모델 클래스 다이어그램입니다. 코스는 0개에서 여러 개의 섹션을 가질 수 있지만 섹션은 하나의 코스에만 속할 수 있고 속해야 하며 섹션은 다대다 관계를 가질 수 있습니다. 0, 점선으로 표시된 학생과 코스 사이에 등급 속성이 있는 연관 클래스가 있습니다.
4.4.2 객체 클래스에 관한 더 복잡한 문제
도메인 클래스에는 세 가지 유형의 관계가 있습니다.
협회
일반화/전문화 생성
일반화/전문화 관계의 기본은 사람들이 유사점과 차이점을 기준으로 사물을 분류한다는 것입니다.
일반화/전문화 관계는 이러한 것들을 보다 일반적인 것에서 보다 구체적인 것으로 구조화하거나 순서를 지정하는 데 사용됩니다.
계층 구조의 각 클래스 위에는 슈퍼클래스라고 하는 보다 일반적인 클래스가 있을 수 있습니다.
클래스 아래에는 하위 클래스라고 하는 보다 특수한 클래스가 있을 수 있습니다.
상속을 통해 하위 클래스는 상위 클래스의 특성을 공유할 수 있습니다.
삼각형 화살표를 사용하여 슈퍼 클래스를 가리킵니다.
예
추상 클래스에 레이블을 지정하려면 이탤릭체를 사용하세요.
추상 클래스는 인스턴스화할 수 없으며 상속만 가능합니다.
인스턴스 객체를 가질 수 있는 클래스인 구체적인 클래스도 있습니다.
슈퍼클래스는 때때로 구체적이거나 추상적입니다.
전체 부분
전역/부분 관계는 클래스와 이 클래스에 포함된 다른 클래스 간의 관계를 표현하는 데 사용됩니다.
중합
집계 관계에서는 구성 요소가 독립적으로 존재할 수 있습니다.
빈 다이아몬드를 사용하여 표현
콤비네이션
결합된 관계에서는 각 부분이 일단 연결되면 독립적으로 존재할 수 없습니다.
솔리드 다이아몬드를 사용하여 표현
Chapter05 요구사항 모델의 확장
5.2 사용 사례 설명
사용 사례 설명은 각 사용 사례의 세부정보를 설명합니다.
간단한 사용 사례 설명
단일 시나리오 및 더 적은 예외에 적합
예
완전히 개발된 사용 사례 설명
좀 더 복잡한 사용 사례의 경우 완전히 확장된 사용 사례 설명이 필요합니다.
표준 템플릿
사용 사례 이름
사용 사례 시나리오
트리거 이벤트
빠른 설명
참가자들
이와 관련된 기타 사용 사례 및 연결 방법
이해관계자
전제조건
전제조건은 이미 존재해야 하는 객체, 사용 가능해야 하는 정보, 사용 사례가 시작되기 전 행위자에 대한 조건 등을 포함하여 사용 사례가 시작될 때 시스템 상태를 결정합니다.
후속 조건
사후 조건은 사용 사례가 완료되었을 때 무엇이 참이어야 하는지를 결정합니다. 가장 중요한 것은 사용 사례가 생성하거나 업데이트하는 새로운 객체와 객체가 어떻게 관련되어야 하는지를 나타냅니다.
활동 흐름
참여자(사용자)와 시스템을 포함한 활동 흐름
비정상적인 상황
각 사용 사례의 활동 흐름은 사용 사례를 호출하는 행위자에 따라 매우 다를 수 있습니다. 다양한 활동 흐름을 시나리오(사용 사례 인스턴스라고도 함)라고 합니다.
5.3 유스케이스 활동 다이어그램
유스 케이스를 기록하는 한 가지 방법은 활동 다이어그램을 사용하는 것입니다. 우리는 2장에서 워크플로를 구축하기 위해 활동 다이어그램을 사용하는 방법을 배웠습니다. 여기서는 유스 케이스의 활동 흐름을 기록하기 위해 활동 다이어그램을 사용할 것입니다.
예
이 활동 다이어그램은 고객 등록 사용 사례 등록의 활동 흐름을 보여줍니다.
5.4 시스템 시퀀스 다이어그램 SSD
시스템 시퀀스 다이어그램은 자동화 시스템 안팎으로의 정보 흐름을 설명하는 데 사용됩니다.
인간 기호를 사용하여 유스 케이스 액터를 나타내고 직사각형 테두리를 사용하여 자동화 경계를 나타냅니다.
직사각형은 자동 시스템을 나타내는 시스템(콜론 포함)으로 표시됩니다.
참여자와 시스템 아래에는 라이프라인이라는 점선이 있는데, 이는 참여자와 시스템의 생명주기를 나타내며, 시간은 하향식 방향으로 흐른다.
참가자와 시스템의 생명선 간에 메시지를 보내고 받습니다.
메시지 전송은 참가자에서 시스템으로의 방향과 함께 실선으로 표시됩니다.
수신된 메시지는 시스템에서 참가자 방향으로 점선으로 표시됩니다.
메시지의 완전한 상징적 표현
(*)[True/False 조건] 반환값:=메시지 이름(파라미터 목록)
*는 루프를 나타냅니다.
[]는 참과 거짓 조건을 의미하며, 해당 내용이 참이면 메시지가 전송되고, 그렇지 않으면 전송되지 않습니다.
메시지 이름은 보낸 메시지에 대한 설명입니다.
매개변수 목록은 전달될 정보입니다.
또한 몇 가지 대체 프레임워크가 있습니다.
루프 변경
여러 메시지가 루프로 전송 및 수신되는 경우 대체 프레임워크를 사용하는 것이 더 나을 수 있습니다.
대체 프레임은 직사각형 프레임을 사용하여 루프할 부분을 선택하고 왼쪽 상단의 모든 항목에 루프를 표현하는 것입니다.
선택 변경
선택의 대체 프레임은 직사각형 프레임을 사용하여 선택 영역을 선택하고 점선을 사용하여 전송된 메시지의 마지막 부분에 각각 레이블을 지정합니다.
5.4.2 SSD 개발
1. 입력된 메시지를 확인하세요
2. 외부에서 시스템으로 전달되는 정보를 설명하기 위해 메시지 기호를 사용합니다.
3. 루프 및 참/거짓 조건을 포함하여 입력 메시지에 특정 조건을 추가합니다.
4. 반송 메시지 확인 및 추가
5.5 상태 머신 다이어그램 상태 머신 다이어그램
객체의 상태는 수명 동안 특정 조건이 충족되거나, 특정 작업이 수행되거나, 일부 이벤트가 기다리는 동안 발생하는 조건입니다.
상태 전이(State Transition)는 한 상태에서 다른 상태로 이동하는 객체의 활동입니다.
상태 전이 기능
변환명(파라미터,...)[판정 조건]/동작 설명
작업 표현은 전환이 완료되고 개체가 대상 상태에 도달하기 전에 발생해야 하는 일부 프로세스를 나타냅니다.
조건은 전환에 대한 한정자 또는 테스트이며 전환이 트리거되기 전에 충족되어야 하는 참/거짓 조건일 뿐입니다.
5.5.1 복합 상태와 동시 상태
동시에 여러 상태에 있는 것을 동시성 또는 동시 상태라고 합니다.
활동 다이어그램과 유사한 동시 경로를 사용하여 표현되는 경로는 상호 연결된 상태 전환의 순서가 지정된 집합입니다.
다른 상위 수준 상태 내에 상태를 중첩합니다. 이러한 상위 수준 상태를 복합 상태라고 합니다.
복합 상태는 하위 수준 상태에 중첩된 상위 수준 상태로 표현됩니다.
예
프린터가 켜져 있으면(복합 상태) 두 개의 동시 경로, 즉 용지함 부분과 인쇄 부분이 있습니다. 두 부분은 켜짐 버튼을 누르면 켜지고 꺼짐 버튼을 누르면 독립적입니다. 누르면 꺼집니다. 제한이 없습니다.
5.5.2 상태 머신 다이어그램 개발 규칙
클래스 다이어그램을 보고 상태가 필요할 수 있는 클래스를 선택하세요.
그룹에서 선택한 각 클래스에 대해 결정할 수 있는 모든 상태 조건을 나열하십시오.
객체가 식별된 상태를 벗어나게 하는 전환을 식별하여 상태 머신 다이어그램 조각 구축을 시작합니다.
이러한 상태 전환 조합을 올바른 순서로 정렬하세요.
이러한 경로를 확인하고 독립적인 동시 경로를 찾으세요.
다른 전환 찾기
적절한 메시지 이벤트, 보호 조건 및 작업 표현으로 각 전환을 확장합니다.
각 상태 머신 다이어그램 확인 및 테스트
5.6 수요 모델의 통합
다양한 수요모델 간의 관계
사용 사례 다이어그램
사용 사례 설명
활동 다이어그램
SSD
도메인 모델 클래스 다이어그램
상태 머신 다이어그램
관계는 다음 그림으로 설명됩니다.
화살표는 종속 항목에서 종속 항목 방향을 가리킵니다.
실선은 기본 종속성을 나타내고 점선은 보조 종속성을 나타내며 일부 화살표는 양방향이므로 상호 영향을 나타냅니다.
chap06 디자인의 기본 포인트와 디자인 활동
6.1 소개
분석 단계에서는 시스템이 수행하는 작업(예: 요구 사항)을 주로 논의하고, 설계 단계에서는 시스템이 이러한 요구 사항을 달성하는 방법을 주로 논의합니다.
시스템 설계의 입력과 출력은 시스템의 입력과 출력이 아니다. 시스템 설계의 입력은 시스템 분석의 결과, 즉 요구사항과 관련 모델인 반면, 시스템 설계의 출력은 보다 상세한 솔루션이다.
6.2 디자인 요소
6.2.1 시스템 설계란 무엇인가?
시스템 설계는 최종 솔루션의 구성요소를 구축 청사진으로 정의, 구성 및 구축하기 위한 목적으로 시스템 분석과 구현을 연결하는 프로세스입니다.
6.2.2 주요 구성 요소 및 설계 수준
주요 구성품
환경 디자인
시스템을 함께 연결하는 네트워크, 하드웨어 등을 설명합니다.
애플리케이션 디자인
컴퓨터 프로그램
사용자 인터페이스 디자인
입력 및 출력에 대해 정의된 화면, 보고서 및 컨트롤
데이터베이스 디자인
데이터베이스 구조
시스템 인터페이스 디자인
다른 시스템과의 통신에 대해 설명합니다.
보안 및 제어 설계
두 가지 수준
건축 디자인
시스템 전체 구조의 폭넓은 설계인 솔루션의 전체 프레임워크와 형태를 명확히 합니다.
종합설계 또는 개념설계라고도 한다.
세부 디자인
특정 프로그래밍 세부정보 포함
예
사용 사례별 디자인
데이터베이스 디자인
사용자 인터페이스 및 시스템 인터페이스 디자인
보안 및 제어 설계
6.3 시스템 설계의 입출력
시스템 분석을 통해 얻은 분석 모델, 문서 등의 정보를 솔루션 시스템을 대표하는 모델로 변환
분석모델
클래스 다이어그램
사용 사례 다이어그램 UCD
시스템 시퀀스 다이어그램 SSD
사용 사례 설명
상태 머신 다이어그램
활동 다이어그램
디자인 모델
패키지 맵
노드 및 위치 그래프
디자인 클래스 다이어그램
흐름도
데이터베이스 스키마
사용자 및 시스템 인터페이스
시스템 보안 통제
협업 다이어그램
6.4 설계 활동
디자인 활동은 위의 6가지 구성 요소의 디자인입니다. 각 디자인 활동에는 해당하는 핵심 문제가 있습니다.
환경 디자인
소프트웨어가 실행될 환경과 다양한 옵션을 모두 자세히 설명했습니까?
애플리케이션 아키텍처 및 소프트웨어 설계
소프트웨어의 모든 요소와 각 사용 사례가 어떻게 수행되는지 자세히 설명했습니까?
사용자 인터페이스 디자인
이 시스템이 조직 내부 및 외부의 다른 모든 시스템과 어떻게 통신하는지 자세히 설명했습니까?
시스템 인터페이스 디자인
사용자가 모든 작업(사용 사례)을 수행하기 위해 시스템과 상호 작용하는 방법을 자세히 설명했습니까?
데이터베이스 디자인
모든 스키마 요소를 포함하여 모든 정보 저장 요구 사항을 지정했습니까?
보안 및 제어 설계
시스템과 데이터를 안전하게 보호하는 데 필요한 모든 요소를 자세히 설명했습니까?
6.4.1 디자인 환경
환경은 소프트웨어 애플리케이션을 지원하는 데 필요한 모든 기술입니다.
서버, 데스크톱 컴퓨터
모바일 장치, 운영 체제
의사소통 능력, 입출력 능력
2장에서는 이를 기술 아키텍처라고 불렀습니다.
6.4.2 디자인 애플리케이션 아키텍처 및 소프트웨어
시스템을 하위 시스템으로 나누기
소프트웨어 아키텍처 정의(아키텍처 설계)
MVC 3계층 아키텍처 등
각 사용 사례의 세부 설계
디자인 클래스 다이어그램
흐름도
상태 머신 다이어그램
6.4.3 사용자 인터페이스 디자인
대화상자 디자인은 요구사항에서 시작됩니다
디자인은 화면 레이아웃, 모양과 느낌, 탐색, 사용자 경험을 추가합니다.
다양한 장치에 대해 다양한 인터페이스 디자인
6.4.4 디자인 시스템 인터페이스
정보 시스템은 다른 많은 내부 및 외부 시스템과 상호 작용합니다.
시스템 인터페이스는 다양한 방식으로 다른 시스템에 연결됩니다.
6.4.5 설계 데이터베이스
도메인 모델 클래스 다이어그램(또는 ERD)으로 시작
데이터베이스 구조 선택
설계 아키텍처(분산 등)
데이터베이스 스키마 설계
테이블, 속성 열
설계 참조 무결성 제약 조건
6.4.6 설계 보안 및 시스템 제어
목적은 인터넷과 무선 세계에서 중요한 조직의 자산을 보호하는 것입니다.
사용자 인터페이스 컨트롤
애플리케이션 제어
데이터베이스 제어
네트워크 제어
6.5 환경을 디자인하는 방법
온프레미스 설계
온프레미스 소프트웨어 시스템에는 두 가지 유형이 있습니다.
독립형 소프트웨어 시스템
네트워크 없이 장치에서 실행
웹 기반 내부 시스템
하드웨어 배포: LAN
클라이언트-서버 아키텍처
데스크탑 애플리케이션 시스템(클라이언트-서버)
브라우저 기반 응용 시스템(브라우저-서버)
하이퍼텍스트 마크업 언어를 페이지로 사용
TCP/IP 프로토콜을 전송 프로토콜로 사용
3계층 클라이언트/서버 아키텍처
소프트웨어를 설계하는 효과적인 방법은 사용자 인터페이스와 비즈니스 논리 계층을 분리하고, 비즈니스 논리 계층과 데이터 액세스 계층을 분리하는 것입니다. 이러한 프로그램 설계 방법을 3계층 아키텍처라고 합니다. 기본 아이디어는 소프트웨어를 세 개의 레이어로 나누는 것입니다.
뷰 레이어: 사용자 입력을 수신하고 이를 형식화된 출력으로 처리하는 역할을 담당합니다.
논리 계층/도메인 계층 도메인 계층: 비즈니스 또는 처리 프로세스를 구현하는 규칙 및 절차를 담당합니다.
데이터 계층: 일반적으로 하나 이상의 데이터베이스에 존재하는 저장된 데이터를 관리하는 역할을 담당합니다.
여러 계층을 단일 컴퓨터에서 실행하거나 각 계층을 별도의 컴퓨터에서 운영할 수 있습니다. 계층의 기능을 분할하거나 중복 컴퓨터 구현에 로드 밸런싱을 구현하여 복잡한 계층을 2~3개에 걸쳐 배포할 수 있습니다.
또 다른 디자인 아이디어는 MVC, 즉 Model-View-Controller입니다.
외부 배포 설계
중요한 질문은 다음과 같습니다
인터넷 배포를 위한 구성
데이터 보호는 HTTPS(Hypertext Transfer Protocol Security)를 사용하여 구현됩니다. HTTPS 프로토콜로 제공되는 웹 페이지는 HTTP보다 더 안전한 암호화된 형식으로 전송됩니다.
다중 계층 서버 구조와 로드 밸런싱, CDN(콘텐츠 전송 네트워크)을 사용하여 성능 향상
다중 계층 서버 구조에는 응용 프로그램 서버와 데이터베이스 서버가 포함됩니다.
로드 밸런싱 컴퓨터를 통해 요청이 다른 데이터 센터 서버로 전송됩니다.
일부 정적 사진이나 비디오에 액세스할 때 독립적인 CDN을 사용하여 전송할 수 있습니다.
인터넷 배포를 위한 호스팅 옵션
장소 대여
고객이 서버 컴퓨터를 배치할 수 있는 안전한 데이터 센터를 제공합니다. 물리적, 보안적, 복잡한 데이터 센터 비용이 없다는 것이 장점입니다.
관리형 서비스
운영 체제, 네트워크 서버, 데이터베이스 서버 등의 관리를 포함한 추가 서비스를 제공합니다. 서버 시스템 및 시스템 소프트웨어를 관리하기 위해 직원을 고용할 필요가 없다는 장점이 있습니다.
가상 서버
고객은 고정된 크기의 가상 서버를 임대할 수 있습니다.
클라우드 컴퓨팅
고객은 필요하고 사용하는 컴퓨팅 용량만 구매하면 되며, 컴퓨팅 용량이 증가하면 클라우드가 자동으로 더 많은 용량을 제공하므로 불필요한 용량을 구매할 필요가 없으므로 비용을 절감할 수 있습니다.
모든 대안에는 특정 수준의 시스템 가용성을 보장하기 위해 기업과 호스팅 회사 간의 계약의 일부인 서비스 수준 계약(서비스 수준 계약)이 있습니다.
인터넷용으로 구축된 고객 장치의 다양성
컴퓨터
중형 태블릿 장치
소형 모바일 장치
원격 및 분산 환경을 위한 설계
VPN(가상 사설망)을 통한 원격 배포
VPN은 인터넷과 같은 공용 네트워크에 구축된 네트워크입니다. 개인 그룹을 위한 안전하고 연결 가능한 네트워크를 제공합니다.
chap07 사용자 인터페이스와 시스템 인터페이스 디자인
7.2 사용자 인터페이스 및 시스템 인터페이스
사용자 인터페이스에는 직접적인 사용자 개입이 필요한 입력 및 출력이 포함되어 있습니다.
시스템 인터페이스에는 최소한의 수동 입력 및 출력이 필요합니다.
7.3 사용자 인터페이스 이해
사용자 인터페이스에는 세 가지 구성 요소가 있습니다.
물리적 의미: 사무실 책상과 의자, 램프, 키보드, 마우스, 터치 스크린
인지된 의미: 색상, 모양, 질감, 글꼴, 창, 메뉴, 버튼
개념적 의미: 고객, 참가자, 주문, 운송, 피드백
사용자 인터페이스의 디자인 관점은 사용자 중심으로, 인간과 컴퓨터 사이의 상호작용(Human-Computer Interaction)을 강조합니다.
인간-컴퓨터 상호작용(Human-Computer Interaction)은 사용자와 컴퓨터 시스템의 상호작용의 효율성과 효과성, 인간 중심의 입출력 기술, 사용자 인터페이스의 심리적 측면을 연구하는 분야이다.
사용자 중심 디자인의 세 가지 기본 원칙
사용자와 작업에 조기에 집중
시스템을 평가하여 유용성을 확인하세요.
반복 개발 사용
인간-컴퓨터 상호작용에 대한 은유
은유는 사용자 인터페이스 기능과 사용자에게 친숙한 물리적 개체 간의 유사성입니다.
은유는 다음과 같은 상황에서 사용자 인터페이스 디자인에 널리 사용됩니다.
직접적인 조작
디스플레이에서 직접 물리적 개체 또는 이를 나타내는 개체를 조작합니다.
예: 사용자가 폴더를 휴지통으로 드래그합니다.
데스크탑 은유
도구 아이콘 세트로 둘러싸인 중앙의 큰 빈 작업 공간을 사용하여 시각적 디스플레이를 다양한 영역으로 구성합니다.
예: Windows 데스크톱
문서 비유
페이지나 테이블과 같은 데이터 표시
예: 사용자 지침 문서 등
대화식 은유
사용자와 컴퓨터는 텍스트, 음성 또는 기타 도구를 사용하여 통신이나 대화에 참여하여 작업을 완료합니다.
예: cmd 창
처음 세 개는 사용자와 상호 작용하는 개체를 강조하고, 대화형 비유는 사용자와 컴퓨터 사이에서 발생하는 통신을 강조합니다.
7.4 사용자 인터페이스 디자인 개념
7.4.1 신속성과 가시성
지시형은 해당 성능을 반영하는 컨트롤의 모양을 나타냅니다.
가시성은 컨트롤이 표시됨을 의미합니다.
7.4.2 일관성
7.4.3 바로가기
7.4.4 피드백
7.4.5 완전한 대화
7.4.6 오류 처리
7.4.7 실행 취소 작업
7.4.8 단기기억의 부담을 줄인다
7.5 분석부터 사용자 인터페이스 디자인까지
7.5.1 사용 사례 및 메뉴 계층
메뉴는 사용자 인터페이스에서 수많은 관련 사용 사례나 대화를 구성하는 방법입니다.
디자이너는 사용 사례 수를 기반으로 메뉴 계층 구조를 추정해야 합니다.
메뉴 수준에는 일반적으로 5~10개의 옵션이 포함됩니다.
7.5.2 대화와 스토리보드
사용자에게 필요한 대화를 녹음해야 함
스토리보드: 대화에 이 일련의 화면 스케치를 표시합니다.
7.6 사용자 인터페이스 디자인
7.6.1 양식 및 테이블 디자인 지침
인터페이스 레이아웃 및 형식
일관성, 라벨 및 제목, 배포 및 순서, 글꼴 및 색상
데이터 투입
텍스트박스, 리스트박스, 콤보박스, 라디오버튼, 체크박스
지도 및 지원 통제
최소화, 최대화, 닫기, 스크롤 막대, 크기 조정
7.6.2 브라우저 인터페이스에 대한 추가 지침
일관성
CSS(Cascading Style Sheets) - 웹 사이트 디자이너가 항상 동일하게 보이는 페이지 부분과 작업이나 대상에 따라 달라지는 부분을 지정할 수 있도록 하는 웹 페이지 코딩 표준입니다.
성능 고려사항
네트워크 연결, 전송되는 정보의 양, 전송되는 정보 유형에 민감합니다.
사진, 비디오 및 사운드
호환성 문제가 있을 겁니다
특별사용자(장애인)
보조 기술 – 장애인의 특별한 요구에 맞게 사용자 인터페이스를 조정하는 소프트웨어(예: 텍스트 음성 변환 및 음성 인식 도구)
7.6.3 모바일 장치 인터페이스에 대한 추가 지침
모바일 장치용 사용자 인터페이스 디자인의 과제
작은 화면, 키패드 및 터치 스크린, 제한된 네트워크 용량, 애플리케이션 설계 지침 및 툴킷
7.7 시스템 인터페이스 결정
시스템 인터페이스는 사용자 개입이 전혀 또는 거의 필요하지 않은 입력 및 출력으로 광범위하게 정의됩니다.
다음과 같은 카테고리로 나누어집니다.
다른 시스템의 입력 및 출력
XML(Extensible Markup Language)은 전자 데이터 교환 및 시스템 간 통신에 사용될 수 있습니다.
XML은 HTML과 비교하여 사용자 정의 데이터 구조 삽입을 구현합니다.
고도로 자동화된 입력 및 출력
외부 데이터베이스의 입력 및 출력
7.8 설계 시스템 입력
7.8.1 자동 입력 장치
모든 데이터 입력의 주요 목적은 오류 없는 데이터를 시스템에 제공하거나 업데이트하는 것입니다. 가장 중요한 것은 오류를 최대한 방지하는 것입니다.
자동 입력 장치 사용
사람의 개입을 최대한 피하세요
스프레드시트에서 입력 정보를 얻을 수 있는 경우 데이터를 다시 입력하지 않고 스프레드시트를 사용하십시오.
데이터 확인 및 수정
7.8.2 시스템 입력 세부사항 정의
7.9 설계 시스템 출력
설계 보고서, 명세서 및 반환 문서
보고서 유형
상세 보고서: 비즈니스 프로세스에 대한 자세한 정보가 포함되어 있습니다.
요약 보고서: 이 유형의 보고서는 단계별 활동을 요약하는 데 사용됩니다.
비정상 보고서: 거래 또는 운영 결과가 비정상인 경우 생성됩니다.
경영진 보고: 전반적인 상태 및 운영 평가
내부 산출물은 조직이나 단위의 내부 사용을 위해 생성됩니다. 앞에서 설명한 보고서는 조직 외부 구성원이 사용하기 위해 생성한 것입니다. 외부인을 위해 생성된 공식적인 업무문서이기 때문에 더 높은 퀄리티를 요구하기 때문에
사용자에게 제공되는 출력은 나중에 시스템에 입력으로 사용할 수 있는 부분으로 구성됩니다. 확인하다.
전자 명세서
그래픽 및 멀티미디어 프레젠테이션
chap08 시스템 개발 방법
8.2 시스템 개발 생명주기
8.2.1 시스템 개발 수명주기의 전통적인 예측 방법
예측방법은 조직개발 프로젝트를 미리 계획하고, 그 계획에 따라 새로운 정보시스템을 개발할 수 있는 방법이다.
요구사항: 프로젝트를 사전에 계획할 수 있고, 계획에 따라 정보 시스템을 개발할 수 있으며, 요구사항을 잘 이해하고, 기술적 위험이 낮다고 가정합니다.
폭포 모델
프로젝트에서는 수명주기의 6단계가 한 단계에서 다음 단계로 진행되며 단계는 순차적입니다.
기존 폭포수 모델에서는 SDLC의 다양한 단계 간에 중복과 반복이 없습니다.
척도의 상대적으로 오른쪽에 있는 모델은 개선된 폭포 모델입니다.
개선된 폭포수 모델은 여전히 예측된 개발 단계의 순서를 유지하지만 이러한 단계는 서로 겹치고 영향을 미치며 의존합니다.
유연성이 향상되지만 여전히 예측 계획 및 순차적 단계를 가정합니다.
8.2.2 시스템 개발 수명주기에 대한 적응형 접근 방식
요구 사항(요구 사항)이 불분명하고 종종 여러 번의 반복이 필요한 경우 적응 모델을 개발에 사용할 수 있습니다.
프로젝트는 보다 유연해야 하며 개발 프로세스 중 변화하는 요구에 적응해야 합니다. 수요는 불확실하고 기술적 위험은 높습니다.
나선형 모델
눈금의 오른쪽 끝에서 상대적으로 멀리 떨어져 있음
프로젝트가 완료될 때까지 중심에서 시작하여 계속해서 바깥쪽으로 확장하는 SDLC를 나선형으로 설명합니다.
스테이지 당 1회 이상
반복 모델
1장의 개발 방법과 유사하게, 표의 행은 개발 활동이고 열은 반복입니다.
각 반복에는 여러 단계가 포함되어 있으며 각 단계는 한 번에 완료되지 않지만 후속 반복에서 지속적으로 개선됩니다.
적응형 접근 방식에 대한 추가 개념
점진적인 개발
기본 개념은 시스템이 작은 단위로 구축되어 유기적으로 성장한다는 것입니다.
프로젝트 기간 동안 시스템은 단계적으로 구현되고 부분적으로 배포됩니다.
장점은 사용자가 시스템의 일부를 빠르게 얻을 수 있어 비즈니스를 가능한 한 빨리 시작할 수 있다는 것입니다.
걷는 해골
완전한 시스템 구조를 구축하되 기본 기능만 제공하는 초기 접근 방식
먼저, 새로운 시스템의 전체 구현 프로세스에 대한 "골격"을 처음부터 끝까지 제공한 다음 후속 반복을 사용하여 뼈대를 채웁니다.
프로젝트에서는 극단적인 선택이 아닌 경우가 많습니다.
8.3 지원 단계
예측 접근 방식 SDLC에는 이러한 지원 단계가 포함됩니다.
적응형 접근 방식은 지원 단계를 완전한 독립형 프로젝트로 처리합니다.
지원 단계에서는 세 가지 주요 활동이 발생합니다.
유지관리 시스템
시스템 강화
사용자 지원
8.4 방법, 모델, 도구 및 기법
시스템 개발 방법
방법의 범위가 가장 크다.
방법론에는 프로젝트의 모든 측면을 모델링하는 것을 포함하여 활동과 작업을 완료하기 위한 일련의 기술이 포함됩니다.
모델
모델은 관련 부분에만 초점을 맞춰 복잡한 개념을 이해할 수 있도록 현실 세계의 특정 측면을 추상적으로 표현한 것입니다.
각 모델은 서로 다른 정보를 강조합니다.
우리는 이미 ER 다이어그램, 유스 케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램 등 일부 모델을 접했습니다.
도구
소프트웨어 지원
기술
학습을 통해 습득한
8.5 소프트웨어 구성 및 모델링의 두 가지 방법
8.5.1 구조화된 접근방식
구조화된 방법은 프로세스에 초점을 맞추고 데이터 흐름에 중점을 둡니다. 시스템은 데이터 흐름과 상호 작용하는 프로세스의 모음이라고 가정합니다.
구조화된 방법은 SDLC 예측 방법과 동일한 전통적인 방법입니다.
구조화된 분석
데이터 흐름도를 이용한 모델링
ER 다이어그램도 사용됩니다.
구조화된 디자인
구조 다이어그램을 이용한 프로그램 설계
낮은 결합도와 높은 응집력이 필요함
결합도가 낮다는 것은 서로 다른 모듈이 다른 모듈과 최대한 독립적이므로 하나의 모듈을 수정해도 다른 모듈의 작동에 영향을 미치지 않는다는 것을 의미합니다.
응집력이 높다는 것은 각 모듈이 명확한 작업을 구현한다는 것을 의미합니다.
구조화된 프로그래밍
시작, 끝 및 세 가지 구조(순서, 선택, 순환)가 포함됩니다.
하향식 프로그래밍/모듈형 설계
8.5.2 객체 지향 접근 방식
객체 지향 접근 방식은 시스템을 특정 상호 작용을 수행하기 위해 함께 작동하는 객체의 모음으로 간주합니다.
객체는 메시지에 응답하는 시스템의 사물입니다.
객체 지향 분석
새로운 시스템에서 사용 사례와 개체 집합(클래스)을 식별하고 정의하는 프로세스
객체지향 디자인
사람 및 장치와 통신하는 데 필요한 모든 유형의 개체를 정의하고 작업을 완료하기 위해 상호 작용하는 방법을 보여줍니다.
클래스 다이어그램, 사용 사례 다이어그램 등의 모델 사용
객체 지향 프로그래밍
실제 클래스와 클래스의 각 개체의 역할을 정의하는 문을 작성합니다.
시퀀스 다이어그램, 디자인 클래스 다이어그램 등의 모델 사용
8.6 애자일 개발
미지의, 급변하는 환경 속에서 진행되는 개발 활동
8.6.1 애자일 개발 이론과 가치
핵심이론
계획을 따르기보다 변화에 대응하는 데 집중
프로세스와 도구보다는 개인과 상호작용에 가치를 둡니다.
포괄적인 문서보다 가치 있는 작업 소프트웨어
계약 협상보다 고객 협업에 집중
애자일 프로젝트의 개념 설명: 혼돈
그것은 혼돈과 질서입니다. 처음 두 가지 핵심 이론, 즉 집단 가치에 대한 개인 가치의 지배는 혼돈의 원인이며 이러한 혼돈은 유연성을 높여 처리할 수 있습니다. 예측할 수 없는 개발 과정에서 혼란은 불가피합니다. 개발자는 혼란을 받아들여야 하지만 때로는 프로젝트에 질서와 구조를 추가하는 데 도움이 되는 다른 방법과 기술을 사용해야 할 때도 있습니다.
쉽게 말하면 전체적인 질서를 유지하면서 약간의 혼란을 허용한다는 뜻이다.
chap09 프로젝트 기획 및 프로젝트 관리
다음은 6개 핵심 섹션 중 처음 2개입니다. 문제 식별 및 승인 받기, 프로젝트 계획 및 모니터링
9.2 프로젝트 관리 원칙
9.2.1 프로젝트 관리 요구사항
통계에 따르면 성공적인 프로젝트의 1/3 미만이
일부 프로젝트가 실패하는 이유
주요 이유: 고위 경영진의 참여 및 관리 기술 부족
사용자 그룹 참여 부족
9.2.2 프로젝트 관리자의 역할
프로젝트 관리는 미리 결정된 일정과 예산에 따라 계획된 결과를 달성하기 위해 다른 사람을 조직하고 지시하는 프로세스이며, 프로젝트를 계획하고 이를 모니터링하고 제어하는 프로세스로도 정의할 수 있습니다.
프로젝트 관리자 내부 책임
프로젝트 일정 개발
팀원 모집 및 교육
팀 구성원 간의 작업 조정
프로젝트 위험 평가
프로젝트 마일스톤 모니터링 및 제어
인력 및 리소스 관리
프로젝트 관리자의 외부 책임
프로젝트 상태 및 진행 상황 보고
고객 및 기타 이해관계자와 직접 협력
자원 요구 사항을 결정하고 자원을 확보합니다.
홍보 조정
프로젝트 관리자는 다양한 그룹의 사람들과 협력합니다.
클라이언트: 시스템에 자금을 지원하는 사람
감독 위원회: 프로젝트를 감독하기 위해 고객과 기타 고위 관리자로 구성됩니다.
사용자 : 업무를 완료하기 위해 시스템을 직접 이용하는 사람
프로젝트 관리자는 이중 내부 및 외부 기능을 가지고 있습니다.
9.2.3 프로젝트 관리 및 식(식)
프로젝트의 형식성 정도나 의식도 프로젝트 관리에 영향을 미칩니다.
소규모 프로젝트에서는 종종 낮은 수준의 의식을 수행합니다.
더 크고 복잡한 프로젝트는 종종 고품질의 행사를 수행합니다.
전통적인 예측 방법과 적응 방법을 사용할 때 프로젝트 의식이 다릅니다.
적응형 프로젝트는 관리 방법이 더 공식적이거나 비공식적일 수 있습니다. UP(통합 프로세스)는 상당히 공식적이며 엄격한 의식을 갖고 있는 반면, 반복적 방법은 더 비공식적입니다.
9.2.4 프로젝트 관리 지식 시스템
PMBOK는 9개의 모듈로 구성됩니다.
프로젝트 규모 관리
프로젝트 시간 관리
프로젝트 비용 관리
프로젝트 품질 관리
프로젝트 인적자원 관리
프로젝트 커뮤니케이션 관리
프로젝트 위험 관리
프로젝트 조달 관리
프로젝트 통합 관리
9.2.5 민첩한 프로젝트 관리
민첩한 프로젝트 관리
범위가 잘 이해되지 않았지만 통제가 필요함
여러 지침을 사용하여 비즈니스 우선순위 결정
민첩한 시간 관리
시간표는 변화를 수용할 수 있도록 유연해야 합니다.
민첩한 비용 관리
비용은 추정하기가 더 어렵기 때문에 비용 통제는 예측 접근 방식만큼 중요하지 않습니다.
민첩한 위험 관리
프로젝트의 고위험 측면을 먼저 완료합니다.
민첩한 품질 관리
각 반복 후에 품질 평가 수행
9.3 핵심 프로세스 1: 문제 식별 및 승인 획득
9.3.1 문제 식별
새로운 시스템을 개발하는 세 가지 주요 목적
새로운 개발 기회에 대응
시장 점유율을 차지하다
기존 비즈니스 문제 해결
외부 명령에 응답
법률, 세금 등
문제를 정의하는 효과적인 방법은 시스템 비전 문서(SVD)를 만드는 것입니다.
세 부분이 포함되어 있습니다.
문제 설명
문제점과 해결책은 무엇입니까?
시스템 성능
새로운 시스템에는 어떤 기능이 포함되나요?
비즈니스 혜택
조직에 대한 이익(유형 또는 무형)
9.3.2 프로젝트 승인 요소의 수량화
명확해야 함
예상 완료 시간
예상 개발 비용
예상 운영 비용
사전 수익
비용 편익 분석
몇 가지 개념
NPV(순현재가치) 순현재가치
특정 투자의 이익과 비용의 현재 가치
"현재 수입"을 사용하여 비용을 빼서 계산합니다(할인 요소 사용).
비용 회수 지점
이 기간 동안 달러 이익은 달러 비용을 상쇄합니다.
실질적인 혜택
이익 중 금전적으로 측정할 수 있는 부분
무형의 이익
조직에 이익이 되지만 정량적으로 측정하거나 정확하게 추정할 수 없음
서비스 수준 향상(달러로 측정할 수 없는 방식)
고객 만족도 향상(달러로 측정 불가)
서바이벌 - 이렇게 경쟁해야 해
사내 전문성 개발 필요(예: 신기술 파일럿 프로젝트)
비용/편익 분석 방법
현재 가치를 추정 가치로 사용
시스템 수명 계산
매년 순현재가치를 누적하여 투자회수 기간과 최종 수익을 계산합니다.
예
투자회수기간은 누적된 순현재가치의 양수 및 음수 전환점을 정수부로 사용하고, 소수부분은 (마지막 음수값/총 차이)를 사용하여 계산합니다.
9.3.3 평가 위험 및 타당성 분석
조직의 위험과 생존 가능성을 결정합니다.
기술적 위험 및 타당성 평가
위험 및 자원의 생존 가능성 평가
일정 위험 및 타당성 결정
9.3.4 승인 시 고객과 협력
집행위원회 검토 및 승인
이사회는 대규모 프로젝트를 검토하고 승인해야 합니다.
관련된 이해관계자는 자신에게 기대되는 것이 무엇인지 이해해야 합니다.
IS 부서는 인력 배치와 지원 측면에서 무엇을 해야 할지 알아야 합니다.
전체 조직은 이 프로젝트와 그 중요성을 인식해야 합니다.
9.4 핵심 프로세스 2: 프로젝트 계획 및 모니터링
9.4.1 프로젝트 환경 구축
여기서 프로젝트 환경이란 앞서 언급한 환경 디자인과 달리 시스템에서 요구하는 기술 등이 아닌 팀 내외부의 작업 환경과 커뮤니케이션을 의미한다.
기록 및 커뮤니케이션 - 내부/외부
작업 환경 – 지원/장비/도구
PC 또는 워크스테이션
개인 개발 소프트웨어 및 도구
리소스 라이브러리, 통신 도구를 갖춘 서버
사무실, 회의실, 프린터 및 기타 장비
지원 직원(팀 외부)
프로세스 및 절차
보고서 및 문서
프로그램 작성
시험
결과물
코드 및 버전 제어
9.4.2 작업 진행 조정
프로젝트 반복 일정을 사용하여 반복에 사용 사례 할당
각 반복에서 완료해야 하는 작업 및 작업의 세부 일정을 계획합니다. 세부 작업 일정을 사용하세요.
반복적인 세부 작업 일정을 만드는 세 가지 단계
작업분류체계 WBS 생성
노력 추정 및 종속성 식별
Gatt Chart를 사용하여 일정 만들기
작업분류체계에는 다음이 포함됩니다.
분해 기초
소요시간
실행 순서
WBS의 관련 정보를 기반으로 시간을 평가하고 중요 경로를 사용하여 종속성을 찾습니다.
간트 차트는 활동이 막대로 표시되고 수평 타임라인에 표시되는 막대 차트입니다.
첫 번째 작업을 제외하고 모든 작업에는 선행 작업이 있습니다.
밝은 색 부분은 중요한 경로로 전체 진행에 영향을 미치므로 면밀히 모니터링해야 합니다.
9.4.3 직원 및 자원 할당
다섯 가지 작업
프로젝트에서 리소스 계획 생성
특정 기술 인력을 파악하고 요청합니다.
특정 사용자 직원 식별 및 요청
팀을 작업 그룹으로 구성
초기 교육 및 팀 구축 연습 설정
9.4.4 평가업무 프로세스
회고전
9.4.5 모니터링 프로세스 및 수정
개인 또는 팀에 작업 할당
수집 현황
과제가 완료되었고 목표가 달성되었는가?
이상 징후 분석
예외가 중요합니까?
올바른 조치를 취하다
10장 객체지향 디자인: 디자인 원칙
10.2 객체지향 설계: 분석과 구현 사이의 가교
10.3 객체지향 아키텍처 설계(고수준 설계)
소프트웨어 시스템은 일반적으로 두 가지 유형으로 구분됩니다.
단일 사용자 시스템: 리소스 공유 없이 사용자의 데스크톱이나 서버에서 실행
엔터프라이즈 수준 시스템: 여러 사람이나 조직 간에 구성 요소를 공유할 수 있습니다.
서버/클라이언트 시스템
인터넷 시스템(브라우저/서버)
시스템 아키텍처 설계에 영향을 미치는 세 가지 기본 차이점
상태
클라이언트/서버는 상태 기반 시스템이며 클라이언트/서버 연결은 오래 지속됩니다.
인터넷 시스템은 상태 비저장 시스템이며 연결은 장기적이지 않습니다.
클라이언트 배포
화면과 테이블을 직접 표시
브라우저를 통해 화면과 테이블이 표시됩니다.
서버 배포
애플리케이션 또는 클라이언트가 서버에 직접 연결됩니다.
클라이언트는 브라우저를 통해 애플리케이션 서버에 간접적으로 연결됩니다.
구성 요소 다이어그램 및 아키텍처 설계
전체 시스템 아키텍처와 그 내부의 논리적 구성 요소를 보여주고 시스템 구현 방법을 보여주는 일종의 설계 다이어그램입니다.
구성 요소 다이어그램은 논리, 재사용성, 이식성을 위한 시스템 구성 요소를 식별합니다.
컴포넌트 다이어그램의 기본 요소는 API가 포함된 컴포넌트 요소입니다.
API는 외부 세계에서 접근할 수 있는 공개 메소드입니다.
컴포넌트 다이어그램에는 두 가지 유형의 API가 있습니다.
입력 소켓(소켓)
출력 포트(포트)
예
사례: 인터넷의 2계층 아키텍처 설계(실제로는 3계층일 수도 있음)
사용자 인터페이스 레이어(뷰 레이어)
도메인 계층(논리 계층)
데이터베이스 액세스 계층(데이터 계층)
구성요소 다이어그램을 사용하여 표현
10.4 객체지향 상세설계의 기본원리
객체지향 세부 설계 단계
예비 설계 클래스 다이어그램 개발
CRC 카드를 사용하여 사용 사례에 대한 클래스 책임 및 협력 결정
각 사용 사례에 대한 세부 시퀀스 다이어그램 개발: 먼저 예비 시퀀스 다이어그램을 개발한 다음 다층 시퀀스 다이어그램을 개발합니다.
메소드 특성 및 탐색 정보 추가
솔루션을 패키지로 나누기(패키지 다이어그램)
10.5 디자인 클래스와 디자인 클래스 다이어그램
10.5.1 디자인 기호
프로토타입은 <<>>로 표현되는 특성에 따라 요소를 분류하는 방법입니다.
디자인 프로토타입에는 네 가지 유형이 있습니다.
엔터티 클래스
문제 도메인 클래스의 설계 식별자는 일반적으로 <<엔티티>>로 표시되며 지속적입니다.
영구 클래스는 시스템이 종료된 후에도 데이터가 남아 있는 클래스를 말합니다. 메서드를 구현할 때 해당 데이터가 데이터베이스나 파일에 기록됩니다.
예
교육 관리 시스템의 학생 및 교사
제어 클래스
<<controller>>로 표현되는 라우터나 스위치와 유사하게 뷰 클래스와 엔터티 클래스 사이에서 조정 역할을 하는 클래스이다.
수업 보기
뷰 클래스 또는 경계 클래스는 입력 상자 또는 웹 페이지와 유사하게 시스템의 자동화 경계에 있으며 사용자를 향하며 <<boundary>>로 표시됩니다.
데이터베이스 액세스 클래스
데이터베이스로부터 데이터를 얻어서 반환하는 클래스로 <<dataAccess>>로 표현됩니다.
각 프로토타입 클래스에는 서로 다른 기호가 있습니다.
10.5.2 디자인 클래스 표현
디자인 클래스의 속성 형식 정의
시계
다른 객체가 해당 속성에 직접 액세스할 수 있는지 여부를 나타냅니다(또는 -). 일반적으로 public() 대신 private(-)을 사용합니다.
속성 이름
소문자 카멜 케이스
유형 표현
클래스, 문자열, 정수, 더블, 날짜
초기 값
재산
{key}와 같이 중괄호 안에
메소드의 형식 정의(메소드 특성)
메소드 가시성
메소드 이름
메소드 반환 값 유형
매개변수 목록
예
이름과 속성 유형 사이에는 콜론이 있고, 매개변수 목록과 메서드의 반환 값 유형 사이에는 초기 값 앞에 등호가 있습니다.
추상 클래스를 나타내려면 이탤릭체 클래스 이름을 사용하십시오.
상속만 허용하고 인스턴스화는 허용하지 않는 클래스는 일반적으로 더 높은 수준의 추상 개념을 나타냅니다.
10.5.3 예비 설계 클래스 다이어그램 개발
속성 세분화
디자이너는 경험을 바탕으로 속성 유형을 결정합니다. 대부분의 경우 속성은 보이지 않습니다(비공개).
내비게이션 가시성
탐색 가시성은 클래스가 다른 클래스에 표시되는지 또는 보이지 않는지 여부를 나타내며, 한 개체가 다른 개체를 보고 상호 작용할 수 있는 능력을 나타냅니다.
화살표를 사용하여 가리키는 방향이 보이는 쪽임을 나타냅니다.
이 예에서 고객은 판매 클래스를 참조하므로 판매는 고객에게 표시되지만 고객은 판매에 표시되지 않습니다.
내비게이션 가시성 유형
일반적으로 상사에서 부하 직원을 가리키는 상사와 부하 직원 간의 일대다 관계를 나타냅니다.
한 클래스의 객체가 다른 클래스의 객체 없이는 존재할 수 없는 강제 연관. 일반적으로 더 독립적인 클래스에서 종속 클래스로 이동합니다.
예를 들어, 위의 고객과 판매에서 고객이 없으면 판매는 의미가 없습니다.
한 개체가 다른 개체의 정보를 필요로 하는 경우 탐색 화살표가 필요할 수 있습니다.
내비게이션 가시성은 양방향일 수 있습니다.
예비 사용 사례 다이어그램 개발 단계
유스 케이스 이후의 유스 케이스, 다이어그램에 추가됨
사용 사례와 관련된 도메인 클래스 선택(전제 조건 및 사후 조건 아이디어 참조)
전제 조건과 사후 조건은 5장의 사용 사례 설명에 있어야 합니다.
사용 사례를 처리하기 위해 컨트롤러 클래스를 추가합니다.
지침을 사용하여 초기 탐색 가시성 요구 사항을 결정하고 이를 다이어그램에 추가합니다.
가시성과 유형을 포함하여 각 클래스의 속성을 자세히 설명합니다.
탐색이 텍스트에서 강조되는 것처럼 연관 및 다중성은 종종 디자인 클래스 다이어그램에서 제거되지만 종종 유지됩니다.
도메인 클래스 다이어그램에서 예비 디자인 클래스 다이어그램까지
10.6 CRC 카드를 사용한 상세화
CRC 카드는 클래스, 책임, 협업을 의미합니다.
객체 지향 설계는 클래스에 책임을 할당하고 클래스가 함께 작동하여 사용 사례를 완성하는 방법에 관한 것입니다.
CRC 카드는 클래스 이름, 책임 이름, 협력 클래스의 세 가지 영역으로 구분됩니다.
CRC 카드 사용 단계
사용하지 않은 CRC 카드 세트로 시작하여 하나의 사용 사례를 차례로 진행해 보세요.
사용 사례를 선택하고 카드를 컨트롤러로 선택하세요.
이 사용 사례를 주로 담당하는 도메인 클래스를 결정합니다. 이 클래스의 개체는 컨트롤러로부터 메시지를 수신하여 책임을 결정하고 이를 카드 왼쪽에 기록합니다.
유스 케이스를 완성하기 위해 기본 객체 클래스와 협력하는 다른 클래스를 식별하고 CRC 카드 오른쪽에 작성합니다.
협력 항목 결정 후, 각 협력 항목별로 위의 작업을 수행합니다.(책임 결정/협력 항목 찾기)
사용자 인터페이스 클래스와 데이터베이스 액세스 클래스를 적절하게 추가할 수 있습니다.
CRC 카드의 결과를 사용하여 예비 설계 클래스 다이어그램을 업데이트합니다.
메소드 업데이트: CRC 카드의 책임이 메소드가 됩니다(그러나 가시성 및 반환 유형 표현식이 없습니다. 즉, 메소드 특성이 추가되지 않습니다)
내비게이션 가시성 업데이트
예
예비 설계 클래스 다이어그램
업데이트된 디자인 클래스 다이어그램
10.7 세부 설계의 몇 가지 원칙
낮은 결합
높은 응집력
가변 보호
간접적인
객체 책임
chap11 객체지향 디자인: 디자인 구현
11.2 다층 시스템의 상세 설계
디자인 패턴
디자인 패턴 – 모범 사례로 널리 인정받는 표준 디자인 기술 및 템플릿
일반적인 디자인/코딩 문제의 경우 디자인 패턴은 문제를 처리하는 가장 좋은 방법을 제안합니다.
디자인 패턴의 요소
스키마 이름
해결이 필요한 문제
문제 해결 모델
패턴 케이스
패턴의 이점과 결과
프로그래밍 디자인 패턴의 첫 번째 예는 컨트롤러 패턴입니다.
사용 사례 컨트롤러는 결합을 줄이기 위해 뷰 계층에서 도메인 계층으로 메시지를 전달하도록 인위적으로 생성됩니다.
장점과 결과
도메인 레이어와 뷰 레이어 간의 결합을 줄입니다.
간접 계층을 제공합니다.
컨트롤러와 도메인 클래스는 긴밀하게 결합되어 있습니다.
조심하지 않으면 컨트롤러에 관련 없는 로직, 특히 비즈니스 로직이 많이 포함됩니다.
11.3 사용 사례 구현 및 시퀀스 다이어그램 SSD
유스케이스 구현 - 인터랙션 다이어그램을 이용하여 유스케이스를 구체적으로 설계하는 과정
상호작용 다이어그램에는 두 가지 유형이 있습니다.
흐름도
시스템 시퀀스 다이어그램을 확장하여 시퀀스 다이어그램을 표시합니다.
레이어 객체 보기
도메인 레이어 객체(보통 먼저 수행됨)
데이터 액세스 계층 객체
협업 다이어그램
11.3.1 시퀀스 다이어그램 이해하기
시스템 시퀀스 다이어그램과 시퀀스 다이어그램의 차이점
시스템 시퀀스 다이어그램에는 시스템을 나타내는 하나의 개체만 있습니다. 반면 시퀀스 다이어그램은 개체를 시스템 내부로 확장합니다.
시스템 시퀀스 다이어그램에는 액터와 시스템을 나타내는 두 개의 라이프라인만 있습니다. 시퀀스 다이어그램의 액터와 각 객체에는 길이가 다를 수 있지만 생명선이 있습니다(타이밍은 객체가 생성될 때 시작됩니다).
동일한 사용 사례에서 시스템 시퀀스 다이어그램과 시퀀스 다이어그램의 자동화 경계 부분은 동일합니다(전체는 변경되지 않음). 즉, 시스템으로의 입력과 시스템 외부로의 출력은 같은.
시퀀스 다이어그램에는 활동 수명선이라는 특별한 수명선 섹션이 있습니다.
활동 수명선은 개체가 활성 실행 상태에 있는 시간을 나타냅니다. 활성 상태는 모든 데이터가 저장되거나 다른 메서드가 호출될 때까지 지속됩니다.
사용자 사용 사례를 생성하는 이 시퀀스 다이어그램에서는 Customform 및 CustomHandler가 생성되었으며, createCustom 메서드 이후에 Custom 개체가 생성되므로 수명선의 시작 시간이 다르며 직사각형 막대가 활성 수명선입니다.
11.3.2 유스케이스 구현의 설계 프로세스
디자인 단계
내비게이션 가시성을 보여주는 예비 디자인 클래스 다이어그램 개발
사용 사례에서 CRC 카드를 사용하여 클래스에 기능 할당
각 사용 사례에 대한 자세한 시퀀스 다이어그램 개발
예비 시퀀스 다이어그램
다단계 시퀀스 다이어그램
CRC 카드와 세부 시퀀스 다이어그램을 사용하여 디자인 클래스 다이어그램을 업데이트하고 메소드 기능을 추가하세요.
패키지 디자인 클래스 다이어그램
11.3.3 사례: 사용자 계정 생성을 위한 예비 디자인 클래스 다이어그램
기존에 개발된 예비 설계 클래스 다이어그램을 기반으로 예비 시퀀스 다이어그램 개발
시스템 시퀀스 다이어그램을 확장하고 원본: 시스템에서 사용해야 하는 클래스 개체를 표시하세요. 그 앞에는 여전히 콜론이 있습니다.
개체 간의 내부 메시지를 결정하고 메시지 및 활성화를 추가하여 협업을 완료합니다.
메시지 형식은 시스템 시퀀스 다이어그램과 일치합니다. *[조건] return_value:=함수_이름(매개변수_목록) 반환 값으로 점선 역방향 화살표를 사용할 수도 있습니다.
하위 주제
11.3.5 예비 시퀀스 다이어그램 개발을 위한 지침 및 가정
가이드
각 메시지를 수락하고 이 입력 메시지로 인해 발생하는 다른 내부 메시지를 식별합니다.
각 메시지를 처리할 때 영향을 받는 클래스 집합을 지정하세요.
메시지 구조를 강화하고 참 및 거짓 조건, 루프, 반환 값, 매개변수 전송 등을 추가합니다.
가설
기술적 완벽성 가설
기억완전가설
이상 가정 없음
11.3.6 다층 시퀀스 다이어그램 개발
위의 내용은 도메인 계층(논리 계층)에 대한 예비 시퀀스 다이어그램일 뿐입니다. 사용 사례를 더 자세히 설명하려면 데이터 액세스 계층과 뷰 계층에 대한 시퀀스 다이어그램을 개발해야 합니다.
11.4 협업 다이어그램 통신 다이어그램 사용
11.5 업데이트 및 패키지 디자인 클래스 다이어그램
디자인 클래스 다이어그램 업데이트
시퀀스 다이어그램의 정보를 기반으로 메서드 기능을 추가하여 DCD를 업데이트합니다.
세 가지 방법 유형
생성자 메서드: 새 개체 인스턴스 만들기
데이터 읽기 및 쓰기 방법: 속성 값 가져오기 또는 업데이트
사용 사례별 방법: 디자인 클래스 다이어그램에 포함됨
패키지 맵
패키지 다이어그램은 관련 클래스 그룹을 연결하는 상위 수준 다이어그램입니다.
폴더형 아이콘을 사용하여 패키지를 표현하고, 클래스는 속한 레이어에 따라 해당 패키지에 배치됩니다.
점선 화살표를 사용하여 클래스 간 종속성과 패키지 간 종속성을 포함한 종속성을 나타냅니다.
예
하나의 사용 사례만 포함된 부분 패키지 다이어그램
하위 시스템 패키지 다이어그램
11.6 기타 일반적인 디자인 패턴
어댑터
두 시스템을 연결해야 하지만 시스템 간의 인터페이스가 일치하지 않는 경우 어댑터가 필요합니다.
데이터를 다시 작성하여 일치하지 않는 인터페이스 연결
예를 들어, 다른 공급업체(세금, 배송비)가 있는 경우 어댑터만 다시 작성하면 됩니다.
공장
팩토리 클래스는 다양한 유형의 유틸리티 클래스 인스턴스를 만드는 데 사용됩니다.
일반적으로 도구 클래스에는 인스턴스가 하나만 필요하며 팩토리에서는 인스턴스가 하나만 있는지 확인합니다.
하나씩 일어나는 것
싱글톤에는 자신의 인스턴스를 가리키는 정적 변수가 있습니다. 어떤 방법을 통해 이 변수를 확인하십시오. 비어 있으면 인스턴스를 만들어 변수에 할당할 수 있고, 비어 있지 않으면 변수 인스턴스를 직접 반환할 수 있습니다.
수업 연결{ 개인 정적 연결=null; 공개 동기화 정적 getConnection(){ conn==null인 경우{ conn=새 연결(); } 반환 연결; } }
팩토리와 싱글톤
팩토리와 싱글톤의 기본 논리는 동일합니다. 둘 다 개체의 인스턴스가 하나만 있는지 확인하고 메모리 오버헤드를 절약하는 것입니다.
그러나 팩토리는 여러 클래스를 담당해야 합니다. 싱글톤은 클래스 내부의 정적 인스턴스 변수만 확인합니다.