컴퓨팅 장치에서 특정 기능 세트를 수행하는 컴퓨터 소프트웨어 프로그램

비즈니스 작업을 완료하는 데 필요한 정보를 수집, 처리, 저장 및 제공하는 상호 연관된 구성 요소 집합

사람들이 정보 시스템이 달성해야 하는 것을 이해하고 구체화할 수 있도록 하는 활동

요구사항을 해결하는 시스템을 세부적으로 정의하고 설명할 수 있는 활동

시작과 끝이 있고 일정한 결과를 가져오는 계획된 작업

시스템 개발 라이프사이클은 정보 시스템을 구축, 출시 및 유지하는 데 필요한 모든 활동을 포함하는 전체 프로세스를 식별합니다.

모든 활동에는 시스템 분석, 시스템 설계, 프로그래밍, 테스트, 시스템 유지 관리가 포함됩니다.

6가지 핵심 프로세스

시스템 테스트를 완료한 후 솔루션을 배포하여 특정 정보 시스템(일명: 방법론)을 개발하는 실용적인 접근 방식

이제 대부분의 프로세스/방법은 민첩하고 반복적인 개발을 사용합니다.

문제 식별 및 시스템 목표 문서화(핵심 프로세스 1)

프로젝트 시작 승인 받기 (핵심 프로세스 1)

SVD(시스템 비전 문서)

핵심 프로세스 2: 프로젝트 계획

요구 사항을 이해하기 위해 예비 사실 조사 작업을 수행합니다. (핵심 프로세스 3)

사용 사례의 예비 목록과 사용 사례 다이어그램을 개발합니다. (핵심 프로세스 3)

예비 수업 목록과 수업 다이어그램을 개발합니다. (핵심 프로세스 3)

위 다이어그램은 Unified Modeling Language UML을 사용하여 개발되었습니다.

자세한 사실을 알아보기 위해 심층적인 사실 조사를 수행합니다. (핵심 프로세스 3)

각 사용 사례에 대한 자세한 워크플로를 이해하고 문서화합니다. (핵심 프로세스 3)

화면과 보고서를 통해 사용자 경험을 정의합니다. (핵심 프로세스 3, 4)

데이터베이스 구조(스키마)를 디자인합니다. (핵심 프로세스 4)

시스템의 상위 수준 구조를 설계합니다. (핵심 프로세스 4)

세부 설계 계속(CP4)

프로그래밍 및 개별 테스트 수행(CP5)

디자인과 프로그래밍은 전체를 디자인하고 프로그래밍하는 것이 아니라, 부품을 디자인하고, 프로그래밍하고, 부품을 디자인하고, 다시 프로그래밍하는 것입니다.

전체 시스템 테스트(CP6)

부분 시스템 구축 가능(CP6)

제1장

2장, 3장, 4장, 5장

6장과 7장

8장과 9장

10장, 11장, 12장

아키텍처는 두 가지 유형으로 나뉩니다.

새로운 통합 영업 및 마케팅 시스템에는 4개의 하위 시스템이 있습니다.

2.3.1 상세정보 수집

2.3.2 요구사항 정의

2.3.3 요구사항의 우선순위 지정

2.3.4 사용자 인터페이스 대화 상자 개발

2.3.5 사용자와 함께 요구 사항 평가

기능 요구 사항

비기능적 요구사항

기능적 기능성

유용성 가용성

신뢰할 수 있음

성능

보안

기타 제한 조건 등

비기능적 요구사항

모델은 구축 중인 시스템의 일부 측면을 표현한 것입니다.

텍스트 모델

그래픽 모델

수학적 모델

많은 그래픽 모델의 개발은 UML(Undefine Modeling Language)을 통해 구현됩니다.

내부 이해관계자

외부 이해관계자

운영 이해관계자

이해관계자 관리

두 가지 유형의 중요한 이해관계자

2.7.1 사용자 및 기타 이해관계자와의 인터뷰 실시

2.7.2 설문지 배포 및 수집

2.7.3 입력, 출력 및 프로세스 확인

2.7.4 비즈니스 프로세스 관찰 및 기록

2.7.5 조사 공급자 솔루션

2.7.6 활성 사용자 댓글 수집

워크플로는 비즈니스 트랜잭션이나 고객 요청을 완벽하게 처리하는 일련의 처리 단계입니다.

활동 다이어그램은 다양한 사용자(또는 시스템) 활동, 각 활동을 수행하는 사람 및 해당 활동의 순차적 흐름을 설명합니다.

새로운 시스템의 모든 잠재적 사용자를 식별합니다.

기능적 역할(예: 운송, 마케팅, 판매)을 기준으로 잠재 사용자를 분류합니다.

잠재 사용자를 조직 수준(예: 운영, 관리, 임원)별로 추가로 분류합니다.

각 유형의 사용자에 대해 해당 사용자를 방문하여 새 시스템을 사용할 때 갖게 될 구체적인 목표 목록을 찾으십시오(현재 목표 및 가치를 추가하는 혁신적인 기능).

사용자 유형별로 정리된 사용 사례의 예비 목록을 만듭니다.

유사한 사용 사례 이름을 가진 복사본을 찾고 불일치를 해결합니다.

다양한 유형의 사용자가 동일한 사용 사례를 필요로 하는 위치 결정

각 유형의 사용자 및 관심 있는 이해관계자와 함께 완성된 목록을 검토합니다.

EBP는 비즈니스 이벤트에 대응하고 측정 가능한 비즈니스 가치를 추가하며 시스템과 데이터를 안정적이고 일관된 상태로 만들기 위해 한 사람이 한 장소에서 수행하는 작업입니다.

각 EBP는 비즈니스 이벤트가 발생할 때 이에 응답합니다.

이벤트

외부 이벤트

시간 제한 이벤트/임시 시간

상태 이벤트

이벤트/전제조건/응답

사건의 연속

기술 의존성 이벤트 및 시스템 제어

1. 시스템 응답이 필요한 시스템 환경의 외부 이벤트 고려

2. 각 외부 이벤트에 대해 시스템에서 요구하는 사용 사례를 식별하고 이름을 지정합니다.

3. 체크리스트를 사용하여 시스템 응답이 필요한 시간 이벤트를 고려하십시오.

4. 각 시간 이벤트에 대해 시스템에서 요구하는 사용 사례를 식별하고 이름을 지정한 다음 사용 사례를 트리거하는 시점을 설정합니다.

5. 시스템이 응답할 수 있는 상태 이벤트를 고려하십시오. 특히 장치 또는 내부 상태 변경으로 인해 사용 사례가 트리거되는 실시간 시스템인 경우 더욱 그렇습니다.

6. 각 상태 이벤트에 대해 시스템에 필요한 사용 사례를 식별하고 이름을 지정한 다음 상태 변경을 정의합니다.

7. 이벤트 및 사용 사례를 정의한 후 완벽한 기술적 가정이 필요한지 확인합니다. 로그인, 로그아웃, 비밀번호 변경, 데이터베이스 백업 또는 복구와 같은 시스템 제어와 관련된 이벤트는 시스템 제어로 배치되므로 포함하지 마십시오.

만들다

읽고 또 읽어라

업데이트, 업데이트

삭제하다, 삭제하다

데이터베이스 관리와 관련된 작업입니다.

누락된 사용 사례 유형이 있는지 확인할 수 있습니다.

1. 새로운 시스템과 관련된 모든 데이터 엔터티 또는 도메인 클래스를 식별합니다.

2. 각 데이터 유형(데이터 엔터티 또는 도메인 클래스)에 대해 새 인스턴스 생성, 기존 인스턴스 업데이트, 인스턴스 값 읽기 또는 보고, 인스턴스 삭제(보관)에 대한 사용 사례를 식별했는지 확인합니다.

3. 필수 사용 사례가 무시되면 새 사용 사례를 추가하고 이해관계자를 식별합니다.

4. 통합 애플리케이션의 경우 어떤 애플리케이션이 데이터 추가 및 유지 관리를 담당하고 어떤 시스템이 데이터만 사용하는지 명확히 해야 합니다.

대부분의 사용 사례에서 암묵적으로는 시스템을 사용하는 사람들(지금까지 사용자라고 지칭함)이 있습니다. UML에서는 이 사람을 액터(actor)라고 합니다. 액터는 자동화 경계 밖에 있는 경우가 많습니다.

유스케이스 다이어그램에서 사람 기호는 액터를 나타내고, 타원은 유스케이스를 나타내고, 직사각형 테두리는 자동화 경계를 나타내며, 유스케이스와 액터 사이의 연결은 어떤 액터가 어떤 유스케이스에 참여하는지를 나타냅니다.

예

유스 케이스와 액터 사이에 관계가 있을 뿐만 아니라 유스 케이스 사이에도 관계가 있을 수 있습니다.

제품, 주문, 고객

1. 사용자와 사용 사례 세트를 식별합니다.

2. 유스 케이스 실행과 관련된 사항, 즉 시스템이 정보를 캡처해야 하는 사항을 식별하기 위해 사용자와 브레인스토밍합니다.

3. 사물 유형(범주)을 사용하여 잠재적인 사물에 대해 체계적으로 질문합니다. 예: 유형의 사물에 대한 정보를 저장합니까? 관련 장소가 있나요? 누구의 역할을 기억해야 합니까?

4. 브레인스토밍 목록을 확장하기 위해 다양한 사용자 및 이해관계자와 계속 협력합니다.

5. 결과를 결합하고 중복 항목을 제거한 후 초기 목록을 작성합니다.

사용자가 언급한 모든 명사를 나열합니다. 이벤트, 사용 사례 또는 행위자를 설명하는 데 사용되는 명사는 잠재적인 것입니다.

단계

예

대부분의 시스템은 속성이라는 트랜잭션에 대한 특정 정보를 저장합니다.

무언가를 고유하게 식별하는 속성을 식별자 또는 키워드(키/코드)라고 합니다.

복합 속성은 주소, 성명 등과 같은 여러 관련 속성으로 구성됩니다.

연관이란 특정 사물 사이에서 자연적으로 발생하는 관계를 말합니다.

관련 세부정보

관련 요소

도메인 모델 클래스 다이어그램

디자인 클래스 다이어그램

클래스 다이어그램에서 직사각형은 클래스를 나타내고, 직사각형을 연결하는 직선은 클래스 간의 관계를 나타냅니다.

직사각형은 두 부분으로 구성됩니다(도메인 모델 클래스 다이어그램, 디자인 클래스 다이어그램은 클래스 이름, 속성, 메서드의 세 부분으로 구성됨). 위쪽은 클래스 이름이고 아래쪽은 클래스의 특성입니다.

클래스 이름과 속성 이름은 카멜 케이스 명명을 사용합니다. 클래스 이름의 첫 글자는 대문자로, 속성 이름의 첫 글자는 소문자로 표시됩니다.

다중성 기호

도메인 클래스에는 세 가지 유형의 관계가 있습니다.

간단한 사용 사례 설명

완전히 개발된 사용 사례 설명

예

인간 기호를 사용하여 유스 케이스 액터를 나타내고 직사각형 테두리를 사용하여 자동화 경계를 나타냅니다.

직사각형은 자동 시스템을 나타내는 시스템(콜론 포함)으로 표시됩니다.

참여자와 시스템 아래에는 라이프라인이라는 점선이 있는데, 이는 참여자와 시스템의 생명주기를 나타내며, 시간은 하향식 방향으로 흐른다.

참가자와 시스템의 생명선 간에 메시지를 보내고 받습니다.

메시지의 완전한 상징적 표현

1. 입력된 메시지를 확인하세요

2. 외부에서 시스템으로 전달되는 정보를 설명하기 위해 메시지 기호를 사용합니다.

3. 루프 및 참/거짓 조건을 포함하여 입력 메시지에 특정 조건을 추가합니다.

4. 반송 메시지 확인 및 추가

상태 전이 기능

동시에 여러 상태에 있는 것을 동시성 또는 동시 상태라고 합니다.

다른 상위 수준 상태 내에 상태를 중첩합니다. 이러한 상위 수준 상태를 복합 상태라고 합니다.

예

클래스 다이어그램을 보고 상태가 필요할 수 있는 클래스를 선택하세요.

그룹에서 선택한 각 클래스에 대해 결정할 수 있는 모든 상태 조건을 나열하십시오.

객체가 식별된 상태를 벗어나게 하는 전환을 식별하여 상태 머신 다이어그램 조각 구축을 시작합니다.

이러한 상태 전환 조합을 올바른 순서로 정렬하세요.

이러한 경로를 확인하고 독립적인 동시 경로를 찾으세요.

다른 전환 찾기

적절한 메시지 이벤트, 보호 조건 및 작업 표현으로 각 전환을 확장합니다.

각 상태 머신 다이어그램 확인 및 테스트

사용 사례 다이어그램

도메인 모델 클래스 다이어그램

관계는 다음 그림으로 설명됩니다.

화살표는 종속 항목에서 종속 항목 방향을 가리킵니다.

실선은 기본 종속성을 나타내고 점선은 보조 종속성을 나타내며 일부 화살표는 양방향이므로 상호 영향을 나타냅니다.

시스템 설계는 최종 솔루션의 구성요소를 구축 청사진으로 정의, 구성 및 구축하기 위한 목적으로 시스템 분석과 구현을 연결하는 프로세스입니다.

주요 구성품

두 가지 수준

분석모델

디자인 모델

환경 디자인

애플리케이션 아키텍처 및 소프트웨어 설계

사용자 인터페이스 디자인

시스템 인터페이스 디자인

데이터베이스 디자인

보안 및 제어 설계

환경은 소프트웨어 애플리케이션을 지원하는 데 필요한 모든 기술입니다.

2장에서는 이를 기술 아키텍처라고 불렀습니다.

시스템을 하위 시스템으로 나누기

소프트웨어 아키텍처 정의(아키텍처 설계)

각 사용 사례의 세부 설계

대화상자 디자인은 요구사항에서 시작됩니다

디자인은 화면 레이아웃, 모양과 느낌, 탐색, 사용자 경험을 추가합니다.

다양한 장치에 대해 다양한 인터페이스 디자인

정보 시스템은 다른 많은 내부 및 외부 시스템과 상호 작용합니다.

시스템 인터페이스는 다양한 방식으로 다른 시스템에 연결됩니다.

도메인 모델 클래스 다이어그램(또는 ERD)으로 시작

데이터베이스 구조 선택

설계 아키텍처(분산 등)

데이터베이스 스키마 설계

설계 참조 무결성 제약 조건

목적은 인터넷과 무선 세계에서 중요한 조직의 자산을 보호하는 것입니다.

사용자 인터페이스 컨트롤

애플리케이션 제어

데이터베이스 제어

네트워크 제어

온프레미스 소프트웨어 시스템에는 두 가지 유형이 있습니다.

3계층 클라이언트/서버 아키텍처

중요한 질문은 다음과 같습니다

VPN(가상 사설망)을 통한 원격 배포

물리적 의미: 사무실 책상과 의자, 램프, 키보드, 마우스, 터치 스크린

인지된 의미: 색상, 모양, 질감, 글꼴, 창, 메뉴, 버튼

개념적 의미: 고객, 참가자, 주문, 운송, 피드백

인간-컴퓨터 상호작용(Human-Computer Interaction)은 사용자와 컴퓨터 시스템의 상호작용의 효율성과 효과성, 인간 중심의 입출력 기술, 사용자 인터페이스의 심리적 측면을 연구하는 분야이다.

사용자와 작업에 조기에 집중

시스템을 평가하여 유용성을 확인하세요.

반복 개발 사용

은유는 사용자 인터페이스 기능과 사용자에게 친숙한 물리적 개체 간의 유사성입니다.

은유는 다음과 같은 상황에서 사용자 인터페이스 디자인에 널리 사용됩니다.

지시형은 해당 성능을 반영하는 컨트롤의 모양을 나타냅니다.

가시성은 컨트롤이 표시됨을 의미합니다.

메뉴는 사용자 인터페이스에서 수많은 관련 사용 사례나 대화를 구성하는 방법입니다.

디자이너는 사용 사례 수를 기반으로 메뉴 계층 구조를 추정해야 합니다.

메뉴 수준에는 일반적으로 5~10개의 옵션이 포함됩니다.

사용자에게 필요한 대화를 녹음해야 함

스토리보드: 대화에 이 일련의 화면 스케치를 표시합니다.

인터페이스 레이아웃 및 형식

데이터 투입

지도 및 지원 통제

일관성

성능 고려사항

사진, 비디오 및 사운드

특별사용자(장애인)

모바일 장치용 사용자 인터페이스 디자인의 과제

다른 시스템의 입력 및 출력

고도로 자동화된 입력 및 출력

외부 데이터베이스의 입력 및 출력

모든 데이터 입력의 주요 목적은 오류 없는 데이터를 시스템에 제공하거나 업데이트하는 것입니다. 가장 중요한 것은 오류를 최대한 방지하는 것입니다.

보고서 유형

내부 산출물은 조직이나 단위의 내부 사용을 위해 생성됩니다. 앞에서 설명한 보고서는 조직 외부 구성원이 사용하기 위해 생성한 것입니다. 외부인을 위해 생성된 공식적인 업무문서이기 때문에 더 높은 퀄리티를 요구하기 때문에

전자 명세서

그래픽 및 멀티미디어 프레젠테이션

예측방법은 조직개발 프로젝트를 미리 계획하고, 그 계획에 따라 새로운 정보시스템을 개발할 수 있는 방법이다.

요구사항: 프로젝트를 사전에 계획할 수 있고, 계획에 따라 정보 시스템을 개발할 수 있으며, 요구사항을 잘 이해하고, 기술적 위험이 낮다고 가정합니다.

폭포 모델

요구 사항(요구 사항)이 불분명하고 종종 여러 번의 반복이 필요한 경우 적응 모델을 개발에 사용할 수 있습니다.

프로젝트는 보다 유연해야 하며 개발 프로세스 중 변화하는 요구에 적응해야 합니다. 수요는 불확실하고 기술적 위험은 높습니다.

나선형 모델

반복 모델

적응형 접근 방식에 대한 추가 개념

유지관리 시스템

시스템 강화

사용자 지원

방법의 범위가 가장 크다.

모델은 관련 부분에만 초점을 맞춰 복잡한 개념을 이해할 수 있도록 현실 세계의 특정 측면을 추상적으로 표현한 것입니다.

각 모델은 서로 다른 정보를 강조합니다.

소프트웨어 지원

학습을 통해 습득한

구조화된 방법은 프로세스에 초점을 맞추고 데이터 흐름에 중점을 둡니다. 시스템은 데이터 흐름과 상호 작용하는 프로세스의 모음이라고 가정합니다.

구조화된 방법은 SDLC 예측 방법과 동일한 전통적인 방법입니다.

구조화된 분석

구조화된 디자인

구조화된 프로그래밍

객체 지향 접근 방식은 시스템을 특정 상호 작용을 수행하기 위해 함께 작동하는 객체의 모음으로 간주합니다.

객체는 메시지에 응답하는 시스템의 사물입니다.

객체 지향 분석

객체지향 디자인

객체 지향 프로그래밍

핵심이론

애자일 프로젝트의 개념 설명: 혼돈

통계에 따르면 성공적인 프로젝트의 1/3 미만이

일부 프로젝트가 실패하는 이유

프로젝트 관리는 미리 결정된 일정과 예산에 따라 계획된 결과를 달성하기 위해 다른 사람을 조직하고 지시하는 프로세스이며, 프로젝트를 계획하고 이를 모니터링하고 제어하는 ​​프로세스로도 정의할 수 있습니다.

프로젝트 관리자 내부 책임

프로젝트 관리자의 외부 책임

프로젝트 관리자는 다양한 그룹의 사람들과 협력합니다.

프로젝트 관리자는 이중 내부 및 외부 기능을 가지고 있습니다.

프로젝트의 형식성 정도나 의식도 프로젝트 관리에 영향을 미칩니다.

소규모 프로젝트에서는 종종 낮은 수준의 의식을 수행합니다.

더 크고 복잡한 프로젝트는 종종 고품질의 행사를 수행합니다.

전통적인 예측 방법과 적응 방법을 사용할 때 프로젝트 의식이 다릅니다.

PMBOK는 9개의 모듈로 구성됩니다.

민첩한 프로젝트 관리

민첩한 시간 관리

민첩한 비용 관리

민첩한 위험 관리

민첩한 품질 관리

새로운 시스템을 개발하는 세 가지 주요 목적

문제를 정의하는 효과적인 방법은 시스템 비전 문서(SVD)를 만드는 것입니다.

명확해야 함

비용 편익 분석

조직의 위험과 생존 가능성을 결정합니다.

기술적 위험 및 타당성 평가

위험 및 자원의 생존 가능성 평가

일정 위험 및 타당성 결정

집행위원회 검토 및 승인

이사회는 대규모 프로젝트를 검토하고 승인해야 합니다.

관련된 이해관계자는 자신에게 기대되는 것이 무엇인지 이해해야 합니다.

IS 부서는 인력 배치와 지원 측면에서 무엇을 해야 할지 알아야 합니다.

전체 조직은 이 프로젝트와 그 중요성을 인식해야 합니다.

여기서 프로젝트 환경이란 앞서 언급한 환경 디자인과 달리 시스템에서 요구하는 기술 등이 아닌 팀 내외부의 작업 환경과 커뮤니케이션을 의미한다.

기록 및 커뮤니케이션 - 내부/외부

작업 환경 – 지원/장비/도구

프로세스 및 절차

프로젝트 반복 일정을 사용하여 반복에 사용 사례 할당

각 반복에서 완료해야 하는 작업 및 작업의 세부 일정을 계획합니다. 세부 작업 일정을 사용하세요.

다섯 가지 작업

회고전

단일 사용자 시스템: 리소스 공유 없이 사용자의 데스크톱이나 서버에서 실행

엔터프라이즈 수준 시스템: 여러 사람이나 조직 간에 구성 요소를 공유할 수 있습니다.

전체 시스템 아키텍처와 그 내부의 논리적 구성 요소를 보여주고 시스템 구현 방법을 보여주는 일종의 설계 다이어그램입니다.

구성 요소 다이어그램은 논리, 재사용성, 이식성을 위한 시스템 구성 요소를 식별합니다.

컴포넌트 다이어그램의 기본 요소는 API가 포함된 컴포넌트 요소입니다.

컴포넌트 다이어그램에는 두 가지 유형의 API가 있습니다.

예

사용자 인터페이스 레이어(뷰 레이어)

도메인 계층(논리 계층)

데이터베이스 액세스 계층(데이터 계층)

구성요소 다이어그램을 사용하여 표현

예비 설계 클래스 다이어그램 개발

CRC 카드를 사용하여 사용 사례에 대한 클래스 책임 및 협력 결정

각 사용 사례에 대한 세부 시퀀스 다이어그램 개발: 먼저 예비 시퀀스 다이어그램을 개발한 다음 다층 시퀀스 다이어그램을 개발합니다.

메소드 특성 및 탐색 정보 추가

솔루션을 패키지로 나누기(패키지 다이어그램)

프로토타입은 <<>>로 표현되는 특성에 따라 요소를 분류하는 방법입니다.

디자인 프로토타입에는 네 가지 유형이 있습니다.

디자인 클래스의 속성 형식 정의

메소드의 형식 정의(메소드 특성)

예

추상 클래스를 나타내려면 이탤릭체 클래스 이름을 사용하십시오.

속성 세분화

내비게이션 가시성

예비 사용 사례 다이어그램 개발 단계

도메인 클래스 다이어그램에서 예비 디자인 클래스 다이어그램까지

사용하지 않은 CRC 카드 세트로 시작하여 하나의 사용 사례를 차례로 진행해 보세요.

사용 사례를 선택하고 카드를 컨트롤러로 선택하세요.

이 사용 사례를 주로 담당하는 도메인 클래스를 결정합니다. 이 클래스의 개체는 컨트롤러로부터 메시지를 수신하여 책임을 결정하고 이를 카드 왼쪽에 기록합니다.

유스 케이스를 완성하기 위해 기본 객체 클래스와 협력하는 다른 클래스를 식별하고 CRC 카드 오른쪽에 작성합니다.

협력 항목 결정 후, 각 협력 항목별로 위의 작업을 수행합니다.(책임 결정/협력 항목 찾기)

사용자 인터페이스 클래스와 데이터베이스 액세스 클래스를 적절하게 추가할 수 있습니다.

메소드 업데이트: CRC 카드의 책임이 메소드가 됩니다(그러나 가시성 및 반환 유형 표현식이 없습니다. 즉, 메소드 특성이 추가되지 않습니다)

내비게이션 가시성 업데이트

예

디자인 패턴 – 모범 사례로 널리 인정받는 표준 디자인 기술 및 템플릿

일반적인 디자인/코딩 문제의 경우 디자인 패턴은 문제를 처리하는 가장 좋은 방법을 제안합니다.

디자인 패턴의 요소

사용 사례 컨트롤러는 결합을 줄이기 위해 뷰 계층에서 도메인 계층으로 메시지를 전달하도록 인위적으로 생성됩니다.

장점과 결과

상호작용 다이어그램에는 두 가지 유형이 있습니다.

시스템 시퀀스 다이어그램과 시퀀스 다이어그램의 차이점

동일한 사용 사례에서 시스템 시퀀스 다이어그램과 시퀀스 다이어그램의 자동화 경계 부분은 동일합니다(전체는 변경되지 않음). 즉, 시스템으로의 입력과 시스템 외부로의 출력은 같은.

시퀀스 다이어그램에는 활동 수명선이라는 특별한 수명선 섹션이 있습니다.

디자인 단계

기존에 개발된 예비 설계 클래스 다이어그램을 기반으로 예비 시퀀스 다이어그램 개발

시스템 시퀀스 다이어그램을 확장하고 원본: 시스템에서 사용해야 하는 클래스 개체를 표시하세요. 그 앞에는 여전히 콜론이 있습니다.

개체 간의 내부 메시지를 결정하고 메시지 및 활성화를 추가하여 협업을 완료합니다.

가이드

가설

위의 내용은 도메인 계층(논리 계층)에 대한 예비 시퀀스 다이어그램일 뿐입니다. 사용 사례를 더 자세히 설명하려면 데이터 액세스 계층과 뷰 계층에 대한 시퀀스 다이어그램을 개발해야 합니다.

시퀀스 다이어그램의 정보를 기반으로 메서드 기능을 추가하여 DCD를 업데이트합니다.

패키지 맵

두 시스템을 연결해야 하지만 시스템 간의 인터페이스가 일치하지 않는 경우 어댑터가 필요합니다.

데이터를 다시 작성하여 일치하지 않는 인터페이스 연결

예를 들어, 다른 공급업체(세금, 배송비)가 있는 경우 어댑터만 다시 작성하면 됩니다.

팩토리 클래스는 다양한 유형의 유틸리티 클래스 인스턴스를 만드는 데 사용됩니다.

일반적으로 도구 클래스에는 인스턴스가 하나만 필요하며 팩토리에서는 인스턴스가 하나만 있는지 확인합니다.

싱글톤에는 자신의 인스턴스를 가리키는 정적 변수가 있습니다. 어떤 방법을 통해 이 변수를 확인하십시오. 비어 있으면 인스턴스를 만들어 변수에 할당할 수 있고, 비어 있지 않으면 변수 인스턴스를 직접 반환할 수 있습니다.

팩토리와 싱글톤의 기본 논리는 동일합니다. 둘 다 개체의 인스턴스가 하나만 있는지 확인하고 메모리 오버헤드를 절약하는 것입니다.

그러나 팩토리는 여러 클래스를 담당해야 합니다. 싱글톤은 클래스 내부의 정적 인스턴스 변수만 확인합니다.