bread, coffee and coding
정보처리기사: 2021년 05월 15일 기출 문제 풀이 1과목 본문
쪼개기 공부
1. 소프트웨어 설계
1.시스템의 구성요소로 볼 수 없는 것은?
1.Process
2.Feedback
3.Maintenance
4.Control
시스템의 구성요소
입력(Input) / 출력(Output) / 제어(Control) / 처리(Process) / 피드백(Feedback)
<입력이 있으면 결과값이 출력이 나와야하며 제어를 하면 처리가 되고 그에 따른 피드백이 필요> ->이런식으로 외우면 쉽게 외워진다
? -> Maintenance은 뭘까
maintenance의 뜻 유지 관리라는 뜻 유지보수는 구성요소가 아니다.
답. 3
2. 유스케이스(Usecase)에 대한 설명 중 옳은 것은?
유스케이스 다이어그램에 개념를 알아보자
유스케이스 다이어그램은 개발된 시스템과 관련되 외부 요소들 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것이다.
-> 즉 사용자의 관점에서 시스템의 범위를 파악하기 편하다.
구성요소
시스템 범위(System scope) / 액터(Actor) / 유스케이스(Usecase) / 관계(Relation)
시스템범위(System scope)
시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어서 시스템 범위를 표현한다.
액터(Actor)
- 시스템과 상호작용을 하는 모든 외부요소로, 사람이나 외부시스템을 의미 (외부 요소 이므로 시스템 밖에 표현)
- 액터는 주액터와 부액터가 있다
주액터(Actor)
- 시스템을 사용함으로써 이득을 얻는 대상 주로 사람이 해당하며 주로 왼쪽에 배치
부액터(Primary Actor)
- 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로 조직이나 기관등이 될 수 있다. 주로 오른쪽에 표현
관계(Relation)
- 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있다.
- 포함관계(Include) / 확장관계(Extends) / 일반화 관계가 있다.
1_ ) 유스케이스 다이어그램은 개발자의 요구를 추출하고 분석하기 위해 주로 사용한다. (x)
? -> 사용자의 관점에서 시스템의 범위를 파악하기 위해 주로 사용한다
2_) 액터는 대상 시스템과 상호 작용하는 사람이나 다른 시스템에 의한 역할이다.. (o)
? -> 액터는 시스템과 상호작용을 하는 모든 외부요소이다
3_) 사용자 액터는 본 시스템과 데이터를 주고받는 연동 시스템을 의미한다. (x)
? -> 사용자 액터= 주액터 기능을 요구하는 대상이나 시스템의 수행결과를 통보 받는 사용자 혹은 기능을 사용하게 될 대상
4_) 연동의 개념은 일방적으로 데이터를 파일이나 정해진 형식으로 넘겨주는 것을 의미한다. (x)
? -> 연동이란 연결되어 자료를 교환할 수 있는 능력
답. 2
3. 요구사항 개발 프로세스의 순서로 옳은 것은?
ㄱ. 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 식별하고 이해하는 과정 (요구사항 도출)
- 개발자와 고객사이의 관계가 만들어짐
요구사항 도출 주요 기법에는 1- 청취와 인터뷰 2 - 설문 3 - 브레인스토밍 4 - 워크샵 5- 프로토타이핑 6 - 유스케이스 가 있다.
ㄴ. 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 요구사항의 타당성을 조사하고 비용과 일정 조율
- 서로 원하는 요구 사항이 있으면 이를 조절 및 중재
요구사항 분석에 사용되는 대표적인 과정은 1 - 자료 흐름도 2 - 자료 사전등 이있다
ㄷ. 요구사항 명세
- 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미
- 기능 요구사항을 빠짐 없이 기술하는 것이 중요 빠지면 책임을 물어야함
- 비기능 요구사항은 필요한 것만 기술 가능
ㄹ. 요구사항 확인
- 요구사항 명세서가 누락없이 정확하고 완전하게 작성되었는지를 검토하는 활동
- 이해관계자들이 검토를 해야함
즉 도출 -> 분석 -> 명세 -> 확인 순서이다.
답. 1
4. 객체지향 기법에서 같은 클래스에 속한 각각의 객체를 의미하는 것은?
1. instance
2. message
3. method
4. module
객제지향 기법에 대하여 알아보자
객제지향 기법
- 현실의 객체(엔티티 Entity)를 하나의 객체(오브젝트 Object)로 만들어 소프트웨어를 개발할 때 객체들을 이용해 프로그램을 작성할 수 있도록 하는 기법
구성요소
1 - 객체(Object)
- 데이터와 데이터를 처리하는 함수를 캡슐화한 소프트웨어 모듈
- 데이터 : 객체 정보, 속성(Attribute) , 상태 등을 나타낸 것
- 함수 : 객체가 수행하는 기능, 객체가 갖는 데이터(속성, 상태)를 처리하는 알고리즘
2 - 클래스(Class)
- 공통된 속성, 연산을 갖는 객체들의 집합
- 인스턴스(Instance) : 클래스에 속한 각각의 객체 / 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(instantiation)라고함
- 슈퍼클래스(Superclass) : 상위 Class (특정 클래스의 상위(부모) 클래스를 의미)
- 서브클래스(Subclass) : 하위 Class (특정 클래스의 하위(자식) 클래스를 의미)
-최상위 클래스는 상위 클래스를 갖지 않은 클래스를 의미한다
3 - 메시지(Message)
- 객체들 간 상호작용을 하기 위한 수단
- 객체 이름, 메소드 이름, 인자로 구성
답. 1
5. 객체 지향 설계에서 가지고 있는 속성과 오퍼레이션의 일부를 감추어서 객체의 외부에서 접근이 불가능하게 하는 개념은?
특징
1 - 캡슐화(Encapsulation)
- 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것을 의미한다
- 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부에서의 접근이 제한적이기 때문에 외부 모듈의 변경으로 인한 파급 효과가 낮음
- 캡슐화된 객체들은 재사용이 용이함
- 인터페이스가 단순, 객체간의 결합고가 낮아진다
2 - 정보 은닉(Information hiding)
- 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근
- 다른 객체에게 주는 영향을 감소 시킴
3 - 추상화(Abstractiom)
- 불 필요한 부분을 생략하고 중요한 것에만 중점을 두어 모델화
4 - 상속성(Inheritance)
- 이미 정의된 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것
- 하위 클래스는 상위 클래스의 모든 속성과 연산을 자신의 클래스 내에서 즉시 자신의 속성으로 사용함
- 하위 클래스는 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다
- 객체와 클래스의 재사용, 즉 소프트웨어의 재사용을 높이는 중요한 개념
다중상속이란? : 한개의 클래스가 두개 이상의 상위 클래스로 부터 속성과 연산을 상속 받는 것
5- 다형성(Polymorphism)
- 객체가 연산을 수행하게 될 때 하나의 메시지에 대한 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할수 있는 능력
설명만 보면 헷갈릴수있다. ?-> '+' 연산자 같은 경우 숫자 클래스에서는 덧셈으로 사용하지만 문자 클래스에서는 문자열 연결 기능으로 사용가능
캡슐화를 통해 정보은닉을 가능하게 함
답. 2, 3
6. GoF(Gangs of Four) 디자인 패턴에 대한 설명의로 틀린 것은?
GoF(Gangs of Four)에는 23가지 디자인 패턴을 3가지 유형으로 분류합니다 .
1 - 생성패턴(Creational Pattern) 2 - 구조패턴(Structural Pattern) 3 - 행위패턴(Behavioral Pattern)
생성패턴
- 객체의 생성과 관련된 패턴
- 객체의 생성, 참조 과정을 캡슐화 -> 객체가 생성, 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 유연성을 더해줌
구조패턴
- 클래스나 객체를 조합해, 더 큰 구조로 만들 수 있게 해주는 패턴
- 구조가 복잡한 시스템을 개발하기 쉽게 도와줌
행위패턴
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
- 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와줌
1) 생성패턴에는
1 - 추상팩토리(Absreact Factory)
- 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
- 연관된 서브 클래스를 묶어 한번에 교체하는 것이 가능
2 - 빌더(bulider)
- 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체를 생성
- 객체의 생성 과정과 표현 방법을 분리 -> 동일 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있다
3 - 팩토리 메소드(Factory Method)
- 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
- 상위 클래스에서 인터페이스만 정의, 실제 생성은 서브 클래스가 담당
4 - 프로토타입(Prototype)
- 원본 객체를 복제하는 방법으로 객체을 생성하는 패턴
- 비용이 큰 경우 주로 이용
5 - 싱글톤(Singleton)
- 하나의 객체를 생성하면 생성된 객체를 어디서든 참조 가능, 여러 프로세스가 동시에 참조할 수는 없다
- 클래스 내에 인스턴스가 하나뿐임을 보장, 불필요한 메모리 낭비를 최소화 가능
2) 구조패턴에는
1 - 어댑터(Adapter)
- 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
- 인터페이스가 일치하지 않을 때 이용
2 - 브리지(Bridge)
- 구현부에서 추상층을 분리 -> 서로 독립적으로 확장할 수 있도록 구성한 패턴
- 기능과 구현을 두 개의 별도 클래스로 구현
3 - 컴포지트(Composite)
- 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용한다
- 복합 객체 안에 복합 객체가 포함되는 구조를 구현 가능하다.
4 - 데코레이터(Decorator)
- 객체 간 결합을 통해 능동적으로 기능을 확장할 수 있는 패턴
5 - 퍼싸드(Facade)
- 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간펴하게 사용할 수 있도록 하는 패턴
- 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요
6 - 플라이웨이터(Flyweight)
- 가능한 한 공유에서 사용함으로 메모리를 절약하는 패턴
- 다수의 유사 객체를 생성하거나 조작할 때 유용
7 - 프록시(Proxy)
- 접근 어려운 객체와 여기에 연결하려는 객체 사이에 인터페이스 역할을 수행하는 패턴
- 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 이용
3) 행위패턴에는
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
- 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와줌
1 - 책임연쇄(Chain of Responsibility)
- 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
- 요청을 처리할 수 있는 각 객체들이 고리로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감
2 - 커맨드(Command)
- 요청을 객체 형태로 캡슐화 -> 재이용하거나 취소할 수 있도록 요청에 필요 정보를 저장하거나 로그를 남기는 패턴
- 요청에 사용되는 각종 명령어들을 추상 클래스(인스턴스 생성 불가)와 구체 클래스로 분리, 단순화
3 - 인터프리터(Interpreter)
- 언어에 문법 표현을 정의하는 패턴
- SQL, 통신 프로토콜 같은 것 개발 시
4 - 반복자(Iterator)
- 접근이 잦은 객체에 대해 동일 인터페이스를 사용하도록 하는 패턴
- 내부 표현 방법의 노출 없이 순차적 접근이 가능
5 - 중재자(Mediator)
- 수만은 객체들 간 복잡한 상호작용을 캡슐화 -> 객체로 정의하는 패턴
- 객체 사이의 의존성 줄여 결합도를 감소시킬 수 있음
6 - 메멘토(Memento)
- 특정 시점에서의 객체 내부 상태를 객체화함 -> 요청에 따라 해당 시점의 상태로 돌릴 수 있는 기능을 제공
- 되돌리기 기능 같은 것 개발 시
7- 옵저버(Observer)
- 한 객체의 상태가 변화하면 객체에 상속된 다른 객체들에게 변화된 상태를 전달하는 패턴
- 분산된 시스템 간 이벤트를 생성, 발행하고 이를 수신해야 할 때 이용
8 - 상태(State)
- 상태에 따라 동일 동작을 다르게 처리해야 할 때
- 객체 상태를 캡슐화하고 이를 참조하는 방식으로
9 - 전략(Strategy)
- 동일 계열 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
- 클라이언트관련 원하는 알고리즘을 선택하여 상요 가능 , 클라이언트에 영향 없이 알고리즘 변경 가능
10 - 템플릿 메소드(Template Method)
- 상위 클래스에 관하여 골격 정의하고 하위클래스에서는 세부 처리를 구체화하는 구조의 패턴이다
- 유사 서브 클래스를 묶어 공통된 내용을 사우이 클래스로 정의함 -> 코드 양을 줄이고, 유지보수를 용이하게 함
11 - 방문자(Vistor)
- 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
- 분리된 처리 기능은 각 클래스를 방문하여 수행
1. factory method pattern은 상위클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록 하는 방식이다.
?-> 생성패턴의 팩토리 메서드
2. prototype pattem은 prototype을 먼저 생성하고 인스턴스를 복제하여 사용하는 구조이다.
?-> 생성패턴의 프로토 타입
3. bridge pattem은 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 한다.
?-> 구조패턴의 브리지 / 3번에 대한 설명은 구조패턴의 어댑터에 대한 설명이다
어댑터:호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
4. mediator pattem은 객체간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성하게 해준다.
?-> 행위패턴의 중재자
답 . 3
7. 요구사항 분석이 어려운 이유가 아닌 것은?
1. 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다.
2. 사용자의 요구는 예외가 거의 없어 열거와 구조화가 어렵지 않다.
3. 사용자의 요구사항이 모호하고 불명확하다.
4. 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다.
사용자의 요구는 예외가 많아 열거와 구조화가 어렵다 -> 이 말이 맞는 말이다
답. 2
소프트웨어 아키텍처 설계에 대해 알아보자
소프트웨어 아키텍처는 소프트웨어의 골격이 되는 기본 구조이자 소프트웨어 구성 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체이다.
쉽게 설명하자면 건축 설계랑 비슷하다
요구사항에 맞게 건물의 용도와 형태를 정하고, 땅을 어떻게 다질지, 골격은 어떻게 세울것인지 대략적인 것을 정하는 과정이라고 생각하면 될 것 같다
소프트웨어 아키텍처 설계의 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보 은닉이 있다.
소프트웨어 아키텍처 설계의 시스템 측면 품질 속성은
성능 / 보안 / 가용성 / 기능성 / 사용성 / 변경 용이성/ 확정성 / 이있다
성능: 사용자 요청 같은 이벤트가 발생했을 때, 이를 적절하고 빠르게 처리하는 것
보안: 허용되지 않은 접근을 막고, 허용된 접근에는 적절한 서비스를 제공하는 것
가용성: 장애 없이 정상적으로 서비스를 제공하는 것
기능성: 사용자가 요구한 기능을 만족스럽게 구현하는 것
변경 용이성: 소프트웨어가 처음 설계 목표와 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현하는 것
확장성: 시스템의 용량, 처리능력 등을 확장시켰을 때 이를 효과적으로 활용할 수 있도록 구현하는 것
소프트웨어 아키텍처 설계의 비즈니스 측면 품질 속성은
시장 적시성 / 비용과 혜택 / 예상 시스템 수명 / 이 있다
시장 적시성: 정해진 시간에 맞춰 프로그램을 출시하는 것
비용과 혜택: 개발 비용을 더 투자하여 유연성이 높은 아키텍처를 만들 것인지를 결정하는 것
예상 시스템 수명: 시스템을 얼마나 오랫동안 사용할 것인지를 고려한는 것
소프트웨어 아키텍처 설계의 아키텍처 측명 품질 속성은
개념적 무결성 / 정확성, 완결성 / 구축 가능성 / 이 있다
개념적 무결성: 전체 시스템과 시스템을 이루는 구성요소들간의 일관성을 유지하는 것
정확성, 완결성: 요구사항과 요구사항을 구현하기 위해 발생하는 제약사항들을 모두 충족시키는 것
구축 가능성: 모듈 단위로 구분된 시스템을 적절하게 분배하여 유연하게 일정을 변경할 수 있도록 하는 것
소프트웨어 아키텍처의 설계 과정
설계 목표 설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브 시스템 구체화 -> 검토
답. 2
연계 메커니즘에 대해 알아보자
연계 메커니즘 구분
송신 시스템 / 수신 시스템 / 중계 서버/
송신 시스템:
송신 시스템은 운영 데이터베이스, 애플리케이션으로부터 연계 데이터를 인터페이스 테이블 또는 파일로 생성하여 송신한다.
수신 시스템:
수신 시스템은 수신한 인터페이스 테이블 또는 파일의 데이터를 변환하여 운영 데이터베이스에 반영한다.
중계서버 :
송수신 시스템 사이에 데이터 송수신과 송수신 현황 모니터링 역할을 하는 중계 서버를 배치할 수도 있다. /중계 서버 배치는 성능과 보안의 품질 특성중 보안이 더 중요하거나 송신 시스템이 위치한 네트워크와 수신 시스템이 위치한 네트워크가 상이한 경우 주로 설계하는 아키텍처 방식이다.
답. 3
CASE의 원천 기술은
구조적 기법 프로토타이핑 정보 저장소 자동프로그래밍 분산처리가 있다.
11. 객체에게 어떤 행위를 하도록 지시하는 명령은?
1.Class
2.Package
3.Object
4.Message
클래스: 객체를 정의해놓은 것. 객체의 설계도 ,틀
12 번 관련
아키텍처 스타일이란 기존의 시스템이나 애플리케이션을 개발자가 아닌 다른 사람이 유지지보수를 해야 하는 경우
서로 설계 방식이 달라 코드를 분석하는데 많은 어려움이 따름 -> 이를 해결하기 위해 많은 사람들 또는 신뢰 있는 기관에서 검즘된 보편전인 설계 방법의 양식들을 사용하는데, 이것을 아키텍쳐 스타일이라고 함
IEEE 1471 -> ANSI/ IEEE 1471 - 2000의 약어이다
특징
표준화 : 아키텍처 관련 용어와 개념들을 통일함
중립성: 모델링 언어와 방법론을 제시하지 않고, 독립적인 메타 모델을 제공함
유연성: 표현을 위한 요소들과 관계의 일반화로 규모에 상관없이 시스템 구축에 적용이 가능함
의사소통: 이해당사자 간의 의사소통을 지원하고, 다양한 관점에서 표현함
구성요소
Architectural Description(AD) : 시스템 구축시 아키텍처가 기록되는 방법
(파번)이라고 하겠음 파파고 번역: 아키텍처럴 디스크립션 -> 건축 설명
Stakeholder : 소프트웨어 시스템 개발에 관련된 모든 이해 당사자를 의미
파번: 스테익호울더 : 이해관계자
Concerns: 시스템의 성능, 유지보수, 보안 ,분배 등과 같은 스테익홀더들의 의견과 목표
파번: 컨선즈 : 걱정이라는 뜻
veiw : Stakeholder들이 가지는 관점으로 전체 시스템을 표현하거나 묘사하는 방법
veiwpoint 도 있음
저장소 구조(Repository Architecture) 뜻 기록관, 저장소 아키텍처라는 뜻
중앙자료구조와 독립된 컴포넌트로 구성된 아키텍처 큰 데이터의 이동 및 공유에 적합, 컨포넌트간의 통신은 이뤄지지 않음
Component : 파번 뜻 구성요소, 부품, 요소
MVC 구조 ( Modle / view/ Controller Architecture)
모델, 뷰, 컨트롤러의 세개의 컴포넌트로 구분하는 아키텍처이다
유저 인터페이스와 비즈니스 로직들을 서로 분리하여 개발하는 방법이다
인터페이스란 : 접속 장치라고 생각하면 편하다
클라이언트 서버 구조(Client/Server Architecture)
클라이언트와 서버로 나뉘는 아키텍쳐를 말한다
계층 구조 (Layered Architecture)
계층적으로 조직화가 되어있는 아키텍처
계층에 관한 이야기가 나오면 계층구조라고 생각하자
파이프 필터 구조(Pipes and Filters Architecture)
데이터의 흐름을 점진적으로 처리하는 시스템을 위한 아키텍처이다
13.럼바우(Rumbaugh)의 객체지향 분석에서 사용하는 분석 활동으로 옳은 것은?
럼바우 객체지향 분석 기법이란?
소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델리하는 객체지향 분석 기법이다
럼바우 객체 지향 분석에서 사용하는 분석 활동은
객/동/기
객체 모델링 : 객체 다이어그램, 정보 모델링이라고 하고 시스템에서 요구하는 객체를 찾고
객체들 간의 관계를 정의
객체들 간의 관계 -> 객체모델링
동적 모델링 : 상태 다이어그램이라고도함 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서등의 동적인 행위를 표현
기능 모델링: 자료흐름도(DFD), 프로세스들의 자료 흐름을 중심으로 처리 과정을 표현
순서
객체들 간의 관계를 정의하고 -> 객체들 사이의 제어나 흐름 동작 순서를 정함 - > 프로세스들의 자료 흐름을 중심으로 처리 과정을 표현
객체 -> 동적 -> 기능
14. UML 다이어그램이 아닌 것은?
UML(Unifed Modeling Language) 이란??
유니프트 모델링 렌기지 -> 통일된 모델링 언어라는 뜻.
시스템 개발 과정에서 개발자와 고객 혹은 개발자 상호간의 원활한 의사소통을 위해 표준화한 객체지향적 모델링 언어
즉 개발자와 개발자 또는 고객이 원활한 소통을 하기 위해 통일된 모델링 언어라고 생각하면 쉽다
UML의 구성 요소: 사물, 관계 ,다이어그램이 있다.
사물(Things)란:
다이어그램안에서 관계가 형성될 수 있는 대상을 말함
즉 행동, 구조, 그룹등등 대상을 말한다고 생각하면 됨
관계(Relationships)란:
사물과 사물사이의 연관성을 표현한것
즉 사물과 사물사이 관계를 표현한것이라고 생각하면 됨
다이어그램(Diagram)란:
사물과 관계를 도형으로 표현한것
즉 사물과 관계를 그림으로 표현했다고 생각하면 됨
다이어그램도 종류가 있다
구조적 다이어그램과 행위적 다이어그램
클래스 다이어그램: 클래스 사이의 관계를 표현한것
객체 다이어그램: 객체 사이의 관계를 표현한것
컴포넌트 다이어그램: 컴포넌트의 인터페이스나 관계를 표현, 구현 단계에서 사용한다.
요소들의 접속기(호출기?)나 관계를 표현
배치 다이어그램: 물리적 위치를 표현, 구현 단계에서 사용
물리적인 위치가 어디인지를 표현한것이다(주소)
복합체 구조 다이어그램과 패키지 다이어그램이 있다
행위적 다이어그램
유스케이스 다이어그램: 사용자의 요구를 분석, 모델링 작업에 사용됨
시퀀스 다이어그램: 시스템이나 객체가 주고 받는 메시지를 표현
sequence 파번: 순서를 정하다, 결정하다 , 차례 절차 등 뜻이 있다
시스템이나 객체가 주고 받는 메시지를 표현했다고 했는데 어떤 행위를 하도록 지시하는 명령이 메시지
즉 결정하게 하다라는 뜻으로 해석하면 시퀀스 다이어그램을 외우기 쉽다
커뮤니케이션 다이어그램 : 의사소통에 대한 다이어그램이라고 생각
상태 다이어그램: 상태의 변화를 표현
활동 다이어그램: 처리의 흐름을 순서대로 표현
상호작용 개요 다이어그램, 타이밍 다이어그램등이 있다
즉 UML 구성요소에는 사물 / 관계 / 다이어그램이 있는데
다이어그램에는 구조적 / 행위적 다이어그램이 있다
구조적에는
클래스 /객체/ 컴포넌트/ 배치/ 복합체/ 패키지
행위적에는
유스케이스/ 시퀀스/ 커뮤니케이션/ 상태/ 활동 /상호/ 타이밍 이 있다
영어로 나올수도 있다
ex) 활동 다이어그램 => 액티비티 다이어그램 요론 식으로
15.UML 모델에서 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계로 옳은 것은?
Dependency(의존) : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 말합니다 (Cascade 생각하셈)
Realization(실체화) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
Generalization(일반화) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말합니다.('is-a')관계
Association(연관) : 두 사물간의 구조적 관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함 ('has-a')관계라고도 합니다
Dependency(의존) : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 말합니다 (Cascade 생각하셈)
Realization(실체화) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
Generalization(일반화) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말합니다.('is-a')관계
Association(연관) : 두 사물간의 구조적 관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함 ('has-a')관계라고도 합니다
16.다음 중 상위 CASE 도구가 지원하는 주요기능으로 볼 수 없는 것은?
상위 CASE 지원 기능 = Upper CASE
모델들 사이의 모순 검사 , 모델의 오류 검증, 일관성 검증, 자료흐름도 프로토타이핑 작성, UI 설계 지원
하위 CASE 지원 기능 = Lower CASE
구문 중심 편집 및 정적/ 동적 테스트 지원
시스템 명세서 및 생성, 소스코드 생성 지원
CASE의 주요 기능
- 그래픽 지원
- SW 생명주기 전 단계 연결
- 다양한 SW 개발 모형 지원
- 표준화된 개발환경 구축 / 문서 자동화 기능 제공
- 작업과정 / 데이터 공유 -> 작업자간 커뮤니케이션 증대
출처: https://aspring.tistory.com/entry/정보처리기사-필기-개념-분석-자동화-도구CASE-도구 [HelloSpring]
17. 요구사항 관리 도구의 필요성으로 틀린 것은?
18.애자일 개발 방법론이 아닌 것은?
애자일 개발 방법론이란?
소프투웨어 개발 방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법
방법론의 특징
프로젝트 요구사항은 기능 중심으로 정의한다
절차와 도구보다 개인과 소통을 중요하게 생각한다
작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.
소프트웨어가 잘 실행되는 데 가치를 둔다
고객과 피드백을 중요하게 생각한다
에자일 방법론을 실천하기 위한 주요 원칙
공정과 도구보다 개인과 상호작용
계획을 따르기보다 변화에 대응하기
포괄적인 문서보다 동작하는 소프트웨어
계약협상보다 고객과의 협력
에자일 방법론 유형
XP/ 린(Lean) / 스크럼 / 기능 주도개발 (FDD)
모델링(Modeling) 기법
모델링의 개념
실세계의 물리현상을 특정한 목적에 대응하여 이용하기 쉬운 형식으로 표현하는 기법
모델링 절차(요개논물)
1.요구사항 분석 -> 개념 모델링 - > 논리 모델링 -> 물리 모델링
'Certificate' 카테고리의 다른 글
| 정보처리기사: 2021년 05월 15일 기출 문제 풀이 4과목 (0) | 2021.08.10 |
|---|---|
| 정보처리기사: 2021년 05월 15일 기출 문제 풀이 3과목 (0) | 2021.08.10 |
| 정보처리기사: 2021년 05월 15일 기출 문제 풀이 2과목 (0) | 2021.08.09 |
| 제 1과목 소프트웨어 설계(요구사항 확인) (0) | 2021.07.10 |
