├── README.md ├── course-info.md ├── deliverables ├── 1 │ ├── deliverable1.md │ └── grading_rubric.txt ├── 2 │ ├── deliverable2.md │ └── grading_rubric.txt ├── 3 │ ├── deliverable3.md │ └── grading_rubric.txt └── 4 │ ├── deliverable4.md │ └── grading_rubric.txt ├── exercises ├── 2 │ └── exercise2.md ├── 3 │ └── exercise3.md ├── 5 │ ├── exercise5.md │ └── hints.md └── Swing_Optional │ └── swing_optional_exercise.md ├── groups ├── Class1 │ ├── Example.md │ ├── FantasticFive.md │ ├── Gumdrop │ ├── Premature Optimization │ ├── TODOComeUpWithTeamName.md │ ├── Team │ ├── Team McTeamFace.md │ ├── Team StillMetaName │ ├── TeamTeamerson.md │ ├── Tha Winged Justice │ ├── ThaSourPatchKidz.md │ ├── WorldOfTeam.md │ └── sourfrittles.md └── Class3 │ ├── Anton Did Nothing Wrong.md │ ├── BitsPlease.md │ ├── Communism.md │ ├── Cronenbergs.md │ ├── D3S.md │ ├── Example.md │ ├── FightingFooBars.md │ ├── FileFormatExceptions.md │ ├── FiveGuys.md │ ├── SennottSquareSUPERCoders.md │ ├── SugarPlumFairies.md │ ├── TheTestGroup.md │ └── longNerdsRope.md ├── lectures ├── CS1530_Lecture10_ProjectManagement.pdf ├── CS1530_Lecture11_Implementation.pdf ├── CS1530_Lecture12_GradleBuildTool.pdf ├── CS1530_Lecture13_QA_Quality_Software.pdf ├── CS1530_Lecture14_TacticalSoftwareDesign.pdf ├── CS1530_Lecture15_Concurrency.pdf ├── CS1530_Lecture16_Integration.pdf ├── CS1530_Lecture17_Legacy_Code.pdf ├── CS1530_Lecture18_SoftwareEngineeringTradeoffs.pdf ├── CS1530_Lecture19_SoftwareCraftsmanship.pdf ├── CS1530_Lecture2_SDLC.pdf ├── CS1530_Lecture3_Building_A_Software_System.pdf ├── CS1530_Lecture4_Principles.pdf ├── CS1530_Lecture5_Methodologies.pdf ├── CS1530_Lecture6_AgileScrum.pdf ├── CS1530_Lecture7_RequirementsEngineering.pdf ├── CS1530_Lecture8_SoftwareDesignArchitecture.pdf └── CS1530_Lecture9_DetailedDesign.pdf ├── reading-quizzes ├── answers.md ├── quiz1.md ├── quiz2.md ├── quiz3.md ├── quiz4.md └── quiz5.md ├── sample_code ├── VarReuse.java ├── Warning.java ├── complexity │ ├── Foo2.asm │ ├── Foo2.bytecode │ ├── Foo2.java │ └── README.md ├── concurrency │ ├── Atomic.java │ ├── BadConcurrency.java │ ├── BetterConcurrency.java │ ├── ConcurrentCalculator.java │ ├── ConcurrentHashMapDemo.java │ ├── ConstructorConcurrency.java │ ├── DavidConcurrency.java │ ├── Deadlock.java │ ├── FixedDeadlock.java │ ├── HashMapDemo.java │ ├── HashtableDemo.java │ ├── HowManyThreads.java │ ├── Increment.java │ ├── JoinDemo.java │ ├── Livelock.java │ ├── LolWut.java │ ├── MethodLevelConcurrency.java │ ├── NoShared.java │ ├── SimpleThread.java │ ├── SynchronousCalculator.java │ ├── ThreadedHashMap.java │ ├── Timer.java │ ├── TimerActual.java │ └── UnnecessaryShared.java └── unsafe │ ├── OrdinaryClass.java │ └── SoUnsafe.java ├── study_guides ├── midterm_1_study_guide.md └── midterm_2_study_guide.md └── syllabus.md /README.md: -------------------------------------------------------------------------------- 1 | # CS1530_Fall2017 2 | CS1530 Software Engineering at the University of Pittsburgh, Fall 2017 Semester 3 | -------------------------------------------------------------------------------- /course-info.md: -------------------------------------------------------------------------------- 1 | # CS/COE 1530 Software Engineering 2 | 3 | ## Course Information 4 | 5 | **Taught by:** Bill Laboon (laboon at cs dot pitt dot edu) 6 | 7 | **Professor's Office Hours:** 8 | 9 | * SENSQ 6305 10 | * Tuesdays 1:30 - 4:30 PM (except first week) 11 | 12 | **Class Time:** Mon / Wed, 1:00 PM - 2:15 PM (Class 1) or 3:00 PM - 4:15 PM (Class 2) 13 | 14 | **Room:** 5129 Sennott Square 15 | 16 | **TAs:** 17 | 18 | Hardik Chinoy - (GitHub username: hardikchinoy25) hac118 at pitt dot edu (1:00 - 2:15) 19 | 20 | Krithika Ganesh - krg63 at pitt dot edu (3:00 - 4:30) 21 | 22 | **Class GitHub repo:** [https://www.github.com/laboon/CS1530_Fall2017](https://www.github.com/laboon/CS1530_Fall2017) 23 | 24 | **Required Texts:** 25 | 26 | * Essentials of Software Engineering. Author: Frank Tsui et al. ISBN 9781284106008 27 | 28 | * Code Complete (Second Edition). Author: Steve McConnell. ISBN 0790145196705 29 | 30 | * Online essays/articles will also be assigned. 31 | 32 | This course provides students with a broad understanding of modern software engineering. It will cover both theory and practical skills in software engineering necessary to be successful in industry. To that end, it will cover project and product management, software architecture and design patterns, team communications, and other material relevant to __engineering__ software instead of just __coding__ it. 33 | 34 | ## Grading 35 | 36 | * Group Project - 50% 37 | * Sprint 1 Deliverable - 10% 38 | * Sprint 2 Deliverable - 12% 39 | * Sprint 3 Deliverable - 13% 40 | * Sprint 4 Deliverable - 15% 41 | * Midterms - 30% 42 | * Midterm 1 - 15% 43 | * Midterm 2 - 15% 44 | * Reading Quizzes and Exercises - 20% 45 | * Reading Quizzes (5) - 10% 46 | * Exercises (5) - 10% 47 | 48 | It is strongly recommended that you come to class each for each lecture. Material may be presented or covered in class that is not in the reading. 49 | 50 | The syllabus is subject to modification if circumstances dictate (e.g. a guest lecturer is unable to make the scheduled day). 51 | 52 | The following grading scale will be used. 53 | 54 | Score | Grade 55 | -----: | ------------------------------ 56 | 100.00-94.00 | A (A+ for extraordinary work) 57 | 93.99-91.00 | A- 58 | 90.99-88.00 | B+ 59 | 87.99-84.00 | B 60 | 83.99-81.00 | B- 61 | 80.99-78.00 | C+ 62 | 77.99-74.00 | C 63 | 73.99-71.00 | C- 64 | 70.99-68.00 | D+ 65 | 67.99-64.00 | D 66 | 63.99-61.00 | D- 67 | 60.99-0.00 | F 68 | 69 | All groups are expected to do their own work on the group project, but are more than welcome to collaborate and ask questions with other groups, the Internet, or other colleagues. Projects may be analyzed with the Stanford _moss_ system to detect unauthorized collaboration between groups. 70 | 71 | It is recommended you keep all of your graded assignments until final grades are posted and accepted, in order to resolve any discrepancies in grading. 72 | 73 | ## Readings 74 | 75 | Readings are listed in the _syllabus.md_ file for each day. The instructor may not mention the reading for the next class. The onus is on you to review the syllabus and do the appropriate reading before class. 76 | 77 | ## Attendance 78 | 79 | Presence for the class exercises are REQUIRED. They will be individually re-scheduled only in the event of an emergency. If you are facing an emergency, please contact the instructor IMMEDIATELY (if it is safe to do so, of course). Failure to show up for a class exercise without clearing it first with the instructor will result in a 0 (zero) for that exam or exercise. 80 | 81 | ## Group Project Details 82 | 83 | Students will be grouped into teams of approximately 4, and will work on a specified project for much of the course. There will be several sprints, at the end of each of which the students will have a working version of their software available on GitHub, as well as documentation and other information (specified for each particular sprint). 84 | 85 | Deliverables must be committed to GitHub by the beginning of class on the day that it is due. Late deliverables will NOT be accepted unless authorized __at least 24 hours before the due date__. 86 | 87 | ## Programming Language Selection 88 | 89 | All software projects for this course will be written in the Java language (version 1.8 or later). Additionally, we will be using associated tools, libraries and frameworks such as Swing, Gradle and JUnit. These will be discussed in class. 90 | 91 | ## Collaborative Programming 92 | 93 | Note that all works produced by you are your intellectual property and you may do what you want with it. However, this class is collaborative. You may need to show and share your work to other students under the direction of the instructor. 94 | 95 | ## Participating in Class 96 | 97 | Under reasonable circumstances, it is almost always better to participate in class than not. Questions and comments are invited and strongly encouraged! However, this implies raising your hand and waiting to be called upon. In dire circumstances, some waving of the hands in order to get the instructor's attention is allowed, but suboptimal. Talking out of turn or while the instructor is speaking is generally frowned upon. If it persists after a warning has been given, the instructor may ask any offending parties to leave the room to continue their discussion elsewhere. 98 | 99 | ## Disability Services Statement 100 | 101 | The Office of Disability Resources and Services (DRS) provides a broad range of support services to assist students with disabilities. Services include, but are not limited to, tape-recorded textbooks, sign language interpreters, adaptive and transportation. Contact DRS at 412-648-7890 or 412-383-1355 (TTY) in 216 William Pitt Union or see www.drs.pitt.edu for more computer technology, Braille translation, and nonstandard exam arrangements, DRS can also assist students with accessibility to campus housing information. 102 | 103 | ## Academic Integrity Statement 104 | 105 | The integrity of the academic process requires fair and impartial evaluation on the part of faculty and honest academic conduct on the part of students. To this end, students are expected to conduct themselves at a high level of responsibility in the fulfillment of the course of their study. It is the corresponding responsibility of faculty to make clear to students those standards by which students will be evaluated and the resources permissible for use by students during the course of their study and evaluation. The educational process is perceived as a joint faculty-student enterprise which will perforce involve professional judgment by faculty and may involve—without penalty—reasoned exception by students to the data or views offered by faculty. 106 | 107 | Cheating/plagiarism will not be tolerated. Students suspected of violating the University of Pittsburgh Policy on Academic Integrity, from the February 1974 Senate Committee on Tenure and Academic Freedom reported to the Senate Council, will be required to participate in the outlined procedural process as initiated by the instructor. A minimum sanction of a zero score for the quiz or exam will be imposed. 108 | 109 | View the complete policy at www.cfo.pitt.edu/policies/policy/02/02-03-02.html. -------------------------------------------------------------------------------- /deliverables/1/deliverable1.md: -------------------------------------------------------------------------------- 1 | # CS/COE 1530 - Software Engineering 2 | Fall Semester 2017 3 | 4 | ### ASSIGNED 11 OCT 2017, DUE 25 OCT 2017 5 | 6 | ## Deliverable 1 7 | 8 | For the first sprint, each group will need to: 9 | 10 | 1. Determine initial user stories for the project, including prioritization, based on an interview with the product owner 11 | 2. Write a task network to determine ordering/prioritization 12 | 2. Write a walking skeleton and prototype UI of the application using gradle, which should include unit tests 13 | 14 | The team should determine the Scrum Master for this first sprint. The Scrum Master will change each sprint. 15 | 16 | ## Format 17 | 18 | For the first sprint, you will turn in: 19 | 20 | 1. A cover page, in the format described below 21 | 2. A breakdown of the user stories BEING DONE IN THIS SPRINT as a task network. You do NOT need to estimate time, but only indicate which user stories must be completed before others. 22 | 3. A "walking skeleton" application available on GitHub in a PRIVATE repository (ADD ME AND THE TA AS COLLABORATORS! Usernames "laboon" and "hardikchinoy25" (1:00 class) or "KrithikaGanesh" (3:00 class)). This should include a basic UI of the program - note that only minimal functionality is required here for the first deliverable. 23 | 24 | 25 | Format for cover page: 26 | * The title "*your team name* - SPRINT 1 DELIVERABLE" 27 | * The names of the people in the group, and their GitHub or GitLab username. Mark down who the Scrum Master is this sprint, e.g. "Jane Doe (Scrum Master)" 28 | * Link to the project repository on GitHub 29 | * The date that it is due (25 OCT 2017) 30 | 31 | ## Grading 32 | * User Stories (in GitHub): 15% of grade 33 | * Task network: 10% of grade 34 | * Project set up and used correctly on GitHub: 15% of grade 35 | * Initial GUI: 60% of grade 36 | 37 | User stories shall be in the Connextra template ("As a.. I want.. so that..") and provide good, user-level descriptions of user needs and wants. User stories should be printed in order of priority. It is NOT expected that you will complete every single user story, or even that these are the final versions of the user story; they may change and be prioritized differently as the sprints go on. 38 | 39 | All user stories shall have story points listed, either in the main description or in the comments. 40 | 41 | User stories should flow from the needs of the customer. Your discussions with the customer should guide the user stories themselves as well as their prioritization. 42 | 43 | The number of user stories in the product backlog will vary based on the project, but it should be at least eight at the VERY minimum. If there are fewer than eight stories, the project may be too small or your user stories too big. 44 | 45 | You should set up a GitHub Project which has four columns: product backlog, sprint backlog, in progress, complete. All user stories should start in the product backlog, and move to sprint backlog when they are scheduled to be done in this sprint. Stories should generally progress from there to in progress to complete. 46 | 47 | User Stories should be entered as "issues" and put in the appropriate place (product backlog, sprint backlog, in progress, complete) in the Project. Tasks can also be added as issues. 48 | 49 | The walking skeleton __must__ compile and show a basic UI for the application. You can have more functionality if you like, but it is essential that your program compiles, runs and displays a basic UI without error! 50 | 51 | This basic UI should display: 52 | 53 | 1. The game area (including the squares of the game with labels) 54 | 2. Tokens on the board, indicating players. 55 | 3. A place to see the deck and the last card dealt 56 | 57 | The game should ask for the number of players and names upon startup, which will be displayed in the status area. 58 | 59 | The basic UI may change over the course of the project. 60 | 61 | The walking skeleton __must__ be able to run on __everybody's__ computer! Everybody should have access to the repository on GitHub and able to make commits by the end of this sprint. 62 | 63 | You must "tag" the particular commit you want to have graded with the tag "D1". Make sure you make an annotated and not a lightweight tag. Also be sure you push the tag up to GitHub specifically! Pushing up the branch to origin will NOT automatically push up the tag as well, you must do so separately. If you want to tag the current commit, you may do so with the following commands: 64 | 65 | ``` 66 | git tag -a D1 -m "D1" 67 | git push origin D1 68 | ``` 69 | 70 | Further details on tagging are here: https://git-scm.com/book/en/v2/Git-Basics-Tagging 71 | 72 | The needs of the customer will be determined in class by interviewing the product owner (i.e., Bill Laboon). 73 | 74 | ## The Game 75 | 76 | In this class, we are going to make a game, World of Sweets, which is similar to but legally distinct from Candyland (tm). In this game, users take turns drawing cards from a deck and moving the appropriate nunmber of spaces. The first player to reach the last square on the board (Grandma's House) wins the game. 77 | 78 | There are two kinds of cards, single and double. There is a ratio of 5 singles for every double. The initial deck has 10 singles and 2 doubles of each color of card (red, yellow, blue, green, orange). 79 | 80 | Squares alternate between several colors: red, yellow, blue, green, and orange, in that order. The first square should be red. Players start immediately "before" the first square (on the "zeroth" square). The last square is a special square, Grandma's House, which can be treated as any color. 81 | 82 | ``` 83 | [GRANDMA'S] <- ... <- [YELLOW] <- [RED] 84 | ^ 85 | | 86 | [START] -> [RED] -> [YELLOW] -> [BLUE] -> [GREEN] -> [ORANGE] 87 | 88 | ``` 89 | 90 | Upon receiving a single card of a specific color, the player moves their token to the NEXT space with the same color as the card. For example, assume Player 1 is on the zeroth square. They draw a "single red" card. They go to the first square, which is red. Player 2 draws a single yellow and goes to the first yellow square (square 2). Player 1 draws another single red and they go to the *next* red square. Player 2 is now on the red square and draws another single red. They go to square 6 (the next red square). Player 2 draws a single blue and moves one space to the next blue square. 91 | 92 | For double cards, players move two spaces of that color forward. For example, assume Player 1, on square 6 (red), draws a double yellow card. They go one space to the next yellow, and then five more spaces to the next yellow. 93 | 94 | Grandma's House, the last square on the board, will be a "rainbow" square which counts as any color. If a player lands on or goes past Grandma's House, they win the game. 95 | 96 | Remember that this is a *deck* of cards. This deck is "used up" as the game progresses. When all of the cards have been used, re-shuffle the deck and start from the top of the deck. You should *not* be randomly choosing a combination of color / number each turn! 97 | 98 | Additionally, there are "special" cards. These special cards will perform special actions, such as moving you to a certain square on the board. These are not necessary for the first deliverable. 99 | 100 | We will start by allowing up to four players to play against each other on the same computer. Future functionality may include playing the computer (AI), playing by email (correspondence), or via a server. 101 | 102 | Further details on what other features, functionality, etc. may be found by interviewing the customer/user during the stakeholder interaction exercise. Features and functionality are subject to change as the customer better understands the system and their own needs. 103 | 104 | For the initial deliverable, you should implement and test, at a minimum, the following features: 105 | 106 | 1. User is asked how many players 107 | 2. Board is displayed, with squares, token, and card deck 108 | 3. Players are cycled through (take turns) 109 | 4. Cards are drawn and displayed 110 | 111 | Tokens do not need to move for the initial deliverable. 112 | 113 | There should be, at a bare minimum, two unit tests per story completed. If you cannot do a unit test for a specific case, you should write and execute a manual test for that case. 114 | 115 | Endeavour to write your code in a good, object-oriented way. This will help with testing and extension later. 116 | 117 | Additional features that may or may not be added later: 118 | 119 | 1. Ability to save/load games 120 | 2. "AI" players 121 | 3. Special cards 122 | 4. "Shortcuts" or "teleports" on the board 123 | 5. Game timer 124 | 125 | ## Other 126 | 127 | Each team member must indicate which user stories they worked on during the sprint. Every sprint, team members must implement at least one user story. 128 | 129 | You must use the Java Swing framework for the graphical user interface. You can use the following repository to either brush up on your Swing or learn it on your own: https://github.com/laboon/GameOfLife This contains a graphical version of Conway's Game of Life. 130 | 131 | The following files from my CS0401 class may also be helpful as examples: 132 | 133 | 1. Frames - https://github.com/laboon/cs0401/blob/master/sample_code/FrameDemo.java 134 | 1. Panels - https://github.com/laboon/cs0401/blob/master/sample_code/PanelDemo.java and https://github.com/laboon/cs0401/blob/master/sample_code/PanelDemo2.java 135 | 2. Extending Panels - https://github.com/laboon/cs0401/tree/master/sample_code/extended_jpanel 136 | 3. Creating and Interacting with Buttons - https://github.com/laboon/cs0401/blob/master/sample_code/ButtonDemo.java 137 | 4. Creating a Grid Layout - https://github.com/laboon/cs0401/blob/master/sample_code/GridDemo.java 138 | 5. Dynamically Changing A Button - https://github.com/laboon/cs0401/blob/master/sample_code/NameChangeButtonDemo.java 139 | 140 | We will also have an in-class exercise for a Swing refresher. 141 | 142 | Please feel free to email me or come to office hours to discuss any problems you have. 143 | -------------------------------------------------------------------------------- /deliverables/1/grading_rubric.txt: -------------------------------------------------------------------------------- 1 | DELIVERABLE 1 2 | 3 | User Stories (in GitHub): _____ / 15 4 | 5 | * All user stories in Connextra template (-2 each if not) 6 | 7 | Task network: 10% of grade _____ / 10 8 | 9 | * All tasks done this sprint included (-3 each if missing) 10 | 11 | Project set up and used correctly on GitHub: 15% of grade _____ / 15 12 | 13 | * GitHub repository link included, TA added as collaborator 14 | (-5 points for each problem) 15 | * D1 tag added (-5 if "git checkout D1" does not work) 16 | * User stories entered as issues (-3 if missing) 17 | * User stories/tasks in correct place (completed stories 18 | this sprint should be completed) (-2 each if in wrong place) 19 | * Product Backlog, Sprint Backlog, In Progress, 20 | Completed columns (-2 per missing one - there can be others) 21 | 22 | Initial GUI _____ / 60 23 | 24 | * Board displays (-20 if nothing displays on screen) 25 | * Red - Yellow - Blue - Green - Orange path (-4 if other colors or 26 | different order) 27 | * Single and double cards dealt (-5 if only one kind, 28 | -12 if cards are not dealt/displayed at all) 29 | * Cards are randomized (diff games = diff patterns) 30 | (-5 if not randomized) 31 | * Visually distinct Grandma's House and Start (-5 each if not) 32 | * Can't have < 2 or > 4 players (-3 if <2 players can play, 33 | -3 if >4, -5 if both) 34 | * Players take turns (-9 if not) 35 | * One token per player (-3 if not) 36 | * gradle test - shows no failures (-5 if there are failures) 37 | * General test coverage ( > 8 unit OR manual tests total) 38 | (-3 for each test less than 8) 39 | * General code quality - (out of 10 points) 40 | * Code is commented 41 | * Good variable names 42 | * Strong cohesion, loose coupling 43 | * Good OO design 44 | 45 | _____ / 100 46 | -------------------------------------------------------------------------------- /deliverables/2/deliverable2.md: -------------------------------------------------------------------------------- 1 | # CS/COE 1530 - Software Engineering 2 | Fall Semester 2017 3 | 4 | ### ASSIGNED 25 OCT 2017, DUE 8 NOV 2017 5 | 6 | ## Deliverable 2 7 | 8 | For the second sprint, each group will need to: 9 | 10 | 1. Continue implementing user stories 11 | 2. Turn in a paper showing a task network of the user stories and detailing which member(s) worked on which user stories. 12 | 13 | The team should determine the Scrum Master for the second sprint. Remember that the Scrum Master will change each sprint. 14 | 15 | ## Format 16 | 17 | For the second sprint, you will turn in: 18 | 19 | 1. A cover page, in the format described below 20 | 2. A breakdown of the user stories BEING DONE IN THIS SPRINT as a task network. You do NOT need to estimate time, but only indicate which user stories must be completed before others. 21 | 3. A list of which developer worked on which user story 22 | 3. The application available on GitHub in the SAME PRIVATE repository as the first sprint. 23 | 24 | Format for cover page: 25 | * The title "*your team name* - SPRINT 2 DELIVERABLE" 26 | * The names of the people in the group, and their GitHub or GitLab username. Mark down who the Scrum Master is this sprint, e.g. "Jane Doe (Scrum Master)" 27 | * Link to the project repository on GitHub 28 | * The date that it is due (8 NOV 2017) 29 | 30 | Recall that all user stories must be shown as "issues" and planned out using the GitHub projects interface. 31 | 32 | All user stories should be done in SEPARATE BRANCHES and submitted via pull request. They should be reviewed by somebody who is NOT the originator of the code. This other person should review the code and merge the pull request. 33 | 34 | YOU SHOULD NEVER MERGE YOUR CODE DIRECTLY TO MASTER. IT SHOULD ALWAYS BE REVIEWED BY ANOTHER MEMBER OF THE TEAM AND SUBMITTED VIA PR. 35 | 36 | ## Grading 37 | * User Stories (in GitHub): 10% of grade 38 | * Task network: 10% of grade 39 | * Project set up and used correctly on GitHub: 10% of grade 40 | * Initial GUI: 70% of grade 41 | 42 | User stories shall be in the Connextra template ("As a.. I want.. so that..") and provide good, user-level descriptions of user needs and wants. User stories should be printed in order of priority. It is NOT expected that you will complete every single user story, or even that these are the final versions of the user story; they may change and be prioritized differently as the sprints go on. 43 | 44 | All user stories shall have story points listed, either in the main description or in the comments. 45 | 46 | User stories should flow from the needs of the customer. Your discussions with the customer should guide the user stories themselves as well as their prioritization. 47 | 48 | The number of user stories in the product backlog will vary based on the project, but it should be at least eight at the VERY minimum. If there are fewer than eight stories, the project may be too small or your user stories too big. 49 | 50 | User Stories should be entered as "issues" and put in the appropriate place (product backlog, sprint backlog, in progress, complete) in the Project. Tasks can also be added as issues. 51 | 52 | Your program __must__ compile and show the UI for the application using the command "gradle run". You can have more functionality if you like, but it is essential that your program compiles, runs and displays the UI without error! 53 | 54 | The program __must__ be able to run on __everybody's__ computer! Everybody should have access to the repository on GitHub and able to make commits by the end of this sprint. 55 | 56 | You must "tag" the particular commit you want to have graded with the tag "D2". Make sure you make an annotated and not a lightweight tag. Also be sure you push the tag up to GitHub specifically! Pushing up the branch to origin will NOT automatically push up the tag as well, you must do so separately. If you want to tag the current commit, you may do so with the following commands: 57 | 58 | ``` 59 | git tag -a D2 -m "D2" 60 | git push origin D2 61 | ``` 62 | 63 | Further details on tagging are here: https://git-scm.com/book/en/v2/Git-Basics-Tagging 64 | 65 | ## The Game 66 | 67 | For the second deliverable, you should implement and test, at a minimum, the following features: 68 | 69 | 1. Players take turns and tokens move to the appropriate square 70 | 2. Players have the ability to win / lose 71 | 3. Five "skip turn" cards added to the deck - if these are picked, the player makes no move during that turn 72 | 4. Three "Go to middle" card added to deck - if picked, that player goes to the middle square of the board (halfway between Start and Grandma's House - if you have an even number of squares, it should go to the one closer to Grandma's House). These cards and the Middle Square should be visually distinct from other cards. 73 | 74 | There should be, at a bare minimum, two tests per story completed. If you cannot do a unit test for a specific case, you should write and execute a manual test for that case. 75 | 76 | Endeavour to write your code in a good, object-oriented way. This will help with testing and extension later. 77 | 78 | ## Other 79 | 80 | Each team member must indicate which user stories they worked on during the sprint. Every sprint, team members must implement at least one user story. 81 | 82 | Please feel free to email me or come to office hours to discuss any problems you have. 83 | -------------------------------------------------------------------------------- /deliverables/2/grading_rubric.txt: -------------------------------------------------------------------------------- 1 | DELIVERABLE 2 2 | 3 | User Stories (in GitHub): _____ / 10 4 | 5 | * All user stories in Connextra template (-2 each if not) 6 | 7 | Task network: 10% of grade _____ / 10 8 | 9 | * All tasks done this sprint included (-3 each if missing) 10 | 11 | Project set up and used correctly on GitHub: 10% of grade _____ / 10 12 | 13 | * GitHub repository link included, TA added as collaborator 14 | (-5 points for each problem) 15 | * D2 tag added (-5 if "git checkout D2" does not work) 16 | * User stories entered as issues (-3 if missing) 17 | * User stories/tasks in correct place (completed stories 18 | this sprint should be completed) (-2 each if in wrong place) 19 | * Product Backlog, Sprint Backlog, In Progress, 20 | Completed columns (-2 per missing one - there can be others) 21 | 22 | GUI _____ / 70 23 | 24 | * Players take turns and tokens move (up to -15) 25 | * Players can win/lose (up to -10) 26 | * "Skip turn" cards added to deck (up to -10) 27 | * Three "go to middle" cards added to deck (up to -10) 28 | * gradle test - shows no failures (-5 if there are failures) 29 | * General test coverage ( > 8 unit OR manual tests total) 30 | (-3 for each test less than 8) 31 | * General code quality - (up to -10 points) 32 | * Code is commented 33 | * Good variable names 34 | * Strong cohesion, loose coupling 35 | * Good OO design 36 | 37 | _____ / 100 38 | -------------------------------------------------------------------------------- /deliverables/3/deliverable3.md: -------------------------------------------------------------------------------- 1 | # CS/COE 1530 - Software Engineering 2 | Fall Semester 2017 3 | 4 | ### ASSIGNED 8 NOV 2017, DUE 20 NOV 2017 5 | 6 | ## Deliverable 3 7 | 8 | For the third sprint, each group will need to: 9 | 10 | 1. Continue implementing user stories 11 | 2. Turn in a paper showing a task network of the user stories and detailing which member(s) worked on which user stories. 12 | 13 | The team should determine the Scrum Master for the third sprint. Remember that the Scrum Master will change each sprint. 14 | 15 | ## Format 16 | 17 | For the third sprint, you will turn in: 18 | 19 | 1. A cover page, in the format described below 20 | 2. A breakdown of the user stories BEING DONE IN THIS SPRINT as a task network. You do NOT need to estimate time, but only indicate which user stories must be completed before others. 21 | 3. A list of which developer worked on which user story 22 | 3. The application available on GitHub in the SAME PRIVATE repository as the first sprint. 23 | 24 | Format for cover page: 25 | * The title "*your team name* - SPRINT 3 DELIVERABLE" 26 | * The names of the people in the group, and their GitHub or GitLab username. Mark down who the Scrum Master is this sprint, e.g. "Jane Doe (Scrum Master)" 27 | * Link to the project repository on GitHub 28 | * The date that it is due (20 NOV 2017) 29 | 30 | Recall that all user stories must be shown as "issues" and planned out using the GitHub projects interface. 31 | 32 | All user stories should be done in SEPARATE BRANCHES and submitted via pull request. They should be reviewed by somebody who is NOT the originator of the code. This other person should review the code and merge the pull request. 33 | 34 | YOU SHOULD NEVER MERGE YOUR CODE DIRECTLY TO MASTER. IT SHOULD ALWAYS BE REVIEWED BY ANOTHER MEMBER OF THE TEAM AND SUBMITTED VIA PR. 35 | 36 | ## Grading 37 | * User Stories (in GitHub): 5% of grade 38 | * Task network: 10% of grade 39 | * Project set up and used correctly on GitHub: 5% of grade 40 | * Game: 80% of grade 41 | 42 | User stories shall be in the Connextra template ("As a.. I want.. so that..") and provide good, user-level descriptions of user needs and wants. User stories should be printed in order of priority. It is NOT expected that you will complete every single user story, or even that these are the final versions of the user story; they may change and be prioritized differently as the sprints go on. 43 | 44 | All user stories shall have story points listed, either in the main description or in the comments. 45 | 46 | User stories should flow from the needs of the customer. Your discussions with the customer should guide the user stories themselves as well as their prioritization. 47 | 48 | The number of user stories in the product backlog will vary based on the project, but it should be at least eight at the VERY minimum. If there are fewer than eight stories, the project may be too small or your user stories too big. 49 | 50 | User Stories should be entered as "issues" and put in the appropriate place (product backlog, sprint backlog, in progress, complete) in the Project. Tasks can also be added as issues. 51 | 52 | Your program __must__ compile and show the UI for the application using the command "gradle run". You can have more functionality if you like, but it is essential that your program compiles, runs and displays the UI without error! 53 | 54 | The program __must__ be able to run on __everybody's__ computer! Everybody should have access to the repository on GitHub and able to make commits by the end of this sprint. 55 | 56 | You must "tag" the particular commit you want to have graded with the tag "D3". Make sure you make an annotated and not a lightweight tag. Also be sure you push the tag up to GitHub specifically! Pushing up the branch to origin will NOT automatically push up the tag as well, you must do so separately. If you want to tag the current commit, you may do so with the following commands: 57 | 58 | ``` 59 | git tag -a D3 -m "D3" 60 | git push origin D3 61 | ``` 62 | 63 | Further details on tagging are here: https://git-scm.com/book/en/v2/Git-Basics-Tagging 64 | 65 | ## The Game 66 | 67 | For the third deliverable, you should implement and test, at a minimum, the following features: 68 | 69 | 1. A running timer showing minutes and seconds that the game is played (should be updated on-screen once per second in a different thread) 70 | 2. The ability to save/load games to a file. This file should include all game state including player positions, the card deck, and the current elapsed game time. Game time should be "paused" while players are not playing the game. 71 | 3. Modify the "move to middle" cards so that there are five "move to Square X" cards which take you one of five different locations on the board. These locations should _only_ be reachable via these cards and should have some sort of candy-themed unique visual specifier/identifier for each one. For example, you may have an Ice Cream square, Licorice square, etc. These must be visually distinct from each other. These squares are "colorless" - unless you get an Ice Cream card, for example, you will never land on the Ice Cream square. Remove the "move to middle" cards and have five of these cards, with each one of the cards moving to a specific square (e.g. one Ice Cream card which moves you to the Ice Cream square, one Licorice card which moves you to the Licorice square, etc.) 72 | 4. One additional feature of your team's choice 73 | 74 | There should be, at a bare minimum, two tests per story completed. If you cannot do a unit test for a specific case, you should write and execute a manual test for that case. 75 | 76 | Endeavour to write your code in a good, object-oriented way. This will help with testing and extension later. 77 | 78 | ## Other 79 | 80 | Each team member must indicate which user stories they worked on during the sprint. Every sprint, team members must implement at least one user story. 81 | 82 | Please feel free to email me or come to office hours to discuss any problems you have. 83 | -------------------------------------------------------------------------------- /deliverables/3/grading_rubric.txt: -------------------------------------------------------------------------------- 1 | DELIVERABLE 3 2 | 3 | User Stories (in GitHub): _____ / 5 4 | 5 | * All user stories in Connextra template (-2 each if not) 6 | 7 | Task network: 10% of grade _____ / 10 8 | 9 | * All tasks done this sprint included (-3 each if missing) 10 | 11 | Project set up and used correctly on GitHub: 10% of grade _____ / 5 12 | 13 | * D3 tag added (-5 if "git checkout D2" does not work) 14 | * User stories entered as issues (-3 if missing) 15 | * User stories/tasks in correct place (completed stories 16 | this sprint should be completed) (-2 each if in wrong place) 17 | 18 | Game _____ / 80 19 | 20 | * Regression failures (-5 each, -10 for major issues) 21 | * Timer starts at 0 at each game (-8 if not) 22 | * Timer counts ~ every one second (-10 if not) 23 | * Timer is in minutes:seconds format (-8 if not) 24 | * Can save games (-10 if not) 25 | * Can save to different files (-4 if not) 26 | * Can load games (-15 if functionality entirely missing) 27 | * Locations correct (-8 if not) 28 | * Names - if used - correct (-5 if not) 29 | * Time correct (-5 if not) 30 | * Five "candy squares" added (-10 if not) 31 | * Tokens go to correct candy square when they get candy square card (-8 if not) 32 | * Candy squares are visually distinct (-5 if not) 33 | * Players cannot otherwise land on candy squares (-5 if not) 34 | * gradle test - shows no failures (-5 if there are failures) 35 | * General test coverage ( > 8 unit OR manual tests total) 36 | (-3 for each test less than 8) 37 | * Additional feature added (up to -15 if not) 38 | * General code quality - (up to -10 points) 39 | * Code is commented 40 | * Good variable names 41 | * Strong cohesion, loose coupling 42 | * Good OO design 43 | 44 | _____ / 100 45 | -------------------------------------------------------------------------------- /deliverables/4/deliverable4.md: -------------------------------------------------------------------------------- 1 | # CS/COE 1530 - Software Engineering 2 | Fall Semester 2017 3 | 4 | ### ASSIGNED 20 NOV 2017, DUE 6 DEC 2017 5 | 6 | ## Deliverable 4 7 | 8 | For the fourth and final sprint, each group will need to: 9 | 10 | 1. Continue implementing user stories 11 | 2. Turn in a paper showing a task network of the user stories and detailing which member(s) worked on which user stories. 12 | 13 | The team should determine the Scrum Master for the final sprint. Remember that the Scrum Master will change each sprint. 14 | 15 | ## Format 16 | 17 | For the fourth sprint, you will turn in: 18 | 19 | 1. A cover page, in the format described below 20 | 2. A breakdown of the user stories BEING DONE IN THIS SPRINT as a task network. You do NOT need to estimate time, but only indicate which user stories must be completed before others. 21 | 3. A list of which developer worked on which user story 22 | 3. The application available on GitHub in the SAME PRIVATE repository as the first sprint. 23 | 24 | Format for cover page: 25 | * The title "*your team name* - FINAL DELIVERABLE" 26 | * The names of the people in the group, and their GitHub or GitLab username. Mark down who the Scrum Master is this sprint, e.g. "Jane Doe (Scrum Master)" 27 | * Link to the project repository on GitHub 28 | * The date that it is due (6 DEC 2017) 29 | 30 | Recall that all user stories must be shown as "issues" and planned out using the GitHub projects interface. 31 | 32 | All user stories should be done in SEPARATE BRANCHES and submitted via pull request. They should be reviewed by somebody who is NOT the originator of the code. This other person should review the code and merge the pull request. 33 | 34 | YOU SHOULD NEVER MERGE YOUR CODE DIRECTLY TO MASTER. IT SHOULD ALWAYS BE REVIEWED BY ANOTHER MEMBER OF THE TEAM AND SUBMITTED VIA PR. 35 | 36 | ## Grading 37 | * User Stories (in GitHub): 5% of grade 38 | * Task network: 10% of grade 39 | * Project set up and used correctly on GitHub: 5% of grade 40 | * Game: 80% of grade 41 | 42 | User stories shall be in the Connextra template ("As a.. I want.. so that..") and provide good, user-level descriptions of user needs and wants. User stories should be printed in order of priority. It is NOT expected that you will complete every single user story, or even that these are the final versions of the user story; they may change and be prioritized differently as the sprints go on. 43 | 44 | All user stories shall have story points listed, either in the main description or in the comments. 45 | 46 | User stories should flow from the needs of the customer. Your discussions with the customer should guide the user stories themselves as well as their prioritization. 47 | 48 | The number of user stories in the product backlog will vary based on the project, but it should be at least eight at the VERY minimum. If there are fewer than eight stories, the project may be too small or your user stories too big. 49 | 50 | User Stories should be entered as "issues" and put in the appropriate place (product backlog, sprint backlog, in progress, complete) in the Project. Tasks can also be added as issues. 51 | 52 | Your program __must__ compile and show the UI for the application using the command "gradle run". You can have more functionality if you like, but it is essential that your program compiles, runs and displays the UI without error! 53 | 54 | The program __must__ be able to run on __everybody's__ computer! Everybody should have access to the repository on GitHub and able to make commits by the end of this sprint. 55 | 56 | You must "tag" the particular commit you want to have graded with the tag "D4". Make sure you make an annotated and not a lightweight tag. Also be sure you push the tag up to GitHub specifically! Pushing up the branch to origin will NOT automatically push up the tag as well, you must do so separately. If you want to tag the current commit, you may do so with the following commands: 57 | 58 | ``` 59 | git tag -a D4 -m "D4" 60 | git push origin D4 61 | ``` 62 | 63 | Further details on tagging are here: https://git-scm.com/book/en/v2/Git-Basics-Tagging 64 | 65 | ## The Game 66 | 67 | For the final deliverable, you should implement and test, at a minimum, the following features: 68 | 69 | 1. Switch between "Classic" and "Strategic" modes of the game. Players will have the ability to choose at the beginning of the game. Classic mode is the game as it is been developed so far. In strategic mode, players will have three "boomerangs" at the start of the game. At the beginning of each turn, the player can either draw a card as per normal, or use a boomerang. If they use a boomerang, they select another player, then draw a card, and that player goes BACKWARD to the last square of that color, or to the START square if there are no squares of that color behind them. If the boomeranged player gets a "go to space" card, the player will go to that space. If the boomeranged player gets a "skip" card, nothing happens. Every use of a boomerang by a player will decrement their boomerang count by one. When a player has no more boomerangs, they cannot use a boomerang. These boomerangs shall be visibly displayed in such a manner that players are aware of how many boomerangs they have at the start of their turn. They may be visible at other times as well, at your discretion. 70 | 2. Incorruptible file - Saved game files should include a mechanism to discourage tampering with the file (to avoid somebody modifying it). You may do this with a simple cipher or adding a checksum to the end of the file. You do not need to worry about it being cryptographically secure, only enough to discourage a layman. If the file is tampered with, the game should refuse to load the game and inform the user that the file is corrupt. 71 | 3. AI players - There should an option to have the computer "play" for a player. This should apply for both modes of the game. You may have the AI randomly choose options if there are multiple options (as in "Strategic" mode). 72 | 4. "Dad" cheat - Players should be able to enter their names, if they cannot do so. If a player enters their name as "Dad", the game will cheat against them. Every time the player with the name "Dad" plays, the game will look through the remaining cards for the _worst_ possible card (defined as the card that will move that player to the square closest to the START square) and deal it to that player. 73 | 74 | There should be, at a bare minimum, two tests per story completed. If you cannot do a unit test for a specific case, you should write and execute a manual test for that case. 75 | 76 | Endeavour to write your code in a good, object-oriented way. 77 | 78 | ## Other 79 | 80 | Each team member must indicate which user stories they worked on during the sprint. Every sprint, team members must implement at least one user story. 81 | 82 | Please feel free to email me or come to office hours to discuss any problems you have. 83 | -------------------------------------------------------------------------------- /deliverables/4/grading_rubric.txt: -------------------------------------------------------------------------------- 1 | DELIVERABLE 4 2 | 3 | User Stories (in GitHub): _____ / 5 4 | 5 | * All user stories in Connextra template (-2 each if not) 6 | 7 | Task network: 10% of grade _____ / 10 8 | 9 | * All tasks done this sprint included (-3 each if missing) 10 | 11 | Project set up and used correctly on GitHub: 10% of grade _____ / 5 12 | 13 | * D4 tag added (-5 if "git checkout D4" does not work) 14 | * User stories entered as issues (-3 if missing) 15 | * User stories/tasks in correct place (completed stories 16 | this sprint should be completed) (-2 each if in wrong place) 17 | 18 | Game _____ / 80 19 | 20 | * Regression failures (-5 each, -10 for major issues) 21 | * Ability to switch between "Classic" and "Strategic" mode (-15 if not) 22 | * In strategic mode, each player has 3 boomerangs (-10 if not) 23 | * Boomerangs can be selected and work correctly (-10 if not) 24 | * File is not corruptible - modify data to cheat, see if it works 25 | (-15 if not) 26 | * AI players - each player can be selected to play as computer 27 | (-20 if not) 28 | * AI player works in both classic and strategic mode (-10 if only one) 29 | * "Dad" cheat works, selects poorest card if "Dad" entered for name 30 | (-10 if not) 31 | * gradle test - shows no failures (-5 if there are failures) 32 | * General test coverage ( > 8 unit OR manual tests total) 33 | (-3 for each test less than 8) 34 | * General code quality - (up to -10 points) 35 | * Code is commented 36 | * Good variable names 37 | * Strong cohesion, loose coupling 38 | * Good OO design 39 | 40 | _____ / 100 41 | -------------------------------------------------------------------------------- /exercises/2/exercise2.md: -------------------------------------------------------------------------------- 1 | ## Git 911 Exercise 2 | 3 | You and a partner should create a BasicGit repository (described below) and fork the BadRepo4 repository under GitHub username laboon. 4 | 5 | NOTE: There are BadRepos 0, 1, 2, and 3. It is NOT necessary to work on them for this exercise. 6 | 7 | ## Basic Git Functionality 8 | 9 | Create a simple Java program, BasicGit, which prints the integers from 1 to 10 inclusive. Add it to a git repository, and push it to GitHub. 10 | 11 | ### Creating A Repository 12 | 13 | 1. Log in to GitHub at https://github.com 14 | 2. Click on "Repositories" tab 15 | 3. Click on the green "New" button 16 | 4. Name the repository BasicGit 17 | 5. Ensure that the "public" radio button is selected 18 | 6. Check the checkbox to create a repository with a README.md file 19 | 7. Underneath that, select Add .gitignore: Java 20 | 8. Click the green "Create Repository" button 21 | 22 | ### Cloning It To Your Computer 23 | 24 | 1. Make sure you have git installed! 25 | 1. Navigate to https://github.com/YOUR_GITHUB_USERNAME/BasicGit 26 | 2. Click on the green "Clone or Download" button 27 | 3. Make sure it says "Clone with HTTPS" (if it does not, click the "Use HTTPS" link) 28 | 4. Copy and paste the URL shown in the textbox 29 | 5. At the command line, or git command window if in Windows, navigate to the directory you want the repo to live under. 30 | 6. Type "git clone" and then paste the URL you copied. This URL should end in .git, e.g., https://github.com/laboon/CS1530_Exercise3.git. You may have to re-enter your username/password at this point. 31 | 6. A copy of the repository is now located in a subdirectory called "BasicGit" under the current directory. 32 | 33 | ### Adding Appropriate Files and Pushing Back To GitHub 34 | 35 | 1. Ensure that you have completed the project. Running `java BasicGit` should print out the numbers from 1 to 10. 36 | 2. Go to the root directory of the project. 37 | 3. Type `git add .` (this will add all files in the current directory to git's tracking) 38 | 4. Type `git commit -am "final"` (this will commit all files that have been added to a commit) 39 | 5. Type `git push origin master` (this will sync your current git repo with the one on origin, i.e., GitHub) 40 | 6. Go to https://github.com/YOUR_GITHUB_USERNAME/BasicGit in your browser and ensure that you see all of the files you expected to see. 41 | 42 | ## Issue a Pull Request 43 | 44 | Create a new branch changing your program to count from 1 to 10 to count to 1 to 20. 45 | 46 | ### Detailed Instructions 47 | 48 | 1. From the root directory, create a new branch, `twenty`. Do this by the command: `git checkout -b twenty` 49 | 2. You should be told you are in a new branch: `Switched to a new branch 'twenty'` 50 | 3. Verify that you are in the twenty branch by typing `git branch`. This should have an asterisk next to your current branch. 51 | 4. Modify the code to count to 20 52 | 5. Type `git status`. This should show you that there is a modification in your Java file. 53 | 6. Add the BasicGit.java file to be commited by typing `git add BasicGit.java` 54 | 7. Commit your changes - `git commit -m "20"` 55 | 8. Push your changes to origin - `git push origin twenty` __NOTE: PUSH TWENTY, NOT MASTER BRANCH!__ 56 | 9. Go to your repo's home page (YOUR_USERNAME/BasicGit) 57 | 10. Click on the "Compare and Pull Request" button 58 | 11. Fill in the textboxes and click on the green Create Pull Request button 59 | 12. Click on the "Merge Pull Request" button 60 | 61 | You're done! 62 | 63 | ## Problem Repos 64 | 65 | _There is a problem with the following repository. Fix it. Please search for the answer via your favorite search engine before asking me. However, if you feel stuck, please ask! That is why I am here._ 66 | 67 | BadRepo4 - Merge the wjl_derp branch into master. Deal with the merge conflicts as best you can to eliminate them. There should be no merge conflicts for full credit. 68 | 69 | Please show or email me the fixed repo by the beginning of the next class. I will be putting up solutions at that time. 70 | 71 | ``` 72 | Basic Git: 1 point 73 | PR created: 0.5 point 74 | BadRepo4 fixed: 0.5 point 75 | ``` 76 | 77 | -------------------------------------------------------------------------------- /exercises/3/exercise3.md: -------------------------------------------------------------------------------- 1 | # Gradle Exercise 2 | 3 | You and a partner are going to create a Java application gradle project which will print results from two different integer sequences. You will then push your project to GitHub and show me. You must do this with a partner! 4 | 5 | The first integer sequence is the Triangle number sequence. Think of this as an "additive" version of a factorial function: whereas 5! = 5 * 4 * 3 * 2 * 1, Tri(5) = 5 + 4 + 3 + 2 + 1. You can find the exact equation here: https://en.wikipedia.org/wiki/Triangular_number 6 | 7 | The second sequence is the Lazy Caterer sequence. This is the sequence which indicates how many pieces a cake could be cut into by using n knife cuts. For example, with 0 knife cuts, a cake would have to stay in one piece. With two knife cuts, you could have four pieces. You can find the equation governing the Lazy Caterer sequence here: https://en.wikipedia.org/wiki/Lazy_caterer%27s_sequence 8 | 9 | The project should meet the following specifications: 10 | 11 | 1. A main class which accepts one argument, an integer. 12 | 1. If the argument is not an integer, or there are the wrong number of arguments (including no arguments), the program shall inform the user and exit with error code 1. 13 | 2. The program shall print out the result (the Lazy Caterer number and the Triangle number) in the following format: "Tri(n) = x" and on a separate line, "Lazy(n) = x". 14 | 3. At least three unit tests each for two methods (one to calculate triangle numbers and the other to calculate Lazy Caterer numbers) shall be added. Thus there should be a total of six unit tests. Each of these methods should accept a value _n_ and then simply return the _n_th sequence value. These methods should have no "side effects" (e.g. printing information to the terminal). 15 | 4. Aside from the gradle commands "build", "run", and "test", an additional task, "sequencehelp", shall be added. I should be able to run this command with `gradle -q sequencehelp` or `gradle sequencehelp` . This task shall do the following (in Groovy): 16 | 17 | ``` 18 | 1. Print "Integer Sequence Project" 19 | 2. Print "Given an integer n as an argument, displays Tri(n) and LC(n)." 20 | ``` 21 | 22 | If you need to exit with an error, it is important to exit with a different error than 0, as 0 indicates success to gradle. It will not know that your program has an error unless you indicate it with a non-zero exit code. This is good advice not just for this class but in general - if your program exits abnormally, the way to indicate this is with some non-zero exit code. Other programs which may depend on yours can use that as a "signal" from your program. 23 | 24 | When complete, you should push up to GitHub and either show me a link or email it to me (if you finish after class). It must be turned in by the next class. If you are emailing, be sure to note both your name and your partner's so that I give you both credit. 25 | 26 | ## Git / GitHub Basics 27 | 28 | Reminder for creating a repository and adding files. 29 | 30 | ### Creating A Repository 31 | 32 | 1. Log in to GitHub at https://github.com 33 | 2. Click on "Repositories" tab 34 | 3. Click on the green "New" button 35 | 4. Name the repository CS1530_Exercise3 36 | 5. Ensure that the "public" radio button is selected 37 | 6. Check the checkbox to create a repository with a README.md file 38 | 7. Underneath that, select Add .gitignore: Gradle 39 | 8. Click the green "Create Repository" button 40 | 41 | ### Cloning It To Your Computer 42 | 43 | 1. Make sure you have git installed! 44 | 1. Navigate to https://github.com/YOUR_GITHUB_USERNAME/CS1530_Exercise3 45 | 2. Click on the green "Clone or Download" button 46 | 3. Make sure it says "Clone with HTTPS" (if it does not, click the "Use HTTPS" link) 47 | 4. Copy and paste the URL shown in the textbox 48 | 5. At the command line, or git command window if in Windows, navigate to the directory you want the repo to live under. 49 | 6. Type "git clone" and then paste the URL you copied. This URL should end in .git, e.g., https://github.com/laboon/CS1530_Exercise3.git. 50 | 6. A copy of the repository is now located in a subdirectory called "CS1530_Exercise3" under the current directory. 51 | 52 | ### Adding Appropriate Files and Pushing Back To GitHub 53 | 54 | 1. Ensure that you have completed the project. 55 | 2. Go to the root directory of the gradle project. 56 | 3. Type `git add .` 57 | 4. Type `git commit -am "final"` 58 | 5. Type `git push origin master` 59 | 6. Go to https://github.com/YOUR_GITHUB_USERNAME/CS1530_Exercise3 in your browser and ensure that you see all of the files you expected to see. 60 | 61 | ### Submission 62 | 63 | Email me a link to repository (e.g., https://github.com/YOUR_GITHUB_USERNAME/CS1530_Exercise3) and the names and github usernames of the people who worked on it. This should be done _before_ the next class. 64 | 65 | ``` 66 | Grading: 67 | Lazy sequence: 0.5 68 | Triangle sequence: 0.5 69 | Tests: 0.5 70 | Error-checking: 0.5 71 | ``` -------------------------------------------------------------------------------- /exercises/5/exercise5.md: -------------------------------------------------------------------------------- 1 | ## Threads Exercise 2 | 3 | You and a partner are going to discover the value of pi through the magic of threads! 4 | 5 | First, let's discuss the _Monte Carlo_ method of calculation. In a Monte Carlo experiment, large numbers of random values are repeatedly tried, instead of using a deterministic algorithm. It is a form of stochastic testing. The benefit of using these methods is that sometimes trying to use a deterministic algorithm is infeasible, would require too much computation, or we do not know the underlying algorithm. 6 | 7 | For example, let's say we wanted to know how large a dartboard's bullseye is compared to the size of the dartboard. We throw twenty darts at it, aiming at different random parts of the board. Two end up in the bullseye. So we determine that 2 / 20, or 10%, of the board is the bullseye. Note that we are not guaranteed to get this value or anything close to it the next time we do this experiment. Perhaps next time, all of our darts miss the bullseye, and so we estimate that the size is 0% of the board. Or by change, every single dart of ours hits the bullseye, and we estimate that the bullseye takes up 100% of the board. 8 | 9 | This is one of the downsides of using a Monte Carlo method of calculation - it's not always replicable. However, with larger numbers, we _should_ get closer and closer to the true value (we will approach the value, if you will). Let's throw a million darts at the board, and we notice that 30,000 darts land in the bullseye. Assuming our throws were sufficiently random, we can say with relative confidence that the bullseye takes up 3% of the board (30000 / 1000000). It is very unlikely - but of course possible! - that it takes up 20% of the board, but only 3% of a million randomly-thrown darts ended up in it. 10 | 11 | For this project, let's assume that we do not know the value of _pi_, but we would like to discover it. Something we can do is think of a unit square (that is, each side is 1 "unit"), and throw a "dart" at some random point on it (with x and y both somewhere between 0.000 and 1.000). If x^2 + y^2 < 1, then that point is "inside" the circle. See this illustration: https://en.wikipedia.org/wiki/Monte_Carlo_method#/media/File:Pi_30K.gif 12 | 13 | After we have run this simulation many times, we can figure out the ratio between how many points were inside the circle and the total number of points. This should be multiplied by four (since we were looking at a "quarter" of the circle). This will allow us to calculate an estimate of pi. 14 | 15 | A more detailed description of the math is here: http://mathfaculty.fullerton.edu/mathews/n2003/montecarlopimod.html 16 | 17 | Since we're running many calculations which are basically independent of each other, this is an excellent opportunity to use threads! 18 | 19 | You will write a program which accepts two long arguments. The first will indicate how many threads the program should use, and the second how many total iterations. Note that the number of iterations should remain constant - for example, if I say 10,000 iterations, and have 4 threads, each thread should calculate 2,500 times. 20 | 21 | This program will tell the user the total number of iterations, the total number of values "inside" the circle, the ratio of points inside to total number of iterations, and finally calculate the value of pi from that. 22 | 23 | Note that you may not see significant differences in time until you work with rather larger numbers. For example, I used one billion (1,000,000,000) in the examples below. 24 | 25 | You should then time how long it takes the program to execute with a differing number of threads. Try to get it down to the minimum amount of time - this will differ based on different people's computers, especially depending on how many cores or virtual cores your computer's CPU has. 26 | 27 | If you are not seeing a reduction in time with more than one thread, even with large values, see the hints.md file in this directory. You can also ignore that file if you want to figure it all out on your own. 28 | 29 | One note: Using Math.random() will result in conflicts between multiple threads as they all try to access the static method. You should use ThreadLocalRandom to get random numbers - it's built into the Java API. Docs here: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadLocalRandom.html 30 | 31 | If you get stuck, check out hints.md for ideas before asking the instructor for help. 32 | 33 | ### Sample Output 34 | 35 | ``` 36 | [laboon@Bills-MacBook-Pro-2 ~/pitt/pitt_private] 37 | (16894) $ time java Pi 2 100 38 | Total = 100 39 | Inside = 90 40 | Ratio = 0.9 41 | Pi = 3.6 42 | 43 | real 0m0.312s 44 | user 0m0.185s 45 | sys 0m0.066s 46 | 47 | [laboon@Bills-MacBook-Pro-2 ~/pitt/pitt_private] 48 | (16895) $ time java Pi 4 100 49 | Total = 100 50 | Inside = 89 51 | Ratio = 0.89 52 | Pi = 3.56 53 | 54 | real 0m0.166s 55 | user 0m0.182s 56 | sys 0m0.036s 57 | 58 | [laboon@Bills-MacBook-Pro-2 ~/pitt/pitt_private] 59 | (16889) $ time java Pi 1 1000000000 60 | Total = 1000000000 61 | Inside = 785402183 62 | Ratio = 0.785402183 63 | Pi = 3.141608732 64 | 65 | real 0m5.996s 66 | user 0m5.990s 67 | sys 0m0.051s 68 | 69 | [laboon@Bills-MacBook-Pro-2 ~/pitt/pitt_private] 70 | (16893) $ time java Pi 2 1000000000 71 | Total = 1000000000 72 | Inside = 785418050 73 | Ratio = 0.78541805 74 | Pi = 3.1416722 75 | 76 | real 0m3.206s 77 | user 0m6.162s 78 | sys 0m0.053s 79 | 80 | [laboon@Bills-MacBook-Pro-2 ~/pitt/pitt_private] 81 | (16890) $ time java Pi 4 1000000000 82 | Total = 1000000000 83 | Inside = 785401494 84 | Ratio = 0.785401494 85 | Pi = 3.141605976 86 | 87 | real 0m2.780s 88 | user 0m9.980s 89 | sys 0m0.048s 90 | 91 | [laboon@Bills-MacBook-Pro-2 ~/pitt/pitt_private] 92 | (16892) $ time java Pi 20 1000000000 93 | Total = 1000000000 94 | Inside = 785430126 95 | Ratio = 0.785430126 96 | Pi = 3.141720504 97 | 98 | real 0m3.733s 99 | user 0m13.110s 100 | sys 0m0.075s 101 | ``` 102 | 103 | Please either show this to me in class or email me a link to your work on GitHub in order to receive credit. 104 | 105 | ``` 106 | Grading: 107 | Program works correctly: 1.5 108 | Timing values: 0.5 109 | ``` -------------------------------------------------------------------------------- /exercises/5/hints.md: -------------------------------------------------------------------------------- 1 | 1. Are you synchronizing properly? 2 | 3 | 2. Are you joining at the correct point? 4 | 5 | 3. Are you remembering to split the number of iterations amongst all threads? 6 | 7 | 4. Should you be using AtomicLong or similar Atomic variables? 8 | 9 | 5. Remember that synchronizing is computationally expensive. Are you minimizing the number of synchronizations? 10 | 11 | 6. Can you reduce shared mutable state? 12 | 13 | 7. Is there any information which you are re-calculating but it is not actually necessary to do so? 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /exercises/Swing_Optional/swing_optional_exercise.md: -------------------------------------------------------------------------------- 1 | ## Swing Exercise 2 | 3 | Your mission, should you choose to accept it, is to create a Tic-Tac-Toe game! 4 | 5 | As you are going along, please compile and check that you are on the right track regularly. Do not just type, type, type. Studies have shown that more senior software engineers tend to make smaller steps, whereas junior engineers like to type in hundreds of lines then see if they compile. Become a senior engineer as soon as you can! 6 | 7 | ### Instructions 8 | 9 | The first thing to do is import all of the libraries that we need. Specifically, we will want the java.awt.*, java.awt.event.*, and javax.swing.* classes. We will see why later. 10 | 11 | ```java 12 | import java.awt.*; 13 | import java.awt.event.*; 14 | import javax.swing.*; 15 | ``` 16 | 17 | After that, it's time to create a new frame. A frame is what most people think of as a window (this is actually an old term - Emacs, for example, calls a window a "frame"). Creating a JFrame will create a new window. You can set its size, default closing behavior, etc. Frames are constructed like so: 18 | 19 | ```java 20 | JFrame _frame = new JFrame("Tic-Tac-Toe"); 21 | ``` 22 | 23 | You should create this as an instance variable, not in a method. Example: 24 | 25 | ```java 26 | public class TicTacToe { 27 | JFrame _frame = new JFrame("Tic-Tac-Toe"); 28 | 29 | public static void main(String[] args) { 30 | 31 | } 32 | 33 | } 34 | ``` 35 | 36 | You will note that our class is a JFrame, and not a Frame. Frames are AWT (Abstract Window Toolkit) classes; JFrames are Swing classes. Swing is a GUI framework built on top of AWT (which is much nicer, trust me). You will find that most classes that start with J have an equivalent J-less class in AWT. 37 | 38 | We will do most of the work in the constructor; our main method should just make a new instance of the TicTacToe class. 39 | 40 | ```java 41 | public static void main(String[] args) { 42 | new TicTacToe(); 43 | } 44 | ``` 45 | 46 | The last line of the constructor should let the frame be visible. We can generate all of the data/elements/etc. "behind the scenes" without displaying them to the user, and then show them the finished version. If you find that a window is not updating, it may be that you need to "force" a refresh by setting the frame to visible again. It won't hurt anything if you do it more times than necessary (except when it comes to performance). 47 | 48 | ```java 49 | // Refresh window - otherwise we will not be able to see it 50 | // THIS IS A COMMON SOURCE OF BUGS! 51 | _frame.setVisible(true); 52 | ``` 53 | 54 | You can set the size of the frame by using the `setSize(width, height)` method on the frame. `width` and `height` are specified in pixels. The size of the frame is up to you. Figure out what works best on your screen. This can be done in the constructor. 55 | 56 | ```java 57 | _frame.setSize(400, 400); 58 | _frame.setVisible(true); 59 | 60 | ``` 61 | 62 | You can set what should happen the user closes the window. In many cases, we will want the program to exit; in others, we would want other events to occur. For example, if you have multiple Firefox windows open, and you close one, you would not want the whole program to exit! In our case, though, since we will have only one window and we will not need it to run in the background. You can also do this in the constructor. 63 | 64 | ```java 65 | _frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 66 | ``` 67 | 68 | Feel free to look at the JFrame API (https://docs.oracle.com/javase/8/docs/api/javax/swing/JFrame.html) to see what else you can do! Look under WindowConstants. 69 | 70 | Now, we want to have two sections of the frame. Each of these sections is called a panel, and like good Swing classes, are called JPanels. Create them 71 | 72 | ```java 73 | JPanel _ttt = new JPanel(); 74 | JPanel _newPanel = new JPanel(); 75 | ``` 76 | 77 | The top panel is going to be a grid layout (that is, it will have all of its elements in a two-dimensional grid, just like a Tic-Tac-Toe board). Each spot in the grid will be a button. The bottom panel is only going to have one button in it, so it doesn't really matter what layout we use. 78 | 79 | In the constructor, set their respective layouts: 80 | 81 | ```java 82 | _ttt.setLayout(new GridLayout(3, 3)); 83 | _newPanel.setLayout(new FlowLayout()); 84 | ``` 85 | 86 | The Grid layout will position any elements (e.g. textboxes, buttons, labels, etc.) in a 3x3 layout. The FlowLayout will just position the elements one after another, like letters in a line of text. Also like a line of text, when no more elements fit, it will go "down" to the next line. 87 | 88 | Now in the constructor, position them like so: 89 | 90 | ```java 91 | 92 | // This will place the tic-tac-toe panel at the top of 93 | // the frame and the newPanel panel at the bottom 94 | _frame.add(_ttt, BorderLayout.NORTH); 95 | _frame.add(_newPanel, BorderLayout.SOUTH); 96 | 97 | ``` 98 | 99 | 100 | Create nine buttons to put in the 3x3 layout and add them. You can do this with a simple for loop: 101 | 102 | ```java 103 | public class TicTacToe { 104 | JButton[] _buttons = new JButton[9]; 105 | ... 106 | ``` 107 | 108 | In the constructor: 109 | 110 | ```java 111 | for (int j=0; j<9; j++) { 112 | // Make a new button in the array location with text "_" 113 | _buttons[j] = new JButton("_"); 114 | // Associate a new ButtonListener to the button (see below) 115 | ActionListener buttonListener = new ButtonListener(); 116 | _buttons[j].addActionListener(buttonListener); 117 | // Set the font on the button 118 | _buttons[j].setFont(new Font("Courier", Font.PLAIN, 48)); 119 | // Add this button to the _ttt panel 120 | _ttt.add(_buttons[j]); 121 | } 122 | ``` 123 | 124 | This will create nine buttons along with their _listeners_ - that is, objects that "listen" for an event to take place, and then execute code when it happens. We will fill in the listeners soon. 125 | 126 | Before you can compile, add a ButtonListener. This can be an internal (non-public) class. In our case, we will start with a button which just changes to X when it is pressed. 127 | 128 | ```java 129 | class ButtonListener implements ActionListener { 130 | 131 | // Every time we click the button, it will perform 132 | // the following action. 133 | 134 | public void actionPerformed(ActionEvent e) { 135 | 136 | JButton source = (JButton) e.getSource(); 137 | String currentText = source.getText(); 138 | if (currentText.equals("_")) { 139 | source.setText("X"); 140 | } else { 141 | source.setText("_"); 142 | } 143 | } 144 | 145 | } 146 | 147 | ``` 148 | 149 | Their default text on the button is `"_"` (the String argument to the JButton constructor). When a user presses a button, the associated ActionListener for the clicked button will have its actionPerformed(ActionEvent e) method called. We associated the listener with our button when we did the `_buttons[j].addActionListener(buttonListener);` statement. Now when a button is pressed, the actionPerformed event actions take place. If the text was a `"_"`, it will be changed to an `"X"`; otherwise, it will be set back to `"_"`. 150 | 151 | Using the above code as a base, create one button and listener for the other panel in the layout (`newPanel`). 152 | 153 | Using the previous steps as a base, create the listener for the "new game" button. It should "erase" all of the buttons, putting them back to their default text when pressed. 154 | 155 | Using the previous steps as a base, create a boolean variable which flip-flops every time somebody presses a button. The first time a button is pressed, the player should be an X, the second time an O, the third time an X, etc. You can determine whether to make the spot an X or O based on this flip-flop variable. 156 | 157 | Finally, add code to ensure that users cannot press a button which is already an X or an O. 158 | 159 | ### Additional Information 160 | 161 | Feel free to take a look at the sample code for these classes to help put the system together: 162 | 163 | 1. Frames - https://github.com/laboon/cs0401/blob/master/sample_code/FrameDemo.java 164 | 1. Panels - https://github.com/laboon/cs0401/blob/master/sample_code/PanelDemo.java and https://github.com/laboon/cs0401/blob/master/sample_code/PanelDemo2.java 165 | 2. Extending Panels - https://github.com/laboon/cs0401/tree/master/sample_code/extended_jpanel 166 | 3. Creating and Interacting with Buttons - https://github.com/laboon/cs0401/blob/master/sample_code/ButtonDemo.java 167 | 4. Creating a Grid Layout - https://github.com/laboon/cs0401/blob/master/sample_code/GridDemo.java 168 | 5. Dynamically Changing A Button - https://github.com/laboon/cs0401/blob/master/sample_code/NameChangeButtonDemo.java 169 | 170 | Remember that part of being a software engineer is knowing how to look things up on your own! If you don't understand how something works, feel free to look at the Java API pages (http://docs.oracle.com/javase/8/docs/api/). 171 | 172 | For fun, you can add code to detect when a player has won or lost. For even more fun, add some artificial intelligence and have the computer play the user! 173 | 174 | You may ask me questions or show me code, but as this an ungraded exercise, you do _not_ need to show me your final product unless you want to do so. 175 | 176 | ``` 177 | GRADING: 178 | UNGRADED EXERCISE 179 | ``` -------------------------------------------------------------------------------- /groups/Class1/Example.md: -------------------------------------------------------------------------------- 1 | # Group Name 2 | 3 | ## Group Slogan! 4 | 5 | ## Group Members: 6 | 7 | 1. Jane Janerson (GitHub username) 8 | 2. Joe Joerson (GitHub username) 9 | 3. Bob Bobberson (GitHub username) 10 | 4. Annie Annerson (GitHub username) -------------------------------------------------------------------------------- /groups/Class1/FantasticFive.md: -------------------------------------------------------------------------------- 1 | # Group Name 2 | Fantastic Five 3 | 4 | ## Group Slogan! 5 | Git me five! 6 | 7 | ## Group Members: 8 | 1. Kenneth Woodruff (kenw1501) 9 | 2. Forrest Wang (CanadianPianoMan) 10 | 3. Nick Taglianetti (nick16754) 11 | 4. Brad Dietz (bdietz56) 12 | 5. Jeremy Patterson (patteronj94) 13 | -------------------------------------------------------------------------------- /groups/Class1/Gumdrop: -------------------------------------------------------------------------------- 1 | # Team Gumdrop 2 | 3 | ## Chemical Engineers Rock!! 4 | 5 | ## Group Members: 6 | 7 | 1. Twesha Mitra (tweshamitra) 8 | 2. Forrest Salamida (fms11) 9 | 3. Addison Beall (slothsenpai) 10 | 4. Jessica Mesler (whitescruffydog) 11 | -------------------------------------------------------------------------------- /groups/Class1/Premature Optimization: -------------------------------------------------------------------------------- 1 | # Group Name 2 | 3 | ## Group Slogan! 4 | 5 | ## Group Members: 6 | 7 | 1. Brandon Hedges (brandonhedges82) 8 | 2. Teg Singh (teg-singh) 9 | 3. Nathan Davidson (nathandavidson) 10 | 4. Julian Monticelli (JulianMonticelli) 11 | 5. Erik Wright (ecwright) 12 | -------------------------------------------------------------------------------- /groups/Class1/TODOComeUpWithTeamName.md: -------------------------------------------------------------------------------- 1 | # TODO: Come Up With Team Name 2 | 3 | ## TODO: Come up with team slogan 4 | 5 | ## Group Members: 6 | 7 | 1. Solomon Astley (solastley) 8 | 2. Kevin Zhang (kzh4ng) 9 | 3. John Linahan (johnlinahan) 10 | 4. Bri Lehman (brianna-lehman) 11 | -------------------------------------------------------------------------------- /groups/Class1/Team: -------------------------------------------------------------------------------- 1 | Team Name:Team Recess 2 | Team Slogan: "What can we code? Can we code things? Let's find out!" 3 | Members: 4 | Maurice Jenkins (mauricej9) 5 | Dannah Gersh (dgtc1012) 6 | Justin Keenan (jak244) 7 | Tim Smith (tsmitty10) 8 | -------------------------------------------------------------------------------- /groups/Class1/Team McTeamFace.md: -------------------------------------------------------------------------------- 1 | # Team McTeamFace 2 | 3 | # Agile is da best 4 | 5 | Nick Bourdakos (bourdakos1) 6 | Malek Ameli-Grillon (malekagr) 7 | Vivek Sen (vas55) 8 | Roger Jordan (rdj14) 9 | -------------------------------------------------------------------------------- /groups/Class1/Team StillMetaName: -------------------------------------------------------------------------------- 1 | # Group Name 2 | Team StillMetaName 3 | 4 | ## Group Slogan! 5 | (we're not creative) 6 | 7 | ## Group Members: 8 | 9 | 1. Sakae Nakahara 10 | 2. Nick Mullen 11 | 3. Matt Damiani 12 | 4. Sai Xu 13 | -------------------------------------------------------------------------------- /groups/Class1/TeamTeamerson.md: -------------------------------------------------------------------------------- 1 | # Team Teamerson 2 | 3 | ## The teammiest team that ever teamed 4 | 5 | ### Group Members 6 | 7 | 1. Joe Rogers (JosephDRogers23) 8 | 2. Alexander Rowden (alex-rowden) 9 | 3. Dan McGrath (djm158) 10 | 4. Brian Dang (bdang) 11 | -------------------------------------------------------------------------------- /groups/Class1/Tha Winged Justice: -------------------------------------------------------------------------------- 1 | # Tha Winged Justice 2 | 3 | ## Generating Wu-Tang Clan names since '96 4 | 5 | ## Group Members: 6 | 7 | 1. Gideon Shils (gideonshils) 8 | 2. William Hinard (wih16) 9 | 3. Joshua Gelenberg (jog93) 10 | 4. Christian Flickinger (cef39) 11 | -------------------------------------------------------------------------------- /groups/Class1/ThaSourPatchKidz.md: -------------------------------------------------------------------------------- 1 | # Tha Sour Patch Kidz 2 | 3 | ## First they're sour, then they're sweet! 4 | 5 | ## Group Members: 6 | 7 | 1. Sarah Bednar sariebeary 8 | 2. Andrew Levandoski andrewlevandoski 9 | 3. Jonathan Lobo JonathanLobo 10 | 4. Alexandra Savage asavage8 11 | -------------------------------------------------------------------------------- /groups/Class1/WorldOfTeam.md: -------------------------------------------------------------------------------- 1 | # World of Team 2 | 3 | ## B) 4 | 5 | ## Group Members: 6 | 7 | 1. Kaitlynn Hetzel (kaitlynnhetzel) 8 | 2. Jill Song (JillSong) 9 | 3. Yueqing Zhang (Yueqing-Zhang) 10 | 4. Ishtar Nyawira (isn4) 11 | -------------------------------------------------------------------------------- /groups/Class1/sourfrittles.md: -------------------------------------------------------------------------------- 1 | # Group Name: Sour Frittles 2 | 3 | ## Group Slogan: Knockoff Candy 4 | 5 | ## Group Members: 6 | 7 | 1. Chris Lagunilla (chrislagunilla) 8 | 2. Shawn Banish (sbanish) 9 | 3. Nick Sallinger (nicksallinger) 10 | 4. Spencer Young (spencerjyoung) 11 | -------------------------------------------------------------------------------- /groups/Class3/Anton Did Nothing Wrong.md: -------------------------------------------------------------------------------- 1 | # Anton Did Nothing Wrong 2 | 3 | ## See above. 4 | 5 | ## Group Members: 6 | 7 | 1. Colin Mason (masonc15) 8 | 2. Ben Kristofic (benkristofic) 9 | 3. Anton Ozaeta (aro24) 10 | 4. Tim Hartman (thartman77) 11 | -------------------------------------------------------------------------------- /groups/Class3/BitsPlease.md: -------------------------------------------------------------------------------- 1 | # BitsPlease 2 | 3 | ## More fun than a pillow fight! 4 | 5 | ## Group Members: 6 | 1. Benjamin Muscato (BenjaminMuscato) 7 | 2. Wyatt Borsos (BorsosWyatt) 8 | 3. Kevin Good (Zekimar) 9 | 4. John Dott (jkd28) 10 | 5. Brian Knotten (BK874) 11 | -------------------------------------------------------------------------------- /groups/Class3/Communism.md: -------------------------------------------------------------------------------- 1 | # Group Name 2 | Communism 3 | 4 | ## Group Slogan 5 | Пролетарии всех стран, соединяйтесь! 6 | 7 | ## Group Members 8 | 1. David Rocker (rockaflacka47) 9 | 2. Dalton Scharff (daltonscharff) 10 | 3. Signe Ruprecht (signeruprecht) 11 | 4. Conor Lamb (pere5troika) 12 | -------------------------------------------------------------------------------- /groups/Class3/Cronenbergs.md: -------------------------------------------------------------------------------- 1 | # Cronenberg 2 | 3 | ## I'm Pickle Riiiick! 4 | 5 | 1. Joshua Rodstein (JoshRodstein) 6 | 2. Mike Smith (15mikesmith) 7 | 3. Ben Anderson (benanders0n) 8 | 4. Jack Halloran (j-halloran) 9 | -------------------------------------------------------------------------------- /groups/Class3/D3S.md: -------------------------------------------------------------------------------- 1 | # D3S 2 | 3 | ## Because we are all S'd 4 | 5 | 1. Ahmed Abdelsalam (duramater) 6 | 2. Sharif Abdelbaky (sharif6178) 7 | 3. Stephen Snow (stephen-snow) 8 | 4. Sumanyu Gupta (sumanyugupta) 9 | -------------------------------------------------------------------------------- /groups/Class3/Example.md: -------------------------------------------------------------------------------- 1 | # Group Name 2 | 3 | ## Group Slogan! 4 | 5 | ## Group Members: 6 | 7 | 1. Jane Janerson (GitHub username) 8 | 2. Joe Joerson (GitHub username) 9 | 3. Bob Bobberson (GitHub username) 10 | 4. Annie Annerson (GitHub username) -------------------------------------------------------------------------------- /groups/Class3/FightingFooBars.md: -------------------------------------------------------------------------------- 1 | # FightingFooBars 2 | 3 | ## Do you mind if I keep my trombone here? 4 | 5 | 1. Marcus Dubreuil (marcdubs) 6 | 2. Steve Hardy (fatcat32594) 7 | 3. Ethan Defrank (ethandefrank) 8 | 4. Eric Grasso (erg52) 9 | -------------------------------------------------------------------------------- /groups/Class3/FileFormatExceptions.md: -------------------------------------------------------------------------------- 1 | #FileFormatExceptions 2 | 3 | ##We're never formatted correctly. 4 | 5 | ##Group Members: 6 | 7 | 1. Ryan Catalogna (ryan-cat) 8 | 2. Kyle Sucro (ksucro) 9 | 3. Zinan Zhuang (ziz19) 10 | 4. Bin Dong (bindong132) 11 | -------------------------------------------------------------------------------- /groups/Class3/FiveGuys.md: -------------------------------------------------------------------------------- 1 | # Five Guys 2 | # Slogan 3 | "Make CS great again!" 4 | 5 | # Group Members: 6 | 1. Matthew Hoesch (matthewhoesch) 7 | 2. Luke Kraus (lukekraus45) 8 | 3. Timotheus Hinton (tgh22) 9 | 4. James Misner (JimmyMiz9) 10 | 5. Kevin Madison (kevinmadison) 11 | 12 | -------------------------------------------------------------------------------- /groups/Class3/SennottSquareSUPERCoders.md: -------------------------------------------------------------------------------- 1 | #SennottSquareSUPERCoders 2 | 3 | ##Floors 1 through 4 are irrelevant 4 | 5 | Leonard Maynard (lhmaynard) 6 | Zach Mell (zacharymell) 7 | Kevin Moore (KMoore21) 8 | Brandon Palonis (brandonp728) 9 | -------------------------------------------------------------------------------- /groups/Class3/SugarPlumFairies.md: -------------------------------------------------------------------------------- 1 | # Sugar Plum Fairies 2 | 3 | ## Sugar and Spice and Everything Nice 4 | 5 | 1. Scott Crawford (Scott-Crawford) 6 | 2. Jacob Bader (jsb99) 7 | 3. Alexa Swihart (alexaswihart) 8 | 4. Alec Brumbaugh (abrumbaugh) 9 | -------------------------------------------------------------------------------- /groups/Class3/TheTestGroup.md: -------------------------------------------------------------------------------- 1 | # The Test Group 2 | 3 | ## Please Ignore! 4 | 5 | ## Group Members: 6 | 7 | 1. Colton Blake ([coltonb](https://github.com/coltonb)) 8 | 2. Raj Patel ([rpp25](https://github.com/rpp25)) 9 | 3. Randyll Bearer ([rlb97](https://github.com/rlb97)) 10 | 4. James Finkel ([jaf177](https://github.com/jaf177)) 11 | -------------------------------------------------------------------------------- /groups/Class3/longNerdsRope.md: -------------------------------------------------------------------------------- 1 | # Group Name 2 | long nerdsRope 3 | ## Slogan 4 | Literally Taking Candy From a Baby 5 | 6 | ## Group Members 7 | 8 | 1. Amani Johnson (akj26) 9 | 2. Alex Coroi (coroialexander) 10 | 3. Sam Nosenzo (snosenzo) 11 | 4. Brian Amaratunga (tunga153) 12 | -------------------------------------------------------------------------------- /lectures/CS1530_Lecture10_ProjectManagement.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture10_ProjectManagement.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture11_Implementation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture11_Implementation.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture12_GradleBuildTool.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture12_GradleBuildTool.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture13_QA_Quality_Software.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture13_QA_Quality_Software.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture14_TacticalSoftwareDesign.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture14_TacticalSoftwareDesign.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture15_Concurrency.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture15_Concurrency.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture16_Integration.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture16_Integration.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture17_Legacy_Code.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture17_Legacy_Code.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture18_SoftwareEngineeringTradeoffs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture18_SoftwareEngineeringTradeoffs.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture19_SoftwareCraftsmanship.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture19_SoftwareCraftsmanship.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture2_SDLC.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture2_SDLC.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture3_Building_A_Software_System.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture3_Building_A_Software_System.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture4_Principles.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture4_Principles.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture5_Methodologies.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture5_Methodologies.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture6_AgileScrum.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture6_AgileScrum.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture7_RequirementsEngineering.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture7_RequirementsEngineering.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture8_SoftwareDesignArchitecture.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture8_SoftwareDesignArchitecture.pdf -------------------------------------------------------------------------------- /lectures/CS1530_Lecture9_DetailedDesign.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/laboon/CS1530_Fall2017/ebc887364f5e6e793b65196473e256f6e41ba7e2/lectures/CS1530_Lecture9_DetailedDesign.pdf -------------------------------------------------------------------------------- /reading-quizzes/answers.md: -------------------------------------------------------------------------------- 1 | # Answer Key for Reading Quizzes 2 | 3 | ## RQ1 4 | 5 | 1. Joy of making things, making things useful for others, always learning, etc. 6 | 2. 105 7 | 3. Adding engineers to a late software project makes it later 8 | 4. Design constraint, because it refers to the technical aspects of the system (how it should do it) as opposed to what the system should do 9 | 5. Effort estimation and schedule, Assignments and communications 10 | 11 | ## RQ2 12 | 13 | 1. Code errors (coding errors, errors of code, etc. are all acceptable) 14 | 2. Requirements phase. Reasons: Because errors can propagate throughout the system, one requirement error can turn into several design/implementation errors, cheaper/faster to fix requirements errors, should be problem-preventative, quicker to test, better to find errors earlier so that they have less impact. 15 | 3. Respect others and strive for fairness, Perform to one's best capability, Follow the law 16 | 4. A description of any interaction between the system software and something external 17 | 5. Optimizing (Level 5) Three key processes: Defect prevention, Technology change management, Process change management 18 | 19 | ## RQ3 20 | 21 | 1. The product owner is the voice of the customer, represents the customer and their wants and needs. 22 | 2. Product backlog, sprint backlog, increment, burndown chart 23 | 3. Agile methodologies have more frequent, crucial, ongoing communication with customers. Traditional methodologies tend to have less frequent communication, with most, if not all, communication at the beginning and end of the software development process. 24 | 4. Requirements analysts need to be able to translate between the domain which the software is written for, and the technical team. They require good industry domain knowledge and communication skills which are not often found in junior 25 | 5. An actor refers to all external interfaces to the system (human users, other systems, etc.) 26 | 27 | ## RQ4 28 | 29 | 1. Yes, every system has a software architecture. If a system exists, it has some architecture, even if it is informal or undocumented. 30 | 2. Event-driven architecture. Its primary method of operation is responding to events. (I will accept client-server since the server operates fundamentally differently than the attached clients) 31 | 3. Database-centric, since it is focused on data storage. (I will also accept client-server since data is stored on a central server and clients access it, or MVC if you assume it is web-based as I mentioned that many web frameworks use MVC) 32 | 4. Content coupling is a very tight coupling. This can lead to changes in one leaking over to another, hard to localize fixes, hard to re-use the code elsewhere. 33 | 5. Procedural cohesion. I would also accept communicational, sequential, or functional since they are also "procedural plus". 34 | 35 | ## RQ5 36 | 37 | 1. Planning, Organizing, Monitoring, Adjusting 38 | 2. Total person-days = 1120 39 | 3. Refactoring 40 | 4. Repeat of the code 41 | 5. (several answers possible here, just need one: performance optimization reduces readability/maintainability, commenting increases readability but increases cost of maintaining, a more secure system often makes it less usable, etc. There are lots of possibilities!) -------------------------------------------------------------------------------- /reading-quizzes/quiz1.md: -------------------------------------------------------------------------------- 1 | Name: `____________________________________` Class start time: `_____________` 2 | 3 | 1. According to Fred Brooks, what are three _joys_ of programming, that is, things that make it fun? 4 | 5 | ``` 6 | ____________________________________ 7 | 8 | ____________________________________ 9 | 10 | ____________________________________ 11 | ``` 12 | 13 | 2. If you have a team of 15 people, assuming intercommunication between all of them, how many pairwise communication channels are there on your team? (I am looking for a specific number, not a formula) 14 | 15 | ``` 16 | ____________________________________ 17 | ``` 18 | 19 | 3. What is Brooks's Law? 20 | 21 | ``` 22 | ________________________________________________________________________ 23 | 24 | ________________________________________________________________________ 25 | 26 | ________________________________________________________________________ 27 | 28 | ``` 29 | 30 | 4. "The system shall be able to run on Linux, FreeBSD, and OpenBSD systems." Is this an example of a program requirement or design constraint? Why? 31 | 32 | ``` 33 | ________________________________________________________________________ 34 | 35 | ________________________________________________________________________ 36 | 37 | ________________________________________________________________________ 38 | 39 | ``` 40 | 41 | 5. What are two __nontechnical__ considerations of software development and support covered by Tsui _et al_? 42 | 43 | ``` 44 | ________________________________________________________________________ 45 | 46 | ________________________________________________________________________ 47 | ``` -------------------------------------------------------------------------------- /reading-quizzes/quiz2.md: -------------------------------------------------------------------------------- 1 | Name: `____________________________________` Class start time: `_____________` 2 | 3 | 1. According to Jones (2008), as referenced in Tsui _et al_, what is most common origin of bugs? 4 | 5 | ``` 6 | ____________________________________ 7 | 8 | ``` 9 | 10 | 2. Which phase of software development do Tsui _et al_ recommend that we spend more time on? Why this phase, and not the phase that is the most common origin of bugs? 11 | 12 | ``` 13 | ________________________________________________________________________ 14 | 15 | ________________________________________________________________________ 16 | 17 | ________________________________________________________________________ 18 | 19 | ``` 20 | 21 | 22 | 3. The author summed up ethical professional behavior as a software engineer into three values/guidelines. What are they? 23 | 24 | ``` 25 | ________________________________________________________________________ 26 | 27 | ________________________________________________________________________ 28 | 29 | ________________________________________________________________________ 30 | 31 | ``` 32 | 33 | 4. What is a use case, as described as part of the RUP framework? 34 | 35 | ``` 36 | ________________________________________________________________________ 37 | 38 | ________________________________________________________________________ 39 | 40 | ________________________________________________________________________ 41 | 42 | ``` 43 | 44 | 5. What is the highest level of CMM? What three key processes must be included in it? 45 | 46 | ``` 47 | ________________________________________________________________________ 48 | 49 | ________________________________________________________________________ 50 | 51 | ________________________________________________________________________ 52 | 53 | ________________________________________________________________________ 54 | 55 | ``` -------------------------------------------------------------------------------- /reading-quizzes/quiz3.md: -------------------------------------------------------------------------------- 1 | Name: `____________________________________` Class start time: `_____________` 2 | 3 | 1. In Agile/Scrum development, describe the role of the product owner. 4 | 5 | ``` 6 | ________________________________________________________________________ 7 | 8 | ________________________________________________________________________ 9 | 10 | ________________________________________________________________________ 11 | 12 | ``` 13 | 14 | 2. What are four artifacts defined by the Scrum process? 15 | 16 | ``` 17 | ________________________________________________________________________ 18 | 19 | ________________________________________________________________________ 20 | 21 | ________________________________________________________________________ 22 | 23 | ________________________________________________________________________ 24 | ``` 25 | 26 | 3. In regards to user involvement, explain the difference between Agile methodologies and traditional/heavyweight methodologies. 27 | 28 | ``` 29 | ________________________________________________________________________ 30 | 31 | ________________________________________________________________________ 32 | 33 | ________________________________________________________________________ 34 | 35 | ``` 36 | 37 | 4. Why are very few requirements analysts entry-level engineers? 38 | 39 | ``` 40 | ________________________________________________________________________ 41 | 42 | ________________________________________________________________________ 43 | 44 | ________________________________________________________________________ 45 | 46 | ``` 47 | 48 | 5. When developing object-oriented use cases, what is an _actor_? 49 | 50 | ``` 51 | ________________________________________________________________________ 52 | 53 | ________________________________________________________________________ 54 | 55 | ________________________________________________________________________ 56 | 57 | ``` -------------------------------------------------------------------------------- /reading-quizzes/quiz4.md: -------------------------------------------------------------------------------- 1 | Name: `____________________________________` Class start time: `_____________` 2 | 3 | 1. Does every software system have an architecture? Why or why not? 4 | 5 | ``` 6 | ________________________________________________________________________ 7 | 8 | ________________________________________________________________________ 9 | 10 | ________________________________________________________________________ 11 | 12 | ``` 13 | 14 | 2. You are designing a climate control system, which accepts inputs from a variety of distributed sensors (e.g., thermometers, smoke sensors, barometers, etc.), and normalizes environmental conditions based on this input. For example, if average temperature is below a threshold, the heater will be turned on. Occasional input needs to be responded to immediately; for example, a smoke sensor detecting particulate matter may set off a fire alarm immediately. 15 | 16 | Of the architectural styles listed in Tsui _et al_, which one would be best for this kind of system? Why? 17 | 18 | ``` 19 | ________________________________________________________________________ 20 | 21 | ________________________________________________________________________ 22 | 23 | ________________________________________________________________________ 24 | 25 | ________________________________________________________________________ 26 | 27 | ________________________________________________________________________ 28 | ``` 29 | 30 | 3. You are designing a system to store classes so that students can view information on the classes available for the next semester. There is little to no business logic associated with this system. The focus is just on storing and viewing (and for administrators, occasionally adding) data to the system. 31 | 32 | Of the architectural styles listed in Tsui _et al_, which one would be best for this kind of system? Why? 33 | 34 | ``` 35 | ________________________________________________________________________ 36 | 37 | ________________________________________________________________________ 38 | 39 | ________________________________________________________________________ 40 | 41 | ________________________________________________________________________ 42 | 43 | ________________________________________________________________________ 44 | 45 | ``` 46 | 47 | 4. After reviewing your system design, your co-worker notes that you have two classes with content coupling. Why is this problematic? 48 | 49 | ``` 50 | ________________________________________________________________________ 51 | 52 | ________________________________________________________________________ 53 | 54 | ________________________________________________________________________ 55 | 56 | ``` 57 | 58 | 5. You have written a class whose methods are all related in terms of some control sequence. What level of cohesion is this? 59 | 60 | ``` 61 | ________________________________________________________________________ 62 | 63 | ``` -------------------------------------------------------------------------------- /reading-quizzes/quiz5.md: -------------------------------------------------------------------------------- 1 | Name: `____________________________________` Class start time: `_____________` 2 | 3 | 1. According to Tsui _et al_, what are the four major sets of activities in the software project management process? 4 | 5 | ``` 6 | ________________________________________________________________________ 7 | 8 | ________________________________________________________________________ 9 | 10 | ________________________________________________________________________ 11 | 12 | ________________________________________________________________________ 13 | 14 | ``` 15 | 16 | 2. You are developing a system which you estimate will need 20 classes. There will be one very simple GUI interface. Based on previous productivity of your team, it takes 16 person-days to fully develop one class. 17 | 18 | Using the Lorenz-Kidd OO estimation technique, estimate how long it will take (in person-days) to complete the project. Show your work. 19 | 20 | ``` 21 | ________________________________________________________________________ 22 | 23 | ________________________________________________________________________ 24 | 25 | ________________________________________________________________________ 26 | 27 | ________________________________________________________________________ 28 | 29 | ________________________________________________________________________ 30 | ``` 31 | 32 | 3. In your code, you have a very long method, `extrapolateDucksAndFish()`. Reviewing the code, you are able to deconstruct it so that the method calls three new, shorter methods, `initializeAnimals()`, `extrapolateDucks()`, and `extrapolateFish()`. In the process, you are also able to remove some duplicate code, leading to an overall reduction of 35% in terms of lines of code, without changing any of the functionality. 33 | 34 | What is the name of the process that you just did? 35 | 36 | ``` 37 | ________________________________________________________________________ 38 | 39 | ``` 40 | 41 | 4. According to Tsui _et al_, what is the one kind of comment which should _not_ be used? 42 | 43 | ``` 44 | ________________________________________________________________________ 45 | 46 | ``` 47 | 48 | 5. Name one instance of a trade-off in implementation characteristics (e.g. making the system/code more X makes the system less Y). 49 | 50 | ``` 51 | ________________________________________________________________________ 52 | 53 | ________________________________________________________________________ 54 | 55 | ________________________________________________________________________ 56 | 57 | ``` -------------------------------------------------------------------------------- /sample_code/VarReuse.java: -------------------------------------------------------------------------------- 1 | public class VarReuse { 2 | 3 | // REDUCE VARIABLE SCOPE 4 | // ELIMINATE VARIABLE RE-USE 5 | 6 | public static void main(String[] args) { 7 | int j = 1; 8 | System.out.println("Count from 1 to 10"); 9 | for (; j <= 10; j++) { 10 | System.out.println("j is " + j); 11 | } 12 | 13 | System.out.println("And count from 1 to 10 again!"); 14 | for (j = 1; j <= 10; j++) { 15 | System.out.println("j is " + j); 16 | } 17 | 18 | } 19 | } 20 | -------------------------------------------------------------------------------- /sample_code/Warning.java: -------------------------------------------------------------------------------- 1 | import java.util.ArrayList; 2 | 3 | 4 | 5 | public class Warning { 6 | 7 | 8 | public static void main(String[] args) { 9 | ArrayList al = new ArrayList(); 10 | for (String arg : args) { 11 | al.add(arg); 12 | } 13 | 14 | al.add(new Darble()); 15 | 16 | int c = 0; 17 | 18 | for (Object a : al) { 19 | c += Integer.parseInt((String) a); 20 | } 21 | } 22 | 23 | 24 | } 25 | 26 | class Darble { 27 | } 28 | -------------------------------------------------------------------------------- /sample_code/complexity/Foo2.bytecode: -------------------------------------------------------------------------------- 1 | Compiled from "Foo2.java" 2 | public class Foo2 { 3 | public Foo2(); 4 | Code: 5 | 0: aload_0 6 | 1: invokespecial #1 // Method java/lang/Object."":()V 7 | 4: return 8 | 9 | public static void main(java.lang.String[]); 10 | Code: 11 | 0: iconst_0 12 | 1: istore_1 13 | 2: iconst_0 14 | 3: istore_2 15 | 4: iload_2 16 | 5: bipush 10 17 | 7: if_icmpge 52 18 | 10: iload_2 19 | 11: iconst_2 20 | 12: imul 21 | 13: istore_1 22 | 14: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 23 | 17: new #3 // class java/lang/StringBuilder 24 | 20: dup 25 | 21: invokespecial #4 // Method java/lang/StringBuilder."":()V 26 | 24: iload_2 27 | 25: invokevirtual #5 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder; 28 | 28: ldc #6 // String doubled is 29 | 30: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 30 | 33: invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String; 31 | 36: invokevirtual #9 // Method java/io/PrintStream.print:(Ljava/lang/String;)V 32 | 39: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 33 | 42: iload_1 34 | 43: invokevirtual #10 // Method java/io/PrintStream.println:(I)V 35 | 46: iinc 2, 1 36 | 49: goto 4 37 | 52: return 38 | } 39 | -------------------------------------------------------------------------------- /sample_code/complexity/Foo2.java: -------------------------------------------------------------------------------- 1 | public class Foo2 { 2 | 3 | public static void main(String[] args) { 4 | int i = 0; 5 | for (int j = 0; j < 10; j++) { 6 | i = j * 2; 7 | System.out.print(j + " doubled is "); 8 | System.out.println(i); 9 | } 10 | } 11 | } 12 | -------------------------------------------------------------------------------- /sample_code/complexity/README.md: -------------------------------------------------------------------------------- 1 | # Reproduction Instructions 2 | 3 | Don't take my word for it, you can make these yourself! 4 | 5 | ### Generate human-readable bytecode 6 | 7 | ``` 8 | javac Foo2.java 9 | javap -c Foo2.class > Foo2.bytecode 10 | ``` 11 | 12 | ### Generate human-readable assembly 13 | 14 | _Note: you may need to download or build the file hsdis-amd64.dylib for your Java version._ 15 | 16 | ``` 17 | javac Foo2.java 18 | java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly Foo2 > Foo2.asm 19 | ``` -------------------------------------------------------------------------------- /sample_code/concurrency/Atomic.java: -------------------------------------------------------------------------------- 1 | import java.util.concurrent.atomic.*; 2 | 3 | public class Atomic { 4 | 5 | // Atomic version of Long class 6 | // Note that there are lots of Atomic variants - 7 | // AtomicBoolean, AtomicLongArray, AtomicInteger, etc. 8 | // See https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html 9 | 10 | public static AtomicLong _a = new AtomicLong(5); 11 | 12 | // Our unsynchronized long 13 | 14 | public static Long _l = new Long(5); 15 | 16 | // Our synchronized Long 17 | 18 | public static Long _sl = new Long(5); 19 | 20 | public static final long NUM_TIMES = 100000; 21 | 22 | public static void main(String[] args) { 23 | 24 | Object lock2 = new Object(); 25 | 26 | Thread t1 = new Thread(() -> { 27 | for (int j = 0; j < NUM_TIMES; j++) { 28 | // Note that our API is slightly different 29 | // for Atomic* types! 30 | // Allow us to do multiple things atomically 31 | // Also note this method returns the new value 32 | // but we are implicitly throwing it away 33 | // synchronized(lock2) { 34 | _a.incrementAndGet(); 35 | // } 36 | } 37 | }); 38 | 39 | Thread t2 = new Thread(() -> { 40 | for (int j = 0; j < NUM_TIMES; j++) { 41 | // synchronized(lock2) { 42 | _a.decrementAndGet(); 43 | // } 44 | } 45 | }); 46 | try { 47 | t1.start(); 48 | t2.start(); 49 | t1.join(); 50 | t2.join(); 51 | } catch (InterruptedException iex) { } 52 | System.out.println("Atomic long is: " + _a); 53 | // System.exit(0); 54 | // Do the same thing, with a regular Long 55 | 56 | Thread t3 = new Thread(() -> { 57 | for (int j = 0; j < NUM_TIMES; j++) { 58 | // No way to perform an increment atomically 59 | // on long 60 | _l++; 61 | } 62 | }); 63 | 64 | Thread t4 = new Thread(() -> { 65 | for (int j = 0; j < NUM_TIMES; j++) { 66 | _l--; 67 | } 68 | }); 69 | 70 | try { 71 | t3.start(); 72 | t4.start(); 73 | t3.join(); 74 | t4.join(); 75 | } catch (InterruptedException iex) { } 76 | 77 | System.out.println("Regular long is: " + _l); 78 | // System.exit(0); 79 | // We CAN use a regular Long, but we will need to make sure 80 | // that we synchronize on some shared object 81 | 82 | // Note that there is now the chance for error since we a 83 | // are forced to remember to synchronize EVERY time we use 84 | // that variable! And remember what to sync on! 85 | 86 | Object lock = new Object(); 87 | 88 | Thread t5 = new Thread(() -> { 89 | for (int j = 0; j < NUM_TIMES; j++) { 90 | // Note that we are synchronizing on a 91 | // RELEVANT object (_l) instead of just 92 | // a random one as we did when I 93 | // introduced locking and synchronization 94 | 95 | synchronized(lock) { 96 | _sl += 1; 97 | } 98 | } 99 | }); 100 | 101 | Thread t6 = new Thread(() -> { 102 | for (int j = 0; j < NUM_TIMES; j++) { 103 | synchronized(lock) { 104 | _sl -= 1; 105 | } 106 | } 107 | }); 108 | 109 | try { 110 | t5.start(); 111 | t6.start(); 112 | t5.join(); 113 | t6.join(); 114 | } catch (InterruptedException iex) { } 115 | 116 | 117 | // Print out results 118 | 119 | System.out.println("Synchronized long is: " + _sl); 120 | 121 | 122 | } 123 | } 124 | -------------------------------------------------------------------------------- /sample_code/concurrency/BadConcurrency.java: -------------------------------------------------------------------------------- 1 | public class BadConcurrency { 2 | 3 | public static int x = 0; 4 | 5 | public static final int NUM_TIMES = 100000; 6 | 7 | public static void main(String[] args) { 8 | 9 | // Start thread 1, which will add 100,000 to x 10 | 11 | Thread t1 = new Thread(() -> { 12 | for (int j = 0; j < NUM_TIMES; j++) { 13 | x++; 14 | } 15 | }); 16 | 17 | // Start thread 2, which will subtract 100,000 from x 18 | 19 | Thread t2 = new Thread(() -> { 20 | for (int j = 0; j < NUM_TIMES; j++) { 21 | x--; 22 | } 23 | }); 24 | 25 | // Start off both threads 26 | t1.start(); 27 | t2.start(); 28 | 29 | // Wait for both to finish 30 | 31 | try { 32 | t1.join(); 33 | t2.join(); 34 | } catch (InterruptedException iex) { } 35 | 36 | // Print out final result - we have done x++ 37 | // and x-- the same number of times 38 | 39 | System.out.println("x is now " + x); 40 | 41 | } 42 | } 43 | -------------------------------------------------------------------------------- /sample_code/concurrency/BetterConcurrency.java: -------------------------------------------------------------------------------- 1 | // In this case, every time we increment or decrement x, 2 | // we ensure that is an ATOMIC operation. 3 | // Either t1 or t2 has the lock on Object ref, 4 | // but never both, so they will never interleave. 5 | 6 | public class BetterConcurrency { 7 | 8 | public static int x = 0; 9 | 10 | public static final int NUM_TIMES = 100000; 11 | 12 | public static void main(String[] args) { 13 | 14 | final Object ref = new Object(); 15 | 16 | Thread t1 = new Thread(() -> { 17 | for (int j = 0; j < NUM_TIMES; j++) { 18 | synchronized(ref) { 19 | x++; 20 | } 21 | } 22 | }); 23 | Thread t2 = new Thread(() -> { 24 | for (int j = 0; j < NUM_TIMES; j++) { 25 | synchronized(ref) { 26 | x--; 27 | } 28 | } 29 | }); 30 | 31 | // Start off both threads 32 | t1.start(); 33 | t2.start(); 34 | 35 | // Wait for both to finish 36 | 37 | try { 38 | t1.join(); 39 | t2.join(); 40 | } catch (InterruptedException iex) { } 41 | 42 | // Print out final result - we have done x++ 10000 times 43 | // and x-- 10000 times 44 | 45 | System.out.println("x is now " + x); 46 | 47 | } 48 | } 49 | -------------------------------------------------------------------------------- /sample_code/concurrency/ConcurrentCalculator.java: -------------------------------------------------------------------------------- 1 | import java.util.*; 2 | 3 | // Perform the same calculations as we did in the SynchronousCalculator, 4 | // but this time using threads 5 | 6 | // For explanation of different performance characteristics, see 7 | // Amdahl's Law - https://en.wikipedia.org/wiki/Amdahl%27s_law 8 | // This is an "embarassingly parallel" problem 9 | 10 | public class ConcurrentCalculator { 11 | 12 | /** 13 | * Helper method for printing out arrays. 14 | * @param int[] arr Array of integers to print 15 | */ 16 | public static void printArray(int[] arr) { 17 | System.out.print("[ "); 18 | for (int j=0; j < (arr.length - 1); j++) { 19 | System.out.print(arr[j] + ", "); 20 | } 21 | if (arr.length > 0) { 22 | System.out.print(arr[arr.length - 1]); 23 | } 24 | System.out.println(" ]"); 25 | 26 | } 27 | 28 | /** 29 | * Generate initial array, where location 0 has 30 | * value 0, location 1 value 1, etc. 31 | */ 32 | 33 | private static int[] generateInitialArray(int n) { 34 | int[] toReturn = new int[n]; 35 | for (int j = 0; j < n; j++) { 36 | toReturn[j] = j; 37 | } 38 | return toReturn; 39 | } 40 | 41 | /** 42 | * Placeholder for complex calculation 43 | */ 44 | 45 | private static int calculate(int n) { 46 | int x = n; 47 | for (int j = 0; j < 100000; j++) { 48 | for (int k = 0; k < 20; k++) { 49 | x += k * Math.atan(n); 50 | } 51 | x += Math.acos(n); 52 | x -= j * Math.sin(n); 53 | } 54 | return x; 55 | } 56 | 57 | 58 | public static void main(String[] args) { 59 | 60 | int n = -1; 61 | 62 | try { 63 | n = Integer.parseInt(args[0]); 64 | if (n < 1) { 65 | throw new Exception(); 66 | } 67 | } catch (Exception ex) { 68 | System.out.println("Expected positive int as argument!"); 69 | System.exit(1); 70 | } 71 | 72 | int[] initialArray = generateInitialArray(n); 73 | final int[] newArray = new int[initialArray.length]; 74 | 75 | printArray(initialArray); 76 | 77 | // Create an array which will hold n threads. 78 | 79 | Thread[] ts = new Thread[n]; 80 | 81 | for (int j = 0; j < initialArray.length; j++) { 82 | 83 | // Any external variables we access in a lambda must be final 84 | // Since j will never need to be modified by the lambda, it's 85 | // fine to just make a final version of it. 86 | 87 | final int fj = j; 88 | 89 | // For each element, create a new thread with a Runnable lambda. 90 | // Note that this is very similar to defining an "anonymous method" 91 | 92 | ts[fj] = new Thread(() -> 93 | { 94 | newArray[fj] = calculate(initialArray[fj]); 95 | System.out.println("Finished calculating " + fj); 96 | 97 | }); 98 | 99 | // We have now created a thread and it is ready to work, but not doing 100 | // anything yet! 101 | } 102 | try { 103 | 104 | // Start each individual thread to calculate. 105 | 106 | for (Thread t : ts) t.start(); 107 | 108 | // All threads must be complete before any further progress in our 109 | // main thread. What do you think will happen if we comment this out? 110 | // Note that if you do comment it out, the compiler will yell about 111 | // our try catch block since no InterruptedException is thrown in the block. 112 | // It's OK if we just catch a generic Exception since a generic Exception 113 | // could theoretically be thrown at any point. 114 | 115 | for (Thread t : ts) t.join(); 116 | 117 | // } catch (Exception iex) { } 118 | } catch (InterruptedException iex) { } 119 | 120 | printArray(newArray); 121 | 122 | } 123 | } 124 | -------------------------------------------------------------------------------- /sample_code/concurrency/ConcurrentHashMapDemo.java: -------------------------------------------------------------------------------- 1 | import java.util.concurrent.ConcurrentHashMap; 2 | 3 | public class ConcurrentHashMapDemo { 4 | 5 | public static void main(String[] args) { 6 | 7 | // Remember hashes are key-value pairs 8 | // e.g. animal id number to noise it makes 9 | // 1 -> "meow" 10 | // 17 -> "moo" 11 | // 4 -> "cluck" 12 | // Can be in any order, can be gaps 13 | 14 | ConcurrentHashMap h = new ConcurrentHashMap(); 15 | 16 | final int NUM_TIMES = 9999999; 17 | 18 | for (int j = 0; j < NUM_TIMES; j++) { 19 | h.put(j, "chirp"); 20 | } 21 | 22 | for (int j = 0; j < NUM_TIMES; j++) { 23 | h.remove(j); 24 | } 25 | 26 | System.out.println("Final size of hash is " + h.size()); 27 | 28 | } 29 | } 30 | -------------------------------------------------------------------------------- /sample_code/concurrency/ConstructorConcurrency.java: -------------------------------------------------------------------------------- 1 | public class ConstructorConcurrency { 2 | 3 | public static int foo = 0; 4 | 5 | public static Object ref = new Object(); 6 | 7 | public ConstructorConcurrency() { 8 | // synchronized(ref) { 9 | foo++; 10 | // } 11 | } 12 | 13 | public static void main(String[] args) { 14 | 15 | final int NUM_TIMES = 1000; 16 | 17 | Thread[] ts = new Thread[NUM_TIMES]; 18 | 19 | for (int j = 0; j < NUM_TIMES; j++) { 20 | Thread t = new Thread( () -> { 21 | for (int k = 0; k < 10; k++) { 22 | new ConstructorConcurrency(); 23 | // try { 24 | // Thread.sleep(10); 25 | // } catch (InterruptedException iex) { 26 | // } 27 | } 28 | }); 29 | ts[j] = t; 30 | } 31 | 32 | for (int j = 0; j < NUM_TIMES; j++) { 33 | ts[j].start(); 34 | } 35 | 36 | for (int j = 0; j < NUM_TIMES; j++) { 37 | try { 38 | ts[j].join(); 39 | } catch (InterruptedException iex) { 40 | System.out.println("lol"); 41 | } 42 | } 43 | 44 | System.out.println("foo is " + foo); 45 | 46 | } 47 | } 48 | -------------------------------------------------------------------------------- /sample_code/concurrency/DavidConcurrency.java: -------------------------------------------------------------------------------- 1 | // In this case, every time we increment or decrement x, 2 | // we ensure that is an ATOMIC operation. 3 | // Either t1 or t2 has the lock on Object ref, 4 | // but never both, so they will never interleave. 5 | 6 | public class DavidConcurrency { 7 | 8 | public static int x = 0; 9 | 10 | public static final int NUM_TIMES = Integer.MAX_VALUE; 11 | 12 | public static void main(String[] args) { 13 | 14 | for (int j = 0; j < NUM_TIMES; j++) { 15 | x++; 16 | } 17 | 18 | for (int j = 0; j < NUM_TIMES; j++) { 19 | x--; 20 | } 21 | 22 | // Print out final result - we have done x++ 10000 times 23 | // and x-- 10000 times 24 | 25 | System.out.println("x is now " + x); 26 | 27 | } 28 | } 29 | -------------------------------------------------------------------------------- /sample_code/concurrency/Deadlock.java: -------------------------------------------------------------------------------- 1 | // A demonstration of deadlock 2 | 3 | public class Deadlock { 4 | 5 | // We have two resources to lock on, printer and scanner 6 | 7 | public static Printer printer = new Printer(); 8 | 9 | public static Scanner scanner = new Scanner(); 10 | 11 | public static void main(String[] args) { 12 | 13 | // Thread 1 is going to attempt to get the printer first, then scanner 14 | // Thread 2 is going to attempt to get the scanner first, then printer 15 | 16 | // Thread 1 gets printer 17 | // Thread 2 gets scanner 18 | // Thread 1 is now waiting for the scanner to be free 19 | // Thread 2 is now waiting for the printer to be free 20 | // Neither will ever be! Each is waiting for the other 21 | 22 | Thread t1 = new Thread(() -> { 23 | synchronized(printer) { 24 | printer.print("thread 1"); 25 | try { 26 | Thread.sleep(100); 27 | } catch (InterruptedException iex) {} 28 | 29 | synchronized(scanner) { 30 | scanner.scan("thread 1"); 31 | try { 32 | Thread.sleep(100); 33 | } catch (InterruptedException iex) {} 34 | 35 | 36 | } 37 | } 38 | }); 39 | 40 | Thread t2 = new Thread(() -> { 41 | synchronized(scanner) { 42 | scanner.scan("thread 2"); 43 | try { 44 | Thread.sleep(100); 45 | } catch (InterruptedException iex) {} 46 | synchronized(printer) { 47 | printer.print("thread 2"); 48 | try { 49 | Thread.sleep(100); 50 | } catch (InterruptedException iex) {} 51 | 52 | } 53 | } 54 | }); 55 | 56 | // Start threads and wait for them finish 57 | 58 | t1.start(); 59 | t2.start(); 60 | try { 61 | t1.join(); 62 | t2.join(); 63 | } catch (InterruptedException iex) { } 64 | 65 | // We'll never get to this point. How can we fix it? 66 | 67 | System.out.println("Everything went well"); 68 | } 69 | 70 | } 71 | 72 | // Two filler classes, just showing example resources to lock on 73 | 74 | class Printer { 75 | public void print(String x) { 76 | System.out.println("Printing, from " + x); 77 | } 78 | } 79 | 80 | class Scanner { 81 | public void scan(String x) { 82 | System.out.println("Scanning, from " + x); 83 | } 84 | } 85 | -------------------------------------------------------------------------------- /sample_code/concurrency/FixedDeadlock.java: -------------------------------------------------------------------------------- 1 | // A demonstration of deadlock 2 | 3 | public class FixedDeadlock { 4 | 5 | // We have two resources to lock on, printer and scanner 6 | 7 | public static Printer printer = new Printer(); 8 | 9 | public static Scanner scanner = new Scanner(); 10 | 11 | public static void main(String[] args) { 12 | 13 | // Thread 1 is going to attempt to get the printer first, then scanner 14 | // Thread 2 is going to attempt to get the scanner first, then printer 15 | 16 | // Thread 1 gets printer 17 | // Thread 2 gets scanner 18 | // Thread 1 is now waiting for the scanner to be free 19 | // Thread 2 is now waiting for the printer to be free 20 | // Neither will ever be! Each is waiting for the other 21 | 22 | Thread t1 = new Thread(() -> { 23 | synchronized(printer) { 24 | printer.print("thread 1"); 25 | try { 26 | Thread.sleep(100); 27 | } catch (InterruptedException iex) {} 28 | 29 | synchronized(scanner) { 30 | scanner.scan("thread 1"); 31 | try { 32 | Thread.sleep(100); 33 | } catch (InterruptedException iex) {} 34 | 35 | 36 | } 37 | } 38 | }); 39 | 40 | Thread t2 = new Thread(() -> { 41 | synchronized(printer) { 42 | printer.print("thread 2"); 43 | 44 | try { 45 | Thread.sleep(100); 46 | } catch (InterruptedException iex) {} 47 | synchronized(scanner) { 48 | scanner.scan("thread 2"); 49 | try { 50 | Thread.sleep(100); 51 | } catch (InterruptedException iex) {} 52 | 53 | } 54 | } 55 | }); 56 | 57 | // Start threads and wait for them finish 58 | 59 | t1.start(); 60 | t2.start(); 61 | try { 62 | t1.join(); 63 | t2.join(); 64 | } catch (InterruptedException iex) { } 65 | 66 | // We'll never get to this point. How can we fix it? 67 | 68 | System.out.println("Everything went well"); 69 | } 70 | 71 | // Two filler classes, just showing example resources to lock on 72 | 73 | // class Printer { 74 | // public void print(String x) { 75 | // System.out.println("Printing, from " + x); 76 | // } 77 | // } 78 | 79 | // class Scanner { 80 | // public void scan(String x) { 81 | // System.out.println("Scanning, from " + x); 82 | // } 83 | // } 84 | 85 | 86 | } 87 | 88 | -------------------------------------------------------------------------------- /sample_code/concurrency/HashMapDemo.java: -------------------------------------------------------------------------------- 1 | import java.util.HashMap; 2 | 3 | public class HashMapDemo { 4 | 5 | public static void main(String[] args) { 6 | 7 | // Remember hashes are key-value pairs 8 | // e.g. animal id number to noise it makes 9 | // 1 -> "meow" 10 | // 17 -> "moo" 11 | // 4 -> "cluck" 12 | // Can be in any order, can be gaps 13 | 14 | HashMap h = new HashMap(); 15 | 16 | final int NUM_TIMES = 9999999; 17 | 18 | for (int j = 0; j < NUM_TIMES; j++) { 19 | h.put(j, "chirp"); 20 | } 21 | 22 | for (int j = 0; j < NUM_TIMES; j++) { 23 | h.remove(j); 24 | } 25 | 26 | System.out.println("Final size of hash is " + h.size()); 27 | 28 | } 29 | } 30 | -------------------------------------------------------------------------------- /sample_code/concurrency/HashtableDemo.java: -------------------------------------------------------------------------------- 1 | import java.util.Hashtable; 2 | 3 | public class HashtableDemo { 4 | 5 | public static void main(String[] args) { 6 | 7 | // Remember hashes are key-value pairs 8 | // e.g. animal id number to noise it makes 9 | // 1 -> "meow" 10 | // 17 -> "moo" 11 | // 4 -> "cluck" 12 | // Can be in any order, can be gaps 13 | 14 | Hashtable h = new Hashtable(); 15 | 16 | final int NUM_TIMES = 9999999; 17 | 18 | for (int j = 0; j < NUM_TIMES; j++) { 19 | h.put(j, "chirp"); 20 | } 21 | 22 | for (int j = 0; j < NUM_TIMES; j++) { 23 | h.remove(j); 24 | } 25 | 26 | System.out.println("Final size of hash is " + h.size()); 27 | 28 | } 29 | } 30 | -------------------------------------------------------------------------------- /sample_code/concurrency/HowManyThreads.java: -------------------------------------------------------------------------------- 1 | public class HowManyThreads { 2 | 3 | public static void main(String[] args) { 4 | while (true) { 5 | System.out.println("Hello, world!"); 6 | } 7 | } 8 | } 9 | -------------------------------------------------------------------------------- /sample_code/concurrency/Increment.java: -------------------------------------------------------------------------------- 1 | // Remember that a line != a command! 2 | 3 | public class Increment { 4 | 5 | public static void main(String[] args) { 6 | byte a = 12; 7 | a += 1; 8 | } 9 | } 10 | -------------------------------------------------------------------------------- /sample_code/concurrency/JoinDemo.java: -------------------------------------------------------------------------------- 1 | // Here, we have thread 1 ("xincr") incrementing variable x, 2 | // and thread 2 ("yincr") incrementing variable y. 3 | // Once they are done incrementing, will then print out values 4 | 5 | // What happens when we comment out the joins? 6 | 7 | public class JoinDemo { 8 | 9 | public static int x = 0; 10 | 11 | public static int y = 0; 12 | 13 | public static final int NUM_TIMES = 100000000; 14 | 15 | public static void main(String[] args) { 16 | 17 | Thread t1 = new Thread(() -> { 18 | for (int j = 0; j < NUM_TIMES; j++) { 19 | x++; 20 | } 21 | System.out.println("END t1!"); 22 | }); 23 | Thread t2 = new Thread(() -> { 24 | for (int j = 0; j < NUM_TIMES; j++) { 25 | y++; 26 | } 27 | System.out.println("END t2!"); 28 | }); 29 | 30 | // Start off both threads 31 | t1.start(); 32 | t2.start(); 33 | 34 | // Wait for both to finish 35 | System.out.println("Main thread of execution here..."); 36 | 37 | try { 38 | t1.join(); 39 | t2.join(); 40 | } catch (InterruptedException iex) { } 41 | 42 | System.out.println("x = " + x + " and y = " + y); 43 | 44 | } 45 | } 46 | -------------------------------------------------------------------------------- /sample_code/concurrency/Livelock.java: -------------------------------------------------------------------------------- 1 | // Livelock 2 | 3 | // In this case, we have two friends who are very polite. 4 | // Both of them want to rent a cat from Rent-A-Cat, but they 5 | // don't want to rent it if their friend also wants it. 6 | // So each one is waiting until the other person has rented 7 | // the cat before they rent it themself. Every time they 8 | // try to rent the cat, they check to see if the other person 9 | // has rented it, and if not, they wait. However, since both 10 | // of them are waiting for the other, none will ever actually 11 | // get the cat! 12 | 13 | // This is not deadlock because there is work being done by 14 | // the CPU, it's just not useful. The two threads are "spinning 15 | // their wheels". 16 | 17 | // Another way to think of livelock as two people trying to walk 18 | // past each other in a hallway. As they approach each other, 19 | // Person A goes to the left and Person B goes to the right. 20 | // This means that they are both on the same side of the hallway, 21 | // and neither can get past the other. 22 | // ---------------------------------------------- 23 | // --->A B<---- 24 | // 25 | // ---------------------------------------------- 26 | 27 | // Now the algorithm for deciding how to go past the other person 28 | // is "go to the other side of the hallway". So both A and B 29 | // go to the other side. 30 | // ---------------------------------------------- 31 | // V V 32 | // A B 33 | // ---------------------------------------------- 34 | 35 | // But they're still blocked! So try the algorithm again - go to 36 | // the other side of the hallway. 37 | // ---------------------------------------------- 38 | // A B 39 | // ^ ^ 40 | // ---------------------------------------------- 41 | 42 | // Continue ad infinitum. There is definitely "work" being done as 43 | // the two people move endlessly back and forth, but it is not 44 | // useful work - no progress is being made. They are stuck in an 45 | // "infinite loop". 46 | 47 | public class Livelock { 48 | 49 | public static void main(String[] args) { 50 | final Renter r1 = new Renter("John"); 51 | final Renter r2 = new Renter("Jane"); 52 | 53 | final Cat c = new Cat(r1); 54 | 55 | new Thread(() -> { 56 | r1.rent(c, r2); 57 | }).start(); 58 | 59 | new Thread(() -> { 60 | r2.rent(c, r1); 61 | }).start(); 62 | } 63 | } 64 | 65 | class Cat { 66 | public Renter _renter; 67 | public Cat(Renter r) { _renter = r; } 68 | 69 | // Note that we are synchronizing on this for both setRenter 70 | // and rent. We should not have issues with accessing data 71 | // or data races here. 72 | 73 | public synchronized void setRenter(Renter r) { _renter = r; } 74 | public synchronized void rent() { 75 | System.out.println(_renter._name + " has rented the cat!"); 76 | } 77 | } 78 | 79 | class Renter { 80 | public String _name; 81 | public boolean _wantsCat; 82 | 83 | public Renter(String n) { 84 | _name = n; 85 | _wantsCat = true; 86 | } 87 | 88 | public void rent(Cat cat, Renter friend) { 89 | while (_wantsCat) { 90 | // Don't have the cat, so wait for friend. 91 | if (cat._renter != this) { 92 | try { 93 | Thread.sleep(1); 94 | } 95 | catch(InterruptedException iex) { } 96 | // Go back to the beginning of the loop and try again 97 | continue; 98 | } 99 | 100 | // If friend wants the cat, insist upon passing the cat. 101 | if (friend._wantsCat) { 102 | System.out.println("You can have the cat, " + friend._name + "!"); 103 | cat.setRenter(friend); 104 | // Go back to the beginning of the loop and try again 105 | continue; 106 | } 107 | 108 | // Friend no longer wants the cat, so finally rent it 109 | cat.rent(); 110 | _wantsCat = false; 111 | System.out.println(_name + " rented the cat!"); 112 | cat.setRenter(friend); 113 | } 114 | } 115 | } 116 | -------------------------------------------------------------------------------- /sample_code/concurrency/LolWut.java: -------------------------------------------------------------------------------- 1 | // "volatile" is a Java keyword which means that the variable 2 | // will be read from main memory *every* time it is accessed. 3 | // It will not be hoisted or read from CPU cache. 4 | 5 | // Threading can result in really, really fun and interesting 6 | // bugs, which will react differently based on slight changes 7 | // in code. Sometimes a threading issue may only show up once every 8 | // several million - or more - times that a program is run. 9 | 10 | // Try commenting/uncommenting the System.out.println on line 11 | // 57 and see how often our (known) data race occurs. 12 | // Threading is a minefield! 13 | 14 | public class LolWut { 15 | 16 | public static final int NUM_TIMES = 10000; 17 | 18 | public static volatile boolean allDoneVolatile = false; 19 | 20 | public static boolean allDone = false; 21 | 22 | public static volatile int v = 0; 23 | 24 | public static int nv = 0; 25 | 26 | public static void main(String[] args) { 27 | 28 | final Object ref = new Object(); 29 | 30 | // Thread 1 is going to increment v and nv NUM_TIMES times 31 | 32 | Thread t1 = new Thread(() -> { 33 | for (int j = 0; j < NUM_TIMES; j++) { 34 | v++; 35 | nv++; 36 | try { 37 | Thread.sleep(0, 100); 38 | } catch (InterruptedException iex) { } 39 | } 40 | allDone = true; 41 | }); 42 | 43 | Thread t2 = new Thread(() -> { 44 | int lv = -1; 45 | int lnv = -1; 46 | while (!allDone) { 47 | lv = v; 48 | // System.out.println("lv = " + lv); 49 | lnv = nv; 50 | // System.out.println("lnv = " + lnv); 51 | 52 | if (lv != lnv) { 53 | System.out.println("1 DIFFERENT! lv = " + lv + ", lnv = " + lnv); 54 | } else { 55 | // Try commenting out this line and seeing how many times values 56 | // are different! 57 | // System.out.println("1 SAME! v = " + lv + ", nv = " + lnv); 58 | } 59 | } 60 | 61 | }); 62 | 63 | t1.start(); 64 | t2.start(); 65 | 66 | try { 67 | t1.join(); 68 | t2.join(); 69 | } catch (InterruptedException iex) {} 70 | 71 | System.out.println("Final value of v = " + v); 72 | 73 | } 74 | } 75 | -------------------------------------------------------------------------------- /sample_code/concurrency/MethodLevelConcurrency.java: -------------------------------------------------------------------------------- 1 | // Just a different way of using synchronized, as a 2 | // method modifier instead of synchronizing on a specific 3 | // object in code. 4 | 5 | // synchronized as a method modifier automatically 6 | // syncs on "this" (i.e. the object the method belongs to) 7 | 8 | // The downside to this is that the entire method is 9 | // synchronized, and not just the part that you absolutely 10 | // need to be run atomically. This can degrade performance. 11 | 12 | public class MethodLevelConcurrency { 13 | 14 | public static int x = 0; 15 | 16 | public static final int NUM_TIMES = 100000; 17 | 18 | public static synchronized void safeIncrement() { 19 | x++; 20 | } 21 | 22 | public static synchronized void safeDecrement() { 23 | x--; 24 | } 25 | 26 | 27 | public static void main(String[] args) { 28 | 29 | Thread t1 = new Thread(() -> { 30 | for (int j = 0; j < NUM_TIMES; j++) { 31 | safeIncrement(); 32 | } 33 | }); 34 | Thread t2 = new Thread(() -> { 35 | for (int j = 0; j < NUM_TIMES; j++) { 36 | safeDecrement(); 37 | } 38 | }); 39 | 40 | // Start off both threads 41 | t1.start(); 42 | t2.start(); 43 | 44 | // Wait for both to finish 45 | 46 | try { 47 | t1.join(); 48 | t2.join(); 49 | } catch (InterruptedException iex) { } 50 | 51 | // Print out final result - we have done x++ 100000 times 52 | // and x-- 100000 times 53 | 54 | System.out.println("x is now " + x); 55 | 56 | } 57 | } 58 | -------------------------------------------------------------------------------- /sample_code/concurrency/NoShared.java: -------------------------------------------------------------------------------- 1 | public class NoShared { 2 | 3 | // If you avoid any shared mutable state between threads, 4 | // you can avoid synchronizing! 5 | 6 | // Remember that synchronization has a non-trivial cost 7 | // when it comes to performance. 8 | 9 | // You have several choices to avoid shared mutable state - 10 | // 1. Never mutate state 11 | // 2. Never share state 12 | // 3. Never share or mutate state 13 | 14 | // In this example, we mutate the state of numDogs and 15 | // numCats, BUT we never share that data. Multiple threads 16 | // will never access any of these vars at the "same time". 17 | // 18 | // Thus there is no risk of a data race here. Huzzah! 19 | 20 | public static int numDogs = 0; 21 | public static int numCats = 0; 22 | 23 | // NOTE there is shared state here but it is immutable. 24 | 25 | public static final int NUM_TIMES = 10000000; 26 | 27 | public static void main(String[] args) { 28 | // Note no synchronization here! 29 | // This is because we know that 30 | 31 | Thread t1 = new Thread(() -> { 32 | for (int j = 0; j < NUM_TIMES; j++) { 33 | numDogs++; 34 | } 35 | }); 36 | 37 | Thread t2 = new Thread(() -> { 38 | for (int j = 0; j < NUM_TIMES; j++) { 39 | numCats++; 40 | } 41 | }); 42 | 43 | t1.start(); 44 | t2.start(); 45 | 46 | try { 47 | t1.join(); 48 | t2.join(); 49 | } catch (InterruptedException iex) { 50 | // Ignore 51 | } 52 | 53 | System.out.println("Num cats = " + numCats); 54 | System.out.println("Num dogs = " + numDogs); 55 | 56 | } 57 | } 58 | -------------------------------------------------------------------------------- /sample_code/concurrency/SimpleThread.java: -------------------------------------------------------------------------------- 1 | import java.util.*; 2 | 3 | public class SimpleThread { 4 | 5 | private static Random rng = new Random(); 6 | 7 | public static void main(String[] args) { 8 | 9 | // Create a new thread which will run the method 10 | // SimpleThread::backgroundTask. 11 | 12 | // Note that it has not started yet! It's just been 13 | // created and sitting around 14 | 15 | // Note that a method is a type of Runnable (something that 16 | // can be run in a Thread). 17 | 18 | SimpleThread st = new SimpleThread(); 19 | 20 | Thread t = new Thread(SimpleThread::backgroundTask); 21 | 22 | // Start running the other thread 23 | 24 | t.start(); 25 | 26 | // Now, in main thread, print out Main Task (j) 27 | // with j from 0 to 99 28 | 29 | // Note that any thread may throw an InterruptedException. 30 | // This occurs when a thread is interrupted before it 31 | // does the activity it is supposed to do. 32 | 33 | for (int j=0; j < 100; j++) { 34 | System.out.println("MAIN TASK (" + j + ")"); 35 | try { 36 | Thread.sleep(10); 37 | } catch (InterruptedException iex) { } 38 | } 39 | System.out.println("MAIN IS DONE WOOT"); 40 | } 41 | 42 | // Note that there is nothing special about this method! 43 | 44 | private static void backgroundTask() { 45 | 46 | // In other thread, print out Background Task (j) 47 | // with j from 0 to 99 48 | 49 | for (int j = 0; j < 200; j++) { 50 | System.out.println("BACKGROUND TASK(" + j + ")"); 51 | try { 52 | Thread.sleep(10); 53 | } catch (InterruptedException iex) { } 54 | 55 | } 56 | System.out.println("BACKGROUND IS DONE WOOT"); 57 | 58 | 59 | } 60 | } 61 | -------------------------------------------------------------------------------- /sample_code/concurrency/SynchronousCalculator.java: -------------------------------------------------------------------------------- 1 | import java.util.*; 2 | 3 | // This will run a complex calculation on every element of an array 4 | // of the size passed in as a parameter. 5 | // It will do so synchronously (that is, work on the first element, then 6 | // the second, then the third, etc.) 7 | 8 | public class SynchronousCalculator { 9 | 10 | /** 11 | * Helper method for printing out arrays. 12 | * @param int[] arr Array of integers to print 13 | */ 14 | public static void printArray(int[] arr) { 15 | System.out.print("[ "); 16 | for (int j=0; j < (arr.length - 1); j++) { 17 | System.out.print(arr[j] + ", "); 18 | } 19 | if (arr.length > 0) { 20 | System.out.print(arr[arr.length - 1]); 21 | } 22 | System.out.println(" ]"); 23 | 24 | } 25 | 26 | /** 27 | * Generate initial array, where location 0 has 28 | * value 0, location 1 value 1, etc. 29 | */ 30 | 31 | private static int[] generateInitialArray(int n) { 32 | int[] toReturn = new int[n]; 33 | for (int j = 0; j < n; j++) { 34 | toReturn[j] = j; 35 | } 36 | return toReturn; 37 | } 38 | 39 | /** 40 | * Placeholder for complex calculation 41 | */ 42 | 43 | private static int calculate(int n) { 44 | int x = n; 45 | for (int j = 0; j < 100000; j++) { 46 | for (int k = 0; k < 20; k++) { 47 | x += k * Math.atan(n); 48 | } 49 | x += Math.acos(n); 50 | x -= j * Math.sin(n); 51 | } 52 | return x; 53 | } 54 | 55 | 56 | public static void main(String[] args) { 57 | 58 | int n = -1; 59 | 60 | try { 61 | n = Integer.parseInt(args[0]); 62 | if (n < 1) { 63 | throw new Exception(); 64 | } 65 | } catch (Exception ex) { 66 | System.out.println("Expected positive int as argument!"); 67 | System.exit(1); 68 | } 69 | 70 | int[] initialArray = generateInitialArray(n); 71 | int[] newArray = new int[initialArray.length]; 72 | 73 | printArray(initialArray); 74 | 75 | for (int j = 0; j < initialArray.length; j++) { 76 | newArray[j] = calculate(initialArray[j]); 77 | System.out.println("Finished calculating " + j); 78 | } 79 | 80 | printArray(newArray); 81 | 82 | } 83 | } 84 | -------------------------------------------------------------------------------- /sample_code/concurrency/ThreadedHashMap.java: -------------------------------------------------------------------------------- 1 | import java.util.HashMap; 2 | 3 | public class ThreadedHashMap { 4 | 5 | public static HashMap h = new HashMap(); 6 | public static HashMap h2 = new HashMap(); 7 | 8 | public static void main(String[] args) { 9 | 10 | // Remember hashes are key-value pairs 11 | // e.g. animal id number to noise it makes 12 | // 1 -> "meow" 13 | // 17 -> "moo" 14 | // 4 -> "cluck" 15 | // Can be in any order, can be gaps 16 | 17 | 18 | final int NUM_TIMES = 1000; 19 | 20 | Thread t1 = new Thread(() -> { 21 | for (int j = 0; j < NUM_TIMES; j++) { 22 | // System.out.println("Adding " + j); 23 | h.put(j, "chirp"); 24 | try { 25 | Thread.sleep(1); 26 | } catch (InterruptedException iex) { } 27 | 28 | } 29 | }); 30 | 31 | Thread t2 = new Thread(() -> { 32 | for (int j = 0; j < NUM_TIMES; j++) { 33 | //System.out.println("Removing " + j); 34 | h.remove(j); 35 | try { 36 | Thread.sleep(1); 37 | } catch (InterruptedException iex) { } 38 | 39 | } 40 | }); 41 | 42 | try { 43 | t2.start(); 44 | t1.start(); 45 | t1.join(); 46 | t2.join(); 47 | } catch (InterruptedException iex) { } 48 | 49 | System.out.println("Final size of hash is " + h.size()); 50 | 51 | // Thread t3 = new Thread(() -> { 52 | // for (int j = 0; j < NUM_TIMES; j++) { 53 | // h2.put(j, "COFFEE"); 54 | // try { 55 | // Thread.sleep(1); 56 | // } catch (InterruptedException iex) { } 57 | 58 | // } 59 | // }); 60 | 61 | // Thread t4 = new Thread(() -> { 62 | // for (int j = 0; j < NUM_TIMES; j++) { 63 | // h2.put(j, "TEA"); 64 | // try { 65 | // Thread.sleep(1); 66 | // } catch (InterruptedException iex) { } 67 | 68 | // } 69 | // }); 70 | 71 | // try { 72 | // t4.start(); 73 | // t3.start(); 74 | // t3.join(); 75 | // t4.join(); 76 | // } catch (InterruptedException iex) { } 77 | 78 | // int c = 0; 79 | // for (Object value: h2.values()) { 80 | 81 | // System.out.println(c++ + ": "+ value); 82 | // } 83 | 84 | } 85 | } 86 | -------------------------------------------------------------------------------- /sample_code/concurrency/Timer.java: -------------------------------------------------------------------------------- 1 | /** 2 | * This illustrates how to sleep for a given number of seconds. 3 | * Note that this is _not_ going to be perfect because sleeping is 4 | * _not_ guaranteed to be for a _precise_ amount of time. 5 | * But it is good enough for our project! 6 | * You can use System.nanoTime() if you want better precision. 7 | */ 8 | 9 | public class Timer { 10 | 11 | public static void main(String[] args) { 12 | 13 | System.out.println("Countdown timer..."); 14 | 15 | // Create a new thread which will count down from 10 to 0... 16 | 17 | // Note this uses the lambda syntax! 18 | 19 | Thread t = new Thread(() -> { 20 | for (int j = 10; j >= 0; j--) { 21 | System.out.println(j + "..."); 22 | 23 | // This thread will sleep for >= 1000 milliseconds (1 second) 24 | // In practice it will be very close to 1000 milliseconds 25 | // Do not rely on Java (or the JVM in general) for hard 26 | // real-time guarantees! 27 | try { 28 | Thread.sleep(1000); 29 | } catch (InterruptedException iex) { 30 | // ignore 31 | } 32 | } 33 | }); 34 | 35 | // Start the thread 36 | 37 | t.start(); 38 | 39 | // Wait until the thread is complete before moving on 40 | 41 | try { 42 | t.join(); 43 | } catch (InterruptedException iex) { 44 | // ignore 45 | } 46 | 47 | System.out.println("Liftoff!"); 48 | } 49 | } 50 | -------------------------------------------------------------------------------- /sample_code/concurrency/TimerActual.java: -------------------------------------------------------------------------------- 1 | /** 2 | * This is a variation on Timer.java in this same directory. 3 | * See there for more specifics. 4 | * Here we will use System.nanoTime() to 5 | */ 6 | 7 | public class TimerActual { 8 | 9 | public static long[] _times = new long[12]; 10 | 11 | 12 | public static void printTimeDiffs() { 13 | long timeDiff = -1; 14 | for (int j = 10; j >= 0; j--) { 15 | timeDiff = (_times[j + 1] - _times[j]) * -1; 16 | System.out.println("Time " + j + " = " + timeDiff + " ns"); 17 | } 18 | } 19 | 20 | public static void main(String[] args) { 21 | 22 | System.out.println("Countdown timer..."); 23 | 24 | 25 | // Create a new thread which will count down from 10 to 0... 26 | 27 | // Note this uses the lambda syntax! 28 | 29 | Thread t = new Thread(() -> { 30 | 31 | // Initial time 32 | _times[11] = System.nanoTime(); 33 | 34 | for (int j = 10; j >= 0; j--) { 35 | System.out.println(j + "..."); 36 | 37 | try { 38 | Thread.sleep(1000); 39 | } catch (InterruptedException iex) { 40 | // ignore 41 | } 42 | _times[j] = System.nanoTime(); 43 | 44 | } 45 | }); 46 | 47 | // Start the thread 48 | 49 | t.start(); 50 | 51 | // Wait until the thread is complete before moving on 52 | 53 | try { 54 | t.join(); 55 | } catch (InterruptedException iex) { 56 | // ignore 57 | } 58 | 59 | System.out.println("Liftoff!"); 60 | 61 | printTimeDiffs(); 62 | } 63 | } 64 | -------------------------------------------------------------------------------- /sample_code/concurrency/UnnecessaryShared.java: -------------------------------------------------------------------------------- 1 | public class UnnecessaryShared { 2 | 3 | // In this version, we will synchronize on a locking 4 | // object, but it won't buy us anything. Data races 5 | // are already impossible since we don't share mutable 6 | // state between threads. 7 | 8 | // Note we do share some state, viz., NUM_TIMES, but since 9 | // this is immutable (a final int), there is no sharing 10 | // of mutable state and so we are still OK from a threading 11 | // perspective. 12 | 13 | // This is will be MUCH slower than NoShared due to the overhead 14 | // of synchronization. 15 | 16 | public static int numDogs = 0; 17 | public static int numCats = 0; 18 | 19 | public static final int NUM_TIMES = 10000000; 20 | 21 | public static Object lockingObject = new Object(); 22 | 23 | public static void main(String[] args) { 24 | 25 | Thread t1 = new Thread(() -> { 26 | for (int j = 0; j < NUM_TIMES; j++) { 27 | // UNNECESSARY SYNCHRONIZATION 28 | synchronized(lockingObject) { 29 | numDogs++; 30 | } 31 | } 32 | }); 33 | 34 | Thread t2 = new Thread(() -> { 35 | for (int j = 0; j < NUM_TIMES; j++) { 36 | // UNNECESSARY SYNCHRONIZATION 37 | synchronized(lockingObject) { 38 | numCats++; 39 | } 40 | } 41 | }); 42 | 43 | t1.start(); 44 | t2.start(); 45 | 46 | try { 47 | t1.join(); 48 | t2.join(); 49 | } catch (InterruptedException iex) { 50 | // Ignore 51 | } 52 | 53 | System.out.println("Num cats = " + numCats); 54 | System.out.println("Num dogs = " + numDogs); 55 | 56 | } 57 | } 58 | -------------------------------------------------------------------------------- /sample_code/unsafe/OrdinaryClass.java: -------------------------------------------------------------------------------- 1 | public class OrdinaryClass { 2 | 3 | private int a = 0; 4 | 5 | public OrdinaryClass() { 6 | System.out.println("Just an ordinary class, la la"); 7 | a = 1; 8 | } 9 | 10 | public void printA() { 11 | System.out.println("Value of a is " + a); 12 | } 13 | } 14 | -------------------------------------------------------------------------------- /sample_code/unsafe/SoUnsafe.java: -------------------------------------------------------------------------------- 1 | import sun.misc.*; 2 | import java.lang.reflect.*; 3 | 4 | // For more fun things you can do with unsafe, such as modify 5 | // private variables, throw checked exceptions even if they are not 6 | // checked for, store information off the heap, write data 7 | // wherever you want (the 10th element of a 4-element array? SURE!), 8 | // allocate native memory, etc. check out: 9 | // http://www.baeldung.com/java-unsafe 10 | 11 | public class SoUnsafe { 12 | 13 | public static Unsafe getUnsafe() { 14 | Unsafe unsafe = null; 15 | try { 16 | Field f = Unsafe.class.getDeclaredField("theUnsafe"); 17 | f.setAccessible(true); 18 | unsafe = (Unsafe) f.get(null); 19 | } catch (Exception ex) { 20 | // ignore 21 | } 22 | return unsafe; 23 | } 24 | 25 | public static void main(String[] args) { 26 | Unsafe theUnsafe = getUnsafe(); 27 | // Regular ol' instantiation 28 | OrdinaryClass oc = new OrdinaryClass(); 29 | oc.printA(); 30 | 31 | 32 | // Unsafe - ignore the constructor 33 | OrdinaryClass unsafeOc = null; 34 | try { 35 | unsafeOc = (OrdinaryClass) theUnsafe.allocateInstance(OrdinaryClass.class); 36 | } catch (Exception ex) { 37 | // ignore 38 | } 39 | 40 | unsafeOc.printA(); 41 | 42 | } 43 | } 44 | -------------------------------------------------------------------------------- /study_guides/midterm_1_study_guide.md: -------------------------------------------------------------------------------- 1 | # CS1530 - Study Guide - Midterm 1 2 | 3 | This covers all the material from the beginning of the class to the last lecture before the midterm. Specifically, it will cover the following topics. 4 | 5 | * The SDLC - Understand what each phase is, what order they come in, what each involves 6 | * Is the SDLC as pictured an accurate view of modern software development? 7 | * The Iron Triangle of Project Management 8 | * What does it consist of? 9 | * Understand/analyze trade-offs 10 | * Are trade-offs always linear? 11 | * Understand how to calculate the number of communications pathways as the number of people increase 12 | * Know Brooks' Law and be able to explain 13 | * Why is estimating software effort/time difficult? 14 | * Understand requirements vs design constraints 15 | * Understand functional vs non-functional requirements (quality attributes) 16 | * Understand implicit vs explicit requirements 17 | * Technical vs non-technical considerations 18 | * Why do projects fail? 19 | * Lack of user input/involvement 20 | * Incomplete requirements/specifications 21 | * Changing requirements/specifications 22 | * Failures by phase of software 23 | * Most common in coding phase, but book recommends focusing on requirements phase.. why? 24 | * Failures by size of software 25 | * Larger software -> bigger chance of failure. Why? 26 | * What is a use case? 27 | * What is an actor? 28 | * Software methodologies - what are they? which one is "best"? 29 | * Heavyweight vs Lightweight methodologies - understand trade-offs 30 | * Understand and know trade-offs of specific methodologies described in slides: 31 | * Cowboy coding 32 | * Waterfall 33 | * Spiral 34 | * Cleanroom 35 | * Iterative and Incremental 36 | * RAD 37 | * Agile / XP 38 | * Agile / Crystal 39 | * Agile / Scrum 40 | * What is CMMI? What are the levels of CMMI? 41 | * What are the main differences between traditional methodologies and Agile methodologies? 42 | * Understand the basic philosophy of Agile (the Agile Manifesto) 43 | * Understand Agile / Scrum in-depth 44 | * User stories (Connextra template, how are they different from "traditional" requirements? 45 | * Product backlog 46 | * Sprints 47 | * Story points 48 | * Tasks 49 | * Sprint planning 50 | * Sprint review 51 | * Retrospectives 52 | * Standups 53 | * Burndown charts 54 | * Velocity 55 | * Kaizen 56 | * What is an SRS? What does it consist of and what does it not consist of? 57 | * Phases of requirements engineering 58 | * Elicitation 59 | * Documentation / definition 60 | * Specification 61 | * Prototyping 62 | * Analysis 63 | * Review and validation 64 | * Agreement and acceptance 65 | * Understand high-level vs low-level (detailed) requirements elicitation 66 | * Analytical hierarchy process - know what it is, but you do not need to memorize the calculations 67 | * Benefits / drawbacks of this approach? 68 | * Requirements traceability - what is it and why do we need it? 69 | * Types of traceability 70 | * Backward-from 71 | * Forward-from 72 | * Backward-to 73 | * Forward-to 74 | * What does it mean to sign off on requirements? 75 | * Phases of design 76 | * Architectural design phase 77 | * Detailed design phase 78 | * What is BDUF? 79 | * How are these different in Agile vs traditional ("BDUF") methodologies? 80 | * What is software architecture? 81 | * Do all systems have an architecture? 82 | * Can you have multiple architectures in one system? 83 | * Views of a software architecture 84 | * Logical view 85 | * Process view 86 | * Subsystem decomposition view 87 | * Physical architecture view 88 | * Know architectural styles and when they would be useful / not useful 89 | * Pipe-and-filter 90 | * Event-driven 91 | * Client-server 92 | * Distributed 93 | * Layered 94 | * MVC 95 | * Big ball of mud 96 | * Architectural tactics - what are they? 97 | * Reference architecture - what is it? 98 | * Functional decomposition - what is it? 99 | * Complexity metrics - know what they are, general ideas, benefits/drawbacks 100 | * Halstead complexity metric - you do not need to know calculations 101 | * McCabe's cyclomatic complexity - be able to calculate using simple if/then conditionals 102 | * Henry-Kafura information flow - calculate fan-in, fan-out, structural complexity, system complexity 103 | * Card-Glass system complexity - you do not need to know calculation 104 | * Fan-in vs fan-out 105 | * Cohesion 106 | * Coincidental 107 | * Logical 108 | * Temporal 109 | * Procedural 110 | * Communicational 111 | * Sequential 112 | * Functional 113 | * Coupling and coupling measures 114 | * Content coupling 115 | * Common coupling 116 | * Control coupling 117 | * Stamp coupling 118 | * Data coupling 119 | * Basics of UI design - the "Golden Rules" 120 | * Place the user in control 121 | * Reduce the user's memory load 122 | * Design consistent user interface 123 | * Usability evaluation 124 | * Project management - know the POMA activities 125 | * Planning 126 | * Organizing 127 | * Monitoring 128 | * Adjusting 129 | * Know how to do Lorenz-Kidd OO Estimation (you WILL need to know the formula for this) 130 | * Understand work breakdown structure and be able to make one 131 | * Understand what earned value is - you do NOT need to calculate yourself 132 | * Programming style and guidelines 133 | * Performance optimization 134 | * When to do it? 135 | * What is refactoring? 136 | * You may refactor some code 137 | * Code re-use - benefits/drawbacks 138 | 139 | 140 | 141 | -------------------------------------------------------------------------------- /study_guides/midterm_2_study_guide.md: -------------------------------------------------------------------------------- 1 | # CS1530 - Study Guide - Midterm 2 2 | 3 | ### Build Systems 4 | * Why use a build system? 5 | * Kinds of tasks involved 6 | 7 | ### Development Tactics 8 | * Accidental vs Essential Complexity 9 | * Information Hiding and Encapsulation 10 | * Postel's Principle 11 | * Abstractions, Leaky Abstractions, and Spolsky's Law 12 | * Use of final 13 | * Avoiding magic numbers 14 | * Minimizing variable scope 15 | * Side effect partitioning and pure vs impure code 16 | 17 | ### Quality Assurance 18 | * Internal vs External Quality 19 | * Ways to improve quality 20 | * Testing, pair programming, code reviews, etc 21 | * Multi-modal reviews 22 | * Limitations of testing 23 | 24 | ### Working on Legacy and Other People's Code 25 | * When should you modify legacy code? 26 | * Questions to ask before you do so 27 | * Pinning tests 28 | * What are they? 29 | * When do you use them? 30 | * How do they differ from "regular" unit tests? 31 | * Be able to describe what seams are, and find one in code 32 | * Understand change points 33 | * Understand inflection points 34 | * Understand and be able to implement sprout methods 35 | * Understand and be able to implement wrap methods 36 | 37 | ### Integration and the Software Pipeline 38 | * Phased vs incremental vs Continuous integration 39 | * Benefits / downsides of each 40 | * Integration strategies: 41 | * Top-down 42 | * Bottom-up 43 | * Risk-oriented 44 | * Feature-oriented 45 | * Understand feature toggles 46 | 47 | ### Programming With Concurrency 48 | * Why use threads? 49 | * Understand Concurrency vs Parallelism 50 | * Understand the differences between processes and threads 51 | * Be able to create use threading in Java 52 | * Threads vs Runnables 53 | * Running 54 | * Starting 55 | * Joining 56 | * Synchronization 57 | * Method level 58 | * On a lock object 59 | * Data race - be able to diagnose/implement 60 | * Ways to avoid: synchronization, no shared mutable state 61 | * Deadlock - be able to diagnose/implement 62 | * Livelock - be able to diagnose/implement 63 | 64 | ### Concurrency in Java 65 | * Understand Atomic variables 66 | * Be able to use appropriately 67 | * What are benefits/drawbacks of using thread-safe collections? 68 | 69 | ### Trade-Offs in Software Engineering 70 | * Be able to make trade-offs using the "cost/benefit" method described in class 71 | * Be able to distinguish between NECESSARY and NICE-TO-HAVE features and quality attributes 72 | * Understand difference in trade-offs in internal quality vs external quality. Which are preferable? When? 73 | -------------------------------------------------------------------------------- /syllabus.md: -------------------------------------------------------------------------------- 1 | # Syllabus - Fall 2017 2 | CS1530 Software Engineering 3 | 4 | _Although the instructor will make a best effort to have the class topic on the day listed, occasionally a change must be made (e.g., a lecture going long, or a guest lecturer unable to make it to class that day). However, these are the topics that will be covered and the expected date that they will be taught._ 5 | 6 | ## Required Books 7 | 8 | * McConnell - Code Complete, Second Edition 9 | * Tsui - Essentials of Software Engineering (third or fourth edition) 10 | 11 | ## Online Resources 12 | 13 | * The Mythical Man-Month is available for free online at the Internet Archive: [https://archive.org/details/mythicalmanmonth00fred](https://archive.org/details/mythicalmanmonth00fred) 14 | * Building and Testing With Gradle is available for free online at: http://www2.gradle.com/l/68052/2015-01-13/6dm 15 | * A Friendly Introduction to Git by Bill Laboon is available for free online at: https://github.com/laboon/friendly_introduction_git/tree/master/presentation 16 | 17 | ## WEEK 1 (28 and 30 Aug) 18 | 19 | * (28 Aug) Introduction: What is Software Engineering? 20 | * Software Engineering vs Programming vs Computer Science 21 | 22 | * (30 Aug) Overview: Designing a Software Product 23 | * __Reading: Brooks, "The Tar Pit" and Brooks, "The Mythical Man-Month" (just the titular essay, not the entire book)__ 24 | * Why is this difficult? 25 | * Overview of the Software Development Life Cycle 26 | * What goes into a software product aside from code? 27 | 28 | ## WEEK 2 (4 and 6 Sep) 29 | 30 | * (4 Sep) NO CLASS - LABOR DAY 31 | 32 | * (6 Sep) Building a Software System 33 | * __Reading: Tsui, Chapters 1 and 2__ 34 | * Overview of requirements, design, testing, estimating 35 | * How is a system built? 36 | * Walkthrough: Developing a system from requirements 37 | * DUE: READING QUIZ 1 38 | 39 | ## WEEK 3 (11 and 13 Sep) 40 | 41 | * (11 Sep) Principles of Software Engineering 42 | * __Reading: Tsui, Chapter 3__ 43 | * Why do software projects fail? 44 | * Fundamental Concepts 45 | * Davis's Principles 46 | * Royce's Principles 47 | 48 | * (13 Sep) Overview of Software Process Models 49 | * __Reading: Tsui, Chapter 4__ 50 | * Waterfall 51 | * Incremental and Iterative 52 | * Spiral 53 | * CMMI 54 | * Benefits and Drawbacks of each 55 | * DUE: READING QUIZ 2 56 | 57 | ## WEEK 4 (18 and 20 Sep) 58 | 59 | * (18 Sep) Our Model: Agile/Scrum 60 | * __Reading: Tsui, Chapter 5 *and* The Agile Manifesto__ - http://agilemanifesto.org/ 61 | * Why Agile? 62 | * Sprints / Sprint Planning / Retrospective 63 | * Scrum teams 64 | * Benefits and Drawbacks 65 | 66 | * (20 Sep) Requirements and User Stories 67 | * __Reading: Tsui, Chapter 6__ 68 | * Requirement elicitation 69 | * Requirement analysis 70 | * Differences between requirements and user stories 71 | * DUE: READING QUIZ 3 72 | 73 | ## WEEK 5 (25 and 27 Sep) 74 | 75 | * (25 Sep) Software Design and Architecture 76 | * __Reading: Tsui, Chapter 7__ 77 | * Phases of design 78 | * Architectural vs Detailed design ("strategy" vs "tactics") 79 | * Architectural styles and patterns 80 | 81 | * (27 Sep) Detailed Software Design 82 | * __Reading: Tsui, Chapter 8__ 83 | * Design metrics 84 | * Object-Oriented and Aspect-Oriented Design 85 | * Coupling and cohesion 86 | * DUE: READING QUIZ 4 87 | 88 | ## WEEK 6 (2 and 4 Oct) 89 | 90 | * (2 Oct) Software Project Management 91 | * __Reading: Tsui, Chapter 13__ 92 | * POMA - Planning, Organizing, Monitoring, Adjusting 93 | * Project effort estimation 94 | * Understanding earned value (EV) 95 | * Comparing EV vs story points 96 | 97 | * (4 Oct) Software Implementation 98 | * __Reading: Tsui, Chapter 9__ 99 | * Basic UI Design Principles 100 | * Software development guidelines 101 | * Implementation practices 102 | * DUE: READING QUIZ 5 103 | 104 | ## WEEK 7 (10 and 11 Oct) 105 | 106 | _Note: Classes that are normally held on Monday are shifted to Tuesday on this week due to the Monday holiday._ 107 | 108 | * (10 Oct) MIDTERM 1 109 | 110 | * (11 Oct) EXERCISE 1: Group Selection and Requirements 111 | * Sprint 1 begins 112 | 113 | ## WEEK 8 (16 and 18 Oct) 114 | 115 | * (16 Oct) EXERCISE 2: Git 911 116 | * __Reading: A Friendly Introduction to Git by Bill Laboon__ 117 | 118 | * (18 Oct) Gradle and Build Systems 119 | * Why a build system? 120 | * Integrating tasks 121 | * Testing with JUnit 122 | 123 | ## WEEK 9 (23 and 25 Oct) 124 | 125 | * (23 Oct) EXERCISE 3: Pair Programming a Gradle App 126 | 127 | * (25 Oct) (OPTIONAL) Swing exercise OR First Sprint retrospective/ Second Sprint planning 128 | * (OPTIONAL) Sprint 1 ends; Sprint 2 begins // can also be on 30 Oct 129 | 130 | ## WEEK 10 (30 Oct and 1 Nov) 131 | 132 | * (30 Oct) EXERCISE 4: GUEST LECTURE - Jenny Liu, Product Manager at TurnItIn, on Product Ownership. 133 | * (OPTIONAL) Sprint 1 ends; Sprint 2 begins // can also be on 25 Oct 134 | * How does Product Management compare to Program or Project Management? 135 | * Understanding customer needs 136 | * Balancing technical requirements with customer requirements 137 | * Product roadmaps 138 | 139 | * (1 Nov) Quality Assurance and Quality Software 140 | * __READING: McConnell, Chapters 20-23__ 141 | 142 | ## WEEK 11 (6 and 8 Nov) 143 | 144 | * (6 Nov) Function/Method-Level Software Development 145 | * __READING: McConnell, Chapters 5 and 10 - 12__ 146 | * Accidental vs Essential Complexities 147 | * Information Hiding and Encapsulation 148 | * Managing complexity 149 | * Techniques for ensuring loose coupling 150 | 151 | * (8 Nov) Programming with Concurrency 152 | * Why program with threads? 153 | * Threads vs Processes 154 | * Pitfalls (data races, deadlock, livelock, etc.) 155 | * Sprint 2 ends; Sprint 3 begins 156 | 157 | ## WEEK 12 (13 and 15 Nov) 158 | 159 | * (13 Nov) Concurrent Programming in Java 160 | * java.util.concurrent 161 | * Thread-safe programming in Java 162 | * Common patterns and anti-patterns 163 | 164 | * (15 Nov) EXERCISE 5: Finding Pi Using Concurrency 165 | 166 | ## WEEK 13 (20 and 22 Nov) 167 | 168 | * (20 Nov) Integration and the Software Pipeline 169 | * __READING: Tsui, Chapter 11__ 170 | * Classical models of integration 171 | * Continuous Integration 172 | * Sprint 3 ends; Sprint 4 begins 173 | 174 | * (22 Nov) NO CLASS 175 | 176 | ## WEEK 14 (30 Nov and 1 Dec) 177 | 178 | * (27 Nov) Legacy Code 179 | * Refactoring 180 | * Sprout and Wrapper methods/classes 181 | * Pinning tests 182 | * Finding/modifying seams 183 | * Finding/modifying inflection points 184 | 185 | * (29 Nov) Trade-offs In Software Engineering 186 | * Cost / Benefit analysis 187 | * Making decisions based on the Iron Triangle 188 | * Examples - Apollo Guidance Computer, Adding Metrics to Web Application 189 | 190 | ## WEEK 15 (6 and 8 Dec) 191 | 192 | * (4 Dec) MIDTERM 2 193 | 194 | * (6 Dec) Software Craftmanship 195 | * __READING: McConnell, Chapters 33 - 34__ 196 | * Writing good code - maintainable, testable, etc. 197 | * Intellectual humility and avoiding complexity 198 | * Conventions and Abstractions 199 | * Continuous Improvement 200 | * Sprint 4 ends 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | --------------------------------------------------------------------------------