[2020 정보처리기사 실기] Section 02 . 요구사항 확인

오랜만에 글쓴당 > <

 

020 . 개발 기술 환경 파악 

 

1. 개발 기술 환경이란?

    개발하고자 하는 소프트웨어와 관련 된 OS,DBMS등을 선정할 때 고려해야 할 사항을 기술하고 Open Source 사용시 주의해야 할 내용을 제시

 

2. OS

    - 운영체제는 컴퓨터 시스템의 리소스들을 효율적으로 관리

    - 컴퓨터 사용시 사용자에게 편의성과 효율성을 증대시킬 수 있는 환경 제공

    - OS 관련 요구사항 식별 시 고려사항

          1. 가용성 : 프로그램이 주어진 시점에서 요구사항에 따라 운영 될 수 있는 능력

          2. 성능

          3. 기술 지원 ; 오픈소스 여부

          4. 주변 기기

          5. 구축 비용 ; * TCO(Total Cost of Ownership):총 소유 비용

 

3. DBMS

    - 사용자와 데이터 베이스 사이에서 사용자의 요구에 따라 정보를 생성 및 관리 

    - 데이터의 종속성 및 중복성 문제 해결 

    - DBMS 관련 요구사항 식별 시 고려사항

          1. 가용성 

          2. 성능

          3. 기술 지원

          4. 상호 호환성

          5. 구축 비용

 

4. WAS(Web Application Server)

   - 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리 하기 위해 사용되는 미들웨어(Miiddle Ware) 

   - Tomcat, JBOss, Jetty 등

   - WAS 관련 요구사항 식별 시 고려사항

          1. 가용성

          2. 성능

          3. 기술지원

          4. 구축 비용

 

021 . 요구사항 정의  

 

1. 요구사항의 유형( 기능, 비기능, 사용자, 시스템 )

     - 기능 요구사항(Functional requriement) : 시스템에 관련된 거

     - 비기능 요구사항(Non-Functional requriement) : 시스템 빼고 다른거, 장비, 성능(처리 속도 및 시간, 가용성등), 인터페이스 , 데이터, 테스트, 보안등 

     - 사용자 요구사항(User requirement) : 사용자 관점

     - 시스템 요구사항(System requirement) 또는 소프트웨어 요구사항 : 개발자 관점

 

2. 요구사항 개발 프로세스

 

     개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서에 정리한 다음 마지막으로 이를 확인 및 검증한다.

 

     * 요구공학 : 요구사항을 정의하고 분석 및 관리하는 공학

 

    - 도출(요구사항 수집)

          - 요구 사항 도출은 SDLC(Software Developement Life Cycle)동안 지속적으로 반복

          - 인터뷰, 설문,워크샵, 프로토타이핑 등 방법이 있음

 

 

022 . 요구사항 분석 기법

 

1. 기법에는 분류, 개념 모델링, 할당, 협상, 정형 분석이 있음.

     - 분류 : 분류 기준에는 

            1) 기능/비기능

            2) 상위 요구사항에서 유도된것인지 이해관계자나 다른 자원으로부터 직접 발생한건지

            3) 제품에 관한건지 프로세스(개발 과정)에 관한건지

            4) 우선 순위

            5) SW가 미치는 영향의 범위

            6) SLC(Software Life Cycle) 동안에 변경될 가능성의 여부

 

 

     - 개념 모델링 : 개체(Entity)와 관계 및 종속성 반영하여 모델링 ex. 유스케이스 다이어그램, 데이터 플로우 모델, 상태 모델, 데이터 모델

            - 모델링 표기는 주로 UML(Unified Modeling Laguage) 사용

 

    - 할당 : 요구사항 만족을 위한 구성요소 식별

    - 정형 분석 : 구문과 의미를 갖는 정형화된 언어를 이용해 수학적 기호로 표현(정형 명세)한 뒤 분석 *마지막에 함

 

 

023 . 요구사항 확인 기법

 

1. 요구사항 확인 기법에는 검토, 프로토 타이핑, 모델 검증, 인수 테스트(사용자가 실제로 사용도리 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정) 이 있다.

     - 검토는 시스템 정의서, 시스템 사양서등을  완성한 시점에 이루어짐

     - 프로토 타입은

            - 장점 : 빠르게 제작하고 반복적인 제작으로 발전된 결과물 획득 가능

            - 단점 : 비용 부담 증가,사용자가 프로토타입의 개발에만 집중할 수 있음

     - 모델 검증에서 객체 모델같은 경우, 객체 사이의 의사소통 경로를 검증하기 위해 Static Analysis 를 수행하는것이 유용; 직접실행하지 않고 도구나 명세서의 정확성/일관성만 확인하는것 <-> 실행하는건 Dynamic Analysis

     - 인수테스트에는 사용자/운영상 인수테스트, 규정 인수 테스트, 알파/베타 검사가 있음

 

 

024 . UML(Unified Modeling Language)

 

1. UML은 시스템 개발과정에서 사람과 사람간의 의사소통의 원활함을 위한 대표적으로 표준화 된 객체 지향 모델링 언어

    - 사물, 관계, 다이어그램이 있음

           - 사물 : 모델 구성 가장 중요 구성 요소(구조, 행동, 그룹, 주해)

                    1) 구조 사물 : Class, Use Case, Component(모듈화 된 자원), Node

                    2) 행동 사물 : Interaction, State Machine

                    3) 그룹 사물 : Package

                    4) 주해(Annotation) 사물 : Note

 

          - 관계 : 연관, 집합, 포함, 일반화, 의존, 실체화 관계가 존재함 

                 - 연관 관계 :                 

다중도	의미
1	1개의 객체가 연관되어 있다.
n	n개의 객체가 연관되어 있다.
0..1	연관된 객체가 없거나 1개만
0.. or ..	연관된 객체가 없거나 다수
1..	연관된 객체가 적어도 1개 이상
n..	연관된 객체가 적어도 n개 이상
n..m	연관된 객체가 최소 n 최대 m

               - 집합 관계 : 포함 하는 쪽(Whole) 포함되는 쪽(Part) 둘은 서로 독립적 (이제부터 나오는 화살표들은 특정 지시 없는 한 점선이 아님)

                    - (포함하는 쪽)◇ㅡㅡㅡ(포함되는 쪽) 으로 표현 

               - 포함 관계 : 집합 관계의 특수한 형태  : Whole과 Part는 독립될 수 없음 Life Cycle을 함께 해야 함

                    - (포함하는 쪽)◆ㅡㅡㅡ(포함되는 쪽) 으로 표현

              - 일반화 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현(일반적인 개념쪽으로 빈 화살표로 표시)

                    - 커피 <---- 아메리카노

              - 의존 관계 : 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표시

                   - 등급 ------> 할인율

              - 실체화 관계 : 사물에서 기능쪽으로 속이 빈 점선 화살표를 연결하여 표현, 기능으로 서로를 그룹화 할 수 있는 관계를 이야기함

                   - 날 수 있는 <------새 

              - 다이어그램 : 구조적 다이어그램과 행위(Behavioral) 다이어그램이 있음. 정적 모델링은 주로 구고적, 동적 모델링은 주로 행위

                     - 구조적 다이어그램 : 클래스, 객체, 컴포넌트,배치 등 * 컴포넌트와 배치(Deployment)는 구현단계에서 사용됨; 컴포넌트는 구현 모듈간의 관계, 배치는 물리적 요소들의 위치 표현

                     - 행위 다이어그램 : 유스케이스, 커뮤니케이션, 상태,활동 등 이..시상은 유행이 커 

 

집합 포함 의존이 햇갈린다.

흠...

 

• 집합 : 야구선수에게는 팬이 있으며, 팬은 다른 야구선수의 팬이 될 수도 있다.
• 집합 : 프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결해서도 사용할 수 있다.

 

• 포함 : 야구선수는 하나의 팀에 소속되어 팀이 해체되면 야구선수도 더 이상 필요가 없다.
• 포함 : 문을 열 수 있는 키는 하나이며, 문이 없어지면 이 키도 더 이상 필요가 없다.

 

• 의존 : 야구선수의 승점이 높으면 연봉을 조정하고, 그렇지 않으면 조정하지 않는다.
• 의존 : 등급이 높으면 할인율을 적용하고, 그렇지 않으면 적용하지 않는다.

025 . Use Case 다이어그램 * 25와 26은 UML 기능 모델링에 속함

1. 시스템을 이용해 수행 할 수 있는 기능을 사용자의 View에서 표현한 것 

 

https://en.wikipedia.org/wiki/Use_case_diagram

1. Actor : 시스템과 상호작용을 하는 모든 외부 요소, 액터 이름은 구체적이면 안된다(홍길동 이렇게) 

     - Primary Actor : 시스템 사용으로 이득을 얻는 대상으로 주로 사람이며 왼쪽에 배치

     - Secondary Actor : 서비스를 제공하는 외부 시스템으로 주로 오른쪽에 배치하며 시스템명을 사각으로 묶은 후 상 단에 <<Actor>>라고 표시

2. Use Case : 상단 그림에 있는 타원을 의미하므로 시스템이 엑터한테 제공하는 서비스나 기능

    - 원자성을 가져야함 

3. RelationShipe 모두 표현은 Guillemet, 즉 <<?>> 안에 표기

    - Include : 예를 들어, 상품주문 시스템에서 주문,배송조회,리뷰작성은 "로그인"을 해야하므로 3가지는 로그인에 포함

    - extend : 예를 들어, 리뷰작성 유스케이스가 사진업로드와 확장관계 

    - Generalization : 예를 들어, 고객이 회원/비회원이라 치면 고객액터와 회원/비회원액터는 일반화 관계

 

026 . Active 다이어그램 * 25와 26은 UML 기능 모델링에 속함 

1. 활동 다이어그램은 액션, 액티비티, 노드, 스윔레인(스윔레인은 Active 다이어그램에만 존재한다)으로 구성; 자료 흐름도(Data Flow Diagram)과 유사

 

https://en.wikipedia.org/wiki/Activity_diagram

    - 액션/ 액티비티 

          - 액션은 원자성을 가지며, 액티비티는 몇개의 액션으로 분리가 가능 

    - 시작/ 종료 노드 각각 ●/⊙ 로 표현 

    - 조건 노드 : 마름모로 표현 들어오는 제어 흐름은 단 하나! 

    - 병합 노드 : 여러 경로 흐름이 하나로 합쳐짐 , 마름모로 표현 나가는 제어 흐름은 단 하나!

    - 포크(Fork) 노드: 액티비티의 흐름이 분리되어 수행됨 , 굵은 가로선 들어오는 액티비티의 흐름은 단 하나!

    - 조인(Join) 노드 : 액티비티의 흐름이 다시 합쳐짐, 굵은 가로선 나가는 액티비티 흐름은 단 하나!

    - 스윔레인(Swim Lane) : 액티비티 수행을 담당하는 주체를 구분함, 가로 또는 세로 실선을 그어 구분, 위 사진에는  안나와있고 아래 처럼 가운데 실선 쫘악

 

https://images.app.goo.gl/dgRPkA6Nc78DK76eA

 

027 . Class 다이어그램

 

1. 정적 모델링의 개념 : 시스템에 의해 처리되거나 생성될 객체들 사이간의 관계를 구조적 관점에서 표현

    - 객체들을 클래스로 추상화하여 표현

    - 정적 모델링의 대표가 class 다이어그램

https://en.wikipedia.org/wiki/Class_diagram

https://en.wikipedia.org/wiki/Class_diagram

- 클래스, 제약조건, 관계등으로 구성

    - 클래스 : 위 사진에서 두번 째 사진이 클래스, 클래스의 이름, 속성, 오퍼레이션 3개의 Compartment로 나뉘어 구분

          - 속성 : [접근 제어자] 속성명 : 자료형 [다중성][=초기값] ; 다중성이 뭐냐면 여러개의 속성 값을 가지는것으로  배열을 생각하면 된다.

                - 접근제어자는 public +, private -, protected #, package ~

          - 오퍼레이션 : [접근 제어자] 오퍼레이션명(매개변수 :자료형):반환자료형

          - 제약 조건 : 아래와 같은 주석 도형안에 조건을 적음 클래스 안에 적을 때는 { 연봉>1500 } 이런식으로 적음 

주석 도형

  - 관계 : UML 공부 할때 랑 같이 연관, 집합, 포함, 일반화, 의존관계가 존재함.

 

 

028 . Sequence 다이어그램 *28부터 30까지는 UML 동적 모델링

 

1. uml 동적 모델링의 대표 다이어그램으로는 시퀀스,상태,커뮤니케이션 다이어그램이 있다.

2. 동적 모델링은 시스템의 내부 구성 요소들의 상태가 시간의 흐름에 따라 변화는 과정중에 발생하는 상호작용을 표현함

3. 오퍼레이션을 통한 상호작용에 초점을 둠

https://en.wikipedia.org/wiki/Sequence_diagram

https://images.app.goo.gl/redNM48X6ZYf6Q9N9

4. 액터, 객체, 라이프라인, 활성 상자, 메시지등으로 구성됨.

    - 액터 : 서비스를 요청하는 외부 요소 

    - 객체 : 메시지를 주고 받는 주체 

    - 라이프라인 : 객체 아래쪽에 점선을 그어 표시 

    - 활성 상자 : 라이프 라인상에 겹쳐서 직사각형 상태로 표현

    - 메시지 : 화살표로 표현

  - 객체 소멸 : 객체 소멸 표시는 진한 엑스 X로 표현

  - 프레임 : 다이어그램 전체 또는 일부를 묶어서 표현 , 왼쪽 위에 다이어그램의 종류와 제목을 표기

 

029 . Comunication 다이어그램 *28부터 30까지는 UML 동적 모델링

1.  compunication은 sequence처럼 메시지를 표현하는데, 이 뿐 아니라 관계까지도 표현하며 초기에는 Collaboration diagram이라고도 불림

 

https://www.uml-diagrams.org/communication-diagrams.html

2. 링크 : 관계를 표현할 때 사용한다. 

 

030 . State 다이어그램 *28부터 30까지는 UML 동적 모델링

 

1. 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태변화를 그림으로 표현 함

 

https://www.geeksforgeeks.org/unified-modeling-language-uml-state-diagrams/

 

    - 상태 : 상태는 둥근 사각형 안에 기술한다.

    - 상태 전환 : 화살표에 표시 

    - 이벤트 : 상태에 변화를 주는 현상

          - 조건 : 예를 들어 결제 정보가 입력되어 결제 준비 상태가 경제 대기 상태로 전환 되었을 때 

          - 외부 신호 : 외부 결제 시스템으로부터 결제 정보가 일치한다는 신호를 받아 대기가 완료가 되었을 때

          - 시간의 흐름

 

++ 추가

 

현행 시스템 파악 과정

 

시스템 구성 현황 파악/ 시스템 기능 파악/ 시스템 인터페이스 현황 파악 ▶ 아키텍쳐 구성 파악, 소프트 웨어 구성 파악 ▶ 하드웨어 구성 파악, 네트워크 구성 파악

 

구조적 다이어그램 : Class, Object, Component 등

행위 다이어그램 : Usecase, Communication, Sequence 등

 

 

다음글 : 2020/04/14 - [2020년도 상반기/정처기] - [2020 정보처리기사 실기] Section 03 . 데이터 입력 및 출력 구현(1/3)