The XSD Generation facility converts a UML class model to a W3C XML Schema (XSD). This allows Data Modelers to start working at a conceptual level in UML, leaving the tedious aspects of XSD creation to EA. The schema generation can then be customized if necessar
To use the schema generation facility you will require the following:
XSDDataTypes Package: This package contains classes representing XSD primitive data types. This package is available as an XMI file. To import the file as a UML Package, use EA's XMI import facility which is available from the menu item: Project | Import/Export | Import Package from XMI.
UML Profile for XML: This resource file contains the stereotyped classes which allow the schema generation to be customized. The UML Profile for XML can be imported into a model using the Resource View (see Importing Profiles for details on importing UML profiles into EA).
Steps to Generate XSD:
Select the package to be converted to XSD by right-clicking on the package in the Project Browser.
Select Project | Generate XML Schema from the main menu.
Set the desired output file using the Filename field.
Set the desired xml encoding using the Encoding field.
Click on the Generate button to generate the schema.
The progress of the schema generator will be shown in the Progress edit box.
strategy to use when less or unconstrained by legacy db schema baggage. ie. the *proper* and *ideal* way to model domain classes... using oo, not dumb structs! :)
this is one sensible interface naming option, if the interface encapsulates a cohesive set of behaviors
and yes, compared to blindly following the meaningless I+ convention, it requires some thought, but thinking of an appropriate name also forces you to (re)consider the interface's primary responsibility and how it fits into the overall design
imho, a class diagram for a domain model should be almost fluently readable english
Sometimes an Adjective doesn't make sense, but I'd still generally be using interfaces to model behavior, actions, capabilities, properties, etc,... not types.
Also, If you were really only going to make one User and call it User then what's the point of also having an IUser interface?
another anti-pattern... blindly create an interface for every class, even if there's only one implementation!! arrgghhhh!
consider introducing an interface when there are 2-3 well-distinguished, concrete implementations required
if you are going to have a few different types of users that need to implement a common interface, what does appending an "I" to the interface save you in choosing names of the implementations?
prefer not to use a prefix on interfaces:
hurts readability.
interfaces names should be as short and pleasant as possible
Implementing classes should be uglier to discourage their use.