A method favors Modular Understandability if it helps produce software in which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.The importance of this criterion follows from its influence on the maintenance process.Most maintenance activities, whether of the noble or not so noble category, involve having to dig into existing software elements.
A method can hardly be called modular if a reader of the software is unable to understand its elements separately.This criterion like the others, applies to the modules of a system description at any level is analysis,design,implementation.the modular understandability criterion will help us address two important questions: how to document reusable components and how to index reusable components so that software developers can retrieve them conveniently through queries.
The criterion suggests that information about a component, useful for documentation or for retrieval, should whenever possible appear in the text of the component itself tools for documentation, indexing or retrieval can then process the component to extract the needed pieces of information. Having the information included in each component is preferable to storing it elsewhere, for example in a database of information about components.
Assume some modules have been so designed that they will only function correctly if activated in a certain prescribed order.for example, B can only work properly if you execute it after A and before C,perhaps because they are meant for use in “piped” form as in the Unix notation encountered earlier.Then it is probably hard to understand B without understanding A and C too.
No comments:
Post a Comment