RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


UML for the Software Developer, Part 5: Component Diagrams : Page 3

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.

How Components Exist in .NET
The last topic that I want to discuss is how components are implemented in .NET. In my first article, "Building Classes," I discussed namespaces. I showed how a namespace is nothing more than a programmatic way to prevent naming collisions by prefixing variables with the same names with a namespace. From an architectural view a namespace can be used to identify parts of an architectural pattern. In the case of MVC there would be three namespaces:

            namespace Model { }
            namespace View { }
            namespace Controller {}
The namespaces in .NET can exist across classes and assemblies so that multiple components can be added to an assembly. Assemblies are the same as components. Each assembly contains one or more portable executables (PEs) that contain multiple classes compiled into MSIL (Microsoft's intermediate code). The assemblies also contain a manifest that tracks the variable names, the number of classes, types, and metadata for the assembly.

In the Richman, Inc. example I could add each component to its own assembly but use the appropriate namespace across the components in the model, view and controller. It is also possible (although it cannot be done through Visual Studio) to add more than one component in each assembly and have three assemblies for model, view, and controller respectively. Depending upon the size of the program it is best to remember that the fewer the assemblies the easier it is to deploy.

So far I have gone from class diagrams to deployment diagrams. The link between the abstract classes and how they are deployed are components that contain multiple classes and are grouped logically so that they can be deployed. The final article in this series, coming next month, will cover sequence diagrams.

Mark Goetsch is an Enterprise Software Architect with Wheels, Inc, and has more than fifteen years of experience in software development, enterprise modeling, and software architecture. He has another seven years experience as a trader, dealer, Broker, and an expert in e-trading. He was one of the enterprise modelers of the Tapestry Project at ABNAMRO, one of the most extensive uses of UML component and deployment diagrams to date. He is the lead architect for the MAP (Meta-Architectural Processes) framework, which is a framework for mapping the role of the software architect into software development processes. Mark is certified in Intermediate UML with the OMG and a member of WWISA. He also has a Masters in Distributed Systems from DePaul University.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date