Software Design SEII - Lecture 10

Software DesignSEII-Lecture 10Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapBasic conceptsRisk, positive/negative risk management, Risk utility / tolerance (risk averse, risk seeking, risk neutral)Planning risk managementRisk management plan, contingency and fallback plansIdentifying risksBrainstorming, Delphi technique, interviewing, SWOT analysis, checklists, risk registersPerforming qualitative and quantitative risk analysisPlanning risk responsesRisk avoidance, risk acceptance, risk transference, risk mitigation, Risk exploitation, Risk sharingMonitoring and controlling risks2What is Design?CreativityAchieving goals within constraintsStakeholder requirements, business needs, and technical considerationsRepresentation or model of the softwareSoftware architecture, components, data structures, and interfaces3Goal of DesignRoman architecture critic Vitruvius said, “well-designed buildings were those which exhibited firmness, commodity, and delight”Same for the good softwareFirmness: bug-freeCommodity: suitable for the intended purposeDelight: pleasurable user experienceModel that exhibits firmness, commodity, and delight4Design Within the Context of SETechnical kernel of software engineeringIndependent of software process modelLast modeling activity before codingFocus on qualityTranslation of stakeholder requirements into a software productWithout design, you are at riskLot of rework5Design ProcessAn iterative processDifferent levels of abstractionCriteria to evaluate software designDesign must implement all explicit and implicit requirementsDesign must be readable and understandableDesign should provide the complete picture6Quality Guidelines [1/2]Design should exhibitRecognizable design patternsGood design characteristicsImplementation in an evolutionary fashionDesign should be modularDesign should contain distinct representations of data, architecture, interfaces, and componentsDesign should lead to appropriate data structures7Quality Guidelines [2/2]Design should lead to independent componentsDesign should reduce connections complexityDesign should be derived using a repeatable methodDesign should be represented using understandable notationApplication of design knowledge rather than by chance achievement8Quality AttributesDifferent modelsFURPS by HPFunctionalityFeature set and capabilities of the programUsabilityHuman factors e.g. aesthetics and consistencyReliabilityFrequency and severity of failurePerformanceProcessing speed and response timeSupportabilityMaintainability, compatibility 9Evolution of Software DesignA continuing processTop-down approachProcedural aspects / structured programmingObject-oriented approachSoftware architecture / design patternsAspect-oriented approach, model-driven and test-driven development10Design Concepts“The beginning of wisdom for a [software engineer] is to recognize the difference between getting a program to work, and getting it right.“These concepts help toSet criteria for partitioningSeparation of data structure details from conceptual representationProvide criteria for qualityFollowed in traditional and object-oriented software development11AbstractionModular solutionProblem-oriented technology coupled with implementation-oriented technologyProcedural abstractionSequence of instructionsExample: ‘open’ the doorData abstractionCollection of data / data objectsExample: open the ‘door’12Architecture [1/2]Overall structure of the softwareProvides conceptual integrity of a softwareMajor system elements and their interactionArchitectural patterns solve common design problemsStructure modelsOrganized collection of system componentsFramework modelsRepeatable frameworks for specific applications13Architecture [2/2]Dynamic modelsBehavioral aspects of program architectureProcess modelsThe design of business or technical processFunctional modelsFunctional hierarchy of a systemArchitectural Description Languages (ADL)Examples: Architectural Analysis and Design Language (AADL), C2, Darwin14Patterns“A pattern is a named nugget of insight which conveys the essence of the proven solution to a recurring problem within a certain context amidst competing concerns.”“A design structure that solves a particular problem within a specific context.” Help to determine Whether it is applicable to the current work?Whether it can be reused?Whether it help to develop more similar patterns?15Separation of ConcernsDivide and conquer policySubdivision of the problemConcern is a feature / behaviorLess effort and time to solveExample: two problems with different perceived complexityIt involves other design concepts too16Modularity“Modularity is the single attribute of software that allows a program to be intellectually manageable.”Helps in separation of concernsComponents are called modulesMonolithic software has great complexityBalanced approach required17Modularity and Software Cost18Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 226Information HidingInformation contained by a module should not be accessible to other modulesIndependent modules lead to effective modularityAbstraction VS hidingHelps in software modification19Functional IndependenceAbstraction, separation of concerns, modularity, and information hiding lead to functional independence“single-minded” function and limited interaction with other modulesHelps in maintainabilityCohesionAn indication of the relative functional strengthCouplingAn indication of the relative interdependence 20Refinement and AspectsRefinementTop-down design strategyA process of elaborationAbstraction and refinement are complementary conceptsAspectsDifferent requirements / concernsCrosscutting concerns / aspectsAspect is implemented as a separate module21RefactoringReorganization technique to simplify component design without changing its function or behaviorImproved internal structure without altering external behaviorUn-used design elements, inefficient or unnecessary algorithms, poor/inappropriate data structures, or any other design failureEasier integration, testing, and maintenance22Design ClassesUser interface classVisual representationBusiness domain classBusiness logicProcess classLower level business abstractionPersistent classData storageSystem classSoftware management23Characteristics of Well-formed ClassComplete and sufficientThe complete encapsulation of all attributes and methodsPrimitivenessFocused on one service for the classHigh cohesionSingle mindedness, small set of responsibilitiesLow couplingAcceptable minimum level of collaboration24SummaryDesign, goal of design, design process in SE context, Process of designQuality guidelines and attributes Evolution of software design processProcedural, object-oriented, aspect-orientedDesign conceptsAbstraction, architecture, pattern, information hiding, separation of concerns, refactoring, design classes25