These are general comments about the content of the MIS:
I noticed that the segment submodule doesn't have an MIS. If there’s a reason for that, I would explain it somewhere.
The “Access routine semantics” sub-section in every MIS should define all access programs in the table above the section, including any setters and getters.
I believe that there are some constants used in different sections that aren’t defined. I suggest adding a table in the appendix defining them/giving them a value and use cross-referencing.
There are some definitions in the document that can be expressed like what you’d write in code or with mathematical symbols. For example, in the “access routine semantics” sub-section, you can write the access programs as method signatures "progName(input1, input2, …): …". This would enhance the readability of the document and you wouldn’t have to add more points in the section such as “input”. Also, some “transition” points include conditions (if … else) such as in 7.12.5, and they’re expressed in words. I would express them using the right arrow like what was stated in the “Notation” section.
Hi @oluowoj ,
These are general comments about the content of the MIS:
I noticed that the segment submodule doesn't have an MIS. If there’s a reason for that, I would explain it somewhere.
The “Access routine semantics” sub-section in every MIS should define all access programs in the table above the section, including any setters and getters.
I believe that there are some constants used in different sections that aren’t defined. I suggest adding a table in the appendix defining them/giving them a value and use cross-referencing.
There are some definitions in the document that can be expressed like what you’d write in code or with mathematical symbols. For example, in the “access routine semantics” sub-section, you can write the access programs as method signatures "progName(input1, input2, …): …". This would enhance the readability of the document and you wouldn’t have to add more points in the section such as “input”. Also, some “transition” points include conditions (if … else) such as in 7.12.5, and they’re expressed in words. I would express them using the right arrow like what was stated in the “Notation” section.