Trujillo Nymann (alarmcoal3)
full text links:
Software architecture can be summarized as
(1) structural model: This is actually the most intuitive and common modeling method. This method describes the structure with the components, connectors and other concepts of the architecture, and tries to reflect the important semantic content of the system through the structure, such as the configuration, constraints, implied assumptions, styles, properties etc. The core of structural model research is architecture description language.
(2) Frame model: the frame model resembles the structure model, nonetheless it focuses less on the details of the structure and more on the entire structure. The framework model mainly is aimed at some special problems and establishes a structure that only is aimed at and adapts to the problems.
(3) Dynamic model: dynamic model is a supplement to structure or frame model, which studies the behavior of "large particles" of the system. Like describe the reconfiguration or evolution of a system. Dynamic can make reference to the configuration of the entire structure of the device, the establishment or removal of communication channels or the calculation process. This kind of system is often incentive type.
(4) Process model: process model studies the steps and processes of constructing a system. Therefore the structure may be the result of following some process script.
(5) Function model: the model considers that the architecture comprises several functional components in line with the hierarchy, and the lower layer provides services to the upper layer. It may be regarded as a special framework model.
Five, but each has its advantagesIt could be right to unify the device, so some one proposed the "4 + 1" view model:
logical view: logical view is targeted on functions, including not merely the visible functions of users, but also the "auxiliary function modules" that must be provided to appreciate the functions of users; they may be logical layer, function modules, and so forth
Development view: development view is targeted on the package, including not merely the foundation program to be written, but also the third-party SDK and ready-made framework, class library you can use directly, as well as the system computer software or middleware which the developed system will run. There might be some mapping relationship involving the development view and the logical view: for instance , the logical layer is usually mapped to multiple packages.
Processing view: processing view centers around process, thread, object and other runtime concepts, as well as related concurrency, synchronization, communication and other dilemmas. The relationship between processing view and development view: development view generally is targeted on the static dependency of packages at compile time, and these programs will be represented as objects, threads and processes if they run. Processing view centers around the interaction of these runtime units. Physical view: physical view targets just how to install or deploy the "target program and its own dependent runtime and system software" to the physical machine, and how to deploy the device and network to generally meet the reliability, scalability and other requirements of the application system. The partnership between physical view and processing view: the processing view pays special awareness of the dynamic execution of the prospective program, while the physical view pays focus on the static precise location of the target program; the physical view comprehensively considers the application system and the complete IT systemArchitecture view of interaction.
Scenarios: it can be thought to be the abstraction of the essential system activities, which organically connects the four views. In a sense, scenarios are the most significant requirement abstraction. When developing architecture, it can he
