uml資料庫

⑴ UML是什麼，包括哪些內容

解釋：
1、 UML -----The Unified Modeling Language is a standard language for writing software blueprints.The UML may be used to visualize, specify, construct, and document the artifacts of a software-intensive system.
2、 Stereotype-----A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of building blocks similar to existing ones but specific to your problem.
3、 Tagged value-------A taffed value is a property of a stereotype, allowing you to create new information in an element bearing that stereotype.
4、 Component--------A component is a replaceable part of a system that conforms to and provides the realization of a set of interfaces.
5、 Message-----A message is the specification of a communication among objects that conveys information with the expectation that activity will ensure
6、 Note-----A note is a graphical symbol for rendering constraints or comments attached to an element or a collection of elements.
7、 Constraints------A constraint is a textual specification of the semantics of a UML element, allowing you to add new rules or to midify existing ones.
8、 Interaction-----An interaction is a behavior that comprises a set of messages exchanged among objects in a set of roles within a context to accomplish a purpose.
9、 Action----An action is an executable computation that results in a change in state of the model or the return of a value.

簡答
1， UML中描述軟體體系結構的五種視圖及其內容？architecture view
@The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users,analysts,and testers.
@The design view of a system encompasses the classes,interfaces,and collaorations that from the vocabulary of the problem and its solution.
@The interaction view of a system shows the flow of control among its various parts,including possible concurrency and synchronization mechanisems.
@The implementation view of a system encompasses the artifacts that are used to assemble and release the physical system.
@The deployment view of a system encompasses the nodes that form the system`s hardware topology on which the system executes.
2， 建模的四項基本原則？principles of modeling
*The choice of what models to create has a profound influence on how a problem is attached and how a solution is shaped.
*Every model may be expressed at different levels of precision.
*The best models are connected to reality.
*No single model or view is sufficient.Every nontrivial system is best approached through a small set of nearly independent models with multipe viewpoints.
3，如何建模系統的接縫？modeling the seams in a system
To model the seams in a system:
!!Within the collection of classes and components in your system,draw a line around those that tend to be tightly coupled relative to other sets of classes and components.
!!Refine your grouping by considering the impact of change,
. Classes or components that tend to change together should be grouped together as collaborations.
!!Consider the operations and the signals that cross these boundaries, from instances of one set of classes or components to instances of other sets of classes and components.
!!Package logically related sets of these poerations and signals as interfaces.
!!For each such collabotation in your system,identify the interfaces it requires from(imports) and those it provides to others(exports).You model the importing of interfaces by dependency relationships,and you model the exporting of interfaces by realization relationships.
!!For each such interface in your system,document its dynamics by using pre-and postcongitions for each operation, and use cases and state machines for the interfaces as a whole.
4.如何建模系統的需求？modeling the requirements of a system
To model the requirements of a system:
//Establish the context of the system by identifying the actors that surround it;
//For each actor,consider the behavior that each expects or requires the system to privide;
//Name common behaviors as use cases.
//Factor common behavior into new use cases that are used by others;factor variant behavior into new use cases that extend more main line flows.
//Model these use cases,actors,and their relationships in a use case diagram;
//Adorn these use cases with notes or constraints that assert nonfunctional;you may have to attach some of these to the whole system.
5如何利用製品圖建模物理資料庫？modeling a physical database by artifact diagrams
1. For simple CRUD(create, read, update,delete) operations,implement them with standard SQL or ODBC calls;
2. For more-complex behavior(such as business rules), map them to triggers or stored proceres.
Guidelines:
&Identify the classes in your model that represent your logical database schema.
&Select a strategy for mapping these classes to tables.You will also want to consider the physical distribution or your databases.Your mapping strategy will be affected by the location in which you want yout data to live on your deployed system.
&To visualize,specify,construct,and document your mapping,create an artifact diagram that contains artifacts stereotyped as tables.
&Where possible,use tools to help you transform your logical design into a physical design.
6如何對注釋建模？modeling comments
*Put your comments as text in a note and place it adjacent to the element to which it refers. You can show a more explicit relationship by connecting a note to its elements using a dependency relationship.
*Remember that you can hide or make visible the elements of your model as you see fit.This means that you don`t have to which it is attached are visible.Rather,expose your comments in your diagram only insofar as you need to communicate that information in that context.
*If your comment is lengthy or involes something richer than plain text,consider putting your comment in an external document and linking or embedding that document in a note attached to your model.
*As your model evolves,keep those comments that record significant decisions that cannot be inferred from the model itself,and-unless they are of historic interest-discardthe others.
7，如何建模邏輯資料庫模式？modeling a logical database schema
The UML`s class diagrams are a superset of entity-relationship(E-R) diagrams, a common modeling tool for logical database design.
To model a schema:
$Identify those classes in your model whose state must transcend the lifetime of their applications.
$Create a class diagram that contains these classes.You can difine your own set of stereotypes and tagged values to address database-specific details.
$Expand the structural details of these classes.In general,this means spencifying the details of their attributes and focusing on the associations and their multiplicities that relate these classes.
$Watch for common patterns that complicate physical database design,such as cyclic association and one-to-one associations.Where necessary,create intermediate abstractions to simplify your logical structure.
$Consider also the behavior of these classes by expanding operations that are important for data access and data integrity.In general,to provide a better sepatration of concerns,business rules concerned with the manipulation of sets of these objects should be encapsulated in a layer above these persistent classes.
$Where possible,use tools to help you transform your logical design into a physical design.
8，給出順序圖的步驟？modeling flows of control by time ordering
To model a flow of control by time dodering:
+Set the context for the interaction,whether it is a system, subsystems,operations,or class,or one scenario of a use case or collabotation;
+Set the stage for the interantion by identifying which objects play a role in the interaction.Lay then out on the sequence diagram from left to right,placing the more important objects to the left and their neighboring objects to the right;
+Set the lifeline for each object.In most cases,objects will persist through the entire interaction. For those objects that are created and destroyed ring the interaction ,set their lifelines,as appropritate,and explicitly indicate their birth and death with appropriately stereotyped messages;
+Starting with the message that initiates this interaction, lay out each subsequent message from top to bottom between the lifelines,showing each message`s properties, as necessary to explain the semantics of the interaction;
+If you need to visualize the nesting of messages or the points in time when actual computation is taking place, adorn each object`s lifeline with its focus of control;
+If you need to specify this flow of control more formally, attach pre-and postconditions to each message.
9，如何利用製品圖建模可執行程序的發布？modeling an executable release
To model an executable release:
#Identify the set of artifacts you`d like to model.Typically,this will involve some or all the artifacts that live on one node,or the distribution of these sets of artifacts across all the nodes in the system.
#Consider the stereotype of each artifact in this set.For most systems you`ll find a small number of different kinds of artifacts.You can use the UNL`s extensibility mechanisms to provide visual cues for these stereotypes.
#For each artifact in this set, consider its relationship to its neighbors.Most often,this will involve interfaces that are exported by certain artifacts and then imported by others.If you want to expose the seams in your system,model these interfaces explicity.If you want your model at a higher level of abstraction, elide these relationships by showing only dependencies among the artifacts.

⑵ 怎麼根據資料庫來畫uml類圖

可以把uml類圖來表示資料庫表，持久類屬性當欄位使用，類方法可以不使用，表示出數據關系就可以了，應該分為持久類和操作類，操作類和你使用的開發框架有關，重點是類方法，uml當設計輔助和文檔是合適的，開發用它不實用，這是個人體會，不一定對。

⑶ UML在資料庫中是什麼意思

uml(統一建模語言)，是一種建模的圖形化工具，並不是只有資料庫有，它是獨立的建模工具，網上可以搜一下，看看詳細的解釋。

⑷ 使用uml進行數據建模時，用什麼來建模數據表中的主鍵

最近在進行UML學習過程中，突然忘記了大學時關於資料庫理論中概念模型、邏輯模型、物理模型之間的區別。隨機復習上網並復習，並在此記錄一下，資料庫建模是對現實世界進行分析、抽象、並從中找出內在聯系，進而確定資料庫的結構。

1、概念模型：就是從現實世界到信息世界的第一層抽象，確定領域實體屬性關系等，使用E-R圖表示，E-R圖主要是由實體、屬性和聯系三個要素構成的。

2、邏輯模型：是將概念模型轉化為具體的數據模型的過程，即按照概念結構設計階段建立的基本E-R圖，按選定的管理系統軟體支持的數據模型（層次、網狀、關系、面向對象），轉換成相應的邏輯模型。這種轉換要符合關系數據模型的原則。目前最流行就是關系模型（也就是對應的關系資料庫）

E-R圖向關系模型的轉換是要解決如何將實體和實體間的聯系轉換為關系，並確定這些關系的屬性和碼。這種轉換一般按下面的原則進行：

（1）一個實體轉換為一個關系，實體的屬性就是關系的屬性，實體的碼就是關系的碼。

（2）一個聯系也轉換為一個關系，聯系的屬性及聯系所連接的實體的碼都轉換為關系的屬性，但是關系的碼會根據聯系的類型變化，如果是：

1：1聯系，兩端實體的碼都成為關系的候選碼。

1：n聯系，n端實體的碼成為關系的碼。

m：n聯系，兩端實體碼的組合成為關系的碼。

3、物理模型就是根據邏輯模型對應到具體的數據模型的機器實現。物理模型是對真實資料庫的描述。如關系資料庫中的一些對象為表、視圖、欄位、數據類型、長度、主鍵、外鍵、索引、約束、是否可為空、默認值。

⑸ XML和UML的區別是什麼

XML和UML兩者並沒什麼可比性。

XML：可擴展標記語言(ExtensibleMarkupLanguage,XML)，用於標記電子文件使其具有結構性的標記語言，可以用來標記數據、定義數據類型，是一種允許用戶對自己的標記語言進行定義的源語言。

UML：UnifiedModelingLanguage(UML)又稱統一建模語言或標准建模語言,是始於1997年一個OMG標准，它是一個支持模型化和軟體系統開發的圖形化語言,為軟體開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。

簡單的說，XML是描述數據的，可以看做是資料庫的文字表達；

UML是軟體開發建模用的，是編寫代碼前的項目總體設計和規劃。