클래스 다이어그램
클래스 다이어그램의 기초
- 클래스 다이어그램의 구성 요소
- 클래스 : 자료 타입 그 자체를 나타냄
- 연관관계 : 클래스 인스턴스 사이의 관계를 나타냄
- 속성 : 클래스와 그 인스턴스 안에서 발견될 단순자료
- 오퍼레이션 : 클래스와 그 인스턴스에 의하여 수행될 함수를 나타냄
- 일반화 : 클래스를 상속 구조로 그루핑
클래스와 가시성
- 클래스는 박스로 표현하며 그 안에 이름을 적는다.
- 다이어그램은 속성과 오퍼레이션을 나타낼 수 있다
- 오퍼레이션의 원형은 다음과 같이 표시한다
- operationName(parameterName parameteType,..): return Type
속성
- 객체의 상태 또는 성질을 나타냄
- 객체에 대한 정보를 나타냄
- 속성은 변수와 동의어는 아님. 추상적으로 정의한 성질
- 객체 외부에서 값을 가져갈 수도 있고 변경할 수도 있음
- 읽기 전용도 있음
오퍼레이션
- 박스 맨 아래 오퍼레이션의 원형으로 표현
- 대부분 속성에 대한 get(), set()
- 읽기 전용은 get() 오퍼레이션만
- 일부 오퍼레이션은 매개변수 필요
- 일부 오퍼레이션은 다른 객체에 메시지 호출할 필요가 있음
가시성
- 속성과 오퍼레이션 앞에 visibility 표시
- Public : '+'
- Protected : '#'
- Private : '-'
추상 클래스
- 추상 오퍼레이션
- 구현이 없는 오퍼레이션
- 추상 클래스
- 인스턴스가 없는 클래스
연관 관계와 다중도
- 두 클래스가 서로 어떻게 관련이 있는지를 나타냄
- 연관관계의 양 끝에는 다중도를 표시
- 연관관계 특성을 드러내기 위해 이름을 붙임
One-to-one
- 한 회사에 오직 한개의 책임자 위원회가 있음
- 책임자 위원회는 한 회사를 위한 위원회임
- 회사는 항상 위원회를 가지고 있어야 함
- 위원회는 어떤 회사의 소속임
Many-to-Many
- 비서 일인이 여러 명의 관리자를 위하여 일함
- 관리자 한 사람이 여러 명의 비서를 둘 수 있음
- 비서는 풀에서 일함
- 관리자들은 비서의 그룹을 가질 수 있음
- 어떤 관리자는 비서가 없을 수도 있음
- 관리자가 없는 비서는 일시적으로 가능한가?
연관관계 검토
- 불필요한 1대 1관계는 피함
복잡한 예
연관 클래스
- 두 개의 연관 클래스에 관한 속성을 어느 한쪽에 위치시킬 수 없을 때
- 아래와 같은 경우
재귀 연관관계
- 클래스 자신과 연관관계를 맺음
전체/부분관계 - Aggregation(빈마름모)
- 쉽게 말해서 필통은 연필과 지우개등을 가지고 있다 처럼 혹은 가질 수 있다로 표현할 수 있는 형식 사이의 관계
- Aggregation : 전체부분 관계를 나타내는 특수한 형태
- 전체에 해당되는 클래스는 aggregate 또는 assembly라 부름
- 다이아몬드 심볼은 isPartOf라는 관계로 생략할 수 있음
Aggregate를 사용하는 경우
- 일반적인 경우 다음의 관계가 성립하면 aggregate를 사용
- is part of관계가 성립할 때
- is composed of관계가 성립할 때
- 집합 개념을 관리하거나 소유하고 있으면 부분 개념도 소유
Aggregation 구조
- * 은 여러개가 있을 수 있다.
- 합성관계 : aggregation이 강한 관계, 집합이 소멸되면서 부분도 다라서 소멸(꽉찬마름모)
시퀀스 다이어그램
- 시스템의 동적인 측면을 모델링하는데 사용
- 시스템이 어떻게 수행되는지 시각화 하는 도움을 준다
- 시퀀스 다이어그램은 사용사례 다이어그램을 기초로하여 초벌 클래스 다이어그램으로부터 작성
- 객체의 집합이 액터와 어떻게 인터랙션이 이루어지는지 나타내는 것이 목적
- 각 클래스에 포함되어야 하는 오퍼레이션을 파악하는데 유용
시퀀스 다이어그램의 요소
- 클래스의 인스턴스 : 박스 안에 클래스 이름, 객체 식별자를 쓰고 밑줄
- 액터 : 사용사례 다이어그램에 그려진 막대 인간 심볼을 사용
- 메시지 : 액터에서 객체로, 객체에서 객체로 이동하는 화살표로 표시
- 사용사례의 각 task를 수행하기 위하여 객체들이 메시지를 교환하는 순서를 나타냄
- 객체가 다이어그램에 수평으로 정렬됨
- 인터랙션을 구동하는 액터를 왼쪽에 표시
- 수직축은 시간의 흐름을 나타냄
- 객체마다 라이프 라인이라 불리는 수직 점선을 붙임
- 객체가 구동 중임을 표시하려면 라이프 라인에 수직막대를 그림(이를 액티베이션 박스라 함)
- 메시지는 송신자와 수신자의 액티베이션 박스 사이에 화살표로 표시
- 메시지 이름과 매개변수를 나타내는 레이블을 붙임
회귀 메시지가 포함된 시퀀스 다이어그램
- 객체에 대한 반복 수행은 메시지 이름 앞에 '*'를 붙여 표시
객체삭제 시퀀스 다이어그램
- 객체가 소멸된 후에는 라이프라인이 중지되며 'x'로 표시
- 비동기메시지 : 실선과 선으로 이루어진화살표(결과 기다리지 않음)
- 동기 메시지 : 실선과 꽉찬화살표(결과가 올대까지 기다림) eX)시간이 걸리는 메시지
커뮤니케이션 다이어그램
- 커뮤니케이션 다이어그램은 인터랙션을 실현하기 위하여 객체들이 어떻게 협동하는지를 나타낸 것
- 커뮤니케이션 다이어그램은 객체가 노드인 네트워크
- 객체들 사이에 커뮤니케이션 링크가 추가 됨
- 메시지가 링크에 추가
- 화살표에 메시지 이름을 붙임
- 메시지가 호출되는 순서는 메시지 앞에 숫자를 적어 표시
- 커뮤니케이션 다이어그램의 거의 모든 심벌은 시퀀스 다이어그램에서 사용하여 쉽게 인식 가능
커뮤니케이션 링크
- 객체에서 다른 객체로 메시지를 보내는 것은 항상 커뮤니이션 링크로 표시
- 메시지 교환이 일어나는 경우
- 1. 두 객체의 클래스가 연관관계에 의하여 결합된 경우
- 대부분은 여기에 해당
- 모든 메시지가 같은 방향이라면 인간관계는 단방향
- 2. 메시지를 받는 객체가 보내는 객체의 로컬 변수로 저장된 경우
- 보내는 메소드에 의하여 객체가 생성되거나 계산결과 리턴되는 경우 <<local>>로 표시
- 3. 메시지를 받은 객체에 대한 레퍼런스가 전달된 메시지의 매개변수가 되는 경우
- 메시지에 <<parameter>>라는 스테레오 타입표시를 함
- 4. 받는객체가 전역변수 인경우
- 객체에 대한 레퍼런스가 공개된 정적메소드를 이용하여 전달
- <<global>>을 사용하여 표시
- 전역변수의 사용을 최소화
- 5. 객체가 네트워크를 통하여 커뮤니케이션 되는 경우
- <<network>>라고 표시
- 1. 두 객체의 클래스가 연관관계에 의하여 결합된 경우
커뮤니케이션 다이어그램과 패턴
- 디자인 패턴을 표현할 때 커뮤니케이션 다이어그램을 사용
- 프록시 패턴에서 필요한 메시지 패싱을 나타냄
- 클라이언트가 객체가 프록시 객체에 요청
- 대규모 파일이나 이미지 객체를 메모리에 저장해야 하는 HeaveyWeigh가 필요하지만 현재 로드되지 않았다면 로드를 요청
- 프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템
- 프록시 서버에 요청된 내용등을 캐시에 저장하여 네트워크 부담을 줄임
커뮤니케이션 다이어그램 그리는 방법
- 해당 사용 사례를 위해 협력하는 모든 객체를 찾는다
- 객체 사이에 교환되는 메시지를 시간 순으로 나열
- 중심이 되는 객체를 찾아 중앙에 놓는다
- 중심 객체와 직접 연결되어 상호작용하는 객체를 주위에 놓는다
- 메시지가 호출되는 순서에 따라 연관된 객체를 하나씩 그리고 메시지를 화살표로 표시
- 만일 시스템이 여러층으로 나뉘어 있다면 각 층의 모든메시지가 다이어그램에 표시될 때까지 다음층에 대해 처음부터 반복
시퀀스, 커뮤니케이션 다이어그램 선택방법
- 시퀀스 다이어그램
- 메시지의 순서를 드러내 보여주고 싶을 때
- 사용사례로부터 인터랙션 모델을 구축할 때는 가장 자연스러운 선택
- 메시지에 자세한 사항, 즉 파라미터, 리턴 값 등을 나타내고 싶을 때
- 커뮤니케이션 다이어그램에서는 자세한 것을 나타낼 공간이 없음
- 메시지의 순서를 드러내 보여주고 싶을 때
- 커뮤니케이션 다이어그램
- 클래스 다이어그램의 투영
- 클래스 다이어그램에서 커뮤니케이션 다이어그램을 추출할 때
- 클래스 다이어그램을 검증할 때 이용
- 누락된 관계를 추가할 수 있음
- 클래스 다이어그램의 투영
11장. 프로젝트 관리
소프트웨어 개발 프로세스
- 프로젝트를 소규모 작업으로 구성하는 일반적인 접근 방법
- 관리자와 팀원들이 다음 사항을 결정하는데 도움
- 무엇을 해야 하며
- 어떤 순서로 작업을 진행 할 것인지
- 모델은 작업 방식을 엄격하게 규정하기 위함보다 생각하는 데 도움을 주어야 함
- 각 프로젝트는 고유의 계획을 가지고 진행하여 완성됨
즉흥적인 개발 프로세스
- 좋은 엔지니어링 과정을 따르지 않았을 때 일어나는 문제점들
- 구현하기 전에 요구나 설계 등의 연습의 중요성을 인식하지 못함
- 설계가 잘 되지 않았다면 S/W의 질이 떨어질 수 있음
- 계획이 없어 목표없이 일하게 됨
- 체계적인 테스트나 품질 보증 같은 작업의 필요성을 간과하게 됨
- 이상의 이유로 개발과 유지보수 비용이 증가 됨
폭포수 모델
- 1970년대 소개
- 항공 방위 소프트웨어 개발 경험으로 습득
- 각 단계가 다음 단계 시작 전에 끝나야 함
- 순서적 - 각 단계 사이에 중복이나 상호작용이 없음
- 각 단계의 결과는 다음 단계가 시작되기전에 점검
- 바로 전단계로 피드백
- 단순하거나 응용 분야를 잘 알고 있는 경우 적합
- 한번의과정, 비전문가가 사용할 시스템 개발에 적합
- 결과물 정의가 중요
- 단점
- 처음 단계의 지나치게 강조하면 코딩, 테스트가 지연
- 각 단계의 전환에 많은 노력
- 프로토타입과 재사용의 기회가 줄어듦
- 소용 없는 다종의 문서를 생산할 가능성 있음
- 개발이 종료된 후에는 유지보수 작업만 가능
- 계요설구시인
- MIT-STD-2167
- general system life cycle
- software development cycle
- ISO 12207
점증적 모형
- 개발 싸이클이 짧은 환경
- 빠른 시간안에 시장에 출시하여야 이윤에 직결
- 개발 시간을 줄이는 법- 시스템을 나누어 릴리스
- 요구 #1 -> 설계 -> 구현 -> 테스트 및 패키징 -> 릴리스 #1
- 요구 #2 -> 설계 -> 구현 -> 테스트 및 패키징 -> 릴리스#2
- ...
- 릴리스 구성 방법
- 점증적 방법 - 기능별로 릴리스
- 반복적 방법 - 릴리스할 때마다 기능의 완성도를 높임
- 단계적 개발
- 기능이 부족하더라도 초기에 사용 교육 가능
- 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음
- 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음
- 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음
나선형 모형(Spiral Model)
- 소프트웨어의 기능을 나누어 점증적으로 개발
- 실패의 위험을 줄임
- 테스트 용이
- 피드백
- 여러번의 점증적인 릴리즈(incremental releases)
- Bohem이 제안
- 단계
- 계획 수립(planning) : 목표,기능 선택, 제약 조건의 결정
- 위험 분석(risk analysis) : 기능 선택의 우선순위, 위험요소의 분석
- 개발(enginerring) : 선택된 기능의 개발
- 평가(evaluation) : 개발 결과의 평가
- 대규모 시스템 개발에 적합
- 반복적인 개발 및 테스트 - 강인성 향상
- 단점 : 관리가 중요, 위험 분석이 중요
진화적 모델
- 반복적이며 점증적인 방법
- 첫 번째 반복 : 모든 사용 사례와 요구를 다룸
- 두 번째 반복 : 분할된 시스템의 조각 중 선택된 조각에서 가장 중요한 위험 요소를 다룬다.
- 다음 반복 : 이전 반복의 결과를 바탕으로 구축
- RUP(Rational Unified Process) (도정구전)
- 1. 도입 단계 : 프로젝트의 범위를 설정하고 목표를 명확히
- 2. 정련 단계 : 시스템의 중요한 요구를 찾아내어 기본이 되는 설계를 완성
- 3. 구축 단계 : 제조단계. 원시코드가 완성되고 모든 중요한 요구의 테스트가 마무리
- 4. 전환 단계 : 사용자에게 릴리스
애자일 프로세스
- 설계가 변경되어도 잘 수용할 수 있도록 짧게 반복하면서 개발하는 방법
- 짧은 릴리스와 반복 : 작업을 작은 조각으로 나누어 되도록 자주 릴리스
- 점증적 설계 : 설계에 대한 결정을 미루고 더 많은 지식이 쌓였을 때 설계를 개선
- 사용자 참여 : 처음부터 변하지 않는 완벽한 표준을 만들려고 하기보다 사용자를 참여시켜 계속 피드백 제공
- 문서 최소화 : 필요한 문서만 최소로 작성. 원시코드가 문서화의 실체
- 비공식적 커뮤니케이션 : 형식적인 문서보다 지속적인 대화
- 변화 : 요구와 환경에 변경을 가정
애자일 선언문
- 프로세스의 도구보다 개인과의 소통이 더 중요
- 완벽한 문서보다 실행되는 소프트웨어가 더 중요
- 계약 협상보다 고객과의 협업이 더 중요
- 계획을 따른 것보다 변경에 대한 응답이 더 중요
익스트림 프로그래밍
- 최초의 애자일 프로세스
- 계획 : 비즈니스 우선수위와 기술적인 예측을 토대로 기능 결정
- 짧은 릴리스 : 2~4주
- 메타포 : 정형화된 아키텍처 대신 메타포를 사용
- 간결한 설계 : 불필요하게 복잡한 부분은 제거
- 테스트 중심 개발 : 실제 코드를 쓰기 전에 먼저 테스트 코드를 작성
- 설계 개선(리팩토링) : 동작의 변경없이 시스템을 재구성하고 설계를 개선
- 페어 프로그래밍 : 컴퓨터를 공유하며 개발과 테스팅 역할을 분리
- 지속적 통합 : 항상 실행되는 시스템을 유지하도록 여러번 통합하고 빌드
- 적정 속도 : 주당 40시간
- 고객 참여 : 팀에 고객이 합류하여 항상 질문에 답할 수 있도록
- 코딩 표준 : 코딩에 동일한 규칙
스크럼
- 개발 연습을 하면서 개발 능력을 향상할 수 있는 프레임 워크
- 릴리스 계획 회의 : 백로그를 결정
- 스프린트
- 제품 개발 과정
- 반복주기(1~4주)
- 스크럼회의
- 매일 15분간의 진도 확인 회의
- 스프린트 회고
일정 계획과 관리
- 일정 계획 : 개발 프로세스를 이루는 소작업을 파악하고 순서와 일정을 정하는 작업
- 작업 순서 : wbs찾기, pert차트작성(임계경로구하기), 간트차트 작성
wbs찾기
- 작업분해(프로젝트에 완성에 필요한 Activiy를 찾아냄)
- Work Breakdown Structure : 계층적 구조
PERT 차트작성, 임계경로 구하기
- PERT차트 장점
- 관리자의 일정 계획 수립에 도움, 일정 시뮬레이션, 일정 점검 관리
- 임계경로 : 프로젝트 완성까지 가장 긴 시간이 걸리는 경로
간트 차트
- 프로젝트 일정표
- 소 작업별로 작업의 시작과 끝을 나타낸 그래프
- 예비시간을 보여줌, 계획 대비 진척도를표시
실적 가치 차트
- 실적 가치 : 소모되는 예상 노력 대비 완성되어 측정된 작업의 양
- 세가지곡선 : 계획된작업예산비용, 실적가치, 실제 수행된 작업비용
'공부' 카테고리의 다른 글
| 클라우딩 컴퓨팅 소개 (1) | 2023.10.24 |
|---|---|
| 웹프로그래밍기초 기말 (1) | 2023.06.11 |
| 소프트웨어공학 - 기말 (0) | 2023.06.06 |
| 소프트웨어공학 - 1.소프트웨어 공학의 개요, 2. 객체지향 개념, 3.요구분석 (0) | 2023.04.23 |
| 웹 프로그래밍 기초 시험 예상 (0) | 2023.04.19 |
