1. 소프트웨어 생명주기(SDLC)

소프트웨어 생명주기는 SW를 개발하기 위한 과정을 정리한 것이다.

솔직히 생각해보자면 소프트웨어 개발은 돈이 가장 중심이 된다. 돈 때문에 여러 방법론이 생긴 것이라고 봐도 무방한 것이다.

소프트웨어 개발 단계에서 가장 비용이 많이 소비되는 단계는 개발도 아닌 유지보수이다. 그래서 SW 재공학과 재사용이 중요한 것이다. 이것에 대해서는 뒤에서 다뤄질 것이지만 소프트웨어 개발의 흐름이란 이렇다.

돈 이야기가 나왔기 때문에 이야기 하는 것인데, 개발에서 돈을 관리하기위해 3가지를 관리해야 한다.

일정, 인원, 조직

이 세가지를 적절히 관리하지 않으면 비용을 낭비하게 되는 것이다.

그 비용을 산출하기 위하여 크게 방식을 두가지로 나눠 볼 수 있다. 바로 과학적 기법과 비과학적 기법이다. 각각 상향식/하향식으로도 부른다. 이것 또한 뒤에서 다시 다뤄질 것이다.

SW개발방법론에는 크게 두가지가 있다 구조적 방식과 객체지향방식이 있다. 구조적 방식은 큰 것을 개발하고 세부적인 것을 개발해나가는 하향식 방법이다. 반면 객체 지향은 작은 것부터 개발해나가며 서로 붙혀나가 큰 것을 만들어 나가는 상향식 개발이다. 비용을 산출할 때 기본적으로 어떤 방법론이 유리하겠는가? 아래에서부터 개발을 해나가며 어느쪽에 노력이 더 들어가는지 파악하기 쉬운 객체지향방법론이 비용을 산출하는데 더 유리할 것이다.

시작부터 왜 이런 글을 쓰는가? 그것은 공부를 함에 있어 전체적인 흐름을 이해하는 것이 가장 중요하다고 생각하기 때문이다. 특히 정보처리기사는 출제 범위가 매우 다양하고 여기저기 넓게 흩뿌려져 있는 정보가 많아 그냥 롤러코스터마냥 책에 적혀있는대로 보기만한다고 모든게 이해가 되는게 아니다. 정확한 이해와 연계를 확실히 볼줄 알아야 진짜로 이해하게 된다.

1) 폭포수(Waterfall) 모델

타당성 가늠 → 계획 → 요구 분석 → 설계 → 구현 → 시험 → 유지보수

위의 과정을 따라 구현이 되어간다. 이건 외워라. 솔직히 조금만 생각해도 당연한 과정이니 어렵지도 않다.

폭포수 모델의 특징은 각 단계에서 결과물을 산출하고 이를 토대로 다음 단계로 넘어간다는 것이다.

매우 전통적이며 성공사례 또한 많을 수 밖에 없다.

폭포수라는 이름만 들어봐도 알겠지만 거슬러 오르는 것은 불가능하다. 즉 고객의 요구사항 변경이 일어나게되면 그것을 변경하기 어렵다라는 문제가 생긴다.

그래서 프로젝트가 작으면 도입하기 쉽다.

요구사항 변경이 어렵다라는 이야기를 했으니 요구사항 도출이 중요하다고 생각이 들 것이다.

그렇다면 요구사항 도출에 대해 가볍게 다뤄보자.

요구사항 도출법은 이것 말고도 다른 것들이 더 있다. 개발자도 고객도 개발 지식이 없어 무엇을 정확히 요구하는지 모를 때가 있다면 어떻겠는가? 일단 무언가라도 조금 만들어서 고객한테 그걸 보여준다면 더 직관적이지 않겠는가? 그래서 생겨난 모델이 바로 다음 모델이다.

2) 프로토타입 모델

왜 생겨났는지는 위에서 이미 봤다.

고객의 불명확한 요구사항을 충실히 반영하기 위한 테스트가 가능한 시제품

이것이 프로토타입 모델의 정의이다.

그리고 당연하게도 프로토타입 만드느라 시간 다 빼앗기면 개발은 언제 하겠는가? 대규모 프로젝트에는 못써먹는 방식인 거다.

그러면 대규모 프로젝트에서 시시각각으로 변할 지도 모르는 이 요구사항을 어떻게 관리하겠는가?

3) 나선형 모델

요구사항이 계속해서 바뀔지도 모르는 것또한 어찌 보면 위험요인이기도 하다.

위험요인을 최소화 시키기 위해 점진적으로 개발해 나가는 것이 바로 스파이럴 모델이다.

이 과정에서 요구사항이 추가되어도, 변경되어도 점진적으로 개발하였기 때문에 수정이 쉬워진다.

4) 애자일 모델

애자일 모델은 비교적 최근에 뜨는 개발방법이다(정확히는 방법론들의 총칭임). 애자일은 고객과 피드백에 더 중심을 잡고 있다.

애자일 선언을 통한 4가지를 한번 살펴볼 필요가 있다.

• 개인과 상호작용
• 실행되는 SW에 집중
• 협업
• 변화 대응

애자일 축에 속하는 개발방법론으로는 스크럼, XP(뒤에서 더 자세히 다룸), FDD, ASD, DSDM, Kanban, crystal이 있다.

스크럼 모델

스크럼 모델은 팀 중심의 개발이다. 여기서 가장 중요한 단어는 스프린트이다.

스프린트 : 짧은 주기의 개발 기간

스크럼은 하나의 팀을 3개로 나눈다.

1. 제품 책임자 : 돈 내는 양반, 의뢰자이다. 말그대로 제품의 결과물을 책임지는 사람으로 개발에 대한 이해도가 높아야된다. 백로그를 관리한다.

   백로그 : 요구사항을 모아놓은 목록

2. 개발팀 : 개발하는 애들이다. 책임자랑 스크럼 마스터가 아니면 다 개발팀으로 분류한다.

3. 스크럼 마스터

   : 개발팀 관리자이다.

특징으로는 매일 마다 일일 스크럼 회의를 한다는 점이다.

XP(eXtreme Programming) 모델

고객이 직접적으로 참여한다는 점이 특징이다.

다른건 모르겠고 XP는 5가지 핵심 가치를 가지고 있다.

• 의사소통
• 단순성
• 용기
• 존중
• 피드백

이 5가지는 무조건 외워라

XP 실천사항 12가지또한 있는데 좀 집중할 것만 보자면

• small releases
• test driven development
• pair programming
• continuous integration
• whole team
• design improvement and refactoring

여기서 번외로 중요하게 볼 것은 리펙토링이다.

리펙토링 : 기능을 유지하면서 코드를 개선하는 작업이다.

시험에 나올 가능성이 아무리 봐도 높다.

5) 소프트웨어 공학 기본 원칙

• 되도록 현대기술 활용

• 검증하기

• 문서화하기

  외계인 코드 해결방법은 문서화(주석, 변수이름, 리펙토링)

2. 현행시스템 파악

개발을 하려면 현행시스템을 파악해서 정확히 뭘 어떻게 만들건지 알아야 한다.

현행시스템을 파악하는 방법은

1. 시스템 (인터페이스)
2. 소프트웨어 (아키텍처)
3. 하드웨어 (네트워크 포함)

이다.

시스템 인터페이스와 아키텍처는 기간업무에 속하지만 그 나머지는 단위업무에 속한다는 점을 기억해라

시스템 인터페이스 : 시스템간 통신을 하는 방법

아키텍처 : 소프트웨어간 구조이다.

현행시스템을 파악할 때 서버 이중화 여부도 파악한다.

서버 이중화 : 같은 서비스를 비상상황을 대비해 하나 더 열어놓는 걸 의미함

3. 개발 기술 환경 파악

이부분에서 좀 먼저 봐야할 건 이 4가지다

• 가용성 (=신뢰성) : 에러 없음?
• 성능 : 얼마나 성능이 좋음?
• 기술 지원 : 문제 생기면 지원 받을 수 있음?
• 구축 비용 : 그래서 그거 도입하면 돈 얼마나 써야됨?

이 4가지를 봐야하는 이유는 걍 공통적으로 계속 나오기 때문이다.

1) 운영체제

운영체제는 windows나 linux같은 컴퓨터 사용을 편리하고 효율적으로 도와주는 장치다. 이건 나중에 더 자세하게 다루니 지금 자세히 다룰 이유가 전혀 없다.

고려사항

• 가용성
• 성능
• 기술지원
• 지원기기 : 주변기기들을 얼마나 지원해줌?
• 구축비용

2) 데이터베이스

데이터베이스도 나중에 자세히 다룬다 지금 다룰 필요 없다.

고려사항

• 가용성
• 성능
• 기술지원
• 상호 호환성 : 데이터베이스는 커넥션 풀이란걸 만들어 줘야 되는데 그게 호환 잘되는지 물어보는거다.
• 구축비용

이제 이정도만 보더라도 고려사항에서 특별한 놈들이 각각 어디에 끼어있는지 눈에 띄지 않는가? 그런게 시험에 나올가능성이 아마 높겠지.

3) 웹 애플리케이션 서버(WAS)

와스라고 보통 부르는데 이것은 웹서버랑 차이점이 있다.

• 웹서버 : 정적 콘텐츠 제공

• WAS : 동적 콘텐츠를 처리하는 미들웨어

  미들웨어 : 클라이언트와 서버 사이에서 특정 처리를 하는 소프트웨어 계층 여기서 WAS를 미들웨어로 보는 것은 사용자와 DB 사이에서 일을 하기때문이다.

정적이냐 동적이냐가 중요한 키포인트이니 이것을 기억해라

고려사항

• 가용성
• 성능
• 기술지원
• 구축 비용

4. 요구사항 정의

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건 등을 나타낸다.
• 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
• 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다.
• 이것이 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있다.

위 처럼 물어보면 요구사항을 이야기 하는 것이다. 실기에 나오기 참 좋다. 귀있는자는 들을지어다.

요구사항은 크게 기능적 요구사항과 비기능적 요구사항으로 나눈다.

1) 기능적 요구사항

컴퓨터와 관련된 입력, 출력, 연산과 관련된건 전부 기능적 요구사항이다.

2) 비기능적 요구사항

성능, 품질, 보안과 같이 어느정도 수준이 되어야 한다같은 그런 제약조건에 관한 내용이면 비기능적 요구사항이다.

3) 사용자 요구사항과 시스템 요구사항

각각 뭐 사용자가 원하는거, 그리고 시스템에서 잘 작동하려면 필요로 하는 것을 얘기하는거다.

5. 요구사항 개발 프로세스

수집, 도출 -> 분석 -> 명세서 -> 확인(Validation)

이 단계로 진행되는데 여기서 확인은 사용자가 확인하는거다. 개발자가 하는게 아니다.

1) 요구사항 도출

• 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정이다.

  실기용으로 아주 좋겠다.

요구사항을 도출할 때 사용하는 기법들은 맨처음에 살짝 이야기 했었다.

여기서 이미 나온 이름도 있듯 다양한 방법이 있다.

• 인터뷰
• 설문
• 브레인스토밍
• 워크샵
• 프로토타이핑
• 유스케이스

프로토타이핑과 유스케이스에 집중하자. 프로토타이핑은 이미 다룬 바 있다. 유스케이스는 뒤에서 다뤄질 것이다.

2) 요구사항 분석

• 요구사항 중 명확하지 않아서 이해되지 않는 부분을 발견하고 걸러내기 위한 과정

요구사항 분석에 사용되는 도구는

자료흐름도(DFD)와 자료사전(DD), 소단위 명세서(Mini-spec), E-R 다이어그램이 있다. 이게 뭔지는 뒤에서 더 자세히 다룬다.

3) 요구사항 명세서

• 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것

문서화가 특징이다.

4) 요구사항 확인

• 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토하는 것

개발자가 하는게 아니다. 사용자 측에서 하는거다.

5) 명세서 작성법

명세서 어캐 쓸거임?

• 정형 명세 기법 : 수학적 기호 사용하면 정형이다.
• 비정형 명세 기법 : 수학적 기호 안쓰면 비정형이다.

각 특징은 조금만 생각해보면 응용할 수 있다.

6. 요구사항 분석

아까 다뤘다.

DFD, DD, 소단위 명세서, ERD가 있다. ERD는 데이터베이스할때 보도록 하자.

소단위 명세서는 그냥 조금 더 상세히 적어놓은 명세서라고 생각하면 된다. 여기서 집중적으로 봐야할건 DFD와 DD이다.

1) Data Flow Diagram

아쉽게도 따로 방법은 없다. 표기법을 그냥 외워놓자.

2) Data Dictionary

이것도 달리 방법은 없다. 외우자.

7. UML(Unified Modeling Language)

SW를 객체지향으로 설계하고 문서화할려고 만든 언어다. 대표적인 객체지향 모델링 언어다. 드디어 객체지향이라는 이름이 나왔다.

객체지향 하면 반드시 기억해야 할 이름 여럿 있겠지만 Rumbaugh라는 이름은 반드시 기억해야한다.

UML을 다루기 이전에 UML이 객체지향을 기반으로 하고 있으니 객체지향을 조금이라도 안다룰 수가 없겠다.

1) 객체지향

객체지향은 여기서 다루는 것으로 모든걸 다 다룰수는 없다. UML의 이해를 위해서 잠시 객체지향을 짚고 넘어갈 수 밖에 없으니 잠깐은 조금만 다룰 수 밖에 없다.

객체지향은 현실세계를 반영하여 소프트웨어를 구성하는 방식이다. 데이터와 기능이 같이 있는 것을 객체라고 부르며 객체

Rumbaugh

객체지향의 격동기를 기억해라

Rumbaugh의 객동기

객체 모델, 동적 모델, 기능 모델

이 세가지를 반드시 기억해야된다.

이 세 가지는 객체지향 분석에서 반드시 기억해야 한다. 왜냐하면, 객체지향으로 시스템을 설계하려면 이 세 가지 관점에서 분석을 수행하기 때문이다.

• 객체 모델링 : 시스템의 정적인 구조를 분석하며, 주로 객체 다이어그램으로 표현한다.
• 동적 모델링 : 객체 간의 상호작용과 상태 변화를 분석하며, 시퀀스 다이어그램이나 상태 다이어그램 등으로 표현한다.
• 기능 모델링 : 시스템 내의 데이터 흐름과 기능 처리를 분석하며, 자료 흐름도(DFD) 를 이용한다.

Coad와 Yourdon

다른거 기억할 필요없이 E-R 다이어그램을 통해서 객체와 행위를 모델링 한다.

우리가 요구사항 분석을 할 때 사용하던 도구들을 기억하는가? DFD, DD, Mini-spec, ERD

이들 도구는 객체지향 분석에서도 그대로 사용되며, 객체 모델링의 다양한 기법들과 자연스럽게 연결된다.

2) UML

이들의 객체지향 방법론을 알아본 이유는 이들의 방법론을 바탕으로 OMG(Object Management Group)에서 UML을 만들고 표준화 시킨 것이기 때문이다. 즉, 이들의 방법론이 UML에 그대로 반영되었기 때문이다.

그것은 차차 확인해보겠다.

UML은 크게 두가지로 분류해서 외워야한다.

1. 다이어그램
2. 구성 요소

먼저 첫번째로 다이어그램부터 정리해보자.

3) UML다이어그램

다른거 볼필요없이 다이어그램도 두개로 찢는다.

1. 구조적 다이어그램
2. 행위적 다이어그램

구조적 다이어그램

6개의 구조적 다이어그램이 존재한다. 이들이 존재하는 이유는 정적인 요소들을 소프트웨어 설계에서 문서화시키기 위함임을 기억해라. 항상 UML은 객체지향 설계의 문서화가 목적이다.

• 클래스 다이어그램 : 클래스라는 이름은 곧 객체의 모임이라고 정리할 수 있다. 클래스와 클래스가 연관되어있다면 그것은 클래스 다이어그램이다.
• 객체 다이어그램 : 객체와 객체의 관계를 표현한다는 말이 있으면 그건 객체 다이어그램이다.
• 컴포넌트 다이어그램 : 컴포넌트라는 단어가 나온다면 재사용을 바로 연관지어라.
• 배치 다이어그램 : 무엇을 어디다 배치할까? 물리적 요소들의 위치를 표현하는 다이어그램으로, 배치와 위치를 짝지어서 외워라
• 복합체 구조 다이어그램 : 복합 구조에 관한 이야기가 나온다면 복합체 구조 다이어그램
• 패키지 다이어그램 : 패키지라는 단어가 나온다면 패키지랑 연관시켜라

이곳에서 나오는 이 6개 다이어그램의 이름을 외워둬야 한다.

컴포넌트와 배치 다이어그램은 구현 단계에서 사용한다는 점도 알아둬야 한다.

행위적 다이어그램

7개의 행위적 다이어그램으로 동적요소들을 표현하기 위해 사용한다.

• 유스케이스 다이어그램 : 유스케이스는 다음에 다룰 것이다. 쉽게 얘기하자면 사용자가 뭘 하면 뭐가 어떻게 되는지 구현한 그림이다. 기능 중심으로 표현한다는 점만 기억해도 된다.
• 순차 다이어그램 : 순차와 메시지를 연관시켜서 기억하라. 메시지는 차곡차곡 쌓여서 하나하나 읽어보니 순차적이라는 느낌이 든다라고 생각하면 더 쉬울 것이다.
• 커뮤니케이션 다이어그램 : 커뮤니케이션은 메시지와 연관관계가 동반한다.
• 상태 다이어그램 : 상태변화에 따라 표현하는 것.
• 활동 다이어그램 : 조건에 따른 행동, 바로 활동 다이어그램으로 연관시켜라.
• 상호작용 개요 다이어그램 : 상호작용 간의 제어 흐름
• 타이밍 다이어그램 : 시간 제약과 관련되어있다면 타이밍 다이어그램이다.

행위적 다이어그램은 이후 조금 더 살펴볼 것이다.

스테레오 타입

수많은 다이어그램들이 있지만 그 다이어그램 내에서 표현이 불충분할 수 있다.

그럴 때, <<>>라는 길러멧 기호를 사용하여 추가적인 기능을 표현할 수 있다.

• <<include>> : 다른 요소에 포함관계

  포함은 필수를 의미하여 화살표 기호로 표현은 →이다.

• <<extend>> : 다른 요소에 확장관계

  확장은 선택을 의미하며 화살표 기호 표현은 ←이다.

• <<interface>> : 인터페이스 정의

• <<exception>> : 예외 정의

• <<constructor>> : 생성자 역할 수행

다 영어 번역만 하면 답이 나오니까 쉽게쉽게 넘어가자.

대신 포함과 확장은 필수와 선택 개념을 잘 분간 하고 화살표 기호 표현도 기억은 해놓자

4) UML Relationship

이제 다이어그램 옆동내를 알아보자. 여기도 외워야 될것이 좀 많다.

관계란 무엇일까? 개체와 개체 사이의 연관성, 사물과 사물 사이의 연관성, 즉, 무엇과 무엇 사이의 연관성. 무슨 연관성이 있는가를 정리해놓은 것이라 보면 된다.

연관(Association) 관계

• 사물 사이를 실선으로 연결하여 표현.
• 방향성이 있다면 화살표로 그어라

다중도는 연관관계에서 각 개체의 개수를 표시하는데

1:1, 1:N, N:M 만 기억해라

집합(Aggregation) 관계 / 포함(Composition) 관계

이 둘은 개념이 좀 비슷한 부분이 있다.

둘다 전체와 부분에 대해서 다룬다. 하지만 집합 관계는 독립적이지만 포함 관계는 종속적이다.

둘다 큰 쪽(전체)에 작은 것(부분)을 연관 시킨 것이지만

마우스는 다른 컴퓨터에 바꿔 사용하는 것에 반면, 문은 문 자체가 사라지면 키도 쓸모를 잃게 된다.

이것이 독립과 종속이다.

기호를 잘 봐두고 외워두어라

일반화(Generalization) 관계

노래 부르듯이, 일반화는 구체화랑 연관지어라. 둘이 반대되는 표현이다.

커피라는 것은 추상적이다. 이것을 구체화 시키면 다양한 커피 종류 이름이 나온다. 하지만 각각의 커피들의 이름을 통칭으로 부른다면 커피라고 부를 것이다. 이것이 일반화이다.

일반화는 추상화 시키는 것이니 삼각화살표의 방향을 신경쓰도록 하자

구체화라는 표현은 일반화를 이해하기 위해 사용한 것이지만 구체화란 표현은 일체 쓰지 않는다는 점을 기억해라. 만약 문제에서 구체화를 들먹인다면 그게 틀린거니 정답으로 선택해라.

여담이지만 2025년, 미국의 한 선출직 공무원께서 너무 위대한 일을 하셔서 그것이 너무도 감명 깊은지라 캐너디아노라고 부르도록 하겠다.

의존(Dependency) 관계

짧은 시간동안에만 서로에게 영향을 주는 관계이다.

화살표가 파선인 것을 주의

실체화(Realization) 관계

실체화는 추상화와 인터페이스라는 말이 따라 붙는다. 하위 개념이 할 수 있는 상위 개념을 실체화라고 한다.

화살표의 방향과 삼각파선화살표라는 점을 기억하라.

5) 유스케이스 다이어그램

이제부터는 행위적 다이어그램으로 분류하며 정리했던 그 다이어그램들을 쭉 나열/정리해보자

아까 행위적 다이어그램에 유스케이스가 있었던 것을 기억하는가? 그리고 이전에 보았던 관계 표현법도 이제 읽혀지는가?

스테레오 타입에서 include의 화살표는 오른쪽으로 가고 extend의 화살표는 왼쪽으로 간다는 것을 기억하는가?

축하한다. 당신은 이제 유스케이스를 설명없이 한번에 모두 이해하였다.

다만 이전에 보지 못했던 것들만 조금 정리해보자

유스케이스 요소 4가지

1. 시스템 : 사각형 박스로 표현하고 시스템의 범위를 표현하는데 사용한다. 사진에선 상품주문 박스가 시스템범위인것이다.
2. 액터
   • 주액터 : 왼쪽의 사람 모양이다. 시스템을 사용할 고객이라고 생각하자
   • 부액터 : 오른쪽의 사각박스 액터이다. 외부 시스템이다.
3. 유스 케이스 : 시스템 내부에 원형으로 표시된 기능들을 볼 수 있는데, 맞다. 기능이다.
4. 관계 : 저 위에 표현된 모든 선들이 모두 관계인걸 이제와서 모른다고 하지 말자. 선 종류들이 무엇인지도 물어보지 말자. 다 이미 앞에서 봤다.

유스케이스는 동적 서비스 흐름을 볼 수 있지만 세부적인 것 까지 볼 수는 없다. 만약 ~때문에 안된다면? 그 때는 어떻게 할건데?를 유스케이스로 표현하기는 어렵다. 그 때, 우리는 이미 이전에 알아보았다. 조건에 따른 행동을 그리는 다이어그램, 곧 활동 다이어그램이다.

6) 활동 다이어그램

조건에 따른 행동을 표현하는 활동 다이어그램

흐름만 보아라 요소를 볼 필요까지는 없겠다.

7) 클래스 다이어그램

클래스와 클래스간의 관계를 표현

야구선수라는 항목이 보이는가? 클래스에는 저렇게 많은 것들을 표시할수도 있지만은 리그, 경기장 등등 이름만 써져있는 것처럼 다른거 필요없이 이름만 적어넣을 수도 있다. 너무 상세하게 까지 그리지는 않아도 된다 이얘기다.

다른 박스와 다르게 표현된 것도 있는데 제약조건이라고 한다. 클래스의 내부 내용에서도 브래킷{}에다가 표현을 해놓은 것 또한 제약조건이다.

클래스 다이어그램의 3요소

• 클래스
• 제약조건
• 관계

이건 기억해두자

연관관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스? (연관 클래스)

연관 클래스는 클래스와 클래스 사이에 그려 넣는다. 그정도만 기억하자

접근제어자라는 것도 사실 볼 수 있긴하다(+-#~). 지금 다룰 필요없지만 이런게 있다는 것만 좀 봐놓자.

8) 순차 다이어그램

메시지를 주고받으며 상호작용한다.

요소

• 액터

• 객체

• 생명선

• 실행상자

  : 직사각형 박스를 의미한다. 실행되는 순간을 표현한것 뿐이다

• 메시지 : 상자 간에 화살표로 왔다갔다 할때 무슨 내용이 왔다갔다하는지 읽을 수 있는데 이게 메시지다. 이게 순차적으로 왔다갔다 하니 순차 다이어그램이라는 것이다.

• 객체 소멸

• 프레임

9) 커뮤니케이션 다이어그램

메시지와 연관관계가 같이 표현된다. => 커뮤니케이션 다이어그램

말(메시지)이 오고간다라는건 그것이 곧 커뮤니케이션이다. 그렇게 외우자.

관계를 표현할때는 링크라는걸 사용한다. 그것만 추가적으로 알아두자

요소나 그림이 중요한 것이 아니니 패스

10) 상태 다이어그램

상태변화 표현

요소들은 딱히 기억할 필요는 없고 만약 이게 나온다면 아쉽게 되었다.

다이어그램 때문에 정신 나갈거 같애

UML과 관련된 수많은 UML다이어그램들을 보면 공부하다가 뭐하는 짓인가 싶을 순간이 바로 이 순간이다.

UML의 종류는 그림을 보고 아 대충 이런거구나 감을 잡고 외울때는 다이어그램과 키워드들을 연관시켜 놓은 것을 기억하고 그 키워드가 문제에서 나온다면 바로 다이어그램을 떠올릴 수만 있어도 된다.

메시지? => 순차 다이어그램

나는 똑똑하다라고 한다면 각 다이어그램의 요소들을 조금 더 외워두자. 대부분 동일하지만 각 다이어그램에서만 쓰는 요소들이 또 따로 있다.

웬만하면 UML 다이어그램은 자주자주 정독해보길 바란다. 한번에 공부하는건 한번에 까먹겠다라는 것과 동일하니깐 말이다.