Executable Specifications

Slides:



Advertisements
Similar presentations
DETAILED DESIGN, IMPLEMENTATIONA AND TESTING Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advertisements

1 Software Testing and Quality Assurance Lecture 13 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
Object-Oriented Software Development CS 3331 Fall 2009.
PROC-1 3. Software Process. PROC-2 What’s a process? Set of activities in creating software It involves creativity –hard to automate –Requires human judgment.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Chapter 22 UML Tooks and UML as Blueprint Model-Driven Architecture (MDA) Object-Constraint Language (OCL)
Alternate Software Development Methodologies
CH02: Modeling the process and life cycle Process of developing software (organization and discipline in the activities) contribute to the quality of the.
4.1 Blended approaches: Information Engineering IMS Information Systems Development Practices.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Requirements Specification
Copyright © 2006 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
CSE 784 Software Studio Phil Pratt-Szeliga Fall 2010 Slides Derived From: Dr. Fawcett.
7M701 1 Software Engineering Software Requirements Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 5
Systems Analysis and Design in a Changing World, 6th Edition
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Chapter 6– Artifacts of the process
Objektorienteret netværkskommunikation Presentation: Architectures for Distributed Systems.
Lesson 7 Guide for Software Design Description (SDD)
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
RUP Implementation and Testing
An Introduction to Software Architecture
Putting together a complete system Chapter 10. Overview  Design a modest but complete system  A collection of objects work together to solve a problem.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Large Scale Software Systems Derived from Dr. Fawcett’s Notes Phil Pratt-Szeliga Fall 2010.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Design Process for Architecture. Architectural Lifecycle Not all lifecycle plans support Architecture! It is hard to achieve architecture based design.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Design and Planning Or: What’s the next thing we should do for our project?
February 8, 2006copyright Thomas Pole , all rights reserved 1 Lecture 3: Reusable Software Packaging: Source Code and Text Chapter 2: Dealing.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
From the customer’s perspective the SRS is: How smart people are going to solve the problem that was stated in the System Spec. A “contract”, more or less.
Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009.
CSE 2341 Object Oriented Programming with C++ Note Set #4
Chapter 7 Lecture 1 Design and Implementation. Design and implementation Software design and implementation is the stage in the software engineering process.
Requirement Classification Nisa’ul Hafidhoh Teknik Informatika
C_ITIP211 LECTURER: E.DONDO. Unit 1 : The Systems Development Environment.
Appendix 1 - Packages Jim Fawcett copyright (c)
Test-Driven Development
UNIT 1.
Project Center Use Cases
CSE687 – Object Oriented Design
Chapter ? Quality Assessment
Architecture Concept Documents
What is UML? What is UP? [Arlow and Neustadt, 2005] October 5, 2017
Configuration Management Why do we need it? What does it do?
Complexity Time: 2 Hours.
Enterprise Computing Collaboration System Example
CSE784 – Software Studio Jim Fawcett Fall 2006.
Component Based Software Engineering
Software Maintenance
The Process of Object Modeling
Software Prototyping Animating and demonstrating system requirements.
Applied Software Implementation & Testing
Design Process for Architecture
Use Case Realization Describes a collaboration among analysis classes that shows how a specific use case is realized Consists of flow-of-events analysis,
Chapter 12 Levels of Testing
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Software Architecture
Design Process for Architecture
Chapter 8, Design Patterns Introduction
Overview Activities from additional UP disciplines are needed to bring a system into being Implementation Testing Deployment Configuration and change management.
Design Process for Architecture
Chapter 3 Software Architecture and Specification
Software Architecture
Software Development Process Using UML Recap
Web Application Development Using PHP
Presentation transcript:

Executable Specifications Jim Fawcett CSE687 – Object Oriented Design Copyright © 2009

Software Development Process Decomposition in application space Understand customer requirements, needs Partition into application objects Develop user views Think about usability, esthetics, extensions, critical issues Recomposition in solution space Define and develop solution objects Aggregate and package Test behavior and packaging Think about simplicity, maintainability, performance

Architecture and Detailed Design System architecture can be loosely associated with the application space User interactions with the system Partitioning into subsystems and application objects Possible and planned extensions to delivered product Detailed design focuses on the solution space Building reusable objects Salvaging existing code Integration and testing

Specifications Specifications describe: Problem: What will be built How the system and built parts behave Not how it is designed and not how it is implemented Specifications are the only basis for testing Problem: We write specifications for the application space We don’t traditionally write specifications for the solution space So what is our basis for testing solutions?

Executable Specifications An executable specification is code for a test driver Prologue that describes, in comments: Designer, platform, and project Tested code, e.g., versioned file names Test description Name, build process Expected behavior, and performance Test procedure Steps the driver will execute and expected results – essentially pseudocode A main function and possibly other functions that implement the test procedure

Implementation Interface defines contracts for: Logging specification Test execution Executable Specification Implements interface Holds specification text as an embedded resource Uses logger and test vector generator to implement test Each test is packaged as a DLL for test execution

Incremental System Development Architecture Define application subsystems and objects Write executable test descriptions as a semi- formal specification (only spec we will use) Detailed Design Define solution side objects Write executable test descriptions, e.g., specification of solution Write solution-side production code and complete executable specifications concurrently Test solutions and iterate System Test Write application-side production code and complete executable specifications concurrently Test applications and iterate

Tools Test harness for running automated tests Test vector generator delivers inputs that drive tests Executor loads and executes test libraries (DLLs) Logger records results and supports queries Test specification parser Extracts readable test description for specification document Extracts names of classes (with help of static analyzer), objects, and descriptions of behavior for design document Extracts test description, procedure and logger results for test document

Conclusions Executable specifications Support specification-driven development Support for both application and solution domains Are compatible with Test-Driven development Are compatible with continuous integration automated daily tests longer cycle regression testing