클라우드 6일차

OOSD

객체 지향 소프트웨어 개발 과정

객체지향기술을 사용하여 소프트웨어를 개발하고자 한다면 OOSD를 사용해야 함

소프트웨어의 방법론

• 사전적 의미로는 경험에 의해 얻어진 방법, 규칙, 가정들의 집합

• 소프트웨어 개발에서 방법론은 개발과정의 가장 고수준으로 얘기되어짐

• 근래의 많은 방법론은 Inception, Elaboration, Construction, Transition 이렇게 4단계로 구성되어짐

• 이들 단계는 다시 세부적인 워크플로우(Workflow)로 구성되어지고 이 워크플로우는 특별한 Activities(동적행위)로 이루어짐

• Activities는 Worker(워커)와 Artifacts(산출물)를 포함

Worker : activity를 수행할 사람

Artifacts : activity에 의해 산출된 유형의 정보 조각, 예를 들어 다이어그램들이나 문서, 소프트웨어 코드 등을 말함

모든 방법론들은 단계라는 것을 갖는데, 각각의 단계에서는 해야할 일의 그룹이 생김, 그것을 워크플로우라 부름

OOSD 계층 피라미드

OOSD 프로세스의 워크플로우 단계

1. 요구사항 수집

• 비즈니스 오너와 시스템 사용자들과의 인터뷰를 통해서 시스템의 요구 사항을 결정짓는 단계

2. 요구사항 분석

• 시스템 요구 사항을 분석, 정제, 모델링 하는 단계

3. 아키텍쳐 수립

• 시스템의 high-level 구조를 모델링하여 프로젝트의 리스크를 진단하고 그것을 줄일 수 있는 방법을 강구하는 단계

4. 디자인

• 시스템 요구사항을 만족하는 솔루션 모델을 생성하는 단계

5. 구현

• 솔루션 모델에 정의되어 있는 소프트웨어 컴포넌트를 생성하는 단계

6. 테스트

• 시스템이 요구사항을 만족시키는지를 검증하는 단계

7. 배치

• 시스템을 배치하는 단계

객체지향 기술의 장점

(vs 절차적 패러다임)

1. 유기적 구조

• 네트웍을 통한 객체간의 협력 구조를 가짐
  (절차적 패러다임 : 계층적인 수행 구문들로 이루어짐)

2. 소프트웨어 변경 능력

• 소프트웨어는 견고하면서도 변경에 유연함
  (절차적 패러다임 : 한번 만들어진 소프트웨어를 변경하는 것이 어려움)

3. 재사용

• 데이터나 기능을 가진 객체의 재사용성이 탁월
  (절차적 패러다임 : copy-and-paste이외의 재사용이 어려움)

4. 특수한 경우의 구성

• Polymorphism이라고 하는 다형성을 표현할 수 있는 기능을 가짐
  (절차적 패러다임 : 종종 if나 switch구문으로 해결)

5. 기능의 분리

• 모듈기능의 코드가 기능의 분리를 도와줌
  (절차적 패러다임 : 기능별로 분리되기 어려움)

다형성은 철학의 의미 뿐만 아니라 속도에 영향을 줄 수 있음

클라우드 엔지니어는 deployment specialist에 해당

모델

• 모델이란 어떤 엔티티 또는 시스템의 추상적 개념화

• 모델은 그것의 본질로 추상화 되어짐

  또한 모델은 여러 다른 사물들(예를 들어, 빌딩이나 컴퓨터 네트웍 같은 물리적 사물들이나 소프트웨어와 같은 관념적 사물들까지도)로 표현 될 수도 있음
  (하려고 하고자 하는 일을 가시적으로 단순화)

• 모델은 어떻게 바라보느냐에 따라 다양한 뷰가 나올 수 있음

  예를 들어 건축가는 집을 지을 때 평면도, 정면도, 투시도와 같은 다양한 관점에서의 그림을 그림
  소프트웨어도 마찬가지로 이러한 여러 관점에서의 그림을 그리게 됨

소프트웨어를 모델하는 이유

모델링은 다음과 같은 것을 가능하게 함

• 새 시스템이나 기존 시스템의 가시화

  • 모델은 우리가 어떤 시스템을 이해하는 데 좀 더 쉬운 방법으로 가시화 할 수 있음

• 프로젝트 stakeholder들간의 의사소통을 원활히 함

  • 어떤 모델은 비즈니스 오너, 도메인 전문가 그리고 다른 클라이언트 참가자들과의 이해를 돕는데 필수적

  • 또 어떤 모델은 개발팀내에서 사용하는데 더 유용할 수도 있음

• 각 OOSD 워크플로우에서 만들어지는 결정의 문서화

  • 개발팀의 크기에 따라 모든 팀원들이 같은 워크플로우를 진행할 수 있는 것은 아님

  • 각 역할 구성원들이 다른 작업을 수행하면서 이루어지는 모든 프로젝트에 관한 결정은 문서화 되어야만 이후에 다른 구성원들에게 전달되어 사용될 수 있을 것임

소프트웨어 개발 과정에서의 요구사항 수집, 구조화, 구현

1. 프로젝트 참가자들의 구상 모델(Stakeholders Mental Model)을 수집

• 프로젝트 참가자(이해관계자)들이 가지고 있는 시스템에 대한 생각과 기대를 수집

• 이는 시스템의 요구사항을 정의하는 기초가 됨

2. 시스템이 최종적으로 가져야 할 모든 요구 사항 모델(Requirements Model)을 구상

• 수집된 요구사항을 기반으로 시스템이 충족해야 할 기능적 요구사항(FRs)과 비기능적 요구사항(NFRs)을 문서화하여 요구사항 모델을 만듦

3. 시스템의 비기능적 요구 사항을 적용한 아키텍처 모델(Architecture Model)과 시스템의 기능적 요구 사항을 적용한 디자인 모델(Design Model) 생성

• 아키텍처 모델: 시스템의 구조를 정의하고 비기능적 요구사항(NFRs)을 반영

• 디자인 모델: 시스템의 세부 설계를 정의하고 기능적 요구사항(FRs)을 반영

4. 솔루션 모델(Solution Model)에서 취합, 시스템의 구체적인 형태를 정의

• 아키텍처 모델과 디자인 모델을 통합하여 시스템의 구체적인 형태를 정의

• 솔루션 모델은 시스템 구현의 청사진

5. 요구사항 모델에서 정의된 요구사항을 충족한 최종적으로 구현된 소프트웨어 생성

• 솔루션 모델을 기반으로 코드를 작성하고, 최종적으로 요구사항 모델에서 정의된 모든 요구사항을 충족하는 소프트웨어를 구현

Use case diagram

actor은 사람뿐만 아니라 system도 될 수 있음
receptionist는 bookingagent가 하는 일을 모두 다 할 수 있으면서 추가적인 일을 할 수 있음

한번만 실행해도 되는것을 extend
매번 선행해야 하는것을 include

오브젝트 다이어그램 표현법

래퍼런스 : 고객 이름(중요하지 않은 래퍼런스는 래퍼런스명 생략 가능)

도메인이 가장 먼저 만들어져야 UI와 Services가 참조

Behavioral : 사용자가 할 수 있는 기능

Structural : 구조적인 기능

Dynamic : 동작 기능

functional programming > 개발 속도, 편의 때문에

영속성

• 객체가 시공을 넘어서도 존재하는 것을 말함

• 메모리 주소에 무관하게 저장

RDBMS는 상속 관계가 없음
실무에서는 완전한 객체지향 형태가 아닌 형태가 많음

primary key(유일키)로 identity를 부여

엔티티

• 독립적 엔티티

• 의존적 엔티티

외래키 설명 추가

ERD : 엔티티 relationship diagram
처음엔 실선(일반 관계성), 방향 관계성을 갖게 됨

다대다 관계를 유지하기보다는 일대다 관계로 표현하기 위해(분리) 별도의 클래스를 생성

데이터와 정보

데이터 : 현실에서 측정하거나 보이는 사실이나 값, 순수하게 있는 그대로의 로우(raw) 데이터

정보 : 어떠한 목적이나 의도에 맞게 데이터를 가공한 것을 의미

모든 데이터가 정보이지는 않다

몽고db는 rdb가 아닌 nosql db
document 기반

데이터베이스는 크게 관계형 데이터베이스와 NoSQL로 분류

MySQL

create database myboard default char set utf8;
use myboard;
create table post (
id int(11) not null auto_increment,
title varchar(100) not null,
content text,
created datetime not null,
writer varchar(100),
email varchar(100),
primary key(id)
);
desc post;
insert into post(title, content, created, writer, email) values('삶은', '계란이다',
now(), 'lee', 'lee@naver.com');
insert into post(title, content, created, writer, email) values('위대하다', '밥을 많이 먹어서',
now(), 'lee', 'lee@naver.com');
insert into post(title, content, created, writer, email) values('나의 성격유형', 'infj',
now(), 'lee', 'lee@naver.com');
insert into post(title, content, created, writer, email) values('가을바람', '가을은 쓸쓸하다',
now(), 'lee', 'lee@naver.com');
insert into post(title, content, created, writer, email) values('언젠가부터', '사람들과 이해관계가 힘들어지는 것 같다',
now(), 'lee', 'lee@naver.com');

select id, title, content from post;

select * from post where id>2;

select * from post where writer='lee';

select * from post order by id desc;

select * from post limit 2;

update post set content='성격 파탄자' where id='3';

delete from post where id=2;

직접 입력하고 Apply 버튼 눌러 적용도 가능

select id, title, content, created, writer, email from post left join profile on post.profile_id = profile.id;

id는 post테이블과 profile테이블 둘 다 포함하고 있어 모호하다는 오류가 뜸

select post.id, title, content, created, writer, email from post left join profile on post.profile_id = profile.id;

post.id라고 명확히 지시해주어 오류 해결