arc42 · neeleym · Jan 6, 2016
diff --git a/VisioDiagram/Architecture.png b/VisioDiagram/Architecture.png
diff --git a/VisioDiagram/Architecture.svg b/VisioDiagram/Architecture.svg
diff --git a/VisioDiagram/Architecture.vsdx b/VisioDiagram/Architecture.vsdx
diff --git a/VisioDiagram/EvaluateArchitecture.png b/VisioDiagram/EvaluateArchitecture.png
diff --git a/VisioDiagram/EvaluateArchitecture.svg b/VisioDiagram/EvaluateArchitecture.svg
diff --git a/VisioDiagram/MaintainImplementation.png b/VisioDiagram/MaintainImplementation.png
diff --git a/VisioDiagram/MaintainImplementation.svg b/VisioDiagram/MaintainImplementation.svg
diff --git a/VisioDiagram/README.md b/VisioDiagram/README.md
@@ -2,7 +2,7 @@ arc42-process-diagram
 ==========================
 
 This diagram is being developed using visio. ( I know ;) ) I've choosen it because the svg exporter works pretty well.
-Using DOM-Manipulation with php, i am able to add generated links to sub sites. Each element has an subpage that is located in the arc42 subfolder.
+Using DOM-Manipulation with php, i am able to add generated links to sub sites. Each element has a subpage that is located in the arc42 subfolder.
 
 http://www.kreissl.info/Architecture
 

diff --git a/VisioDiagram/Requirements.png b/VisioDiagram/Requirements.png
diff --git a/VisioDiagram/Requirements.svg b/VisioDiagram/Requirements.svg
diff --git a/VisioDiagram/arc42/Alternatives.txt b/VisioDiagram/arc42/Alternatives.txt
@@ -1 +1 @@
-Critical architectural decisions should be supported by alternatives that had been discussed or evaluated.
+Critical architectural decisions should be supported by alternatives that have been discussed or evaluated.
diff --git a/VisioDiagram/arc42/ArchitecturalDecisions.txt b/VisioDiagram/arc42/ArchitecturalDecisions.txt
@@ -1,2 +1,2 @@
 Every architectural decisions must be documented in an understandable and logical way.
-This decisions can belong to technical decisions like chosen frameworks or other dependencies, but always relating to the customers or stakeholders point of view.
+These decisions can become part of technical decisions like chosen frameworks or other dependencies, but always relating to the customers or stakeholders point of view.
diff --git a/VisioDiagram/arc42/ArchitectureGoals.txt b/VisioDiagram/arc42/ArchitectureGoals.txt
@@ -1 +1 @@
-The list of architecture goals describes all quality criteria and other non functional goals of the architecture.
+The list of architecture goals describes all quality criteria and other non-functional goals of the architecture.
diff --git a/VisioDiagram/arc42/Bottom-Up.txt b/VisioDiagram/arc42/Bottom-Up.txt
@@ -1 +1 @@
- Bottom-Up means starting with details going to the abstractions. Most implementations are done using bottom-up strategies. Planing and modelling are mostly done top-down!
+ Bottom-Up means starting with details and moving toward abstractions. Most implementations are done using bottom-up strategies. Planning and modelling are mostly done top-down!
diff --git a/VisioDiagram/arc42/BuildingBlockView.txt b/VisioDiagram/arc42/BuildingBlockView.txt
@@ -1 +1 @@
-This is also known as component view and describes a part of the model as a white box including other blackboxes. It is a structural diagram that shows a specific view to the system.
+This is also known as a component view and describes a part of the model as a white box that may include other blackboxes. It is a structural diagram that shows a specific view to the system.
diff --git a/VisioDiagram/arc42/BusinessRules.txt b/VisioDiagram/arc42/BusinessRules.txt
@@ -1 +1 @@
-Most enterprise software systems include logic in form of business rules. Those rules can be described in many ways. There can be static XML files, in-line hard-coded rules or complex rule engines that are configurable at runtime and work dynamically.
+Most enterprise software systems include logic in the form of business rules. Those rules can be described in many ways. There can be static XML files, in-line hard-coded rules, or complex rule engines that are configurable at runtime and work dynamically.

diff --git a/VisioDiagram/arc42/CodeMetrics.txt b/VisioDiagram/arc42/CodeMetrics.txt
@@ -1,2 +1,2 @@
-Code metrics measures a specific property of a part of a software or its specifications. Examples for metrics are LoC (Lines Of Code), Cohesion, Number Of Bugs, Coupling
+Code metrics measure a specific properties of software or its specifications. Examples for metrics are LoC (Lines Of Code), Cohesion, Number Of Bugs, Coupling
 or Cyclomatic complexity.
diff --git a/VisioDiagram/arc42/Concepts.txt b/VisioDiagram/arc42/Concepts.txt
@@ -1,2 +1,2 @@
-Technical concepts can be evaluated using proof of concepts. Keep in mind that it is better to decide as late as possible to minimize the risc of wrong decisions. This is called 
+Technical concepts can be evaluated using a Proof-of-Concept (PoC) approach. Keep in mind that it is better to decide as late as possible to minimize the risk of wrong decisions. This is called 
 "last responsible moment" or just LRM.
diff --git a/VisioDiagram/arc42/TechnicalConcepts.txt b/VisioDiagram/arc42/TechnicalConcepts.txt
@@ -1,2 +1,2 @@
-To fulfil the requirements the software solution may need technical concepts and frameworks.
+To fulfill the requirements the software solution may need technical concepts and frameworks.
 Use tested and well known patterns and concepts that match specific parts of your solution.
diff --git a/VisioDiagram/arc42/choose.txt b/VisioDiagram/arc42/choose.txt
@@ -1 +1 @@
-You will have to make desicsions about tools and frameworks. In difficult cases it should be documented as architectural decision including the reasons the made the decision!
+You will have to make desicsions about tools and frameworks. In difficult cases it should be documented as an architectural decision including the reasoning behind the decision!
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		Critical architectural decisions should be supported by alternatives that had been discussed or evaluated.
		Critical architectural decisions should be supported by alternatives that have been discussed or evaluated.
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		The list of architecture goals describes all quality criteria and other non functional goals of the architecture.
		The list of architecture goals describes all quality criteria and other non-functional goals of the architecture.
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		Bottom-Up means starting with details going to the abstractions. Most implementations are done using bottom-up strategies. Planing and modelling are mostly done top-down!
		Bottom-Up means starting with details and moving toward abstractions. Most implementations are done using bottom-up strategies. Planning and modelling are mostly done top-down!
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		This is also known as component view and describes a part of the model as a white box including other blackboxes. It is a structural diagram that shows a specific view to the system.
		This is also known as a component view and describes a part of the model as a white box that may include other blackboxes. It is a structural diagram that shows a specific view to the system.
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		Most enterprise software systems include logic in form of business rules. Those rules can be described in many ways. There can be static XML files, in-line hard-coded rules or complex rule engines that are configurable at runtime and work dynamically.
		Most enterprise software systems include logic in the form of business rules. Those rules can be described in many ways. There can be static XML files, in-line hard-coded rules, or complex rule engines that are configurable at runtime and work dynamically.
Expand Down
Original file line number	Diff line number	Diff line change
		@@ -1 +1 @@
		You will have to make desicsions about tools and frameworks. In difficult cases it should be documented as architectural decision including the reasons the made the decision!
		You will have to make desicsions about tools and frameworks. In difficult cases it should be documented as an architectural decision including the reasoning behind the decision!