[ 1과목 ] 소프트웨어 설계

< 참고사항 >

※ 정보처리기사 개정된 후,  기출문제들 다 풀고 3회 정도 반복할 것!
※ 이해 안 되는 문제들은 유튜브를 통해서 이해할 것! ( 전문강사들이 문제풀이 영상 많음 )
※ 게시물은 자주 나오는 필기 기출 내용 위주이지만 스스로 다른 개념들도 확인해 볼 것!

 

---

 

소프트웨어 생명주기 ( Software Development Life Cycle )

 

 

 

•   시스템 개발 주기( System Development Life Cycle : SDLC )라 부른다.

•   소프트웨어가 개발되기 위해 정의되고 사용이 완전히 끝나 폐기될 때까지의 전 과정

•   소프트웨어 제작 공정 과정이다.

​

 

1) 폭포수 모형( Waterfall Model )

•  가장 오래되고 가장 폭넓게 사용된 고전적 생명주기 모형

•  선형 순차적 모형

•  단계별 정의 및 산출물이 명확하다.

•  각 단계의 결과가 확인된 후, 다음 단계로 넘어가는 단계적 / 순차적 접근 방식이다.

•  개발 중간에 요구사항의 변경이 용이 X ( 반복을 허용 X )

•  타당성 검토  >  계획  >  요구분석  >  설계  >  구현(코딩)  >  테스트(검사)  >  유지보수

 

 

2) 프로토타입 모형( Prototype Model )

•  견본(시제품)을 만들어 최종 결과물 예측하는 모형

•  시제품은 의뢰자나 개발자 모두에게 공동의 참조모델이 된다.

•  새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어 구현

•  단기간 제작을 목적으로 하니 비효율적인 언어나 알고리즘 사용될 수 있다.

•  인터페이스 중점 개발

•  개발 중간에 요구사항의 변경 용이

 

 

3) 나선형 모형( Spiral Model , 점진적 모형 )

•  폭포수 모형 / 프로토타입 모형 장점 + 위험분석 기능 추가한 모형

•  점진적 개발 과정 반복으로 요구사항 추가 가능

•  누락되거나 추가된 요구사항 첨가 가능

•   정밀하고, 유지보수 과정 필요 X

•   계획 및 정의  >  위험분석  >  공학적 개발  >  고객 평가

 

 

4) 애자일 모형( Agile Model )

•  애자일 : 민첩함 / 기민함 의미

•  변화에 유연하게 대응

•  중소형, 아키텍처 설계, 프로토타이핑에 적합하다.

•  일정한 주기( literation , Sprint ) 반복하며 개발과정 진행

•  절차와 도구보다 고객(개인)과의 소통에 초점

•  방대한 문서보다는 소프트웨어가 잘 실행되는데 더 가치를 둔다.

•  기능 주도 개발( FDD : Feature Driven Development )

​

ex) 

XP( eXtreme Programming ) , 스크럼( Scrum ), 칸반( Kanban ), 크릐스탈( Crystal ), 린( LEAN )

 

---

 

스크럼( Scrum ) 기법

​

 

 

30일마다 동작 가능한 제품을 제공하는 스플린트를 중심

짧은 시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론

​

 

1) 제품 책임자( Product Owner )

•   주로 개발 의뢰자나 사용자가 담당

•   요구사항이 담긴 백로그 작성 및 제품의 백로그에 대한 우선순위를 지정

​

 

2) 스크럼 마스터( Scrum Master )

•  객관적인 시각에서 조언을 해주는 가이드 역할 수행

•   일일 스크럼 회의 주관

•  스크럼 프로세스를 따르고, 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할

​

 

3) 개발팀( Development Team )

PO , SM 제외한 모든 팀원

​

 

4) 스크럼 개발 프로세스

스프린트 계획 회의  >  스프린트  >  일일 스크럼  >  스크럼 검토회의  >  스프린트 회고

 

※  스프린트 계획 회의

•  수행할 작업을 대상으로 단기 일정 수립

 

※  일일 스크럼 회의

•  약 15분 정도의 짧은 시간동안 진행 상황 점검

•  남은 작업시간은 소멸차트에 표시

 

※  스프린트 검토 회의

•  사용자가 포함된 참석자 앞에서 테스팅 수행

•   개선사항에 대한 피드백 정리 후 제품 백로그 업데이트

 

※  스프린트 회고

•  규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인 및 기록

​

 

5) 제품 백로그( Product Backlog )

•  개발할 제품에 대한 요구사항 목록

•  스크럼팀이 해결해야 하는 목록( 소프트웨어 요구사항, 아키텍처 정의 등이 포함 )

​

 

6) 스프린트( Sprint )

•  반복적인 개발 주기( 계획 회의부터 제품 리뷰가 진행되는 날짜 )

•  백로그에 작성된 업무를 대상으로 속도를 추정한 후 개발담당자에게 할당

•  할당된 업무는 보통 할 일( To Do), 진행중( In Progress), 완료( Done ) 상태를 갖는다.

​

 

※  속도( Velocity )

•  한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

 

---

 

XP( eXtreme Programming ) 기법

​

 

 

•  애자일 개발 프로세스의 보급에 큰 역할을 하였다.

•  고객과 함께 2주 정도의 반복 개발, 테스트와 우선 개발을 특징으로 하는 명시적인 기술

•  소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법

•  구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것

•  구체적인 실천 방법을 정의, 개발 문서보다는 소스코드에 중점

​

 

1) XP의 핵심 가치

•  용기( Courage ) : 고객의 요구사항 변화에 능동적인 대처

•  단순성( Simplicity ) : 부가적 기능, 사용되지 않는 구조 / 알고리즘 배제

•  의사소통( Communication ) : 개발자, 관리자, 고객 간의 원활한 의사소통

•  피드백( Feedback ) : 지속적인 테스트와 반복적 결함 수정

•  존중( Respect ) : 프로젝트 관리자는 팀원의 기여를 존중

​

 

2) XP 개발 프로세스

•  사용자 스토리

-  고객의 요구사항을 간단한 시나리오로 표현

-  내용은 기능 단위로 구성, 필요한 경우 테스트사항도 기재

 

•  릴리즈 계획 수립

-  몇개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라 함

-  부분 혹은 전체 개발 완료 시점에 대한 일정 수립

 

•  스파이크

-  기술문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

 

•  이터레이션

-  하나의 릴리즈를 더 세분화 한 단위

-  일반적으로 1 ~ 3주 정도의 기간으로 진행

 

•  승인 검사( = 인수 테스트 )

-  하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트

-  고객이 직접 수행

-  테스트 과정에서 발견된 오류사항은 다음 이터레이션에 포함

 

•  소규모 릴리즈

-  고객의 반응을 기능별로 확인 가능하여 고객의 요구사항에 좀 더 유연하게 대응 가능

 

 

3) XP의 실천 방법

•  Whole Team( 전체 팀 )

-  모든 구성원은 각자의 역할이 있고 책임을 가져야 함

 

•  Small Releases( 소규모 릴리즈 )

-  릴리즈 기간을 짧게 반복하여 고객의 요구변화에 신속히 대응

 

•  Test-Driven Development( 테스트 주도 개발 )

-  실제 코드 작성 전, 테스트 케이스를 먼저 작성하여 무엇을 해야 할지 정확히 파악

-  테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구 사용

 

•  Continuous Intergration( 계속적인 통합 )

-  하나의 작업이 마무리될 때마다 코드들은 지속적으로 통합되어야 한다.

 

•  Collective Ownership( 공동 소유권 )

-  코드에 대한 권한과 책임을 공동으로 소유

 

•  Pair Programming( 짝 프로그래밍 )

-  다른 사람과 함께 프로그래밍을 수행하여 책임을 공동으로 나눠갖는 환경 조성

 

•  Design Improvement( = 디자인 개선, Refactoring 리팩토링  )

-  프로그램 기능 변경없이 단순화, 유연성 강화 등을 통해 시스템 재구성

 

 

---

 

개발 기술 환경

​

 

 

1) 운영체제( OS : Operating System )

•  컴퓨터의 제한된 각종 자원을 효율적으로 관리, 운영함으로써 사용자에게 편리성을 제공하고자 하는

   인간과 컴퓨터 사이의 인터페이스를 위한 시스템 소프트웨어

•  제어 프로그램( Control Program ) + 처리 프로그램( Processing Program )으로 이루어진다.

•  소프트웨어 ex) Windows , UNIX, Linux, Mac OS , Android 등등

•  고려사항 : 가용성 / 성능 / 기술&지원 / 구축비용 / 주변기기

 

 

2) 미들웨어( Middleware )

•  운영체제와 응용프로그램 사이에서 추가적인 서비스 제공하는 소프트웨어

•  클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어

•  소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공

•  여러 컴포넌트를 1대 1 , 1대 다수, 다수대 다수 등 여러 가지 형태로 연결 가능

 

 

•   분류

 

- DB 미들웨어

애플리케이션과 데이터베이스 간에 통신을 원활하게 하는 것을 목적

다양한 형태로 구축된 데이터베이스 간의 통신이 가능하도록 해주는 제품

​

- 원격 프로시저 호출( RPC : Remote Procedure Call )

네트워크 상에서 애플리케이션과 애플리케이션 간의 연동을 하기 위한 미들웨어

​

- 메시지 지향 미들웨어( MOM : Message-Oriented Midleware )

애플리케이션과 미들웨어 간의 상호연동을 위한 미들웨어

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

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

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

​

- 트랜잭션 처리( TP : Transaction Processing ) 모니터

통신량이 많은 클라이언트와 서버 사이에 위치하여 서버 애플리케이션 및 자원을 효율적으로 관리

​

 

3) 데이터베이스 관리 시스템( DBMS : Database Management System )

•  사용자와 데이터베이스 사이에서 정보 생성, DB 관리하는 소프트웨어

•  데이터베이스의 구성, 접근방법, 유지관리에 대한 모든 책임

•  JDBC( Java Database Connectivity ) , ODBC( Open Database Connectivity )

•  Oracle, MySQL , SQLite, MongoDB, Redis 등

•  가용성 / 성능 / 기술&지원 / 구축비용 / 상호 호환성

 

 

4) 웹 애플리케이션 서버( WAS : Web Application Server )

•  정적인 콘텐츠를 처리하는 웹 서버( Web Server)와 반대

•  동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

•  데이터 접근 / 세션 관리 / 트랜잭션 관리 라이브러리 제공

•  Tomcat , JEUS, WebLogic, JBoss, Jetty, Resin 등

•  가용성 / 성능 / 기술&지원 / 기술의 지속 가능성

 

 

5) 오픈소스( Open Source )

•  누구나 제한 없이 사용할 수 있도록 코드를 무료로 사용할 수 있게 공개

•  라이선스의 종류, 사용자의 수, 기술의 지속 가능성

 

---

 

요구사항 정의

​

 

 

1) 기능 요구사항

•   기능 / 입력 / 출력 / 저장 / 수행 등

-  시스템의 입력이나 출력으로 무엇이 포함되어야 하는지

-  시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지

-  시스템이 반드시 수행해야 하는 기능

-  사용자가 시스템을 통해 제공받기를 원하는 기능

 

 

2) 비기능 요구사항

•   성능 / 품질 / 제약사항 / 호환성 / 보안 등

-  시스템 장비 구성 요구사항( 하드웨어, 소프트웨어, 네트워크 등 )

-  성능 요구사항( 처리속도, 처리량, 가용성 등 )

-  인터페이스 요구사항( 시스템 인터페이스, 사용자 인터페이스, 하드웨어 및 통신 인터페이스 등 )

-  데이터 요구사항

-  테스트 요구사항

-  보안 요구사항

-  품질 요구사항( 가용성, 정합성, 상호 호환성, 대응성, 신뢰성, 이식성, 확장성, 보안성 등 )

 

※  사용자 요구사항

•  사용자 관점에서 본 시스템이 제공해야 할 요구사항

•  사용자가 이해하기 쉽게 작성

 

※  시스템 요구사항( = 소프트웨어 요구사항 )

•  개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

•  전문적이고 기술적인 용어로 표현

 

 

3) 요구사항 개발 프로세스

도출( Elicitation )/추출  >  분석( Analysis )  >  명세( Specification )  >  확인( Validation )/검증

​

※ 요구사항 도출( = Requirement Elicitation, 요구사항 수집 )

•  소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계

•  개발자와 고객사이의 관계가 만들어지고 이해관계자 식별

•  요구사항 도출은 소프트웨어 개발 생명주기( SDLC ) 동안 지속적으로 반복

•  도출 기법 ( 청취&인터뷰, 설문, 브레인스토밍, 워크숍, 프로토타이핑, 유스케이스 등 )

 

※ 요구사항 분석( = Requirement Analysis )

•  사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않은 부분을 발견 및 거르기 위한 과정

•  요구사항의 타당성을 조사하고 비용과 일정에 대한 제약 설정

•  서로 상충되는 요구사항이 있으면 중재하는 역할

•  분석에 사용되는 자료( 자료 흐름도( DFD ), 자료 사전( DD ) 등 )

 

※  요구사항 명세( = Requirement Specification )

•  분석된 요구사항을 바탕으로 모델 작성 및 문서화

•  기능 요구사항은 빠짐없이 명확하게 기술 / 비기능 요구사항은 필요한 것만 명확하게 기술

 

※  요구사항 확인( = Requirement Validation, 요구사항 검증 )

•  요구사항 명세서가 정확하고 완전하게 작성되었는지 검토

•  문제가 발견되면 재작업 비용이 발생하므로 검증단계는 중요

•  이해관계자들을 통해 검증 필요

 

 

4) 요구사항 분석

•  개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미

•  요구사항의 타당성을 조사하고 비용과 일정에 대한 제약 설정

•  목표를 정하고 어떤 방식으로 해결할 것인지 결정

•  사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화해야 한다.

•  요구사항 분석 도구 : UML( Unified Modeling Language ), 자료흐름도( DFD ), 자료사전( DD ), 개체 관계도( ERD)

                                          상태전이도( STD ), 제어명세서 등

 

•  구조적 분석 기법

-  도형 중심의 분석용 도구 + 분석 절차를 이용하여 사용자의 요구를 파악하고 문서화

-  하향식 방법을 사용하여 시스템을 세분화, 분석의 중복을 배제

-  분석의 질이 향상되고, 시스템 개발의 모든 단계에서 필요한 명세서 작성 가능

 

※  자료 흐름도( = Data Flow Diagram DFD, 자료흐름그래프, 버블차트 )

•  자료의 흐림 및 변환과정과 기능을 도형중심으로 기술하는 방법

• 시스템 안의 프로세스와 자료저장소 사이에 자료의 흐름을 나타내는 그래프

•  자료흐름과 처리를 중심으로 하는 구조적 분석기법에 이용

•  DFD 요소 : 프로세스( Process ), 자료흐름( Data Flow ), 자료저장소( Data Store ), 단말( Terminator )

 

※  자료 사전( = Data Dictironary DD )

•  자료흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용 가능

•  자료사전 표기 : 자료의 정의 ( = ), 자료의 연결( + ), 자료의 생략( ( ) ), 자료의 선택( [ ] ), 자료의 반복( { } ), 자료의 설명( ** )

•  개념 모델링( UML )

•  요구사항 할당

•  요구사항 협상

•  정형적 분석

 

 

※  요구사항 분석 CASE ( 자동화 도구 )

•  요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구

•  자동화 도구 종류 : SADT, SREM, PSL/PSA, TAGS 등

 

---

 

UML

​

 

 

•  시스템 개발 과정에서 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인

    객체지향 모델링 언어이다.

•  6개의 구조 다이어그램 + 시스템의 동작을 표현하는 7개의 행위 다이어그램 작성 가능

 

 

1) UML( Unified Modeling Language )의 구성요소

•   사물( Things ) / 관계( Relationship ) / 다이어그램( Diagram )

 

 

2) 사물( Things )

•   구조 사물( Structure Things )

-  시스템의 개념적, 물리적 요소를 표현

-  클래스( Class) , 유스케이스( Use Case ), 컴포넌트( Component ), 노드( Node ) 등

 

•   행동 사물( Behavioral Things )

-  시간과 공간에 따른 요소들의 행위를 표현

-  상호작용, 상태머신 등

 

•   그룹 사물( Grouping Things )

-  요소들을 그룹으로 묶어서 표현

-  패키지( package )

 

•   주해 ( Annotation Things )

-  부가적인 설명이나 제약조건 등 표현

-  노트( Note )

 

 

3) 관계( Relationships )

•   연관( - ) 관계

-  2개 이상의 사물이 서로 관련되어 있음을 표현

-  실선으로 연결하여 표현, 방향성은 화살표로 표현

-  서로에게 영향을 주는 양방향 관계의 경우 화살표 생략하고 실선으로만 연결

 

•   집합( ◇ ) 관계

-  하나의 사물이 다른 사물에 포함되어 있는 관계

-  포함하는 쪽과 포함되는 쪽은 서로 독립적

-  포함되는 쪽에서 포함하는쪽으로 빈 마름모를 연결하여 표현

 

•   포함( ◆ ) 관계

-  포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

-  포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현

 

•   일반화( -▷) 관계

-  하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현

-  보다 일반적인 개념을 상위( 부모 ), 보다 구체적인 개념을 하위( 자식 ) 

-  하위에서 상위로 속이 빈 화살표를 연결

 

•   의존( --> ) 관계

-  필요에 의해 서로에게 짧은시간 동안만 연관을 유지하는 관계

-  한 클래스가 다른 클래스를 매개변수로 사용하는 경우

-  영향을 주는 사물

 

•   실체화( --▷ ) 관계

-  사물이 할 수 있거나 해야하는 기능으로 서로를 그룹화 할수 있는 관계를 표현

-  한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정

-  사물에서 기능쪽으로 속이 빈 점선 화살표 연결

 

4) 다이어그램

•  사물과 관계를 도형으로 표현

•  정적 모델링에서는 주로 구조적 다이어그램을 사용

•  동적 모델링에서는 주로 행위 다이어그램을 사용

 

•  구조적 다이어그램 ( Structure Diagram ) 종류

-  클래스 다이어그램 ( Class Diagram )

-  객체 다이어그램( Object Diagram )

-  컴포넌트 다이어그램( Component Diagram )

-  배치 다이어그램( Deployment Diagram )

-  복합체 구조 다이어그램( Composite Structure Diagram )

-  패키지 다이어그램( Package Diagram )

 

•  행위 다이어그램( Behavioral Diagram )  종류

-  유스케이스 다이어그램( Usecase Diagram )

-  순차 다이어그램( Sequence Diagram )

-  커뮤니케이션 다이어그램( Communication  Diagram )

-  상태 다이어그램( State Diagram )

-  활동 다이어그램( Activity Diagram )

-  상호작용 개요 다이어그램( Interaction Overview Diagram )

-  타이밍 다이어그램( Timing Diagram )

 

 

6) 스테레오 타입 객체를 표현할 때 사용하는 기호

•    기본 기능 외에 추가적인 기능을 표현하기 위해 사용

•    << include >> , << extend >> , << interface >> , << exception >> , << constructor >>

 

※  시퀀스 다이어그램의 구성항목

•  생명선 / 실행 / 메시지 / 액터 / 객체

 

 

7) 유스 케이스( Use Case ) 다이어그램

•  개발될 시스템과 관련된 외부 요소, 즉 사양자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을

    사용자의 관점에서 표현

•  외부 요소와 시스템 간의 상호작용 확인 가능

•  사용자의 요구사항을 분석하기 위한 도구

•  시스템의 범위 파악 가능

 

•  구성요소

-  시스템 / 시스템 범위 : 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 사각형으로 묶어 시스템의 범위 표현

-  액터(  Actor ) : 시스템과 상호작용을 하는 모든 외부 요소 ( 사람, 외부 시스템 )

-  유스케이스( Use Case ) : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현

-  관계( Relationship ) : 연관 / 포함 / 확장 / 일반화 관계 표현 가능

 

※  관계 

-  연관 : 액터와 사용자 사이의 관계 ( 시스템 기능에 접근하여 사용할 수 있음을 의미 )

-  포함 : 중복된 것을 줄이기 위한 방법 ( 함수의 호출처럼 포함된 사용 사례 호출 )

-  확장 : 특별한 조건을 만족할 때 수행

-  일반화 : 상속을 의미, 유사한 사용 사례를 모아 일반적인 사용사례 정의

​

 

8) 클래스 다이어그램

•  클래스의 특성인 속성과 오퍼레이션, 제약조건, 관계를 표현한 것

•  시스템의 구성요소에 대해 알수 있는 구조적 다이어그램ㅌ

•  시스템 구성요소를 문서화 하는데 사용

•   객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링한 것이다.

 

•  구성요소

-  클래스( Class ) : 각각의 객체들이 갖는 속성과 오퍼레이션( 동작 ) 을 표현

-  제약조건 : 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건

-  관계 : 클래스와 클래스 사이의 연관성을 표현

 

 

9) 순차 다이어그램

•  시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터 , 객체, 메시지등의

   요소를 사용하여 그림으로 표현

•  시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지 표현

•  각 동작에 참여하는 시스템이나 객체들의 수행기간 확인 가능

•  수직방향은 시간의 흐름

•  클래스 내부에 있는 객체들을 기본단위로 하여 그들의 상호작용 표현

 

•  구성요소

-  액터( Actor ) : 서비스를 요청하는 외부 요소로 사람이나 외부 시스템 의미

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

-  생명선( Lifeline ) : 객체가 메모리에 존재하는 기간

-  실행상자( Active Box ) : 객체가 메시지를 주고받으며 구동되고 있음을 표현

-  메시지( Message ) : 객체가 상호작용을 위해 주고받는 메시지

-  회귀 메시지( Return Message ) : 객체가 처리한 반환값이 담긴 메시지

-  제어블록(  Loop , Statement Block ) : 반복처리되는 영역 표시

 

 

---

 

사용자 인터페이스( UI : User Interface )

​

 

 

•   사용자와 시스템간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어 의미

•   정보내용을 전달하기 위한 표현 방법

 

•   사용자 인터페이스( UI ) 분야

-  정보제공과 전달을 위한 물리적 제어 분야

-  콘텐츠의 상세적인 표현과 전체적인 구성 분야

-  사용자가 편리하고 간편하게 사용하도록 하는 기능 분야

 

•  사용자 인터페이스( UI ) 특징

-  소프트웨어 영역 중 변경이 가장 많이 발생

-  사용자의 편리성과 가독성을 높임으로써 작업시간을 단축, 업무에 대한 이해도를 높여줌

-  사용자 중심으로 설계되어 사용자 중심의 상호작용이 되도록 함

-  정보 제공자와 정보 이용자간의 매개역할 수행​

 

 

1) 사용자 인터페이스( UI )의 구분

•  CLI( Command Line Interface ) : 명령과 출력이 텍스트 형태

•  GUI( Graphical User Interface ) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경

•  NUI( Natural User Interface ) : 사용자의 말이나 행동으로 기기를 조작

•  VUI( Voice User Interface ) : 사람의 음성으로 기기를 조작

•  OUI( Organic User Interface ) : 모든 사물과 사용자 간의 상호작용

 

※ 모바일 기기 사용 NUI 인터페이스

•   Tab( 누르기 ), Double Tab( 두번 누르기 ), Drag( 누른 채 움직임 ), Pan( 누른채 계속 움직임 ), Press( 오래 누르기 )

    Flick( 빠르게 스크롤 ), Pinch( 두 손가락으로 넓히기 / 좁히기 ) 등

 

 

2) 사용자 인터페이스( UI )의 기본원칙

•  직관성( intuitiveness ) : 누구나 쉽게 이해하고 사용할 수 있도록 제작

•  유효성( Efficiency ) : 사용자의 목적을 정확하고 완벽하게 달성될 수 있도록 제작

•  학습성( Learnability ) : 누구나 쉽게 배우고 익힐 수 있게 제작

•  유연성( Flexibility ) : 사용자의 요구사항을 최대한 수용, 실수 방지할 수 있도록 제작

 

 

3) 사용자 인터페이스( UI ) 설계지침

•  사용자 중심 : 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경 제공 ( 실사용자에 대한 이해가 바탕이 되어야 함 )

•  사용성 : 사용자가 얼마나 빠르고 쉽게 이해 가능한지, 얼마나 편리하고 효율적으로 사용할 수 있는지

•  일관성 : 사용자가 쉽게 기억하고 습득할 수 있게 설계해야 함

•  단순성 : 조작 방법을 단순화시켜 인지적 부담 감소

•  결과 예측 가능 : 작동시킬 기능만 보고 결과를 미리 예측할 수 있게 설계

•  가시성 : 메인화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계

•  심미성 : 디자인적으로 완성도 높은 글꼴 및 색상을 적용 그래픽 요소를 배치하여 가독성을 높이도록 설계

•  표준화 : 기능 구조와 디자인을 표준화하여 한번 학습 이후 쉽게 사용할 수 있도록 설계

•  접근성 : 사용자의 연령, 성별, 인종등 다양한 계층이 사용가능토록 설계

•  명확성 : 사용자가 개념적으로 쉽게 인지할 수 있도록 설계

•  오류 발생 해결  : 오류가 발생하면 사용자가 쉽게 인지토록 설계

 

 

4) 사용자 인터페이스( UI ) 개발 시스템의 기능

•  사용자의 입력을 검증

•  에러처리와 그에 관련된 에러 메시지 표시

•   도움과 프롬프트( Prompt ) 제공

 

 

5) UI 설계 도구

 

•  와이어프레임( Wireframe )

-  기획단계의 초기에 제작

-  페이지에 대한 개략적인 레이아웃, UI 요소등에 대한 뼈대를 설계

-  각 페이지의 영역 구분, 콘텐츠, 텍스트 배치등을 화면 단위로 설계

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

 

•  스토리보드( Storyboard )

-  와이어프레임 + 콘텐츠에 대한 설명, 페이지간 이동 흐름등을 추가한 문서( 구체적인 작업 지침서 역할 )

-  디자이너 / 개발자가 참고하는 최종적인 산출문서로써 정책, 비즈니스, 프로세스, 콘텐츠

-  구성, 와이어프레임, 기능 정의, 데이터베이스 연동 등 서비스 구축을 위한 모든 정보가 담겨 있는 문서

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

 

•  목업( Mockup )

-  와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적힌 형태의 모형

-  시각적으로만 구성 요소를 배치하는 것으로 일반적으로 실제로 구현 X

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

 

•  프로토타입( Prototype )

- 와이어프레임 or 스토리보드 + 다양한 인터랙션이 결합되어 실제 서비스처럼 작동하는 모형

-  사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플

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

 

•  유스 케이스( Usecase )

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

-  요구사항을 빠르게 파악하여 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 문서화할 수 있다.

-  시스템이 어떤 기능을 수행하고, 주위에 어떤 것이 관련되어 있는지를 나타낸 모형

-  외부에서 보는 시스템의 동작, 외부 객체들이 어떻게 시스템과 상호작용하는지 모델링

 

 

6) UI 시나리오 문서 요건

이해성( Understandable ) / 완전성( Complete ) / 일관성( Consistent ) /

가독성( Readable ) / 수정 용이성( Modifiable ) / 추적 용이성( Traceable )

​

 

---

 

품질 요구사항

 

 

 

1) 국제 제품 품질 표준

ISO/IEC 9126 , ISO/IEC12119 , ISO/IEC14598 , ISO/IEC25000 ( 왼쪽 3개 표준을 통합 )

 

 

2) ISO / IEC 9126

•  소프트웨어 품질 특성과 평가를 위한 표준 지침으로 국제표준으로 널리 사용됨

•  2011년에 호환성과 보안성을 강화하여 ISO/IEC 25010 으로 개정됨

 

•  ISO/IEC 9126 소프트웨어 품질 특성

-  기능성( Functionality )

-  신뢰성( Reliability )

-  사용성( Usability )

-  효율성( Efficiency )

-  유지 보수성( Maintainability )

-  이식성( Portability )

 

※  기능성( Functionality )

•  소프트웨어가 사용자의 요구사항을 정확하게 마족하는 기능을 제공하는지 여부

-  적절성 / 적합성( Suitability )

-  정밀성/정확성( Accuracy )

-  상호 운용성( Interoperability )

-  보안성( Security )

-  준수성( Compliance )

 

※  신뢰성( Reliability )

•  소프트웨어가 요구된 기능을 정확하고 일관되게 오류없이 수행할 수 있는 정도

-  성숙성( Maturity )

-  고장 허용성( Fault Tolerance )

-  회복성( Recoverability )

 

※  사용성(Usability )

•  사용자가 쉽게 배우고 사용 가능, 다시 사용하고 싶은 정도

-  이해성( Understandability )

-  학습성( Learnability )

-  운용성( Operability )

-  친밀성( Attractiveness )

 

※  효율성( Efficiency )

•  사용자가 요구하는 기능을 할당된 시간동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지 정도

-  시간 효율성( Time Behaviour )

-  자원 효율성( Resource Behaviour )

 

※  유지 보수성( Maintainability )

•  새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도

-  분석성( Analyzability )

-  변경성( Changeability )

-  안정성( Stability )

-  시험성( Testability )

 

※  이식성( Portability )

•  소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도

-  적용성( Adaptability )

-  설치성( Installability )

-  대체성( Replaceability )

-  공존성( Co-existence )

 

 

3) ISO/IEC 25010

•   소프트웨어에 대한 국제 표준으로, 2011년 ISO/IEC 9126 개정함

•  ISO/IEC 25010 소프트웨어 품질 특성

-  기능 적합성

-  성능 효율성

-  호환성

-  사용성

-  신뢰성

-  보안성

-  유지보수성

-  이식성

 

 

4) ISO / IEC 25000 : 소프트웨어 품질 평가 통합모델

•  2500n : 품질 관리

•  2501n : 품질 모델

•  2502n : 품질 측정

•  2503n : 품질 요구

 

 

※  ISO/IEC 12119

•  패키지 소프트웨어의 일반적인 제품 품질 요구사항 및 테스트를 위한 국제 표준

 

 

---

 

객체지향( Object - Oriented )

 

•  소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법​

•  소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 게발가능하고 유지보수가 쉽다.

•  주요 구성 요소 및 개념 : 객체( Object ), 클래스( Class ), 캡슐화( Encapsulation ), 상속( Inheritance ),

                                               다형성( Polymorphism ), 연관성( Relationship ) 

 

 

1) 객체( Object )

•  데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈

-  데이터 : 객체가 가지고 있는 정보로 속성이나 상태, 분류

-  함수 : 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘

 

•  현실세계에 존재할 수 있는 유형 / 무형의 모든 대상

•  객체가 가질 수 있는 조건을 상태( State ) 라고 하며 일반적으로 상태는 시간에 따라 변함

•  객체와 객체는 상호 연관성에 의한 관계 형성

•  독립적으로 식별 가능한 이름을 가진다.

•  일정한 기억 장소를 가지고 있다.

•  속성과 메서드로 정의된다. ( 객체의 상대틑 속성 값에 의해 정의 )

 

※  메서드( Method )

•  생성된 객체를 사용하는 방법

•  시스템의 함수( Function ) 또는 프로시저( Procedure )에 해당하는 연산

 

 

2) 클래스( Class )

•  하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현

•  객체지향 프로그램에서 데이터를 추상화하는 단위

•  클래스에 속한 각각의 객체를 인스턴스( Instance )라 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화 라고 한다.

•  각각의 객체들이 갖는 속성과 연산( Method )을 정의하는 틀

•  슈퍼클래스( Super Class )는 특정 클래스의 상위( 부모 ) 클래스

•  서브클래스( Sub Class )는 특정 클래스의 하위( 자식 ) 클래스

 

 

3) 캡슐화( encapsulation )

•  데이터( 속성 )와 데이터를 처리하는 함수를 하나로 묶는 것

•  인터페이스를 제외한 세부내용이 은폐(정보 은닉) 되어 외부 접근 제한  ( 필요한 인터페이스만 밖으로 드러냄 )

•  정보 은닉 측면과 가장 밀접한 관계

•  외부 모듈의 변경으로 인한 파급효과가 적다

•  재사용 용이 , 인터페이스 단순화

•  결합도 Down / 응집도 Up

 

 

4) 상속( Inheritance )

•  정의된 상위(부모) 클래스의 모든 속성과 연산을 하위(자식) 클래스가 물려받는 것

•  소프트웨어의 재사용( Reuse )을 높이는 중요한 개념

 

※  다중 상속

•  한개의 클래스가 두개 이상의 상위 클래스로부터 속성과 연산을 상속 받는 것

 

 

4) 다형성( Polymorphism )

•  하나의 메시지에 대해 각각의 객체( 클래스 )가 가지고 있는 고유한 방법( 특성 )으로 응답할 수 있는 것

•  주로 동적 바인딩에 의해 실현된다.

    ex) “ + ” 연산자의 경우, 숫자 클래스에서는 덧셈 기능, 문자 클래스에서는 연결 기능

•  현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있게 한다.

•  메서드 오버 라이딩( Overriding )은 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 무시하고 재정의할 수 있다.

 

※ 메시지( Message )

객체에게 어떤 행위를 하도록 지시하기 위한 방법

 

 

5) 연관성( Relationship )

•  두 개 이상의 객체( 클래스 ) 들이 상호 참조하는 관계

•  연관성의 종류

-  is member of ( = 연관화, Association ) : 2개 이상의 객체가 상호 관련되어 있음

-  is instance of ( = 분류화, Classfication ) : 동일한 형의 특성을 갖는 객체들을 모아 구성

-  is part of ( = 집단화, Aggregation ) : 관련 있는 객체들을 묶어 하나의 상위 객체 구성

-  is a ( = 일반화, Generalization ) : 공통적인 성징들로 추상화한 상위 객체를 구성

 

 

6) 객체지향 분석

•  객체지향 분석( OOA : Object Oriented Analysis ) 은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든

    클래스( 객체 ) , 이와 연관된 속성과 연산, 그들간의 관계등을 정의하여 모델링

 

 

7) 객체지향 분석 방법론

•  Rumbaugh( 럼바우 ) 방법

-  가장 일반적으로 사용되며, 분석활동을 객체모델, 동적모델, 기능모델로 나누어 수행

 

•  Booch 방법 ( 부치, OOAD )

- 여러 가지 방법론을 통합하여 하나의 방법론 만듦 ( 분석보다는 설계 쪽에 중점 )

- 설계를 위한 문서화 기법을 강조

-  클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의

 

•  Coad / Yourdon 방법

-  E-R 다이어그램을 사용하여 객체의 행위를 모델링하며 객체 식별, 구조 식별, 주체 정의속성 및

   관계 정의, 서비스 정의 등의 과정으로 구성

 

•  Jacobson 방법

-  Usecase를 강조하여 사용하는 분석 방법

 

•  Wirfs-Brock 방법

-  분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행

 

 

※  럼바우( Rumbaugh ) 분석 방법

•  객체 모델링 기법( = OMT, Object-Modeling Technique ) 라고 부른다.

•  분석 활동은 객체 모델링  >  동적 모델링  >  기능 모델링 순으로 이루어짐

-  객체 모델링( Object Modeling ) : 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여

                                                                    객체 다이어그램으로 표시

-  동적 모델링( Dynamic Modeling ) : 상태 다이어그램( 상태도 )를 이용하여 시간의 흐름에 따라 객체들 간의 제어흐름

                                                                       , 상호 작용, 동작 순서 등의 동적인 행위를 표현

-  기능 모델링( Functional Modeling ) : 자료 흐름도( DFD ) 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리과정 표현

 

 

 

7) 객체지향 설계 원칙

 

•  SRP( Single Resposibility Principle , 단일 책임의 원칙 )

-  객체는 하나의 책임( 변경의 축 ) 만을 가져야 한다.

-  응집도는 높고, 결합도는 낮게 설계

 

•  DIP( Dependency inversion Principle, 의존관계 역전의 원칙 )

-  클라이언트는 구체 클래스가 아닌 인터페이스에 의존하여 변화에 대처한다.

-  추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존관계를 맺어야 한다.

 

•  ISP( Interface Sergregation Principle, 인터페이스 분리의 원칙 )

-  클라이언트가 분리되어 있으면 인터페이스도 분리된 상태이어야 한다.

-  클라이언트는 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안 된다.

 

•  OCP( Open-Closed Principle , 개방 폐쇄 원칙 )

-  기존 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계되어야 한다.

-  클래스는 확장에 대해 열려있어야 하며 변경에 대해 닫혀있어야 한다.

 

•  LSP( Liskov Substitution Principle, 리스 코프 대체 원칙 )

-  기반 클래스는 파생 클래스로 대체 가능해야 한다.

-  서브타입은 어디에서나 자신의 기반 타입으로 교체할 수 있어야 한다.

-  자식 클래스는 최소한 부모클래스에서 가능한 행위는 수행 할 수 있어야 한다.

​

 

 

 

---

 

럼바우 객체지향 분석

​

 

 

•  객체 모델링 : 객체 다이어그램( 객체 관계 )으로 표시 ( 가장 중요하며 선행돼야 함 )

                         ( = 정보 모델링으로도 불린다. )

​

•  동적 모델링 :상태 다이어그램( 상태도 ) 이용해 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호작용, 동작 순서 등의

                           동작인 행위를 표현

​

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

​

 

•  객체지향 분석 절차 : 객체 모형 > 동적 모형 > 기능 모형

 

---

 

코드( Code )

​

 

•   코드란 파일 시스템을 체계화( 데이터의 수집 / 분류 / 집계 등을 용이하게 하기 위해 ) 하기 위하여

•   처리 대상이 되는 주요 항목에 대하여 사용목적에 따라 문자 / 숫자 / 영숫자 / 기호를 사용하여 만든 것

•  정보를 신속, 정확, 명로하게 전달할 수 있게 한다.

•  일정한 규칙에 따라 작성되며 정보처리의 효율과 처리된 정보의 가치에 많은 영향을 미친다.

 

•  코드의 주요기능

-  식별기능 : 데이터 간의 성격에 따라 구분 가능

-  분류기능 : 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화 가능

-  배열기능 : 의미를 부여하여 나열 가능

-  표준화 기능 : 데이터를 기준에 맞추어 표현 가능

-  간소화 기능 : 복잡한 데이터 간소화 가능

 

•  코드의 종류

​-  연상 코드 : 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용

​-  블록 코드 : 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 묶어서 구분 각 블록 내에서 일련번호를 부여하는 방법

                        ( = 구분코드 )

​-  순차 코드( Sequential Code ) : 일정 기준에 따라 최초의 자료부터 일련번호를 부여 

                                                                ( 자료의 크기순, 발생 순, 가나다순 등 일정 순서대로 )

-  표의 숫자 코드 : 코드화 대상 항목의 성질, 물리적 수치를 그대로 코드에 적용 ( = 유효숫자 코드 )

​

 

 

 

---

 

모듈

​

•  모듈화를 통해 분리된 시스템의 각 기능

•  서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업단위 등과 같은 의미

 

•  모듈은 단독으로 컴파일 가능, 재사용 가능

•  모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제

•  독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈에게 영향을 미치지 않으며 오류가 발생해도 쉽게 해결 가능

•  모듈의 독립성 : 독립성을 높이기 위해서 결합도는 약하게 응집도는 강하게 모듈의 크기는 작게 만든다.

 

※  결합도( Coupling )

•   모듈간 상호 의존하는 정도 or 두 모듈 사이의 연관 관계

•   결합도가 약할수록 품질이 높고 강할수록 품질이 낮다.

•   결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다.

 

•   결합도 종류 ( 위에서 아래로 갈수록 결합도가 강함 )

-  자료 결합도( Data Coupling ) : 모듈간의 인터페이스가 자료 요소로만 구성됨

-  스탬프 결합도( Stamp Coupling ) : 모듈간의 인터페이스로 배열이나 레코드등의 자료구조가 전달됨

-  제어 결합도 ( Control Coupling ) : 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어신호를 이용하여 통신 및 제어요소 전달

-  외부 결합도 ( External Coupling ) : 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때

-  공통 결합도 ( Common Coupling ) : 공유되는 공통 데이터 영역을 여러 모듈에서 사용할 때

-  내용 결합도 ( Content Coupling ) : 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참조하거나 수정할 때

 

 

※  응집도( Cohesion )

•  정보 은닉 개념을 확장한 것으로, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련있는 정도

•  모듈이 독립적인 기능으로 정의되어 있는 정도

 

•  응집도의 종류( 위에서 아래로 갈수록 응집도 강함 )

-  우연적 응집도( Coincidental Cohesion ) : 모듈 내부의 각 구성 요소들이 서로 관련없는 요소로만 구성된 경우

-  논리적 응집도( Logical Cohesion ) : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우

-  시간적 응집도( Temporal Cohesion ) : 특정 시간에 처리되는 몇개의 기능을 모아 하나의 모듈로 작성할 경우

-  절차적 응집도( Procedural Cohesion ) : 다수의 관련 긴으을 가질때 모듈안의 구성요소들이 그 기능을 순차적으로 수행할 경우

-  교환적 응집도( Communication Cohesion ) : 동일한 입력과 출력을 사용하여 서로 다른 긴으을 수행하는 경우

-  순차적 응집도( Sequential Cohesion ) : 하나의 활동으로부터 나온 출력 데이터를 그다음 활동의 입력데이터로 사용할 경우

-  기능적 응집도( Functional Cohesion ) : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

 

 

•  효과적인 모듈 설계 방안

-  결합도는 줄이고 응집도는 높여 모듈의 독립성과 재사용성을 높인다.

-  모듈의 제어영역 안에서 모듈의 영향영역을 유지

-  복잡도와 중복성을 줄이고 일관성울 유지

-  유지보수가 용이해야 한다.

-  효과적인 제어를 위해 모듈간의 계층적 관계를 정의하는 자료가 제시되어야 함

 

 

 공통 모듈

 

 

•   자주 사용하는 기능들을 다시 사용할 수 있도록 하나의 패키지로 제공하는 독립된 모듈

​

•  공통모듈 명세 기법 준수

-  정확성( Correctness ) : 해당 기능이 실제 시스템 구현 시 필요 여부 정확하게 작성

-  명확성( Clarity ) : 해당 기능에 대해 일관되게 이해하고 한 가지로 해석될 수 있도록 작성

-  완전성( Completeness ) : 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술

-  일관성( Consistency ) : 공통 기능 간에 상호 충돌이 없도록 작성

-  추적성( Traceability ) : 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적인 관계에 대한 식별이 가능하도록 작성

 

•   재사용( Reuse )

-  이미 개발된 기능들을 파악하고 재구성하여 시스템 or 기능 개발 사용하기 적합하도록 최적화

-  외부 모듈과 결합도는 낮고 응집도는 높은 대상

 

•  재사용 규모에 따른 구분

-  함수와 객체 : 클래스나 메소드 단위의 소스코드 재사용

-  컴포넌트 : 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈

                        인터페이스를 통해 통신하는 방식으로 재사용

-  애플리케이션 : 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식

 

 

---

 

인터페이스

​

 

정의

•  서로 다른 두 개의 시스템 / 장치 사이에서 정보나 신호를 주고받는 경우의 접점 or 경계면

    즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미

•  기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어

•  순서적 연산에 의해 소프트웨어를 실행하는 절차

​

 

1) 인터페이스 식별

인터페이스 요구사항 명세서 / 인터페이스 요구사항 목록 기반으로 개발할 시스템과

연결할 시스템 사이의 인터페이스를 식별하고 목록 작성

 

 

2) 인터페이스 시스템 식별

인터페이스에 참여하는 시스템들을 송신시스템 / 수신시스템으로 구분하여 작성

​

•  송신 시스템 : 운영 데이터베이스에서 연계 데이터를 식별 및 추출, 인터페이스 테이블로 생성한 뒤 송신한다

•  수신 시스템 : 수신한 테이블을 수신 시스템의 운영 데이터베이스나 환경에 맞게 변환하여 처리에 활용할 수 있도록 하는                                         시스템

 

 

3) 인터페이스 표준항목

시스템 공통부 : 시스템 간 연동 시 필요한 공통 정보

ex) 인터페이스 ID / 전송 시스템 정보 / 서비스 코드 정보 / 응답 결과 정보 / 장애정보

​

 

거래 공통부 : 송, 수신되는 데이터를 처리할 때 필요한 정보

ex) 직원 정보 / 승인자 정보 / 기기 정보 / 매체 정보

 

---

 

인터페이스 요구사항 검증

​

 

 

1) 요구사항 검토

인터페이스 요구사항 검토 계획 수립 > 검토 및 오류 수정 > 베이스라인 설정

 

 

2) 요구사항 검토 방법

•  동료검토( Peer Review )

- 작성자가 내용 집적 설명 후, 동료들이 결함을 발견하는 방법

- 2 ~ 3 명이 진행하는 리뷰 형태로 작성자가 설명하고, 이해관계자들이 설명을 들으면서 결함을 발견하는 형태

 

•  워크 스루( Walk Through )

- 검토 자료를 검토회의 전 요구사항 명세서 미리 배포하여 사전 검토 후 짧은 검토회의 통해 결함 발견하는 방법

 

•  인스펙션( Inspection )

- 명세서 작성자를 제외한 다른 전문가들이 확인하면서 결함을 발견하는 방법

 

•  인터뷰

- 주로 일대일, 일대다의 요구사항 분석방법

 

•  설문조사

- 불특정 다수에게 특정 항목에 대한 소극적인 의견을 파악하기 위한 방법

 

 

3) 인터페이스 요구사항 검토 주요 항목

기능성( Functionality )

완전성( Completeness )

일관성( Consistency )

명확성( Unambiguity )

검증 가능성( Verifiability )

추적 가능성( Traceability )

변경 용이성( Easily changeable )

 

---

 

미들웨어 솔루션 명세

​

 

 

 

1) DB( Database )

클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어

ex) ODBC( 마이크로소프트 ) , IDAPI( 볼랜드 ) , Glue( 오라클 )

 

 

2) RPC( Remote Procedure Call, 원격 프로시저 호출 )

응용프로그램의 프로시저를 사용해 원격 프로시저를 로컬 프로시저처럼 호출하는 미들웨어

ex) Entera( 이큐브 시스템스 ) , ONC/RPC( OSF )

 

 

3) MOM( Message Oriented Middleware , 메시지 지향 미들웨어 )

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

ex) MQ( IBM ) , Message Q( 오라클 ) , JMS( JCP )

 

 

4) TP-Monitor( Transaction Processing Monitor, 트랜잭션 처리 모니터 )

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

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

- 트랜잭션이 올바르게 처리되고 있는지 데이터를 감시 / 제어

ex) tuxedo( 오라클 ) , tmax( 티맥스소프트 )

 

 

5) Legacyware( 레거시 웨어 )

기존 애플리케이션에 새로운 업데이트된 기능을 덧붙이고자 할 때 사용되는 미들웨어

 

 

6) ORB( Object Request Broker, 객체 요청 중개인 )

객체지향 미들웨어로 코바( CORBA ) 표준 스펙을 구현한 미들웨어

ex) Orbix( Micro Focus ) , CORBA( OMG )

 

 

7) WAS( Web Application Server, 앱 애플리케이션 서버 )

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

- 클라이언트 / 서버 환경보다는 웹 환경을 구현하기 위한 미들웨어

- HTTP 세션 처리를 위한 웹 서버 기능뿐만 아니라 Java , EJB 컴포넌트 기반으로 구현 가능

ex) Web Logic( 오라클 ) , WebSphere( IBM ) , JEUS, Tomcat

 

---

 

DFD( 자료 흐름도 : Data Flow Diagram )

​

 

 

•  가장 보편적으로 사용되는 시스템 모델링 도구, 기능 중심의 시스템을 모델링하는데 적합

•  구조적 분석 기법에 이용된다.

•  자료 흐름 그래프 또는 버블 차트라 고도 부른다.

•  시간 흐름을 명확하게 표현 불가능 X

•  구성 : 프로세스( Process ) / 흐름( Data Folow ) / 자료 저장소( Data Stor ) / 단말( Terminator )

•  표현 : 프로세스 – 원 / 흐름 – 화살표 / 자료저장소 – 평행 직선 두 개 / 외부 엔티티( Terminator ) - 사각형

 

---

 

CASE( Computer Aided Software Engineering )

​

 

 

•  소프트웨어 공학의 자동화 / 하나의 작업을 자동화한 패키지를 CASE 도구

•  CASE도구를 한데 모아놓은 것 = 소프트웨어 공학 환경

    ( Software Engineering Environment )

•  소프트웨어 관리자들과 실무자들이 소프트웨어 프로세스와 관련된 활동을 지원

•  프로젝트 관리 활동을 자동화 / 프로세스에서 생산된 결과물 관리

•  문서 자동화 기능 제공 / 작업자 간의 커뮤니케이션이 증대한다.

•  엔지니어들의 분석, 설계 및 코딩과 테스트 작업을 도와준다.

 

•  주요 기능 : 다양한 소프트웨어 개발 모형 지원, 그래픽 지원, 소프트웨어 생명주기 전 단계의 연결

 

 

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

1) 모델들 사이의 모순 검사 기능

2) 모델의 오류검증 기능

3) 자료 흐름도 작성 기능

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

: 원시 코드 생성 기능

 

---

 

디자인 패턴( GoF )

​

 

 

정의

•  UML과 같은 일종의 설계기법

•  Design Pattern은 설계 방법을 제시한다.

•  자주 접하게 되는 디자인 문제에 대한 기존의 시스템에 적용되어 검증된 해법 재사용성을 높여 쉽게 적용할 수 있는 방법론

​

특성

•  객체지향 방법론의 가장 큰 장점인 재사용성과 모듈성을 극대화시켜 이를 적용하면

시스템 개발은 물론 유지보수에 큰 효과가 있다.

•  시스템 구조를 재사용하기 쉽게 만들 수 있다.

•  절차형 언어( C+ ) 과는 너무 복잡해서 도움이 되지 않는다.

•  범용적인 코딩 스타일로 인해 구조 파악이 용이

•  객체지향 설게 및 구현의 생산성을 높이는데 적합

​

분류

1) 생성 패턴( Creational Pattern )

•  객체의 생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 함

    ( 유연성을 더해준다. )

 

•  추상 팩토리( Abstract Factory )

-  인터페이스를 통해 서로 연관, 의존하는 객체들을 그룹으로 생성해 추상적으로 표현

-  연관된 서브 클래스를 묶어 한번에 교체하는것이 가능

 

•  빌더( Builder )

-  객체의 생성 과정과 표현방법 분리 > 동일한 객체 생성에도 서로 다른 결과

-  작게 분리된 인스턴스를 건축하듯이 조합하여 객체 생성

 

•  팩토리 메서드( Factory Method )

-  객체를 생성하기 위한 인터페이스 정의, 어떤 클래스가 인스턴스화될 것인지는 서브 클래스가 결정하도록 하는 것

-  객체 생성을 서브클래스에서 처리하도록 분리하여 캡슐화한 패턴

-  가상 생성자 패턴이라고도 한다.

 

•  프로토타입( Prototype )

-  원본 객체를 복제하는 방법으로 객체 생성

-  비용이 큰 경우 주로 이용

 

•  싱글톤( Singleton)

-  하나의 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수 X

-  불필요한 메모리 낭비를 최소화 가능

 

​

2) 구조 패턴( Structural Pattern )

•  클래스나 객체를 조합하여 더 큰 구조로 만들수 있게 해준다.

 

•  어댑터( Adapter )

-  호환성이 없는 클래스 인터페이스를 다른 클래스가 이용할 수 있도록 변환

-  기존의 클래스와 인터페이스가 일치하지 않을때 이용

 

•  브리지( Bridge )

-  구현부에서 추상층을 분리, 독립적으로 확장 및 다양성을 가짐

-  기능과 구현을 두개의 별도 클래스로 구현

 

•  컴포지트( Composite )

-  여러 객체를 가진 복합, 단일 객체를 구분 없이 다룰 때 사용

-  객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합객체가 포함되는 구조 구현

 

•  퍼 싸드( Facade )

-  서브클래스들의 기능을 간편하게 사용할 수 있도록 함

-  서브 클래스들 사이의 통합 인터페이스 제공하는 Wrapper 객체 필요

 

•  플라이 웨이트( Flyweight )

-  인스턴스를  공유해서 사용함으로써 메모리 절약

-  다수의 유사 객체를 생성하거나 조작할때 유용

 

•  프락시( Proxy )

-  접근이 어려운 객체를 연결해 주는 인터페이스 역할 수행

-  네트워크 연결, 메모리의 대용량 객체로의 접근등에 주로 이용

 

​

 

 

3) 행위 패턴

•  클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의

 

 

 

 

---

 

 

자료 사전

​

 

정의

•  자료 사전은 개발 시스템과 연관된 자료 요소들의 집합

•  저장 내용이나 중간 계산 등에 관련된 용어를 이해할 수 있는 정의

자료 사전 기호	의미
=	항목의 정의( ~로 구성되어 있다. )
+	그리고 / 순차( and )
( )	선택사양 / 생략가능( Optional )
{ }	반복( iteration )
[ ]	여러 대안 중 하나 선택
**	주석( Comment )

 

---

 

상향식 설계 / 하향식 설계

​

 

•  하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.

•  하향식 설계에서는 레벨이 낮은 데이터 구조의 세부사항은 설계 초기 단계에서 필요하다.

•  상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사

 

상향식 설계

 

하향식 설계

 

---

 

 

소프트웨어 아키텍처 설계

​

 

 

•  소프트웨어 컴포넌트들과 그들의 외부적으로 보이는 특성으로 그들 상호 간의 관계들로 구성되는 해당 시스템의 구조

•  소프트웨어의 골격이 되는 기본 구조, 품질 특성과 개발 진행방법에 영향을 준다.

•  비기능적 요구사항으로 나타난 제약을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결과정 

•  소프트웨어 개발을 성공적으로 이끌기 위한 중요한 역할 수행

​

•  기본원리

-  모듈화

-  추상화

-  단계적 분해

-  정보은닉

 

※  모듈화

•  소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지관리 등이 용이하도록 시스템의 기능들을 모듈단위로 나누는 것

•  프로젝트의 재사용성 향상

•  기능의 분리가 가능하여 인터페이스가 단순해짐

•  프로그램의 효율적인 관리가 가능하고 오류의 파급효과를 최소화 할 수 있다.

 

※  추상화

•  전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시켜 나가는 것

•  최소의 비용으로 실제 상황에 대처 가능하고 시스템의 구조 및 구성을 대략적으로 파악 가능토록 한다.

•  유형

-  과정 추상화

-  데이터 추상화

-  제어 추상화

 

※  정보 은닉

•  한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

•  모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않아 수정, 시험, 유지보수가 용이

 

0) 소프트웨어 아키텍처 설계 과정

•  설계목표 설정

•  시스템 타입 결정

•  아키텍처 패턴 적용

•  서브시스템 구체화

•  검토

 

※  시스템 타입

•  시스템 타입의 구분

-  대화형 시스템 : 시스템이 이를 처리하고 반응하는 시스템 ( 웹 애플리케이션 )

-  이벤트 중심 시스템 : 외부의 상태 변화에 따라 동작하는 시스템( 전화, 비상벨 등 내장 소프트웨어 )

-  변환형 시스템 : 데이터가 입력되면 정해진 작업들을 수행하여 결과를 출력하는 시스템(  컴파일러, 네트워크 프로토콜 등 )

-  객체 영속형 시스템 : 데이터베이스를 사용하여 파일을 효과적으로 저장/검색/갱신할 수 있는 시스템( 서버 관리 소프트웨어 )

 

 

 

---

 

아키텍처 패턴

 

 

•  아키텍처를 설계할 때, 참조할 수 있는 전형적인 해결방식 또는 예제

•  아키텍처 스타일 또는 표준 아키텍처라고도 한다.

 

 

1) 저장소 구조

•  서브 시스템들이 단일 중앙 저장소의 자료를 접근하고 변경한다.

•  서브 시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화

 

 

2) MVC 구조( Model - View - Controller Pattern )

•  모델 / 뷰 / 제어구조라는 세 가지 다른 서브 시스템으로 구성

•  사용자 인터페이스 즉, 뷰와 제어가 도메인 지식을 나타내는 모델보다는 저 자주 변경될 수 있기 때문에 분리

•  사용자 인터페이스를 담당하는 계층의 응집도를 높일 수 있고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다.

•  뷰( View )는 모델( Model )에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당

•  제어( Controller )는 모델( Model )에 명령을 보냄으로써 모델의 상태를 변경할 수 있다.

 

 

3) 파이프 필터 구조( Pipe - Filtter Pattern )

•  데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 하여 파이프를 통해 데이터를 전송

•   데이터 변환, 버퍼링, 동기화 등에 주로 사용

•  데이터 변환으로 인한 오버헤드가 발생

•  서브 시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업 반복

•  서브시스템 : 필터 / 서브시스템 사이의 관계 : 파이프

•   대표적으로 UNIX 의  Shell 이 있다.

 

 

4) 계층 구조 ( Layers pattern )

•  각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용

•  추상화의 성질을 잘 이용한 구조

 

 

5) 마스터 - 슬레이브 패턴( Master - Slave Pattern )

•  마스터 컴포넌트는 동일한 구조의 슬레이브 컴포넌트로 작업을 분할한 후 , 슬레이브 컴포넌트에서 처리된

   결과물을 다시 돌려받는 방식으로 작업 진행

•  장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 사용

•  일반적으로 실시간 시틈에서 사용

•  마스터와 슬레이브는 구조가 동일하여 기능도 동일하게 수행 가능

 

 

※  소프트웨어 아키텍처

•  데이터 중심 아키텍처는 공유 데이터 저장소를 통해 접근자 간의 통신이 이루어지므로 각 접근자의 수정과 확장이 용이

•  이해 관계자들의 품질 요구사항을 반영하여 품질속성 결정

 

 

※  피어 투 피어 ( Peer - To - Peer )

•  여러 컴포넌트들 중 각 컴포넌트들이 서비스를 제공하는 서버가 될 수도 있고, 요청하는 클라이언트도 될 수 있는 패턴

•  전형적인 멀티스레딩을 사용하는 방식

 

 

---

 

 

N-S 차트 ( Nassi-Schneiderman Chart )

 

 

•   논리의 기술에 중점을 둔 도형을 이용한 표현 방법

•  박스 다이어그램, Chapin Chart 라고도 함

 

•  연속, 선택 및 다중선택, 반복등의 제어 논리구조 표현

•  GOTO 나 화살표 사용 X

•  선택과 반복구조를 시각적으로 표현

•  이해하기 쉽고, 코드 변환이 용이

•  총체적인 구조 표현과 인터페이스를 나타내기가 어렵습니다.

•  단일 입구와 단일 출구로 표현