XML in UML Analysis and Design
If we gain a deep understanding of the conceptual models that define e-business processes and related information content, we can transform these logical models into alternative implementation languages, and reverse engineer the implementations into logical models. In my recent work, I've found it helpful to think in terms of model transformation instead of code generation, because implementation languages are also based on their own metamodel definitions. The Unified Modeling Language is a standard representation and graphical notation for describing these shared models. The important point is that we must think about the information content model without getting caught up in the details of implementation syntax.
Conceptual models of XML applications also improve communication with business stakeholders who are unfamiliar with the increasingly complex grammars of new XML schema and Web service definition languages. Whereas the DTD schema standard is easy to learn, the W3C XML Schema offers many more design alternatives, and the growing array of Web service specifications such as SOAP, WSDL and WSFL present further challenges. However, as in database systems, successful deployment of XML in large distributed systems depends on critical design decisions. UML profiles are used to describe these design choices when customizing the UML models for XML schemas and Web services.
But there are also several hundred preexisting XML schemas created by companies and industry consortiums, and the future world of Web services will yield a similar set of competing process and Web service interface specifications. Later in this series, I'll examine various approaches for reverse engineering XML schemas into UML, where they can be leveraged as part of complete e-business system analyses. XML fulfills only one part of any successful e-business application.
E-business integration must support the following general requirements:
(1) Actors agree on message content vocabularies, not APIs.
(2) Documents are validated against a known vocabulary, but should allow for extensions.
(3) Message content can be transformed from one vocabulary to another.
(4) Workflow processes and communication protocols are defined for document exchange.
(5) Legacy system adapters import and export XML.
E-business integration requirements are divided into three categories: shared business vocabularies, process workflow and messaging, and application integration. The use cases corresponding to these requirements are illustrated with a UML use case diagram in the figure above, in which the three categories are differentiated using shaded icons.
E-business Integration With XML
This high-level use case diagram includes three groups of typical XML requirements: vocabulary definition (clear), process modeling (light gray) and system integration (dark gray). (From D. Carlson's Modeling XML Applications with UML, p. 53 [Addison-Wesley, 2001].)
Four of the use cases depicted in the E-business Integration With XML diagram are related to the design of shared business vocabularies and schemas; they're illustrated with no shading in the diagram. The business analyst is responsible for defining one or more business vocabularies that are then used by the system integration specialist. The XML schemas are generated from the vocabulary definition, and are used as the basis for transforming and validating XML message contents. Because the XML schemas are automatically generated from the UML model, that use case doesn't show a direct interaction with an actor.
更多軟考資料請(qǐng)?jiān)L問(wèn):考試吧軟件水平考試欄目
希望與更多網(wǎng)友交流,請(qǐng)進(jìn)入考試吧軟件水平考試論壇
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |