소프트웨어 공학: 객체 지향 설계 과정

study/se 2009/06/10 18:30 자루
1. 관점 통합

정보 모델링 + 동적 모델링 + 기능 모델링 - 통합 -> 객체 정의

객체 정적인 구조 (정보 모델링)
- 클래스: class
- 속성: attr

객체 오퍼레이션 맵핑 (동적 모델링)
- 사건:event
- 동작:action
- 활동:activity

오퍼레이션과 프로세스 통합 (기능 모델링)

2. 알고리즘 설계
: 오퍼레이션 구현

3. 객체 접근 경로 최적화
- 연관성 고려: 객체 접근 경로 줄임
- 계산 순서 고려: 알고리즘 능률성 높임
- 유도된 속성 저장: 속성 재계산 피함

4. 제어방법 설계
: 동적 모델을 제어 구조로 구현
- 객체상태 기억
- 상태기계 구현
- 동기적 태스크 사용

5. 상속 관계 정제
- 클래스간 공통 오퍼레이션을 추출 후 재정돈해 일반화 시킴
- 필요시 상속으로 오퍼레이션 중복 제거(?)

6. 집단화와 연관성 설계
- 포인터와 컬렉션을 사용해 구현

7. 객체 표현
- 객체의 속성과 관계를 자료형이나 자료구조로 표현

8. 다형성 사용
- 오퍼레이터 중복
- 함수 중복
- 템플릿

(-_-);; 아아 ...

이게 뭔소리인지..
시험 공부하느라 막 올렸는데..
애매한 부분은 잘 안보이게 처리했습니다.
2009/06/10 18:30 2009/06/10 18:30
TAG ,
받은 트랙백이 없고, 댓글 2개가 달렸습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/192

댓글+트랙백 ATOM :: http://myevan.net/atom/response/192

소프트웨어 공학: 설계 관점 분류

study/se 2009/06/10 18:07 자루
관리적 관점
- 기본 설계: 시스템 구조, 데이터 구조, 인터페이스 정의
- 상세 설계: 각 모듈에서 사용되는 내무 알고리즘 설계

기술적 관점
1. 데이터 설계: 정보 모델링 사용 -> 자료 구조, 데이터 베이스 설계
2. 사용자 인터페이스 설계: 인터페이스 정의 (구조 설계보다 먼저 설계해야함)
3. 구조 설계: 동적 모델링과 기능 모델링 사용 -> 모듈간의 관계 기술
4. 프로시져 설계: 각 모듈에서 사용하는 내부 알고리즘 설계
2009/06/10 18:07 2009/06/10 18:07
TAG , , , , , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/191

댓글+트랙백 ATOM :: http://myevan.net/atom/response/191

소프트웨어 공학: 설계 - 품질에 영향을 미치는 요소

study/se 2009/06/10 17:57 자루
설계를 하는 이유는 품질을 향상하기 위해서이다.
품질을 향상하기 위해서는 새로운 기능을 추가하기 쉽고, 유지 보수가 편리해야한다.

시스템을 각 구성하는 요소를 모듈이라고 부르며,
모듈을 추가하거나 수정할 경우 파급효과를 최소화하는
모듈 독립성이 기본으로 갖추어져야 한다.
비슷한 기능은 최대한 모아서 하나의 모듈의 응집도를 높이고,
다른 모듈과의 결합도를 줄이는 것이 핵심이다.

모듈과 모듈간의 결합은 이해도 높게 작성되어야 한다.
이해도를 높이기 위해서는 먼저 시스템을 여러개의 독립된 서브 시스템으로 나누어
규모를 줄여야 한다. 서브 시스템으로 나눈 이상 서브 시스템간 통신은 필수적이다.
최소한의 통신을 위해 결합도를 낮추고, 불필요한 정보는 감춘다.
코드 컨벤션과 문서은 시스템 이해가 큰 도움이 된다.

시스템의 환경은 계속적으로 변해 가기 때문에 적응도가 높아야 한다.
적응도는 환경 결합도가 낮고, 내부 응집도가 높다는 이야기이다.

외부 환경과 결합할 수 밖에 없는 부분은 최대한 작게 지역화해서
최소한의 수정으로 변화에 적응할 수 있어야 한다.



2009/06/10 17:57 2009/06/10 17:57
TAG , , , , , , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/190

댓글+트랙백 ATOM :: http://myevan.net/atom/response/190

소프트웨어 공학: 모델링

study/se 2009/06/10 17:27 자루
모델링은
복잡한 시스템을 쉽게 이해하기 위해
불필요한 부분을 생략하고 추상화해서
간단한 모델로 표현하는 것이다.

모델링은
이해하기 쉽게 시각적으로 표현(representation)되어야 하며,
표현에 사용된 기호들 사이의 약속인 규약(convention)이 있어야 한다.

시각적인 표현만으로 이해가 어려울 수 있으므로
간단히 글자로 설명해 놓은 상술(specification)이 필요하다.

대표적인 모델링 종류
- 정보 모델링: 객체 관계도 (ERD: Entity Relation Diagram)
- 동적 모델링: Use Case -> 시나리오 -> 사건추적도 -> 상태 변화도 (STD: State Transition Diagram)
- 기능 모델링: 자료 흐름도 (DFD: Data Flow Diagram)

2009/06/10 17:27 2009/06/10 17:27
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/189

댓글+트랙백 ATOM :: http://myevan.net/atom/response/189

소프트웨어 공학: 시스템 분석가의 임무와 필요한 자질

study/se 2009/06/10 17:22 자루
시스템 분석가는
고객이나 물주의 요구 사항을 정확하게 파악해서
목표를 정립한 다음 엔지니어들에게 제대로 일을 시킬 수 있어야 한다.

필요한 자질:

상대의 관점에서 문제를 바라보기
- 고객이 원하는걸 잘 알기 위해서는 고객의 관점에서 바라봐야한다.

응용 분야의 지식
- 고객이나 물주가 원하는 건 대개 응용 분야이다. 응용 분야의 상황과 용어등에 대한 지식은 기본적으로 필요하다.

쉬운 용어 사용
- 컴퓨터 전문 용어를 이야기하면서 고객이 이해하기를 바라면 안된다.

컴퓨터 기술 이해
- 고객이나 물주가 원하는 것이 기술적으로 가능한지 아닌지는 알고 있어야 한다.

의사 소통 능력
- 고객이 하는 이야기를 제대로 파악하고 개발 관련 사항을 잘 이해시켜야 한다. 내가 제대로 이해 못 했을 수도 있고, 내가 말한 내용이 전혀 다르게 이해 되거나 기억되지 못할 수 도 있다는 걸 기억해야한다.

모순되는 요구 사항 해결
- 고객의 생각은 정돈된게 아니다.

주도적인 진행
- 고객은 물주다. 고객이 뭔가를 해주기를 바라면 안된다. 고객에게 서비스를 제공한다는 생각으로 접근해야한다.






2009/06/10 17:22 2009/06/10 17:22
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/188

댓글+트랙백 ATOM :: http://myevan.net/atom/response/188

소프트웨어 공학: 요구사항 분석과 개발(설계)의 차이점

study/se 2009/06/10 17:00 자루
요구 사항 분석과 개발(설계)의 가장 큰 차이점은 관점이다.

사용자 관점에서 바라보는 것이 요구 사항 분석이며
개발자 관점에서 바라보는 것이 개발 (설계) 이다.

요구 사항 분석는 프로그래머가 진행하는 경우가 많은데,
프로그래머의 관점, 다시 말해 "어떻게 만들까" 를 먼저 생각하기 때문에
문제가 생기는 경우가 많다.

요구 사항 분석을 잘 해내는 가장 쉬운 방법은
엄마에게 내가 만드는 프로그램에 대해 설명해보는 것이다,

"엄마, 내가 프로그램 만드는데..."

"뭐 만드는데?"

그렇다. 사용자가 알고 싶은건 "무엇을 만드냐"라는 것이다.

엄마가 3D 프로그래머 출신이 아닌 이상
Direct3D 로 만들지 OpenGL 을 만들지는 중요하지 않다.

"MMORPG"

"MMORPG 가 뭐냐-_-)?"

"캐릭터가 움직이면서 몬스터 잡으면서 레벨올리는거예요"

"캐릭터-_-)? 몬스터-_-)? 레벨-_-)? 그게 뭐여?"

... 아 orz;

엄마처럼 아무것도 모르는 경우는 용어 정립부터 필요하다는 사실을 깨닫게 되는군...

좀 더 픽션을 가미해서 엄마가 워우 광렙 유저라고 가정해보면 좀 더 편할 듯 하다.

"음.. 그래-_- 엄마가 MMORPG 는 알겠는데.. 게임의 목적이 뭐니?"

이런 식으로 풀어나가는 과정이 요구 사항 분석이다.

2009/06/10 17:00 2009/06/10 17:00
TAG , , ,
받은 트랙백이 없고, 댓글 4개가 달렸습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/187

댓글+트랙백 ATOM :: http://myevan.net/atom/response/187

소프트웨어 공학: 소프트웨어 위기의 원인과 해결 방법

study/se 2009/06/10 16:36 자루
소프트웨어 위기의 원인
- 생산: 서비스 요구 사항 증가 속도를 소프트웨어 생산성이 따라가지 못함.
- 유지: 소프트웨어 품질 향상과 유지 보수가 어렵다.
- 비용: 개발 일정과 소요 비용 예측이 어렵다.

소프트웨어 위기의 해결책
- 체계적이고 조직적인 개발 필요
- 소프트웨어에 대한 오해 풀기

옛날에는 혼자서도 게임 개발이 가능했다.
작은 크기의 이미지를 만들어서 출력하면 되므로
그래픽 작업도 빠르고, 기술적인 문제도 존재하지 않았다.
한가지의 단순한 재미만으로도 게임이 완성될 수 있었다.

현재는 엄청난 크기의 텍스쳐에 모델링 그리고 애니메이션 작업이 필요하다.
그래픽 영역만 3개로 늘어났다. 많은 연산 능력 요구와 다양한 성능의 하드웨어는
기술적인 문제만 해결하는데도 별도 인력이 필요하다.

외부 엔진 도입을 위해서는 객체 지향 방법론을 도입해야 하나,
구조적인 방법론으로 체계없이 개발해온 프로그래머들에게는 엄청난 장벽이 되었다.

다양한 객체들의 존재는 복잡한 연관관계를 가져와
프로그램은 더욱 복잡해졌고, 늘어난 개발자 숫자는 커뮤니케이션 문제를 만들었다.

개발 인원 증가와 복잡해진 소스와 리소스는 엄청난 비용 증가를 가져왔다.




2009/06/10 16:36 2009/06/10 16:36
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/186

댓글+트랙백 ATOM :: http://myevan.net/atom/response/186

소프트웨어 공학: 구조적 방법론과 객체 지향 방법론의 차이

study/se 2009/06/10 16:03 자루
구조적 방법론
시스템의 대표적인 기능을 찾아내고,
대표 기능을 수행하기 위한 서브 기능을 찾아가는 식으로 분석한다.

전체에서 세부를 알아내가는 하향식 방법이다.
사람의 구조적인 분석

대표기능: 밥먹기
서브기능: 이빨로 자른다 -> 목구멍으로 넘긴다 -> 식도를 타고 내려간다 ->
위에서 녹인다 -> 장에서 흡수한다 -> 항문에서 배출한다.

서브기능: 장에서 흡수한다.
세부기능: 모세혈관이 흡수한다 -> 심장으로 보낸다 -> 동맥을 통해 근육과 내장기관에 보낸다.

특정 기능을 수행하는 엔트리 포인트를 찾아 한단계씩 진행하며 소스를 따라 가능 디버깅 방식을
참고 하면 될듯...


객체 지향 방법론
시스템의 구성 요소들을 찾아내고
구성 요소들간의 연관성을 증명해내는 과정이다.

세부에서 전체를 만들어가는 상향식 방법이다.
사람의 객체 지향적인 분석

1. 객체 모델링
- 뇌, 척수, ..
- 눈, 코, 귀, ...
- 이빨, 목구멍, 식도, 위, 장, 항문, ...
- 심장, 동맥, 정맥, 모세혈관, ...
- 근육, 내장 기관

[이빨] - 전달 - [목구멍] - 전달 - [위] - 전달 - [장] - 전달 - [항문]
[장] - 흡수 - [모세혈관] - 전달 - [심장] -> 동맥 - [전달] - [모세혈관] - 전달 - [근육, 내장기관]

2. 동적 모델링

음식물
초기 상태 -> 잘린 상태 -> 녹은 상태 -> 흡수 상태 -> 배출 상태

3. 기능 모델링

[초기 상태] - 이빨로 자른다 -> [잘린 상태] - 위로 전달해 위액으로 녹인다 -> [녹은 상태]
- 소장으로 전달한다 -> [흡수 상태] - 대장으로 전달한다 -> [배출 상태]

... 사람의 소화 시스템 완성;



구조적 방법론과 객체 지향 방법론의 장단점

구조적 방법론에서는
상하 관계가 명확하고 결합도가 강하므로
어떻게 처리가 진행되는지 따라가기 쉽기 때문에
사소한 기능 수정에는 매우 편리하다.

하지만 새로운 기능을 추가하거나 재활용하려면
각 기능들을 다시 뜯어내야 하므로 상당한 노력이 필요하다.


객체 지향 방법론에서는 각 객체는 독립적(응집성이 높고, 결합도가 낮다)이므로
개별적인 객체의 작동은 파악하기 쉽다. 하지만 전체의 작동 원리를 알기 위해서는
객체간 연관 관계에 대한 이해가 필요하기 때문에, 객체간 관계 정립 없이
작업을 진행하는 것은 매우 어렵다.

하지만 객 객체 요소들이 독립적이므로 새로운 기능을 추가하거나 재활용할때는
기존 구조에 큰 영향을 주지 않고 수정할 수 있다.
2009/06/10 16:03 2009/06/10 16:03
TAG , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/185

댓글+트랙백 ATOM :: http://myevan.net/atom/response/185

소프트웨어 공학: 시스템의 정의

study/se 2009/06/10 15:39 자루
시스템이란
특정 목적과 기능 수행을 위해
서로 의존하며 함께 작용하는
유기적인 요소들의 집합이다.

ps.
각 요소들이 완전히 독립적인 것들의 모음은 그냥 라이브러리일뿐... ~(-_-)~
2009/06/10 15:39 2009/06/10 15:39
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/184

댓글+트랙백 ATOM :: http://myevan.net/atom/response/184

소프트웨어 공학: 시스템 요구사항 분석 중 발생가능한 문제 해결

study/se 2009/06/10 15:31 자루
고객이 목표를 설정했으나 어떻게 만족시켜야 할지 모르는 경우

나선형 패러다임:
계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가 -> 다음 결과물 계획 시작

요구사항 분석후 해결 방법이 애매할 경우이다.
해결 방법을 찾아내기 위한 다양한 시도는 잘못될 가능성이 있으므로,
정확한 정보를 모아 불확실성과 위험 요소를 줄여나가는 위험 분석 단계가 필요하다.

위험 분석중 현재 방법에 문제가 있을 경우 포기하고 다른 방법을 찾는다.

개발은 위험 요소에 대한 평가가 이루어진 다음 진행되며.
개발 결과물을 고객에게 평가 받은 이후 다음 결과물을 만들기 위한 계획을 시작한다.



엔지니어들이 고객의 요구사항을 불완전하게 이해한 경우

프로토타입 패러다임:
요구 사항 분석 -> 시제품 설계 -> 시제품 개발 -> 고객 시제품 평가 -> 시제품 정제 ->
-> 다시 요구 사항 분석부터 반복 ... 모든 요구 사항 만족시 -> 완제품 생산 시작

엔지니어가 이해한 내용이 고객의 요구사항과 맞는지 확인하기 위해
빠른 시간내에 시제품을 설계해 개발한다.

고객은 시제품을 사용해 보면서 요구 사항이 명확하게 만든다.
시제품이 모든 요구사항이 만족한다면 완제품 개발을 시작한다.

2009/06/10 15:31 2009/06/10 15:31
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://myevan.net/rss/response/183

댓글+트랙백 ATOM :: http://myevan.net/atom/response/183

◀ 이전페이지 1 2 3 4 5 ... 16 다음페이지 ▶