Yttrium is based on a microkernel architecture and thus comes with various modules, each providing services and contracts, and sometimes also a toolkit. Since alls the Contracts only depend on other contracts and Services never depend on other Services (only their contracts and maybe toolbox), you may easily extend or replace some of the components. Nevertheless, in most cases it is probably enough to just add another
package (packages are not discussed here).
Edit Modules vs Packages vs Services vs ...
Before you get confused, here a short overview:
- A Module is a part of the Yttrium Framework, like the Interpreter for Parsing expressions and executing scripts, Traversing for walking through expressions, or Library to collect all available mathematical operators. A module may consist of some Toolkit or one or more Services. Modules are discussed on this page. You won't get much in touch of modules unless you're extending Yttrium or are writing a package.
- A Service is a unit (usually a .Net interface) that provides some isolated services, like storing temporary signals or parsing an expression. You won't get much in touch of modules unless you're extending Yttrium or are writing a package.
- A Package is a set of (mathematical) operators, data structures, theorems etc. If you need some data structures or operators not yet available, then write a small package. There's a standard package available.
Have a look at
Yttrium Meta Architecture if you're interested in why it was structured that way.
Edit Modules Overview
| Module | Description | Components |
| Microkernel | Architecture Core, Module Loader | Microkernel |
| Core | Yttrium Core | Contracts, Core |
| Conversion | Value Conversion Infrastructure | Contracts, Service, Toolkit |
| Interpreter | Parser and Interpreter Infrastructure | Contracts, Service |
| Simulation | Simulation & Scheduling Infrastructure | Contracts, Service |
| Library | Manages available operations/structures, value types, theorems etc. | Contracts, Service |
| Patterns | Provides (coalesce) pattern building and matching | Toolkit |
| Traversing | Provides various system visitors and traversion strategies | Contracts, Service |
| Manipulation | Provides automatic cyclic system manipulation | Contracts, Service |
| SystemBuilder | Builder Pattern Service, System I/O | Toolkit |
| Repository | Temporary Storage for various objects (e.g. singleton signal for constants) | Contracts, Service |
| Mediator | Mediator, interaction between Yttrium and e.g. a GUI (MVC-like pattern) | Contracts, Service |
| Packages Helper | Toolkit for simple package development, providing various base classes. | Toolkit |
| Unit Tests | Not exactly a module, but provides a set of unit tests. | NUnit Unit Tests |
Edit Module Configuration
Modules are configured in an XML config file named
yttrium.mapping.config. The configuration format is similar from what you may know from the
Spring.NET Application Framework. You simply add an
object entry for every module you want to make available:
<object id="Domain.Label" comment="Comment" contract="Class/Interface, Assembly"
factory="Class, Assembly" />
For example, to make the expression parser service of the interpreter module available, add the following line:
<object id="Interpreter.Parser" comment="INTERPRETER: Parser"
contract="MathNet.Symbolics.Interpreter.IParser, MathNet.Yttrium.Interpreter.Contracts"
factory="MathNet.Symbolics.InterpreterFactory, MathNet.Yttrium.Interpreter.Service" />
Yttrium comes with a default configuration file. You only need to care about it if you want to replace or extend it with some new modules & services.
Edit Services and Objects provided by the default Modules
Edit- Core.Signal: Yttrium Signal
- Core.Bus: Yttrium Bus
- Core.Port: Yttrium Port
- Core.MathSystem: Yttrium MathSystem
Edit- Conversion.Router: Value Conversion Router
Edit- Library.Library: Library (strict singleton service)
- Library.PackageLoader: Package Loader (service)
Edit- Builder.Builder: Builder (service)
Edit- Interpreter.Parser: Parser (service)
Edit- Simulation.SimulationMediator: Simulation Mediator (strict singleton service)
Edit- Traversing.Scanner: Scanner (service)
- Traversing.AllStrategy: Strategy: All
- Traversing.AllSignalsStrategy: Strategy: All Signals
- Traversing.AllPortsStrategy: Strategy: All Ports
- Traversing.AllSpanningTreeStrategy: Strategy: All Spanning Tree
- Traversing.AllPathsStrategy: Strategy: Strategy: All Paths"
- Traversing.ExistsSignalVisitor: Visitor: Exists Signal
- Traversing.ExistsPortVisitor: Visitor: Exists Port
- Traversing.TrueForAllSignalsVisitor: Visitor: True For All Signals
- Traversing.TrueForAllPortsVisitor: Visitor: True for all Ports
- Traversing.SignalPathCollectVisitor: Visitor: Signal Path Collect
- Traversing.PortPathCollectVisitor: Visitor: Port Path Collect
- Traversing.CollectVisitor: Visitor: Collect
- Traversing.ConditionalCollectVisitor: Visitor: Conditional Collect
- Traversing.SignalActionVisitor: Visitor: Signal Action
- Traversing.PortActionVisitor: Visitor: Port Action
- Traversing.SignalConditionalActionVisitor: Visitor: Signal Conditional Action
- Traversing.PortConditionalActionVisitor: Visitor: Port Conditional Action
- Traversing.BasicVisitor: Visitor: Basic
Edit- Manipulation.Manipulator: Manipulator (service)
- Manipulation.Transformer: Transformer (service)
- Manipulation.TransformationTheoremProvider: Transformation Theorem Provider
Edit- Repository.SignalCache: Signal Cache (service)
Edit- Mediator.Mediator: Mediator (strict singleton service)
- Mediator.SystemMediator: MathSystem Mediator