CSE 5324: Software Engineering I. (Analysis, Design, Creation)
|
|
- Hester Shepherd
- 5 years ago
- Views:
Transcription
1 CSE 5324: Software Engineering I (Analysis, Design, Creation)
2 Process and process improvement
3 The way you get better is practice, practice, practice. (And learn from your mistakes) Defining your process: what steps are done when? what is the result? Learn from (your) history What can you measure? Transactions/sec. Average module (or method) size (or complexity) Time/module (or method) Reuse rate Time per phase Fault density Requirements "creep" (changes in new/changed function points) Schedule slips and much more Quantitative measurements What can change? What could be improved? Variability, quality, etc. Predictive: what can one predict and plan knowing history
4 Many tools are statistical: based on broad sample of industry, many types of projects, many types of programming languages, styles, methods, etc. COCOMO FP counting... Your history is much more accurate Set targets Set baselines Goals
5 CSE 5324: Software Engineering I (Analysis, Design, Creation)
6 Review: SQA and Testing Cleanroom Formal Methods Real Time Maintenance Process and process improvement Exam 3: November 18 Primarily Text: Chap 8, 9.2, 10, , 4.5 (Z) Real Time, Z, Test, Maintenance, Process measurement and improvement Review
7 Why Grades are not important (But what is...)
8 Real-Time Systems: What are they? When (where) are they used? How are they different? (From non-rt)
9 Many (most) real-time systems are embedded Where are they seen: where real-world events are time critical: navigation (air, space) medical telecomm, network games Often classified into: Soft (RT) Hard (RT) Usually both (and non-rt requirements also) Degraded operation versus Incorrect results
10 Often viewed as stimulus - response system Stimuli: Periodic (predictable time intervals) Aperiodic (irregular) Response: Actuator Classification: Monitoring systems Data Acquisition Command and Control etc.
11 Usually hardware and software done in parallel (and tradeoffs are made) Establish system requirements Partition Requirements Software Reqs Hardware Reqs Software Design Hardware Design Steps: Identify Stimuli (to process) and associated response For each stimuli and response identify timing constraints Group stimuli and response into concurrent processes For each, design algorithms (usually early in design process, may make tradeoffs) Design scheduling system to ensure processes started on time Integrate with a real-time executive (OS)
12 Implementation overhead is critical: Design tools and methodolgies Programming language: Is C appropriate? (NO) C++? (Even worse) Ada Ada 83 was not (design errors) but Ada 95 is What is needed: HLL synchronization OS interface constructs: mutual exclusion, IPC, start process by time, scheduler changes, etc. Interrupt handling
13 OS: (Not Unix!) Real time clock Interrupt handler Scheduler Resource manager Dispatcher May include: Configuration manger Static or dynamic Fault manager Hardware and software
14 Some Issues: Is OO a good idea for RT? Timing: how to make estimates: Counting instructions (pipelines, etc.) Compiler helping Analysis Simulate Use good tools:
15 CSE 5324: Software Engineering I (Analysis, Design, Creation)
16 News (you can use) "Last week NASA announced that the "human" error stemming from space engineers using two sets of measurements -- one utilizing miles and the other kilometers -- caused the loss of the Mars Climate Orbiter spacecraft last week, NASA said Thursday." The teams, located at the National Aeronautics and Space Administration's Jet Propulsion Laboratory in Pasadena and at Lockheed Martin Astronautics in Colorado, complicated matters further by failing to realize the error, the agency said in a statement. The $125 million orbiter, intended to serve as the first interplanetary weather satellite, is believed to have broken up when it hit the Martian atmosphere last week after an approach that was too near the surface.
17 Today's question is: What kind of error was this? How could/(should) it have been prevented?
18 Object Oriented Methodolgy: Terms, ideas, techniques OO Concepts, OO Analysis, OO Design Design Concepts, Design Methods (Structured) Real Time Analysis and Design
19 What is designed: Data Architecture Interface Procedural
20 Object Oriented Design: Find objects, factor into good classes, define class hierarchies and interfaces, make it reusable, modifiable. OO Design architecture stresses object relations rather than flow of control What is different: (Fichman, Kemerer) (From SA) Module Hierarchy representation Data Definition Spec Procedural Spec End-to-end processing sequences Class and Hierarchy definition Operations assigned to classes
21 Bertrand Meyer suggests: Decomposable design method makes easier subproblems Composable reusable Understandable by module Continuity coupling (local) Protection coupling (isolation) To achieve: Few, small, explicit interfaces. Information hiding. OOD: Booch Coad Yourdon Rumbaugh Jackson design a part of analysis! Coad suggest (for any method): Define: Problem Domain User I/F Task Management Data Management
22 Design Patterns: (This is another of the SE Buzz words!) Recurring and reusing of classes and objects (Gamma) Name of pattern Problem to which applied Characteristics Consequences of applying Should one use inheritance or composition? (When both possible) Use what is general, or make it specific?
23 Compare SA, SD versus OO: Hospital system: Patient record system. Spreadsheet
24 Is OO Important? OO Prog languages: JAVA, et al OO Interfaces: Windowing systems CORBA Distributed objects
25 Cleanroom: (Formal Methods) Requirements: Remember: What to do. (what, NOT how.) What is wrong with what is done now? Vague Ambiguity Incomplete Contradictions Mixed Abstraction and methods Clients must agree to requirements, Developers must be able to design from them. Word descriptions (suffer from above) Structured Analysis O-O Analysis
26 Cleanroom Software Engineering Build correct software as it is developed. Use Mathematical Notation Verify Correctness (Statistical Quality Certification) Formal Design and verification Code Generation, Inspection, Verification Statistical Test Planning, Usage Testing Certification, Integration
27 Techniques used in Cleanroom: Incremental life-cycle Formal Techniques for Specification and Design Non-Execution Based Module-Testing (Code reading, walkthroughs, inspections, proofs) Module not compiled until AFTER passed inspection
28 Does Cleanroom work? US Naval Underwater systems Center: 18 Faults detected when design functionally verified (Informal proofs used mostly, only when participants unsure of correctness were full mathematical proofs used) 19 more faults during walkthrough (about 2KLOC) NO compilation errors NO Failures during execution Does it scale? Testing Fault Rate (Faults detected per KLOC) This is different between Cleanroom and other Development techniques. Ericsson Telecom OS32 350,000 Lines of code 18 months, team of 70 people Testing Fault Rate 1.0 Faults per KLOC (Navy was 0.0) Linger reports average Testing Fault Rate 2.3 Faults per KLOC based on 17 products of 1 million LOC. (This is very high quality)
29 What s not so good about Cleanroom: Problems?: Henderson: Too theoretical, mathematical, radical for real-world No Unit testing for developers Maturity of software developers, industry
30 Strategy: Increment Planning example Requirements Gathering Box structure Specification Formal Design Correctness Verification Code Generation, Inspect, Verify Statistical Test Planning Statistical Usage Testing Certification, Integration
31 Strategy: Increment Planning example Requirements Gathering Box structure Specification Formal Design Correctness Verification Code Generation, Inspect, Verify Statistical Test Planning Statistical Usage Testing Certification, Integration
32 How CoffeePot is this different (from other methods)? Statistical Q. C. Design Specs mathematically proved correct Statistical Usage Testing
33 Functional Specification: Box Structure: Referential transparency (information content stands alone) Black Box State Box Clear Box
34 Design Refinement: Structured Programming Stepwise expansion Verify at each level of refinement (Linger) Verification is a finite process Every line of design and code verified Very low defect levels It scales up Better code than unit testing Statistical Use Testing Probability Distribution Certification
35 Requirements: What to do. (what, NOT how.) Formal Methods: What is wrong with what is done now? Vague Ambiguity Incomplete Contradictions Mixed Abstraction and methods Clients must agree to requirements, Developers must be able to design from them. Word descriptions (suffer from above) Structured Analysis O-O Analysis
36 Use Mathematical Notation (Must extend some) Many choices available: CSP, VDM, Z, etc. Z ( Zed )
37 Should I Use Formal Methods? (Bowen and Hinchley) Use Appropriate Notation Formalize, not overformalize Costs? Have a FM guru available Don t abandon what you have Document Still need SQA No dogma Test, test, Reuse
38 What s good about Formal Methods: It is Real Engineering Precise Validation, Verification Testable Automated tools Good SE s can do it Don t need to spel gud or English Grammar Reusable (Many more)
39 What s not so good about Formal Methods: Problems?: Hard to learn I can t read this I can t write this Client can t either Is this the future? Lack of scoping and structuring
40 example Schema signature Schema predicate
41 CoffeePot Coffee: N PotCapacity: N Coffee PotCapacity
42 CoffeeLight Light: { off, on } CoffeeLevel: N PotCapacity: N Light = on Coffee > PotCapacity
43 CoffeeMaker CoffeePot FreshCoffee?: N FreshCoffee? + CoffeeLevel < PotCapacity CoffeeLevel = CoffeeLevel + FreshCoffee?
44 CoffeeSystem CoffeeMade CoffeeBrewing CoffeeOverflow
45 Some more notation: Domain to range: Coins = { cent 1, nickel 5 } I, j: dom s (I < j ) => s(i) < T s(j) ΞName means that state variables are unchanged
46 MakeChange CostOfItem: N ChangeFrom: N ChangeFrom = 1.00
47 Software Testing Object Oriented Testing
48 REMEMBER: What is the goal of testing? (Finding errors.) Assess quality Uncover errors Ensure standards are met
49 Is OO Test different? (From other methods) OO models are different Unit testing is based on classes Integration is different OO assumes re-use The basic goals of testing remain the same We want to find errors as early as possible (in process steps: requirements, design, code) to avoid propagation
50 Errors made in analysis may: Lead to errors in classes in design Make more work in procedures for a bad attribute (update, inherit, etc.) Cause extra (or incorrect) subclasses or system behavior How are analysis and design "models" tested Different methodologies (UML, Rumbaugh, Booch, etc) use different notation We still want to check that "some" correct syntax was used "Experts" in the problem domain can review class definitions and hierarchy for missing or ambiguous Do class relationships reflect "the real world"?
51 Class - Responsibility - Collaboration (CRC) model classes and relationships may be inconsistent CRC lists class name responsibilities (operations, what it does) collaborators (other classes needed, sent messages) and optionally: class type (like: transaction) class characteristics (systems related: atomic, secure)
52 CRC Steps: Cross check CRC and O-R model Ensure that a delegated responsibility is actually done by each (that) collaborator Ensure each collaborator receives requests from correct (reasonable) source Are other classes needed, is work grouped correctly? Can (should) widely requested services be grouped (combine responsibilities that always go together) NOTE: this may be a bad idea - reuse, etc.
53 OO Unit testing With encapsulation, smallest testable unit is a class (or object) How can we isolate and test? Class testing - unlike unit test based on algorithms and data flow - state behavior of class and encapsulated operations Integration testing What is top-down or bottom-up (with classes)? Integration often described as: Thread-based - based on response to an input or event. Use-based - test independent classes that use fewest server classes, then move on to dependant classes
54 Cluster testing collaborating classes are clustered (by O-R and CRC models) and exercised Validation testing At system level, class connections not visible Black Box works here Test cases may be done from OOA: Object Behavior, event flow
55 Test Case Design Berard Test case explicitly connected to class State test purpose Testing: Object states operations, messages exceptions tested May be difficult to know the internal state of an object It might be necessary to build in operations to report the state Inheritance requires retesting
56 Conventional testing (and differences): Fault based test - high probability of finding an error where are most likely errors (to be found)? Derived and Inherited classes - redefined class tests Scenario-based testing What does the user do? (Fault based - what does software do) Use Case Surface structure test - structure visible to user (commands, etc.) Deep Structure - examine design and code
57 Class Testing Random tests Partition test - similar to equivalence partition based on: Interclass test attribute class states category - functions of operations Multiple class testing random testing, partition testing Behavior model test based on state transition diagram (dynamic behavior) breadth first usually
58 Reasons not to test: You didn't know it was policy Blame someone else's code (design, etc.) Good choices: dead co-workers children that can't talk Bad choices: bosses children boss Not on the schedule We keep finding problems Too complex The risks (product liability) not great Waste of (my) time
59 REMEMBER: What is the goal of testing? (Finding errors.) Assess quality Uncover errors Ensure standards are met
60 Is OO Test different? (From other methods) OO models are different Unit testing is based on classes Integration is different OO assumes re-use The basic goals of testing remain the same We want to find errors as early as possible (in process steps: requirements, design, code) to avoid propagation
61 Errors made in analysis may: Lead to errors in classes in design Make more work in procedures for a bad attribute (update, inherit, etc.) Cause extra (or incorrect) subclasses or system behavior How are analysis and design "models" tested Different methodologies (UML, Rumbaugh, Booch, etc) use different notation We still want to check that "some" correct syntax was used "Experts" in the problem domain can review class definitions and hierarchy for missing or ambiguous Do class relationships reflect "the real world"?
62 Class - Responsibility - Collaboration (CRC) model classes and relationships may be inconsistent CRC lists class name responsibilities (operations, what it does) collaborators (other classes needed, sent messages) and optionally: class type (like: transaction) class characteristics (systems related: atomic, secure)
63 CRC Steps: Cross check CRC and O-R model Ensure that a delegated responsibility is actually done by each (that) collaborator Ensure each collaborator receives requests from correct (reasonable) source Are other classes needed, is work grouped correctly? Can (should) widely requested services be grouped (combine responsibilities that always go together) NOTE: this may be a bad idea - reuse, etc.
64 OO Unit testing With encapsulation, smallest testable unit is a class (or object) How can we isolate and test? Class testing - unlike unit test based on algorithms and data flow - state behavior of class and encapsulated operations Integration testing What is top-down or bottom-up (with classes)? Integration often described as: Thread-based - based on response to an input or event. Use-based - test independent classes that use fewest server classes, then move on to dependant classes
65 Cluster testing collaborating classes are clustered (by O-R and CRC models) and exercised Validation testing At system level, class connections not visible Black Box works here Test cases may be done from OOA: Object Behavior, event flow
66 Test Case Design Berard Test case explicitly connected to class State test purpose Testing: Object states operations, messages exceptions tested May be difficult to know the internal state of an object It might be necessary to build in operations to report the state Inheritance requires retesting
67 Conventional testing (and differences): Fault based test - high probability of finding an error where are most likely errors (to be found)? Derived and Inherited classes - redefined class tests Scenario-based testing What does the user do? (Fault based - what does software do) Use Case Surface structure test - structure visible to user (commands, etc.) Deep Structure - examine design and code
68 Class Testing Random tests Partition test - similar to equivalence partition based on: Interclass test attribute class states category - functions of operations Multiple class testing random testing, partition testing Behavior model test based on state transition diagram (dynamic behavior) breadth first usually
69 Reasons not to test: You didn't know it was policy Blame someone else's code (design, etc.) Good choices: dead co-workers children that can't talk Bad choices: bosses children boss Not on the schedule We keep finding problems Too complex The risks (product liability) not great Waste of (my) time
70
71 Re-engineering (This is a good "YAB" - Yet Another Buzzword) As the rules of business change the software supporting those rules must change. A Business Process ("BP") - like other processes is a set of related tasks to achieve a defined outcome BPR (Reengineering) is implementing change for "breakthroughs" BP has a "customer" - who receives the outcome (product)
72 Hammer suggests: Organize around outcomes (not tasks) (easier to "track" work status) The process customer performs (controls) the process. Put information processing into place where work is done. Get the data once, where it is produced. View distributed (geographically) resources as if they were centralized. Make decisions where work is done (not higher up).
73 BPR is a cycle, including: Define Business Goals Identify process, prioritize Evaluate processes, measure Specify and design process Prototype (try it out) Refine and use
74 Software Re-engineering: Maintenance is: Corrective Adaptive Perfective (enhance) Preventive (re-engineer) Process Model: Inventory Analysis - details of applications Document restructuring Reverse Engineer - create an abstract representation Restructure Code - most common Restructure Data - may actually be more valuable Forward Engineering - apply SE principles to recreate existing application (with new features)
75 Some details: Reverse Engineer to understand: Data Structures Database Model User IF Restructure to: Improve quality (how to measure?) Improve programmer productivity Maintainable, testable Forward Engineer to: Use new technology: Distributed, new GUI, OO methods, CASE Tools Is it worth it? Cost benefit is Maintenance costs - Re-engineering costs
76
Gradational conception in Cleanroom Software Development
Gradational conception in Cleanroom Software Development Anshu Sharma 1 and Shilpa Sharma 2 1 DAV Institute of Engineering and Technology, Kabir Nagar, Jalandhar, India 2 Lovely Professional University,
More informationFeasibility of Testing to Code. Feasibility of Testing to Code. Feasibility of Testing to Code. Feasibility of Testing to Code (contd)
Feasibility of Testing to Code (contd) Feasibility of Testing to Code (contd) An incorrect code fragment for determining if three integers are equal, together with two test cases Flowchart has over 10
More informationKey Features. Defect Rates. Traditional Unit testing: 25 faults / KLOC System testing: 25 / KLOC Inspections: / KLOC
Cleanroom attempt to mathematically-based, scientific engineering process of software development Cleanroom software engineering yields software that is correct by mathematically sound design, and software
More informationTesting Object-Oriented Applications. Slide Set to accompany. Software Engineering: A Practitioner s Approach, 7/e by Roger S.
Chapter 19 Testing Object-Oriented Applications Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman
More informationTesting. Unit, integration, regression, validation, system. OO Testing techniques Application of traditional techniques to OO software
Testing Basic ideas and principles Traditional testing strategies Unit, integration, regression, validation, system OO Testing techniques Application of traditional techniques to OO software Testing-11,
More informationCleanroom Software Engineering
Cleanroom Software Engineering Abstract There are circumstances where quality is paramount, and any kind of error cannot be tolerated. When these circumstances arise, special measures need to be taken
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationIntroduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p.
Preface p. xv Introduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p. 8 Specification and Design Aspects p.
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationFramework for Improvement in Cleanroom Software Engineering Thesis Submitted in the partial fulfillment of requirements for the award of the degree
Framework for Improvement in Cleanroom Software Engineering Thesis Submitted in the partial fulfillment of requirements for the award of the degree of Master of Engineering in Software Engineering By:
More informationOO Requirements to OO design. Csaba Veres Alan M. Davis (1995), Colorado
OO Requirements to OO design Csaba Veres Alan M. Davis (1995), Colorado Alan Davis? Guru? Academic and professional www.omni-vista.com? Controversial article on research into requirements engineering Requirements
More informationTesting Object-Oriented Applications. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only
Chapter 19 Testing Object-Oriented Applications Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman
More informationIntroduction to Formal Methods
2008 Spring Software Special Development 1 Introduction to Formal Methods Part I : Formal Specification i JUNBEOM YOO jbyoo@knokuk.ac.kr Reference AS Specifier s Introduction to Formal lmethods Jeannette
More informationDesign and Information Hiding
Design and Information Hiding 15-214: Foundations of Software Engineering Jonathan Aldrich Related Reading: D. L. Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. CACM 15(12):1053-1058,
More informationVerification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should
More informationThe Cleanroom Method
Course "Softwareprozesse" The Cleanroom Method Lutz Prechelt Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ Principles Empirical results Typical practices Stepwise
More informationObjectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture
Objectives Architectural Design To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More informationCS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS 1. Explain iterative waterfall and spiral model for software life cycle and various activities
More informationChapter 4 Objectives
Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams 4.1 The
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationIdioms and Design Patterns. Martin Skogevall IDE, Mälardalen University
Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University 2005-04-07 Acronyms Object Oriented Analysis and Design (OOAD) Object Oriented Programming (OOD Software Design Patterns (SDP) Gang
More informationPart I: Preliminaries 24
Contents Preface......................................... 15 Acknowledgements................................... 22 Part I: Preliminaries 24 1. Basics of Software Testing 25 1.1. Humans, errors, and testing.............................
More informationMetrics and OO. SE 3S03 - Tutorial 12. Alicia Marinache. Week of Apr 04, Department of Computer Science McMaster University
and OO OO and OO SE 3S03 - Tutorial 12 Department of Computer Science McMaster University Complexity Lorenz CK Week of Apr 04, 2016 Acknowledgments: The material of these slides is based on [1] (chapter
More informationAdministrative Stuff. We are now in week 11 No class on Thursday About one month to go. Spend your time wisely Make any major decisions w/ Client
Administrative Stuff We are now in week 11 No class on Thursday About one month to go Spend your time wisely Make any major decisions w/ Client Real-Time and On-Line ON-Line Real-Time Flight avionics NOT
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationTopics in Software Testing
Dependable Software Systems Topics in Software Testing Material drawn from [Beizer, Sommerville] Software Testing Software testing is a critical element of software quality assurance and represents the
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationArchitectural Design
Architectural Design Objectives To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More information09. Component-Level Design
09. Component-Level Design Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 What is Component OMG UML Specification defines a component as OO view a
More informationQUIZ #5 - Solutions (5pts each)
CS 435 Spring 2014 SOFTWARE ENGINEERING Department of Computer Science Name QUIZ #5 - Solutions (5pts each) 1. The best reason for using Independent software test teams is that a. software developers do
More informationMethods for requirements engineering
Methods for requirements engineering Objectives To explain the role of methods and techniques in requirements engineering To introduce data-flow modelling To introduce semantic data modelling To introduce
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationObject Oriented Programming
Binnur Kurt kurt@ce.itu.edu.tr Istanbul Technical University Computer Engineering Department 1 Version 0.1.2 About the Lecturer BSc İTÜ, Computer Engineering Department, 1995 MSc İTÜ, Computer Engineering
More informationSample Exam Syllabus
ISTQB Foundation Level 2011 Syllabus Version 2.9 Release Date: December 16th, 2017. Version.2.9 Page 1 of 46 Dec 16th, 2017 Copyright 2017 (hereinafter called ISTQB ). All rights reserved. The authors
More informationCHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview
CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1:
More informationIndex. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107
A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures PART 1 ARCHITECTURAL DESIGN DECISIONS Recap on SDLC Phases
More informationSetting the stage... Key Design Issues. Main purpose - Manage software system complexity by improving software quality factors
Setting the stage... Dr. Radu Marinescu 1 1946 Key Design Issues Main purpose - Manage software system complexity by...... improving software quality factors... facilitating systematic reuse Dr. Radu Marinescu
More informationQuality Assurance = Testing? SOFTWARE QUALITY ASSURANCE. Meaning of Quality. How would you define software quality? Common Measures.
Quality Assurance = Testing? SOFTWARE QUALITY ASSURANCE William W. McMillan Meaning of Quality Error-free How define an error? Client is happy (we get paid!). User is happy (we are loved!). Stable (we
More informationDesign Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1
What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review (Part 1) 1 Coad-Yourdon Two-phase introduction: Object-Oriented Analysis
More information5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered
Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process
More informationSystems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, Fourth Edition Systems Analysis and Design in a Changing World, 4th Edition Learning Objectives Explain the purpose and various phases of the systems development
More informationDesign Patterns. Gunnar Gotshalks A4-1
Design Patterns A4-1 On Design Patterns A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution Good designers know not to solve every problem
More informationSession 8: UML The Unified Modeling (or the Unstructured Muddling) language?
Session 8: UML The Unified Modeling (or the Unstructured Muddling) language? A few observations, opinions, pros & cons COMP 320 / 420 Spring, 2018 Mr. Weisert Where did the UML come from? Object-oriented
More informationQ Body of techniques supported by. R precise mathematics. R powerful analysis tools. Q Rigorous, effective mechanisms for system.
Introduction to Formal Methods 1 Introduction to Formal Methods 2 Formal Specification Requirements specification R notational statement of system services Software specification R formal abstract depiction
More informationSoftware Service Engineering
Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language
More informationManaging Change and Complexity
Managing Change and Complexity The reality of software development Overview Some more Philosophy Reality, representations and descriptions Some more history Managing complexity Managing change Some more
More informationCASE TOOLS LAB VIVA QUESTION
1. Define Object Oriented Analysis? VIVA QUESTION Object Oriented Analysis (OOA) is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationObject-oriented development. Object-oriented Design. Objectives. Characteristics of OOD. Interacting objects. Topics covered
Object-oriented development Object-oriented Design Object-oriented analysis, design and programming are related but distinct. OOA is concerned with developing an object model of the application domain.
More informationSoftware Engineering 2 A practical course in software engineering. Ekkart Kindler
Software Engineering 2 A practical course in software engineering Quality Management Main Message Planning phase Definition phase Design phase Implem. phase Acceptance phase Mainten. phase 3 1. Overview
More informationCleanroom Software Engineering
Course "Softwareprozesse" Cleanroom Software Engineering Lutz Prechelt Freie Universität Berlin, Institut für Informatik Principles Empirical results Typical practices Stepwise refinement box structures,
More informationREVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION
c08classandmethoddesign.indd Page 282 13/12/14 2:57 PM user 282 Chapter 8 Class and Method Design acceptance of UML as a standard object notation, standardized approaches based on work of many object methodologists
More informationTopic 01. Software Engineering, Web Engineering, agile methodologies.
Topic 01 Software Engineering, Web Engineering, agile methodologies. 1 What is Software Engineering? 2 1 Classic Software Engineering The IEEE definition: Software Engineering is the application of a disciplined,
More informationA Mini Challenge: Build a Verifiable Filesystem
A Mini Challenge: Build a Verifiable Filesystem Rajeev Joshi and Gerard J. Holzmann Laboratory for Reliable Software, Jet Propulsion Laboratory, California Institute of Technology, Pasadena, CA 91109,
More informationCleanroom Software Engineering
Cleanroom Software Engineering Software Testing and Verification Lecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Required Reading and Additional Reference Required Reading: Linger,
More informationSample Question Paper. Software Testing (ETIT 414)
Sample Question Paper Software Testing (ETIT 414) Q 1 i) What is functional testing? This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type
More informationSoftware Design And Modeling BE 2015 (w. e. f Academic Year )
Software Design And Modeling BE 2015 (w. e. f Academic Year 2018-2019) 1 The Team Prof. Ravi Patki, I 2 IT Hinjawadi Pune Prof. Sangita Jaibhaiye SCOE Prof. D.D.Londhe PICT Prof. P. A. Joshi, ZCOER 2 The
More informationRecalling the definition of design as set of models let's consider the modeling of some real software.
Software Design and Architectures SE-2 / SE426 / CS446 / ECE426 Lecture 3 : Modeling Software Software uniquely combines abstract, purely mathematical stuff with physical representation. There are numerous
More informationChapter 9. Software Testing
Chapter 9. Software Testing Table of Contents Objectives... 1 Introduction to software testing... 1 The testers... 2 The developers... 2 An independent testing team... 2 The customer... 2 Principles of
More informationIntroduction To Systems Engineering CSC 595_495 Spring 2018 Professor Rosenthal Midterm Exam Answer Key
Part 1. Each question is worth 4 points. 1. Define what a system is. Introduction To Systems Engineering CSC 595_495 Spring 2018 Professor Rosenthal Midterm Exam Answer Key A system is a construct or collection
More informationSoftware Design Fundamentals. CSCE Lecture 11-09/27/2016
Software Design Fundamentals CSCE 740 - Lecture 11-09/27/2016 Today s Goals Define design Introduce the design process Overview of design criteria What results in a good design? Gregory Gay CSCE 740 -
More informationCHAPTER 9 DESIGN ENGINEERING. Overview
CHAPTER 9 DESIGN ENGINEERING Overview A software design is a meaningful engineering representation of some software product that is to be built. Designers must strive to acquire a repertoire of alternative
More informationADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE
ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE Dave Clarke 1 THIS LECTURE At the end of this lecture you will know notations for expressing software architecture the design principles of cohesion
More informationadministrivia today UML start design patterns Tuesday, September 28, 2010
administrivia Assignment 2? promise to get past assignment 1 back soon exam on monday review slides are posted your responsibility to review covers through last week today UML start design patterns 1 Unified
More informationTechnical Metrics for OO Systems
Technical Metrics for OO Systems 1 Last time: Metrics Non-technical: about process Technical: about product Size, complexity (cyclomatic, function points) How to use metrics Prioritize work Measure programmer
More informationNOTES ON OBJECT-ORIENTED MODELING AND DESIGN
NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented
More informationVragen. Intra-modular complexity measures. The uses relation. System structure: inter-module complexity
Vragen Intra-modular complexity measures Wat wordt bedoeld met het ontwerpsprincipe: Anticipate obsolence? Wat is het voordeel van strong cohesion en weak coupling? Wat is het gevolg van hoge complexiteit
More informationPatterns and Testing
and Lecture # 7 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the lectures of Marc Conrad and Dayou Li and on the book Applying UML and (3
More informationWhat is Software Architecture
What is Software Architecture Is this diagram an architecture? (ATM Software) Control Card Interface Cash Dispenser Keyboard Interface What are ambiguities in the previous diagram? Nature of the elements
More informationTutorial 1 Answers. Question 1
Tutorial 1 Answers Question 1 Complexity Software in it what is has to do, is often essentially complex. We can think of software which is accidentally complex such as a large scale e-commerce system (simple
More informationDEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK TWO MARKS UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering
More informationSoftware Testing Strategies. Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only
Chapter 22 Software Testing Strategies Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright 1996, 2001, 2005, 2009, 2014
More informationSOFTWARE ENGINEERING SOFTWARE EVOLUTION. Saulius Ragaišis.
SOFTWARE ENGINEERING SOFTWARE EVOLUTION Saulius Ragaišis saulius.ragaisis@mif.vu.lt CSC2008 SE Software Evolution Learning Objectives: Identify the principal issues associated with software evolution and
More informationRequirements and Design Overview
Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions
More informationSE 2730 Final Review
SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more
More informationQuestion 1: What is a code walk-through, and how is it performed?
Question 1: What is a code walk-through, and how is it performed? Response: Code walk-throughs have traditionally been viewed as informal evaluations of code, but more attention is being given to this
More informationFormal Foundations of Software Engineering
Formal Foundations of Software Engineering http://d3s.mff.cuni.cz Martin Nečaský Pavel Parízek CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics Goals of the course Show methods and tools
More informationCSC Advanced Object Oriented Programming, Spring Overview
CSC 520 - Advanced Object Oriented Programming, Spring 2018 Overview Brief History 1960: Simula first object oriented language developed by researchers at the Norwegian Computing Center. 1970: Alan Kay
More informationSOFTWARE DESIGN COSC 4353 / Dr. Raj Singh
SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationVETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT
More informationUNIT II Requirements Analysis and Specification & Software Design
UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they
More informationCleanroom Software Engineering
Cleanroom Software Engineering Software Testing and Verification Lecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Required Reading and Additional Reference Required Reading: Linger,
More informationReview sheet for Final Exam (List of objectives for this course)
Review sheet for Final Exam (List of objectives for this course) Please be sure to see other review sheets for this semester Please be sure to review tests from this semester Week 1 Introduction Chapter
More informationMinsoo Ryu. College of Information and Communications Hanyang University.
Software Reuse and Component-Based Software Engineering Minsoo Ryu College of Information and Communications Hanyang University msryu@hanyang.ac.kr Software Reuse Contents Components CBSE (Component-Based
More informationMotivation State Machines
Motivation State Machines Generating test cases for complex behaviour Textbook Reading: Chapter 7 We are interested in testing the behaviour of object-oriented software systems Behaviour: Interactions
More informationSolved Question Paper June 2017
Solved Question Paper June 2017 1.a) What are the benefits of Object Oriented Methodology in real life applications? Briefly explain each element of the state diagram with respect to dynamic modeling.
More informationEngr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Software Design and Architecture Software Design Software design is a process of problem-solving
More informationTrusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout
1 Last update: 15 October 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout 2 Lecture 1: Issues of software quality Agenda for today 3 Introduction Some statistics
More informationSoftware Reuse and Component-Based Software Engineering
Software Reuse and Component-Based Software Engineering Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Contents Software Reuse Components CBSE (Component-Based Software Engineering) Domain Engineering
More informationThree General Principles of QA. COMP 4004 Fall Notes Adapted from Dr. A. Williams
Three General Principles of QA COMP 4004 Fall 2008 Notes Adapted from Dr. A. Williams Software Quality Assurance Lec2 1 Three General Principles of QA Know what you are doing. Know what you should be doing.
More informationObject Oriented System Development
Object Oriented System Development Ratna Wardani Semester Genap, 2012 2/26/2012 Ratna W/PSBO2012 1 About This Course It shows how to apply OOAD technique to analyze and develop systems.. It gives you an
More informationProgram Correctness and Efficiency. Chapter 2
Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you
More informationIntroduction to Object Oriented Analysis and Design
A class note on Introduction to Object Oriented Analysis and Design Definition In general, analysis emphasizes an investigation of the problem and requirements of the domain, rather than a solution. Whereas,
More informationREENGINEERING SYSTEM
GENERAL OBJECTIVES OF THE SUBJECT At the end of the course, Individuals will analyze the characteristics of the materials in the industries, taking into account its advantages and functionality, for their
More informationRAISE in Perspective
RAISE in Perspective Klaus Havelund NASA s Jet Propulsion Laboratory, Pasadena, USA Klaus.Havelund@jpl.nasa.gov 1 The Contribution of RAISE The RAISE [6] Specification Language, RSL, originated as a development
More informationEINDHOVEN UNIVERSITY OF TECHNOLOGY
EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics & Computer Science Exam Programming Methods, 2IP15, Wednesday 17 April 2013, 09:00 12:00 TU/e THIS IS THE EXAMINER S COPY WITH (POSSIBLY INCOMPLETE)
More information