A method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.Where decomposability was concerned with the derivation of subsystems from overall systems composability addresses the reverse process.Extracting existing software elements from the context for which they were originally designed so as to use them again in different contexts.
A modular design method should facilitate this process by yielding software elements that will be sufficiently autonomous sufficiently independent from the immediate goal that led to their existence as to make the extraction possible.Composability is directly connected with the goal of reusability the aim is to find ways to design software elements performing well defined tasks and usable in widely different contexts.
This criterion reflects an old dream: transforming the software design process into a construction box activity, so that we would build programs by combining standard prefabricated elements.Composability is independent of decomposability. In fact, these criteria are often at odds. Top-down design, for example, which we saw as a technique favoring decomposability tends to produce modules that are not easy to combine with modules coming from other sources.
This is because the method suggests developing each module to fulfill a specific requirement, corresponding to a sub problem obtained at some point in the refinement process. Such modules tend to be closely linked to the immediate context that led to their development, and unfit for adaptation to other contexts. The method provides neither hints towards making modules more general than immediately required nor any incentives to do so.It helps neither avoid nor even just detect commonalities or redundancies between modules obtained in different parts of the hierarchy.
THANX FOR YUOR SERVICE
ReplyDelete