//****************************************************************************//
//******************* Final Review - December 4th, 2017 *********************//
//**************************************************************************//
- The last lecture of 2340...T_T
----------------------------------
- So, today, we're mostly going to talk about the take-home final exam...so let's knock that out of the way first
- The exam has been posted as a new assignment under T-Square; it is due at 5 o'clock on December 13th
- As you'll see, there're 2 documents: a word document (which is the ACTUAL final), and a PDF containing the "design problem" that most of the final's questions ask about
- So, it gives you information about the business process for the problem, info you need to come up with a design, etc.
- "If there's something fuzzy and you need to make an assumption for your design ('we assume there'll never be more than 1000 delinquent loans'), just write them down so the TAs can see what you were thinking"
- Then, on the ACTUAL final, you're supposed to do it with your teammates! You're encouraged to talk freely w/ teammates, it's open-book/open-notes ("in the real world, your employer isn't gonna come into your office and tell you to get rid of your books since it's design-problem time")
- The questions are pretty familiar; for the information in your "design problem" pdf, you have to draw a context diagram, write a user story, create a class diagram, discuss design patterns to use, etc.
- The LAST 2 questions are about the rat report project; all the rest are based off of the provided PDF.
- "To submit it, either submit it electronically or in paper to my office. MAKE SURE that everything can be viewed without special software if you submit it electronically"
- So, then, a few more odds and ends to wrap up this class:
- Exam 2 is almost entirely graded EXCEPT for one last question; it should be done by Tuesday
- TAs will start grading M12 as soon as you turn it in tonight; apologies that you don't have your grades already, but I accidentally made the due date THIS Monday instead of last Monday, because I don't know when Thanksgiving is
- "I know you're hearing about it in EVERY SINGLE CLASS, but please fill out CIOS. ~80% participation will result in a few points of extra credit, but we do listen to CIOS feedback."
- "I spent 20 years in the military; I'm sorry to disappoint you all, but there's not a whole lot you can do to make me angry compared to that, so feel free to write however you honestly feel."
- Usually, results are a bi-modal distribution, where the future software engineers love the class and the future theory people think it's pointless
- If you don't fill out the CATME survey, then I'm going to assume that everything was good and your team worked well together and all want the same grades for everything.
- So, let's now review the whole semester in a few minutes:
- So you want to write an application, right? FIRST, we have to figure out what the heck we're building (OOA)!
- So, we start by asking who'll actually use the app? To do this, we draw CONTEXT DIAGRAMS
- Then, we try to figure out HOW those people will use the app by writing USER STORIES for them
- Then, we try to understand the customer's concepts and understand their domain, ending by creating a DOMAIN MODEL of the problem.
- Across all of this, to make sure that all of the dev team is on the same page, we tie this all together in a ROBUSTNESS DIAGRAM
- After this point, the UI designers start coming up with UI prototypes to figure out how the app will work, presenting it to the customer to make sure it's what they need
- So, we know what the app is; how do we figure out how to actually build it?
- First off, what sort of ARCHITECTURE will the app use (blackboard, microservices, etc.)? We consider the architecture styles/views we want to focus on, then create a UML CLASS DIAGRAM to begin laying out the class structure
- We then create a SEQUENCE DIAGRAM and begin coming up with design patterns/principles to follow
- Finally, we have to actually start constructing our application
- This is where we come up with coding standards, code reviews, unit tests, configuration managment (Git), building applications (Gradle) etc.
- "The days of one person working on a single application are mostly past; once you start building an application of any scale, you HAVE to have these standards in place to work with other people."
- This is also where you worry about AGILE development techniques (like SCRUM), working with your teammates, etc.
- "This semester, we did have a waterfall-y approach due to having to teach everything in-order: drawing the sequence diagrams, then beginning the coding, etc.; in REAL LIFE, we'd be doing user stories 1-3, then start work on that while we get info for user stories 4-6, etc."
- "If you go into industry, you'll hear ALOT about REFACTORING: improving the design of the software to reduce technical debt, without changing how the software actually works."
- A few things we didn't get to ("ALOT of this is covered in CS 3300/4400, both of which I'd recommend"):
- REFACTORING, as mentioned
- Requirements Engineering, where we try to figure out WHAT the customer actually wants (since oftentimes their ideas are pretty vague)
- Functional/Procedural audits
- Doing multi-threading in Java
- Database techniques
- Non-Object Oriented design stuff; "We didn't even touch functional programming, etc."
- Alot of specific software engineering techniques...this class hit the most important concepts, but it's still an introductory class; there's a LOT more you can learn if you want to go deeper.
- Annnnnnnd...well, that's it!
- I hope you enjoyed the class, I hope it was useful for you, I hope you take another class with me again...but other than that, we're done here! Thanks for coming, and good luck out there!