[정보처리기사] 소프트웨어 설계 정리

 

 

UI 설계 시 오류 메시지나 경고에 관한 3가지 지침

1. 메시지는 이해하기 쉬워야 한다.

2. 오류로부터 회복을 위한 구체적인 설명이 제공되어야 한다.

3. 오류로 인해 발생될 수 있는 부정적인 내용을 적극적으로 사용자들에게 알려야 한다.

 

Entity-Relationship Diagram : 정보공학방법론

 

<Coad-Yourdon>

- E-R 다이어그램을 사용하여 객체의 행위를 모델링

- 객체 식별, 구조 식별

 

<아키텍처 설계 품질 시스템 측면> (가용)이가 (변)의 (성능)(보안)위해 약 (사용)해서 (시험)해봄
가용성 availability
변경용의성 modifiability
성능 performance
보안성 security
사용편의성 usability
시험 용의성 testability

 

<자료사전(Data Dictionary)>

= : 자료의 정의(~로 구성되어 있다)

+ : 자료의 연결(그리고)

() : 자료의 생략(생략 가능한 자료)

[] : 자료의 선택(또는) ex) [ A | B | C ]

{} : 자료의 반복

* * : 자료의 설명(주석)

 

<CASE: 시스템 개발과정의 일부 또는 전체를 자동화시킨 것>

<CASE의 원천 기술> (자구) (프로)듀스 (정보) (분산)됨.

1. 구조적 기법(Structured Technique): 복잡한 시스템을 여러 개의 작은 부분으로 분할하여 문제를 해결하는 방법으로, 설계 및 개발 과정을 구조화합니다.

2. 프로토타이핑 기술(Prototyping Technique): 사용자와 시스템 간의 상호 작용을 모방한 모형을 생성하여 시스템 요구사항을 더 잘 이해하는 데 도움이 됩니다.

3. 자동프로그래밍 기술

4. 정보 저장소 기술(Information Repository Technique): 모든 정보를 중앙에 모아 정보를 쉽게 액세스하고 업데이트할 수 있도록 하는 방법.

5. 분산 처리 기술

 

상위 CASE: 요구 분석과 설계 단계를 지원

- 모델들 사이의 모순검사 기능

- 모델의 오류 검증 기능

- 자료흐름도 작성 기능

 

하위 CASE: 코드를 작성하고 테스트하며 문서화하는 과정 지원

- 원시코드 생성 기능

 

통합 CASE: 소프트웨어 개발 주기 전체과정을 지원

 

시스템 구성요소 : Process, Feedback, Control

 

1. 클래스(Class): 객체를 정의해놓은 것. 객체지향 프로그램에서 데이터를 추상화하는 단위

2. 패키지(Package): 클래스를 묶어두는 물리적인 단위. 클래스들의 집합

3. 객체(Object): 실존하는 것. 클래스에 정의된 내용대로 메모리에 생성된 것

4. instance : 객체지향 기법에서 같은 클래스에 속한 각각의 객체

5. Message : 객체에 어딴 행위를 하도록 지시함.

6. 파이프 필터 : 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송, 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복되는 아키텍처 스타일

7. 메소드 : 객체의 행위. 메시지를 받았을 때 정해진 기능을 수행한다.

1. 연상 코드: 항목의 명칭이나 약호와 관계 있는 숫자, 문자, 기호를 이용하여 코드를 부여하는 방법

2. 블록 코드: 대상 항목에서 공통적인 것을 블록으로 구분하고 블록 내에 일련 번호를 부여하는 방법

3. 순차 코드: 일정 기준에 따라 최초의 자료부터 순차적으로 일련번호를 부여하는 방법

4. 표의 숫자 코드: 길이 넓이 부피 등 항목의 성질의 물리적인 수치를 그대로 코드에 적용시키는 방법

 

FEP(Front End Processor, 전치프로세서)

: 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어

 

EAI(Enterprise Application Integration, 기업 애플리케이션 통합 솔루션)

: 기업에서 운영하는 서로 다른 애플리케이션을 통합

(Point-to-Point, Hub&Spoke, Message Bus, Hybrid)

 

<럼바우(Rumbaugh)>

- 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 객체지향 분석(Object-oriented Analysis) 기법

 

객체 모델링(Object Modeling): 객체 다이어그램, 정보 모델링이라고도 하며 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의, 가장 중요하며 선행되어야 함

동적 모델링(Dynamic Modeling): 상태 다이어그램, 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현

기능 모델링(Functional Modeling): 자료 흐름도(DFD), 프로세스들의 자료 흐름을 중심으로 처리 과정 표현

- 럼바우 객체지향 분석 기법의 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행된다.

 

<아키텍처 설계과정>

설계목표설정 – 시스템타입결정 – 스타일 적용 및 커스터마이즈 – 서브시스템의 기능 - 인터페이스 동작 작성 – 아키텍처 설계 검토

 

<클래스 설계원칙>

용어	개념
단일 책임 원칙 (S RP , Single responsibility principle)	한 클래스 는  하나의 책임 만 가져야 한다.
개방 폐쇄 원칙 (O CP , Open/closed principle)	소프트웨어 요소는  확장에는 열려 있으나  변경에는 닫혀  있어야 한다.
리스코프 치환 원칙 (L SP , Liskov substitution principle)	프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서  서브타입(하위클래스)은 어디서나 자신의  기반타입(상위클래스) 인스턴스로 바꿀 수 있어야 한다.
인터페이스 분리 원칙 (I SP , Interface segregation principle)	특정 클라이언트를 위한 인터페이스  여러 개가 범용 인터페이스 하나보다 낫다.
의존관계 역전 원칙 (D IP , Dependency inversion principle)	추상화에 의존 해야지, 구체화에 의존하면 안된다.

 

<DFD> : 자료 흐름 그래프 또는 버블(bubble) 차트/구조적 분석 기법/시간흐름x

- 프로세스(Process): 원

- 데이터 흐름도(Data Flow): 화살표

- 자료 저장소(Data Store): 직선(단선/이중선)

- 단말(Terminator): 사각형

 

<소프트웨어 설계>

상위설계 : 아키텍처 설계, 데이터 설계, 시스템 분할, 인터페이스 정의, 사용자 인터페이스 설계(UI 설계)

하위 설계 : 모듈 설계, 인터페이스 작성

 

<UML> (Things은 사물, Relationship은 관계, Diagram은 다이어그램) 뒷다리

: UML은 객체지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어이다. UML은 비즈니스 프로세스 개발 분야에 특화되어 사용 · 발전되었다. UML은 방법론을 통합한 것으로, 표준화된 모델링 기법을 제공한다.

 

UML 다이어그램

<정적> 클객패컴배

1. 클래스 다이어그램 : 클래스 속성, 함수, 변수타입들로 구성

2. 객체 다이어그램 (Object ): 클래스의 값이 매겨진 행동을 갖고있는 독립된 객체정보 표시

3. 패키지 다이어그램 : 모델요소를 그룹화한 다이어그램

4. 컴포넌트 다이어그램 : 컴포넌트끼리 구조관계 표현

5. 배치 다이어그램 (Deployment): SW,HW를 포함 시스템의 물리적 구조 나타냄

<동적>아유상순

1. Use Case Diagram : 사용자 관점에서 바라본 시스템 표현

- 액터 : 시스템과 상호작용하는 모든 외부요소

- 구성요소 : 연관, 포함, 확장, 일반화,그룹화 <확연포함 일반그룹>

- 연관 : use case 와 actor의 관계

- 확장 : 기본 use case 수행 시 특별한 조건을 만족할 때 수행할 usecase

- 포함 : 시스템의 기능이 별도의 기능을 포함

- 일반화 : 하위 use case/action이 상위 use case/actor에게 기능/역할을 상속받음

- 그룹화 : 여러개의 usecase를 단순화하는 방법

2. Activity Diagram (활동 다이어그램) : 순차, 병행하게 표현, 분기마다 순차적으로 표시/ 시스템 전체 흐름 표현

3. 상태 다이어그램(State ): 하나의 객체가 다른 객체와 상호작용에 따라 어떻게 변화하는지 표현하는 다이어그램. 하나의 객체의 흐름을 나타냄

4. 순차 다이어그램 (Sequence): 여러 대상간의 상호작용을 (수직)시간순으로 표현

-> 액터(Actor), 객체(object), 생명선(Lifeline), 메시지(Message), 실행 상자(Active Box)

 

커뮤나케이션 다이어그램 : 동적에 참여한 객체들의 메시지, 관계를 표현.

 

◎ 미들웨어의 개념 및 종류 (WAS,RPC,ORB(TP-Monitor),MOM)

 

클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어이다. 표준화된 인터페이스를 통하여 시스템 간의 데이터 교환에 있어 일관성을 제공한다. 운영체제와 애플리케이션 사이에서 중간 매개 역할을 하는 다목적 소프트웨어이다. 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 확인할 필요가 없다.

 

사용자가 미들웨어의 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있다면, 보안의 위협이 될 수 있으므로 확인할 수 없도록 해야함.

 

◎ RPC(Remote Procedure Call)

 

응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식

 

◎ MOM(Messgae Oriented Middleware)

 

메시지 기반의 비동기형 메시지를  전달하는 방식의 미들웨어

 

- 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용

다소 느리고 안정적인 응답을 필요

독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 역할을 한다.

송신측과 수신측의 연결 시 메시지 큐를 활용하는 방법이 있다.

상이한 애플리케이션 간 통신을 비동기 방식으로 지원한다. 

 

ORB(Object Request Broker) : 객체 간 메시지 전달을 지원하는 미들웨어

◎ TP-Monitor(Transaction Processing Moniter)

 

항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어

 

- 사용자 수가 증가해도 빠른 응답속도를  유지해야 하는 업무에 주로 사용

 

◎ WAS(Web Application Server)

 (Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere)

정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를  처리하기 위해 사용되는 미들웨어 

 

익스트림 프로그래밍 (eXtreme Programming)

: 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복, 개발 생산성을 향상시키는 방법.

 

5가지 핵심가치

의 사소통(Communication)

단 순성(Simplicity)

용 기(Courage)8

 

피 드백(Feedback)

존 중(Respect)

▶ 의용단피존  

 

기능적 요구사항 Vs 비기능적 요구사항

 

- 기능적 요구사항 : 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항

- 비기능적 요구사항 : 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 성능, 보안, 품질, 안정성등으로 실제 수행에 보조적인 요구사항

 

<객체지향 주요 개념>

 

캡슐화(Encapsulation)

: 속성과 관련된 연산을 클래스 안에 묶어서 하나로 취급하는 것을 의미하는 객체지향개념

- 세부내용 은폐 -> 변경사항 발생해도 오류파급 적음

- 재사용 용이

- 인터페이스 단순해짐, 객체간 결합도 낮아짐

 

상속성(Inheritance)

: 정의된 상위 클래스로부터 하위 클래스가 속성, 연산을 물려받는 것

상위클래스에서 받은 속성, 연산 이외에도 새로운 것 첨가 가능

클래스 재사용, 소프트웨어 재사용 높임

 

다형성(Polymorphism)

: 하나의 메시지에 대해 각 객체가 갖고있는 고유한 방법대로 응답

- 코드 변형하지 않고 새로운 클래스 쉽게 추가 가능

집단화 : 클래스들 사이의 ‘부분-전체(part-whole)' 관계 또는 ’부분(is-a-part-of)'의 관계

 

여러 가지 형태를 가지고 있으면서 여러 형태 받아들일 수 있음

오버로딩 :　같은 이름의 메소드 중복 정의(매개변수, 타입)

오버라이딩 : 상속관계에서 발생, 상위 클래스에서 정의한 일반 메소드 구현을 하위 클래스에서 무시하고 재정의 가능

 

애자일(Agile) :　개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.

 

애자일 방법론 특징

 

프로젝트의 요구사항은 기능 중심 으로 정의한다. [2020년 4회]

절차와 도구보다 개인과 소통을 중요하게 생각한다.

작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.

소프트웨어가 잘 실행되는 데 가치를 둔다.

고객과의 피드백을 중요하게 생각한다.

 

애자일 선언문 (개변동고)

공정과 도구보다 개 인과 상호작용

계획을 따르기보다 변 화에 대응하기

포괄적인 문서보다 동 작하는 소프트웨어

계약 협상보다 고 객과의 협력

 

GoF(Gang of Four) : 생성패턴, 구조, 행동패턴

 

추상 팩토리 (Abstract Factory)	상위 클래스의 객체 생성코드를 하위클래스가 상속받는다.
빌더 (Builder)	분리된 인스턴스를 조합하여 객체 생성. 같은 객체를 생성해도 다른 결과를 도출할 수 있음.
팩토리 메소드 (Factory Method)	객체 생성 코드를 하위 클래스에서 구체화, 상위 클래스는 인터페이스만 제공 (각각 다른 작업 수행)
프로토타입 (Prototype)	원본을 복제하는 형태로 객체 생성, 비용 저렴
싱글턴 (Singleton)	클래스 내 생성되는 인스턴스가 하나만 필요할 때 사용 (동시참조X)

1. 생성패턴(Creational Patterns) : 객체 생성에 대한 패턴 / 캡슐화 + 유연성 목표

 

 

2. 구조패턴(Structural Patterns) 7 : 구조가 복잡한 시스템 개발에 도움을 줄 수 있음

어댑터 (Adapter)	일치하지 않는 인터페이스 변환 (전류 어댑터와 같은 역할)
브릿지 (Bridge)	추상층(기능)과 구현층(구체화)을 분리하여 서로 독립적 확장 가능 기존 클래스 사용시 재사용할 수 있게 중간에서 맞춰줌
합성 (Composite)	트리구조로 구성
데토레이터 (Decorator)	클래스에 기능을 추가하기 위해 다른 객체를 덧붙이는 형태
파사드 (Facade)	다수의 서브클래스들의 통합 인터페이스를 제공할 수 있는 Wrapper 객체 구성
플라이웨이트 (Flyweight)	다수의 유사 객체 생성이 필요할 때 메모리 절약을 위해 최대한 공유해서 사용하는 형태
프록시 (Proxy)	접근이 어려운 객체에 접근할 수 있도록 인터페이스 역할 수행

 

4. 행동패턴(Behavioral Patterns) 11 : 상호작용이나 책임 분배에 대한 부분을 정의하고 결합도는 최소화 하는 것이 목표

 

책임연쇄 (Chain of Responsibility)	요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴. 각 객체들이 고리(Chain)으로 묶여있어 요청이 해결될 때까지 고리를 따라 책임이 넘어간다.
커맨드 (Command)	명령어를 캡슐화하여 재사용하거나 취소할 수 있도록 필요한 정보를 로그에 남기는 형태
인터프리터 (Inerpreter)	언어에 문법 표현을 정의하는 패턴
반복자 (Iterator)	접근이 잦은 객체는 동일한 인터페이스를 사용하도록 하는 패턴
중재자 (Mediator)	상호작용을 캡슐화하여 결합도를 낮추기위해 사용
메멘토 (Memento)	특정 시점에서의 객체 내부 상태를 객관화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 들릴 수 있는 기능을 제공하는 패턴이다. Ctrl + Z 기능이 이 패턴의 대표적 기능
옵저버 (참견자) (Observer)	이벤트 발행과 구독, 상태 변화 전달. 한 객체의 상태가 변화하면 객체에 상속되어있는 다른 객체들에게 변화된 상태를 전달하는 패턴. 카톡의 읽음표시 같은 느낌
상태 (State)	이벤트를 객체 상태에 따라 다르게 처리해야 할 때 사용. 카톡 알림설정 같은 느씸
전략 (Strategy)	동일 계열 알고리즘 상호 교환, 독립적 사용
템플릿 메소드 (Template Method)	상위에서 인터페이스를 정의하고 하위에서 구체화 시킴 (유지보수 쉬워짐)
방문자 (Visitor)	처리 기능을 별도의 클래스로 구성. 분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행한다.

Feedback : 시스템의 상태와 사용자의 지시에 대한 효과를 보여줌으로서 사용자가 명령의 진행상황과 표시된 내용을 해석할 수 있도록 도와주는 것

Posture : 사람의 자세 추정

Module : 기능 단위로 묶어 관리하는 독립적인 코드 블록, 유일한 이름을 가짐, 다른 모듈에서의 접근 가능.

Hash : 고정된 길이의 데이터 출력하는 해시 함수 이용해 데이터를 변환시킴

 

＜UI 구분＞

 

- CLI(Command Line Interface) : 텍스트 형태 인터페이스

- GUI(Graphical User Interface) : 마우스로 선택하여 작업하는 그래픽 환경 인터페이스

- NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기 조작하는 인터페이스

- VUI(Voice User Interface) : 사람의 음성으로 기기 조작하는 인터페이스

- OUI(Organic User Interface) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

 

모델링 : 시스템 동작, 상호작용, 구조 등 이해, 서로 다른 모델링 작업에 영향 줄 수 있음

 

<UI 설계도구>

1. 와이어프레임(Wireframe)

기획 단계의 기초에 제작하는 것, 페이지에 대한 개략적인 레이아웃이나 UI요소 등에 대한 뼈대를 설계하는 단계

 

- 와이어프레임을 제작할 때는 각 페이지의 영역 구분 컨텐츠, 텍스트 배치 등을 화면 단위로 설계

 

- 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 와이어프레임 사용

 

- 와이어프레임 툴 : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등

 

2. 목업(Mockup)

목업은 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 설계 화면과 유사하게 만든 정적인 형태의 모형

- 시각적으로만 구성 요소를 배치하는 것으로 실제로 구현되지 않음

 

- 목업 툴 : 파워 목업, 발사믹 목업 등

 

3. 스토리보드(Story Board)

스토리보드는 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서

 

- 디자이너와 개발자가 최종적으로 참고하는 작업 지침서

 

- 스토리보드는 상단이나 우측에는 제복, 작성자 등을 입력하고, 좌측에는 UI 화면, 우측에는 디스크립션을 기입

 

- 디스크립션은 화면에 대한 설명, 전반적인 로직, 분기처리, 예외처리 등을 작성하는 부분으로, 명확하고 세부적으로 작성

 

- 스토리보드 톨 : 파워포인트, 키노트, 스케치, Axure 등

 

 

4. 프로토타입(Prototpye)

 

프로토타입은 와이어프레임이나 스토리보드 등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형

 

- 프로토타입은 사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플

 

- 프로토타입은 작성 방법에 따라 페이지 프로토타입과 디지털 프로토타입으로 나뉨

 

- 프로토타입 툴 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등

 

4. 유스케이스(Use Case)

 

유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술

 

- 사용자의 요구사항을 빠르게 파악함을써 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화

 

- 유스케이스는 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것

 

- 유스케이스 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성

 

<MVC>

MVC는 사용자 담당하는 계층의 응집도를 높일수도 있고, 여러개의 다른 UI를 만들어 그 사이의 결합도를 낮출수도 있음

-Controller는 model과 view사이에서 전달자 역할을 한다.

- 여러개의 뷰를 만들 수 있으므로 한 개의 모델에 여러개의 뷰를 연결 가능