3. 객체지향 분석
(1) Rumbaugh의 OMT(Object Modeling Technique)기법
- 소프트웨어 구성요소들을 그래픽 표기법을 이요하여 객체들을 모델링하는 기법
- 객체들의 연관성을 강조하며, 조직적인 모델링 방법론을 이용하여 실세계의 문제들을 다른 방법보다 상세하게 나타낸다.
- 시스템의 분석, 설계, 구현단계 전 과정에 객체지향 개념을 적용했다.
⭐️
[1] 객체 모형화(object modeling)
- 객체들을 식별하고 객체들간의 관계를 정의
[2] 동적 모형화(dynamic modeling)
- 시스템이 시간 흐름에 따라 변화하는 것을 보여주는 상태 다이어그램(state diagram)을 작성
[3] 기능 모형화(function modeling)
- 시스템 내에서 데이터가 변하는 과정을 나타낸다.
(2) Booch의 OOAD(Object Oriented Analysis and Design)
- 여러가지 다른 방법론을 통합하여 하나의 방법론으로 만들었는데 분석보다는 설계쪽에 더 많은 중점을 두고 있다.
- 전체 시스템의 가시화와 실시간 처리에 유용하며, 설계를 위한 문서화 기법을 강조된다.
- 규모가 큰 프로젝트 수행 시 과정이 매우 복잡해지며, 구현언어(Ada)에 제한된다.
(3) Coad/Yourdon 방법
⭐️- E-R 다이어그램을 사용하여 객체의 행위를 모델링하며 객체식별, 구조식별, 주체정의, 속성 및 관계정의, 서비스정의 등의 과정으로 구성된다.
4. UML(Unified Modeling Language) ⭐️
(1) UML의 정의
[1] 시스템의 여러 다양한 특성을 표현할 수 있는 방법이 있으며, 객체지향 분석/설계 표현 방법에 대한 표준으로 받아들여지고 있다.
[2] 객체 지향 분석/설계용의 모델링 언어이며, 종래의 객체 지향 방법론과 함께 제안되어 모델링 언어 표기법의 표준화를 목적으로 한 것이다.
(2) UML의 특성
[1] 시스템의 정적인 측면 : Class Diagram 정적인 구조
[2] 시스템의 동적인 측면 : Sequence Diagram, State Diagram
[3] 시스템의 기능적 측면 : Use Case Diagram
(3) UML의 종류
[1] Use Case(사용 사례) Diagram
- 시스템이 어떤 기능을 수행하고, 주위에 어떤 것이 관련되어 있는지를 나타낸 모형
- 외부에서 보는 시스템의 동작으로, 외부 객체들이 어떻게 시스템과 상호작용하는지 모델링한 것이다. (시스템이 외부 자극에 어떻게 반응하는가)
⭐️ [2]Class Diagram 정적 구조
- Class 다이어그램은 객체, 클래스, 속성, 오퍼레이션 및 연관관계를 이용하여 시스템을 나타낸다.
- Class 다이어그램을 통하여 사용자는 보다 쉽게 원하는 시스템의 구조를 정의할 수 있다. 또한 입출력 화면도 하나의 객체로 나타나기 때문에 시스템의 구조화가 용이하고 분석단계에서 사용자인터페이스 프로토타이핑 작성이 쉬워진다.
[3] Sequence Diagram 동적 구조
- 순서 다이어그램은 객체간의 메시지 통신을 분석하기 위한 것이다. 이는 시스템의 동적인 모델을 아주 보기 쉽게 표현하고 있기 때문에 의사 소통에 매우 유용하다.
- 시스템의 동작을 정형화하고 객체들의 메시지 교환을 시각화하여 나타낸다.
[4] Collaboration Diagram 동적 구조
- Sequence 다이어그램이 객체간의 메시지 처리에 대한 순서에 중점을 둔 반면, Collaboration 다이어그램은 관련 객체와의 연관성 분석에 중점을 두고 있다.
- UML의 다이어그램들 중에서 상호작용을 하는 객체들 사이의 조직을 강조하고, 시스템의 행동관점으로 행동과 실제와 구현을 만들어내며, 클래스간의 상호작용 관계들을 통해서 메시지를 교환하는 작용을 나타내는 다이어그램이다.
[5] State Diagram 동적 구조
- State 다이어그램은 객체 내의 동적 행위를 모형화하기 위한 것으로, 복잡한 객체 혹은 객체내부의 프로세스를 표현하고자 할 때 사용된다.
- State 다이어그램에서 상태는 둥근 사각형으로 상태의 흐름은 화살표로 표시된다.
[6] Activity Diagram 동적 구조
- Activity 다이어그램은 State 다이어그램과는 달리 시스템의 흐름 전체를 파악하기 용이하도록 행위를 중심으로 흐름을 표현한 것이다.
- Activity 다이어그램은 현재 업무의 흐름 파악이 용이하다. 따라서 업무 흐름 지향적인 문제영역에서 작성하는 것이 좋다.
[7] Component Diagram 정적 구조
- 시스템을 구성하는 실제 소프트웨어 컴포넌트 간의 구성체계를 기술하므로 아키텍처 표현에 우수하다.
- 컴포넌트 다이어그램은 각 컴포넌트를 그리고 컴포넌트 간의 의존성 관계를 화살표로 나타낸다.
정적 구조 : Class Diagram, Component Diagram
동적 구조 : Sequence Diagram, Collaboration Diagram, State Diagram, Activity Diagram
5. 애자일(Agile)
(1) 애자일의 정의
[1] 애자일 소프트위어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다.
[2] 애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일개발을 가능하게해 주는 다양한 방법론 전체를 일컫는 말이다.
[3] eBusiness 시장 및 SW개발환경 등 주위변화를 수용하고 이에 능동적으로 대응하는 여러 방법론의 통칭한다.
(2) 애자일의 특성
[1] Predictive라기보다 Adaptive(가변적 요구사항에 대응)
[2] 프로세스중심이 아닌 사람 중심(책임감이 있는 개발자와 전향적인 고객)
[3] 전반적인 문서화보다는 제대로 동작하는 소프트웨어
[4] 계약 협상보다는 고객 협력
[5] 계획을 따르기보다는 변화에 응대함
[6] 모든 경우에 적용되는 것이 아니고 중소형, 아키텍처 설계, 프로토타이핑에 적합하다.
(3) 애자일의 종류
⭐️ [1] 익스트림 프로그래밍(Extreme Programing, XP)
- 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역활을 하였다.
- 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하느 명시적인 기술과 방법을 가지고 있다.
[2] 스크럼
- 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다.
- 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.
[3] 크리스털 패밀리
- 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다.
- 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지도않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
[4] Feature-Driven Development
- feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이요한 설계 기법과도 밀접한 관련을 가진다.
[5] Adaptive Software Development, ASD
- 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적용할 수 있는 소프트웨어방법을 제시하기 위해 만들어진 방법론이다.
- 내용적으로는 다른 방법론들과 유사하지만, 합동 어플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다르다.
⭐️ (4) 익스트림 프로그래밍(eXtreme Programming, XP)
1) 개요
[1] 익스트림 프로그래밍(eXtreme Programming, XP)는 켄트 백 등이 제안한 소프트웨어 개발방법이다.
[2] Agile Process의 대표적 개발법이며, 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다.
[3] 개발자, 관리자, 고객이 조화를 극대화하여 개발생산성을 높이고자 하는 접근법이다.
⭐️ 2) XP(eXtreme Programming)의 5가지 핵심 가치
[1] 존중(Respect) : 팀 기반의 활동 중 팀원 간의 상호 존중을 강조
[2] 단순성(Simplicity) : 사용되지 않는 구조와 알고리즘 배제
[3] 의사소통(Communication) : 개발자, 관리자, 고객간의 원활한 의사소통
[4] 피드백(Feedback) : 지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백
[5] 용기(Courage) : 고객의 요구사항 변화에 능동적인 대처
⭐️ 3) XP(eXtreme Programming)의 실천사항
[1] 점증적인 계획 수립 : 계획세우기, 우선순위와 기술사항 고려 범위 결정
[2] 소규모 시스템 릴리즈 : 짧은 사이클로 버전 발표
[3] 시험우선개발 : 테스팅, 단위 테스트를 계속 작성
[4] 리팩토링
[5] 페어pair 프로그래밍 : 가장 좋은 구현 방법 고민, 전략적인 방법 고민
[6] 공동 소유권 : 개발자들 누구나 코드 수정
[7] 지속적 통합
[8] 유지할 수 있는 속도 : 1주에 40시간 작업
[9] 현장의 고객 : 고객도 한 자리에
[10] 표준에 맞춘 코딩
