[Project] Software Architecture

1. 프로젝트(Project) - 사업

(1) 정의 : 제품, 서비스를 일정기간동안 만들어내는 과정

(2) 실패 원인

불완전한 요구 사항

사용자의 참여부족

인력 및 기술 자원 부족

비현실적인 기대감

경영층의 지원 부족

요구사항 및 사양의 변경

프로젝트 계획 부족

(3) R & R(Role and Responsibility) - 프로젝트 인원 구성

1) PM(Project Manager)

- 프로젝트 성공에 대한 책임

- 프로젝트 팀 구성에 대한 권리와 책임

- 프로젝트 업무 정의

- 리스크 관리 및 외주 관리

- 다른 팀 또는 프로젝트 팀간의 의사 소통

2) PL(Project Leader)

- 각 본인의 파트에 대한 설계와 무결점에 대한 책임

- 구현 단계 이끌기

- 각 본인의 파트에 대한 의사소통

- 각 본인 파트 검토 및 보고서 작성

- 다른 파트간 협업

3) PE(Project Engineer)

- 프로젝트의 실무자

- 상세 설계에 대한 책임

- 구현 일정 산정에 대한 책임

- 프로젝트가 주어진 요건에 맞게 동작 및 완료가 되게 만들어야 하는 책임

- 회사의 표준을 따를 책임

- 프로젝트에 결함이 없도록 해야할 책임

4) QA(Quality Assurance) 빌드/릴리즈 담당자, 기술문서 작성자 등

(4) 프로젝트 성공 요인 -> Architecture

1) 기술을 아는 프로젝트 관리 전문가가 필요

2) 개발이슈 사전관리

3) 요구사항 추적관리

조견표 : RFP(Request For Proposal), 제안서, 계획서

(5) 아키텍처

시스템의 복잡성을 단순화 시켜서 모델로 만드는 것

모델로 만든것으로 이해관계자들과 의사소통

2. 소프트웨어 아키텍처

(1) 정의

프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와 그들이

지니고 있는 특성 중에 외부에 드러나는 특성 그리고 그 구성요소들의 관계를 표현하는

시스템의 구조이다.

(2) 누가 시작하는가?

소프트웨어 엔지니어(프로그래머)

(3) 필요한 기본소양

    1) 다양한 프로그래밍 언어의 사용

    2) 다양한 테이터베이스 관리 시스템의 사용

    3) 다양한 인터넷 기술의 활용 (Front End)

    4) 프레임워크의 사용

    5) 모바일 앱 프로그래밍

(4) 종류

    1) 전사(전체사업) 아키텍처 : EA. ERP 전사적 자원관리

    2) 업무 아키텍처 : BA

    3) 소프트웨어 아키텍터 : SA

    4) 인프라 아키텍처 : IA

    5) 솔루션 아키텍처

3. 아키텍처 비지니스 사이클

*. 스웨덴의 전함 바사

4. UML : 아키텍처의 문서화

(1) Unified Modeling Language

'97 1.1

'05 2.2

(2) 어디에서 사용할까?

1) 정보 시스템을 만드는 곳

2) 내장 시스템 : 자동차

(3) 모델링 도구

1) 파워포인트, 비지오

2) IBM-Rational Rose, BOLAND

3) Amateras, StarUML

(4) Usecase Diagram

1) 시스템 개발 초기에 작성

2) 요구 사항을 정의하기 위해 작성

3) 구성요소

액터, 관계, 유스케이스

(5) Class Diagram

1) 실제 코드로 변환할 수 있는 diagram

2) 나타내지 않는 것

- 클래스가 서로 어떻게 상호 작용하는지

- 자세한 알고리즘

- 특정한 동작이 어떻게 구현되는지

3) 그리는 방법

- 박스를 3등분하여 그린다.

클래스명

인스턴스 변수

메서드

- 인스턴스 변수

변수명 선언

변수명 : 타입

변수명 : 타입 = 초기값

변수명 : 타입 [갯수[

접근 지정자

+ : public

-  : private

# : protected

static

밑줄

- 메서드

메서드명 선언

메서드명(파라미터) : 리턴 타입

생성자나 void인 경우 리턴 타입 생략

접근 지정자

상동

static

상동

아주 흔한 메서드는 생략 가능(getter/setter)

상속받은 메서드도 생략 가능

4) 관계

- 일반화 관계(Generalization)

상속 관계( 클래스, 인터페이스 )

is a 관계

인터페이스  --------▷

추상클래스   ―――▷

- 연관 관계(Association)

has a 관계

의존(dependency)  ―――>, ――― 

집합(aggregation) : 있어도 그만 없어도 그만인 관계   ―――◇

합성(composition) : 꼭 필요한 관계                         ―――◆

*. 결합도(낮은), 응집도(높은)

5) Multiplicity

인스턴스의 수

*

1

2...4

3..*

ex) 한 회사에서는 여러 팀이 있다.

각 팀에 대해서는 팀을 관리하는 하나의 팀이 있으며

한 팀은 여러 팀을 관리할 수 있다.

회사는 여러 사무실을 가지고 있다.

팀은 하나 이상의 사무실에 위치할 수 있고

반대로 한 사무실에서 여러 팀이 작업할 수 있다.

(6) sequence Diagram

1) 정의

해결해야 할 문제가 주어진 상황(Usecase)에서

그 문제를 해결하기 위해 필요한 객체를 정의하고,

객체간의 동적인 상호관계를 시간 순서에 따라

정의함으로써 주어진 문제를 해결하는 모델

2) 목적

- 객체간의 동적 상호작용을 시간적 개념을 중시하여 모델링

- 객체의 오퍼레이션과 속성을 상세히 정의

- 유스케이스를 실현

- 프로그램 사양을 정의

3) 구성 요소

- Things : Actor, 객체(Object) 

- Relationships : Message

- etc : Life line, Focus Of Control

- Actor

시스템의 외부에 존재하면서 시스템과 교류 혹은 상호작용

- Object

클래스의 인스턴스

사각형으로 표시

인스턴스 : 클래스 -> ex) 홍길동:사원

인스턴스 -> ex) 홍길동

클래스 -> ex) :사원

- Message

객체와 객체가 통신하는 유일한 수단

동기적 메시지

비동기적 메시지

리턴 메시지

- LifeLine

객체의 생존 기간

- Focus Of Control

Acti