BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
195,318 Visitors up to today!
Today 34 hit, Yesterday 86 hit
daisy rss
'DSA세미나'에 해당되는 글 8건
2012.10.06 21:36

모듈 뷰 또는 시앤시 뷰는 소프트웨어 구성요소들로 표현한 것입니다. 할당 뷰는 소프트웨어 요소와 소프트웨어의 외부환경의 비소프트웨어 요소와의 매핑을 나타냅니다. 

할당 스타일은 할당 뷰에 대한 스타일입니다.

 

무엇을 할당할까?

소프트웨어 구성요소는 구현되기 위해 작업자들에게 할당되어야 합니다.

설계되고 구현된 소프트웨어 구성요소는 실행환경인 하드웨어에 할당되어야 합니다.

소프트웨어 구성요소는 실행되기 위해 먼저 설치되어야 합니다. 설치라는 것은 특정 디렉토리에 파일들을 할당하는 것입니다.

이러한 할당에 대해 할당 스타일들이 존재합니다. 작업 할당 스타일(work assignment style), 배치 스타일(deployment style), 설치 스타일(install style)

 

할당 스타일은 구성요소로 소프트웨어 요소와 환경 요소를 갖습니다. 그들 사이에 allocated-to 관계가 있습니다.  

 

배치 스타일

배치 스타일은 시앤시 뷰의 구성요소들에 해당하는 소프트웨어 요소와 컴퓨팅 플랫폼의 하드웨어인 외부환경 요소를 구성요소로 갖습니다. 구성요소들 사이에는 allocated-to 관계를 맺을 수 있습니다. 동적으로 할당이 이루어질 경우, migrates-to, copy-migrates-to, execution-migrates-to 관계를 맺을 수 있습니다.

• Migrates-to. A relation from a software element on one processor to the same software element on a different processor, this relation indicates that a software element can move from processor to processor but does not simultaneously exist on both processors.
• Copy-migrates-to. This relation is similar to the migrates-to relation, except that the software element sends a copy of itself to the new processor while retaining a copy on the original processing element.
• Execution-migrates-to. Similar to the previous two, this relation indicates that execution moves from processor to processor but that the code residency does not change. A copy of a process exists on more than one processor, but only one is active at any particular time. The execution of the process “migrates” when the active process is changed.

외부환경 요소는 다음과 같은 속성들을 가질 수 있습니다.

• CPU properties. The properties relevant to the various processing elements (such as processor clock speed, number of processors, memory capacity, bus speed, cache size, and instruction execution speed).
• Memory properties. The properties relevant to the memory stores (such as memory size and speed characteristics). 
• Disk or other storage unit capacity. The storage capacity and access speed of disk units: individual disk drives, disk farms, and redundant arrays of independent disks (RAIDs).
• Bandwidth. The data transfer capacity of communication channels.
• Fault tolerance. Multiple hardware units may perform the same function, and these units may have a failover control mechanism.

소프트웨어 요소는 다음과 같은 속성들을 가질 수 있습니다.

• Resource consumption. For example, a computation takes 32,123 instructions always, or at most, or on average, or under nominal(error-free) conditions, and so on.
• Resource requirements and constraints that must be satisfied. For example, a software element must execute in no more than 0.1 second.
• Safety critical. For example, this would be true if a software element must always be running. The following property is relevant to the allocation:
• Migration trigger. If the allocation can change as the system executes, this property specifies what must occur for a migration of a software element from one processing element to another.

배치 스타일은 UML 배치 다이어그램으로 작성할 수 있습니다. 개인적으로 배치 스타일에는 배치 다이어그램보다는 자유로운 스타일로 작성하는 것이 좋다고 생각합니다.

 

설치 스타일

설치 스타일은 어떤 특별한 파일이 사용되고 어떻게 그들이 구성되고 패키지 되는지를 기술합니다. 설치 스타일은 형상 관리 도구와 빌드 스크립트들이 설치를 자동화할 수 있도록 도와야 합니다.

설치 스타일은 구성요소로 하나의 시앤시 스타일의 컴포넌트에 해당하는 소프트웨어 요소와 파일 또는 폴더와 같은 configuration item들에 해당하는 외부환경 요소를 갖습니다. 구성요소들 사이에는 allocated-to 관계와 containment 관계를 맺을 수 있습니다.

설치 스타일은 UML 배치 다이어그램으로 작성할 수 있습니다.

 

작업할당 스타일

작업할당 스타일은 팀 자원 할당을 계획하고 관리하고 구축을 위한 책임을 할당하고 프로젝트 구조를 설명하는 것을 돕습니다.

작업할당 스타일은 구성요소로 하나의 모듈에 해당하는 소프트웨어 요소와 조직 단위, 팀, 부서, 협력업체 등과 같은 외부환경 요소를 갖습니다. 구성요소들 사이에는 allocated-to관계가 맺어집니다.

작업할당 스타일에 대한 기호는 특별한 것이 없습니다. 표 형식으로 매핑관계를 표현하면 됩니다.

작업할당 부분은 프로젝트 관리 영역이어서 아키텍처 영역에서 다루기는 민감합니다. 저자 또한 그랬던 것 같습니다. 그래도 저자가 작업할당을 아키텍처 영역에 넣은 것은 이해가 됩니다. 아키텍트는 모듈 분할을 통해 작업 할당 등에 대한 생각을 갖고 있습니다. 이러한 점을 생각해보면, 현실적으로는 모르겠으나 아키텍처와 프로젝트 관리자의 협력은 꼭 필요한 것으로 보입니다.

 

다른 할당 스타일들

구현 스타일

구현 스타일은 어떻게 개발 환경이 파일과 폴더의 트리 구조로 조직화될 것인지와 어떻게 모듈이 그 구조에 매핑될 것인가를 기술합니다. 구현 스타일은 설치 스타일과 유사하지만 개발환경에 대한 것이라는 점이 다릅니다.

데이터 저장소 스타일

데이터 저장소 스타일은 소프트웨어의 데이터 엔티티를 데이터 서버들의 하드웨어에 매핑하는 것을 기술합니다. 데이터 저장소 스타일은 배치 스타일과 유사하지만 대상이 시앤시뷰의 구성요소가 아니라 데이터 엔티티라는 점이 다릅니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.10.06 13:28

어떤 시앤시 스타일을 선택할 것인가는 일반적으로 시스템의 실행 구조의 특성에 의존합니다.

The choice of a C&C style (or styles) will usually depend on the nature of the runtime structures in the system. For example,if the system will need to access a set of legacy databases, the style will likely be based on a shared-data style. Alternatively, if a system is intended to perform data stream transformation, a data flow style will likely be chosen.

 

시앤시 스타일은 많습니다. 그래서 좀 더 넓은 범주로 묶어서 다룰 필요가 있습니다. 이 장에서는 4개의 스타일 범주를 제시합니다. call-return, data flow, event-based, repository

• Call-return styles. Styles in which components interact through synchronous invocation of capabilities provided by other components.
• Data flow styles. Styles in which computation is driven by the flow of data through the system.
• Event-based styles. Styles in which components interact through asynchronous events or messages.
• Repository styles. Styles in which components interact through large collections of persistent, shared data.

스타일 범주들의 이름을 보면 상호작용 방식이 어떠한가에 따라서 나누어졌다는 것을 알 수 있습니다. 커넥터는 상호작용 메커니즘에 해당하는 것입니다. 사실 이러한 스타일 범주 구분은 커넥팅 방식에 의한 구분이라고 할 수 있습니다. 따라서 시앤시 스타일에서는 컴포넌트보다는 커넥터 중심으로 생각하는 것이 좋습니다.

 

 

데이터 흐름 스타일(Data Flow Styles)

데이터 흐름 스타일은 컴포넌트의 상호작용이 데이터의 흐름에 의해서 이루어질때 선택되는 스타일입니다. 데이터 흐름이 생기려면 데이터를 보내는 컴포넌트와 데이터를 받는 컴포넌트가 있어야 합니다. 데이터 흐름을 가능하게 하려면 그러한 방식을 지원하는 커넥터가 있어야 합니다. 커넥터를 연결하려면 포트들이 있어야 합니다. 출력 포트에서는 전달되어야 하는 데이터를 쓰고, 입력 포트에서는 데이터를 읽고 사용해야 합니다.

데이터 흐름 스타일은 스트림 처리가 있는 곳에서 주로 사용됩니다. 또한 다수의 변형 단계들을 거치면서 해야 하는 일에도 사용됩니다.

 

파이프 앤 필터 스타일(Pipe-and-Filter Style)

파이프 앤 필터 스타일은 데이터 흐름 스타일의 한 종류입니다. 구성요소는 컴포넌트에 해당하는 필터와 커넥터에 해당하는 파이프로 구성됩니다. 필터와 파이프를 연결하는 attatchment 관계를 갖습니다. 

파이프 앤 필터 스타일에서 상호작용 패턴은 데이터 스트림의 연속되는 변형에 의해 특징지어집니다. 필터의 입력 포트에 도착한 데이터는 변형되어집니다. 변형된 데이터는 필터의 출력 포트로 연결된 파이프를 통해 다음 필터의 입력 포트로 전달됩니다.

하나의 필터는 데이터를 주고 받는데 다수의 입력 포트들과 출력 포트들을 사용할 수 있습니다. 이러한 스타일을 사용하는 다양한 예들이 있습니다.

Modern examples of such systems are signal-processing systems, systems built using UNIX pipes, the request-processing architecture of the Apache Web server, the map-reduce paradigm for search engines, Yahoo! Pipes for processing RSS feeds, and many scientific computation systems that have to process and analyze large streams of experimental data.

파이프와 필터의 속성에는 다음과 같은 것들이 있을 수 있습니다. 

Typical properties to document for pipes include
• Pipe capacity (that is, buffer size)
• How end-of-data is signaled
• What form of blocking occurs when writing to a pipe whose buffer is full or reading from a pipe that is empty
Properties of filters can include
• Whether or not each filter is a separate process
• The data stream transformation each performs 

 

 

호출 리턴 스타일(Call-Return Styles)

호출 리턴 스타일은 프로그래밍 언어에서의 함수 호출을 생각하면 쉽습니다. 한 컴포넌트는 다른 컴포넌트에게 서비스 제공을 요청합니다. 요청한 컴포넌트는 요청받은 컴포넌트가 서비스를 제공하기 전까지는 제어권을 잃기 때문에 다른 일을 할 수가 없습니다. 커넥터는 서비스 요청을 요청자에서 제공자로 전달해야 하고 결과를 리턴해야 하는 책임을 갖습니다.

 

클라이언트 서버 스타일(Client-Server Style)

호출 리턴 스타일의 한 종류입니다. 컴포넌트에 해당하는 클라이언트와 서버와 커넥터에 해당하는 요청/응답 커넥터(request/reply connector)를 구성요소로 갖습니다. 클라이언트와 서버사이의 연결에 해당하는 attatchment 관계를 갖습니다.

서버는 다른 서버의 클라이언트가 될 수도 있습니다. 컴포넌트들은 티어들에 놓여질 수도 있습니다.

 

피어 투 피어 스타일(Peer-to-Peer Style)

호출 리턴 스타일의 한 종류입니다. 컴포넌트에 해당하는 피어와 커넥터에 해당하는 호출리턴 커넥터(call-return connector)를 구성요소로 갖습니다. attatchment 관계를 갖습니다.

특별한 피어 컴포넌트들은 라우팅, 인덱싱, 피어 찾기 등을 제공할 수 있습니다.

이 스타일을 통해 가용성이나 규모성이나 높은 수준에서 분산된 시스템을 가능하게 합니다.

피어 투 피어 스타일에서 컴포넌트는 클라이언트 서버 스타일의 컴포넌트와는 달리 일방향으로 서비스 요청과 제공이 이루어지는 것이 아니라 양방향으로 요청과 제공이 이루어집니다. 피어는 클라이언트가 되기도 하고 서버가 되기도 합니다.

피어 투 피어 스타일의 사용 예는 다음과 같은 것들이 있습니다. 

Examples of peer-to-peer systems include file-sharing networks, such as BitTorrent and eDonkey; instant messaging and VoIP applications, such as Skype; and desktop grid computing systems. 

 

서비스지향아키텍처 스타일

서비스지향아키텍처 스타일을 선택하는 주요한 이유 중 하나는 상호운용성(interoperability)입니다.

서비스지향아키텍처 스타일에는 기본적으로 서비스 제공자와 소비자가 컴포넌트가 있어야 합니다. 또한 서비스 요청과 제공을 가능하게 하는 기반구조가 있어야 합니다.

서비스 제공자와 소비자 사이에 메지를 전달하고 라우트할 수 있는 ESB가 있을 수 있습니다. 

서비스 제공자가 제공하는 서비스를 등록할 수 있는 서비스 레지스트리가 있을 수 있습니다. 

서비스 제공자와 소비자가 비즈니스 워크플로어를 정의하는 스크립트에 기반해서 상호작용하는 것을 조율할 수 있는 Orchestration 서버가 있을 수 있습니다.

커넥터에는 호출 리턴 커넥터에 해당하는 SOAP 커넥터와 REST 커넥터가 있고, 비동기 메시징 방식의 Messaging 커넥터가 있습니다. 

• Call-return connectors. Two of the most common such connectors are SOAP and REST:
– SOAP is the standard protocol for communication in Web services technology. Service consumers and providers interact by exchanging request/reply XML messages, typically on top of HTTP.
– With the REST connector, a service consumer sends synchronous HTTP requests. These requests rely on the four basic HTTP commands (post, get, put, and delete) to tell the service provider to create, retrieve, update, or delete a resource (a piece of data). Resources have a well-defined representation in XML, JSON, or a similar language/notation.
• Asynchronous messaging. Components exchange asynchronous messages, usually through a messaging system such as IBM WebSphere MQ, Microsoft MSMQ, or Apache ActiveMQ.

 

이벤트 기반 스타일

이벤트 기반 스타일은 컴포넌트들이 비동기 메시지를 통해 커뮤니케이션하도록 합니다. 이러한 방식은 서로의 결합력을 떨어뜨려 변경에 유연한 시스템을 가능하게 합니다.

 

발행구독 스타일(Publish-Subscribe Style)

이벤트 기반 스타일의 한 종류입니다. 특정한 이벤트를 발행하는 컴포넌트와 구독하는 컴포넌트를 구성요소로 갖고, 커넥터로 publish-subscribe 커넥터를 갖습니다. attatchment 관계를 갖습니다.

다음과 같은 예들이 있습니다.

• Graphical user interfaces, where a user’s low-level input actions are treated as events that are routed to appropriate input handlers
• Applications based on the model-view-controller (MVC) pattern, where view components are notified when the state of a model object changes
• Extensible programming environments, in which tools are coordinated through events
• Mailing lists, where a set of subscribers can register interest in specific topics
• Social networks, where “friends” are notified when changes occur to a person’s Web site

 

 

레파지토리 스타일(Repository Style)

레파지토리 스타일은 레파지토리라 불리는 하나 이상의 컴포넌트들과 이 컴포넌트를 사용하는 컴포넌트를 갖습니다. 레파지토리는 일반적으로 영속성 데이터의 큰 컬렉션을 갖습니다.  

 

공유 데이터 스타일

공유 데이터 스타일은 레파지토리 스타일의 한 종류로, 레파지토리를 공유함으로 데이터를 생산해 내는 컴포넌트와 데이터를 소비하는 컴포넌트를 분리할 수 있는 것과 같은 잇점을 제공합니다.  

공유 데이터 스타일에서 상호작용 패턴은 영속성 데이터의 교환에 의해 주도됩니다. 데이터는 다수의 접근자들을 갖고 적어도 하나의 영속성을 갖는 데이터에 대한 공유데이터 저장소를 가져야 합니다. 

레파지토리와 데이터 액세스 컴포넌트를 갖고 데이터 읽기와 쓰기 커넥터를 갖습니다. 데이터 읽기와 쓰기 커넥터의 중요한 속성은 트랜잭션이냐 아니냐 입니다. attatchment 관계를 갖습니다. 

다음과 같은 속성들이 있을 수 있습니다.

Useful properties to document about data stores include the following:
• Restrictions on the number of simultaneous connections to the data store.
• Whether or not new accessors can be added at runtime.
• Access-control enforcement policies.
• Whether concurrent access to the same data element is permitted, and if so, what kinds of synchronization mechanisms are used.
• Administrative concerns, such as whether one modifies the types of data stored, and if so, who has access, when those changes can be performed, and via what interface.
• Replication of data in a distributed setting.
• Age of data.
• If the repository system supports both query-based and triggered modes of interaction, it is important to clearly document what form of interaction is intended, for example, by using different connector types.

 

 

시앤시 스타일에 공통적인 이슈들

병행처리는 런타임시에는 고려해야할 중요한 부분입니다. 병행처리하나의 스타일에서만 고려해야 하는 것이대부분의 시앤시 스타일들에서 고려해야 하는 것입니다. 이러한 공통적인 고려에서 나오는 스타일을 communicating-processes 스타일이라 합니다.

Communicating processes are used to understand (1) which portions of the system could operate in parallel, (2) the bundling of components into processes, and (3) the threads of control within the system.

communicating-process 스타일에서는 프로세스와 쓰레드 구조가 기술되어야 합니다. 또한 다음과 같은 것들이 추가적으로 기술되어야 합니다.

• Mechanisms for starting, stopping, and synchronizing a set of processes or threads
• Preemptability of concurrent units, indicating whether the execution of a concurrent unit may be preempted by another concurrent unit
• Priority of the processes, which influences scheduling
• Timing parameters, such as period and deadline
• Additional components, such as watchdog timers and schedulers, for monitoring and controlling concurrency
• Use of shared resources, lock mechanism, and deadlock prevention or detection techniques

 

공통적인 고려에서 또 다른 것은 어떻게 컴포넌트들을 티어로 묶어내고 제약할 것인지에 대한 것입니다.

또 다른 고려사항은 런타임시에 어떤 컴포넌트를 생성하고 소멸시켜서 실행 구조를 재조정할 것인지에 대한 부분입니다.

 

 

 

 

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.10.05 18:06

시앤시(C&C)뷰는 시스템의 런타임 구조에 중점을 둡니다.

시앤시뷰는 컴포넌트와 커넥터라는 구성요소와 attachments와 interface delegation 관계를 사용합니다.

컴포넌트는 포트(port)라 불리는 인터페이스를 가질 수 있습니다. 포트는 자신의 외부환경과의 특별한 상호작용지점을 나타냅니다. 포트는 명시적인 타입을 갖는데 여기에는 상호작용지점에서 발생할 수 있는 행위를 정의합니다. 포트는 모듈에서 이야기한 인터페이스와는 다릅니다. 하나의 컴포넌트에는 동일 타입의 여러 포트가 있을 수 있습니다.

커넥터는 컴포넌트들 사이의 상호작용을 위한 통로입니다. 커넥터는 협력을 위한 연결이기 때문에 협력에 참여하는 역할들이 명시되어야 합니다.

컴포넌트와 커넥터가 복잡하고 큰 경우 분할될 수 있습니다. 컴포넌트는 다른 컴포넌트들을 부분들로 가질 수 있고, 커넥터는 다른 커넥터들을 부분들로 가질 수 있습니다.

attachments는 컴포넌트들 사이의 관계이고, interface delegation은 전체 컴포넌트와 부분 컴포넌트들 사이의 관계입니다.

시앤시뷰의 구성요소들이 가질 수 있는 속성들에는 다음과 같은 것들이 있습니다.

• Reliability. What is the likelihood of failure for a given component or connector? This property might be used to help determine overall system reliability.
• Performance. What kinds of response time will the component provide under what loads? What kinds of latencies and throughputs can be expected for a given connector? This property can be used with others to determine system properties such as response times, throughput, and buffering needs.
• Resource requirements. What are the processing and storage needs of a component or a connector? This property can be used to determine whether a proposed hardware configuration will be adequate.
• Functionality. What functions does an element perform? This property can be used to reason about overall computation performed by a system.
• Security. Does a component or a connector enforce or provide security features, such as encryption, audit trails, or authentication? This property can be used to determine system security vulnerabilities.
• Concurrency. Does this component execute as a separate process or thread? This property can help to analyze or simulate the performance of concurrent components and identify possible deadlocks.
• Tier. For a tiered topology, what tier does the component reside in? This property helps to define the build and deployment procedures, as well as platform requirements for each tier.

 

커넥터가 복잡한 메커니즘을 가질 경우 커넥터를 컴포넌트로 다룰 수 있습니다. 사실 커넥터는 협력에 해당하는 것으로 RSM에서는 컬레보레이션에 해당합니다. 원래부터 독립된 컴포넌트로 다루어질 수 있는 것입니다.

시앤시뷰의 UML 표현은 UML2의 컴포넌트 다이어그램을 사용합니다. UML2에서는 attachments된 커넥터를 assembly connector라 하고, interface delegation된 커넥터를 delegate connector라고 합니다.  

시앤시뷰는 모듈뷰와 밀접한 관계를 갖습니다. 모듈뷰의 다수의 모듈들이 하나의 시앤시뷰의 구성요소에 매핑될 수도 있고 하나의 모듈이 다수의 시앤시뷰의 구성요소들에 매핑될 수도 있습니다. 하지만 이것은 실제 많은 매핑의 복잡성을 낳습니다. RSM에서는 컴포넌트 수준에서 하나의 컴포넌트가 동일한 수준으로 런타임시에 인스턴스되는 것을 권장합니다.

 

 

RSM에서는 모든 독립적 실체들을 객체로 정의하고, 전체와 부분의 개념하에서 최상위 루트 객체에서부터 최하위 리프 객체까지 모두 동일하게 다룹니다. 소프트웨어 시스템 수준에서 부터 모델링을 시작할 경우 최상위 루트는 시스템이 됩니다. 이렇게 할 경우 모듈뷰는 설계도에 시앤시뷰는 조립도에 해당한다고 할 수 있습니다. 조립을 할 때는 부품들보다 연결에 더 많은 신경을 써야 합니다. 

연결을 하려니 연결을 위한 커넥터가 필요하고 커넥터와 연결하는 포트가 있어야 합니다. 쉽게 프린터 포트와 커넥터를 생각하시면 됩니다. 커넥터는 협력을 위한 것으로 커넥터의 끝지점들에는 협력을 위해 요구되는 역할들이 명시되어야 합니다.

커넥터와 포트가 구체화된다면 커넥터에는 역할들에 해당하는 인터페이스들이 명시되고 포트는 인터페이스를 구현하는 클래스가 될 수 있습니다.

 

시앤시뷰는 중요한 런타임 품질속성들을 다루기 위한 좋은 부분입니다. RSM에서는 이것을 왜 사용하느냐를 따지지 않고 반드시 시앤시뷰에 해당하는 UML 컴포넌트 다이어그램을 필수적으로 작성하도록 합니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.10.05 13:43

이 장에서는 6개의 중요한 모듈스타일을 살펴봅니다. decomposition, uses, generalization, layered, aspects, data model

 

분할 스타일(Decomposition Style)

크고 복잡한 소프트웨어는 한 덩어리로 이해하기가 어렵습니다. 또한 한 덩어리이기 때문에 나누어 작업하기도 어렵고, 변경이 생겼을 때에도 전체가 영향을 받기 때문에 대응이 어렵습니다.

오늘날 개발되는 소프트웨어는 크고 복잡하다고 생각하면 됩니다. 따라서 이러한 문제에 대응을 해야 합니다.

개발되는 소프트웨어에 대한 이해와 커뮤니케이션이 쉬워야 합니다. 작업을 할당할 수 있어야 합니다. 변화를 국지화할 수 있어야 합니다. 그러기 위해서는 다루어야 할 대상이 충분히 작아야 합니다.

크고 복잡한 것을 다루는 가장 일반적인 방법은 분할입니다. 모듈뷰 스타일에 분할 스타일이 있는 것도 이 이유입니다.

분할이란 다루어야 할 대상을 전체로 놓고 전체가 해야 할 일을 부분들과 그들의 협력으로 바꾸는 것입니다. 분할로 인해 전체와 부분의 관계가 요구되는 것입니다. 모듈뷰에서의 모듈들 사이의 관계 중에 is-part-of는 전체와 부분의 관계입니다. UML에서는 전체와 부분의 관계를 위해 컴포지션과 어그리케이션을 제공합니다.

오늘날 소프트웨어는 크고 복잡한 것이 기본이기 때문에, 분할 스타일은 특별한 조건이 있어서 선택되는 것이 아니라 소프트웨어를 개발한다면 기본적으로 선택해야 할 스타일이라고 생각하면 됩니다.

어떤 이유가 있을 때 더 작은 부분으로 분할하는가? 

• Achievement of certain quality attributes. For example, to support modifiability, the information-hiding design principle calls for encapsulating changeable aspects of a system in separate modules, so that the impact of any one change is localized.
• Build-versus-buy decisions. Some modules may be bought in the commercial marketplace, reused intact from a previous project, or obtained as open-source software. These modules already have a set of responsibilities implemented. The remaining responsibilities then must be decomposed around those established modules.
• Product line implementation. To support the efficient implementation of products of a product family, it is essential to distinguish between common modules, used in every or most products, and variable modules, which differ across products.
• Team allocation. To allow implementation of different responsibilities in parallel, separate modules that can be allocated to different teams should be defined. The skills of developers also influence the decomposition. For example, if specialized Web developers are available, modules that handle the Web UI should be kept separate.

소프트웨어개발은 문제해결로 문제영역을 갖고, 문제영역의 변경이 해결책 영역의 변경을 야기합니다. 이러한 이유로 변경에 대응하기 위해서 해결책영역의 구조를 문제영역의 구조와 동일하게 하거나 최대한 맞추는 것이 좋습니다. 문제영역의 구조를 반영한 해결책 구조는 기술에 대한 고려가 없는 논리적인 구조입니다.

위에 제시한 기준들은 문제영역의 구조를 기반으로 해결책 영역의 구조를 구성하고 난 이후에 고려해야 할 사항들입니다.

분할스타일은 모듈스타일의 일종이니 분할스타일의 구성요소는 모듈이 됩니다. 관계는 전체와 부분의 관계를 나타내는 is-part-of가 사용됩니다. 제약사항은 당연한 것이지만 전체와 부분이 서로 전체와 부분이 되는 순환관계가 되어서는 안됩니다. 또한 하나의 모듈은 하나의 부모에만 속해야합니다. UML의 컴포지션 관계에 해당합니다. 하나의 모듈이 하나의 부모에게만 속해야 한다는 제약을 통해 모듈이 설계 시의 요소라는 것을 알 수 있습니다. 

UML에서 다른 모듈을 포함하는 모듈은 패키지로 나타내고, 다른 모듈을 포함하지 않는 모듈은 클래스로 나타냅니다. 책임성과 같은 다른 속성들은 주석을 사용할 수 있고, 특별한 종류의 모듈을 나타내기 위해 스테레오타입을 사용할 수도 있습니다.

다른 모듈을 포함하는 모듈에 패키지를 사용하는 방법은 속성이나 오퍼레이션을 표현할 수 없는 한계가 있습니다. RSM에서는 이러한 한계를 극복하기 위해 모듈은 모두 동일한 구조와 동일한 표현법을 갖도록 하고 있습니다. RSM에서는 모듈을 클래스를 확장한 기호를 사용해서 표현합니다. RSM 클래스는 속성 영역과 오퍼레이션 영역에 추가적으로 구조 영역을 갖습니다. 구조 영역에는 전체를 구성하는 컬레보레이션과 부분들과 그들 사이의 관계가 표현됩니다. 

모듈은 서로 다른 작업자들에게 할당되어 구현되고 실행되어야 합니다. 따라서 모듈 스타일들은 시앤시 스타일과 할당 스타일들과 밀접한 관계를 갖습니다.

이 책에서는 몇 가지 분할 스타일에 대한 예들을 보여주고 있습니다. 이들은 모두 행위 중심적이 아니라 구조 중심적입니다. 구조는 행위에 의해서 결정된다는 개념이 없는 것입니다. 그래서 다수의 클래스를 그저 분류한 수준으로 결과가 나옵니다.  RSM은 행위형식화를 통해 행위중심적인 설계를 합니다. 구조는 행위형식화의 결과로 도출됩니다.

온라인 예제인 Adventure Builder는 아래 링크에서 볼 수 있습니다.

https://wiki.sei.cmu.edu/sad/index.php/Main_Page

 

사용 스타일(Uses Style)

부분들은 협력을 위해 서로를 사용하기 때문에 사용 스타일의 등장은 자연스러운 것입니다. 분할 스타일이나 사용 스타일은 사실 스타일이라기 보다는 전체와 부분 개념의 일부일 뿐입니다. 전체와 부분에 대한 깊은 이해가 없는 상태에서 이들은 단지 공통적으로 등장하는 스타일이 된 것입니다.

사용 스타일의 구성요소 또한 모듈이고 그들 사이의 관계는  depends-on의 한 종류인 use입니다.

UML에는 의존의 일종인 use 관계를 지원합니다. 모듈은 인터페이스를 가질 수 있습니다. 이때에는 의존의 대상은 인터페이스가 됩니다.

 

일반화 스타일(Generalization Style)

일반화 스타일 또한 스타일이라기 보다는 개념에 해당합니다. 일반화에 대한 개념을 분명히 이해한다면 이것 또한 스타일로 등장하지 않았을 것입니다.

일반화에는 생성 개념인 클래스들 사이의 일반화가 있고, 사용 개념인 연관역할들 사이의 일반화가 존재합니다. UML에서는 전자를 일반화 관계로 나타내고 후자를 실현 관계로 나타냅니다.  

일반화 스타일의 구성요소 또한 모듈이고 그들 사이의 관계는 is-a입니다.  하나의 모듈은 다수의 모듈을 부모로 가질 수 있습니다. 일반화 관계의 사이클은 허용하지 않습니다.

다수의 모듈을 부모로 가질 수 있다는 것은 일반화에 대한 잘못된 이해에서 나온 것입니다. 이와 유사한 맥락에서 객체지향 프로그래밍 언어에서 다중상속 또한 그렇습니다. RSM에서는 하나의 하위 클래스는 하나의 상위 클래스만을 갖습니다.

일반화 스타일에서는 UML의 일반화와 실현 기호를 사용해서 표현할 수 있습니다.

 

레이어 스타일(Layered Style)

레이어는 모듈을 포함하는 모듈입니다. 다른 모듈들에 비해 특이한 점은 모듈들이 배치 순서로 관계를 맺는 다는 것입니다. 상위에 배치된 모듈은 하위에 배치된 모듈에 접근할 수 있지만 하위에 배치된 모듈은 상위에 배치된 모듈에 접근할 수 없습니다.

레이어 스타일의 구성요소는 특별한 종류의 모듈인 레이어입니다. 레이어들 사이에는 depends-on의 특별한 형태인 allowed-to-use를 사용합니다. 모든 모듈은 정확히 한 레이어에 할당되어야 하고 최소한 두개의 레이어가 있어야 하며 상위 레이어에서만 하위 레이어로 접근할 수 있습니다.

레이어 스타일에서는 UML의 패키지 표현과 <<allowed to use>> 스테리오 타입을 갖는 의존 기호를 사용해서 표현할 수 있습니다.

레이어는 종종 티어(tier)와 혼동되곤 합니다. 티어는 런타입에 대한 것으로 시앤시 스타일의 일종입니다.

 

애스펙트 스타일(Aspects Style)

기능 요구들의 대부분은 각각의 기능별로 영역을 갖고 다른 기능들과 잘 섞이지 않습니다. 하지만 비기능은 여러 기능들에 공통적으로 요구되는 것들이 많습니다. 비기능 요구와  같이 다수의 영역들을 가로질러 걸친 관심사라는 의미로 crosscutting concerns이라고 합니다.

기능 요구에 의해서 기능구조가 결정됩니다. 기능 요구는 문제영역의 것으로 문제영역을 통해 도출됩니다. 하지만 비기능요구는 문제영역에서 제시되기는 하나 기술적인 부분이 주를 이루고 이를 위한 구조 또한 기술적인 구조가 주를 이룹니다.

아키텍처는 기능구조를 먼저 문제영역을 통해 구성하고, 비기능요구를 만족할 수 있는 비기능구조를 구성해야 합니다. 비기능구조는 다수의 기능구조들에 걸쳐지기 때문에 독립된 애스펙트들을 만들고 그들을 기능구조에 적용할 수 있도록 해야 합니다. 저는 개인적으로 애스펙트들을 기능구조에 적용하는 것을 색깔을 입힌다라고 합니다.

The goal of designing and implementing crosscutting concerns in separate aspect modules is to improve modifiability of the modules that deal with the business domain functionality.

애스펙트 스타일은 특별히 AOP를 사용해서 구현할 때 유용합니다.

애스펙트 스타일의 구성요소는 특별한 종류의 모듈인 애스펙트입니다. 특정한 모듈이 애스펙트를 적용하는 것을 bind한다고 하고, crosscuts 관계를 사용해서 표현합니다. 하나의 애스펙트는 하나 이상의 모듈에 crosscut될 수 있습니다. 합니다.

애스펙트 스타일의 애스펙트는 <<aspect>> 스테레오타입을 갖는 UML의 클래스로 표현됩니다. crosscut 관계는 스테레오타입을 갖는 의존관계로 표현할 수 있습니다. 하지만 그렇게 하면 애스펙트의 사용빈도에 따라 너무 많은 관계가 작성되어 다이어그램 이해를 어렵게 할 수 있습니다. 좀 더 나은 방법은 crosscut 관계를 표시하지 않고 노트를 사용해서 해당 애스펙트가 어떤 모듈들에 사용될지를 기술하는 것입니다.

 

데이터 모델 스타일

스타일로 설명하기에는 너무 넓은 영역이다.

 

 

이 장에서 제시하는 스타일 중에는 스타일로 제시하기에는 좀 탐탁치 않은 것들이 있습니다. 스타일로 분류된 것들 중에서도 특정한 이유를 갖고 선택해야 하는 것들이 아니라 당연히 적용해야 하는 기법 수준으로 분류할 만한 것들도 있습니다.

 

RSM에서는

- 분할 스타일과 사용 스타일은 스타일이라고 보다는 전체와 부분의 개념의 일부분으로 봅니다. 전체와 부분의 개념에 충실하면 자연스럽게 전체가 부분들로 분할됩니다.

- 일반화 스타일 또한 스타일이라기 보다는 일반화 개념의 일부에 해당하는 것으로 봅니다.

- 데이터 모델 스타일은 스타일로 분리하기 보다는 하나의 영역으로 봅니다. 

- 레이어와 애스펙트 스타일은 도메인을 중심으로 했을 때 반드시 적용해야 하는 스타일로 구분합니다. 

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.10.04 11:19

소프트웨어시스템은 점점 더 복잡해지고 있기 때문에 소프트웨어 개발자는 복잡성을 다룰 방법이 필요합니다.

복잡성을 다루는 대표적인 방법은 분할정복입니다. 좀 더 본질적으로 말하면 하나의 실체 또는 개념을 전체와 부분으로 구조화하는 것입니다. '구조를 갖는다'는 말에는 이미 전체와 부분에 대한 이야기가 내포되어 있는 것입니다.

소프트웨어개발이 처한 이러한 상황에서 '어떻게 하나의 큰 전체를 여러 개의 부분들과 그들 사이의 관계로 구조화할 것인가'에 대한 답을 구하려는 노력은 당연한 것입니다. 컴포넌트기반개발은 이러한 배경에서 당연하게 등장한 것입니다.

소프트웨어 개발에 있어 전체와 부분에 대한 이해는 근본적인 이해 없이 임시변통적으로 다루어져 왔습니다. 이 책의 모듈에 대한 개념 또한 그러합니다.

RSM은 두 축으로 이루어져있는데, 그 하나의 축이 '전체와 부분'입니다. 전체와 부분에 대한 이해는 소프트웨어개발에 있어 근본적인 것입니다. 

 

 

이 장에서는 소프트웨어의 모듈 구조를 문서화하는 방법을 살펴봅니다.  문서에는 모듈뷰로 기술됩니다. 모듈뷰에는 시스템의 주요한 기본 구현 단위인 모듈과 그들 사이의 관계가 기술됩니다. 

In this chapter and the next, we look at ways to document the module structures of a system’s software. Such documentation enumerates the principal implementation units, or modules, of a system, together with the relations among these units. We refer to these descriptions as module views.

 

 

모듈이란?

A module is an implementation unit of software that provides a coherent set of responsibilities.


A responsibility is a general statement about an architecture element and what it is expected to contribute to the architecture. This includes the actions that it performs, the knowledge it maintains, the decisions it makes, or the role it plays in achieving the system’s overall quality attributes or functionality.

오늘날의 객체지향개발에 있어 주요한 구현 단위는 클래스입니다. 컴포넌트기반개발에서는 컴포넌트 수준까지 구현 단위로 다룹니다. 컴포넌트기반개발의 컴포넌트와 클래스소프트웨어 시스템의 주요한 모듈입니다. 컴포넌트기반개발의 컴포넌트는 이 책의 모듈뷰의 모듈과 시앤시뷰의 컴포넌트를 합한 의미를 갖습니다.

구현단위는 기능적으로 또는 비기능적으로 아키텍처에 기여를 하기 위한 것입니다. 그것이 구현단위의 존재목적입니다.  

 

 

모듈 사이에 가능한 관계는?

Is part of, Depends on, Is a

이들 관계에 대해서는 이번 장에서는 이런 것들이 있다는 정도만 살펴보고 다음 장에서 자세히 다루도록 합니다.

 

 

어떤 속성들이 있는가?

Properties of modules that help to guide implementation or are input to analysis should be recorded as part of the supporting documentation for a module view. The list of properties may vary but is likely to include the following:

Name. A module’s name is, of course, the primary means to refer to it. A module’s name often suggests something about its role in the system. In addition, a module’s name may reflect its position in a decomposition hierarchy; the name “A.B.C,” for example, refers to a module C that is a submodule of a module B, itself a submodule of A.

Responsibility. The responsibility property of a module is a way to identify its role in the overall system and establishes an identity for it beyond the name. Whereas a module’s name may suggest its role, a statement of responsibility establishes it with much more certainty. Responsibilities should be described in sufficient detail to make clear to the reader what each module does.

Visibility of interface(s). When a module has submodules, some interfaces of the submodules may have internal purposes; that is, the interfaces are used only by the submodules within the enclosing parent module. These interfaces are not visible outside that context and therefore do not have a direct relationship to the parent interfaces. Different strategies can be used for those interfaces that have a direct relationship to the parent interfaces.

Implementation information. Because modules are units of implementation, it is useful to record information related to their implementation from the point of view of managing their development and building the system that contains them. Although this information is not, strictly speaking, architectural, it may be useful to record it in the architecture documentation where the module is defined.

구현 정보에는 다음과 같은 것들이 포함됩니다.

모듈은 구현되는 것이고 하나 이상의 소스코드 단위에 매핑될 수 있기 때문에 이에 대한 언급이 필요할 수 있습니다. 테스트 정보와 관리 정보가 언급될 수 있습니다. 구현제약사항들이 언급될 수 있씁니다.  

 

 

모듈뷰를 문서화하는 이유는?

Expect to use module views for

• Providing a blueprint for construction of the code
• Facilitating impact analysis
• Supporting requirements traceability analysis• Planning incremental development
• Explaining the functionality of the system and the structure of the code base
• Supporting the definition of work assignments, implementation schedules, and budget information
• Showing the structure of information to be persisted

모듈뷰는 시스템이 어떻게 구현단위들로서 구조화되는지에 중점을 두는 뷰입니다. 

모듈은 구현단위로 구축을 위한 설계도이다. 영속성을 갖는 정보구조 또한 모듈로 표현된다. 변경에 대한 영향이나 추적은 구조를 알아야 한다. 점진적 개발이나 작업할당과 일정과 비용을 계획하려면 구조를 알아야 한다. 구조를 이루는 모듈은 독립적으로 개발가능해야 한다.

 

 

모듈뷰에 사용되는 UML 기호들은? 

패키지 다이어그램과 클래스 다이어그램에 사용되는 것들입니다. 영속성을 갖는 정보구조를 표현하기 위해 ERD에 사용하는 기호들을 추가할 수 있습니다.  
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.09.27 21:41
The starting point of architecture design is most often a preexisting package of design decisions. A most useful package of design decisions is the architecture style.

 

아키텍트가 하는 의사결정은 시스템 수준의 요구사항과 관련된 것입니다.

RSM은 소프트웨어 개발을 문제해결로 봅니다. 소프트웨어 개발자는 문제를 이해하고 해결책을 구축합니다. 소프트웨어 개발에 있어 해결책은 설계로 시작해서 설계로 끝납니다. 설계란 다양한 대안들을 고안하거나 탐색하고 그 중 하나를 선택하는 의사결정입니다.

소프트웨어 개발에 있어 해결책 구축은 끊임 없는 의사결정의 연속입니다. 소프트웨어 개발이 복잡해짐에 따라 의사결정은 좀 더 다양해 집니다.  기업에서 CEO가 내릴 수 있는 의사결정과 중간 관리자가 내릴 수 있는 의사결정을 구분하는 것과 같이 좀 더 영향력이 큰 것과 그렇지 않은 것을 구분하기 시작한 것입니다.

아키텍트는 설계자 입니다. 다른 설계자들 보다 좀 더 영향력 있는 의사결정을 합니다.

소프트웨어 개발은 요구사항으로 부터 시작하고, 개발된 시스템은 이를 만족해야 합니다. 요구사항이 바뀌면 시스템의 구조 또한 바뀔 수 있습니다. 따라서 영향력이 좀 더 큰 의사결정이란 시스템 수준의 요구사항과 관련된 의사결정이 됩니다.

 

세 가지 뷰와 스타일

무엇인가를 할 때 아무것도 없는 상태에서 시작하는 것은 어리석은 것입니다. 선진들의 지혜와 지식을 활용해야 합니다. 선진들의 지혜와 지식들 중에 반복적으로 사용될 수 있는 것들은 스타일이나 패턴으로 정리됩니다. 소프트웨어 아키텍처링에 있어서도 이러한 스타일들이나 패턴들이 존재합니다. 이 책에서는 아키텍처 스타일을 사용하는 것에 중점을 두고 있습니다.

1장에서 5장까지는 널리 사용되는 중요한 아키텍처 스타일들을 다루고 있습니다. 아키텍처 스타일들은 뷰를 기준으로 분류하고 있습니다. 하나의 뷰에 하나의 스타일이 있습니다. 문서화는 뷰를 기준으로 합니다.

뷰는 모듈(module)뷰와 시앤시(c&c)뷰와 할당(allocation)뷰로 구분하고 있습니다.

전체 개념의 이름을 지을 때는 주요 구성요소를 선택하거나 주요 행위를 선택합니다. 모듈뷰는 주요 구성요소인 모듈을 선택했으며, 시앤시뷰 또한 주요 구성요소인 컴포넌트와 커넥터를 선택했습니다. 할당뷰는 주요 행위인 할당을 선택했습니다.  

 

 

이 책에서 스타일 설명에 사용하는 공통 구조는?       

1. Overview

개요를 기술한다. 

2. Element types, relation types, and properties

아키텍처를 구성하는 요소들과 그들 사이의 관계들과 속성들을 기술한다.

3. Constraints

적용에 있어서의 제약사항을 기술한다.

4. What it's for

이 스타일을 선택해야 하는 이유를 기술한다.

5. Notation

그래픽 또는 텍스트 기호로 내용을 기술한다. 

우리는 UML 표현만 사용할 것이다.

6. Relation to other styles

다른 스타일들과의 관계를 기술한다.

7. Examples

적용 예를 기술한다.

개인적으로 이 책의 가치는 아키텍처 스타일에 대한 정리하고 생각하고, 세미나 진행 또한 이에 중점을 둘 것입니다.

아키텍처 스타일을 선택하려면 먼저 자신이 해결해야 하는 문제가 무엇인지를 알아야 합니다. 따라서 우리는 이 책에서 제시하는 스타일들을 What it's for를 중심으로 재 정리할 것입니다. 그리고 이를 기반으로 지원 도구를 개발할 것입니다.  

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2011.04.11 17:23

본격적으로 들어가기에 앞서, 이 책 전반에 걸쳐 등장하는 개념들을 다룹니다. 

우리는 이 부분을 읽으면서 다음과 같은 질문에 대한 답을 얻으려고 노력해야 합니다. 

소프트웨어 아키텍처? 소프트웨어 아키텍처 문서화?
아키텍처 뷰? 아키텍처 스타일?
잘 된 아키텍처 문서화?

 


소프트웨어 아키텍처?  
아키텍처는 아직까지 하나의 통일된 정의를 갖지 못하고 있습니다. SEI 웹사이트에 150개가 넘는 정의를 수집해놓았다고 합니다. 이 책에서는 2003년에 출판된 Bass, Clements, Kazman의 Software Architecture in Pranctice 2nd ed의 정의와 비슷한 정의를 사용한다고 합니다. 

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relations among them.
By “externally visible properties,” we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. (Bass, Clements, and Kazman 2003, p. 27)

 

아키텍처 모델링이 필요합니다.

아키텍처는 복잡한 것입니다. 따라서 복잡한 것을 가장 잘 다룰 수 있는 방법인 모델링 기술을 사용할 수 있습니다. 다수의 뷰를 가지고 아키텍처를 다룬다는 것은 모델링 기술을 사용한다는 의미를 담고 있습니다. 복잡한 것을 다수의 관점에 따라 추상화하는 것이 모델링입니다.

 

아키텍처는 구조이고, 아키텍처링은 구조를 짜는 것입니다.

구조는 구성요소들과 그들 사이의 관계로 드러납니다. 구성요소들은 속성들을 갖기 때문에 외부적으로 드러나는 속성 또한 구조로 표현되어야 합니다. 구조가 어떻게 생겼는지는 어떤 구성요소들이 있고 그들 사이에 어떤 관계가 있는지로 표현됩니다.

RSM에서는 모든 것을 객체로 봅니다. 시스템은 큰 객체입니다. RSM에서 객체 구조는 아래 그림과 같이 모두 동일하게 컬레보레이션과 부분들과 컬레보레이션과 부분들 사이의 관계로 구성됩니다.

대부분은 소프트웨어 개발 방법론이나 접근법들이 아키텍처라고 하는 것은 객체가 시스템일 때의 구조를 말하는 것입니다.

 

부분과 컬레보레이션은 속성을 가질 수 있습니다.

시스템에 대한 요구사항은 기능적인것과 비기능적인 것으로 나뉘어집니다. 이들 요구사항을 만족하기 위해 부분과 컬레보레이션은 특별한 속성을 갖는 것입니다. 

기능요구에 해당하는 속성은 클래스의 속성으로 표현됩니다. 비기능요구에 해당하는 것은 별도로 관리되어야 합니다.

기능요구에 해당하는 속성은 도메인에서 나오기 때문에 아키텍처에서 주로 다루어지는 속성은 비기능요구에 해당하는 속성들입니다.

 

왜 다양한 정의들 중에 이 정의를 선택했을까?

The definition emphasizes the plurality of structures present in every software system.
These structures, carefully chosen and designed by the architect, are the key to achieving and reasoning about the system’s design goals. And those structures are the key to understanding the architecture.
Therefore, they are the focus of our approach to documenting a software architecture.
Structures consist of elements, relations among the elements, and the important properties of both. So documenting a structure entails documenting those things.

 

 

아키텍처를 처음 접하는 분들이 많이 하는 질문 중의 하나는 '아키텍처와 설계가 어떻게 다른가?"입니다.
저자는 이 부분에 대해서 명쾌한 설명을 합니다.

Architecture is design, but not all design is architectural.

The architect draws the boundary between architectural and nonarchitectural design by making
those decisions that need to be bound in order for the system to meet its development, behavioral, and quality goals. All other decisions can be left to downstream designers and implementers.

Decisions are architectural or not, according to context. If structure is important to achieve your system’s goals, that structure is architectural.
But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.

 

아키텍처적인 의사결정은? 

아키텍처를 이야기할 때는 객체가 시스템인 경우입니다. 아키텍처링은 시스템에 대한 기능요구와 비기능요구를 만족시킬 수 구조를 짜는 것입니다. 저자가 말하는 행위는 기능요구이고, 개발과 품질은 비기능요구입니다.

시스템 수준에서 기능요구와 비기능요구는 고객으로 부터 제시됩니다. 따라서 아키텍처적인 의사결정은 고객의 기능/비기능 요구사항과 직접적으로 관련된 의사결정라고 할 수 있습니다.

 

다음과 같은 충고도 새겨 둘 만 합니다. 

And (repeat after me) we all promise to stop using the phrase “detailed design.”
Try “nonarchitectural design” instead.

 

 

소프트웨어 아키텍처 문서화?  
우리는 소프트웨어 아키텍처를 문서화하려고 이 책을 읽고 있기 때문에, 왜 소프트웨어 아키텍처를 문서화해야 하는지에 대해서는 간단히 몇 문장을 인용하고 넘어갑니다. 나중에 누군가를 설득할 필요가 있을 때 다시 이 부분을 읽으면 됩니다.  

Doing business without advertising [or designing an architecture without documenting it] is like winking at a girl in the dark. You know what you’re doing, but nobody else does. —Steuart Henderson Britt

Fundamentally, architecture documentation has three uses.
1. Architecture serves as a means of education.
2. Architecture serves as a primary vehicle for communication among stakeholders.
3. Architecture serves as the basis for system analysis and construction.



 

아키텍처 뷰?
아키텍처는 한 번에 이해할 만큼 단순하지 않습니다. 복잡합니다. 다수의 관점을 가지고 다루어야 합니다. 

A documentation package for a software architecture can be composed of one or more view documents and documentation that explains how the views relate to one another, introduces the package to its readers, and guides them through it.

아키텍처 뷰에는 여러가지가 있습니다. 그 중 잘 알려진 것이 4+1 뷰 입니다. 이 책에서는 Module, Component-and-Connector(C&C), Allocation과 같이 3개의 뷰를 제공합니다. 

RSM에서는 하나의 컴포넌트 단위로 설계하고 구현합니다. 따라서 RSM의 컴포넌트와 Module뷰의 모듈과 C&C 뷰의 컴포넌트를 구분할 수 있어야 합니다. 이에 대해서는 각각의 뷰를 다루는 부분에서 설명하도록 하겠습니다.  

 

 

아키텍처 스타일?

An architecture style is a “specialization of element and relation types, together with a set of constraints on how they can be used”.

패턴은 특정 컨텍스트를 중심으로 문제와 해결책을 설명하지만 스타일은 컨텍스트를 이야기하지 않습니다. 패턴이 스타일에 비해 좀 더 구체적인 것입니다.

아키텍처 스타일과 아키텍처 패턴이 어떻게 다른지를 설명하는데, 크게 관심 갖지 않아도 될 것 같습니다. 사실 이 책에서 제시하는 스타일 중에 아키텍처 패턴에서 언급되는 것들이 많이 있습니다.

 

 

문서화를 잘하기 위한 7가지 규칙

1. Write documentation from the reader’s point of view.
2. Avoid unnecessary repetition.
3. Avoid ambiguity.
4. Use a standard organization.
5. Record rationale.
6. Keep documentation current but not too current.
7. Review documentation for fitness of purpose.
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2011.04.09 20:16

이 세미나는 The Certified RSMer Candidate들의 원서 읽는 속도 향상을 위한 세미나로 진행하였습니다. 진행되었던 내용 중에 책의 내용에 해당하는 부분만 온라인 세미나로 정리할 것입니다. 

 

저자는 이 책의 purpose가 다음과 같은 질문에 답하는 것이라고 합니다.  

How do you document an architecture
so that others can successfully
use it,
maintain it.
and
build a system from it? 

 

이 책의 goal에 대해서 다음과 같이 언급합니다. 

The goal of this book is
to help you decide what information about an architecture is important to capture
and
to provide guidelines, notations, and examples for capturing it.

 

이 책의 goal에 따라, 우리는 다음과 같은 질문을 갖고 책을 읽어야 합니다.

아키텍처에 있어 중요한 정보는 어떤 것들일까?
그러한 정보는 어떻게 capture하고 표현할 수 있을까?

 

다음 링크에서, 이 책에서 제시하는 접근법과 템플릿을 사용하여 소프트웨어 아키텍처를 문서화한 예를 볼 수 있습니다. 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
prev"" #1 next

티스토리 툴바