-
변화하는 요구사항을 다뤄야 한다.
-
구조적(Structured) 접근과 객체지향(Object Oriented)접근의 차이는
=> 책임의 이동이다.구조적인 접근은 한명이 명령을 내리는 거라면
객체지향은 각각의 객체가 자신의 역할을 알고 움직이는 것이다. -
성공적인 소프트웨어는 반드시 이해관계자의 요구사항을 만족해야 한다.
소프트웨어 상품은 정시(On Time)에 정해진 예산(On Budget)에 맞추어야 한다.
소프트웨어 상품은 변화하는 요구사항에 탄력적(resilient)으로 대응할 수 있어야 한다. -
소프트웨어 공학은 1960년대 소프트웨어 위기에서 비롯됐다.
(소프트웨어 위기 : 높은 퀄리티를 유지하지 못함 왜냐하면 소프트웨어의 크기랑 복잡성이 커져서) -
소프트웨어 공학은 소프트웨어 생산의 모든 측면에 관련된 공학 분야이다.
-
개발프로세스는 누가 무엇을 언제 어떻게 특정한 목표를 이룰 수 있는지 정의한다.
소프트웨어 공학에서 목표는 소프트웨어를 개발하는 것 혹은 기존의 것을 향상 시키는 것이다. -
프로세스에서 기본적인 흐름은 다음과 같다.
Analysis -> Design -> Implementation -> Testing
Analysis : 기능적 비기능적 요구사항은 뭔지, 도메인 분석, 요구사항 수집 분석 기타 등등
Design : 요구 사항을 충족하기 위한 논리적 해결책을 고안하는 방법, 시스템 아키텍처 내부적인 디자인, UI 데이터베이스 디자인
Implementation : 논리적 해결책을 코딩
Testing : 유닛 테스트, 통합 테스트, 재귀 테스트, 인수 테스트
- 전통적인 폭포수 모델 -> 중간에 요구사항 수정이 어려움
전통적인 개발방식의 문제점 :
계획된 기간 초과, 비용 상승, 취소 비율 높음, 퀄리티 낮음, 유지비용 높음
- 잘못된 가정
9-1. 요구사항은 상당히 정확할 것이다. X
9-2. 요구사항은 자주 안바뀐다. X
시장은 변하고 기술도 변하고 이해관계자들의 목적도 변한다.
9-3. 프로그래밍하기 전에 설계를 마칠 수 있다. X
- Iterative 개발은 변화를 수용한다.
작은 단계, 피드백, 정교함(Refinement), 적응성
반복적(Iterative)이고 점진적(Incremental)이며 시간단위로 나눠짐
혁신적인 나선현 모델
-
반복적 점진적 개발의 장점
빠르게 위험성을 회피할 수 있다
빠르게 과정 시각화 가능
빠르게 피드백, 유저 참여, 적응 가능
analysis paralysis(완벽주의자) 제압 가능
반복을 통해 과정 스스로 개선 가능 -
대표적 반복 프로세스는 Unified Process이다.
각 과정마다 목표가 존재하고
상대적인 중요성을 두께로 표시할 수 있음
각 과정은 작은 폭포수 프로세스이다.
-
전략적 합리적 시스템 개발 계획은 시스템의 전체 비용에 기초한다. 단순히 개발 비용만 따지지 않음
유지보수 비용이 엄청나기 때문이다. -
운영 기술(Operation Technology)의 진정한 힘과 장점은 복잡한 시스템에 대처하고 쉽게 적응할 수 있는 시스템을 지원하는 능력으로 변경 비용과 시간을 낮춘다는 것입니다.
-
재사용은 일반적으로 객체 레벨에서 달성되거나 가치가 있지 않다.
"연구에 따르면 재사용 증가와 이전 프로젝트에서 재사용 가능한 구성 요소의 라이브러리 수집 사이에는 아무런 관계가 없습니다."
초점:
프레임워크 생성 및 사용 문화.
아키텍처, 분석 및 설계 패턴 재사용
-
디자인 패턴은 특정 맥락에서 문제와 해결에 대한 설명입니다.
-
프레임워크는 클래스 라이브러리이지만 일반적인 툴킷(예: 수학, 파일 I/O, 데이터 구조 등)보다 많습니다.
통합 협력 클래스 세트
A semi-complete application: 추상 프레임워크 클래스는 응용 프로그램에 특화되어 있습니다.
Inversion of control : 프레임워크의 코드는 동적 바인딩을 통해 응용프로그램의 코드를 호출할 수 있습니다.
Domain-specific : business, telecommunications, windows system, databases, etc.
- 프레임워크를 통해 설계 및 코드를 재사용할 수 있습니다.
프레임워크: 유사한 응용프로그램 제품군
매우 빠른 애플리케이션 개발
강력한 매개 변수화 메커니즘(하위 분류 및 동적 바인딩)
- Framework Examples
Framework concept origin - use interface frameworks
- Model-View-Controller (MVC) : for smalltalk GUI (1980)
- MacAPP : for Mac applications (1986)
the first commercially successful framework
Other examples - Microsoft Foundation Classes
- Choices Operating system
framework - Unidraw Graphical editors
- Android
- 객체 지향 프로그래밍의 장점 : 현실세계 사물 간의 관계를 맵핑하기 쉽다.
유연하고 재사용 가능한 시스템을 얻기 위해
소프트웨어의 구조를 행동보다는 객체에 기초하는 것이 더 낫다.
- 객체 지향 패러다임 이면의 이론적 근거:
일반적으로 시스템이 발전하고 기능이 변경되지만 데이터 개체, 인터페이스 및 구성 요소 관계는
시간이 지남에 따라 상대적으로 안정적인 상태를 유지하는 경향이 있습니다.
=> 대규모 시스템 및 자주 변경되는 시스템에 사용
- 복잡한 소프트웨어 시스템을 점점 더 작은 부분으로 분해하는 것이 필수적이며,
각각의 부분은 독립적으로 다듬을 수 있다.
개인이 동시에 이해할 수 있는 최대 정보 덩어리의 수는 7+- 2 이다 -밀러
복잡성에 대한 기술은 고대부터 알려져 왔다 : devide and conquer -다익스트라
- Structured Paradigm vs. OO Paradigm
구조적 패러다임은 시스템을 절차와 기능으로 구성한다.
객체지향 패러다임은 시스템을 객체로 구성한다.
- Structured vs. Object-Oriented Decompositions
구조 분해
– 절차/기능에 대한 시스템 구성
– 프로그램 =(알고리즘 + 데이터 구조)
– SA/SD/SP
객체 지향 분해
– 개체 주위에 시스템 구성
– 개체 =(알고리즘 + 데이터 구조)
– 프로그램 =(개체 + 개체 + ... )
– OOA/OOD/OOP
