슬라이드 1

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "슬라이드 1"

Transcription

1 소프트웨어아키텍처패턴

2 소프트웨어아키텍처설계와패턴 2

3 시스템과아키텍처 시스템은하나이상의구성요소로연결된통합체이다. * Created by Sungwon Choi, Myoungji Univ. 3

4 기능과비기능요구사항의관계 System Requirement Funtional NonFunctional Stakeholders Concern Viewpoint View * Created by Sungwon Choi, Myoungji Univ. 4

5 소프트웨어시스템 개발생명주기 System requirements System Architecture Software requirements Hardware requirements Software requirements Software Design Hardware design Software design Software System System including both software and hardware 5

6 기능요구사항 - 개요 요구사항모델링기법 구조적분석 (Structured Analysis) Data Flow Diagram(DFD) Entity Relation Diagram(ERD) State Transition Diagram (STD) 유즈케이스분석 (Use Case Analysis) Use Case Modeling (UC) 목표와시나리오기반분석 (Goal and Scenario Based Analysis) Goal-Scenario Modeling(GS) 6

7 기능요구사항 - 개요 소프트웨어요구사항의 3 단계 1 단계 2 단계 3 단계 7

8 기능요구사항 - 유스케이스 유스케이스분석기법 사용자중심요구사항모델링 유즈케이스와액터간상호작용을통해시스템분석 사용자비즈니스와애플리케이션영역을이해 작업중심적 : Diagram 으로요구사항이해 유즈케이스는각각독립적 High Priority Use Case = High Priority Requirements 단순한유즈케이스나열 : 전체적인시스템요구사항이해어려움 비기능적인요구사항은표현이어려움 표준 Graphic 표기 Communication 개선, 해석의 Risk 감소 8

9 기능요구사항 - 유스케이스 ATM 시스템예제 9

10 비기능요구사항 - 개요 이해관계자를통한비기능요구사항추출 유스케이스다이어그램에서액터에서시스템이아닌사람은모두이해관계자이다. 이해관계자중액터가아닌사람도있다. 팀장, 기획자, 고객 ( 사용자가아닌 ), 유지보수자, 내부개발자등 이해관계자의이해를중심으로비기능요구사항을추출 각각의이해관계자를중심으로관심사항을추출하여비기능요구사항추출 프로젝트환경을통한비기능요구사항추출 프로젝트기간, 비용에대한이해후이슈를추출한다. 프로젝트조직 ( 개발인력의부족, SQA 분리등 ) 에대한이해후이슈를추출한다. 주의사항 무엇을 (What) 쓰는것이지 어떻게 (How) 를쓰는것이아니다. 시나리오기반으로작성 ( 상황을명확히표현 ) 하는것이이해하기가좋다. 모호한표현 (Ex. 잘, 쉬운, 의도되지않은, 유사시등 ) 을쓰지않는다. 10

11 비기능요구사항 작성예제 내부사용자가시스템에서비스실행을요구할때, 시스템이 3 초이내에응답하지않으면, 재요청을 3 회실시한다. 이때에도 3 초이내에응답하지않으면오류상태로인식하고시스템관리자에 SMS 으로알리며, 2 초이내에자동으로응급시스템으로전환한다. 11

12 아키텍처전략 - 개요 아키텍처전략선택 공학적기법사용 Encapsulation, Loosely Coupled, Highly Cohesive, Separate of Concern 법칙준수 Pattern, Tactics, Style 등을응용 소프트웨어기술및경험사용 주의사항 외부의아키텍처참조 ( 참조아키텍처 ) 자신의경험이나기술에의한결정추출 비기능요구사항에대응하는전략을작성한다. 비기능요구사항의표를사용하는것이좋다. 잘알려진전략이라면간단한단어를사용해도좋으나그렇지않을경우반드시근거및설명을달도록한다. 12

13 아키텍처전략 - 패턴 1. 소프트웨어아키텍처패턴 1) 다양한상황에서소프트웨어아키텍처수립하는방식을정형화한것을소프트웨어아키텍처패턴이라고한다. 2) 가장일반적인아키텍처패턴은아래표와같다. 3) 아키텍처패턴은지속적으로생성되고있으며 POSA(Pattern Oriented Software Architecture) 시리즈 (1 ~ 5권 ) 에자 세한내용이나와있다. 패턴명설명아키텍처예제 Layer 패턴 가장일반적으로사용하는아키텍처패턴으로서 subtask 들을그룹으로묶어사용허가관계를표시하는패턴이다. 모듈의재사용성을높여유지보수성이나이식성에좋은패턴이다. Broker 패턴 외부에분산된컴포넌트를호출하려고할때클라이언트 request 의분석하여서버컴포넌트에전달하고그결과값을전달하는역할을하는패턴을브로커패턴이라고한다. 보안이나, 안정성을높일수있는패턴이다. MVC 패턴 모델, 뷰, 컨트롤세개의컴포넌트로어플리케이션을구분한패턴으로사용자인터페이스를가지고있는많은어플리케이션에사용된다. 모델은기능과데이터를가지고있고뷰는사용자의화면표시를지원한다, 컨트롤러는이들과의관계를가지고사용자이벤트나모델의변화를감지하여모델과뷰에전달하는역할을한다. 뷰와모델사의사이의일관성을갖게하여변경용이성, 기능확장성을지원한다. 13

14 아키텍처전략 - 패턴 패턴명설명아키텍처예제 State-Logic-Display(3-tier) 패턴 비즈니스애플리케이션을개발할때가장일반적으로사용되는패턴으로사용자인터페이스 (UI) 와비즈니스로직, 데이터를구분하여변경용이성이좋다. 게임, 웹어플리케이션등많은분야에서사용되고있다. Sense-Compute-Control 패턴 일정한시간별로센서의값을읽어들이는 Sense 와센서의값을계산하여해야할행위를정의한 compute, actuator 에해야할기능이나행위를전달하는 control 로모듈을구분하는패턴을말한다, 임베디드애플리케이션을개발할때주로사용되는패턴이다. 14

15 아키텍처전략 스타일 1. 소프트웨어아키텍처스타일 1) 소프트웨어아키텍처수립하는수단으로아키텍처스타일을사용하기도한다. 아키텍처스타일은아키텍처패턴중에 Runtime view, Module view, Allocation view 에자주사용되는패턴을표준화한것이다. 2) 각종뷰를작성할때참조할수있는아키텍처패턴으로서 Call & Return style, Layer style, Uses style, Decomposition style 이많이쓰이고있다. ( 소프트웨어아키텍처문서화책참조 ) 뷰아키텍처스타일설명 Data Flow 데이터이동에목적을둔 Style (Ex. Batch sequential, pipes & filters) Runtime view Call & Return S/W 요소들의호출을특성화한 Style( 객체지향에서사용하는스타일 ) Interacting process Event Based 로 system 이움직이는 Style (Ex. Publish-Subscriber system) Module view Data-Sharing Decomposition Generalization Data Storage 를중심으로연동하는 Style 모듈을단계별로분리하여모듈을파악하는스타일 (UML 의 aggregation style) 부모, 자식모듈과의관계 (UML 의 inheritance) Uses (Layer style) 모듈간의사용성을표현한스타일 (UML 의 association 관계 ) (Layer style 은 Layer 패턴과같음 ) Allocation view Decomposition Implementation Work assignment Software 요소와 infra system(h/w, N/W) 과의관계를나타낸스타일 소프트웨어모듈과파일시스템 ( 디렉토리 ) 과의관계를나타낸스타일 소프트웨모듈을개발하는사람, 그룹가개발할모듈과의관계를나타낸스타일 15

16 아키텍처전략 - 스타일 1. 소프트웨어아키텍처패턴과스타일비교 16

17 아키텍처전략 스타일 1. 소프트웨어아키텍처수립전술 (tactics) 1) 소프트웨어아키텍처에요구되는품질속성을만족시키는특정기법의모음을 tactics 라고한다. 2) 아키텍처수립전술은 Computer science 적인기법과소프트웨어구조로문제가포함되어있다. ( 패턴, 스타일과의 차이점 ) 3) 주로소프트웨어아키텍처를수립하고부족한품질속성을높이는데사용된다. 4) 보다자세한사항은 아키텍처이론과실제 4장에나와있다. 품질속성명 안정성유지보수성성능 관련 tactics 그래프 17

18 Graphics & Image Data Management Data Interchange International Operations User Interface Location & Directory Transaction Processing System & Network Management Security Software Engineering 아키텍처전략 - 참조아키텍처 참조모델 (TOGAF, etc.) 참조아키텍처 (J2EE, SOA, etc.) S/W 아키텍처 (XX 프로젝트아키텍처, etc.) 아키텍처패턴 (Call-Return, etc.) 참조모델 특정도메인의기능을요소별로구분하여놓은것 참조아키텍처 Implementation F/W (Spring, Struts, etc.) 참조모델과아키텍처패턴을결합하여특정품질을항상시켜놓은아키텍처 Implementation F/W 참조아키텍처를기준으로프레임워크으로개발된상용제품 Qualities Infrastructure Applications Business Applications Application Programming Interface Operating System Services Network Services Communications Infrastructure Interface Communication Infrastructure TOGAF TRM 18

19 패턴 Overview 19

20 패턴개요 패턴 특정문제에대한해법을추상화하고그안의공통된요인을추출하여정형화한것을패턴이라고한다. 패턴의 3 가지의스키마 정황 (Context) : 문제를발생시키는상황 문제 (Problem) : 해당정황에서반복적으로발생하는문제 해법 (Solution) : 해당문제에대해검증된해답 소프트웨어시스템개발에서의패턴종류 소프트웨어아키텍처패턴 문제를해결하는해법으로소프트웨어시스템의기본구조와관련된것을다룰경우아키텍처수준의패턴이라고말한다. 디자인패턴 소프트웨어시스템의서브시스템이나컴포넌트들, 혹은그것들간의관계를해법으로사용하는경우, 디자인패턴이라고말한다. 이디엄 (Idiom) 특정프로그래밍언어의기능을이용하여컴포넌트들혹은컴포넌트들간관계의특정측면을구현하는방법을이디엄이라고한다. 20

21 아키텍처패턴종류 Layer Blackboard Pipes and Filters Broker Model-View-Controller Publisher-Subscriber (Event-Bus) Presentation-Abstraction- Control Microkernel Reflection Interceptor Reactor Procator Half-sync/half-async Leader/Followers 21

22 Layer 패턴 22

23 Layer 패턴 정의 특정추상레벨에있는서브태스크들끼리서로묶어서하나의그룹으로분류하는방식 하위수준의이슈를상위수준에이슈와분리시켜소프트웨어의재사용성을높여주는패턴 예제 네트워크프로토콜아키텍처 (e.g. OSI 7 layer) 가상머신 (e.g. interpreters, JVM) 23

24 Layer 패턴 패턴예제 Applications& interfaces Issues - Separation of concerns Major processes Domain classes Mechanisms Services 24

25 Layer 패턴 정황 (Context) 시스템의규모가커서분해할필요가있을경우 문제 (Problem) 하위레벨과상위레벨이슈가서로혼재해있다는점이주된특징인시스템을설계할경우 시스템의기능이수직적으로나눠져있거나수평적인경우와혼재되어있는경우 해법 (Solution) 시스템의상호연동관계가있는모듈들을모아계층으로추상화 ( 최하위계층 : Layer 1, 최상위계층 : Layer N) Layer J 는반드시 Layer J-1 이제공하는서비스만사용. 다른계층의서비스를사용해서는안됨 25

26 Layer 패턴 설계순서 1. 계층별로모듈을묶는추상기준을정의 2. 추상기준에따라계층을몇레벨로나눌지결정 3. 계층마다역할및태스크부여 4. 계층별제공서비스를상세히정의 5. 계층별상세인터페이스정의 6. 시스템기능이계층에서동작하는것이가능한지확인 ( 예. 유스케이스시나리오를시뮬레이션하는방식 ) 7. 계층내부에대한구조정의 8. 인접한계층간의통신방식정의 9. 예외처리방식을정의 26

27 Layer 패턴 설계순서예제 계층을 5개로구분하고그역할을정의함 계층별객체를선언하고그들의관계를정의함 계층패턴의원칙을어긋나는객체가없는지확인 27

28 Layer 패턴 OSI 7 Layer 패턴예제 28

29 Layer 패턴 Java Virtual Machine 예제

30 Layer 패턴 장점 계층별연동을한정할수있어 Loosely coupled 원칙을지킬수있음 계층별로변화에대한영향력을한정할수있어코딩이나테스트를계층별로진행할수있음 인터페이스정의가잘되어있다면계층을통째로교체할수있음 모듈의재사용성을높여유지보수성이나이식성이필요한시스템에적용하기좋은패턴임 단점 계층의원칙을지키기위해각계층을모두거쳐야하므로성능측면에불이익을받을수있음 계층을구분하기어렵고잘못구분할경우설계수정이빈번히발생할수있음 계층의적절한개수및규모를정의하는것이어려움 30

31 Blackboard 패턴 31

32 Blackboard 패턴 Copy right by 정의 Shared data, database 와같은데이터중심패턴중에하나 명확히정의된문제해법이없을때문제를풀어가는하나의방식을정의한패턴 대략적으로해법을수립하기위해특수한서비스시스템의지식을조합하는패턴 Accessor 예제 Accessor AI system Signal processing Accessor Accessor Accessor Accessor repository Radar/sonar Vision processing repository Accessor Accessor Speech processing Accessor Accessor Accessor Accessor Middleware Shared data DBMS 32

33 Blackboard 패턴 Copy right by 패턴예제 - 음성인식시스템 Input: 파형형태의음성 Output: 시스템이인식한문장 33

34 Blackboard 패턴 Copy right by 정황 (Context) 도메인의해법이명확하지않은경우 문제 (Problem) 컴퓨터비전, 음성인식, 화상인식등도메인분야와같이상위수준의데이터구조로변환하기위한명확한해법이존재하지않음 하나의문제를분해하면여러가지도메인의하위문제들이발생함. 하위문제들을해법이있다해도다시취합하여상위수준의문제를포괄적으로해결하는데어려움이있음 해법 (Solution) 일반적인데이터구조 (blackboard) 를가지고각각독립적으로동작하는프로그램들 (Knowledge sources) 로이뤄져있음 통제컴포넌트 (Control) 에의해모든독립적인프로그램들은하나의해법을찾기위해서로협력하여동작함 34

35 Blackboard 패턴 Copy right by 구성컴포넌트 Blackboard 문제의현재상태를제시 데이터를관리 Knowledge Sources Blackboard 상태를업데이트 특정도메인의해법을제시 Blackboard에그해법을적용 Control Blackboard 상태모니터링 Knowledge Sources 스케줄을관리하고실행시킴 35

36 Blackboard 패턴 패턴예제흐름도 1. Start Control::loop 2. Control::nextSource 3. determine potential knowledge sources by calling Blackboard::inspect 4. Invoke KnowledgeSource::execCondition of each candidate knowledge source 5. Each candidate knowledge source invokes Blackboard::inspect to determine if/how it can contribute to current state of solution 6. Control chooses a knowledge source to invoke by calling KnowledgeSource::execAction 7. Executes KnowledgeSource::updateBlackboard 8. Calls Blackboard::inspect 9. Calls Blackboard::update 36

37 Blackboard 패턴 패턴예제흐름도 37

38 Blackboard 패턴 Copy right by 설계순서 1. 문제의도메인을정의하고해법을찾기위해일반적인지식분야를상세히살펴본다. 2. 해법에대한추상화수준을상위수준에서하위수준까지나눠서정의한다. 3. 해법수준에맞게 Knowledge source 를정이하고각수준으로분할한다. 4. 모든 Knowledge source 가 blackboard 와상호작용하는표현방식을찾아서정의한다. (blackboard 어휘를정의한다.) 5. Control 을정의한다. 38

39 Blackboard 패턴 Copy right by 퍼즐맞추기게임예제 How do you solve a puzzle? edges control regions organize pieces assemble parts 39

40 Blackboard 패턴 Copy right by 퍼즐맞추기게임예제 Level 4 assemble chunks Level 3 Level 2 Level 1 build chunks of edges build chunks of sky : collect water pieces collect sky pieces : Turn all pieces picture side up 40

41 Blackboard 패턴 퍼즐맞추기게임예제 Level 4 Level 3 Level 2 Level 1 Blackboard assemble chunks build chunks of edges build chunks of sky : collect water pieces collect sky pieces : turn all pieces picture side up write write write write KS KS KS KS Copy right by Knowledge Sources Sample Environment reads data flow from a to b event send from a to b a a b b Control Activates (e.g. events) repository process/object/thread 41

42 Blackboard 패턴 Copy right by F-22 Sensor Fusion System 예제 관심사항 비행기조종사는넘쳐나는데이터로인해많은스트레스를받는다. avoid being detected engage enemy fighters engage ground targets avoid terrain obstacles avoid surface-to-air ordinance navigate and find the targets oh yeah,... and fly the airplane too! 42

43 Blackboard 패턴 Copy right by F-22 Sensor Fusion System 예제 요구사항 기존시스템은센서, 표시판, 조절기능이분리되었음 조종사가데이터를조합하고판단하여야함 데이터통합 필요데이터만선별적으로보드에표시 보기좋은형태로데이터를표시 FL Radar TFTA Radar Airspeed Altitude Weapon Stores Aircraft Status Observability GPS/Compass 43

44 Blackboard 패턴 Copy right by F-22 Sensor Fusion System 예제 아키텍처패턴선정 F-22 비행기에서가장복잡한기계중에하나로서 blackboard 패턴을사용 44

45 Blackboard 패턴 Copy right by F-22 Sensor Fusion System 예제 The F-22 Advanced Tactical Fighter s Sensor Fusion System 은조종사가필요로하는정보를하나의계기판에표시해준다. FL Radar TFTA Radar Airspeed Altitude Weapon Stores Aircraft Status Observability GPS/Compass Mission Profile Sensor Fusion Computer Pilot Input Integrated air picture 45

46 Blackboard 패턴 Copy right by F-22 Sensor Fusion System 예제 Mission Profile Pilot Input Fusion Control interrupt Display Engine FL Radar TFTA Radar Airspeed Altitude Weapon Stores Radar KS Attitude KS Attitude KS Air Data Repository Aircraft Status Observability Profile KS GPS/Compass Navigation task data repository data interrupt : processes repository Integrated air picture 46

47 Blackboard 패턴 장점 완벽한해법을찾기어려운경우에사용할수있음 KS, Control, Blackboard 가독립적으로동작하여가변성이나유지보수성이좋음 KS 는타문제도메인에재사용될수있음 단점 완벽한해법을제시하지못하므로얼마동안동작해야하는지알수가없음 ( 성능문제 ) 계산결과가항상동일하지않아테스트가어려움 많은시간에걸쳐수정되어야하므로개발에많은노력이필요 47

48 Broker 패턴 48

49 Broker 패턴 정의 외부에분산된컴포넌트를호출하려고할때클라이언트요청값을분석하여서버컴포넌트에전달하고그결과값을전달하는역할을하는패턴 클라이언트와서버사이의브로커라는컴포넌트를두어보다효과적으로서버와클라이언트사이를분리할수있어분산시스템을구축하는데용이함 예제 광역네트워크기반의 CIS(city information system) 시스템 CORBA (Common Object Request Broker Architecture) 49

50 Broker 패턴 패턴예제 50

51 Broker 패턴 정황 (Context) 독립적인컴포넌트형태로이질적인환경에서작동하는분산시스템을개발하는경우 문제 (Problem) 독립컴포넌트마다실행환경이다르고이들끼리통신이필요한경우 클라이언트와서버들이추가, 삭제및변경이자주일어날경우 해법 (Solution) Broker 컴포넌트를도입하여클라이언트와서버사이를분리 Broker 컴포넌트가클라이언트와서버의정보를가지고있어서로간의통신을조율 클라이언트와서버 Proxy 를두어특정환경과관련된부분을처리 Bridge 를두어네트워크통신과관련된부분을이관하여처리 51

52 Broker 패턴 패턴구성도 52

53 Broker 패턴 패턴흐름도 53

54 Broker 패턴 설계순서 1. 객체모델을정의하거나기존모델을재사용할지결정 2. 컴포넌트들사이의상호연동을어떤방식으로할지결정 3. 클라이언트와서버간의협력을위한 Broker 컴포넌트의역할정의 4. Proxy 객체를사용해환경과관련된부분캡슐화설계 5. Broker 컴포넌트설계 6. IDL 컴파일러설계 54

55 Broker 패턴 CORBA(Common Object Request Broker Architecture) 예제 55

56 Broker 패턴 CORBA 예제 Server Code // Create an object request broker ORB orb = ORB.init(args, null); // Create a new address book... AddressBookServant servant = new AddressBookServant(); //... and connect it to our orb orb.connect(servant); // Obtain reference for our nameservice org.omg.corba.object object = orb.resolve_initial_references("nameservice"); // Since we have only an object reference, we must cast it to a NamingContext. We use a helper class for this purpose NamingContext namingcontext = NamingContextHelper.narrow(object); // Add a new naming component for our interface NameComponent list[] = { new NameComponent("address_book", "") }; // Now notify naming service of our new interface namingcontext.rebind(list, servant); 56

57 Broker 패턴 CORBA 예제 Client Code // Create an object request broker ORB orb = ORB.init(args, null); // Obtain object reference for name service... org.omg.corba.object object = orb.resolve_initial_references("nameservice"); //... and narrow it to a NameContext NamingContext namingcontext = NamingContextHelper.narrow(object); // Create a name component array NameComponent nc_array[] = { new NameComponent("address_book","") }; // Get an address book object reference... org.omg.corba.object objectreference = namingcontext.resolve(nc_array); //... and narrow it to get an address book address_book AddressBook = address_bookhelper.narrow(objectreference); // call the address book interface name = AddressBook.name_from_ ( ); 57

58 Broker 패턴 EJB(Enterprise Java Beans) 3.0 예제 Server public class HelloWorldBean { public String sayhello() { return "Hello World!!!"; } } Client Code InitialContext ic = new InitialContext(); Hello = (HelloRemote) ic.lookup("example/hellobean/remote"); 58

59 Broker 패턴 장점 컴포넌트간의위치투명성을제공 플랫폼간의 Portability 제공함 서버다른시스템의연동을용이하게함 재사용컴포넌트확보에용이 단점 성능에대한불이익 장애대처율이떨어짐 테스트디버깅의복잡함 ( 서버, 클라이언트연동시에 ) 분산환경을지원하는시스템이많지않음 59

60 MVC 패턴 60

61 MVC 패턴 정의 하나의데이터값 ( 도메인오브젝트 ) 을여러개의클라이언트화면으로일관적으로보여줄수있는패턴 화면 (View) 과데이터값 (Model) 의연결부분을컨트롤러 (Control) 가관리하여 View 의추가, 변경, 삭제가 Model 에영향을미치지않고 Model 의변화도 View 에영향을미치지않게하는패턴 예제 웹기반서비스시스템 ( 거의대부분 ) IOS application 서비스 61

62 MVC 패턴 패턴예제 - Tomcat 62

63 MVC 패턴 정황 (Context) 상호작용이많은시스템에유연한 HCI(Human-Computer Interface) 를개발하는경우 문제 (Problem) 사용자인터페이스의변경이많이일어나는경우 같은기능을사용하는사용자화면이다른경우 ( 예. 마우스로값입력 vs. 키보드로입력 ) 사용자인터페이스들끼리서로연관성이복잡할경우 해법 (Solution) Model, View, Controller 이렇게 3 개의영역으로구분 Model : 핵심데이터와기능을캡슐화 View : 사용자의정보를화면에표시 Controller : View 로부터입력정보를받아관련된 View 나 Model 을호출함 63

64 MVC 패턴 패턴구성도 64

65 MVC 패턴 패턴흐름도 초기화 65

66 MVC 패턴 패턴흐름도 이벤트발생 66

67 MVC 패턴 구현순서 1. 서비스의핵심기능과사용자인터페이스부분을분리한다. 2. Publisher-Subscriber (Observer) 패턴을적용하여모델을구현한다. 3. View를설계하고구현한다. 4. Controller를설계하고구현한다. 5. View와 Controller 관계를설계하고구현한다. 67

68 MVC 패턴 장점 동일한모델로부터여러 View 들을표현할수있음 View들을동기화할수있음 View의추가, 변경, 삭제가자유로움 프레임워크로확장하여구현이가능함 단점 설계가복잡하고개발이어려움 View 와 Controller 는밀접히관련되어있음 68

69 Publishers-Subscribers(Event-Bus) 패턴 69

70 Publisher-Subscriber 패턴 정의 하나의 Publisher 가다수의 Subscriber 에게상태가변경되었음을단방향전파로통지하는패턴 협력컴포넌트들의상태를동기화하는데유용함 Observer 패턴, Dependents 패턴, Event 패턴으로사용됨 예제 GUI 애플리케이션 사용자의요청에따른화면의변화 ( 줌인, 포커스, 클릭등 ) MVC 패턴을애플리케이션 70

71 Publisher-Subscriber 패턴 정황 (Context) 한번의호출로다수의협력컴포넌트의상태를변경해야하는경우 문제 (Problem) 특정컴포넌트에서발생하는상태변경정보를하나이상의컴포넌트에서수신해야함 Publisher 와 Subscriber 는서로 tightly coupled 되어서는안된다. 해법 (Solution) 하나의컴포넌트를 Publisher 로두고상태변경을받을컴포넌트들을 subscriber 로둔다. Subscriber 는 Publisher 에서제공하는인터페이스를통해서등록한다. Publisher 의상태가변경되면등록된 Subscriber 에게변경상태를전송한다. 71

72 Publisher-Subscriber 패턴 구현 이벤트기반으로 Publisher-Subscriber 패턴을구현한다. 이벤트기반으로구현하면시스템변경을쉽게할수있다. 이벤트가명확히전송되었는지알수가없다. (Non-Deterministic) 응답시간을명확히예측할수없다. (Non-Deterministic) Event-Bus 기반으로구현 Explicit Invocation 변경정보를전달한대상을명확히알고변경정보를전달함 Implicit Invocation 변경정보를전달할대상을명확히알지않고정보를전달함 72

73 Publisher-Subscriber 패턴 Copy right by 패턴예제 Implicit Invocation 73

74 Publisher-Subscriber 패턴 Copy right by 패턴예제 Explicit Invocation 74

75 Publisher-Subscriber 패턴 Referenced by : David Garlan, Lecture notes of / Architecture for software system, Institute for software research, CMU, 패턴예제 분산환경이벤트전송방법 75

76 Publisher-Subscriber 패턴 Copy right by 패턴예제 분산환경이벤트전송방법 76

77 Publisher-Subscriber 패턴 Referenced by : David Garlan, Lecture notes of / Architecture for software system, Institute for software research, CMU, 패턴예제 공유메모리를이용한이벤트전송방법 77

78 Publisher-Subscriber 패턴 장점 다수의컴포넌트에게동시에변경공지를할수있음 GUI 인터페이스를쉽게만들수있음 GUI 빌더나프레임워크를쉽게만들수있음 단점 Non-deterministic 한문제 이벤트핸들러와프로세스로직이 Tightly coupled 되어있다. 78

79 Pipes and Filters 패턴 79

80 Pipes and Filters 패턴 Copy right by 정의 데이터스트림을처리하는패턴 데이터는 Pipe 를통해서 Filter 로전달 전달된데이터는 Filter 를통해걸러지고 pipe 를통해다음 Filter 로이동 예제 Unix command system Ex>> cat etc/passwd grep joe sort > junk 80

81 Pipes and Filters 패턴 패턴예제 - Programming Language Compiler 81

82 Pipes and Filters 패턴 Copy right by 정황 (Context) 입력된데이터스트림을처리하거나변환해야함 문제 (Problem) 다수의개발자가참여하여시스템을구축해야함 데이터스트림을처리하는프로세싱단계가쉽게변할수있음 프로세싱단계를재사용할수있어야함 다양한방식으로처리결과물을보여줄수있어야함 해법 (Solution) 입력된데이터를처리하는단계를순차적 (sequencial) 으로처리 하나의처리단계 (Filter 로구현 ) 에서처리된결과물은다음처리단계의입력물 각각의처리단계를 Pipe 로연결 82

83 Pipes and Filters 패턴 Copy right by 구성컴포넌트 Filters 데이터가입력되면시작 데이터를보강하거나정제, 변형하는프로세스를진행 Pipes 데이터가흐르는공간 필터와필터사이를연결 데이터소스와최초필터간의역할 최종필터와데이터싱크간의연결 연결된 Filter 에게데이터를입력하고출력하는역할 Data Source 시스템에들어오는입력값 동일한구조체나타입으로이뤄진일련의데이터값 Data Sink Pipe 를통해나오는최종결과물을취합 83

84 Pipes and Filters 패턴 설계순서 1. 처리단계순서에맞게시스템의작업을나눈다. 각단계는이전단계의아웃풋에만의존성을가져야한다. 2. 데이터포맷을결정한다. 3. 파이프간의연결방법을설계한다. 4. 필터설계하고구현한다. 5. 에러핸들링을설계하고구현한다. 6. 파이프라인을구현한다. 84

85 Pipes and Filters 패턴 Pipes and Filters 패턴예제 시그널처리와관련된어플리케이션에주로사용된다. radar medical process control sonar audio video telemetry 등등 85

86 Pipes and Filters 패턴 Copy right by 패턴예제 - Signaling Process 지속적으로들어오는아날로그신호를디지털신호로변경 다시디지털신호를아날로그신호로바꿔주는방식

87 Pipes and Filters 패턴 Copy right by 패턴예제 - Signaling Process Digital Audio Analog to Digital Converters (ADC) -> analog voltages to digital values. Digital to Analog Converters (DAC) -> digital values to voltages. Amplifier audio signal ADC DAC 87

88 Pipes and Filters 패턴 Copy right by 패턴예제 신디사이저 1950 년대에 Max Mathews 는 unit generators (UG) 라는네트워크모듈을이용하여신디사이저를개발했다. UG 는신디사이저의핵심으로다음과같은기능을한다. 사운드재생과사운드처리에사용 ( 최근까지사용 ) 처음에는하드웨어로개발되었으나최근에는소프트웨어로개발 이기술은최근에음악기기, 레코더, 음악재생기계 (CDs, MP3 players) 등에사용되고있다. Sampler Digital Equalizer Digital amplifier Audio Input Hardware filter data flow sink device source device Audio Output Hardware 88

89 Pipes and Filters 패턴 Copy right by 패턴예제 - Modern Audio Application filter data flow sink device source device Sampler Compressor Delay Distortion Equalizer Sampler Compressor Flange Equalizer Merge AmpOut Sampler Compressor Echo Reverb Equalizer All in done in software 89

90 Pipes and Filters 패턴 장점 중간결과파일이불필요함 Filter의교환이나재조합이쉬움 Filter의재사용성이좋음 Parallel 프로세싱에용이함 단점 다음과같은처리시간이성능에악영향 Filter 간의전송시간 Context switching 시간 Synchronization 에러처리가어려움 ( 데이터복구작업등 ) 90