System Architecture - Revision history

Osskyn: /* Reports */

2024-11-26T12:31:41Z

Reports

Osskyn: /* Kommandon */

2024-11-26T12:31:18Z

Kommandon

Peder at 07:29, 26 May 2010

2010-05-26T07:29:05Z

Peder: moved System Architecture Description to System Architecture

2010-05-26T07:10:26Z

moved System Architecture to System Architecture

Peder: /* Layering */

2010-05-26T07:08:44Z

Layering

Peder: /* Layering */

2010-05-26T07:07:55Z

Layering

Peder at 07:01, 26 May 2010

2010-05-26T07:01:38Z

Fkl: /* Forest model and Calculations */

2010-05-21T09:29:02Z

Forest model and Calculations

Fkl: /* Persisting Data */

2010-05-21T09:08:09Z

Persisting Data

Fkl: /* Persisting Data */

2010-05-21T09:06:50Z

Persisting Data

@@ Line 167: / Line 167: @@
 === Reports ===
-Standrd reports are developed in Visual Studio as Microsoft Client Report Definitions (rdlc). These are shown in the applications with the <tt>ReportViewer</tt> component.
+Standard reports are developed in Visual Studio as Microsoft Client Report Definitions (rdlc). These are shown in the applications with the <tt>ReportViewer</tt> component.
 === Help ===

@@ Line 155: / Line 155: @@
 The exception message should be brief. If a longer description is needed, set the <tt>HelpLink</tt> for the exception.
-=== Kommandon ===
+=== Commands ===
 The Command design pattern is used to encapsulate actions that the user performs into separate objects. There are several benefits with this simple pattern, so it should be used frequently:

← Older revision		Revision as of 07:29, 26 May 2010
Line 1:		Line 1:
−	[[Category:System design]]	+	[[Category:System design\|Architecture]]
	[[Category:Developer's guide]]		[[Category:Developer's guide]]

@@ Line 65: / Line 65: @@
 === Layering ===
-[[file:layering.png|500px]]
+[[file:layering.png|600px]]
 The system is built with a layered architecture (see for example [[ISBN 0321154959|Bass et al: Software Architecture in Practice]]. The layering is based on the system logic, where each layer adds functionality from a lower layer.

@@ Line 65: / Line 65: @@
 === Layering ===
-[[file:layering.png]]
+[[file:layering.png|500px]]
 The system is built with a layered architecture (see for example [[ISBN 0321154959|Bass et al: Software Architecture in Practice]]. The layering is based on the system logic, where each layer adds functionality from a lower layer.

← Older revision	Revision as of 07:10, 26 May 2010
(No difference)

← Older revision		Revision as of 07:01, 26 May 2010
Line 1:		Line 1:
		+	[[Category:System design]]
		+	[[Category:Developer's guide]]
		+
	== Architectural Goals and Quality ==		== Architectural Goals and Quality ==

@@ Line 18: / Line 18: @@
 The key entity in Heureka is the Treatment Unit, that represents a stand, i.e. an area restricted in space, with the same type of forest. A Treatment Unit is the smallest unit treatments are applied for. Each treatment unit contains one or more predictions units. A prediction unit represents a plot or a cell inside the treatment unit. Each prediction unit contains trees. Trees have [[Handling of tree states|different states]], identifying if the tree object represents a sapling, a tree, is dead and so forth. Each of these entities [[handle different time periods]].
-Treatments are simulated in Heureka with different type of treatment models such as regeneration, fertilization, cleaning, thinning, and final felling.
+Treatments are simulated in Heureka with different type of [[Design of Treatment Models|treatment models]] such as regeneration, fertilization, cleaning, thinning, and final felling.
-Growth and yield models calculates tree related values such as volume, basal area growth, height, age, and bark thickness. With help of the growth models, a treatment unit can grow, i.e. the state in a future time period can be calculated.
+Growth and yield models calculates tree related values such as volume, basal area growth, height, age, and bark thickness. With help of the growth models, a [[Calculation of growth|treatment unit can grow]], i.e. the state in a future time period can be calculated.
 [[Result models]] are used to calculate different types on results. Based on the state of a treatment unit in a given time period, different types of results can be calculated, such as cost and revenue of treatments, amount of biomass in the living forest, or amount of litter added to the ground. A result model may also produce a result based on the results in other result models (e.g. the recreation model uses input from the dead wood model).

@@ Line 126: / Line 126: @@
 * Application configuration is stored in the file system (typically in the user's application data folder)
-Storgate to files are mainly done via serialization. However, a major drawback with serialization is that versioning can be a problem. Also, performance can be an issue. The subsystem <tt>Slu.Heureka.BaseLayer.SerializationManagement</tt> provides helper classes to resolve some of these issues. The classes <tt>SerializationReader</tt> and <tt>SerializationWriter</tt> improves performance drastically. A recommended practice is to always serialize a version number first. By doing this, deserialization of different versions can easily be implemented. A different problem is when a class changes its name or becomes obsolete. A solution for that problem has not been implemented in the Heureka system, but it should be possible to do it using the <tt>[[http://msdn.microsoft.com/en-US/library/system.runtime.serialization.serializationbinder|SerializationBinder]]</tt> class in the .Net framework.
+Storgate to files are mainly done via serialization. However, a major drawback with serialization is that versioning can be a problem. Also, performance can be an issue. The subsystem <tt>Slu.Heureka.BaseLayer.SerializationManagement</tt> provides helper classes to resolve some of these issues. The classes <tt>SerializationReader</tt> and <tt>SerializationWriter</tt> improves performance drastically. A recommended practice is to always serialize a version number first. By doing this, deserialization of different versions can easily be implemented. A different problem is when a class changes its name or becomes obsolete. A solution for that problem has not been implemented in the Heureka system, but it should be possible to do it using the <tt>[[http://msdn.microsoft.com/en-US/library/system.runtime.serialization.serializationbinder |SerializationBinder]]</tt> class in the .Net framework.
 For simple configuration data, the class <tt>ConfigurationStore</tt> should be used.

@@ Line 136: / Line 136: @@
 ;Typed data sets: Used when the user is updating data
 ;Custom OR-mappning: Used for the result database
 === Error Handling ===