The Modular Structure of Complex Systems Team 3

The Modular Structure of Complex Systems Team 3 n Nupur Choudhary n Aparna Nanjappa n Mark Zeits

Overview n A Recap n Complex Systems n Module Guide n Modular Hierarchy n An Example – Linux Internals n Design Through Documentation n Conclusion 2

A Recap: Modules n n What is a Module? u A Work Assignment The Principles: u Each module’s implementation is a secret u Each module’s interface abstractly and precisely described u We abstract from implementation details likely to change u We parameterize changeable aspects that cannot be hidden 3

A Recap: Buzzwords n Hierarchical Structure directed graph with no loops n Encapsulation - language facility n Information Hiding - design principle 4

Some possible classification criteria for modules. . . n Similarity of interface n Ultimate purpose n Type of function or service provided n Similar programming problems n Nature of secret 5

Goals of Modular Structure n Modules can be designed independently n Modules can be tested independently n Modules can be changed independently n Integration goes on smoothly n Reduction of overall software cost!!! 6

A Complex System n Large number of interacting modules (usually greater than a couple hundred modules) n Collective behavior cannot be simply understood in terms of the behavior of modules 7

About Complex Systems. . . n Many implementation decisions n Many details n How can we ……. . u keep the project under control ? u keep the maintenance cost down? u maintain conceptual integrity? u avoid duplication? u deal with unstructured lists of modules? 8

Quick example of a Complex System n The A-7 E Aircraft n Extremely complex Onboard Flight Program n Limited memory n Real-time constraints 9

New Complications n Previous attempts dealt with simple systems i. e. less than 25 modules n Easy to find modules affected by changes in a design decision n What about complex systems with hundreds of modules? ? ? 10

New Complications n Impossible to carefully inspect each module u Most maintainers ignorant about internal structure of most modules n Use of Information Hiding could backfire! n Any solutions? 11

Solution! n Create a hierarchically structured document - Module Guide 12

Module Guide n n n Shows how responsibilities are allocated among modules Modular descriptions arranged according to hierarchical modular structure Leads readers to a module that implements a certain aspect of the system 13

Being Specific…. n Specifically, for each module the Module Guide states its : u Primary Secret u Role u Criteria behind assigning the module its particular responsibility 14

New terms… n Primary Secret: Hidden information contained within the module. n Secondary Secret: Implementation decisions used to implement the module. 15

For example, n In an Address Book System, representation of an address is the primary secret of an Address Storage Module. n The data structures used to represent the address is the secondary secret of the Address Storage Module 16

How does the Module Guide help? n Hierarchical arrangement of modules allows current and future programmers to quickly read about relevant modules without searching through unrelated documentation. 17

How does the Module Guide help? n New programmers can get a good grasp of the project structure by reading the Module Guide. u Eliminates the need for meeting and talking with older programmers familiar with the project 18

How does the Module Guide help? n Aids design review n Helps developers assess the effects of potential changes (enables them to quickly locate modules that would need to be modified. ) 19

How does the Module Guide help? n Saves Time n Saves Effort n Provides Development Support n Lowers maintenance costs for complex software systems! 20

Modular Hierarchy n Modules organized by the type of secret. u First level – Hardware Hiding Modules, Behavior Hiding Module and Software Decision Module n Nodes represent modules. n An edge from node i to node j shows that node j is a sub-module of node i. 21

Modular Hierarchy Top Level Decomposition parent of Second Level Decomposition parent of Third Level 22

Top level Decomposition n Hardware-Hiding Module: Programs that need to be changed if any part of the hardware is replaced. n Behavior-Hiding Module: Programs that need to be changed if there are changes in the required behavior. n Software Decision Module: Hides software design decisions that are based on mathematical theorems, physical facts, and programming considerations. 23

Top level Decomposition The three first-level modules could be used for the top-level design of ninety percent of software systems 24

An Example: Linux Internals 25

Linux: Second-level Decomposition n Hardware-Hiding Module u Drivers - contains modules that pertain to the kernels device drivers u Architecture - modules that contain hardware architecture specific kernel code 26

Linux: Second-level Decomposition n Behavior-Hiding Module u IPC - contains modules that perform inter-process communication u init - contains modules that perform initialization 27

Linux: Second-level Decomposition n Software Decision Module u FS - contains modules that interface with many different file systems u MM - contains modules that control memory management 28

Linux Internals – Uses Structure Linux Kernel Drivers File System . . . ext 2 Memory Manager vfat xfs Network . . . sparq Hardware Architecture i 386 Interprocess Comm . . . alpha 29

Module Guide: Drivers n Drivers: Takes care of the interface and Role implementation between user programs, the kernel and peripherals. Primary secret Criteria This module hides how external / internal hardware etc… is interfaced. The modules included here are specific to how hardware is used. 30

Restricted & Hidden Modules n Restricted Modules: modules that contain information which cannot be hidden in a single module practically. n Hidden Modules: “sub-modules” contained in larger modules that clearly specify where certain functions are performed. 31

Linux Internals – Restricted & Hidden Modules Linux Kernel Drivers File System Network . . . ext 2 Memory R Manager vfat xfs . . . sparq Hardware Architecture i 386 Interprocess Comm . . . alpha journaling. H 32

Parnas’ Experience n “When we tried to work without the guide, ……responsibilities ended up either in two modules or in none. With the module guide, further progress on the design has revealed relatively few oversights”. 33

Parnas’ Experience n Integration testing took only a week n Only nine bugs were discovered. n Location of bugs isolated to single module. n All bugs were quickly fixed. 34

“Design Through Documentation” n Module Guide: Helps developers and maintainers of the system find modules affected by a change n Module Interface Document : Contains precise and complete description of interface to each module 35

“Design Through Documentation” n Module Design Document : An internal design document for each implementation of a module n Requirements Document : Module Guide refers to it for the related changes 36

Tying it all together n Complex Systems are too complex – too many modules! n Well-structured Module Guide needed to provide development support and to cut down maintenance costs. n “Design through Documentation” increases likelihood of product completeness and software reusability. 37

The End 38