锘??xml version="1.0" encoding="utf-8" standalone="yes"?> Modules are discrete units of software (binary and source).
Binary modules are instantiated at run time and these instantiations are
commonly called components and connectors. A given module may contain the specifications for
several component types and connector types. The component (instances) may be of
a fixed number in some situations. For example, a Web server executable, when
launched, results in a single Web server component instance. The Web server module is the binary code that exists as a set of
program files. The Web server component is a running
instance of the Web server. I have seen some confusion over the use of the terms module, component, and connector. A module is a discrete unit
of design that is composed of a hidden set of elements and a set of shared
elements. Modules have high internal cohesion and low external coupling. Modules
may represent the physical packaging of the application's binary code, which can
be described further by component types and connector types. Components and
connectors describe the physical instantiation of a system. The term component is often used to mean a component type or module. A
module refers to a unit of software that can be designed,
implemented, and compiled into a deliverable executable system or subsystem; it
is a unit of execution. A component is a runtime entity,
the definition of which exists in a module. A classic modular architecture is a
client-server system. The client and the server are two modules. The server
exports some elements such as a set of publicly visible relational database
tables and views. The client knows about this publicly visible schema. The
client and server are unaware of the internal composition of the other.
1 .鍙傝冧竴涓嬨婅蔣浠舵灦鏋勮壓鏈嬩竴涔︼紝Stephen T. Albin 鍦ㄩ噷闈㈡弿榪幫細
妯″潡寮忚蔣浠惰鍒掑垎鎴愮嫭绔嬪懡鍚嶇殑錛屽茍鍙鐙珛璁塊棶鐨勬垚鍒嗐傛ā鍧楀垝鍒嗭紝綺掑害鍙ぇ鍙皬銆傚垝鍒嗕緷鎹槸瀵瑰簲鐢ㄩ昏緫緇撴瀯鐨勭悊瑙c?/span>
榪欎釜瀹氫箟錛屼技涔庢湁娌℃湁銆婅蔣浠舵灦鏋勮壓鏈嬮偅涔堜弗鏍箋傛病鏈夊畾涔夊叿浣撲粈涔堜負“琚嫭绔嬭闂?#8221;鐨勬垚鍒嗐?br>3. 銆奃ocumenting_Software_Architectures銆?br> A module tends to refer first and foremost to a
design-time entity. Parnas's foundational work in module design (1972) used
information hiding as the criterion for allocating responsibility to a module.
Information that was likely to change over the lifetime of a system, such as the
choice of data structures or algorithms, was assigned to a module, which had an
interface through which its facilities were accessed.
鍏惰錛屾ā鍧楁槸璁捐鏃剁殑瀹炰綋錛岀壒鐐規槸淇℃伅闅愯棌鍜岃兘閫氳繃妯″潡鐨勬帴鍙h闂傚湪浠嬬粛妯″潡瑙嗗浘鏃朵粬璇達細
A module is a code unit that implements a set of responsibilities. A module can
be a class, a collection of classes, a layer, or any decomposition of the code
unit. Every module has a collection of properties assigned to it. These
properties are intended to express the important information associated with the
module, as well as constraints on the module. Sample properties are
responsibilities, visibility information, and author. Modules have relations to
one another. Example relations are is part of or
inherits from.
---------------------------------------------------
涓嶅悓鐨勪綔鑰呮湁涓嶅悓鐨勭湅娉曪紝浣嗙患鍚堜竴涓嬶紝鎴戣涓烘ā鍧楀洜璇ユ槸涓涓嫭绔嬭璁$殑鍗曞厓錛屽茍涓哄叾浠栨ā鍧楁彁渚涜闂帴鍙c備篃灝辨槸璇達紝浠栨槸涓涓灦鏋勪腑鐨勮璁″厓绱狅紝浣嗕笉闄愬埗浠栫殑瀛樺湪妯″紡錛屼篃灝辨槸浠栨槸鎻愪緵浜嗗彲璁塊棶鎺ュ彛鑰屼笖瀹炵幇鏌愪竴鍔熻兘鐨勪竴涓疄浣擄紝鍙互鏄竴涓被鎴栦竴緇勭被鎴栧彲鎵ц紼嬪簭絳夈?br>
]]>