American Journal of Computer Engineering (ISSN:2688-5360 ...
9/21/2015CPSC-4360-01, CPSC-5360-01, Lecture 11 Software Engineering, CPSC-4360-01, CPSC-5360-01,...
-
Upload
justin-baldric-parrish -
Category
Documents
-
view
227 -
download
4
Transcript of 9/21/2015CPSC-4360-01, CPSC-5360-01, Lecture 11 Software Engineering, CPSC-4360-01, CPSC-5360-01,...
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 1
Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 1
Stefan Andrei
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 2
Software Engineering CPSC-4360-01 and CPSC-5360-01 are 3 credits
points modules: Midterm exam (Monday, March 14, 10:00am): 20% CPSC-4360-01:
Project: 30% (10% - Analysis & Design – Report, 20% - Implementation & Test – Demonstration)
CPSC-5360-01: Project: 15% (5% - Analysis & Design – Report, 10% -
Implementation & Test – Demonstration) Paper Presentation: 15%
Written final exam (May 9, 11:00am-1:30pm): 50%
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 3
Software Engineering Module homepage
http://galaxy.lamar.edu/~sandrei/CPSC-4360-01/ Teaching
Lectures: Monday, Wednesday, Friday, 10:10-11:00, MA111
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 4
Course Etiquette Code of conduct
no copying for details, see webpage
You are encouraged to attend to all lectures, tutorials, and so on.
You are encouraged to ask questions. You are encouraged to offer answers.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 5
Consultation and Recommended Books Dr. Stefan Andrei, [email protected] (please send an email to make an appointment - MA2, #69)
Lectures based of the book (chapters available at the course website):
Bimlesh Wadhwa, Stefan Andrei, Soo Yuen Jien. Software Engineering: An object-oriented approach. McGraw Hill, 2007, ISBN: 978-007-126610-9
Recommended books: Mark Priestley: Practical Object-Oriented Design with UML, McGraw Hill, 2004 Ian Sommerville: Software Engineering, Pearson – Addison Wesley, 7th Edition,
2004 Craig Larman: Applying UML and Patterns, Pearson – Prentice Hall, 2005 Robert Binder: Testing Object-Oriented Systems, Addison Wesley, 2000
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 6
Overview of This Course Software Development Process Modelling with Objects
Analysis Model Use Case Modelling Analysis Class Modelling Object States
Design Model Design Class Modelling Object Interactions
Implementation Issues Testing and Integration Design Patterns Software Life Cycle Models / Methodologies
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 7
Tutorials Objectives Purposes
for self-assessment use material from lectures answer questions help deep understanding prepare projects save your time!
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 8
Students are given a problem specification Vague, misleading, ambiguous, conflicting
It has two parts: Report(i) Sort out what to do - analyse (ii) Sort out how to do it - design Demonstration(i) Do it ! - code (ii) Verify - test
Group size is 3 or 4. Strict deadline – the last week of teaching.
The Project
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 9
Recommendations For CPSC-4360-01 and CPSC-5360-01:
Walkthrough the software development process: Lectures give the theory background; Tutorials allow you to explore the theory; Project gives the opportunity to apply what you have
learned; Furthermore, CPSC-5360-01 students need to present a
research paper presentation. Best way to appreciate the course:
Read up relevant topics; Attend the lectures and tutorials; Do the relevant part for the project right after.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 10
Useful Software
Pre-requisites software: Java Programming Language (http://java.sun.com/).
Recommended software: ArgoUML (http://argouml.tigris.org/) is a UML design
tool with cognitive support, released on September, 2003;
JUnit (http://junit.sourceforge.net/) is a simple framework to write repeatable tests, released on August, 2002.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 11
Lecture Structure
Reminder of last lecture Overview Content (new notions + examples) Summary Reading suggestions Coming up next
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 12
Overview of This Lecture
Overview of Software Engineering SE definitions Quality of Good Software
Overview of Software Process Activities and associated stages
Overview of Software Engineering Method Structured Analysis Object-Oriented Method
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 13
What is ‘Software Engineering’?... A term used occasionally in 1950s, 1960s Popularized in 1968 at NATO Software Engineering Conference (http://homepages.cs.ncl.ac.uk/brian.randell/NATO/)
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 14
What is Software?
More than computer programs. The collection of programs, documentation
and configuration data that ensures correct execution.
Three major types: Generic Product: Stand alone, Sold on open
market. Customized Product: For specific customer. Embedded Product: Built into hardware.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 15
The Nature of Software Intangible:
Opposite of physical artifacts, e.g., Computer vs Windows XP
Hard to understand the development process. Easy to Reproduce:
Costly design and construction, cheap manufacturing.
Malleable: Easy to change, even without full understanding. Untrained people can “hack” something together.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 16
Software Development Problems “Software is not constrained by materials, or
governed by physical laws, or by manufacturing process” ---- (Sommerville, Software Engineering)
Allows almost unbounded complexity: Exponential growth of complexity w.r.t. to the size
of a program: twice the size, four times the complexity;
Example: Windows XP has 40millions lines of source code (estimation).
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 17
Software Development Problems Difficulty in understanding and managing the
complexity causes: Late completion:
“vaporware” that are announced but never produced Overrunning Cost:
Denver Airport Automated Baggage System, 2 billions US dollar over budget
Unreliable Difficult to maintain Etc…
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 18
Famous Software Disaster
Ariane 5 expendable launch system: Spacecraft launching system improved from
Ariane 4. First test flight took place on June 4, 1996.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 19
Famous Software Disaster (cont) US $5 hundred millions worth of payload
destroyed. Reason:
Main Navigation Computer crashes after 37 seconds.
Caused by a conversion overflow: converting floating point number to integer number.
Reuse of specification of Ariane 4 without taking into consideration the new capability.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 20
More Software Disasters
Denver Airport Automated Baggage System. Therac-25: Massive overdose of radiation. Link to History's Worst Software Bug:
http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1
http://www.comlab.ox.ac.uk/archive/safety.html http://www.csl.sri.com/risks.html
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 21
What is Engineering? Systematically identify, understand, and
integrate the constraints on a design to produce a successful result.
Constraints may include: available resources, physical or technical limitations, flexibility for future modifications and additions, cost, manufacturability, and serviceability.
Deduce specifications from the limits. Ethical Practices.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 22
Quality of Good Software Usability
Easy to learn and use. Efficiency
Does not waste resources such as CPU time and memory. Dependability
Reliable, secure and safe. Maintainability
Easily evolved (modified) to meet changing requirement. Reusability
Parts can be reused, with minor or no modification.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 23
Quality of Good Software
Can be quite different based on your viewpoint:
Customer:
- Solves problems at acceptable cost (time and resource).
Developer:
- Easy to design and maintain
User:
- Easy to learn
- Efficient to use
- Get work done
Developer Manager:
- Sells more and pleases customers
- Costing less to develop and maintain
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 24
So, ‘Software Engineering’ is
IEEE Standard 610.12: The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.
“Designing, building and maintaining large software systems”. - I. Sommerville
“Multi-person construction of multi-version software”. - D. L. Parnas
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 25
What is Software Engineering?... “Technological and managerial discipline of software products that are developed and modified on time and within cost estimates”. – R. Fairley “Software development is not simply a case of sitting down at a terminal and typing in the program code”.
– M. Priestley A discipline that guides the process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints. – our definition
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 26
Software Engineering Myths A general statement of objectives is sufficient
to begin writing programs - we can fill in the details later.
Poor Up-front definition is the major cause of failed software efforts.
If we get behind schedule, we can add more programmers and catch up.
Brooks Law: “Adding people to a late project makes it later.”
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 27
Software Engineering Myths
Project requirements continually change, but change can be easily accommodated because software is flexible.
Cost Impact
Severe
Moderate
Minor
Planning Design ImplementationOccurrence of
Change
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 28
Software Process
The steps involved in creating a software system Software Process.
The guideline or overall principle used during the Software Process Software Engineering Method.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 29
Software Process The set of activities and associated results
that produce a software product. Four fundamental process activities:
Software Specification Software Development Software Validation Software Evolution
Can be organized in different ways, described at varying level of details → different software development process models (lecture 2).
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 30
Activity 1: Software Specification Customers and Software Engineers
Define the software to be produced Define the constraints on its operations
Typical Stages: Feasibility Study:
Is it possible with the current technologies + within budget? Domain Analysis:
What is the background for the software? Requirements Gathering and Analysis:
What is it that the user wants? Requirements Specification:
Formal documentation on User and System requirements. Requirements Validation:
Check for realism, consistency, and completeness.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 31
Activity 2: Software Development Consists of Design and Programming System Analysts
Design: decide how the requirement can be implemented.
Programmers Coding: translate high level design into real code
in a chosen programming language.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 32
Activity 2: Software Development
Typical Stages (Design): Architectural Design: Split into subsystems Abstract Specification: High level specification on the
services and constraints for each subsystem Interface Design: Interface with other subsystems are
defined Component Design: Split the services and allocate to
components within a subsystem Data Structure Design: Choose appropriate data structure Algorithm Design: Design and specify algorithm used to
provide services
High Level
Low Level
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 33
Activity 2: Software Development Typical Stages (Programming):
Data structure and algorithm design (from the design stage) may be delegated to the programmer.
Personal activity. Usually without a predefined process.
Debugging: Low level testing of code. Reveals program defects (bugs).
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 34
Activity 3: Software Validation Software Engineer (or dedicated tester) and Customer:
Check the software to ensure it meets the customers’ requirements.
Typical Stages: Component Testing: Independent testing of individual
components in subsystem. System Testing: Testing of integrated components. Can be
multi-levels, e.g., subsystem → system. Acceptance Testing: Tested with customer supplied data. Final
test before operation. Interactive activity that feedback to previous stages:
E.g., an error in component testing triggers re-coding.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 35
Activity 4: Software Evolution Customers and Software Engineers:
Define changing requirements. Modify the software system to adapt.
Typical Work: Update the system for minor new requirements,
e.g., changing the telephone number from 7 digits to 8 digits, changing the date representation (the Millennium Bug).
Could be drastic, more like redevelopment, e.g., windows95 →windows98 → windowsXP.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 36
Simple Software Process Example In the simplest cases, code is written directly
from some statements of requirements.
Process
Artifact
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 37
Simple Software Process Example Two processes:
‘Analyze requirements’ ‘Write code’
Two artifacts: ‘Requirements specification’ ‘Source code’
‘Requirements specification’ can be written as: an informal outline or a highly detailed description.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 38
Simple Software Process Example Software Specification:
Analyze Requirement → Requirement Documentation Software Development:
Design: Data structure and algorithm
Programming: Write Code → Source Code Debugging
Software Validation: Compare against sample outputs
Software Evolution: Not applicable.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 39
A More Complex Software Process It is better to design before you code. On larger projects, intermediate pieces of
documentation are produced.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 40
A More Complex Software Process One new process:
‘Design module structure’ - splitting the program into modules and subroutines
One new artifact: ‘Structure chart’ – is based on the information
contained in the ‘requirements specification’ Both the ‘requirements specification’ and the
‘structure chart’ are used when writing the final code.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 41
A More Complex Software Process Software Specification:
Analyze Requirement → Requirement Documentation Software Development:
Design: Structure Chart of the functions/modules/classes
Programming: Write Code → Source Code Debugging
Software Validation: Compare against sample outputs
Software Evolution: Not applicable.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 42
Modeling the System
The structure chart is an example of system model.
A powerful and useful technique. Give abstract view of the actual system
Usually in graphical notation Easier to understand Easier to manipulate
The semantic, usage and notation used in modeling is part of Software Engineering Method, described next.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 43
Software Engineering Method A strategy for successfully developing
software. A guiding principle throughout the Software
Process. Based on the idea of developing graphical
models (abstract representation) of a system, which can be used as specification or design.
No best method: depends on type of system. Two popular methods are described next.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 44
Structured Analysis One of the earliest methods, developed in 1970s. Essence:
Function Oriented: Identify process (function) that transform data.
Good match for procedural languages like C, Pascal, Fortran, etc.
Example (Data Flow Diagram - DFD):
Push Value on to Stack
Stack
New Value
Stack with New Value
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 45
Structured (Procedural) Methods Structured methods = structured analysis and
structured design. Characteristic model = data flow diagram (description
of the system’s data and how the data interact with the system).
Structured methods refer to software systems where data are processed by functions external to data.
In other words, the system’s data are stored in one place, and functions (operations) are essentially separated by the data.
Structured methods are appropriate for the design of data-rich systems (e.g., relational databases).
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 46
Object-Oriented Methods Recently developed in 1990s. Essence:
Object-Oriented: Identify entity (object) that contains natural collection of both data and the process (function) that operates on them.
Good match for OO languages like C++, JAVA, SmallTalk, etc.
Example (UML Class Diagram):
Stack
-Items: Integer[ ]
+push(value: integer)
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 47
Object-Oriented Methods Most operations in real-world only use a small
fraction of the total data of the system, and most pieces of data will be accessed by a small number of operations.
So, there was a need to split the data repository and integrate pieces of data with the operations that directly manipulate those data = object-oriented approaches.
Example: scanners and printers are (in) separate (rooms), as they provide different operations.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 48
Structured and Object-Oriented Methods: Comparison Compared with structured approaches, in the object-
oriented approaches the operations are localized together with the data that they affect, instead of being part of a large and global structure.
Programs using object-oriented structures are easy to understand and maintain (incremental software development).
In the structured approach, each operation has the responsibility of choosing the necessary data from the central repository (i.e., global place where the data is stored).
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 49
What’s in CPSC-4360 and CPSC-5360? Subsequent lectures resemble a walkthrough of the
software development process using Object-Oriented Method.
Software Specification
-Domain Analysis-Requirements Gathering and Analysis-Requirements Specification-Requirements Validation-Feasibility Study
Software Development
-Architectural Design-Abstract Specification-Interface Design-Component Design-Data Structure Design-Algorithm Design
Software Validation
-Component Testing-System Testing-Acceptance Testing
Software Evolution
-Maintenance-Redevelopment
Those in Bold Font will be covered by lectures and project.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 50
What’s NOT in CPSC-4360 and CPSC-5360? Aspects of Project Management:
Scheduling Risk Assessment Quality Assessment Documentation Human Resource Management Etc….
Communication and Inter-Personal Skills: Other than communicating with your team mate and tutor Not formally covered.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 51
Object Thinking
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 52
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 53
Class Representation: Example Informal representation:
Define a class for representing students who can be identified by name may be enrolled in some program of some level.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 54
Class Representation: Example
Student- name : String- program : String- level : int+ Student(n:String, p:String, lv:int)
+ printDetails() : void
UML class
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 55
Class Representation: Examplepublic class Student { private String name; private String program; private int level; public Student(String n, String p, int lv) { name = n; program = p; level = lv; }
public void printDetails() { System.out.println("\nDetails for student " + name); System.out.println("\tProgram: " + program); System.out.println("\tLevel: " + level); }}
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 56
Summary
Overview of Software Engineering SE definitions Quality of Good Software
Overview of Software Process Activities and associated stages
Overview of Software Engineering Method Structured Analysis Object-Oriented Method.
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 57
Reading suggestions From [Wadhwa, Andrei, Soo; 2007]
Chapter 1 From [Priestley; 2004]
Chapter 1 Appendix A Exercises 1.1-1.4
From [Sommerville; 2004] Chapters 1, 2
From [Larman; 2005] Chapter 1
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 58
Coming up next
Software Development Process Models: [Wadhwa, Andrei, Soo; 2007], Chapter 2 [Priestley, 2004], Chapter 3
UML Overview: [Wadhwa, Andrei, Soo; 2007], Chapter 2 [Priestley, 2004], Chapters 1, 2
04/19/23CPSC-4360-01, CPSC-5360-01,
Lecture 1 59
Thank you for your attention!
Questions?