Actualizado documento y algun diagrama

4+1view-model.md

 # The "4+1" Model View of Software Architecture
 
-The [4+1 model view][4+1 model view], designed by Philippe Krutchen, present a way to describe the architecture of software systems, using multiple and concurrent views. This use of multiple views allows to address separately the concerns of the various 'stakeholders' of the architecture such as end-user, developers, systems engineers, project managers, etc.
+The [4+1 model view][4+1 model view], designed by Philippe Krutchen, presents a way to describe the architecture of software systems, using multiple and concurrent views. This use of multiple views allows to address separately the concerns of the various 'stakeholders' of the architecture such as end-user, developers, systems engineers, project managers, etc.
 
 The software architecture deals with abstraction, with decomposition and composition, with style and system's esthetic. To describe a software architecture, we use a model formed by multiple views or perspectives. That model is made up of five main views: logical view, development view, process view, physical view and scenarios or user cases.
 
@@ -28,7 +28,7 @@ To represent the architecture of the fragments that make up *PySD* a package dia
 
 **pysd** module interacts with modules in the **py_backend** package. This package has two sub-packages: **vensim** and **xmile**. **Vensim** package contains all the needed logic to translate *Vensim* models.
 
-In [PySD relationships between modules] the relationships between the main modules are represented. For clarity, each module has been represented by with name package.
+In [PySD relationships between modules] the relationships between the main modules are represented. For clarity, each module has been represented with its name package.
 
 ![PySD relationships between modules]
 
@@ -37,11 +37,11 @@ As previously discussed, users interact with **pysd** module. In turn, **pysd**
 ## The logical view of PySD
 
 The purpose of each PySD module is detailed below as well as the most important functions of each module.
-It should be noted that in diagrams it has been necessary, it is detailed input parameters with *in*  notation, output parameters with *out* notation and parameters that are modified in a function with *inout* notation are detailed. In addition, the different types of parameters that could be are described through notes in convenient diagrams, which is due to Python's dynamic typing.
+It should be noted that in diagrams it has been necessary, it is detailed input parameters with *in*  notation, output parameters with *out* notation and parameters that are modified in a function with *inout* notation. In addition, the different types of parameters that could be, are described through notes in convenient diagrams, which is due to Python's dynamic typing.
 
-In [Main modules of PySD] **pysd**, **vensim2py** and **table2py** modules are presented with detail. The **pysd** module is in package *pysd*, while **vensim2py** and **table2py** module, in package *vensim*.
+In [Main modules of PySD]: **pysd**, **vensim2py** and **table2py** modules are presented with detail. The **pysd** module is in package *pysd*, while **vensim2py** and **table2py** module, in package *vensim*.
 
-The **pysd** module has the necessary functions to allow the user to create the translation of a Vensim model to Python. The function **read\_vensim** takes as a parameter a Vensim model in text format and converts it to an instance of the Model class, which is in the **functions** module. In the same way, **pysd** has **load** function, which can generate from a Python model to an instance of *Model* class, which can be able to execute and perform the simulation. The **load** function is used within **read\_ vensim** function.
+The **pysd** module has the necessary functions to allow the user to create the translation of a Vensim model to Python. The function **read\_vensim** takes as a parameter a Vensim model in text format and converts it to an instance of the Model class, which is in **functions** module. In the same way, **pysd** has **load** function, which can generate from a Python model to an instance of *Model* class, which can be able to execute and perform the simulation. The **load** function is used within **read\_ vensim** function.
 ![Main modules of PySD]
 The table2py module has only one function, **read_tabular**. This function allows to read a Vensim model in table form (csv, tab or xlsx) and convert it into an instance of Model class.
 
@@ -52,11 +52,12 @@ The main function of the *vensim2py* module, which is also used by **read\_vensi
 The **get\_model\_elements**, **get\_equation\_components**, **parse\_general\_expression** and **parse\_lookup\_expression** functions have the four remaining grammars of *PySD* which are: *model\_structure\_grammar*, *component\_structure\_grammar*, *expression\_grammar* and *lookup\_grammar*, respectively. Moreover, after each of these functions, the NodeVisitor classes that are associated with each grammar are defined. These classes allow to perform and parse the parse tree.
 
 Noteworthy is the **\_include\_common\_grammar** function which has the basic grammar rules used by all other grammars.
+
 Due to the complexity of vensim2py, since it has the five functions in which PySD grammars and their visitor classes are defined, in [Simplified vensim2py module] it is represented without detail. These classes are: FileParser, ModelParser, ComponentParser, ExpressionParser and LookupParser. Note that these classes inherit from the NodeVisitor class, that provides an inversion-of-control framework for walking a tree and returning a new construct based on it.
 
 ![Simplified vensim2py module]
 
-In [Classes of pysd grammars] and [Classes of pysd grammar2] are represented the classes associated to the grammars.  
+In [Classes of pysd grammars] and [Classes of pysd grammars2] are represented the classes associated to the grammars.  
 ![Classes of pysd grammars]
 ![Classes of pysd grammars2]
 The methods of each class are the visitor methods associated with the different grammar rules. There is not a visitor method for each rule, but there is a visitor method associated with a rule that serves to store certain information about the parsed model. Within the visitor method, that relevant information is stored in the attributes of each class, which are then returned as a result of the grammar.
@@ -108,8 +109,9 @@ Two main scenarios can be distinguished throughout the
 [External module]:/images/logical-view/external1.png "External module"
 [External module2]:/images/logical-view/external2.png "External module"
 [Decorators module]:/images/logical-view/decorators-module.png "Decorators module"
+
 <!-- Process view -->
-[Process view 1]:/images/process-view/main1.jpg "Process view 1"
+[Process view 1]:/images/process-view/main1.png "Process view 1"
 [Process view 2]:images/process-view/divide-sentences2.png "Process view 2"
 [Process view 3]:/images/process-view/macro-list3.png "Process view 3"
 [Process view 4]:/images/process-view/translate-section4.png "Process view 4"