Common Modeling Techniques
- Modeling Source Code
- Modeling Executable Release
- Modeling a Physical Database
- Modeling Adaptable Systems
Modeling Source Code
To model a system's source code,
- Either by forward or reverse engineering, identify the set of source code files of interest and model them as components stereotyped as files
- For larger systems, use packages to show groups of source code files
- Consider exposing a tagged value indicating such information as the version number of the source code file, its author and the date it was last changed
- Use tools to manage the value of this tag
- Model the compilation dependencies among the source files using dependencies
- Where possible, use tools to help generate and manage these dependencies
Modeling Executable Release
To model an executable release,
- Identify the set of artifacts you want to model
- Typically, this will involve some or all the components that live on one node, or the distribution of these sets of components across all the nodes in the system
- Consider the stereotype of each component in this set
- For most systems, you will find a small number of different kinds of components (such as executable's libraries, tables, files and documents)
- Using extensibility mechanisms, provide visual cues for these stereotypes
- For each component in this set, consider its relationship to its neighbors
- Most often, this will involve interfaces that are exported (realized) by certain components and then imported (used) by others
Modeling a Physical Database
To model a physical database,
- Identify the classes in the model that represent your logical database schema i.e., the objects of those classes need to be persistent
- Select a strategy for mapping these classes to tables
- You will also want to consider the physical distribution of your databases
- Based on the location in which the data needs to live in the deployed, map physical distribution of the databases
- To visualize, specify, construct and document the mapping, create a component diagram that contains components stereotyped as tables
- Where possible, use tools to transform the logical design into a physical design
Modeling Adaptable Systems
To model an adaptable system,
- Consider the physical distribution of the components that may migrate from node to node
- You can specify the location of a component instance by marking it with a location attribute, which you can then render in a component diagram
- If you want to model the actions that cause a component migrate, create a corresponding interaction diagram that contains component instances
- You can illustrate a change of location by drawing the same instance more than once, but with different values for its state, which includes its location
