Free Download Aplikation

Kami Disini menyediakan berbagai Aplikasi yang dapat Anda Download secara gratis..tis..tis..buat semua jenis hp anda...



Organizational Diagrams
* Group together functionally-similar classes.
* Same as C++ namespace.
* identifies derivation. Classes/interfaces in "base" package are extended/implemented in "derived" package, etc. Derived classes need not be in the same package as base class, however.
* represents a dependency, typically stereotyped («import», «access», etc.).
* Package name is part of the class name. (e.g. given the class fred in the flintstone package, the fully-qualified class name is flintstone.fred).
* Generally needed when entire static-model won't fit on one sheet.
* Packages can nest. Outermost packages called domains if they contain only subpackages (no classes). (The tools package at left is an outer package; the com.holub package is a domain.) Nested packages can also be shown using a tree structure and static-model nested-class symbol (shown at right).

Subsystems. A subsystem is is a cooperating system of runtime objects that form a cohesive group. (Packages are made up of classes, not objects.) Subsystems presents a standard set of interfaces to the outside world, and all access to the objects that comprise the subsystem should be through these interfaces.

Packages are compile-time things, subsystems are run-time things. Don't confuse them — the similar notation is unfortunate. The classes that comprise the subsystem are often contained in a single package, but need not be. (The classes that define objects in the JDBC subsystem are defined in the java.sql package. I've shown relationship at left, but that's not standard UML.) Subsystems are identified as such by a symbol, which can be placed in the tab or body of the box.

The diagram at left shows both the standard and ball-and-socket-style interface notations. UML also lets you put into the box a static-model diagram showing the classes that comprise the subsystem. I've found that level of detail to be unnecessary in practice, so have not shown it.

Use-Case Diagram
Specifies participants in a use case and the relationships between use cases.

* The stick-figure represents a role taken on by some actor (sometimes called simply "actor," but it's really a role).
* A line connects the actor/role to the use case in which it participates. You may use cardinality. (A Salesperson places many orders.)
* An is-specialization-of/generalizes relationship between actor/roles (denoted by ) indicates additional responsibilities. (A Supervisor has all the responsibilities of a Salesperson, but can also establish credit. A Supervisor can create an account, for example.)
* Dotted lines denote use-case dependencies. Common dependencies are:
«equivalent» Equivalent use cases have identical activities and identical flow, but end users think of them as different. ("Deposit" and "Withdrawal" might have identical activities, though the objects involved might be different.)
«extends» When extension extends base, all the activities of the base use case are also performed in the extension use case, but the extension use case adds additional activities to —or slightly modifies existing activities of—the base use case. (To place a recurring order, you must perform all the activities of placing an order plus set up the recurrence.)

If a set of activities occur in several use cases, it's reasonable to "normalize" these common activities out into a base use case, and then extend it as necessary.

Holub Extension: This relationship is really a form of derivation, so I use the derivation arrow () instead of a dashed line. As in a class diagram, the arrow points from the extension to the base use case.
«includes» A subcase. If case includes subcase, then the activities of subcase are performed one or more times in the course of performing case. (An "Authenticate" subcase may be included in several larger use cases, for example.) The subcase is usually represented in the using use case as a single box marked with the subcase name and the stereotype «use case».
«requires»
«follows» If follower requires leader, then leader must be completed before you can execute the follower use case. (You must create an account before you can place an order.)
«resembles» Two use cases are very similar, but do have different activities.

Actors/roles are mostly uninteresting to programmers. The dependencies are valuable in determining which use case to implement first. (I often implement the use cases that have the most incoming arrows first, since other use cases depend on them.)

Activity and State Diagrams
Starting and Stopping. The solid circle indicates the beginning of the sequence of activities.

The circle with an X represents an end of a "flow" but not the end of the entire use case. In other words, some subtask completes, but the entire use case is not yet complete.

The "target" indicates that the entire use case is complete.

Starting and Stopping. The solid circle indicates the beginning of the sequence of activities.

The circle with an X represents an end of a "flow" but not the end of the entire use case. In other words, some subtask completes, but the entire use case is not yet complete.

The "target" indicates that the entire use case is complete.