Use case diagram

Computer/Terms 2008. 4. 22. 09:53

A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML) created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases.

While SysML uses the same notation as UML for use cases, system engineers model at the system or systems-of-systems level.

UML Use Case Diagram
OMG's UML standard defines a graphical notation for modeling use cases with diagrams, but no format for describing these use cases. While the graphical notation and descriptions are important, they are documentation of the use case—a purpose that the actor can use the system for—

The true value of a use case lies in two areas:

- The written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.
- The position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

This diagram describes the functionality of a simplistic Restaurant System. Use cases are represented by ovals and the actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Prepare Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.

Actor Generalization
The only relationship allowed between actors is generalization. This is useful in defining overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general actor.

Use Case Relationships
Three relationships among use cases are supported by the UML standard, which describes graphical notation for these relationships.

Uses
In one form of interaction, a given use case uses another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label "«include»". This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values.

Extend
In another form of interaction, a given use case (the extension) may extend another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label '«'extend'»'. This can be useful for dealing with special cases (when A extends B, A is a special case of B), or in accommodating new requirements during system maintenance and extension.

To make the points at which extension may occur explicit extension points may be defined in a use case which are listed in a compartment below the use case.

Generalization
In the third form of relationship among use cases, a generalization/specialization relationship exists. A given use case may be a specialized form of an existing use case. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case. This resembles the object-oriented concept of sub-classing, in practice it can be both useful and effective to factor common behaviors, constraints and assumptions to the general use case, describe them once, and deal same as except details in the specialized cases.

Reference:
http://en.wikipedia.org/wiki/Use_case_diagram

Posted by 알 수 없는 사용자
,

XForms

Computer/Terms 2008. 4. 21. 19:03

XForms is an XML format for the specification of a data processing model for XML data and user interface(s) for the XML data, such as web forms. XForms was designed to be the next generation of HTML / XHTML forms, but is generic enough that it can also be used in a standalone manner or with presentation languages other than XHTML to describe a user interface and a set of common data manipulation tasks.

XForms, much like XHTML 2.0 which is currently under development as of November 2006 and within which XForms will be embedded, differs from previous versions of XHTML. Because of this there is a learning curve for developers, but because XForms in general provides a large time savings for the development of enterprise quality web forms, it can be an attractive alternative for many uses.

XForms 1.0 (Third Edition) was published on 29 October 2007. The original XForms specification was made an official W3C Recommendation on 14 October 2003.

XForms 1.1, which introduces a number of improvements, reached the status of W3C Candidate Recommendation on 29 November 2007.

Reference:
http://en.wikipedia.org/wiki/Xform

Posted by 알 수 없는 사용자
,

XPointer

Computer/Terms 2008. 4. 21. 18:51

XPointer is a system for addressing components of XML based internet media.

At the present time (late 2002), XPointer is divided among four specifications: a "framework" which forms the basis for identifying XML fragments, a positional element addressing scheme, a scheme for namespaces, and a scheme for XPath-based addressing.

The XPointer language is designed to address structural aspects of XML, including text content and other information objects created as a result of parsing the document. Thus, it could be used to point to a section of a document highlighted by a user through a mouse drag action.

XPointer is covered by a technology patent held by Sun Microsystems.

Positional Element Addressing
The element() scheme introduces positional addressing of child elements. This is similar to a simple XPath address, but subsequent steps can only be numbers representing the position of a descendant relative to its branch on the tree.

For instance, given the following fragment:

<foobar id="foo">
  <bar/>
  <baz>
    <bom a="1"/>
  </baz>
  <bom a="2"/>
</foobar>


 
results as the following examples:

 xpointer(id("foo")) => foobar
 xpointer(/foobar/1) => bar
 xpointer(//bom) => bom (a=1), bom (a=2)
 xpointer(/1/2/1) => bom (a=1) (/1 descend into first element (foobar), descend into second child element (baz), select first child element (bom))



Reference:
http://en.wikipedia.org/wiki/Xpointer

Posted by 알 수 없는 사용자
,