Designing Software for Ease of Extension and ContractionPresentation OutlineProblem and MotivationOverview of ContributionObservationsHow the lack of subsets and extensions manifests itselfSteps towards a better structureSteps towards a better structure(2)Example: Address Processing SubsystemAn Address Processing SubsystemSlide 11Slide 12ImpactOpen QuestionsDesigning Software for Ease of Extension and ContractionDavid ParnasPresented by Kayra HopkinsIEEE Transactions on Software Engineering, Vol. , No. 1, March 1979 pp. 128-138.Presentation OutlineProblemMotivationObservationsContributionExampleImpactQuestionsProblem and MotivationProblemHow can we design software so that is is easily extended and contracted?MotivationComplaints that most software systems as commonly/intuitively designed are not flexible.Changes require a lot of code rewritingOverview of ContributionObservationsRecognizing how the lack of Subsets and extensions manifests itself The Technique: Steps towards a better structureObservationsA software solution isn’t a single programSoftware as a family of programsChange is inevitableSo why not anticipate it with preparation?How the lack of subsets and extensions manifests itself Excessive Information DistributionA Chain of Data Transforming ComponentsComponents That Perform More Than One TaskLoops in “Uses” RelationSteps towards a better structureIdentify Subsets firstSolves problem of components with more than one functionMakes system more flexible to changeInformation Hiding: Define Interfaces and ModulesSolves problem of excessive information distributionVirtual Machine ConceptAddresses chain of data problemDesign the “Uses” StructureEliminates loops in the “uses” relationSteps towards a better structure(2)Design the “Uses” StructureProgram A “uses” program B if function of A depends on correct implementation of B.Structure has hierarchy.ConsequencesA is simpler because it uses B.B doesn’t use A, so it doesn’t increase its complexity.There exists a useful subset containing B and not A.There isn’t a practical subset containing A but not B.Example: Address Processing SubsystemAssumptions:Specific address information is to be processedInput formats are subject to change. Likewise with output formats.For each system the format for input and output may be done in one of three ways.Representations of address may be different for each system.Only a subset of the addresses are needed in main memory at any given time.An Address Processing SubsystemDesign DecisionsInput and Output will be table drivenRepresentations of addresses in core will be the “secret” of an address storage module(ASM)When the number of addresses to be stored exceeds the capacity of ASM, programs will use an address file module (AFM)Implementation of AFM will use ASM as a submodule along with a block file module (BFM)An Address Processing SubsystemComponent ProgramsAddress Input ModuleAddress Output ModuleAddress Storage ModuleBlock File ModuleAddress File ModuleAn Address Processing SubsystemUses RelationImpactModern Programming LanguagesClass DiagramsMore Flexibility!Open QuestionsWhat is a universal message that we can take away from this problem? Could planning for change not be cost-effective?/Is there ever a situation that you would not want to plan for change?Should this technique be modified for today’s problems and applications? If so,
View Full Document
Unlocking...