# 14.2.3 Packages SEAMCAT has different modules. These are used to group certain classes of the code and handle dependencies between them. This is similar to the layers of abstraction where the engine only knows general system types but not specifics. Modules can be used to enforce such dependencies. There are two main modules: model and application. - Model holds all the abstract definitions that composes a System – Transmitter, Receiver, Antenna, Propagation model, Distribution, etc.; - Application implements the SEAMCAT UI, simulations, Propagation Models, and basically ties everything together. We will descuss this structure in more detail later. ![image.png](https://wiki.cept.org/uploads/images/gallery/2026-07/scaled-1680-/5xeP1zfgNud7EL8k-image.png)
![](blob:https://ecowiki.atlassian.net/463ce219-292b-4c47-a3b7-6efceda8df78#media-blob-url=true&id=26876eec-b09e-4e61-8a85-c70d349b545d&collection=contentId-493520&contextId=493520&width=866&height=423&alt=&clientId=113268fe-fe5b-4bc3-8ff3-07965dbf1d18)**Figure 304: Modules of SEAMCAT**
Inside a module we organise the software files in packages. It is similar to a folder and like a folder it contains the individual source code files. The names of the packages is helpful when nagivating the source code. The packages of the model module: - The names can be helpful when navigating the source code; - Cellular and generic contains the definitions for the cellular and generic systems; - Plugin holds the plugin definition for the mentioned types (Eventprocessing, Coverageradius, propagation etc…); - Distribution, functions, and mathematics holds the distributions and other helper functions; - Simulation and types holds the simulation results and general type definitions (Antenna, Receiver, RadioSystem, etc). The packages of Application is more messy than the model. So here it is harder to know exactly where to go. The packages to know here is: scenario and simulation: - Scenario contains the implementation of some of the types defined in Model; - Similarly with simulation: here are the specific simulations e.g. CDMADownlinkVictimSimulation. It is the very nature of code to change, but with a good design and understanding of the abstractions it should be easy to identify part that will change the least. Most of the dynamic parts of the code can be examined with runtime inspection by software development tools. Mechanism vs Policy is a software principle based on the fact that mechanism change infrequently whereas policies change all the time. Mechanism is here the engine of SEAMCAT and policies are the plugins. The parts that changes behaviour are left open for developers.
![](blob:https://ecowiki.atlassian.net/34681d30-88a0-4fce-bb6b-8a6ac7920250#media-blob-url=true&id=d0c9f0e7-cb3c-4a56-b783-cc3ecbdc3d32&collection=contentId-493520&contextId=493520&width=274&height=426&alt=&clientId=113268fe-fe5b-4bc3-8ff3-07965dbf1d18)
![image.png](https://wiki.cept.org/uploads/images/gallery/2026-07/scaled-1680-/4vn3Y6BhyhTKK8Z5-image.png)
![](blob:https://ecowiki.atlassian.net/97490b0e-252c-42d8-96de-a3a5e9566bb8#media-blob-url=true&id=5f74ca19-7a03-4be5-8c6d-3edaf7e48da2&collection=contentId-493520&contextId=493520&width=308&height=310&alt=&clientId=113268fe-fe5b-4bc3-8ff3-07965dbf1d18)
![image.png](https://wiki.cept.org/uploads/images/gallery/2026-07/scaled-1680-/hLqTkKKT487pY1zM-image.png)
**Figure 305: Packages of Model**
**Figure 306: Packages of Application**