New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here


by: Raphael Maggio


Raphael Maggio
GPA 3.57


Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Class Notes
25 ?




Popular in Course

Popular in Computer Science and Engineering

This 22 page Class Notes was uploaded by Raphael Maggio on Saturday September 12, 2015. The Class Notes belongs to CSE 121 at University of California - Irvine taught by Staff in Fall. Since its upload, it has received 18 views. For similar materials see /class/201936/cse-121-university-of-california-irvine in Computer Science and Engineering at University of California - Irvine.

Similar to CSE 121 at UCI

Popular in Computer Science and Engineering




Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 09/12/15
INF 111 CSE 121 Software Tools and Methods I m I J Lecture Notes for Fall Quarter 2007 Michele Rousseau Set 7 Some slides adapted from Susan E Sim Announcements I o Reminder Quiz on Monday Lectures amp Readings 0 Lecture vs Lecture Slides Tum 7 Previous Lecture 0 Finished XP 1 l Tum 7 Remember Iterations to Release Phase 0 Several Iterations before 1St Release 0 of Iterations determined in planning hase 0 Each iteration takes 14 wks to implement 0 Select stories wisel these enforce system architecture for the entire stem Customer chooses stories for each iteration 0 Functional tests created by Customer 39 Run at the end ofeach iteration At the end of last iteration Production rum 7 And Productionizing Phase 0 End testing before release 0 New changes may be found o Decide whether to include in current release 1 Documented for later implementation 9 Maintenance Phase 0 Iterations shortened rum 7 Today s Lecture 0 Testing 0 No Silver Bullet rum 7 Topic 7 7 Veri cation and Validation Req rements I Validation quot Speification V I Verification Implementation gt waron IS Impemenlalon consistent mm requirements spewcanon an does the system meet me customer susefs needs Software Quality assessment by VampV i 0 Software process must include I verification and validation to measure product qualities correctness reliability robustness ef ciency usability understandability veri ability maintainability a reusability portability interoperability v realtime safety security survivability accuracy 0 Products can be improved by improving the process by which they are developed and assessed a Tom Testing Terminology 0 Failure Incorrect or unexpected I output based on specifications aSymptom of a fault 0 Fault Invalid execution state Symptom of an error May or may not produce a failure 0 Error Defect or anomaly or bug in source code 1 May or may not produce a fault Examples Faults Errors and Failures o Supgose nodes should be x A2 E V Failurarauiriessermr r Suppuse me inputs are A2 51 assureu path Will be 7 8 which Will nut 1245 reveal this fault because 6 is nut executed 7 Su Else the in uts are 7 HE P rthe Bltecuted path Will be l Z B E E E Which Will nut reveal the fault because C 1 El e sur pr V the uerinmuns m c atnuues a and A bum affect me use at c at riqu 6 r executing pam 1 2 4 5 6 8 Wll l reealthefailure buturilylf 42g lriputsAl E72 ll Functional and Structural Testing 0 Functional Testing 0 Test cases selected based on specification Views programcomponent as black box 0 Structural Testing 0 Test cases selected based on structure of code o Views program component as white box also called glass box testing rum 7 Black BOX vs White BOX Testing RESULTANT H DESIRED INPUTS outputs output SLACK onquot TESTING l u RESULTANT DESIRED outputs output SELECTED iNPUVS INTERNAL sortwaps EEHAVIOR IISIGN WM 7 WHITE onquot TESTNG Different Levels of Testing I 0 System Testing o De ned at Requirements gt Run a er integration test39n 0 Integration Testing De ned at Design gt Run a er Unit Testing 0 Unit Testing De ned at Implementation gt Run a er Implementation of each unit 0 Regression Testing testing after Change De ned throughoutthe process gt Run atter modifcations Tunic t Regression Testing I 0 Permanent suite of test cases t 0 Saves effort creating test cases Provides record of existing functionality 0 Add new test cases and delete obsolete ones when necessary Unit Testing a A unit test typically tests one class in the system A unit test suite contains many test cases Each test case typically tests one method in the system c There can be many test cases for each method in the system a Each test case either succeeds orfails there is no gray area a lfa test case has an error that is also a failure A test ortest suite can be said to succeed to a certain a percentage 0 Tupi 7 i5 Automated Testing 0 Idea Have the computer do more of the work ofrunning ancl tallying test cases 0 How Using tools like JUnit Benefits u Frequent testing 1 Concrete demonstration of effectiveness 0 In XP TestDriven Development says to create tests firs Automated Testing Tupi 7 i7 J Unit 0 Framework for performing unit testing on Java programs 0 Test cases are subclassed from an interface 0 Available as a standalone application and built intoEclipse 0 Framework executes the test cases and records the Results 0 Displays results in a GU 0 Keep the bar green to keep the code clean Tupi 7 18 More J Unit Help 0 Eclipse Hel Help gt Help Contents Java Development Us rGuide Getting Started Basic Tu oria Writing and running 0 JUnit tests JUnit Home Page httpwwwjunitorg o JUnit Primer v Ettpljlwww arkwarecomlarticleleUnitPrimer m 39 mm a lull The Mythical ManMonth 0 Originally Published in 1975 rocks Based on Experiences From 08360 ll l mldVBO S 0 So why should we care i I Fred B 0 Some interesting Stats Amazon com Sales ank with if Hunks m if Microprocessor Design 3 if Systems Analysis ampDesign I 12 if Software Engineering mm Who is Fred Brooks 0 Father of IBM 08360quot 01992 Computer Pioneer Award IEEE 01999 Turing award winner o 2007 Harvard Centennial Medal 39 o Founded UNCChapel Hill CS dept mm NoSilver Bullet There is no single development in either technology or management technique which by itself promises even one orderof magnitude improvement within a decade in productivity in reliability in simplicity rum 7 Essence amp Accident 0 Essential Tasks 9 Specifications design amp testing of conceptual cons ruc 0 Accidental or incidental Tasks 1 Programming amp Compiling The essential tasks are the hard part rum 7 23 Why is building sw dif cult I believe that hard part of building software to be the specification design and testing of this conceptual construct not the labor of representing it and testing the fidelity of the representation 0 It is the nature of slw inherent in the process 0 Conceptual errors are the problem rum 7 u Four Inherent Dif culties 0 Complexity 0 Conformity o Changeability o Invisibility rum 7 25 Complexity 0 Very large of states 0 Scaling is up is not a repetition of the same elements in large sizes 0 Elements interact in a nonlinear fashion 0 Complexity Communication 0 It is difficult to extend large programs Without creatingTside effects Complexity makes management difficult Personnel turnover can be a disaster rum 7 25 Some of Brooks Suggestions 0 IF an OTS fits buy it o Why reinvent the wheel 0 Requirements refinement and rapid prototyping a Many iterations between client and designer o Grow don t build software 1 Develop incrementally 0 Train great designers rum 7 27 Monday January 26 Overview Last Class Revision control This Class Revision control Code reading Programming practices Next Class UML infill013E121 WEEK 4 Slide 2 What to check in Code that compiles cleanly and has been tested Don39t check in les that are automatically created from others eg class files Do check in Your own little test programs And their expected output Readme files notes build logs etc Anything else you created by hand mm lCSElZl WEEK 4 Slide 3 When to check in Version control is not a backup system Your computer should have one ofthose Don39t check in just because you39re taking a break Check in files when they are stable eg After adding a new feature Or when you have to switch machines eg From home to school or vice versa lnm lCSElZl WEEK 4 Slide 4 Comments Upon check in you will have the opportunity to add a comment USE THIS FEATURE You re going to wish you did when you try to revert back to an earlier version mm lCSElZl Week 4 Slide 5 More Uses for Version Control Protecting you from yourself Backing out changes Finding where errors were injected Working with a team Simultaneous file sharing More complex products Multiple versions platforms Recording an audit trail Hey boss I ve been working Linus Torvalds vs 800 lnm lCSElZl Week 4 Slide 6 Branching and Merging Using a particular version as the baseline for a series of versions Reasons for branching Variations on a theme Experimental code Bug x chains Happens at the repository not your working copy fork merge Figure 196 Forking and merging of development paths nf111lCSE121 Week 4 Slide 7 Tagging Use tags to label a group of files Makes it easy to check out a release or configuration nf111lCSE121 Week 4 Slide 8 Exercise Adding Tax Rules lnfii icsEizi WEEK 4 Slide 9 Program Intently and Expressiver The PIE Principle Code you write must clearly communicate your intent and must be expressive By doing so your code Will be readable and understandable Since your code is not confusing you will also avoid some potential errors Program Intently and Expressively Choose readability over convenience Clearly communicate your intent int result va 1 More difficult to understand int result va 2 Much clearer Pick this Examples Avoid magic numbers Avoid unnecessary optimization lnfiiiCSEiZi Weewz Slide in Wednesday January 28 Overview Last Class Revision Control Programming Practices This Class Programming Practices UML Next Class UML lnfiiiCSEiZi WEEKA Slide 12 Program Intently and Expressiver The PIE Principle Code you write must clearly communicate your intent and must be expressive By doing so your code will be readable and understandable Since your code is not confusing you will also avoid some potential errors Program Intently and Expressively Choose readability over convenience Clearly communicate your intent int result val 1 More difficult to understand int result val 2 Much clearer Pickthis Examples Avoid magic numbers Avoid unnecessary optimization inmicsEizi W22k4Slid213 Avoid Magic Numbers directly Numerical constants literals should not be coded Prevent the number from being changed inconsistently in different places eg in previous example WEIGHT can be used in many places If it is hardcoded and its value need to be changed the change can be inconsistent Easier to understand eg OBJECTHEGHT width lengthquot is more readable than H4 width lengthquot lnflllCSElZl WEEKA Slide 15 Compare these two snippets int volumeint i intj int vol vol i j k return vol int calculateVolumeint width int length int volume 0 volume OBJECTHEGHT width length return volume lnflllCSElZl Only know that the function multiplies i j an But for what purpose And where did k come from Instantly know that it calculate volume of a rectangular solid object with a fixed height WEEKA Slide is Unified Modeling Language Let s look at each of the words in the name Uni ed Two important methodologists Rumbaugh and Booch decided to merge their approaches in 1994 They worked together at the Rational Software Corporation In 1995 another methodologist Jacobson joined the team His work focused on use cases In 1997 the Object Management Group OMG started the process of UML standardization WEEKA Slide 17 lnf111CSE121 Models Models are abstract representations Contain essential characteristics and omit nonessential details Essential depends on the problem domain There are no perfect representations Models can be representations of the world Domain models Requirements Models can be representations of software Specifications Design Systems WEEKA Slide 18 lnf111CSE121 Why make models Systems are complex and hard to understand The world organizations relationships software Models can make certain aspects more clearly visible than in the real system What can you do with models Express your ideas and communicate with other engineers Reason about the system detect errors predict qualities Generate parts of the real system code schemas Reverse engineer the real system to make a model lnflllCSElZl Weekzt Slide 19 Brooks on Invisibility of Software Software is invisible and unvisualizable Geometric abstractions are powerful tools As soon as we attempt to diagram software structure we find it to constitute not one but several general directed graphs superimposed on upon another The several graphs may represent the flow of control the flow of data patterns of dependency time sequence namespace relationships These are usually not even planar much less hierarchical Indeed one of the ways of establishing conceptual control over such structure is to enforce link cutting until one or more ofthe graphs becomes hierarchical infill013E121 Weekzt Slide 2n What constitutes a good model A model should Provide abstraction Render the problem in a format amenable to reasoning use a standard notation be understandable by clients and users lead software engineers to have insights about the system make the problem solvable computationally Be good enough lnflllCSElZl Weemeiiuezi Remember It s only a model There will always be Phenomena in the application domain that are not in the model Details in the application that are not in the model A model is never perfect If the map and the terrain disagree believe the terrain Perfecting the model is not always a good use of your time infill013E121 Weem Slide 22 Modeling Languages Natural language Extremely expressive and flexible Very poor at capturing the semantics ofthe model Better used for elicitation and to annotate models for communication Semiformal notation Captures structure and some semantics Can perform some reasoning consistency checking animation etc Examples diagrams tables structured English etc Mostly visual for rapid communication with a variety of stakeholders Formal notation very precise semantics extensive reasoning possible Every detailed models may be more detailed than we need lnflllCSElZl Weexa Slide 23 Visual Languages Words symbols Syntax rules for combining symbols drawing and layout of language Example Sheet music tictactoe Example Visual Basic is a visual programming language 0 4 lnflllCSElZl Weexa Slide 24


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Amaris Trozzo George Washington University

"I made $350 in just two days after posting my first study guide."

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.