3) 분석 모델 확인하기
•UML(Unified Modeling Language)
-> OMG(Object Management Group)에서 만든 객체지향 모델링 언어
-> 정보 시스템을 객체 지향으로 분석 설계
- 구성요소
- 뷰 : 모델화된 시스템의 서로 다른 모형 제공
- 다이어그램 : 뷰의 내용을 나타내기 위한 13가지 다이어그램 제공
- 모델요소 : 클래스, 속성, 오퍼레이션
- 일반적 체계 : 주석 정보와 의미 제공
- UML 다이어그램 종류
-> 요구사항
- Use-Case : 사용자 입장에서 본 시스템의 행동을 표현, Use Case들은 시스템의 기능적인 요구를 정리
-> 정적 모델링
- Class : 시스템 내 클래스들의 정적 구조를 표현, 속성과 동작으로 구성
- Object : 클래스의 여러 오브젝트 인스턴스를 나타내는 대신 실제 클래스를 사용, 관계 있는 모든 인스턴스를 표현
- Component : 코드 컴포넌트에 바탕을 둔 코드의 물리적 구조 표현
- Deployment : 시스템 하드웨어와 소프트웨어간 물리적 구조 표현
-> 동적 모델링
- Sequence : 객체와 객체간의 상호 작용을 시간의 흐름에 따라 메세지로 표현, 오브젝트 사이에 메세지를 보내는 시간 또는 순서를 보여주기 위해 사용
- Collaboration : 오브젝트간 연관성 표현
- Activity : 오브젝트의 행위를 순서적 흐름으로 표시
- State Transition : 객체가 가질 수 있는 모든 가능한 상태와 상태간의 전이를 표현
- Use Case Diagram
-> 유스케이스 : 시스템이 제공해야 하는 서비스
-> 액터 : 시스템과 상호작용하는 사람 또는 사물
-> 시스템 : 전체 시스템의 영역을 표현
-> 관계 -> 확장 : 수행할 수도 하지 않을 수도 있음
-> 관계 -> 포함 : 반드시 수행해야 하는 관계
-> 관계 -> 일반화
-> 관계 -> 그룹화
- 유스케이스 명세서
-> 사용자와 시스템 간의 상호 작용을 나타내는 유스케이스를 설계할 때 사용
- 개요
- 관련 액터
- 우선순위
- 선행조건 : 해당 유스케이스가 수행되기 전에 수행해야 하는 유스케이스
- 주요흐름 : 해당 유스케이스가 기본적으로 수행되는 절차
- 대체흐름 : 주요 흐름 도중 발생하는 예외 상황에 대한 대안 흐름
- 후행조건 : 해당 유스케이스가 종료된 이후 수행되는 흐름
- Class Diagram
-> Class, Interface, Collaboration, Relation을 이용하여 시스템의 정적인 관계들을 가시화하고 구현을 위한 자세한 내용을 명세화한 다이어그램
-> Class name : 이텔릭체는 Interface를 의미
-> field, attribute, 속성, 멤버변수
-> method, 연산, operation, 특정 클래스의 객체로부터 요청할 수 있는 서비스를 표현
-> 접근성 표기법
- - : private, 해당 클래스 내에서만 접근 가능
- # : protected, 동일 패키지 내에서만 접근 가능
- + : public, 어디서든 접근 가능
-> 일반화관계(Generalizaation) : IS-A, 객체 지향 개념에서 상속 관계 상위와 하위 관계를 의미하며 하위는 상위의 공통점을 상속함
-> 연관관계(Association) : 클래스들의 상호 메세지를 주고 받는 관계, 한 클래스가 다른 클래스와 영속적인 연관성을 맺을 때 사용
-> 의존관계(Dependency) : HAS, 연관관계의 특수한 형태로 한 클래스가 다른 클래스에 의존적인 연관관계
-> 집합연관(Aggregation) : Part-of, Part-whole, 연관관계의 특수한 형태, 하나의 클래스가 다른 클래스를 포함하는 관계, 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적임
-> 복합연관(Composition) :연관관계의 특수한 형태, 전체 객체의 라이프타임과 부분 객체의 라이프타임이 동일, 전체 객체가 없어지면 부분 객체도 없어짐
-> 실체화관계(Realization) : Implement, 하나의 클래스가 다른 클래스를 구체화하는 관계, 인터페이스 클래스를 다른 클래스로 구현해주는 관계가 좋은 사례
- Sequence Diagram
-> 객체간의 주고받는 메세지의 순서를 시간의 흐름에 따라 보여주는 다이어그램
-> 활성 객체 : 시스템의 행위자이거나 시스템 내의 유효한 객체, 객체는 생명선을 가지고 있음
-> 메세지 : 서로 다른 활성 객체간의 의사소통 라인
-> 제어 사각형 : 객체가 활성되되어 있는 기간을 표현(inflate), 객체가 제어를 가지고 있다는 것
-> 동기 : 트랜잭션이 지속되는 동안 메세지를 주고 받으며, 메세지가 완료될 때에 비로소 트랜잭션이 종료되는 흐름
-> 반환 : 제어흐름이 반환됨, 동기 메세지가 그 임무를 완료했음
-> 비동기 : 호출한 객체가 응답을 기다리지 않고 바로 다름 트랜잭션을 시작할 수 있도록 함
-> 평판 : 동기와 비동기의 구분이 없음
- Activity Diagram
-> 시스템 내부에 있는 객체의 활동간의 처리 흐름을 모델링하는 범용적인 다이어그램, 사건 발생에 따른 객체들간의 행위에 대한 상호관계를 표현
-> 구획면(Swim Lane) : 업무 조직이나 개인의 역할에 따른 처리 구분
-> 시작 상태(Initial State) : 처리 흐름이 시작되는 곳을 의미
-> 종료 상태(Final State) : 처리 흐름이 종료되는 곳을 의미
-> 액션 상태(Action State) : 행위나 작업등 활동을 하고 있는 상태
-> 전이(Transition) : 상태에서 활동 또는 상태에서 다른 상태 사이의 제어 흐름을 보여줌
-> 분기(Decision) : 논리식의 결과에 따라 분기가 일어나는 곳
-> Synchronization Bar : 병렬 처리 흐름을 표현할 때 사용
-> 포크(Fork) : 병렬 처리 분기가 갈라져 나간다는 의미
-> 조인(Join) : 병렬 처리 분기가 모여져서 합쳐진다는 의미
- Component Diagram
-> 구축하려는 시스템을 분석하여 컴포넌트를 도출하고 이들 간의 상호작용을 그린 다이어그램
-> 컴포넌트는 독립적으로 구동될 수 있는 소프트웨어 모듈
-> 컴포넌트 : 해당하는 모듈이 컴포넌트임을 표시
-> Provided Interface : 컴포넌트가 외부에 제공하는 인터페이스
-> Required Interface : 컴포넌트가 외부에 요구하는 인터페이스
•디자인 패턴
-> 소프트웨어 설계에 있어 공통괸 문제들에 대한 표준적인 해법
- 디자인 패턴의 종류
-> 생성 패턴 : 객체의 생성 방식을 결정, 클래스의 정의, 객체 생성 방식의 구조화 캡슐화 지향
- Abstract Factory
- Builder
- Singleton
- Prototype
-> 구조 패턴 : 객체를 조직화 하는 일반적인 방법 제시, 유동성, 확장성
- Adaptor
- Facade
- Bridge
-> 행위 패턴 : 객체의 행위를 조직화 관리, 연합한다. 런타임 시 복잡한 제어흐름을 결정짓는데 사용
- Chain of Responsibility
- Command
- Visitor
- Abstract Factory 패턴
-> 구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공하는 패턴
-> 객체 생성을 클라이언트가 직접하는 것이 아닌 간접적 수행
-> 여러 제품군 중 사용한 제품군을 쉽게 선택할 수 있도록 만들고 싶을 때 사용
- AbstractFactory : 개념적 제품에 대한 객체를 생성하는 연산으로 인터페이스 정의
- ConcreteFactory : 구체적인 제품에 대한 객체를 생성하는 연산을 구현
- AbstractProduct : 개념적 제품 객체에 대한 인터페이스를 정의
- ConcreteProduct : 구체적으로 팩토리가 생성할 객체를 정의
- Client : AbstractFactory와 AbstractProduct 클래스에 선언된 인터페이스를 사용함
- Builder 패턴
-> 복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리해 서로 다른 표현이라도 이를 생성할 수 있는 동일한 절차 제공
-> 복합 객체의 생성 알고리즘과 이를 합성하는 요소 객체들간의 조합 방법이 서로 독립적일 때 사용
- Builder : 인스턴스를 생성하기 위한 인터페이스(API)를 결정, 인스턴스의 각 부분을 만들기 의한 메소드 준비
- Concrete Builder : Builder 클래스의 인터페이스(API)를 구현, 각 부분을 만드는 부분, 조립하는 부분, 최종적으로 인스턴스를 생산하는 부분 모두 구현
- Director : Builder 인터페이스(API)를 사용해 원하는 부품을 조립해 인스턴스를 생산
- Product : builder에 의해 최종적으로 생산된 제품, Director가 사용
- Singleton 패턴
-> 지정한 클래스의 인스턴스가 반드시 1개만 존재하도록 함
-> getInstance() 메소드를 통해서만 생성할 수 있음
-> 클래스의 인스턴스가 오직 하나여야함을 보장, 모든 클라이언트가 접근 할 수 있도록 해야 할 때
-> 시스템에서 유일한 인스턴스를 가져야하는 공통 모듈 설계에 활용 ex) 데이터베이스
-> 인스턴스 필요시 생성하는 방법
-> 생성속도가 문제되지 않을 때
-> java에서 동기화 식별자로 구분하여 반드시 동시에 1개의 싱글톤 인스턴스를 생성하게 함 -> 여러 프로세스가 생성할 경우 -> 경합 -> 느려짐
-> 처음부터 만들어 놓는 방법
-> 인스턴스를 실행중에 수시로 만들고 관리하기 불편한 경우 사용
-> java의 경우 private static으로 변수 선언
- Adaptor 패턴
-> 클래스의 재사용성을 높이기 위해 요구되는 특정 기능으로 변환, 적용하여 클래스간의 호환성을 확보
-> wrapper 패턴
-> 상속을 이용한 Adaptor
-> 위임을 이용한 Adaptor
- Facade 패턴
-> 복잡한 내부 구조를 보이지 않으면서 외부와의 일관된 인터페이스를 제공하는 패턴
- Chain of Responsibility 패턴(책임 패턴)
-> 요청을 처리 할 수 있는 기회를 하나 이상의 객체에 부여 -> 객체 간 결합도 없앰
-> 요청을 해결할 객체를 만날때까지 객체 고리를 따라서 요청을 전달하는 패턴
-> 책임 패턴은 수행의 책임을 연결된 다른 클래스에게 인계함
-> 하나 이상의 객체의 요청을 처리해야 하는 경우, 핸들러가 누가 선행자인지 모를 때 사용
-> 유기적으로 연결된 여러 객체들 중 하나의 객체에 요청을 전달할 때 사용
- Command 패턴
-> 동작이나 트랜잭션에 대한 요청을 객체를 통해 캡슐화함으로써 해당 요청을 저장하거나 로그에 기록
-> Undo, Redo 등의 기능을 제공하고자 하는 설계
정보처리기사 실기 - 2. 데이터 입출력 구현(1) /정규화
1) 논리 데이터 저장소 확인하기 - 논리 데이터 저장소 확인 절차 -> 엔티티 및 속성 확인 엔티티의 누락/중복 확인 속성을 확인하여 물리 테이블의 컬럼으로 전환 가능한지 여부 확인 공통 코드
aapslie94.tistory.com
'전공 > 정보처리기사 실기' 카테고리의 다른 글
| 정보처리기사 실기 - 2. 데이터 입출력 구현(2) /인덱스/반정규화 (0) | 2021.04.03 |
|---|---|
| 정보처리기사 실기 - 2. 데이터 입출력 구현(1) /정규화 (0) | 2021.04.03 |
| 정보처리기사 실기 - 1. 요구사항 확인(2) /애자일 방법 (0) | 2021.04.01 |
| 정보처리기사 실기 - 1. 요구사항 확인(1) /현행시스템/아키텍처 (0) | 2021.04.01 |
| 정보처리기사 실기 독학 후 합격 후기 (0) | 2021.03.31 |