完成課程作業，順便轉載下，因爲作業手寫的，懶得打字了，大家將就着看吧，順便提升英語能力 = =
UML類圖：http://www.uml-diagrams.org/class-diagrams.html
Class Diagrams
Class diagram is UML structure diagram which shows structure of the designed system at the level of classes and interfaces, shows their features,constraints and relationships - associations, generalizations, dependencies, etc.
Class
A class is a classifier which describes a set of objects that share the same
- features,
- constraints,
- semantics (meaning).
A class is shown as a solid-outline rectangle containing the class name, and optionally with compartments separated by horizontal lines containing features or other members of the classifier.
As class is the most widely used classifier, there is no need to add the "class" keyword in guillemets above the class name. Class name should be centered and inbold face, with the first letter of class name capitalized (if the character set supports upper case).
Class Customer - details suppressed
Features of a class are attributes and operations.
When class is shown with three compartments, the middle compartment holds a list of attributes and the bottom compartment holds a list of operations. Attributes and operations should be left justified in plain face, with the first letter of the names in lower case.
Class SearchService - analysis level details
Characteristics represented by feature may be of the classifier’s instances considered individually (not static) or of the classifier itself (static). The same feature cannot be static in one context and non static in another.
With regard to static features, two alternative semantics are recognized. Static feature may have:
- different values for different featuring classifiers, or
- the same value for all featuring classifiers.
In accordance with this semantics, inheritance of values for static features is permitted but not required by UML 2.
Static features are underlined - but only the names. An ellipsis (...) as the final element of a list of features indicates that additional features exist but are not shown in that list.
Attributes of a class are represented by instances of property that are owned by the class. Some of these attributes may represent the navigable ends ofbinary associations.
Objects of a class must contain values for each attribute that is a member of that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.
Class SearchService - implementation level details.
The createEngine is static operation
Attributes or operations may be grouped by visibility. A visibility keyword or symbol in this case can be given once for multiple features with the same visibility.
Class SearchService - attributes and operations grouped by visibility
Additional compartments may be provided to show other details, such as constraints, or just to divide features.
A class in the UML could be used as a namespace for other classifiers including classes, interfaces, use cases, etc. Nested classifiers are visible only within the namespace of the containing class.
Abstract Class
Abstract class was defined in UML 1.4.2 as class that can't be directly instantiated. Abstract class exists only for other classes to inherit from and to support reuse of the features declared by it. No object may be a direct instance of an abstract class, although an object may be an indirect instance of one through a subclass that is nonabstract.
UML 2.4 mentions abstract class but provides no definition. We can probably relate definition of abstract classifier to abstract class. We may assume that in UML 2.x abstract class does not have complete declaration and "typically" can not be instantiated. An abstract class is intended to be used by other classifiers (e.g., as the target of generalization generalization relationships).
UML 2.4 provides no explanation of the "incomplete class declaration" and whether it is related to the concept of abstract operation - which was also present in UML 1.4.2 and is absent in UML 2.x.
Attempting to create an instance of an abstract class is undefined - some languages may make this action illegal, others may create a partial instance for testing purposes.
The name of an abstract class is shown in italics.
Class SearchRequest is abstract class
An abstract classifier can also be shown using the keyword {abstract} after or below the name.
Standard Class Stereotypes
Standard UML class stereotypes include:
Note, that naming convention for stereotypes and applied stereotypes was changed in UML 2.4.1 to have the first letter in upper case. You will still see stereotypes in lower case, e.g. «focus», «type», everywhere as it will take some time to switch to the new notation.
«Focus»
Focus is class that defines the core logic or control flow for one or more supporting classes. The supporting classes may be defined either explicitly usingauxiliary classes or implicitly by dependency relationships.
Focus classes are typically used for specifying the core business logic or control flow of components during design phase.
«Auxiliary»
Auxiliary is class that supports another more central or fundamental class, typically by implementing secondary logic or control flow. The class that the auxiliary supports may be defined either explicitly using a focus class or implicitly by a dependency relationship.
Auxiliary classes are typically used for specifying the secondary business logic or control flow of components during design phase.
«Type»
Type is class that specifies a domain of objects together with the operations applicable to the objects, without defining the physical implementation of those objects.
Type may have attributes and associations. Behavioral specifications for type operations may be expressed using, for example, activity diagrams. An object may have at most one implementation class, however it may conform to multiple different types.
«Utility»
Utility is class that has only class scoped static attributes and operations. As such, utility class usually has no instances.
Math is utility class - having static attributes and operations (underlined)
Nonstandard Class Stereotypes
There are several nonstandard but routinely used class stereotypes available in several UML tools including IBM Rational Software Architect (RSA) and Sparx Enterprise Architect:
These class stereotypes are part of the Analysis Profile in RSA which is applied by default with the Analysis Model template. The stereotypes roughly correspond to the parts of the Model-View-Controller (MVC) design pattern, where Boundary represents View, Control is Controller, and Entity corresponds to the Model.
«Boundary»
Boundary is a stereotyped class or object that represents some system boundary, e.g. a user interface screen, system interface or device interface object. It could be used in the analysis or conceptual phase of development to capture users or external systems interacting with the system under development. It is often used in sequence diagrams which demonstrate user interactions with the system.
Boundary is drawn as a circle connected with a short line to a vertical line to the left It could be also shown as a class with the «Boundary» stereotype.
«Control»
Control is a stereotyped class or object that is used to model flow of control or some coordination in behavior. One or several control classes could describe use case realization. System controls represent the dynamics of the designed system and usually describe some "business logic".
Control is drawn as a circle with embedded arrow on the top. It could be also shown as a class with the «Control» stereotype.
Note, that UML has standard «Focus» stereotype applicable to classes which could be used for specifying the core business logic or control flow of components during design.
«Entity»
Entity is a stereotyped class or object that represents some information or data, usually but not necessarily persistent.
Entity is drawn as a circle with line attached to the bottom of the circle. It could be also shown as a class with the «Entity» stereotype.
Business entities represent some "things", items, documents, or information handled, used or processed by business workers while they do business. Examples of business entities are Prescription at the doctor's office, Menu at the restaurant, Ticket at the airport.
System entities represent some information or data, usually but not necessarily persistent, which is processed by the system.
Note, that UML has standard «Entity» stereotype applicable to components and representing a business concept of a persistent information.
Class Template
UML classes could be templated or bound.
The example below shows template class Array with two formal template parameters. The first template parameter T is an unconstrained class template parameter. The second template parameter n is an integer expression template parameter.
Template binding for the bound class Customers substitutes the unconstrained class T with class Customer and boundary n with integer value 24. Thus, the bound class Customers is an Array of 24 objects of Customer class.
Template class Array and bound class Customers.
Interface
An interface is a classifier that declares of a set of coherent public features and obligations. An interface specifies a contract. Any instance of a classifier thatrealizes (implements) the interface must fulfill that contract and thus provides services described by contract.
In UML 1.4 interface was formally equivalent to an abstract class with no attributes and no methods and only abstract operations.
An interface may be shown using a rectangle symbol with the keyword «interface» preceding the name.
Interface SiteSearch
The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.
Interface Pageable
Since interfaces are declarations, they are not instantiable. Instead, an interface specification is implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification.
Any given classifier may implement more than one interface. Interface may be implemented by a number of different classifiers.
An association between an interface and any other classifier implies that a conforming association must exist between any implementation of that interface and that other classifier. In particular, an association between interfaces implies that a conforming association must exist between implementations of the interfaces.
Interfaces realized by a classifier are its provided interfaces, and represent the obligations that instances of that classifier have to their clients. They describe the services that the instances of that classifier offer to their clients.
Interface participating in the interface realization dependency is shown as a circle or ball, labeled with the name of the interface and attached by a solid line to the classifier that realizes this interface.
Interface SiteSearch is realized (implemented) by SearchService.
Required interface specifies services that a classifier needs in order to perform its function and fulfill its own obligations to its clients. It is specified by a usage dependency between the classifier and the corresponding interface.
The usage dependency from a classifier to an interface is shown by representing the interface by a half-circle or socket, labeled with the name of the interface, attached by a solid line to the classifier that requires this interface.
Interface SiteSearch is used (required) by SearchController.
It is often the case in practice that two or more interfaces are mutually coupled through application-specific dependencies. In such situations, each interface represents a specific role in a multi-party “protocol.” These types of protocol role couplings can be captured by associations between interfaces.
An interface in the UML could be used as a namespace for other classifiers including classes, interfaces, use cases, etc. Nested classifiers are visible only within the namespace of the containing interface.
Data Type
A data type is a classifier - similar to a class - whose instances are identified only by their value.
A typical use of data types would be to represent value types from business domain, primitive types or structured types of a programming language. For example, date/time, gender, currency, address could be defined as data types. All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances.
A data type is shown using rectangle symbol with keyword «dataType».
DateTime data type
A data type may contain attributes and operations to support the modeling of structured data types. Instances of a structured data type are considered to be equal if the structure is the same and the values of the corresponding attributes are equal.
Structured data type Address
When data type is referenced by, e.g., as the type of a class attribute, it is shown simply as the name of the data type.
Attributes of the Patient class are of data types Name, Gender, DateTime, Address and Visit.
Primitive Type
A primitive type is a data type which represents atomic data values, i.e. values having no parts or structure. A primitive data type may have precise semantics and operations defined outside of UML, for example, mathematically.
Standard UML primitive types include:
- Boolean,
- Integer,
- UnlimitedNatural,
- String,
- Real.
Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.
A primitive type has the keyword «primitive» above or before the name of the primitive type.
Primitive data type Weight.
Enumeration
An enumeration is a data type whose values are enumerated in the model as user-defined enumeration literals.
An enumeration may be shown using the classifier notation (a rectangle) with the keyword «enumeration». The name of the enumeration is placed in the upper compartment. A compartment listing the attributes for the enumeration is placed below the name compartment. A compartment listing the operations for the enumeration is placed below the attribute compartment.
A list of enumeration literals may be placed, one to a line, in the bottom compartment. The attributes and operations compartments may be suppressed, and typically are suppressed if they would be empty.
Enumeration AccountType.
