Presentation on theme: "Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz"— Presentation transcript:
1Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz University of PalestineFaculty of Engineering and Urban planningSoftware Engineering DepartmentSoftware Modeling SWE5441Lecture 3Eng. Mohammed TimrazElectronics & Communication Engineer
2Two 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.
3Software 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?)
4Software 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.
6Software 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
7Is 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)
8The Software Lifecycle Systems EngineeringRequirements AnalysisSoftware DesignImplementationTestingDeploymentEvolutionThe process/activities of developing and evolving software
10The Software Lifecycle Software DesignRequirements AnalysisImplementationSystems EngineeringIdentify needs, problems and allocate rolesTestingDeploymentEvolutionRequirements AnalysisDefine goals, objectives, features of target software
11The 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
12The 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
13The 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
14The 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
15The 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
16Inputs 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.
17Outputs 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.
18Software Design Process Software life cycle models:Waterfall: limitations of Waterfall ModelIncremental: evolutionary prototypingExploratory: throwaway prototypingSpiral model: risk driven process model
20Software 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.
21Software 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.
22Software 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.
23Software 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
24Limitations 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.
25Prototyping 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
32Spiral 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