\documentclass[10pt,a4paper]{article}

% Packages
\usepackage{fancyhdr}           % For header and footer
\usepackage{multicol}           % Allows multicols in tables
\usepackage{tabularx}           % Intelligent column widths
\usepackage{tabulary}           % Used in header and footer
\usepackage{hhline}             % Border under tables
\usepackage{graphicx}           % For images
\usepackage{xcolor}             % For hex colours
%\usepackage[utf8x]{inputenc}    % For unicode character support
\usepackage[T1]{fontenc}        % Without this we get weird character replacements
\usepackage{colortbl}           % For coloured tables
\usepackage{setspace}           % For line height
\usepackage{lastpage}           % Needed for total page number
\usepackage{seqsplit}           % Splits long words.
%\usepackage{opensans}          % Can't make this work so far. Shame. Would be lovely.
\usepackage[normalem]{ulem}     % For underlining links
% Most of the following are not required for the majority
% of cheat sheets but are needed for some symbol support.
\usepackage{amsmath}            % Symbols
\usepackage{MnSymbol}           % Symbols
\usepackage{wasysym}            % Symbols
%\usepackage[english,german,french,spanish,italian]{babel}              % Languages

% Document Info
\author{kniz}
\pdfinfo{
  /Title (programming-architecture.pdf)
  /Creator (Cheatography)
  /Author (kniz)
  /Subject (Programming Architecture Cheat Sheet)
}

% Lengths and widths
\addtolength{\textwidth}{6cm}
\addtolength{\textheight}{-1cm}
\addtolength{\hoffset}{-3cm}
\addtolength{\voffset}{-2cm}
\setlength{\tabcolsep}{0.2cm} % Space between columns
\setlength{\headsep}{-12pt} % Reduce space between header and content
\setlength{\headheight}{85pt} % If less, LaTeX automatically increases it
\renewcommand{\footrulewidth}{0pt} % Remove footer line
\renewcommand{\headrulewidth}{0pt} % Remove header line
\renewcommand{\seqinsert}{\ifmmode\allowbreak\else\-\fi} % Hyphens in seqsplit
% This two commands together give roughly
% the right line height in the tables
\renewcommand{\arraystretch}{1.3}
\onehalfspacing

% Commands
\newcommand{\SetRowColor}[1]{\noalign{\gdef\RowColorName{#1}}\rowcolor{\RowColorName}} % Shortcut for row colour
\newcommand{\mymulticolumn}[3]{\multicolumn{#1}{>{\columncolor{\RowColorName}}#2}{#3}} % For coloured multi-cols
\newcolumntype{x}[1]{>{\raggedright}p{#1}} % New column types for ragged-right paragraph columns
\newcommand{\tn}{\tabularnewline} % Required as custom column type in use

% Font and Colours
\definecolor{HeadBackground}{HTML}{333333}
\definecolor{FootBackground}{HTML}{666666}
\definecolor{TextColor}{HTML}{333333}
\definecolor{DarkBackground}{HTML}{A3A3A3}
\definecolor{LightBackground}{HTML}{F3F3F3}
\renewcommand{\familydefault}{\sfdefault}
\color{TextColor}

% Header and Footer
\pagestyle{fancy}
\fancyhead{} % Set header to blank
\fancyfoot{} % Set footer to blank
\fancyhead[L]{
\noindent
\begin{multicols}{3}
\begin{tabulary}{5.8cm}{C}
    \SetRowColor{DarkBackground}
    \vspace{-7pt}
    {\parbox{\dimexpr\textwidth-2\fboxsep\relax}{\noindent
        \hspace*{-6pt}\includegraphics[width=5.8cm]{/web/www.cheatography.com/public/images/cheatography_logo.pdf}}
    }
\end{tabulary}
\columnbreak
\begin{tabulary}{11cm}{L}
    \vspace{-2pt}\large{\bf{\textcolor{DarkBackground}{\textrm{Programming Architecture Cheat Sheet}}}} \\
    \normalsize{by \textcolor{DarkBackground}{kniz} via \textcolor{DarkBackground}{\uline{cheatography.com/123738/cs/23432/}}}
\end{tabulary}
\end{multicols}}

\fancyfoot[L]{ \footnotesize
\noindent
\begin{multicols}{3}
\begin{tabulary}{5.8cm}{LL}
  \SetRowColor{FootBackground}
  \mymulticolumn{2}{p{5.377cm}}{\bf\textcolor{white}{Cheatographer}}  \\
  \vspace{-2pt}kniz \\
  \uline{cheatography.com/kniz} \\
  \end{tabulary}
\vfill
\columnbreak
\begin{tabulary}{5.8cm}{L}
  \SetRowColor{FootBackground}
  \mymulticolumn{1}{p{5.377cm}}{\bf\textcolor{white}{Cheat Sheet}}  \\
   \vspace{-2pt}Published 24th June, 2020.\\
   Updated 24th June, 2020.\\
   Page {\thepage} of \pageref{LastPage}.
\end{tabulary}
\vfill
\columnbreak
\begin{tabulary}{5.8cm}{L}
  \SetRowColor{FootBackground}
  \mymulticolumn{1}{p{5.377cm}}{\bf\textcolor{white}{Sponsor}}  \\
  \SetRowColor{white}
  \vspace{-5pt}
  %\includegraphics[width=48px,height=48px]{dave.jpeg}
  Measure your website readability!\\
  www.readability-score.com
\end{tabulary}
\end{multicols}}




\begin{document}
\raggedright
\raggedcolumns

% Set font size to small. Switch to any value
% from this page to resize cheat sheet text:
% www.emerson.emory.edu/services/latex/latex_169.html
\footnotesize % Small font.

\begin{multicols*}{3}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - 추상팩토리}}  \tn
% Row 0
\SetRowColor{LightBackground}
개요 & 구체적인 서브클래스들을 의존하지 않고, 여러 클래스 집단을 생성하기 위한 인터페이스 \tn 
% Row Count 4 (+ 4)
% Row 1
\SetRowColor{white}
언제 & 객체들이 생성되는 것을 변경하게 하고 싶을 때, 관련된 여러 객체들이 함께 사용되어야 할 때, 여러 Product 군 중에서 하나를 선택해야 할때 \tn 
% Row Count 10 (+ 6)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & AbstactFactory, ConcreteFactory, AbstractProduct, ConcreteProduct,Client \tn 
% Row Count 13 (+ 3)
% Row 3
\SetRowColor{white}
장점 & 구체 클래스를 client에서 분리, Product 그룹을 쉽게 교체, Product 그룹의 객체들 간의 일관성 \tn 
% Row Count 17 (+ 4)
% Row 4
\SetRowColor{LightBackground}
단점 & 전혀다른 새로운 제품 제공이 어렵다. \tn 
% Row Count 19 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - 빌더}}  \tn
% Row 0
\SetRowColor{LightBackground}
언제 & 복잡한 객체들을 생성하는데 그 객체가 하나의 ADT로 나올 수 있을 때, 객체의 생성방법이 복잡하지만 동일한 생성API를 제공하고 싶을 때 \tn 
% Row Count 6 (+ 6)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Builder=생성API, \seqsplit{ConcreteBuilder=실제생성}, Director=생성workflow, Product=제품의ADT \tn 
% Row Count 9 (+ 3)
% Row 2
\SetRowColor{LightBackground}
장점 & Product의 생성 로직을 변경할 수 있다, 생성과 Product 클래스를 코드 분리 \tn 
% Row Count 12 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.34379 cm} x{3.63321 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{추상팩토리 vs 빌더}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{추상팩토리} & 확장성에 관심, 매 생성시마다 객체가 나옴 \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
빌더 & 복잡한 객체 생성을 단계별로 쪼개는 데 관심, 내부적으로 모든 작업이 끝난 뒤, 마지막에 하나의 객체가 생성 됨 \tn 
% Row Count 8 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - 책임 연쇄}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐냐 & UI event handling \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
언제 & msg receiver들이 다수로 구성되어있고 누가 처리할 지 모를때, msg를 누가 처리할지 정하고 싶지 않을때 \tn 
% Row Count 6 (+ 5)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Handler(다른 Handler를 링크), ConcreteHandler \tn 
% Row Count 8 (+ 2)
% Row 3
\SetRowColor{white}
장점 & msg receiver, sender의 결합이 낮아짐(= 동적으로 삭제/추가해도 무방하다는 것) \tn 
% Row Count 12 (+ 4)
% Row 4
\SetRowColor{LightBackground}
단점 & msg가 반드시 처리되지는 않음, \tn 
% Row Count 14 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - 반복자}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐냐 & Container의 구조를 노출하지 않고 구성요소를 순회하게 하는 것 \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
언제 & container의 내부구조를 노출하고 싶지 않을 때, 구성 요소를 순회하는 단일 API를 제공하고 싶을 때, 순회방법을 여러개 추가하고 싶을때 \tn 
% Row Count 9 (+ 6)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Aggregate(Container ADT), ConcreteAggregator, Iterator, ConcreteIterator \tn 
% Row Count 12 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Command}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐냐 & 요청을 객체화 \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
언제 & 요청을 지연하거나, 요청을 분산처리, 요청을 되돌리거나 \tn 
% Row Count 4 (+ 3)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Command(요청의 API), ConcreteCommand, Invoker(명령을 하나씩 처리), Receiver(client에게 알려줌) \tn 
% Row Count 8 (+ 4)
% Row 3
\SetRowColor{white}
장점 & 요청 추가가 쉽다, 요청을 지연,분산,undo 가능 \tn 
% Row Count 10 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - 팩토리메소드}}  \tn
% Row 0
\SetRowColor{LightBackground}
언제 & 객체의 생성 시점을 client가 정해야 할때, 어떤 클래스를 생성해야 하는지는 서브클래스가 정하게 하고 싶을때 \tn 
% Row Count 5 (+ 5)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Product, ConcreteProduct, Creator, ConcreteCreator \tn 
% Row Count 7 (+ 2)
% Row 2
\SetRowColor{LightBackground}
장점 & 생성될 객체를 외부에서 변경할 수 있다. \tn 
% Row Count 9 (+ 2)
% Row 3
\SetRowColor{white}
단점 & Product와 Creator 양쪽에 서브클래스를 하게 된다. \tn 
% Row Count 11 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Adapter}}  \tn
% Row 0
\SetRowColor{LightBackground}
언제 & 어느 클래스의 인터페이스를 client가 원하는 인터페이스로 변경해야 할 때, 그런데 그 클래스를 수정할 수는 없을 때 \tn 
% Row Count 5 (+ 5)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & ObjectAdapter(위임), \seqsplit{ClassAdpater(다중상속)} 2개 버전이 있다. Target=사용자가 바라보는 인터페이스, Adapter, Adaptee(문제아) \tn 
% Row Count 10 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{X}
\SetRowColor{DarkBackground}
\mymulticolumn{1}{x{5.377cm}}{\bf\textcolor{white}{Adapter vs Proxy}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{1}{x{5.377cm}}{Adapter는 기존과 다른 interface로 변형 vs proxy는 realSubject와 동일한 인터페이스를 redirection} \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
\mymulticolumn{1}{x{5.377cm}}{Proxy는 객체에 대한 접근을 관리하는 것.} \tn 
% Row Count 5 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}-}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - 브릿지}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐냐 & 구현과 추상을 분리해서 서로 조합하게 함. \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
언제 & 추상과 구현을 분리할 때, 구현을 런타임에 변경하고 싶을 때, \tn 
% Row Count 5 (+ 3)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Abstraction, \seqsplit{RefinedAbstraction(확장된} client가 사용할 API), Implementor(구현부의 ADT), ConcreteImplementor \tn 
% Row Count 9 (+ 4)
% Row 3
\SetRowColor{white}
장점 & 구현이 인터페이스에 얽매이지 않게 됨, 추상과 구현을 각각 확장 가능,상세한 구현을 숨김 \tn 
% Row Count 13 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{X}
\SetRowColor{DarkBackground}
\mymulticolumn{1}{x{5.377cm}}{\bf\textcolor{white}{Adapter vs Bridge}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{1}{x{5.377cm}}{구조적으로는 서로 똑같음. 목적이 다르다. client가 사용할 수 있도록 인터페이스를 맞추는 것. Bridge는 추상과 구현이 얽매이지 않도록 함.} \tn 
% Row Count 4 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}-}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Mediator}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐냐 & 복합객체의 workflow를 확장할 수 있도록 한 객체에 몰아주는 것. \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
언제 & 메소드 안에 복합객체가 여러 객체들간 interaction이 존재할 때, 각 객체들이 다른 객체와 많은 분산된 interaction이 존재할 때 \tn 
% Row Count 9 (+ 6)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Mediator, ConcreteMediator, Colleague, ConcretreColleague \tn 
% Row Count 11 (+ 2)
% Row 3
\SetRowColor{white}
장점 & 다른 객체를 접근하고 제어하는 코드는 모두 Mediator에 통합, 다른 객체들 간의 종속성을 줄어듬, 제어가 중앙집중적, Mediator를 상속해서 제어를 쉽게 수정 \tn 
% Row Count 18 (+ 7)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{X}
\SetRowColor{DarkBackground}
\mymulticolumn{1}{x{5.377cm}}{\bf\textcolor{white}{Facade vs Mediator}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{1}{x{5.377cm}}{Facade는 편한 Interface 사용이 목적 vs Mediator는 객체간 interaction을 가운데서 통제하자.} \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
\mymulticolumn{1}{x{5.377cm}}{Facade는 새로운 객체 추가하려면 수정 필요 vs Mediator는 필요 없음.} \tn 
% Row Count 5 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}-}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - State}}  \tn
% Row 0
\SetRowColor{LightBackground}
언제 & 객체의 상태에 따라서 런타임에 행동이 달라져야 할때, if-else가 가 너무 많을때 \tn 
% Row Count 4 (+ 4)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Context(client의 API), State, ConcreteState \tn 
% Row Count 6 (+ 2)
% Row 2
\SetRowColor{LightBackground}
장점 & 특정 state와 관련된 코드를 별도로 모아둘 수 있다, State를 명확하게 구분하고 state전이를 두드러지 게 한다. \tn 
% Row Count 11 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Composite}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐냐 & 객체의 트리구조를 하나의 클래스로 구성하는 것 \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
언제 & 트리구조를 만들어야 하는데, 모든 구성요소를 하나의 API로 다룰 수 있도록 하고 싶을때 \tn 
% Row Count 7 (+ 4)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Component(client가 사용하는 객체 합성 API를 가짐), Leaf(합성이외에 객체를 행동을 정의), Composite(자식을 Component르 가질 수 있도록 API를 구현함) \tn 
% Row Count 13 (+ 6)
% Row 3
\SetRowColor{white}
장점 & client 코드가 단순해짐, 일관된 클래스 hierarchy가 나옴 \tn 
% Row Count 16 (+ 3)
% Row 4
\SetRowColor{LightBackground}
단점 & 너무 범용적이라 특수화 된 코드를 넣기가 어려움(자식을 1개만 두고 싶다, 새로운 메소드 추가 등) \tn 
% Row Count 21 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.64701 cm} x{4.32999 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Visitor}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{뭐냐} & 복합객체의 구조와 코드를 유지하면서 외부에서 그 요소에 대한 연산을 수행할 수 있다. \tn 
% Row Count 4 (+ 4)
% Row 1
\SetRowColor{white}
\seqsplit{언제} & 객체의 구조의 요소들이 서로 다른 클래스일 때, 클래스마다 다른 연산을 적용해야 할때, 해당 클래스들은 코드 수정하고 싶지 않을때, 이러한 추가 연산이 앞으로도 또 일어날 때 \tn 
% Row Count 11 (+ 7)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{구조} & Visitor, ConcreteVisitor, Element, ConcreteElement \tn 
% Row Count 13 (+ 2)
% Row 3
\SetRowColor{white}
\seqsplit{장점} & 새로운 연산을 쉽게 추가한다, 관련 연산을 추가할때 한군데에 모아둘 수 있다 \tn 
% Row Count 17 (+ 4)
% Row 4
\SetRowColor{LightBackground}
\seqsplit{단점} & 새로운 ConcreteElement 추가하면 모든 Visitor를 다 수정해야 한다. \tn 
% Row Count 20 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Observer}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{참여자} & Subject(여러개의 Observer를 가지며, notify()가 불려지면 observer들에게 통보한다), ConcreteSubject, Observer, \seqsplit{ConcreteObserver(subject로부터} 상태가 변경되었다고 받으면 ConcreteSubject에게 notify 한다.) \tn 
% Row Count 8 (+ 8)
% Row 1
\SetRowColor{white}
장점 & 1:N 의 sender, receiver 구조를 가질 수 있다, 동적으로 변경할 수 있다, \tn 
% Row Count 11 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{패턴 - Strategy}}  \tn
% Row 0
\SetRowColor{LightBackground}
언제 & 동적으로 알고리즘 교체, 클래스가 같아도 알고리즘은 달라야 할때, 알고리즘의 추가를 고려할때 \tn 
% Row Count 5 (+ 5)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Context(client의 API), Strategy, ConcreteStategy \tn 
% Row Count 7 (+ 2)
% Row 2
\SetRowColor{LightBackground}
장점 & 상속을 사용하지 않으므로 알고리즘을 변경하기 위해서 서브클래싱을 찍어내는 걸 안해도 된다, 조건문이 사라짐, 동적으로 알고리즘 선택 \tn 
% Row Count 13 (+ 6)
% Row 3
\SetRowColor{white}
단점 & 사용자가 각 전략들이 무엇인지 알고있어야 한다, 어떠한 ConcreteStategy는 Stategy로 넘어온 인자가 필요없는 오버헤드가 있을 수 있다, 객체 수가 증가한다. \tn 
% Row Count 20 (+ 7)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.9954 cm} x{3.9816 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{SOLID - Single Responsibility Principle}}  \tn
% Row 0
\SetRowColor{LightBackground}
정의 & 한 클래스는 하나의 책임만 가져야 한다. \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
\seqsplit{안되면}? & 책임이 결합된다. 분리되어 있으면 일부만 수정한 부분을 조합해서 재사용이 가능했을 것이다. \tn 
% Row Count 6 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.64701 cm} x{4.32999 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{SOLID - Open Closed Principle}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{정의} & 확장에 열려있고, 수정에 닫혀있어야 한다. \tn 
% Row Count 2 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.4977 cm} p{0.4977 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{SOLID - Liskov substituion principle}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{2}{x{5.377cm}}{} \tn 
% Row Count 0 (+ 0)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.4931 cm} x{3.4839 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{SOLID - Interface Segregation principle}}  \tn
% Row 0
\SetRowColor{LightBackground}
뭐야? & 사용자가 사용하지 않는 메소드에 의존하도록 해서는 안된다. \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
어떻게 해결? & 다중 상속 (mixin, interface), Delegation \tn 
% Row Count 5 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.74655 cm} x{4.23045 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{SOLID - Dependency Inversion Principle}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{뭐야}? & '구현에 의존하지 말고, 추상화에 의존하자. 상위 수준(ADT)은 \seqsplit{하위수준(구체클래스)에} 의존해서는 안된다. \tn 
% Row Count 5 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{X}
\SetRowColor{DarkBackground}
\mymulticolumn{1}{x{5.377cm}}{\bf\textcolor{white}{Coupling vs Cohension}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{1}{x{5.377cm}}{결합도 -\textgreater{} 코드가 딱 붙어 의존상태가 강한 정도 (상속, Composition, 등) 낮을수록 좋다} \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
\mymulticolumn{1}{x{5.377cm}}{응집도 -\textgreater{} 클래스가 하나의 책임에 대해 관련 있는 코드만 잘 모여져 있는가. 관련 없는 메소드가 많이 모여 있거나, 책임이 너무 많이 모여있으면 응집도가 떨어진다.} \tn 
% Row Count 8 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}-}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.9908 cm} x{2.9862 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학}}  \tn
% Row 0
\SetRowColor{LightBackground}
요구공학 & System Service (FR)과 Context(NFR)을 찾고 정리하는 것 \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
SDLC의 종류 & Water fall, Incremental, Evolutionary, Spiral Iterative, Agile, RUP \tn 
% Row Count 6 (+ 3)
% Row 2
\SetRowColor{LightBackground}
RUP의 프로세스 & Inception, elaboration, construction, transition \tn 
% Row Count 8 (+ 2)
% Row 3
\SetRowColor{white}
Incremental의 프로세스 & RE는 RE만, code 팀은 code만, Test팀은 Test만 파이프라인 처럼 \tn 
% Row Count 12 (+ 4)
% Row 4
\SetRowColor{LightBackground}
Validation vs Verification & Verification은 명세대로 했는가, Validation은 명세가 올바른가 \tn 
% Row Count 16 (+ 4)
% Row 5
\SetRowColor{white}
RE의 과정 & Feasibility Test \textgreater{} RE Elicitation \textgreater{} Req Specification \textgreater{} Req Validation \tn 
% Row Count 19 (+ 3)
% Row 6
\SetRowColor{LightBackground}
Elicitation & System model을 만들고 Workshop, Brainstorming, survey, interview, role playing, prototyping 등을 해서  요구사항을 뽑아낸다. \seqsplit{Prioritization\&Negotiation으로} NFR에 대해 점수를 메긴다. (FR은 반드시 해야 하므로 필요없다) \tn 
% Row Count 30 (+ 11)
\end{tabularx}
\par\addvspace{1.3em}

\vfill
\columnbreak
\begin{tabularx}{5.377cm}{x{1.9908 cm} x{2.9862 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 (cont)}}  \tn
% Row 7
\SetRowColor{LightBackground}
Negotiation & 요구사항의 우선순위 측정은 ranking, ahp, grouping, bubble sort, hundred dollors \tn 
% Row Count 4 (+ 4)
% Row 8
\SetRowColor{white}
Specification & 뽑아낸 요구사항을 분류 / 조직화한다. \tn 
% Row Count 7 (+ 3)
% Row 9
\SetRowColor{LightBackground}
SRS & Software Requirement Specification (요구사항 최종 산출물). 설계나 Plan이 들어있으면 안된다. \tn 
% Row Count 12 (+ 5)
% Row 10
\SetRowColor{white}
Validation & 최종 검증 (프로토타이핑 등) \tn 
% Row Count 14 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{2.23965 cm} x{2.73735 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 - QA - Functionality}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Suitability(적합성)} & 지정된 작업과 사용자 목적에 따라 적절한 기능들을 제공 \tn 
% Row Count 4 (+ 4)
% Row 1
\SetRowColor{white}
Accuracy & 올바른 결과를 얼마나 잘 제공할 수 있는가 \tn 
% Row Count 7 (+ 3)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{Interoperability(상호운영성)} & 다른 시스템과 interaction 할 수 있는 정도 \tn 
% Row Count 10 (+ 3)
% Row 3
\SetRowColor{white}
Security & 권한이 없는 사람의 접근을 막거나, 데이터의 변조를 막거나, 권한있는 사람이 허용되게 하는 것 \tn 
% Row Count 16 (+ 6)
% Row 4
\SetRowColor{LightBackground}
\seqsplit{Compliance(준수성)} & SW 관련된 법적 규제, 관례, 규정을 준수하는 정도 \tn 
% Row Count 19 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{2.18988 cm} x{2.78712 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 - QA - Reliability}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Maturity(성숙성)} & SW 결함이 발생하여 고장이 나지 않도록 하는 정도 \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
Fault \seqsplit{Tolerance(결함허용성)} & 결함이 발생하여도, 명세한 성능을 유지할 수 있는 정도 \tn 
% Row Count 7 (+ 4)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{Recoverability(복구성)} & 고장 발생시, 명세된 성능으로 다시 돌아가고 영향받은 데이터를 복구 하는 능력 \tn 
% Row Count 12 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{2.04057 cm} x{2.93643 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 - QA - Usability}}  \tn
% Row 0
\SetRowColor{LightBackground}
Usability & 사용자가 쉽게 이해하고 학습하고 사용되고 선호하는 정도 \tn 
% Row Count 4 (+ 4)
% Row 1
\SetRowColor{white}
\seqsplit{Understandability(이해성)} & 소프트웨어가 적합한지, 어떻게 사용해야 하는지 사용자가 쉽게 이해하는가? \tn 
% Row Count 9 (+ 5)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{Learnability(학습성)} & 사용자가 쉽게 배울 수 있도록 도와주는 능력 \tn 
% Row Count 12 (+ 3)
% Row 3
\SetRowColor{white}
\seqsplit{Operability(운영성)} & 사용자가 SW를 쉽게 운영/관리 하게 할 수 있는가? \tn 
% Row Count 15 (+ 3)
% Row 4
\SetRowColor{LightBackground}
\seqsplit{Attractiveness(선호도)} & 사용자에 의해 선호되는 정도 \tn 
% Row Count 17 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{2.43873 cm} x{2.53827 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 - QA - Effectivness}}  \tn
% Row 0
\SetRowColor{LightBackground}
Effectiviness & 명세된 조건하에서 얼마나 자원을 덜 사용하여 높은 성능을 내는가? \tn 
% Row Count 5 (+ 5)
% Row 1
\SetRowColor{white}
\seqsplit{TimeBehavior(시간} 반응성) & 명세된 조건하에서 처리시간과 처리율이 얼마나 빠르고 좋은가? \tn 
% Row Count 10 (+ 5)
% Row 2
\SetRowColor{LightBackground}
Resource Utilization(자원 활용성) & 기능을 수행하기 위해서 얼마나 덜 자원을 사용하는가 \tn 
% Row Count 14 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.89126 cm} x{3.08574 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 - QA - Maintainability}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Analyzability(분석성)} & SW 결함의 원인을 진단하는 능력 \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
\seqsplit{Changeability(변경성)} & 명세가 변경되었을때 쉽게 구현하는 정도 \tn 
% Row Count 5 (+ 3)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{Stability(안정성)} & SW 변경으로 예상치 않은 결과가 잘 발생하지 않게 하는 정도 \tn 
% Row Count 9 (+ 4)
% Row 3
\SetRowColor{white}
Testability & 변경된 SW를 검사할 수 있는 능력 \tn 
% Row Count 11 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.89126 cm} x{3.08574 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{요구공학 - QA - Portability}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Adaptability(적응성)} & SW에서 원래 목적으로 제공되는 것 이외에 다른 환경으로 변경될 수 있는 정도 \tn 
% Row Count 5 (+ 5)
% Row 1
\SetRowColor{white}
\seqsplit{Installability(설치성)} & 명세된 환경에 설치가 얼마나 쉬운가 \tn 
% Row Count 8 (+ 3)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{Co-existency(공존성)} & 공통 자원을 공유해야 하는 환경에 설치될 경우, 다른 SW와 같이 공존하는 정도 \tn 
% Row Count 13 (+ 5)
% Row 3
\SetRowColor{white}
\seqsplit{Replaceability(대체성)} & 동일한 환경에서 같은 목적인 SW들과 대체가 얼마나 쉬운가 \tn 
% Row Count 17 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.44333 cm} x{3.53367 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Viewpoints 4+1}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Viewpoints?} & 시스템을 바라보는 관점. View는 그 관점에서 시스템의 요소를 도식화 한것. Logical Views는 구조를, Process View는 흐름, 즉 런타임 동작을, Development는 개발팀의 산출물 (패키지, 코드 위치등)을, Deployment는 최종 시스템 요소의 물리적인 설치를 \tn 
% Row Count 12 (+ 12)
% Row 1
\SetRowColor{white}
Use-Case view & Activity/Info Flow Diagram, UseCase diagram \tn 
% Row Count 14 (+ 2)
% Row 2
\SetRowColor{LightBackground}
Logical View & Sequence Diagram, Domain Model Class Diagram \tn 
% Row Count 16 (+ 2)
% Row 3
\SetRowColor{white}
\seqsplit{Development} view & component diagram, package diagram \tn 
% Row Count 18 (+ 2)
% Row 4
\SetRowColor{LightBackground}
Domain Model? & RE 에서 요구사항 분석을 위한 Conceptual class diagram. \tn 
% Row Count 21 (+ 3)
% Row 5
\SetRowColor{white}
Process view & sequence, activity diagram \tn 
% Row Count 23 (+ 2)
% Row 6
\SetRowColor{LightBackground}
Physical view & deployment diagram \tn 
% Row Count 25 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.69218 cm} x{3.28482 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 Quality Life cycle}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{2}{x{5.377cm}}{Process Quality} \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
Internal QA & 개발팀 내에서 세분화한 QA \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
External QA & Stake holder 들이 제시한 QA. 위에 2개 모두 제품 관점에서 산정한 모델 \tn 
% Row Count 7 (+ 4)
% Row 3
\SetRowColor{white}
Quality in use & 사용자 관점에서 산정한 QA의 모델(모음집) \tn 
% Row Count 10 (+ 3)
% Row 4
\SetRowColor{LightBackground}
Architecture concerns & 요구사항 이외에 아키텍트가 추가로 넣는 요구사항으로, 일반적으로 이 프로젝트에서 추가하는 요구사항 혹은 경험에 따라서 추가하는 요구사항 들이다. \tn 
% Row Count 18 (+ 8)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.94103 cm} x{3.03597 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - GRASP}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Responsibility란}? & 클래스에 주어진 contract 혹은 의무. 다른 메소드 / 객체와 연계해서 메소드로써 구현됨. 메소드로 동작을 하는 책임도 있는 반면, 다른 객체나 private field를 아는 것도 책임에 포함됨 \tn 
% Row Count 10 (+ 10)
% Row 1
\SetRowColor{white}
GRASP & coupling, cohension, expert, controller, creator, don't talk to stranger \tn 
% Row Count 13 (+ 3)
% Row 2
\SetRowColor{LightBackground}
Low coupling이 높으면? & 재사용이 힘듬. 하나 바꾸면 다 바꿔야 함, 코드 이해가 어려움, \tn 
% Row Count 17 (+ 4)
% Row 3
\SetRowColor{white}
cohension이 낮으면? & 여러 책임이 한 클래스에 다 모여있어서 이해가 어려움 직관적이지 않음, \tn 
% Row Count 22 (+ 5)
% Row 4
\SetRowColor{LightBackground}
Information Expert & 가장 먼저 클래스에 줄 책임은, 가지고 있는 private info (encapsulated)를 관리하고 값을 채워넣는 책임이다. \tn 
% Row Count 28 (+ 6)
% Row 5
\SetRowColor{white}
Creator & A가 B를 매우 친밀하거나, B를 가지고 있거나, B와 aggregate 하거나 B가 생성될때 초기화 정보를 넣어준다면 A가 B를 생성하게 하라. \tn 
% Row Count 36 (+ 8)
\end{tabularx}
\par\addvspace{1.3em}

\vfill
\columnbreak
\begin{tabularx}{5.377cm}{x{1.94103 cm} x{3.03597 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - GRASP (cont)}}  \tn
% Row 6
\SetRowColor{LightBackground}
\mymulticolumn{2}{x{5.377cm}}{controller} \tn 
% Row Count 1 (+ 1)
% Row 7
\SetRowColor{white}
\mymulticolumn{2}{x{5.377cm}}{Don't talk to stranger} \tn 
% Row Count 2 (+ 1)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.4931 cm} x{3.4839 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - ADD 방법론}}  \tn
% Row 0
\SetRowColor{LightBackground}
ADD? & Architecture Design Methodology \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
Plan do and check & 모듈 선택 -\textgreater{} 분해 -\textgreater{} Architecture Driver 선택 -\textgreater{} NFR해결을 위한 Style 선택 + FR을 위한 하위 모듈 실체화 -\textgreater{} 하위 모듈의 인터페이스 정의 -\textgreater{} Usecase, QA를 검증하고 contraint 확정 -\textgreater{} 이하 반복 \tn 
% Row Count 11 (+ 9)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.89126 cm} x{3.08574 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Unified process}}  \tn
% Row 0
\SetRowColor{LightBackground}
UP 구성 & inception phase, elaboration, construction, transition \tn 
% Row Count 3 (+ 3)
% Row 1
\SetRowColor{white}
각 phase 별 disciplines & test, code, planning, Req, analysis \& design, business modeling, deployment, configuration \& change management, Project management \tn 
% Row Count 9 (+ 6)
% Row 2
\SetRowColor{LightBackground}
Inception phase & Business modeling, Req 추출, Prototyping, feasibility study \tn 
% Row Count 12 (+ 3)
% Row 3
\SetRowColor{white}
Elaboration & ADD 방법론 등을 사용하여 아키텍처 설계를 해서 Baseline Architecture를 정의한다. Baseline archirecture는 skeleton architecture로 elaboration 단계가 끝나면 최종 완성되며 이후 절대로 바뀌어서는 안된다. \tn 
% Row Count 23 (+ 11)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.54287 cm} x{3.43413 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Pattern, Style, Idium}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Architecture} Style & == Architecture Pattern \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
Pattern? & 특정한 문맥(조건,상황)에서 발생하는 설계 문제가 있을때 그것을 잘 해결하는 일반화된 설계 형태를 제시한 것. \tn 
% Row Count 8 (+ 6)
% Row 2
\SetRowColor{LightBackground}
Design pattern? & components나 subsystem을 설계할 때 적용 가능한 패턴 \tn 
% Row Count 11 (+ 3)
% Row 3
\SetRowColor{white}
idium & 구현시 적용 가능한 패턴 \tn 
% Row Count 13 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.09494 cm} x{3.88206 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{클래스 관계}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{Association} & 클래스를 사용함 \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
\seqsplit{Aggregation} & 포함 관계가 있지만 owner가 죽어도 owning은 영향 없음. 중간에 다른 객체에 붙을 수도 있음 \tn 
% Row Count 6 (+ 4)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{Composition} & 포함관계가 있으며 라이프 사이클이 동일함. \tn 
% Row Count 8 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.54287 cm} x{3.43413 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{UML 표기}}  \tn
% Row 0
\SetRowColor{LightBackground}
class diagram & class, interface, component, visibility \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
deployment diagram & artifacts(file, db), node, components \tn 
% Row Count 4 (+ 2)
% Row 2
\SetRowColor{LightBackground}
component diagram & port, provided interface, required interface, component, \tn 
% Row Count 7 (+ 3)
% Row 3
\SetRowColor{white}
sequence & lifeline, message, interaction use, \tn 
% Row Count 9 (+ 2)
% Row 4
\SetRowColor{LightBackground}
activity diagram & swim lanes, merge node, decision node, initial node, final node, merge node, fork node \tn 
% Row Count 13 (+ 4)
% Row 5
\SetRowColor{white}
data flow & external entity, process, datastore \tn 
% Row Count 15 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{2.18988 cm} x{2.78712 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{품질속성}}  \tn
% Row 0
\SetRowColor{LightBackground}
품질속성 시나리오 구성 & Source(위치), 원인(Stimulus), 대상(Artifact), 상태(Environment), 대응(Response), 대응결과(Response Measure) \tn 
% Row Count 6 (+ 6)
% Row 1
\SetRowColor{white}
Modifiability & 변경 지역화(책임을 분리시킴), 기존 인터페이스를 유지, LateBinding \tn 
% Row Count 10 (+ 4)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{성능(자원수요)} & 필요한 자원을 \seqsplit{줄이기(알고리즘} 개선, 요청 자체를 없앤다, 이벤트 빈도 줄이기, \tn 
% Row Count 15 (+ 5)
% Row 3
\SetRowColor{white}
\seqsplit{성능(자원관리)} & 동시성 제공,데이터 처리가 병목 되지 않도록, 자원을 늘림(HW), \tn 
% Row Count 19 (+ 4)
% Row 4
\SetRowColor{LightBackground}
\seqsplit{가용성(오류감지)} & Ping,Echo(다른 컴포넌트,프로세스가 잘 동작하는지 확인), \seqsplit{HeartBeat(정상이라고} 신호를 내가 보낸다), \tn 
% Row Count 25 (+ 6)
% Row 5
\SetRowColor{white}
\seqsplit{가용성(오류복구)} & 같은 일을 처리하는 여러개의 프로세스/Node를 둬서 하나가 망가져도 다른쪽이 잘 동작시킴, 롤백 \tn 
% Row Count 31 (+ 6)
\end{tabularx}
\par\addvspace{1.3em}

\vfill
\columnbreak
\begin{tabularx}{5.377cm}{x{2.18988 cm} x{2.78712 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{품질속성 (cont)}}  \tn
% Row 6
\SetRowColor{LightBackground}
보안 & 기밀성(권한 있는 사람만 본다), 무결성(권한 있는 사람만 write), 인증(송신자가 맞는지 확인), \seqsplit{Non-Repudication(부인봉쇄}, 안보냈다고 뻥카치지 못하게, \seqsplit{AccessControl(권한이} 있어야 사용 가능), 가용성(권한이 있으면 서비스 이용이 지속되야) \tn 
% Row Count 14 (+ 14)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Batch Sequencial}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Data Flow \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
뭐냐 & Data Flow AS 중 하나. 데이터가 단방향으로 하나의 서브시스템에서 다른 서브시스템으로 이동한다. 각 서브시스템은 input이 넘어와야만 작업할 수 있다. \tn 
% Row Count 8 (+ 7)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{참여자} & Program, Data Store \tn 
% Row Count 10 (+ 2)
% Row 3
\SetRowColor{white}
장점 & 오직 데이터(파일)에 의해서만 연결되어있이므로 데이터 포맷만 맞추면 쉽게 분리 가능, \tn 
% Row Count 14 (+ 4)
% Row 4
\SetRowColor{LightBackground}
단점 & 데이터만 input이므로 외부에서 각 서브시스템을 제어하기에는 다소 맞지 않는다. 동시성을 지원하지 못하므로 높은 latency를 가진다. \tn 
% Row Count 20 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.94103 cm} x{3.03597 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Pipe and Filter}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Data Flow \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
뭐냐 & 스트림을 따라서 데이터가 필터에 도착하면 데이터를 가공하고 다음 필터로 파이프로 전달. \tn 
% Row Count 7 (+ 6)
% Row 2
\SetRowColor{LightBackground}
참여자 & 데이터스트림, 필터, 파이프 \tn 
% Row Count 9 (+ 2)
% Row 3
\SetRowColor{white}
장점 & 동시성을 제공한다. 데이터가 끊임없이 밀려오고 각 필터는 자기 담당만 처리하므로., 재사용, 변경이쉽다, 단순하다. \tn 
% Row Count 16 (+ 7)
% Row 4
\SetRowColor{LightBackground}
단점 & 동적으로 데이터의 포맷을 변경할 수 없다. \tn 
% Row Count 19 (+ 3)
% Row 5
\SetRowColor{white}
Batch Sequencial의 차이 & 사전 처리 과정이 완료되어야 하지만, 파이프\&필터는 데이터가 계속 주어지는 상황을 전제로 한것이다. \tn 
% Row Count 25 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.24425 cm} x{3.73275 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Process Control}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Data Flow \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
참여자 & Controller, Actuator, Process, Sensor \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & Controller가 현재 상태를 측정값을 보고 Actuator에게 start/stop을 내린다. Actuator는 핵심 기능을 담당하는 Process에게 이 정보를 전달하고 Process에 input이 들어가면 start/stop을 수행한다. 그 결과는 sensor가 수집하여 다시 Controller에게 전달한다. 이처럼 closed - loop의 구조를 주로 띄게 된다. \tn 
% Row Count 16 (+ 13)
% Row 3
\SetRowColor{white}
장점 & 복잡한 공식이 없어도 상태값을 일정한 수준으로 유지하게 하는게 가능하다. \tn 
% Row Count 20 (+ 4)
% Row 4
\SetRowColor{LightBackground}
추천 적용 & 상태 값을 제어하는 임베디드 시스템, 빌딩 온도 제어 시스템, 핵 발전소 등 \tn 
% Row Count 24 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Repository}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{참여자} & Repository, Components \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
뭐냐 & 중간에 공유 저장소가 있는 것. 그래서 저장소를 기반으로 데이터 interaction 하는 것이다. \tn 
% Row Count 6 (+ 4)
% Row 2
\SetRowColor{LightBackground}
장점 & 데이터 통합되게 해준다, BackUp\&Restore를 쉽게 달성한다, 각 components의 확장성/ 재사용 가능하다 (직접적으로 interaction을 하지 않기 때문에), \tn 
% Row Count 12 (+ 6)
% Row 3
\SetRowColor{white}
단점 & 데이터 중복이 발생할 수 있다, 저장된 데이터의 구조에 components들이 높은 의존성, 데이터의 포맷을 변경하고 확장하는 것은 비용이 크다. \tn 
% Row Count 18 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Blackboard}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Data Centered \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Blackboard, Control, KnowledgeSource \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & KnowledgeSource는 독립된 서브시스템으로 복잡한 문제 1개를 잘 알려진방법으로 해결한다. Blackboard는 공유 저장소를 가지고 있고 여기에 붙은 KnowledgeSource들은 blackboard에 있는 데이터를 각각 해결해서 업데이트한다. Control은 이 변화를 모니터링 한다. \tn 
% Row Count 14 (+ 11)
% Row 3
\SetRowColor{white}
\seqsplit{언제?} & 유일한 해결책이 없는 복잡한 문제를 해결해야 할때 \tn 
% Row Count 17 (+ 3)
% Row 4
\SetRowColor{LightBackground}
장점 & KnowledgeSource를 쉽게 추가가 가능하다. 동시성을 제공한다. \tn 
% Row Count 20 (+ 3)
% Row 5
\SetRowColor{white}
단점 & blackboard의 구조를 바꾸면 매우 많이 바꿔야 한다. 언제까지 계속 데이터를 업데이트 해야 하는지 판단하는 것이 어렵다. 여러 KnowledgeSource들 간에 동기화문제 \tn 
% Row Count 27 (+ 7)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.29402 cm} x{3.68298 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Layered}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Hierarchical \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
참여자 & Layer \tn 
% Row Count 2 (+ 1)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & 상위 레이어는 하위레이어에 의존한다. 아래에서 위로 의존관계가 맺어지지는 않는다. 하나의 Layer에서 발생한 수정은 다른 layer에 영향을 주지 않는다. \tn 
% Row Count 9 (+ 7)
% Row 3
\SetRowColor{white}
언제 적용? & 시스템이 확장해가면서 최소한의 의존을 만들고 각 모듈이 모듈성 재사용성을 높이면서 독립적으로 개발될 수 있어야 할때 \tn 
% Row Count 15 (+ 6)
% Row 4
\SetRowColor{LightBackground}
장점 & 인터페이스가 변하지 않는 한, 하위레이어의 수정이 상위레이어에 영향을 주지 않는다, 각 layer는 미리 정의된 인터페이스로 통신하기 때문에 인터페이스만 지켜주면 쉽게 확장/교체 가능하다., \tn 
% Row Count 24 (+ 9)
% Row 5
\SetRowColor{white}
단점 & 런타임 성능이 떨어진다. 아래까지 내려갔다가 위로 올라와야 하니까, Exception Handling도 마찬가지로 depth가 깊기 때문이다. \tn 
% Row Count 30 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - PlugIn Architecture}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Hierarchical \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & CoreSystem, Plug-in modules \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & App 추가 로직을 PlugIn을 떼었다가 붙였다가 하는 것. 핵심로직은 coreSystem으로 미리 구현을 해놓아야 한다. \tn 
% Row Count 8 (+ 5)
% Row 3
\SetRowColor{white}
장점 & 이식성, 확장성, \tn 
% Row Count 9 (+ 1)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Virtual Machine}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{참여자} & Application, Virtual Machine, Existing Platform \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
장점 & 이식성, SW개발 쉬움 \tn 
% Row Count 3 (+ 1)
% Row 2
\SetRowColor{LightBackground}
단점 & 속도 느림 \tn 
% Row Count 4 (+ 1)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Non-buffered event invoc}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Implict asynchronous communication software \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Event source, event listener \tn 
% Row Count 4 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & 버퍼를 두지 않고 컴포넌트 끼리 비동기로 interaction 한다. 이벤트가 발생하면 바로 쏜다. 옵저버 패턴하고 유사함 \tn 
% Row Count 9 (+ 5)
% Row 3
\SetRowColor{white}
장점 & 런타임에 listener를 쉽게 추가/삭제, 재사용성(쉽게 다른 source, listener를 붙일 수 있다), \tn 
% Row Count 13 (+ 4)
% Row 4
\SetRowColor{LightBackground}
단점 & listener의 동작이 언제 끝날지 알기가 힘들다, 디버깅이 어려움, 버퍼 비동기보다 직접적으로 의존하므로 결합도가 높다 \tn 
% Row Count 18 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.24425 cm} x{3.73275 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Buffered Message Based}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Implicit Asynchronous communication \tn 
% Row Count 2 (+ 2)
% Row 1
\SetRowColor{white}
참여자 & MessageBroker, Consumer, Producer \tn 
% Row Count 4 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & Producer가 msg를 xml 등과 같은 형태로 broker에 넣는다. Broker는 가공하거나, 보안체크를 하거나 다른 borker로 route하거나  consumer들에게 전달한다. \tn 
% Row Count 11 (+ 7)
% Row 3
\SetRowColor{white}
언제 적용 & 네트워크 관리, 날씨 예보, 뱅킹 시스템 \tn 
% Row Count 13 (+ 2)
% Row 4
\SetRowColor{LightBackground}
장점 & 비동기가 가능한데 Producer가 메시지를 보낼때 Consumer가 idle 상태가 아니어도 된다, 매우 독립적인 설계가 가능하며 쉽게 교체/확장이 가능하다, producer는 누가 이 메시지를 받을 것인지 어디에 위치하고 있는지 몰라도 된다, 동시성을 보장한다 \tn 
% Row Count 24 (+ 11)
% Row 5
\SetRowColor{white}
단점 & 메세지 큐에 한계는 있다, 구현에 복잡도가 올라간다, 디버깅이 어렵고 직접호출보다 퍼포먼스가 저하된다. \tn 
% Row Count 29 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Client - server}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Client, Server \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & 전체 시스템의 구조를 요청자와 처리자로 tier를 분산하는 것이다. \tn 
% Row Count 6 (+ 3)
% Row 3
\SetRowColor{white}
\seqsplit{언제?} & 클라이언트가 여러명이 하나의 서비스로 접근하는데 이를 효율적으로 관리하고 싶을때, 리소스 Control은 중앙집중으로 하고 싶고 리소스 자체는 여러 군데 분산시키고 싶을때 \tn 
% Row Count 14 (+ 8)
% Row 4
\SetRowColor{LightBackground}
장점 & 책임을 분리시킬 수 있다. (presentation, businiess logic), 보안성, 서버의 가용성 \tn 
% Row Count 18 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.24425 cm} x{3.73275 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Multi tier}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
참여자 & Tier \tn 
% Row Count 2 (+ 1)
% Row 2
\SetRowColor{LightBackground}
Layer vs Tier & Layer는 소프트웨어 적으로 구분한 구조의 구성 요소, Tier는 물리적인  요소 \tn 
% Row Count 6 (+ 4)
% Row 3
\SetRowColor{white}
장점 & 중간에 tier를 넣음으로써 확장성과 재사용성,  비지니스 관련은 중간 티어에만 들어감, 트래픽 감소, 신뢰성 증가, \tn 
% Row Count 12 (+ 6)
% Row 4
\SetRowColor{LightBackground}
단점 & 테스트가 더 어렵다 \tn 
% Row Count 13 (+ 1)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Dispatcher}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Client, Broker, Server \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & Server들은 모두 같은 구현이다. Broker는 Server의 걸린 load를 보고 제일 좋은 Server로 client의 요청을 연결 시켜 준다. Broker또한 별도의 tier이며, Server는 Broker에 register 한다. \tn 
% Row Count 10 (+ 7)
% Row 3
\SetRowColor{white}
장점 & Client-Server가 결합도가 낮다, 트래픽에 강하다, 서비스 가용성이 좋다, \tn 
% Row Count 13 (+ 3)
% Row 4
\SetRowColor{LightBackground}
단점 & Broker를 거쳐서 통신하므로 퍼포먼스 저하, 테스트가 어렵다. \tn 
% Row Count 16 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.89586 cm} x{4.08114 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Broker}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{참여자} & Broker, Client, Servant \tn 
% Row Count 3 (+ 2)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & CORBA임. 분산객체 각 Node는 Broker를 앞에 달고 있고 Broker는 해당 Node 내에서 등록한 Servant 들을 모두 들고 있음. Node와 Node는 서로 통신이 가능함. \tn 
% Row Count 9 (+ 6)
% Row 3
\SetRowColor{white}
장점 & 컴포넌트가 로컬에 있건 외부에 어디에 있건 위치 관계없이 의도한 결과를 얻는다, 완전히 다른 서버와 플랫폼 간의 interaction이 쉽게 가능함, 컴포넌트 재사용이 좋다 \tn 
% Row Count 16 (+ 7)
% Row 4
\SetRowColor{LightBackground}
단점 & 성능이 떨어진다, 장애가 발생할 경우 대처가 어렵다 (fault-torelance), 테스트가 어렵다 \tn 
% Row Count 20 (+ 4)
% Row 5
\SetRowColor{white}
\seqsplit{언제?} & 많은 시스템이 분산되어있다, 바인딩을 동적으로 바꾸고, 객체로써 다루고 싶고 서비스 제공자의 위치를 알고싶지도 않고.... \tn 
% Row Count 26 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.24425 cm} x{3.73275 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Master slave}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
참여자 & Master, Slave \tn 
% Row Count 2 (+ 1)
% Row 2
\SetRowColor{LightBackground}
뭐냐 & Master는 Slave 중에서 주어진 문제를 해결할 수 있는 놈을 선정해서 그 결과를 받아옴 \tn 
% Row Count 6 (+ 4)
% Row 3
\SetRowColor{white}
장점 & fault tolerance, 신뢰성(실패해도 다른 slave와 연결) \tn 
% Row Count 9 (+ 3)
% Row 4
\SetRowColor{LightBackground}
언제 적용 & fault tolerance, reliability가 중요할때 \tn 
% Row Count 11 (+ 2)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{1.89126 cm} x{3.08574 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - P2P}}  \tn
% Row 0
\SetRowColor{LightBackground}
분류 & Distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
뭐냐 & 동일한 역할을 부여받은 Peer 노드 끼리 Provider 이자 Consumer로써 서로 연결되어 하나의 contents에 대한 일정 비율을 각각 나누어 가져서 제공하는 것 \tn 
% Row Count 9 (+ 8)
% Row 2
\SetRowColor{LightBackground}
structured, unstructured & unstructured는 말그대로 중앙이 아무것도 없음, structured는 중앙에 관리 혹은 분배하는 놈이 더 있고 더 효율적임. \tn 
% Row Count 16 (+ 7)
% Row 3
\SetRowColor{white}
장점 & 중앙이 없으므로 중앙이 실패할 염려도 없음, 확장성이 좋음 그냥 연결해서 붙이면 끝, 별도의 DB나 서버를 둘 필요가 없음 \tn 
% Row Count 23 (+ 7)
% Row 4
\SetRowColor{LightBackground}
단점 & 시스템 전체적으로 일관성을 갖도록 유지하는 것이 어렵다, 각 node 마다 power가 다르다 \tn 
% Row Count 28 (+ 5)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.74655 cm} x{4.23045 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - Service oriented}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{분류} & distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{뭐냐} & 서비스(흔히 생각하는 OS의 서비스가 아니다)라고 하는 작은 단위에 독립적인 MVC를 모두 가진 서브시스템이 있다. 이 서비스들을 매우 완화된 포맷인 XML등을 사용해서 레고블럭 처럼 쌓아서 통신하는 것이다. 네트워크를 사용할 수도 있고 사용하지 않을 수도 있다. 다른 언어라고 해도 XML만 지원하면 동작한다. \tn 
% Row Count 14 (+ 13)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{언제}? & 하나의 큰 시스템을 책임으로 묶어서 보다 작은 서비스로 만들어, 이들간에 표준화된 인터페이스를 정의하고 이를 잘 블럭처럼 쌓아올려서 다른 시스템을 만들때 재사용하고자 하는 것 \tn 
% Row Count 22 (+ 8)
% Row 3
\SetRowColor{white}
\seqsplit{장점} & 상호운용성, 확장성, 재사용성 \tn 
% Row Count 24 (+ 2)
% Row 4
\SetRowColor{LightBackground}
\seqsplit{단점} & 구축하기 어렵다, 성능이 떨어진다, 병목현상이 발생할 수 있다. \tn 
% Row Count 27 (+ 3)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{x{0.84609 cm} x{4.13091 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - micro service}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{분류} & Distributed \tn 
% Row Count 1 (+ 1)
% Row 1
\SetRowColor{white}
\seqsplit{뭐냐} & SOA의 일종의 부분집합이다. SOA는 monolithic 아키텍처다. interaction은 언어에서 독립적인 방법으로 수행하지만 공통으로 묶을 수 있는 부분은 묶는다. (예를들면 공용 DB) 반면 Microsoervice는 각 서비스를 작게 쪼개서 네트워크를 통해 API를 제공할 뿐 그 안에 구성은 encapsulation 하듯이 감추는 것이다. DB도 각자사용하거나 DB를 없앤다. \tn 
% Row Count 15 (+ 14)
% Row 2
\SetRowColor{LightBackground}
\seqsplit{RESTful}? & 네트워크로 API를 만들려면 다양한 방식이 있을 것이다. json으로 https로 날려도 되고. RESTful은 이러한 API를 HTTP의 방식 GET, POST 등을 사용해서 표현하는 것을 말한다. 즉 API 정의방법. \tn 
% Row Count 23 (+ 8)
% Row 3
\SetRowColor{white}
\seqsplit{장점} & 독립적인 작은 서비스이므로 확장이 쉽고, 결합도가 낮다. 모듈화 수준이 높다, 테스트/개발이 쉽다. \tn 
% Row Count 28 (+ 5)
% Row 4
\SetRowColor{LightBackground}
\mymulticolumn{2}{x{5.377cm}}{단점} \tn 
% Row Count 29 (+ 1)
% Row 5
\SetRowColor{white}
\seqsplit{언제}? & 결합도가 너무너무 높다, 하나만 기능을 고치려는데 시스템 전체를 다 체크한다, 기존 시스템을 분해하면 수십개의 micro service가 나온다. \tn 
% Row Count 35 (+ 6)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.64701 cm} x{4.32999 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - MVC}}  \tn
% Row 0
\SetRowColor{LightBackground}
\seqsplit{단점} & View와 Control 구분하는 것이 때로는 명확하지 않다, Model이 변경되면 impact가 크다. \tn 
% Row Count 4 (+ 4)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}

\begin{tabularx}{5.377cm}{p{0.4977 cm} p{0.4977 cm} }
\SetRowColor{DarkBackground}
\mymulticolumn{2}{x{5.377cm}}{\bf\textcolor{white}{최적설계 - PAC}}  \tn
% Row 0
\SetRowColor{LightBackground}
\mymulticolumn{2}{x{5.377cm}}{} \tn 
% Row Count 0 (+ 0)
\hhline{>{\arrayrulecolor{DarkBackground}}--}
\end{tabularx}
\par\addvspace{1.3em}


% That's all folks
\end{multicols*}

\end{document}