Presentation on theme: "Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz"— Presentation transcript:
1 Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz University of PalestineFaculty of Engineering and Urban planningSoftware Engineering DepartmentSoftware Modeling SWE5441Lecture 3Eng. Mohammed TimrazElectronics & Communication Engineer
2 Two Types of Design Models Static model:Represents the parts, relationships, and attributes that do not change (during execution of the software )Dynamic model:Represents what happens during the execution of the software.
3 Software Product Designer & Engineering Designer A software product designer is concerned with:Product features and capabilities.Visually appealing and easy to use user interfaces.Fitting into users’ business processes and operability.Product packaging.** ( a closer tie to what is specified in the product requirements )A software engineering designer is concerned with:Individual functionalities and performance.Internal structure of the software system.Individual programs and their interfaces & interactions.The data flow through the software system (including inputs and outputs).System maintenance and evolution.** (a closer tie to the internal technical design )(similarities and differences?)
4 Software Design Team We Need both: Software Product Designer. Software Engineering Designer.Different sets of skills needed:Product Designer: knowledge of:User interface, communicating the requirements/product design, marketing, business processes, applications domain knowledgeEngineering Designer: knowledge of:Architecture, programming, database and data structures, development platforms, networking, operating systems.
6 Software Product Design .vs. Software Engineering Design Product Design Activity:output is a software requirements specification document.Answers mostly “what” the user and customer needs and wants.formulates the problem in an organized way :Functionalities & featuresLooks and interfacesConstraintsEngineering Design Activity:output is a design specification documentAnswers mostly “how” the software will be put together to respond to the users’ needs and wants.formulates the solution in an organized way.High level software:Components and How they interact.Rationale behind your design decisions ( * my addition )Low level specifications of programs and data and their behaviororganize: relating these
7 Is There a Design Method? There is no ONE design method in the form of a “recipe” for design.There are several methods that all speak to:Design process: a set of steps that starts with “some inputs” and transform that input to some output and eventually results in a design specification (e.g. structured method, OO-method, etc.).Design notation: a set of symbolic representations and how the symbols are to be used (e.g. UML, etc.).Design “heuristics”: a set of guiding rules (e.g. low coupling and high cohesion)
8 The Software Lifecycle Systems EngineeringRequirements AnalysisSoftware DesignImplementationTestingDeploymentEvolutionThe process/activities of developing and evolving software
9 The Software Lifecycle Software DesignRequirements AnalysisImplementationSystems EngineeringTestingSystems EngineeringIdentify needs/problemsAllocation of rolesHardwareProceduresSoftwareFeasibility studiesDeploymentEvolution
10 The Software Lifecycle Software DesignRequirements AnalysisImplementationSystems EngineeringIdentify needs, problems and allocate rolesTestingDeploymentEvolutionRequirements AnalysisDefine goals, objectives, features of target software
11 The Software Lifecycle “Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design. Detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more.”The Software LifecycleSoftware DesignRequirements AnalysisImplementationSystems EngineeringDefine software featuresIdentify needs, problems and allocate rolesTestingDeploymentSoftware designCreating a blueprint for building the softwareArchitectural designSubsystem designDetailed designProcedural DesignUser Interface DesignDatabase DesignData Structures DesignTest case designEvolution
12 The Software Lifecycle Software DesignRequirements AnalysisImplementationCreate blueprintSystems EngineeringDefine software featuresIdentify needs, problems and allocate rolesTestingDeploymentEvolutionImplementationCreating the finished product – the programCodingWriting code for the classes and operationsGenerate object codeCreate Test casesCreate user manuals
13 The Software Lifecycle Software DesignCreate codeRequirements AnalysisImplementationCreate blueprintSystems EngineeringDefine software featuresIdentify needs, problems and allocate rolesTestingDeploymentEvolutionTestingDetermining if the software has errors/fulfils its requirementsTest planningUnit testingSubsystem testingIntegration testingRegression testingTest case design
14 The Software Lifecycle Software DesignCreate codeRequirements AnalysisImplementationCreate blueprintSystems EngineeringDefine software featuresIdentify needs, problems and allocate rolesTestingDeploymentUncovering errorsDeploymentMaking the software available for useDeployment/installation planningDevelop documentationHardware configurationInstallationSoftware distributionTrainingEvolution
15 The Software Lifecycle Software DesignCreate codeRequirements AnalysisImplementationCreate blueprintSystems EngineeringDefine software featuresIdentify needs, problems and allocate rolesTestingDeploymentUncover errorsEvolutionManaging the softwareConfiguration managementControlling change as software evolvesTechnical supportSoftware lifecycle activitiesEvolutionMake software available for use
16 Inputs To Software Design Software requirements specificationDescribes WHAT system shall do not HOW.External view of system to be developed.Environmental constraintsHardware, language, system usage.Design constraintsDesign method.Design notation.
17 Outputs From Software Design Architectural DesignOverall description of software structure, Textual and Graphical.Specification of software components and their interfaces.Data Design.Detailed Design of each componentInternal logic.Internal data structures.Design decisions madeDesign rationale.Traces to requirements.
18 Software Design Process Software life cycle models:Waterfall: limitations of Waterfall ModelIncremental: evolutionary prototypingExploratory: throwaway prototypingSpiral model: risk driven process model
20 Software Life Cycle Model (Definition) Requirements Analysis and SpecificationAnalysis of user's problem.Specification of "what" system shall provide user.Architectural DesignSpecification of "how" system shall be structured into components.Specification of interfaces between components.Data Design.
21 Software Life Cycle Model (Construction) Detailed DesignInternal design of individual components.Design of logic and data structures.CodingMap component design to code.Unit TestingTest individual components.
22 Software Life Cycle Model (Integration and Test) Integration TestingGradually combine components and test combinations.System TestingTest of entire system against software requirements.Acceptance TestTest of entire system by user prior to acceptance.
23 Software Life Cycle Model (Maintenance) Modification of software system after installation and acceptanceFix software errors.Improve performance.Address changes in user requirements.Often implies significant software redesign
24 Limitations of Waterfall Model Does not show iteration in software life cycle.Does not show overlap between phases.Software requirements are tested late in life cycle.Operational system available late in life cycle.
25 Prototyping During Requirements Phase ProblemSoftware requirements are tested late in life cycle.SolutionUse throw-away prototyping.Help ensure requirements are understoodAlso first attempt at designing systemDesign of key file and data structuresDesign of user interfaceEarly design tradeoffs
32 Spiral Process Model (SPM) SPM consists of four main activities that are repeated for each cycle:Defining objectives, alternatives and constraintsAnalyzing risksDeveloping and verifying productSpiral planningNumber of cycles is project specificRisk driven processAnalyze risks in second quadrant
Your consent to our cookies if you continue to use this website.