[시스템 분석 및 설계]요약정리

2010년 4월 20일

1. 소프트웨어공학

1.1 SE?

소프트웨어의 개발, 운영, 유지보수를 위해 체계적이고, 통제되며, 정량적인 접근방법을 적용하는 것. 즉, 소프트웨어에 공학을 적용하는 것. (The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software

 

1.2 SE 목적은?

양질의 소프트웨어를 제작하기 위함이다.

-양질 = 사용자요구기능/ 재사용에 의한 높은 생산성/ 용의한 유지보수/높은 성능/ 기타

 

1.3 SE 핵심주제 3가지는?

① 프로세스 : 제품생산을 위해 수행되는 순서화된 활동 (분석-설계-구현-테스팅-유지보수)

② 방법 : 구조적방법론/객체지향방법론/ Agile방법론

※ Agile : 요구변화에 빠르고, 유연한 반응

③ 도구:프로세스와 관련된 작업이나 방법을 지원하는 컴퓨터 시스템

CASE(Computer Aided Software Engineering) 도구

 

2. 소프트웨어 개발 프로세스

2.1 폭포수 모델과 반복점증 모델의 차이점을 쓰시오.

- 점증모델의 강점

낮은 프로젝트 실패율, 향상된 생산성, 낮은오류률, 높은 위험을 초기에 경감시킴

 

3. UP

3.1 UP 특징은?

● 반복점증 소프트웨어 개발 프로세스에서 유명하다. (도입, 정제, 구축, 전이)

● Unified Process (통합된 프로세스?)

● iterative-and incremental software development 방법론

● UML-based modeling 방법론

● Use-case driven 방법론

● UP는 다른 방법들로부터 다양한 개념 도입

test-driven development

refactoring and continuous integration

risk-driven iterative development

architecture-centric iterative development

Not having a solid core architecture is a common high risk.

programming in pairs

agile approach

‘Agile’ means rapid and flexible response to change

 

※ 비기능적인거에 영향을 많이 받는다.

 

3.2 반복점증 활동분야 3가지

비즈니스 모델링 : 애플리케이션 도메인에서 가치있는 개념을 시각화 하기 위한 모델 산출물

요구사항 : 기능적/ 비기능적 요구사항을 표현하기 위한 유즈케이스 모델 및 보충명세서

설계: 소프트웨어 객체를 설계하기 위한 설계모델 산출

3.3

 

※ 노력과 강조점은 시간이 지나면서 변한다.

3.4 크게 뽑아서 이해

3.5 UP Phases

● Inception phase의 목적은 시스템을 개발할 가능성이 있는지 개발 가치가 있는지 충분히 조사하여 결정 하는 단계

● 공동 비전(목적) 수립

● 상위 수준에서 프로젝트 범위 설정

● 상위 수준의 위험요소 파악

● 비즈니스 사례 생성

● 기본적인 요구조사 (10%)

● 기본적인 비기능 요구조사

● 주의점

- Inception phase는 요구분석 단계가 아니며, 대부분 주요 요구분석 활동은 elaboration phase(정제단계)에 서 수행

- 객체지향과 관계 없음

- 상대적으로 짧은 시간(1주)에 수행

- 약간의 프로그래밍 필요

- 중요한 기술적인 문제를 해결하기 위해,

- 불명확한 주요 요구를 명확하게 하기 위해 ‘proof of concept’ 프로토타입 개발

 

3.6 Inception Artifacts

● 비전 및 비즈니스 케이스 : 상위수준의 목표 및 제약사항, 비즈니스 케이스를 기술하고 행정적인 요약문서를 제공한다.

● 유즈케이스 모델 : 기능적요구사항을 기술한다 . 대략 10%정도의 유즈케이스는 상제한 수준에서 분석한다.

● 보충명세서 : 비기능적요구사항을 기술한다.

● 용어집 : 핵심이 되는 도메인 용어 및 데이터사전

 

3.7 Elaboration Pharse (정제단계)

● elaboration phase의 목적은 inception phase의 기본 요구들을 반복 정제하여 대부분의 요구를 파악하고 이러한 요구들이 안정화되는 단계

● 프로젝트의 주요 소프트웨어 구조를 반복적으로 구현하고 테스트

● 중요하고 기술적으로 위험한 요소 해결

● 대부분의 요구 파악

 

● 주의점

-Elaboration phase는 반복적(2-6주)으로 수행

-폭포수 모델에서의 설계단계가 아님

-폐기 프로토타입을 개발하는 것이 아니라 최종 시스템의 부분이 되는 increments 생성

-각 반복에서 객체지향 분석/설계 방법을 적용하는 주요 단계

 

3.8 정졔단계 산출물

● 도메인모델 : 도메인 개념을 가시화 한다. -정적정보모델과 유사한다.

● 설계 모델 : 로직설계를 설명하는 다이어그램의 집합이다. (클래스다이어그램, 객체인터렉션다이어그램, 패키지 다이어그램등을 포함한다.)

● 데이터모델 : 데이터스키마, 객체와 비객체 표현간의 매핑전략을 포함한다.

 

4. UML

4.1 UML 이란?

● Unified Modeling Language

● OO 시스템을 설계하고 묘사하는 것을 돕는 그래픽(다이어그램) 표기법

● 그래픽 모델링 언어

● 80-90년대 수많은 OO 그래픽 모델링 언어들의 통합 모델링 언어

 

4.2 UML 특징(UML표기법을 사용하여 모델링 하는 이유?)

● 시스템을 다양한 각도에서 볼 수 있는 시각적인 뷰(view) 제공 -> 시스템 이해 용이

● 다양한 시스템 유형(예, 정보, 내장, 실시간, 제어)에 대하여 모두 적용 가능

● 개발 방법론(구조적, 객체지향…)에 관계 없이 적용 가능

● UML이 표준이 된 이후 모든 CASE 도구는 UML 지원

● 단점 : 복잡함

 

4.3 UML을 적용하는 세가지 방법

● 스케치로서의 UML : 비정형적이고 완벽하지 않은 다이어그램

● 청사진으로서의 UML : 비교적 상세한 설계 다이어그램

● 프로그램 언어로서의 UML : S/W 시스템의 명세를 실행가능 수준까지 완성.

 

4.4 다이어그램에 따른 그림떠올리기.

 

4.5 (왕중요!) UML 시스템의 3가지 관점을 쓰세요.

관점	무엇을 표현했는가?	대표다이어그램
정적관점	시스템에서 사용하는, 객체, 속성,동작, 관계를 표현	structure diagrams
기능관점	사용자의 관점으로부터 시스템의 기능표현	use case diagram
동적관점	객체들이 메시지를 통해 어떻게 상호작용했는가 표현	behavior diagrams

 

6. Use Cases

6.1 요구란?

요구는 시스템이 수행해야 하는 능력(capabilities) 과 조건(conditions)

● 능력 = 기능요구(functional requirements)

● 조건 = 비기능요구(non-functional requirements)

 

6.2 요구의 종류란?

UP에서 요구들은 FURPS+ 모델에 의해 분류

● Functional(기능성) : features, capabilities, security (특징, 기능, 보안)

● Usability(사용성) : human factors, help, documentation (인적요소, 도움말, 문서)

● Reliability(신뢰성) : frequency of failure, recoverability, predictability (복구성, 예측성, 실패빈번도)

● Performance(성능) : response times, throughput(처리량), accuracy, availability, resource usage

(반응시간, 처리량, 정확성, 가용성, 자원사용성)

● Supportability(지원성) : Adaptability, maintainability, internationalization, configurability

(적응성, 유지보수성, 국제화, 구성력)

● FURPS+에서 ‘+’는 기타 요구를 가리킴

- Implementation : Language, tools, hardware, ….

- Interface : constraints by interfacing with external systems (외부시스템과의 연계에서 오는 제약사항)

- Operations : operational setting

- Packaging

- Legal : licensing

 

6.3 Requirements Artifacts in UP

● Use Case Model : 시나리오의 집합

● Supplementary Specification(보충명세) : 비기능적인 것들

● Glossary(용어사전)

● Vision

 

6.4 사용사례 (7)

● 기능요구를 발견하고 기록하기 위해 이용되는 다이어그램이 아닌 텍스트로 작성된 이야기

● 사용자 목적(goals)을 만족하기 위해 시스템을 이용하는 이야기

● 시스템 사용자와 시스템 사이의 상호작용 기술

● 시스템 기능에 대한 요구를 발견하고 정의하기 위해 적용되는 가장 핵심 방법

● 시스템 개발시 객체 지향과 관계 없으나, OOA/D에 입력되는 중요한 요구

● 사용자 요청에 대한 응답으로 시스템이 수행하는 활동

● 시스템이 제공하는 서비스를 표현

 

6.5 사용사례 서술

● 텍스트로 서술

● A use case includes a whole sequence of steps to complete the use case

(유즈케이스를 완성하기 위해 전체 시퀀스 스텝을 포함한다.)

● A use case is a set of scenarios (시나리오의 집합)

● A scenario is a particular sequence of steps within a use case  (시나리오는 UseCase 범위 이내의 집합)

● A use case might have several different scenarios

- Success(정상) scenarios

- Exception(예외) scenarios

● 서술에 대한 3가지 수준

- 간단(brief) : 일반적으로 주요 성공시나리오를 표현하는 간결한 한 문단의 요약

- 중간(intermediate)

- 완전(fully developed) : 모든 단계와 변형이 상세하게 작성된다.

 

6.6 Use case 작성지침

● UI를 고려하지 말고 Use-case작성

-사용자는 ID와 PW를 대화 창에 입력한다

사용자는 신원정보를 제공한다

● Black-box Use-case 작성

-시스템은 판매량을 데이터베이스에 기록한다

시스템은 판매량을 기록한다

● 사용사례의 크기 정도

-사용사례는 한 단계가 아닌 여러 단계를 포함하므로 분석할 가치가 있을 정도의 크기로 사용사례 결정

-보기 1

고객이름 입력 (너무작다)

고객정보입력 (분석에 적당)

고객처리 (너무크다)

-고객정보입력, 고객정보갱신, 고객정보삭제, 미납고객처리

 

6.7 Use Case 발견방법

① 시스템 범위 결정

② Actor 파악

-시스템의 서비스를 이용하여 그들의 목적을 만족시키는 행위자(역할에 의해) 파악

-(보기) POS 시스템에서 ‘고객’이 시스템을 이용하는가 ‘계산원’이 시스템을 이용하는가???

③ 각 Actor의 목적 파악

-actor에게 시스템을 사용하는 목적을 물음

-다음과 같은 문장 이용

“The order clerk(actor) uses the system to create a new order(use case)”

④ actor-goal 목록 작성

⑤ 사용사례 다이어그램 작성

-목적은 사용사례 이름이 됨

 

6.8 Use Case 다이어그램

● Use case는 텍스트 문서

● Use case 다이어그램은 외부 actors과 이러한 actors이 어떻게 시스템을 이용하는가를 간결하게

설명하는 시스템의 그래픽문맥 다이어그램

-문맥(context) 다이어그램 : 시스템의 범위를 보이는 다이어그램

 

6.9 include 관계

하나의 use case 가 공통 use case를 필요로 하는 경우

 

6.10 Use Case 작성을 위한 Activity 다이어그램 활용

● Activity 다이어그램은 작업흐름이나 비즈니스 흐름을 표현하는데 유용

● Use Case는 작업흐름이나 비즈니스 흐름을 포함하므로 use case를 텍스트로 작성하는 것에 대한

대안으로 이용될 수 있음

 

7. Inception (도입)

7.1 도입을 이해하지 못한 경우

도입단계에서 많은 시간을 소비하는 경우

도입단계에서 대부분의 요구를 정의하려고 시도하는 경우

신뢰할 수 있는 추정(estimates)이나 계획(plans)이 기대되는 경우

프로젝트에 대한 비즈니스 케이스나 비전을 정의하지 않는 경우

모든 사용사례(use-case)가 상세히 정의되는 경우

어떤 사용사례도 상세히 정의되지 않은 경우

-요구의 10-20%는 프로젝트를 이해하기 위해 상세히 작성되는 것이 필요

 

7.2 Inception Phase : 시작단계

● Inception phase의 목적은 시스템을 개발할 가능성이 있는지 개발 가치가 있는지 충분히 조사하여 결정 하는 단계

● 공동 비전(목적) 수립

● 상위 수준에서 프로젝트 범위 설정

● 상위 수준의 위험요소 파악

● 비즈니스 사례 생성

● 기본적인 요구조사 (10%)

기본적인 비기능 요구조사

 

● 주의점

-Inception phase는 요구분석 단계가 아니며, 대부분 주요 요구분석 활동은 elaboration phase(정제단계)에서 수행

-객체지향과 관계 없음

-상대적으로 짧은 시간(1주)에 수행

-약간의 프로그래밍 필요

중요한 기술적인 문제를 해결하기 위해,

불명확한 주요 요구를 명확하게 하기 위해 ‘proof of concept’ 프로토타입 개발

 

7.3 반복에서 요구노력

 

 

I -1 week : 상위수준의 유즈케이스 리스트에서 10% 정도를 선택하여 상세하게 분석하고 작성을 한다.

E -4 week : 유즈케이스의 30% 정도를 상세하게 완성

E2-4 week : 유즈케이스의 50% 정도를 상세하게 완성

E3-3 week : 반복하고 70%모든 usecase를 상세하게 완성

E4-3 week : 명확해지고 상세하게 작성한다.

 

8. Elaboration-Basics (ppt참고)

8.1 Elaboration Artifacts

● 도메인 모델 : 도메인의 개념을 가시화 한다. 도메인 개체들의 정적정보 모델과 유사

● 설계 모델 : 로직설계를 설명하는 다이어그램 집합 (클래스, 객체 인터렉션, 패키지 다이어그램)

● 소프트웨어 설계 문서 : 설게에서의 핵심 아키텍쳐문제와 그 해결방안을 요약하는 학습지원

● 데이터모델 : 데이터베이스 스키마, 객체와 비객체 표현간의 매핑전략을 포함한다.

※도메인 모델, Use case 모델, 설계 모델 차이점!!!

도메인 모델 : 어떤 도메인에서 중요한 개념들을 표현하는 모델 (=개념클래스)

 

9. Elaboration Domain Model

9.1 산출물의 예 (ppt 참조 그림참조)

9.2 도메인 모델 생성이유

● 도메인에서 사용되는 중요 개념과 어휘를 이해하기 위해

● 도메인 모델에서 객체(클래스) 이름은 디자인 모델에서 소프트웨어 객체(클래스)이름으로 이용되어

실 세계 모델과 소프트웨어 모델 사이의 차이가 낮아짐

 

9.3 “개념클래스” 발견 3가지 방법

● 존재하는 모델 재사용 : 이미 존재하는 정보 시스템 도메인 모델이나 데이터 모델 재사용

● 카테고리 목록 재사용 : 정보 시스템 도메인에서 공통으로 사용되는 개념 클래스 목록 사용

● 문장분석에 의한 명사 식별 :

도메인에 대한 텍스트 기술(사용사례)에서 명사나 명사구 식별하여 개념 클래스나 속성(attributes)으로 사용

 

10. SSD(시스템 시퀀스 다이어그램 ppt 참고)

11. Elaboration Logic Architecture

11.1 논리적 구조란?

● 전형적인 OO 시스템의 설계는 다양한 시스템 구조(architecture)에 기초

-클라이언트-서버 구조, 분산 구조, 계층 구조

● 논리적 구조(logical architecture)는 서로 밀접하게 관련되는 컴포넌트(클래스)들을 패키지, 서브시스템, 계층(layer) 그룹으로 구성하는 것

-UML 패키지 다이어그램에 의해 표현

 

11.2 계층구조

● 시스템을 계층으로 구성

● 일반적으로 하위계층은 하드웨어를 다루는 컴포넌트들로 구성하며, 하위계층은 상위계층이 이용할 수 있는 서비스 컴포넌트들을 정의

※p198(그림참조) : 논리적아키텍쳐는 보충명세에 의해 파악되는 제약사항과 비 기능적 요구사항에 영향을 받는다.

※p119(그림참조) : UI와 같은 상위 계층이 하위 계층이 제공하는 서비스를 호출하도록 구성.

 

11.3 UML 패키지 다이어그램

UML 패키지 다이어그램은 어떤 요소들을 그룹화 하는데 사용

 

11.4 P203 어플리케이션 계층 그림 해석;

 

11.5 계층구조 장점

● 결합도, 의존성, 복잡성 감소

● 응집력 개선

● 재사용, 명확성 증가

 

11.6 p207 도메인 계층과 도메인 모델은 어떤관계?

● 도메인 모델을 살펴 봄으로써 도메인 계층의 클래스 이름에 대한 영감을 얻을 수 있다.

● 도메인에 대한 인식과 실제 소프트웨어 구현간의 표현상의 차이가 줄어들게 된다.

11.7 SSD와 layer 사이의 연결 (ppt참고)

 

12. Elaboration Interaction Diagrams

12.1 상호작용 다이어그램이란?

● 객체들이 메세질르 통해 어떻게 상호작용하는지 표현하는 다이어그램

● 동적 OO 설계를 위해 이용

 

12.2 Sequence vs. Communication

● 두개의 다이어그램 모두 객체와 객체 사이의 상호작용 표현

● Sequence Diagram

-시퀀스 다이어그램의 주된 관점은 시간 축에 의한 메시지 교류의 순서

-시간에 중점, 메시지 호출 순서 강조

※장점

- 호출 흐름 순서에 의해 이해 용이

- 위에서 아래로

- 역공학 UML 도구로 부터 용이한 생성

※단점

- 객체 추가 시 계속 오른쪽으로 확장

● Communication Diagram

- 통신 다이어그램의 주된 관점은 객체 사이의 상호작용에 대한 관계

- 공간에 중점 , 객체 사이의 연결 강조

- UML 1.x에서 ‘collaboration’ diagram이라 부름

 

12.3 다이어 그램

 

 

12.4 기본표기법

메시지 종류

※동기(Synchronous) 메시지

보내는 객체가 수신 객체의 응답을 기다려야만 하는 메시지

―▶

※비동기(Asynchronous) 메시지

보내는 객체가 수신 객체의 응답을 기다릴 필요 없이 자신의 작업을 계속할 수 있는 메시지 

→


12.5 Frames

●UML은 조건이나 반복 구조를 지원하기 위해 frame 표기법 사용

●Frame은 다이어그램의 영역을 나타내며 연산자(예, loop)와 조건(guard)을 포함

용어

● SDLC (System Development Life Cycle) : the entire process of building, deploying, using, and updating an information system

● tool : automated or semi-automated support for the process and the methods

● UML : the unified notation of the many OO graphical modeling languages

● Use Case : an activity the system performs, usually in response to a request by a user

● class diagram : represent the static structural view of a system

● activity diagram: an effective technique to document the flow of activities for each use case scenario

● model : represent some aspects of the system being built

● analysis : define what users need and want without regard to specific technology

● scenario : a particular sequence of steps within a use case

● method : guidelines that help an analyst complete a system development activity

● design : how the system will satisfy that users want and need


이거 가지고 시험에 참고하면 큰일! 참고만!

이 과목 공부할때

Bruegge, "Object oriented software engineering :using UML, patterns, and Java", Prentice Hall, 2010. 

도움이 많이 된 책
물론 저기의 내용이 저 책안에 있으니까 ㅍ▽ㅍ