1과목 소프트웨어 구축

Chapter 01 소프트웨어 공학 개념

 

Section 1. 소프트웨어 공학 

 

소프트웨어 공학 정의

효율적으로 품질 높은 소프트웨어를 개발하기 위한 학문

 

소프트웨어 공학의 3R의 정의

역공학(Reverse Engineering) 문서만드는 과정

기존 개발된 시스템을 CASE 도구를 이용하여 요구분석서, 설계서 등의 문서로 추출하는 작업

CASE 도구 : 소프트웨어 만드는 과정을 컴퓨터가 도와준다. (SW) 

개발 단계를 역으로 올라감

 

재공학

(기존에 있던 코드를 두고 업그레이드)/ 유지보수의 생산성으로 해결하려는 방법 / 예방 유지보수 

과정 : 분석 => 재구성 => 역공학 => 이관

 

재사용(Reuse) (기존에 있던 코드에 모듈을 가져와서 쓰는 것)

함수와 객체 재사용, 컴포넌트(함수보다 큰 단위) 재사용, 애플리케이션 재사용

합성 중심 ( 조립 ) 블록 구성 / 생성 중심 ( 추상화 형태 ) 패턴 구성 

 

소프트웨어 개발 단계

계획(비용, 일정) => 요구사항 분석 => 설계 => 구현 => 테스트 => 유지보수

계획 : 비용과 기간을 예측 ( RFP )

분석 : 기능 제약조건, 목표 등을 고객과 함께 정의 / 요구사항의 정확한 이해 및 요구사항 유도

설계 : 모델링 = 그림 그리는 것 / 설계 구분 : 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

구현 : 코딩과 디버깅이 이루어짐

테스트

유지보수 : 소프트웨어를 좀 더 발전시키는 단계 , 가장 많은 비용이 들음

 

 

---

 

Section 2. 소프트웨어 개발 방법론

개념 : 절차, 방법, 산출물, 기법, 도구 체계적으로 정리한 것

 

구조적 방법론

절차지향 소프트웨어 제한된 구조, 순차적 실행

구성 요소 : 데이터 흐름도(DFD), 자료사전(DD), 상태전이도(STD), 소단위명세서(Minispec)

 

정보공학 방법론

구조적 방법론과 비슷하나 기업에서 사용하는 데이터 중심 방법론 

 

객체지향 개발 방법론

현실세계의 개체(Entity)를 속성(Attribute)과 메서드(Method)형태로 표현

캡슐화, 정보은닉, 상속, 다형성, 추상화

 

CBD 분석 방법론

재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트를 조합해 애플리케이션 개발

 

애자일 방법론

고객의 리즈의 맞게 빠르게 빠르게 개발

종류 : ( XP, SCRUM, FDD, Crystal 방법론)

 

3. 소프트웨어 개발 모델

폭포수 모델 

 

프로토타이핑 모델 : 시제품

 

나선형 모델( 중요 )

계획하고 위험분석하고 개발하고 평가하고 반복하면서 소용돌이 처럼 점점 발전 하는 것

위험 분석을 추가한 점증적(소용돌이) 개발 모델 / 폭포수 모델 + 프로토타이핑 / 위험들어가면 나선형

순서 : 계획 및 요구분석 => 위험분석 => 프로토타입 개발 => 사용자 평가 ( 계속 점증적으로 개발 ) 

 

RAD(Rapid) 모델 

매우 짧은 개발 주기를 강조하는 점진적 소프트웨어, CASE 도구 이용, 개발 기간 60~90일

 

 

V모형 (중요)

폭포수 모델에 테스트 작업을 강조 

순서 : 단위 테스트(개발자가 진행, 정적, 동적) => 통합 테스트(상향식, 하향식, 빅뱅) => 시스템 테스트(기능, 비기능) =>

인수 테스트(알파테스트, 베타 테스트)

( 단위로 만들어서 그것을 통합을 하고 시스템에 올려서 돈을 받기 위해 인수 ) 

정적테스트 : 안에 있는 소스코드를 보면서 하는 것 

동적테스트 : 기능을 돌리면서 하는 것 

기능 : 사용자 요구사항에 맞게 잘 만들어 졌는데 확인

비기능 : 요구사항에 맞는 기능들이 동작을 할 때 효율성, 보안 등을 확인

 

4세대 기법

요구사항 명세서로부터 원시코드를 자동으로 생성할 수 있게 해주는 모델 

 

4. 애자일 방법론 ( 작은 단위 빨리 빨리 ) 

신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소트프웨어 개발 방식

 

애자일 선언문

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

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

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

계획보다 변화에 대응하기 

 

애자일 방법론 종류(중요)

XP

문서보다 코드를 중시, 5가지 핵심가치와 12개 실천항목이 존재 

(중요)5가지 핵심가치 : 용기, 존중, 의사소통, 피드백, 단순성 ( 용단의 피존 )

12개 실천 항목 : 짝 프로그래밍, 계획세우기(Plannig Game), 테스트 기반 개발 (TDD), 고객상주, 지속적인 통합

작은 릴리즈(배포), 코딩 표준, 공동 코드 소유(주인 의식), 간단한 디자인, 시스템 메타포어, 작업시간 준수

 

스크럼

개발 주기는 30일 정도로 조절 개발 주기마다 동작할 수 있는 결과를 제공 , 항상 팀단위로 생각, 15분 정도의 회의

주요개념 : 제품 백로그(요구사항 목록), 스프린트(단위), 스프린트 계획 회의, 스프린트 백로그, 일일 스크럼 회의, 

                 실행 가능한 제품, 제품 책임자(PL), 스크럼 마스터(PM)

 

그 외 애자일 방법론

크리스털, FDD(기능 주도 개발), ASD(합동 애플리케이션), 린(Lean)도요타

 

5. IT 서비스 관리 

SLM( Service Level Management)

IT 서비스의 품질을 높이는 일련의 관리 및 활동

 

SLA(Service Level Agreement )서비스 수준을 명시적으로 정의한 문서

 

ITSM
서비스 수준(SLA)에 맞는 IT 서비스를 제공하는 것

ITIL 

ITSM을 실형하는 도구 또는 방법

 

 

---

 

Chapter 02 프로젝트 계획 및 분석

 

Section 1 프로젝트 계획

프로젝트 핵심 관리 대상 ( 3p )

사람(People), 문제(Problem), 프로세스(Process)

 

1. 프로젝트 관리

PMBOK

PMI에서 제작한 프로젝트 관리 프로세스 및 지식 체계

PMBOK 5단계 프로세스 그룹 1단계 : 프로젝트 착수 ( 광 범위 )2단계: ..계획 (세부 범위)3단계 : ..실행(계발)4단계 : ..통제(비용 인력 )5단계 : ...종료 ( 고객으로 부터 확인 ) 

 

2. 개발 비용 산정

비용 산정 기법

 

하향식 산정

사람이 진행( 경험있는 전문가 판단 )

델파이 ( 여러 전문가 의견)

 

상향식  산정

LOC(원시코드라인 수) : 비관치( 가장 많은 라인 수 ), 낙관치 ( 가장 적은 라인 수 ), 중간치( 평균 라인 수 ) 

단계별 인원수(M/M)기법 

 

수학적 산정( 중요)

COCOMO 

조직형 ( Oranic Mode ) : 5만 라인 이하  (일반 업무용)

반분리형 ( Semidentached Mode  ): 30만 라인 이하 ( 운영체제, DBMS )

내장형 ( Embedded Mode ) : 30만 라인 이상 ( 미사일 유도 시스템, 신호기 제어 )

 

PUTNAM

시간에 따른 함수로 표현된는 Rayleigh-Norden곡선의 노력 분포도를 기초로 한다.

SLIM : 예측 모형을 기초로 개발한 자동화  추정 도구

 

FP(Function Point )기능 점수 기법 

ESTIMACS : FP모형을 기초로 개발된 자동화 추정 도구

데이터 기능 ( 내부 논리 파일, 외부연계파일 ) 내부있음

트랜잭션 기능 ( 외부입력, 외부출력, 외부조회 ) 내부 없음

 

 

 

3. 개발 일정 산정

작업 순서

WBS => P.C ( 임계 경로 ) => 간트차트

 

1. 작업 분해 WBS( Work Breakdown Structure ) 

회원 관련 ( 로그인, 회원수정, 등등 ) 세분화 하는 작업 

 

2. CPM 네트워크 작성 ( PERT, CPM )

PERT : 일정이 명확하지 않을 때 ( 미 해군의 Polaris 미사일 개발 프로젝트 )

개발기간을 낙관치, 기대치, 비관치로 나누어 예측치를 구한다. 

CPM : 이미 경험을 해봤음 일정을 명확히 알 때 

작업 선/ 후행 관계를 고려 전체작업의 완료시간을 결정(PERT)

추가비용 투입을 고려하여 전체작업 완료시간을 단축하는(CPM)

3. 최소 소요 기간을 구함 ( 임계 경로 ) 개발 경로 중 가장 오래 걸리는 것을 고름

4. 소요 M/M(인원), 기간 산정하여 CPM 수정 

 

5. 간트 차트로 표현 ( 엑셀같은 개념 ) 

일정 계획의 최종 산출물

프로젝트 일정관리를 위한 바(bar) 형태의 도구

 

 

---

 

 

 

Section 2 요구사항 분석 

차세대 : 기존에 있던 걸  새롭게 바꾸는 것

고도화 : 기존에 있던 걸 기능 업그레이드

 

1. 현행 시스템 분석 : 현재 어떤 것들을 사용하고 있는지 분석 

(1). 현행 시스템 파악

1단계 : 현행 시스템의 구성, 기능, 인터페이스 (외부 시스템 연동 ) 현황을 파악

2단계 : 아키텍처( 전체적인 구성도 ) 및 소프트웨어 구성 현황을 파악하는 단계 

3단계 : 하드웨어 및 네트워크 구성 현황을 파악하는 단계

 

(2). 플랫폼 기능 분석 ( 유튜브, g마켓 )

애플리케이션을 구동시키는데 필요한 하드웨어와 소프트웨어의 결합

생산자와 소비자가 서로 원하는 가치를 거래할 수 있는 매개체 역할 수행

연결기능, 비용감소(내가 직접 안만들어도 되니까), 브랜드 신뢰 기능, 커뮤니티 형성

싱글 사이트 플랫폼 ( 소비자 공급자 1:1 ), 투 사이드 플랫폼 ( 두 그룹을 중개하고 모두에게 개방 ),

멀티 사이트 플랫폼 ( 다양한 이해관계 그룹을 연결하여 중개 )G마켓

CPND : 콘텐츠, 플랫폼, 네트워크, 디바이스 / 무선 인터넷 서비스의 가치 사슬

 

(3). 운영체제 분석어떤 운영체제를 쓰는지 확인

 

(4). 네트워크 분석프로토콜의 3요소구문(Syntax), 의미(Semantic), 타이밍

 

(5). DBMS 분석

 

(6). 미들웨어 분석

중간에서 매개 역할을 하는 소프트웨어

종류

1. 원격 프로시저 호출 ( RPC )

2. 메시지 지향 미들웨어 ( MOM ) : 비동기형 ( 쌓아서 한번에 처리 )

3. ORB : 객체지향 시스템

4. DB 접속 미들웨어 ( ODBC, JDBC )

5. TP 모니터 : 트랜잭션( 일처리 단위 )이 올바르게 처리되고 있는지 

6. 웹 애플리케이션 서버 ( WAS ) 

7. 엔터프라이즈 서비스 버스 ( ESB ) : 메시지 기반으로 느슨한 결합형태의 표준

 

 

 

 

2. 요구 공학

(1). 요구공학 개념 : 고객 요구를 체계적으로 수집, 분석, 명세화, 검증하고 추적, 변경되는 요구사항을 도출하고 관리

고객에 머리속에 있는 걸 끄집어 내는 것

 

(2). 필요성 : 분석의 어려움, 요구사항 변화, 관점별 차이 발생

 

(3). 요구사항의 분류

1). 참여자 관점 : 사용자 요구사항(사용자관점), 시스템 요구사항(설계자의 관점), 소프트웨어 요구사항 ( 개발자 관점 )

 

2). 요구사항 내용의 종류 

  기능적 요구사항 : 소프트웨어를 구성하는 기능들이 무엇인지를 정의

  비기능적 요구사항 : 기능들에서 발생 할 수 있는 보안, 성능, 품질, 안정성 등

 

(4). 요구사항 개발 프로세스 ( 중요 )

도출 => 분석 => 명세 => 확인 

도출 : 인터뷰, 관찰, 사용자 스토리( 서로 요구사항을 계속 말하는 것, 애자일 ), 설문조사, 브레인 스토밍, 포커스 그룹

 

분석 : 도메인 분석, DFD(자료흐름도), DD(자료 사전), Mini-Spec(소단위 명세서), ERD(개체 관계도), STD(상태 전이도)

객체지향 분석 도구 : UML, 모델링

 

명세 : 문서를 작성, 정형 명세 기법( 수학적 기호, Z ), 비정형 명세 기법(자연어, 그림)

 

확인 : 확인, 검증, 형상관리를 수행, 이해관계자들이 문서를 검토

 

(5). 요구사항 분석 기법 

1). 기능/ 비기능 분류 / 2). 개념 모델링 UML : 현실 세계상황을 단순화 / 3). 요구사항 할당 / 4). 요구사항 협상 

5).정형 분석( 구문과 의미를 갖는 정형화된 언어 )

 

(6). 요구사항 분석 도구

1) 요구사항 분석 CASE : 반복적인 걸 자동으로 해줌  ( 생명주기 : SDLC )

상위 CASE : 분석, 설계에서 사용(생명주기 전반부)

하위 CASE : 구현, 테스트에서 사용, 코드의 작성과 테스트, 문서화하는 과정 ( 생명주기 후반부 )

통합 CASE : 두개를 합친거 ( 전체과정 지원 )

PSL/PSA : 미시간 대학에서 개발한 것

 

2) HIPO ( 중요 ) 

하향식 소프트웨어 개발을 위한 문서화 도구 

가시적도표 : 전체적인 구조 Tree(계층) / 입력, 처리, 출력 없음

총체적도표 : 프로그램을 구성하는 기능 / 입력, 처리, 출력에 대한 전반적인 정보 제공

세부적도표 : 총체적 도표 상세히 기술하는 도표

 

 

 

 

요구사항 분석 모델링

(1). 모델링의 개념 : 복잡한 시스템을 쉽게 이해하기 위해 간단한 모델로 표현하는 것을 의미 / 그림으로 표현 

 

(2). 모델링 구분

기능적 모델링 : 시스템의 기능을 사용자 관점으로 ( 사용 사례 다이어그램, 액티비티 다이어그램 )

정적 모델링 : 시스템을 구조화하여 클래스 단위로 표현 ( 클래스 다이어그램 ) 구조

동적 모델링 : 시스템이 어떤 기능을 수행하는지 상호작용을 표현 ( 순서, 상태, 커뮤니케이션 다이어그램 ) 구조 변화

 

(3). 분석 모델의 종류 ( 중요 ) 

1). 구조적 분석 모델 ( 하향식 모델), 하향식 기능 분해 기법

자료 흐름도(DFD)도형 중심으로 기술,  버블차트라고도 한다, 가장 보편적

자료 사전 (DD), 자료흐름도에 기술된 모든 자료들에 대한 사항을 자세히 정의, 기호 사용 

소단위 명세서 ( Mini-Specifcation ) : 자료흐름도에서 어떤 일이 수행되는지를 정의하기 위해 각 처리들이 수행하는 업무 상세하게 작성

개체 관계도(ERD) : ER다이어그램, 개체, 속성, 관계 ERD기호(도형)

상태 전의도(STD)  

 

 

2). 객체 지향 분석 모델 ( 상향식 모델 )

(중요)

1. 럼바우(Rumbaugh) 방법 : 객체 모델, 동적 모델, 기능 모델 => 객동기 순서 중요

객체 모델링 : 객체 다이어그램으로 표현, 3가지 중 가장 선행

동적 모델링 : 상태 다이어그램 

기능 모델링 : 자료흐름도(DFD)를 이용해  다수의 프로세들 간의 자료 흐름을 중심으로 처리

2. Booch(부치) 방법 : 미시적 개발 프로세스와 거시적 개발 프로세스

3. Jacobson 방법 : Use case를 강조

4. Coad와 Yourdon 방법 : E-R 다이어 그램 사용

5. Wirfs-Brock 방법 : 분석과 설계간 구분 없음

 

 

---

 

Chapter 03. 소프트웨어 설계

 

Section 1 소프트웨어 설계의 기본 원칙

 

1. 소프트웨어 설계

(1). 소프트웨어 설계의 개념

요구사항 명세서를 참조하여 소프트웨어의 구체적인 설계서를 작성하는 단계 

 

(2). 소프트웨어 설계의 종류 

상위 설계 : 아키텍쳐 설계(시스템 전체적인 구조 설계), 데이터 설계, 인터페이스 정의, 사용자 인터페이스 설계

하위 단계(실제로 구현) : 모듈 설계, 자료구조, 알고리즘 설계

 

(3). 소프트웨어 설계의 원리

1). 분할과 정복(Divide & Conquer)

 

2). 추상화(Abstraction)

과정 추상화, 데이터 추상화, 제어 추상화

 

3). 단계적 분해 

 

4). 모듈화

 

5). 정보은닉(Information Hiding)

다른 객체에게 자신의 정보를 숨기고, 자신의 연산만을 통해 접근이 가능하도록 한다. 캡슐화와 밀접한 관계가 있다.

 

 

 

2. 설계 모델링

(1).설계 모델링 유형

 

1). 구조 모델링 (정적) : user( id, pw, name ) 구조 만드는 것, UML 정적 다이어그램

 

2). 행위 모델링 (동적): 구조 값 기능 , UML 동적 다이어그램

 

(2). 소프트웨어 설계 절차 및 유형

아키텍처 설계, 데이터베이스 설계, 서브시스템 설계, 컴포넌트 설계, 자료구조와 알고리즘 설계

협약에 의한 설계 : 클래스에 대한 여러 가정을 공유하도록 명세 ( 선행조건, 결과조건, 불변조건 ) 중요

 

 

 

 

Section 2 소프트웨어 아키텍처

1. 소프트웨어 아키텍처

(1) 개념 : 소프트웨어의 골격이 되는 기본 구조 

 

(2) 특징 : 간략성, 추상화, 가시성( 눈으로 확인 ), 관점 모형, 의사소통수단

 

(3) 소프트웨어 아키텍처 프레임워크 구성요소 

1) 아키텍처 명세서

2) 이해관계자

3) 관심사

4) 관점

5) 뷰(View)

 

(4) 소프트웨어 아키텍처 4+1 뷰(View)

     고객의 요구사항을 정리해 놓은 시나리오를 4개는 만드는 사람들 관점 1개는 사용자 관점

      4View : 논리적 관점, 구현 관점, 프로세스 관점, 배치 관점

      +1View : 유스케이스 관점 ( 사용자 기능 ) 

 

(5) 소프트웨어 아키텍처 품질 속성

정확성, 신뢰성, 효율성, 무결성, 사용 용이성, 유지보수성, 시험 용이성, 유연성, 이식성, 재사용성, 상호 운용성

 

 

 

2. 소프트웨어 아키텍처 패턴 ( 중요 )

(1) 소프트웨어 아키텍처 패턴 종류

 

1) 계층화 패턴 : N-티어 아키텍처 패턴

 

2) 클라이언트 - 서버 패턴 : 다수의 클라이언트와 하나의 서버로 구성, 일반적인 웹 프로그램

 

3) 마스터 - 슬레이브 패턴 : 슬레이브는 생각안하고 마스터가 처리해서 결과값을 슬레이브한태 줌 

    최종 결과값을 계산하는 구조, 컴퓨터와 주변장치 

 

4) 파이프-필터 패턴 : 서브시스템이 입력데이터를 받아 처리하고 결과를 다음 서브시스템으로 넘겨주는 과정

     컨베이어 벨트 시스템과 비슷 ( 자동차 공장 ), Unix 쉘 처리

 

5) 브로커 패턴 : 분산 시스템에서 사용되는 패턴 ( 직접 연결 x ) 중간에 브로커가 있다. 

 

6) 피어 투 피어 패턴 : 피어(컴퓨터), 파일공유(P2P)

 

7) 이벤트-버스 패턴 : 특정 채널로 메시지를 발행 / 알림 서비스

 

8) 모델-뷰-컨트롤러 패턴(MVC) ( 매우 중요 )

모델(DB) <= 컨트롤러(DB에 있는 값들을 읽고 쓰고) <= 뷰(사용자에게 결과표시)

모델 : 도메인의 기능과 자료를 저장하고 보관

컨트롤러 : 사용자로부터 입력을 받아 연산을 처리

뷰 : 사용자에게 결과를 표시 

자료 저장, 제어,표현 기능을 분리하여 재사용을 증진

 

9) 블랙보드 패턴 : 명확히 정의가 되지 않은 것

 

10) 인터프리터 패턴 : 특정 언어로 작성된 프로그램을 해석

 

 

---

 

Section 3 UML ( 객체지향에서 많이 사용 ) 

(1) UMl 개념

통일된 기호 사용해서 그림을 그리는 언어

기호와 도식을 이용하여 표현하는 방법 / 시각화, 문서화

 

(2) UML 특징 

1). 가시화 언어 : 시각적인 그래픽으로 작성

2). 명세화 언어 : 문서화 모델을 명세화 

3). 구축 언어 : 소스코드로 변환하여 구축

4). 문서화 언어 : 과정을 문서로 남겨 계속 유지보수

 

( 사물 : 회원 => 상품 => 주문 ) 해당 관계를 다이어그램으로 표시

(3) 구성요소  

1). 사물(Things) : 구조사물, 행동사물, 그룹사물, 주해사물(주석)

 

(3). 관계(Relationship)

1).일반화 관계 ( 상속 관계 ) 

2).연관 관계( 오랜시간 유지 ), 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 표시

3).의존 관계 ( 짧게 유지 ), 한 클래스가 다른 클래스를 오퍼레이션(기능)의 매개변수로 사용하는 경우

4).실체화 관계 (다형성, 리모콘 추상화) : 한 객체가 다른 객체에게 오퍼레이션(기능)을 수행하도록 지정 

5). 집합 관계 - 집약관계 : 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적

      ( 불고기 다먹었다고 간장 안사라짐) 전체 객체가 사라진다 해도 부분 객체는 남아 있음

6). 집합 관계 - 합성관계 : 긴밀한 필수적 관계 라이프타임은 의존적

      ( 책상은 상판은 책상다리가 없어지면 안됨 ) 전체 객체가 사라지면 부분 객체도 없어짐

 

(4).다이어그램

1) 구조(정적) 다이어그램

클래스 다이어그램 

객체 다이어그램

컴포넌트 다이어그램

배치 다이어그램 

복합체 다이어그램

패키지 다이어그램 

 

2)행위(동적)다이어그램

유스케이스 다이어그램

시퀀스 다이어그램 : 활성객체, 메시지, 생명선, 제어, 사각형

커뮤니케이션 다이어그램 

상태 다이어그램 : 상태 변환

활동 다이어그램  : 순선에 따라 표현

상호작용 다이어그램

타이밍 다이어그램

 

주요 다이어그램

(1). 클래스 다이어그램

1). 개념 : 자기만의 속성과 일정한 행동으로 구성

 

2). 접근 제한자 표기법 = ( - )private, ( # )protected, ( + )public

 

(2). 유스케이스 다이어그램

1). 개념 : 시스템과 사용자의 상호작용을 다이어그램으로 표현

 

2). 유스케이스 다이어그램 구성요소

시스템

액터

유스케이스(사용자 입장에서 바라본 시스템의 기능 )

관계( 액터와 유스케이스 사이의 의미있는 관계 )

 

3). 유스케이스 다이어그램 관계

1. 연관관계 

2. 포함관계 : 유스케이스를 수행할 때 반드시 실행되어야 하는 경우, login->ID //// <<include>>

3. 확장관계 : 포함 관계 반대, 글등록->파일첨부 <<extend>>

4. 일반화 관계 : 유사한 유스케이스 또는 액터를 모아 추상화 

 

 

(3) 시퀀스 다이어그램

1). 개념 : 객체 간의 상호작용 메시지 시퀀스를 시간의 흐름에 따라 나타내는 다이어그램

2). 구성요소

객체 : 직사각형으로 표현

라이프라인 : 객체에서 이어지는 점선으로 표현

활성 박스 : 라이프라인에서 기다란 직사각형으로 표현 ( 현재 객체가 어떤 활동을 하고 있음을 의미 )

메시지 : 인스턴스 간 주고 받은 데이터

   ( 동기메시지 : 반환이 올 때까지 기다림 )

   ( 비동기메시지 : 반환을 기다리지 않고 다른 작업을 수행 ) 

   ( 자체 메시지 : 자기 자신에게 요청 ) 

   ( 반환 메시지 : 메시지 반환 ) 

 

(4) 상태 다이어그램

1) 개념 : 한 객체의 상태 변화를 나타냄

시작 : 꽉 찬 동그라미, 종료 : 꽉 찬 동그라미에 그밖에 동그라미 하나 감싸져 있음

 

 

---

 

 

Chapter 04. 화면 설계

 

Section 1 UI 설계 

1. UI( User Interface ) 

(1). UI 개념

정보기기와 사용자가 서로 상호작용을 할 수 있도록 연결해주는 매개체

 

(2).UX( 사용자 경험) 개념 

사용자의 경험을 통해서 UI를 만드는것 

UI를 기반으로 사용자들의 공감과 만족을 이끌어내는 역할

 

(3). UI 유형

CLI, GUI, NUI( 인간의 자연스러운 움직임을 인식 ), OUI ( 현실의 모든 것이 입출력 장치가 됨 )

 

 

2. UI 설계

(1) UI 요구사항 구분

 1). 기능적 요구사항 : 눈에 보이는 기능 / 시스템이 제공해야 하는 ( 입력, 출력, 데이터, 연산 ) 

 2). 비기능적 요구사항 : 눈에 보이지 않는 기능 품질 ( 사용성, 효율성, 신뢰성, 유지 보수성, 재사용성, 비용, 일정, 플랫폼 )

 

(2) UI 설계 절차

개발 목표 및 범위 수립 => UI 전략 수립 => 사용자 요구사항 분석 => UI 상세 설계 => 구현, => 테스트 

 

(3) UI 설계 원칙 ( 중요 ) 

 1) 직관성 : 누구나 쉽게 이해하고 사용 

 2) 유효성 : 사용자의 목적을 정확하게 달성해야 한다.

 3) 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다. 

 4) 유연성 : 사용자의 요구사항을 최대한 수용 오류를 최소화

 

(4) UI 설계 도구 

 1) 와이어 프레임 : 선으로 간단하게 틀을 잡는다. 손그림이나 파워 포인트로

 2) 스토리 보드(SB) : 개발 후 완성된 콘테츠의 최종 결과를 예상할 수 있는 기초 문서 / 디, 개 최종적으로 참고

    ( 작성 절차 : 표지, 문서의 버전, Index 작성 ( 목차 ), IA(사이트 맵), 공통모듈( Header, Footer ), 화면설계와 설명서 )  

 3) 프로토타입 : 시제품

 4) 목업 : 와이어프레임보다 좀 더 실제화면과 유사하게 만든 정적인 형태의 모형 

 5) 유스케이스 : 사용자 측명의 요구사항

 

 

3. 감성공학

(1)개념

인간의 심상을 구체적인 물리적 설계 요소로 번역하여 이를 실현하는 기술 

 

(2) 제품과 관련된 인간의 감성

 1) 감각적 감성 : 사용자가 느끼는 감정 ( 외관, 색상, 디자인 ) 

 2) 기능적 감성 : 성능과 편리함

 3) 문화적 감성 : madein ... 개인이 속한 사회나 문화

 

(3) 감성공학의 접근 방법

 1) 1류 접근 방법 : 인간의 어휘 ( 잘 만들었네 )

 2) 2류 접근 방법 : 문화적감성의 일부를 반영  ( 잘 만들었는데 madein.. )

 3) 3류 접근 방법 : 정량화된 값을 환산

 

 

 

 

Section 2 UI 구현

1. 화면 레이아웃( 틀 ) 구성  

(1). 개념

특정 공간에 여러 구성 요소를 보기 좋게 효과적으로 배치하는 작업

 

(2). HTML5월드와이드웹(WWW)을 통해 제공되는 정보를 나타낼 목적으로 사용되는 마크업 언어

 1) 특징 : 플러그인의 설치 없이 동영상이나 음악을 웹브라우저상에서 재생 / 실시간으로 서버와 양방향 통신 가능

 2) 시맨틱 요소 : 의미를 부여한 태그, 크롤링 /  header, nav, aside, section(article), footer / 

 

(3). CSS

 1) 개념 : HTML과 함께 웹을 구성하는 기본 프로그래밍 요소 / 색상이나 크기, 이미지 크기나 위치, 배치방법 디자인요소

 2) 특징 : 자바스크립트와 연계해 동적인 콘테츠 표현이나 디자인 적용 가능 / 다양한 기기에 맞는 반응형 웹 적용 가능

 

(4). JavaScript 

 1) 개념 : 모질라 재단의 프로토타입 기반의 프로그래밍언어로, 스크립트 언어에 해당 / 웹페이지가 동작하는 것을 담당

 2) 특징 : 값에 따라 변수의 형변환이 자동으로 이루어지는 동적 형변환 ( var ) 

 3) 프레임워크

  React : 싱글 페이지 애플리케이션(SPA)이나 모바일에서 가능 / 페이스북에서 개발

  View.js : Evan You에 의해 개발

  Angular JS : 구글에서 개발

  Ajax : 비동기적인 웹 애플리케이션의 제작을 위한 웹 개발 기법 ( 페이지가 껌뻑 거리는게 아니라 부분만 변경됨 ) 

 

 

2. UI 관련용어

웹 표준 ( 크롬, 엣지 등 ) => 웹 호환성 ( 하드웨어, 소프트웨어 환경이 다른 경우에도 공등한 서비스 ) =>

웹 접근성 (장애인 비장애인 ) => 반응형 웹 ( PC, 모바일 크기에 맞춰서 ) => 인포그래픽 (? 도움말, x닫기 시각화) =>

브랜드 아이덴티티(IBI)브랜드에 특화된 이미지 =>   내비게이션( 웹 사이트 탐색 ) => 아코디언 ( 사용자가 원하는 정보만 선택적으로 볼 수 있게 접을 수있는 ) => 플레이스 홀더 ( 입력필드에 제공되는 간략한 텍스트 도움말 ) => 필터링 (원하는 데이터) => 입력 폼( 웹서버로 전송 ) => 입력 필드 ( 사용자 입력칸 ) => 썸네일 ( 커다란 이미지 축소 ) => 레이블 ( 이름표 )

대체 텍스트 ( 콘텐츠를 대신하기 위해 제공되는 텍스트 ) => 초점(Focus) 커서 껌뻑껌뻑