Reference Model
a Reference Model is a division of functionality together with data flow between the pieces. A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. Arising from experience, reference models are a characteristic of mature domains and are often obtained by domain analysis or other group activity. Can you name the standard parts of a compiler to a database management system? Can you explain in broad terms how the parts work together to accomplish their collective purpose? If so, it is because you have been taught a reference model of these applications.
Technical Reference model
A Technical Reference Model (TRM) is a taxonomy that provides the following :
◎ A consistent set of service areas, interface categories, and relationships used to address interoperability
and open-system issues
◎ Conceptual entities that establish a common vocabulary to better describe, compare, and contrast systems
and components
◎ A basis (an aid) for the identification, comparison, and selection of existing and emerging standards
and their relationships
The TRM organizes the Standards Profile and any Standards or Technology Forecast documents. It can also organize technology infrastructure documentation. Frequently, some combination of the documents organized using the TRM are presented in a single document.
Reference Architecture
A reference architecture is the generalized architecture of several end systems that share one or more common domains. The reference architecture defines the infrastructure common to the end systems and the interfaces of components that will be included in the end systems.The reference architecture is then instantiated to create a software architecture of a specific system. The definition of the reference architecture facilitates deriving and extending new software architectures for classes of systems. A reference architecture, therefore, plays a dual role with regard to specific target software architectures. First, it generalizes and extracts common functions and configurations. Second, it provides a base for instantiating target systems that use that common base more reliably and cost effectively.The concept of a reference architecture is very similar to that of an application framework in the parlance of object technologists and to that of a product line architecture. In fact, the terms reference architecture and product line architecture are often used interchangeably. A product line architecture is the architecture for a software product line.1 Within a government context, the establishment of a reference architecture that can span a broad range of missions, development organizations, and operations concepts is motivated by the desire of end-system customers and integrators. These groups wish to achieve high levels of strategic software reuse and interoperability. The reference architecture provides specifications
for both system and component developers.
Software Architecture
The software architecture of a program or computing system is the structure
or structures of the system, which comprise software components, the externally
visible properties of those components, and the relationships among
them [Bass 98].
The software architecture represents the earliest software design decisions. These design decisions are the most critical to get right and the most difficult to change downstream in the system development life cycle. The software architecture is the first design artifact addressing reliability, modifiability, security, real-time performance, and interoperability goals and requirements.
There are many different views of a software architecture, and which one is relevant depends on the stakeholders and the system properties that are of interest. If we consider the analogy of the architecture of a building, various stakeholders such as the construction engineer, the plumber, and the electrician all have an interest in how the building is to be constructed. However, they are interested in different structural units and different structural relationships; they each have a different view of what constitutes the architecture. Each of their views of
architecture is valid. Each represents a structure that maps to one of the structural goals of the building, and all views are necessary to represent the architecture of the building fully. Similarly, a software architecture has a variety of stakeholders, including possibly the development organization, the end user, the system maintainer, the operator, and the acquisition organization. Each of these stakeholders has a vested interest in different system properties and goals that are structurally represented by different views of the system. These different properties
and goals and their corresponding architectural views are important to understand and to analyze in order to reason about the appropriateness and the quality of the architecture.
Reusable Application Framework
Reusable Application Framework은 공식적인 용어는 아니다 일반적으로 말하는 Application framework을 의미한다고 보면 된다.
Application Framework을 2가지로 분류할 수 있는데, 하나는 프로젝트에서 만들어지는 것이고 다른 하나는 프로젝트와 상관없이 외부에서 만들어 지는 것이다. 전자는 과거에 보통 프로젝트에서 공통모듈의 형태를 취하고 있었으며 객체에 와서 프레임웍으로 발전되었으며 본 문서에서는 이를 Project Framework이라 명명하고 있다. 후자의 경우에는 Apache Struts와 같이 임의의 시스템에서 사용할 수 있는 프레임웍이다.
Architectural Style
An architecture style is a description of component types and a pattern of their runtime control and/or data transfer. A style can be thought of as a set of constraint on an architecture - constraints on the components on the component types and their patterns of interaction - and these constraints define a set of family of architectures that satisfy them. For example, client-server is a common architectural style. Client and server are two component types, and their coordination is described in terms of the protocol that the server uses to communicate with each of its clients themselves are not identified, and there is no discussion of what functionality(other than implementation of the protocols)has been assigned to any of the clients or to the server. Countless architectures are of the client-server style as we have defined it, but these architectures are different from each other.An architectural style is not an architecture, then, but it still conveys a useful image of the system - it imposes useful constraints on the architecture
아키텍쳐 스타일과 아키텍쳐패턴은 유사하게 사용되고 있다. 그들은 모두 각각의 요소에 대한 타입과 요소들 사이의 상호 작용에 대해서 정의하고 있다.
그런데 다른 패턴(코딩패턴, 분석패턴,디자인패턴, 도메인패턴, 조직패턴)들과 명확히 구분하기 위해 주로 아키텍쳐 스타일이 많이 사용된다
Design Patterns
Design Patterns are applicable towards the end of coarse-grained design, when refining and extending the fundamental architecture of a software system. For example deciding on the basic communication mechanisms between subsystems. Design patterns are also applicable in the detailed design stage for specifying local design aspects, such as the required support for multiple implementation of a component
Refactoring
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
Product-line architecture
Product-line 아키텍쳐는 주로 조직이나 회사의 프로덕트의 집합에 적용되는 개념이다.
회사에서 동일한 유형의 제품을 개발하는데 있어 그 제품들을 일반화하는 데서 발전한 개념이다.
공통 디자인과 일부 구현부를 재사용함으로써 일관되고 저가에 제품을 개발하는데 초점이 맞추어져 있다.
MS의 각종 제품들이 상호 연동되고 동일한 DLL파일을 공유하도록 되어 있는 것에서 가장 근접한 예를 찾을 수 있다. 그러나 MIS 프로젝트를 수행하는 회사에서는 개념자체를 직관적으로 적용하는데는 약간의 어려움이 있을 수 있다.
| |
Define Element Types and How They Interact
|
Defines a Mapping of Functionality to Architecture Elements
|
Define Instances of Architecture Elements
|
|
|
YES |
Sometimes |
NO |
|
|
YES |
YES |
NO |
Product-line Architecture
|
YES |
YES |
Sometimes |
|
|
YES |
YES |
YES |
