SYSTEM SOFTWARE DESIGN & ARCHITECTURE

ASSIGNMENT # 01
AFSHAN SALEEM
MSCS-18

MILITARY COLLEGE OF SIGNALS, NUST, RAWALPINDI 27th NOV, 2011

RESEARCH PAPER:1

On the Criteria to be used in Decomposing Systems into Modules

Paper is written with the purpose of describing the importance of modularization and some techniques of the modularization in order to prove its importance. The main two advantages that are attained by the modularization of any system are modularization and the flexibility of a system. Comprehensibility of a system is the property of the system that allows the detailed study of the system on the basis of individual modules hence providing the way of better understanding. Flexibility of a system can be defined as a capability of a system for the sudden changes in one module without the major changes in other modules. Generally the approaches used for modularization are conventional and unconventional. It is proved and demonstrated that the unconventional has the district advantaged over the conventional with the determined goals. There are no specific criteria that can be used for modularization of a system. In this paper some problem are presented with the help of which some criteria is discussed for modularization. When talking about modular programming then we will come to know that there were two major achievements in the field of modular programming. These two advancements were in the form of coding techniques and the assembler. With the help of these facilities it was quite easy for the person to write a one module without having very major knowledge of other modules and the replacement and the reassembly of the modules was quite easy without the reassembly or replacement of the whole system. This kind of facility or technique is quite valuable for the systems that produce the large pieces of code. So, in this context a module is defined as responsibility assignment instead f considering it as a sub part of a program. Modularization basically the design decisions on the system level that must be made and understood and after that only the work on the independent modules can be started. Different types of decisions are there for different kinds of alternatives but the intention is to decide some system level requirements that are affected on more than one module. KWIC Index Production System In this paper a KWIC system is described with the help of which two decomposition approaches are discussed in this paper. It is the system that is being operated on the basis of ordered set of lines. These lines are in the form of ordered set of words and these words are in the form of ordered set of characters. Among the lines coming in the system any of the line may be circulars shifted by removing the first word from the line and placing it in the end of the line. Then all the circular shifts are placed or listed in the alphabetical order. This is the small system and hence no such difficulties are there in this system in context of a modular programming. In this paper this system is being treated as a large system and then two approaches of modularization are

Page | 1

discussed; one that is representing the current approaches and the other one that has been implemented successfully in the class project of under graduation. Modularization 1 According to this approach system was basically divided into 5 modules. These modules are Input: Data is read by the module and stored in the core for processing by other modules in the form of characters that are packed four to a word. Starting address of each line is kept or indicated by the index. Circular Shift: an index is prepared by the module for keeping the track of the circular shift by indicating the address of the first element of each circular shift. Output core is provided with the numbers in pairs, original line number and starting address. Alphabetizing: Input is taken by the module 1 and 2 and the circular shifts are stored in the alphabetical order. Output: This modules uses the arrays produce by the module 1 and 3 and present the formatted list of all the circular shifts. Master Control: Along with controlling the above mentioned modules it also controls the space allocation, error messages and some others. But it should be understood that the above provided information is not much sufficient other information is also required for implementing it completely. Interfaces should be defined between the modules in order to start the work. This approach is in accordance with the modular programming. This modularization is the most common and the most proposed type of modular approach used by many programmers. Modularization 2 Six modules were defined in this approach of modularization. Line Storage: It consists of functions or the subroutines for its calling. CHAR(r,c,w) will be representing the integer that is the cth character in the rth line and the wth word. SETCHAR(r,c,w,d) will be presenting the cth character in the rth line and wth word that is represented by d as CHAR(r,c,w)=d. Words(r) will be giving the numbers of words in the line r. The calling of these routines are in a certain way and if that routes are not followed then certain errors could also occur. Other functions like DELINE and DEWRD are used for deleting the lines that have already been stored. Input: Reads the lines and stored them through the line storage module. Circular Shift: It contains all of the circular shifts. Function CSCHAR(l,w,c) gives the value of the cth character and wth word in the lth circular shift. The specifications of the functions are like this. If I is less than j then shifts in the line I are preceding the shifts in the line j and for each line the first shift is the original line and the second shift is the circular shift of the original one. Function of CSSETUP must be called before other functions got their values. Alphabetizer: this module consist of two functions one is called as ALPH that must be called before other functions defined the value and the other one is ITH(i) providing the index of circular shift.
Page | 2

Output: It will print the set of lines or the circular shift. Master Control: Controls the modules mentioned above. Comparison of Two Modular Approaches The two approaches are quite similar if seen with the respect of programming effort as both will be providing the independent programming. After assembly both the decomposition may provide quite the similar structure. Systems may be identical in a running environment but are quite different in the aspects of changing, documenting, understanding and some others. Some of these aspects are discussed in this paper. Changeability Many design decision decisions are there that are expected to change, list of some of them are presented here 1. The input format of the data. 2. Decision for storing all the input lines in core that may not be feasible for the large systems. 3. Packing the four characters in the word that may not feasible for the small systems. 4. The decision of indexing for the circular shift that may not feasible for the large or small systems as they may prefer to store the indexes. 5. The decision to alphabetize the list at one time is not advantageous as in many cases periodic functioning on the basis of requirement is needed. The first change will remain confined to one module in both the decomposition approaches. The second change will result in the change of all modules in decomposition 1 but in decomposition 2 only the module 1 will be affected by this change. The third change will again be affecting all the modules in decomposition 1 but in decomposition 2 all modules will not be affected. The fourth change in the decomposition 1 is associated with the alphabetizer and the output routines while in decomposition 2 it is only associated with circular shift. The fifth change will be difficult for the decomposition 1 but in decomposition 2 the alphabetizer module was designed in a way that the process of alphabetization is hidden form user. Independent Development In the decomposition 1 the interfaces between the modules are quite complex so the design decisions in turn will be complex and difficult for the each module in a system. In the decomposition 2 the modules are present in the more abstract form and hence the design decisions are less complex and the independent development will be much earlier. Comprehensibility In the first decomposition the understanding of the output module is dependent on the understanding of the other modules like alphabetizer, circular shift and input module but according to the writer this will not be the case in the second decomposition. Criteria The criterion used in the first decomposition was to make each major step in processing a module. So simply we can say that a flowchart can be used for the first decomposition. This is the quite common approach and is useful for systems processing the 5,000 to 10,000 instructions but systems beyond this order will be requiring some additional features.
Page | 3

The criterion used in the second decomposition is information hiding. Each module is working dependent on the knowledge provided to it with certain decisions hidden from other modules. Like circular shift in some case may not make a table but just process the characters on the demand. Improvement in Circular Shift Module Writer said that in circular shift the information revealed is more than necessary. On one side the method of storing or calculating the list is hidden but on the other hand an order for doing that is specified. The only needed specifications are Lines in circular shift will all exist in a table. No one line will be included twice. A function is there for the identification of the original line. In accordance with the criteria of information hiding some examples of the decomposition can be seen. 1. Data Structures, its internal workings and likings are part of the module and are not shared by other modules in a system. 2. The sequence of instructions necessary to call a given routine and the routine itself are part of the same module. By assigning responsibility for generating the call to the person responsible for the routine we make such improvements easier and also make it more feasible to have several distinct sequences in the same software structure. 3. The format of control blocks used in the Operating Systems in the form of queues is hidden in the control block module. 4. Character codes, alphabetic orderings, and similar data should be hidden in a module for greatest flexibility. 5. The order of processing for the certain items must be hidden within a single module. Efficiency and Implementation A special care is required in the second decomposition otherwise it will become less efficient as compared to the first decomposition. The repeatedly switching between the modules is present in the decomposition 2 but this is not present in the decomposition 1. For the efficiency of the decomposition 1 a tool is required for writing the functions in the form of subroutines but assembled by the any appropriate implementation. With this approach the division of the modules will not be visible in the final code and for that purpose additional modifications will be required. A Decomposition Common to a Compiler and Interpolator for the Same Language It was discovered that the approach used for this decomposition is also valid for compiler and several forms of the interpreters. There is quite a difference between the final representations but the design decisions at the decomposition level will be quite similar. On the other hand if the decomposition is done with the classical lines of compiler or the interpreter then this similarity will not be there.

Page | 4

Hierarchical Structure The hierarchy of the system is formed as follows: If there is a system table then it will function on without the other modules and hence it will be on level 1. Line storage will be on level 1 if no symbol table is used for it or otherwise on level 2. Line storage is required by circular shift and input module for their functionality. Circular shift will be required by output and alphabetizer but since circular Shifter and line holder are in some sense compatible, it would be easy to build a parameterized version of those routines which could be used to alphabetize or print out either the original lines or the circular shifts. So, in the first use they will not require the circular shift but in the later they would be requiring it. So, there is a hierarchy in a system if the modules have a certain relation between them in terms of uses or depends upon. The use of certain relations is beneficial sometimes as modules sometimes depend partly on the other modules. So, there is a benefit because the upper parts use the services of lower levels and hence the upper levels can be removed and the new system can be build upon the lower levels. Conclusion The decomposition of the module on the basis of flowchart is not at all feasible. The decomposition should be done on the basis of difficult design decisions that are most likely to change and then each module should be designed to hide those decisions from other modules. The concept should be adopted that subroutines and programs are the assembled collection of codes from various modules instead of considering a module as a one or more subroutine. Applications of Modularization Modular programming is a software design technique that increases the extent to which software is composed of separate, interchangeable components called modules by breaking down program functions into modules, each of which accomplishes one function and contains everything necessary to accomplish this. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components. Modules are typically incorporated into the program through interfaces. [1] Traditional programming languages have been used to support modular programming - since at least the 1960s. Modular programming is a loosely defined concept with no official definition. It is, in essence, simply a programming technique. Exactly where modularized programming ends, and Dynamically Linked Libraries or Object-oriented programming starts in this context is subjective. It might be defined as the natural predecessor of OOP, or an evolutionary step beyond it - depending upon viewpoint. A quite good example of the modularization is the CDM approach. The Constructionist Design Methodology (CDM) was developed by artificial intelligence (AI) researcher Kristinn R. Thrisson and his students at Columbia University and Reykjavik University for use in the development of cognitive robotics, communicative humanoids and broad AI systems. The creation of such systems requires integration of a large number of functionalities that must be
Page | 5

carefully coordinated to achieve coherent system behavior. CDM is based on iterative design steps that lead to the creation of a network of named interacting modules, communicating via explicitly typed streams and discrete messages. CDM has been used in the creation of many systems including robotics, facial animation, large-scale simulation and virtual humans. One of the first systems was MIRAGE, a simulated human in an augmented-reality environment that could interact with people through speech and gesture. Component-based software engineering (CBSE) (also known as component-based development (CBD)) is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software. Software engineers regard components as part of the starting platform for serviceorientation. Components play this role, for example, inWeb services, and more recently, in service-oriented architectures (SOA), whereby a component is converted by the Web service into a service and subsequently inherits further characteristics beyond that of an ordinary component. WorleyParsons modular experience encompasses some of the worlds most hostile and remote locations including the arctic regions of Alaska, Canada and Russia, the dense forests of Colombia, Saudi Arabian deserts, and the remote Australian coastline. WorleyParsons has provided innovative and first-of-a-kind modular solutions to solve the unique challenges associated with our customers projects in remote locations and harsh environments. Our modularization experience began in 1961 with a single skid-mounted, 10 tonne-per day sulphur recovery plant; the first of many designed and built as package plants for customers throughout the world. We followed this with the modular design for a 22,000 barrels per day (BPD) grassroots refinery in Alaska, beginning our long involvement with North Slope modular facilities which continues today. Since these early days on the North Slope, WorleyParsons has expanded its modular capabilities to include the design and installation of facilities for upstream oil and gas processing, downstream refining, mining and minerals processing, and chemical industries in over 30 countries. WorleyParsons combines its offshore design capability with its onshore Very Large Module (VLM) expertise to optimize module size and density. This approach results in smaller, more economical module footprints, and in some cases, increased logistics benefits. WorleyParsons also combines its proven EPCM track record and extreme environments and remote locations experience with its specialist in-house skills to provide customers with cost effective, innovative modular solutions. [2]

Page | 6

RESEARCH PAPER: 2

Designing Software for Ease of Extension and Contraction

In the paper titled Designing Software for Ease of Extension and Contraction, David Parnas discusses Software design that eases identification of working system subsets and addition of extensions is a special case of design for change, and therefore should be pursued. Parnas suggests methodology that helps achieve better, more flexible design structure. Key points of paper include Family of Programs, Uses Relations,Information Hiding and Virtual Machines . Motivation: common complaints about software systems are subset of capabilities are not possible because subsets do not work on their own. Adding a capability (no matter how simple) implies major code rewriting. Removing a capability also implies major code rewriting. Software as a Family of Programs: According to Parnas: A set of programs is considered a family if they have so much in common that it pays to study their common aspects before looking at their differences. However there are number of ways members of a program family can differ: Run on different hardware configurations .Same functions, but different format in input/output, data structures, algorithms etc and lastly that is also focus of paper is that Some users may require only a subset of the services or features that other uses need. Obstacles when trying to extend or shrink systems: Excessive information distribution, Chain of data-transforming components (pipe-and-filter deficiency), Components that perform more than one function and Loops in the Uses Relation Steps toward a Better Structure: for making a better structure we define requirements as: Identify subsets first; Search for minimal useful subsets and increments to the system and include them in requirements .Secondly Information Hiding is define as : During module definition, try to isolate changeable parts in modules and create interfaces between module and rest of system; Modules should not be aware of other modules existence, thirdly The Virtual Machine Concept is to think module as responsibility assignment; Create set of VMs so problem can be broken into smaller parts, and subsets found more easily. Each VM must be a useful subset and last concept is designing the Uses structure. Uses structure: A uses B if correct execution of B is necessary for A to complete task described in its specification. Uses is not the same as invokes. Unrestricted usage causes module interdependency. Criteria used when allowing one program to use another: A is simpler because it uses B; B is not more complex because it is not allowed to use A, There is a useful subset containing B and not A. There is no conceivable useful subset containing A but not B.
Page | 7

Sandwiching technique used when criteria cannot be followed, but programs can benefit from using each other. Family Concept: Some users may require only a subset of the services or features that other users need. These less demanding users may demand that they not be forced to pay for the resources consumed by the unneeded features. Subsets & Extensions are minimal subsets of a useful nature plus minimal possible increments. They develop family of programs, not individual one-off systems. Their common functionalities are share code and reduce maintenance cost. Design and Decomposition Decisions: Determine module secrets items most likely to change: separate them in modules, Information hiding/encapsulation. Dont give away details of implementation; dont reveal any internal design decisions. Apply virtual Machine approach when possible. Conclusions: Early subset identification meets variety of need and handles scheduling problems. Use of the virtual machine make program extensible and removable. Generality vs. flexibility generality implies variable use as run-time cost and easier maintenance (single version) .Flexibility implies ease of change as design-time cost and multiple versions. Duplication is avoided by proper use of structured programming. Allow for subsets and extensions provide convenience without extra cost and no development of support software. Design model allows consistent development and more design in less time.

REFERENCES
[1]. http://en.wikipedia.org/wiki/Modular_programming [2]. http://www.worleyparsons.com/CSG/HYDROCARBONS/SPECIALTYCAPABILITIES/Pa ges/Modularization.aspx

Page | 8