Enterprise Architect, as a modeling tool for different domains, can be used to provide the artifacts needed by the mentioned standards. In addition to the required artifacts, the standards often require a chain of traceability between all artifacts. Dr. Detlev Hatke presents in his article Tool-Based Checks of Process Implementation – an Example some approaches how SPICE can be lived with Enterprise Architect.

Here, you find the article.

Here you can read some success stories of our customers, using Enterprise Architect.

Department of Motor Vehicles – CSI Systems Redesign Project DMV, April 2009		Download PDF
Royal Navy Command and Control BAE Systems, January 2009		Download PDF
Large Synoptic Survey Telescope LSST Corporation, September 2008		Download PDF
Applying MDA to Air Traffic Control AD4 Consortium, June 2008		Download PDF
Visualizing the St.George Bank enterprise IT model St.George Bank, May 2008		Download PDF
Smart Freight Process Model for Port of Melbourne Red Wahoo and Department of Infrastructure Victoria, May 2008		Download PDF
Developing the GeoSciML interoperability standard Geoscience Australia and CSIRO, November 2007		Download PDF
Developing an Enterprise-wide Architecture Insurance Australia Group, August 2007	Read More…	Download PDF
A Model Driven approach to Business Improvement Canonic Corp and IBS Interprit, April 2007	Read More…	Download PDF
CMMI meets UML iITa, September 2006	Read More…	Download PDF
Hunter Unmanned Vehicle Mike Meakin, September 2004		Download PDF
A project rollout of UML using Enterprise Architect Xpdian, July 2002		Download PDF

Here we are going on with our EA whitepapers review.

Product Description
About This Book Praise for Enterprise Architecture Planning— “… the book has given me a wealth of good, fresh ideas about every facet of the architecture process … makes a substantive contribution to the body of IS planning knowledge.” —John A. Zachman Zachman Information Systems Enterprise Architecture Planning is more advanced than traditional system planning approaches because you:

• define a stable business model independent of organizational boundaries, systems, and procedures,
• define data before application, and
• let data determine the sequence for implementing applications systems.

Here the authors give you a common-sense approach to Enterprise Architecture Planning. You’ll find dozens of examples of architectures, procedures, checklists, and useful guidelines to support these techniques. This is the best guide available to help you ensure a cost-effective, long-term solution.

You can buy the book Enterprise Architecture Planning in well sorted bookstores.

ISBN-10: 0471599859
ISBN-13: 978-0471599852

A deployment diagram models the run-time architecture of a system. It shows the configuration of the hardware elements (nodes) and shows how software elements and artifacts are mapped onto those nodes.

Features:

Node
A Node can either be a hardware or a software element and is shown via a three-dimensional box shape.

Node Instance
For example, node instances are shown on diagrams. You can distinguishe an instance from a node, if its name is underlined and has a colon before its base node type. An instance can or can not have a name before the colon.

Node Stereotypes

There are a lot standard stereotypes provided for nodes:
«cdrom»
«cd-rom»
«computer»
«disk array»
«pc»
«pc client»
«pc server»
«secure»
«server»
«storage»
«unix server»
«user pc»
Displayed by an appropriate icon in the top right corner of the node symbol.

Artifacts
Artifacts are products of a software development process including  process models, source files, executables, design documents, test reports, prototypes and user manuals.

Association
The association represents a communication path between nodes.

Node as Container
Within a node you can also contain other elements, like components or artifacts.

Role Binding
The role binding connector draws from a collaboration to the classifier that fulfils the role, shown by a dashed line.

Represents
Represents are drawn from a collaboration to a classifier showing that a collaboration is used in the classifier. Graphically viewed by a dashed line with arrowhead and the keywort “represents”.

Occurrence
To show that a collaboration represents its classifier, an occurrence connector is drawn from a collaboration to a classifier, shown as adashed line with arrowhead and the keyword “occurrence”.

Here you can read part 1 of the UML 2 composite structure diagram.

Part
Parts are elements which represent a set of one or more instances that are owned by a containing classifier instance and it is shown as an unadorned rectangle contained within the body of a class or component element.

Ports
Ports are defining interaction between a classifier and its environment, shown with a named rectangle on the boundary edge of its owning classifier.

Interfaces
Interface operations are public and abstract and they are similar to a class having a lot of restrictions. It can be shown as a circle.

Delegate Connector
The delegate connector connects an external contract of a component as shown by its ports to the internal realization of the behavior of the component’s part to view an internal working of a component’s external ports and its interfaces.

Don’t miss part 2 of the UML2 composite structure diagram.

Generalizations
With a generalization you indicate inheritance. If it’s drawn from a specific classifier to a general classifier, the generalize implication is that the source inherits the target’s characteristics.

Aggregations
Aggregations are depicting elements which are made up of smaller components. This aggregation relationships will be shown by a white diamond-shaped arrowhead pointing towards the target or parent class.

Association Classes
With an association class you can construct an association connection to make operations and attributes.

Dependencies
If you need to model a wide range of dependent relationships between model elements you use dependencies. This will be done early in the design process. Later on the dependencies will be stereotyped or replaced with more specific data.

Traces
With traces yo can easily track requirements or model changes, because it is a specialization of a dependency, linking model elements or sets of elements, representing the same idea across models.

Realizations
A realization expresses traceability and completeness in a model.

Nestings
Nestings are connectors showing source elements within a target element.

Click to read part 1 of the UML 2 Class Diagram

Definitions:
Classes
Classes are elements that define the attributes and behaviors of an object . A behavior describes possible messages of the class along with operations. Within classes you can also define constraints, tagged values and stereotypes.

Class Notation
A class shows the name of the class and optionally the name of the operations and attributes. The compartments divides the class name,  attributes and operations.

Interfaces
The interface is a contract with a specification of behaviors that implementers agree to meet. In an interface, classes are guaranteed to support the required behavior. You may draw the interface in a similar style to a class, specified with operations, or you draw it as a circle with no details to explicit operations.

Tables
Tables are not a part of the base UML, it’s more an example of what can be done with stereotypes. When a table is drawn you can see a small table icon in the upper right corner.

Following in part 2 of the UML Class Diagram.