XMI is a great technology for anyone who builds applications from models, allowing you to use information contained in those models for big upside. But if you want your model data to be effective, components are an essential building block. Learn to get your dependencies straight by making traceable components.
XMI is a great technology for anyone who builds applications from models, allowing you to use information contained in those models for big upside. Learn to extract dependency information from a UML deployment diagram using C# and how to use the Pipes and Filters pattern to simplify the whole process.
UML models of the future will use XMI as a method of interchanging model data. And because XMI uses XML, suddenly the world is our oyster: In particular, you can extract model data and save it to a data store. Find out how to dissect data from your models using C#.
As the official OMG specification for exchanging model information between tools and repositories, XMI will have a huge impact on architects and developers. Find out how to use this spec to make your model metadata agnostic and portable for the future.
Interaction or sequence diagrams are the critical link between the static class diagrams and how the classes behave. A well-defined sequence diagram will find missing classes, elucidate the sequence of events for class interaction, and define the methods needed for each class.
Their ability to show interdependencies between applications' components make component diagrams invaluable. They can however be surprisingly complex. Find out how to use the right architectural patterns within your component diagrams to make them manageable.
At SD West, one man finds the heart of modeling—and opens his eyes to the power of invariants—thanks to the founder of MDA.
Deployment diagrams act as the link and reference point between how the system is built and where it is displayed. Learn how capacity planning, n-tier development, and coordination of tasks between different teams can all benefit from these diagrams.
Part 3 of this series on UML tackles aggregation, which is a special form of association.
Part 2 showed you how associations related one class to another, but this article shows that associations are not strong enough when you need to specify ownership.
Associations are a key part of the UML lexicon. Use them to define the ways in which your application's classes communicate. In this article you'll see that adding a database introduces design patterns for the first time using the façade pattern.
Whatever language you code in, however you feel about documentation, and whichever process you ascribe to—you will need to model. Whether those models are in a formal charter, reference document, part of a diagram, or on the
back of a napkin, you as a software developer will end up using models or modeling yourself.
Author Bio
