yongmin

1. Business process and Funcrtional modeling

requirement를 functional model로 설계

requirements들로부터 use-case 설계

use-cases들로부터 activity diagram 설계

2. Use-case & use-case diagram

Use-Case 정의

- 소프트웨어 시스템이 주변 환경과 어떻게 상호작용하는지, 유저가 소프트웨어 시스템을 어떻게 사용하는지 표현

각각의 use-case는 1개의 기능만을 묘사

use-case는 block들을 만들고 block들에는 연속적인 activity들이 담겨있다

Use-Case identification

1. 요구사항 분석

2. subject boundary 확인하여 시스템이 해야하는 일과 안해도 되는 일 구분

3. 주요 actors과 그들의 목표 확인

4. business process와 주요 use-cases 확인

5. 현재 만들어진 use case들을 재검토하여 올바른 size인지, 추가적인 use cases가 있는지 확인

use-case diagram 정의

- Use Case를 그림으로 표현한 것

Use Case Diagram의 4가지 원소.

1. Actors : 유저 또는 소프트웨어 시스템이 상호작용하는 다른 시스템

2. Associations : actors와 use-cases를 연결하는 선으로 interaction, inclusion, extension, generalization과 같은

관계를 나타낸다

3. Use-case : 요구사항에 따라 만들어져서 유저에게 이익을 주는 시스템의 주요한 프로세스

4. Subject boundary : 시스템의 범위를 나타내는 박스

Use-ase Diagram 생성과정

1. use cases를 그리고 배치

2. actors를 그리고 배치

3. subject boundary를 그린다

4. actors와 use cases의 관계, use case와 use case의 관계를 추가

3. Activity Diagram

Activity Diagram

business processes를 구성하는 activity들의 sequence를 묘사하는 활동다이어그램

- 함축적이며, 일반적인 상황에서의 프로세스들을 표현한다

- object들의 독릭접인 행동들을 설계한다

- 모든 타입의 프로세스에 사용될 수 있다.

Activity Diagram syntax

action & activity : 엑션과 액션집합 표시

control flow : 실행의 순서 표시

initial node : 액션집합의 시작점

final node : 액티비티에서 flow가 끝나는 지점

decision node : test condition 표시

Activity Diagram elements

- Actions : 특정 비즈니스 reason을 위해 수행되는 것, 동사와 명사로 표시됨, action은 더 이상 나눠질 수 없다

- Activities : 특정 비즈니스 reason을 위해 수행되는 것, 동사와 명사로 표시됨, activities는 더 나눠질 수 있다.

- Object Nodes : 한 activity에서 다른 activity로의 정보흐름을 나타냄

- Control Flows : 실행 경로를 설계

- Object Flows : object들의 흐름을 설계

- Control Nodes : 여러 activities들중에 어느 activity로 진행 할 것인지 결정하는 node

Control Nodes의 7가지 타입

- initial node : actions/activities의 시작

- final-activity node : actions/activities의 끝

- final-flow node : 한 excution path는 멈추지만 다른 excution path들은 계속 수행되는 node

- decision node : 어떤 path는 계속진행 되고, 어떤 path는 멈추는지 결정하는 node

- merge node : 상호 연관성 없는 path들을 하나로 결합하는 node

- fork node : 하나의 excution path를 한개 이상의 병렬 path들로 나누는 node

- join node : 병렬 excution paths들을 하나로 결합하는 node

Swimlanes

- Activity Diagram의 대표적 형태 중 하나

- object들 마다 어떤 activity를 수행해야 하는지 object마다 나누어서 표현

- object들 사이의 구분된 역활을 나타낸다

- 가로 혹은 세로로 표현될 수 있다.

Guideline for Activity Diagrams

- 설계된 activity의 scope를 정한다.

- activities들을 선언하고, flowsfh activities들을 연결

- control node를 선언하여 어떤 path로 decision을 할지 만든다

- 프로세스에서 parallelism을 만든다.

- Activity Diagram을 그린다

Creating an Activity Diagram

- 요구사항, use-case diagram, documentation을 review하고 business process를 선택한다

- business process에서 사용되는 activities들을 선언

- control flows와 control nodes를 선언

- object flows와 object noodes를 선언

- 레이아웃을 하고 diagram을 그린다. 이때 crossing line을 최소화 하도록 한다

4. Use-case description

정의 : use-case를 표현하는 하는 문서

Elements of Use-case description

1. use-case name : use-case 이름

2. id : use-case의 id 번호

3. importance level : use-case의 중요도

4. primary actor : use-case의 주요 actor

5. use-case type

6. stakeholders and interests : 해당 use-case 사용자들과 그들의 관심

7. brief description : use-case에 대해나 짧은 설명

8. trigger : use-case를 trigger하는 조건상황

9. type

- external = 외부의 actor가 트리거

- internal = 내부의 또다른 use-case가 트리거

10. relationship

- association : 연관관계 -해당 use-case와 연관 있는 actor 또는 다른 use-case

- include : 포함관계

- extend : 확장관계

- generalization : 상속관계

11. normal flow of events : use-case 안에서 일어나는 stepe들. 한 step안에서는 작은 여러 step들 존재 가능

12. subflows : normal flow 외에 수행되는 부가적인 flow

13. alternative/exceptional flows : 필요시, 추가적으로 수행되는 flow

Use-case description 생성과정

1. high prority use-case를 선택하고 overview를 작성

- primary actor 나열

- tpye 결정 : overview 또는 detail / essential 또는 real

- 모든 stakeholders 과 그들의 interests 나열

- use-case의 importance level 결정

- brief description 작성

- 무엇이 use-case를 trigger하는지 나열

- 해당 use-case와 다른 use-case간의 관계 나열

2. normal flows of events의 step들을 작성

3. step들이 너무 복잡하지 않고, 길지 않고, 다른 step들과 일관성있는 사이즈가 있도록 한다

4. alternate/exceptional flow를 결정하고 작성

5. use-case description을 검토하고 올바름을 결정

6. 위의 과정들을 반복 실행

5. Verifying & Validating a use-case

use-case는 structural and behavioral modeling 단계 이전에 검증되어야 한다

지금까지 만들어진 model들과 diagram들을 review한다

사용자와 development team이 같이 검토한다

facilitator : 미팅을 스케쥴을 잡고 진행

presenter : review된 것을 프리젠테이션한다

recorder : review를 기록하고 에러들을 기록한다.

1. Project initiation

project management : 올바른기능, 최소비용, 명시된시간 안에 진행되는 시스템개발을 관리 및 계획하는 프로세스

project manager : task와 role이 잘 조절되도록 관찰 및 관리

Project identification : 프로젝트의 목표, 방향, 결과정의

-project는 비즈니스밸류로부터 도출

business value

tangible value : 셀 수 있고 측정가능한 밸류 (ex: 비용)

intangible value : 셀 수 없고 측정불가능한 밸류 (ex: 사용만족도)

System request

: 새로운 시스템을 만들 때 해당 기능을 가져야하는지 이유와 어떤 가치가 추가되는지를 명세하는 문서.

다음의 5가지 요소 포함

1. Project sponsor : 프로젝트의 일차적인 연락 지점

2. Business need : 프로젝트를 시작하는 이유

3. Business requirements : 상업적 요구사항을 만족 시킬 시스템의 기능

4. Business value : 시스템의 기능으로 하여금 어떻게 사용자들이 가치, 이익을 엊게 될 것인가

5. Special issues : 그외 프로젝트를 진행하면서 고려해야 할 사항.

2. Feasibility Analysis

: 프로젝트에 어떤 리스트가 있고 해당 리스크를 극복할 수 있는지 프로젝트의 실효성 분석

Techinal feasibility

Economic feasibility

3. Organizational feasibility

Techinal feasibility, 기술적 실효성

개발하고자 하는 소프트웨어를 실제로 개발할 수 있는 역량, 기술을 가지고 있는지 분석한다.

이를 위해 다음 4가지 risk를 파악해야 한다.

1. the functional area : 분석가가 소프트웨어가 사용되는 해당 비즈니스 영역에 대해 잘 알고 있는가

2. the technology : 사용하고자 하는 기술을 잘 알고 있는가

3. project size : 프로젝트의 사이즈가 클 수록 더 많은 risk 존재

4. compatibility : 개발하고자 하는 소프트웨어가 사용환경 속에서 다른 소프트웨어들과 호환이 가능한가

Economic feasibility 경제적 실효성

경제적가치가 있는지 분석하기위해 비용(인건비, 자원, 특허권사용)과 이익(매출, 미래가치)을 파악하고 가치를 할당해야한다.

비용과 이익을 파악하여 cashflow(현금흐름)을 산정한다.

가치를 산정하기 위해서는 다음과 같은 방법들이 있다.

1. ROI (Return on Investment) = (total benefits - total costs) / total costs : 투자대비 얼마나 이익을 얻었는가

2. Break-Even Point = (yearly net cash flow - cumulative net cash flow) / yearly net cash flow : 손익분기점

3. Present Value (PV) = cash flow amount / (1 + interest rate)^n (n = number of years in the future) : 현재가치

4. Net Present Value = Σ PV benefits - Σ PV costs : 순현재가치

Organization feasibility, 사회적 실효성

: 사용자에게 잘 받아들여질 것인가 또는 사회에게 소프트웨어가 윤리적, 사회적에서 허용될 수 있는지 분석하는 단계이다.

- Stakeholder analysis : 프로젝트에 의사결정권을 가진 관계자들의 분석

- sponsor : 시스템의 중요성에 대해 다른 관련자들과 의사결정을 논의

- organizational management : 소프트웨어를 사용할 사람들이 잘 받아들이도록 분석

- system user : 실제 사용자들의 의견을 분석하여 반영

3. Project selection

프로젝트는 가치와 리스트에 의해 승인되거나 거절되거나 지연된다

4. Project management tools

workplans을 만드는데 도움을 주는 tool로써

큰 작업을 작은 여러 작업들로 어떻게 나눌지 정의하며 작업들의 순서와 작업소요시간을 결정한다.

Work Breakdown Structures(WBS) 라는 계층적 구조로 나타냄으로써 작업들의 duration, current state, task dependency를 명확히 표현할 수 있다

대표적은 WBS로는 Gantt chart와 PERT가 있다.

Gantt chart는 WBS를 나태내는 수평적인 바 차트로써 작업들의 dependency, duration, current state를 이해하기 쉽게 나타내며

PERT는 diagram으로 표현된 task들을 network형식으로 나타내어 dependeny를 한 눈에 알아볼 수 있다.

5. Project effort estimation

프로젝트의 functionality, time, cost간의 trad-off를 측정하고 프로젝트의 시간과 비용에 대한 value를 할당하는 과정

use-case estimatoin에는 technical complexity factors(13)와 environmental factors(8)존재

6. Creating & Managing the Workplan

workplan : 프로젝트를 완료에 필요한 task들을 변화하고 순차적인 리스트로 표현한 것이다.

workplan은 기존 또는 완료된 프로젝트의 workplan을 변경하여 사용

Structured Development Methodology나 Rapid Application Development Methodology를 적용하여 task들을 생성‘

Work Breakdown Structure (WBS)

전체 프로젝트에서 일관성있게 task들을 조직하고, 반복적이고 증강되는 방식으로 커다란 work를 task 단위로 나누어서 생성하는 구조

과거의 실패나 성공으로부터의 학습을 현재에 적용해 나간다.

Scope Management : task의 사이즈인 "scope"를 관리

scope creep(변화)는 프로젝트가 진행 후 발생하며, 새로운 요구사항을 추가해야 하는 경우가 발생한다.

스케줄상에서 해로운 효과를 가지기 때문에 project manager는 scope creep을 줄이기 위한 노력을 해야한다.

프로젝트 scope 관리 기술

1. 시작단계에서 모든 요구사항 정의

2. 절대적으로 필요한 변화만을 허용

3. 변화에 의한 영향을 면밀히 검사

4. 꼭 필요한 변화가 아니면 다음 버전을 위해 지연

5. time boxing, 시간관리

7. Staffing the project

목표

얼마나 많은 사람이 필요한지 결정

필요한 activity에 맞는 스킬 셋 연결

팀에게 올바른 목표를 설정

갈등 최소화

산출물 : staffin plan (다음의 요소 포함)

어떤 사람이 얼마나 할당되는가

보고체계

project charter 프로젝트 선언

Staffing plan

필요한 사람의 수 = 한사람이 프로젝트 완료하는데 걸리는 시간 / 프로젝트완료 제한기간

Motivating People

motivation은 퍼포먼스에 가장 큰 영향을 준다

돈으로 보상하는 것은 motivate이 되지 않는다

motivateing 기술

사람대 사람간의 친분

팀 오너쉽

멤버들이 흥미있는 것에 집중할 수 있도록한다

공평한 보상

그룹 오너쉽 격려

Handling confilct : 갈등을 예방하고 완하는 것

cohesiveness는 가장 큰 효과 있다

역할을 분명히 하고 팀 멤버들이 책임감 있도록 한다

work 와 커뮤니케이션 규칙을 확립

8. Environment & Infrastructure management

Environment : 올바른 tools을 선택

올바른 CASE tool 사용

생산성증가, 정보 집중화

다이어그램 활용하여 이해도 향상

기준을 확립하여 복잡도 감소

Infrastructure

프로젝트를 올바르게 문서화하여 산출물생성

산출물과 커뮤니케이션을 저장

unified process standart document 이용

1. introduction

시스템?

: 주어진 인풋을 가지고 프로세싱 과정을 거쳐 가치를 창출하고 사용자가 원하는 의미있는 아웃풋을 만드는 것

시스템 제작시 정형화된 제작과정이 필요한 이유?

1. 무작정 만든 프로젝트는 대부분 실패한다.

2. 시스템을 만드는 것은 직관적인 것이 아니다.

3. 프로젝트는 늦어지고, 예산초과되거나 계획보다 적은 기능만 만들어지는 경우가 존재한다.

System Analyst, 시스템분석가? :

가치를 창출하기 위한 시스템 설계하는 사람

비즈니스 프로세스를 반드시 이해해야하는 사람

특정 스킬들이 요구되는 사람

업무를 분석하고 목표를 설정하고 개선시키고 아이디어를 구현하기 위한 정보 시스템을 설계함.

2. SDLC : Systems Developemnt Life Cycle

SDLC : 시스템의 퀄리티를 높이는 것을 목표하는 4단계 순환구조 형태의 시스템개발 생애주기

planning(기획) : 프로젝트 계획

analysis(분석) : 소프트웨어 가치창출을 위해 어떤 기능을 넣을 것인지 요구사항분석하여 결정

design(디자인) : 시스템 개발 작업의 기반이되는 설계도면 작성

implementation(구현) : 설계도면을 가지고 실제로 시스템 제작

SDLC process

프로세스는 4 phases로 구성 : planning -> analysis -> design -> implementation

각각의 phase는 여러 steps들로 구성

각각의 phase는 산출물이 존재 : deliverables(산출물)

phases들은 순차적, 증가적(결과물이 증가), 반복적(수정,보완반복->퀄리티향상)으로 실행됨

Deliverables(산출물)

기획 : 시스템 요구서, 현실성 분석, 작업 계획 보고서

분석 : 시스템 제안서

디자인 : 시스템 설계도면

구현 : 실제 시스템 소스코드, 유지보수 계획

3. SDLC Phases

Planning phase

> 시스템 요구사항, 기술실행 가능성, 경제적 이익 실현성, 사회적 통용가능성등을 파악하여 작업계획을 구성하고,

이를 적절한 개발기간동안 현재의 인적자원 상황에 맞게 적절히 배분하는 계획단계이다.

project initiation

시스템 요구사항확인

feasibility analysis(실효분석) 실행

1. technical feasibility : 기술적으로 구현가능한가

2. economic feasibility : 소프트웨어를 만들었을 때 얼마나 이익을 가져올 것인가

3. organizatoinal feasibility : 소프트웨어가 사회적으로 통용가능한가

project management

workplan 작성

staff the project : 인적자원의 보유기술, 프로젝트 참여현황 파악

프로젝트 진행현황 파악

Analysis Phase : 가치창출을 위해 소프트웨어를 분석하고 어떤 기능을 넣을지 결정하는 단계

develop an analysis strategy : 분석전략 수립

model the current system : 현재 시스템 파악하여 추보완점파악

formulate the new system : 새로 추가할 기능 파악

2. gather the requirements : 사용자/개발자/관계자들의 요구사항수집

develop a system concept : 시스템 컨셉정의

create a business model to represent : 비즈니스모델 정의

3. develop a system proposal : 시스템 제안서(산출물) 작성

Design phase : 시스템개발작업의 기반이되는 설계도면 작성

develop a design strategy : 설계전략수립

design architecture and interfaces : 시스템의 구조와 인터페이스 설계

develop databases and file specifications : 데이터베이스 및 파일형식 개발

develop the program design to specify : 프로그램설계 명시

Implementation phase : 설계도면을 가지고 실제로 구현하는 단계

construct the system

- 구현

- 테스트

install system

- 사용자 교육

3. 유지보수

4. SDLC Methodologies

정의 : SDLC를 구현하기 위한 정형화된 방법론

- 시스템 목적, 특징에 따라 적합하게 사용할 수 있는 여러가지 방법론이 존재한다.

1. Process oriented : input을 받아 output을 만드는 작업, 소프트웨어의 모듈, 프로세스에 초점을 둔 방법론

2. Data centered : 어떻게 가공하여 의미있는 데이터를 만들지와 같은 데이터에 초점을 둔 방법론

3. Object-oriented : 객체지향개념(객체, 객체의 메서드, 객체간 상호작용 등)을 적용한 방법론

4. Structured development : SDLC의 phases와 각 phase의 steps들의 구조에 초점을 둔 방법론

5. Rapid actoin development : 빠른 개발 진행, 빠른 새 요구사항 대처등에 초점을 둔 방법론

Structured development

- Waterfall Development

- Parallel Development

Waterfall Development

- Planning -> Analysis -> Design -> Implementation 과정을 시간 순차적으로 진행하는 방법

- 전단계가 끝나고 다음단계로 넘어가면 다음단계에서 발견한 오류나 수정할 점을 전단계에 피드백하는 것이 아니라 해당단계에서 수정 보완을 해야 하는 특징이 있다.

장점 : 시스템 요구사항을 분명히 할 수 있다. 프로젝트 진행에서 요구사항의 변경이 최소화 된다

- 단점 : 디자인이 설계도면에 매우 세부적으로 명시되어야 한다. 시스템 제안부터 출시까지 긴 시간이 걸린다

Parallel Development

- Planning -> Analysis -> Design -> Implementation 과정 중 design 단계에서 여러 subproject들로 나뉘어 병렬적으로 프로젝트를 진행하고 각각의 subproject들의 implementation을 통합하는 방식

- 전단계가 끝나고 다음단계로 넘어가면 다음단계에서 발견한 오류나 수정할 점을 전단계에 피드백하는 것이 아니라 해당단계에서 수정 보완을 해야 하는 특징이 있다.

장점 : 스케줄시간이 감소된다. 재작업의 확률이 줄어든다

단점 : subproject들을 병합하는데 어려움이 있을 수 있다.

Rapid Action Development Methodology는

- 빨리 개발과정을 진행하여, 빠르게 시스템을 완성하는 것을 목표로하는 방법론으로 요구사항이 자주변하거나, 출시날짜가 임박한 경우에 주로 적용된다.

1. Phased Development Methodolgy

2. Prototyping

3. Thoroway Prototyping

Phased Development Methodolgy

기능의 우선순위를 매겨 코어 기능을 탑재된 시스템을 우선적으로 만들어서 낮은 버전으로 출시하는 방법론

낮은 버전 출시이후 받은 피드백은 다음버전에 반영하여,다음 버전은 좀 더 다양한 기능들이 탑재되고 이전버전의 결점이 보완된 상태로 출시된다.

장점 : user가 시스템을 빨리 이용가능. user의 추가적인 요구를 다음버전에 반영가능

단점 : user가 이용하는 시스템은 불완전한 시스템

Prototyping

시스템(완제품) 만들기전 시스템프로토타입(반제품, system의 코어기능은 탑재되어 있지만 UI가 완벽하게 구현되지 않은 소프트웨어)을 미리 만드는 방법론

- 프로토타입에서 부족한 부분은 피드백되어 수정 보완되고 이런 과정이 계속 반복되어 원하는 기능과 퀄리티가 만족되면 실제 시스템을 만든다.

장점 : user가 프로토타입을 빨리 사용해 볼 수 있어 상호작용을 빠르게 해볼 수 있다.
user가 필요한 변경사항을 확인하여 실제 요구사항을 제시할 수 있다

단점 : 초기 디자인의 퀄리티가 떨어질 수 있다.

Thoroway Prototyping

“디자인 프로토타입”을 만듬으로써 완벽한 설계도면을 만드는것을 목표로하여 완성된 디자인프로토타입으로

디자인을 하고 해당 디자인으로 시스템을 만드는 방법론

장점 : 시간적, 비용적,기술적등 리스크를 최소화. 실제 시스템이 만들어지기 전에, 중요한 이슈들을 미리 알수 있다.

적절한 방법론을 선택하는 기준

-> 사용자 요구사항을 분명히 함.

제작에 필요한 기술을 확보할 수 있는가?

시스템의 복잡도는 어떠한가?

시스템의 신뢰도는 얼마나 중요한가?

시간을 얼마나 주어졌는가?

스케쥴을 예측할 수 있는가?

5. the Systems Analyst

- 변화에 잘 적응하는 사람으로써, 유저들의 기술적 역량등을 향상시키기 위한 방법들을 분명히하고 소프트웨어를 사용하도록 권장하며 교육시킨다.

Systems Analyst skills

technical skills : 기술을 이해해야 한다

business : 비즈니스 프로세스를 알아야 한다

analytical : 문제해결을 할수있는 분석적 역량

communications : 상대방이 기술을 잘 알든 모르든 상관없이 잘 소통할 수 있는 커뮤니케이션 역량

interpersonal : 리더쉽과 관리능력

ethics : 윤리적역량

Systems Analyst 역활

Business analyst : 시스템이 어떻게 비즈니스 밸류를 창출할지 찾고 새로운 비즈니스 프로세스와 정책을 설계

Systems analyst : 어떻게 기술이 비즈니스 프로세스를 향상시킬수 있을지 파악. 새로운 비즈니스 프로세스를 설계

Infrastructure analyst : 시스템이 인프라 표준에 부합하도록 해야하며, 인프라변화가 있더라도 시스템이 잘 적응하도록 해야한다.

Change management analyst : 프로젝트 진행중 발생하는 변경사항들을 관리, 유저 훈련 계획 개발 및 집행

Project manager : 프로젝트를 총괄하여 관리하는 사람 (스케쥴 설정, 작업 분배)

6. Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design

- Object-Oriented System을 UML을 이용하여 분석하는 방법론

use-case를 분석 : 유저가 어떻게 시스템을 사용하는가

구조 분석 : 객체간의 상화관계 분석

반복적, 증가적 분석 : 데이터와 프로세스를 반복적으로 추가하여 더 많은 기능들이 제공됨

Object-Oriented Systems

클래스

object : 클래스의 instance

attribute :　클래스의 속성

state : 특정시간에 클래스가 가지고 있는 value, 관계

2. methode, message

methode : 클래스의 행동

message : 한 object에서 다른 object로 전달되는 정보

3. encapsulation

- encapsulation : 데이터와 프로세스를 결합

information hiding : 외부에서 클래스의 기능성이 보이지 않는다

4. inheritance

: 서브클래스는 슈퍼클래스의 데이터와 methode를 상속받을 수 있다.

7. Engineering workflows

business modeling

requirement

analysis

design

implementation

testing

deployment – 유지보수

8. UML : Unified Modeling Language

UML, Unified Modeling Language

시스템 개발 과정에서, 개발자간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어

총 14개의 다이어그램이 다음과 같이 2 그룹으로 나누어진다.

1. Structure diagrams : 소프트웨어의 구조를 중점적으로 나타냄 (6개)

2. Behavior diagrams : 소프트웨어의 행동을 중점적으로 나타냄 (8개)

Structure diagrams

시스템의 data와 staric realationships을 표현하는 다이어그램들로 다음과 같이 6개의 diagrams이 속한다

1. class : 객체 내부의 속성과 메서드를 정리하여 정의한 것

2. object : 클래스를 인스턴스화 한 것

3. package : 비슷한 object들의 그룹

4. deployment : 소프트웨어가 작동하는 환경

5. component : input을 받아 내부에서 프로세싱을 하고 output을 출력하는 모듈

6. composite structure : component들로 구성된 구조

Behavior diagrams

object들 사이의 dynamic relationships을 나타내는 다이어그램들로 다음과 같이 8개의 diagram이 속한다

1. activity : 어떤 object의 행동을 나타냄

2. sequence : 여러 object들의 연속적인 행동들을 나타냄

3. communication : object들간의 연결 관계를 나타냄

4. interaction overview : object들간의 action을 통한 데이터 송수신

5. timing : 순서, 시간적인 개념

6. behavior state machine : 하나의 object에서 내부상태에 따른 행동양상을 나타냄

7. protocol state machine : 여러 object들 사이의 상태에 따른 행동양상을 나타냄

8. use-case diagrams : 사용예제로 어떤 기능을 어떻게 사용하는 나타냄