Welcome to CSE 218 Advanced Software Engineering! We love software design, and want to help you become great software designers.
This website is divided into many sections (pages), accessible from the drop-down at the upper-right.
LECTURE: Tuesday-Thursday, 9:30-10:50am, Peterson 102
OFFICE HOURS:
Instructor: Tuesday-Thursday 10:50am-11:30am (immediately after class outside Peterson Hall), and by appointment
TA: TBD
NOTE: This course is open to undergraduates who have completed CSE 110. CSE 218 can be repeated for credit, although it cannot be taken with the same instructor twice.
Programmers and software designers/architects are often concerned about the modularity of their systems, because effective modularity reaps a host of benefits for those working on the system, including ease of construction, ease of change, and ease of testing, to name just a few. Other possible benefits are reuse (e.g., in software product lines) and online adaptability.
This course will be an open exploration of modularity - methods, tools, and benefits. In the process we will confront many challenges, conundrums, and open questions regarding modularity. Techniques and concepts explored include Information-Hiding, the Single Responsibility Principle, Dependency Inversion, Dependency Injection, the Open-Closed Principle, Design by Contract, Design Patterns, Software Architecture, and Object-Oriented Design.
Each week we will cover one of these topics (Design Patterns takes two). A week will proceed as follows:
Tuesday: After class, readings are formally assigned (but available much sooner).
Thursday:
Before class, submit a short writeup on the readings (or annotations directly on the readings). See:
Structured form for reading and taking notes on a paper: PDF, latex, Word
Analogous Book chapter reading form [latex, Word] (do not turn in a marked up chapter; you can write up multiple chapters from the same book with a single form)
Required annotations if you mark up your paper instead of filling out the form
During class, in-class discussion of readings in breakouts, using a methodology called Socratic Circles. See:
After class, a Lab on the readings will be formally released. A Lab is a small team project performed on a common code base in which we analyze and (usually) refactor the code base.
Tuesday: A small number of teams (3-4) will present their Labs to the class.
For more information, see the introductory slides from 2023.
This class is using Canvas [link] for all course resources.
The required text and some of the recommended texts are available online (on campus or via the UCSD VPN), up to 20 readers at a time. If you're not a risk-taker, buy the books. You should buy HFDP, it is great reference work.
NOTE: Page numbers may vary between paper and digital versions. Unless otherwise indicated, page numbers are from the paper edition. Please use Chapter and Section names to disambiguate as necessary.
Mandatory Class Books
[HFDP] Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004 [online 2020 edition] [online 2004 edition]
Optional Class Books
[ASD] Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices, Pearson, 2004.
[UMLD] Martin Fowler, UML Distilled, Addison-Wesley, 2003.
Reference Books
[AND] Dawn Griffiths and David Griffiths. Head First Android Development, 3rd Edition, O'Reilly Media, 2022. [online]
Occasionally we may need to contact you regarding your homework or some pressing matter. We may use e-mail or Piazza. When we use e-mail, we will use your official UCSD e-mail address, as registered in TritonLink. You are responsible for reading course-related e-mails sent to your UCSD account in a timely manner.
We also post important announcements to Piazza. You are responsible for keeping yourself subscribed to Piazza's announcements so that you automatically receive updates regarding instructor posts as an e-mail. All course content will be provided through Canvas. Note that there are mobile clients for Canvas and Piazza.
For general questions, please use Piazza, with a public message to everyone. To contact us about a private matter, please use Piazza via a private note or question. We do not follow e-mail religiously, but we stay on top of Piazza.
Software engineers are trusted with the lives and livelihoods of the users of the software they develop. Paying customers (clients, product owners) also depend on software engineers for their livelihoods. Furthermore, society depends on software engineers to act in the interest of the broader society, not just the paying customer and immediate users. Consequently, great (and ethical) software engineers hold themselves to the highest standards of conduct. They do their own work, they know where every line of code came from and document it, speak up when there is a problem, and do not allow the release of code that may jeopardize the livelihoods of users, clients, or society at large. It's not just good for business in the long term, it's the moral and ethical thing to do. Software engineers who do not uphold these standards will be passed over for promotions, lose their jobs, and be unable to get good references from previous employers or colleagues. You could even be sued for civil damages or indicted for a crime. Short-term or selfish thinking leads to long-term losses to all parties. In short, take the high road, you'll never regret it. Act in ways that you, your friends, and family would be proud.
It is within this framework -- the framework of the ethical software engineer -- that you should understand and practice UCSD's principles and rules of Academic Integrity. These are not arbitrary rules. These are the principles on which our identities as engineers are founded. There is no higher honor than to know that those around you feel they can count on you. Be worthy of that trust. It's not easy, it takes discipline and effort. Here, forthwith, is the Academic Integrity statement.
You are to do your own work in this course. Each student is responsible for knowing and abiding by UCSD's policies on Academic Dishonesty and on Student Conduct. Any student violating UCSD's UCSD Academic Integrity Policy will be reported to the Academic Integrity Office for administrative processing, and may result in suspension or dismissal from UCSD, as well an an academic sanction that could result in failing the course (e.g., a grade of zero (0) on a compromised assignment). Committing acts that violate the UCSD Student Conduct Code that result in course disruption will be referred to the Office of Student Conduct, and could result in suspension or dismissal.
As a clarification of the UCSD Academic Integrity Policy as it applies to the work in this course, note the following:
No student shall provide their assignments, in part or in total, to any other student in current or future classes of this course. No student shall procure or accept assignments from any other student from current or prior classes of this course.
You alone can possess and use your clicker. If you are found possessing someone else's clicker in lecture, or your clicker is found in possession of someone else during lecture, both of you will be in violation of the academic integrity policy.
All programming code and documentation submitted for evaluation or existing inside the student's computer accounts must be the student's original work or material specifically authorized or provided by the Instructor. The course accounts are authorized for course work only.
Collaborating with other students to develop, complete or correct course work is limited to activities explicitly authorized by the Instructor (e.g., see below). Use of other student's course work, in part or in total, to develop, complete or correct course work is unauthorized. However, students may freely discuss their work with others.
Each student must retain intermediate work as proof that submitted work is their own. A student may be asked to provide these intermediate copies as evidence that the submitted work is the student's.
With regard to the above rules, it is understood that your project team members will be sharing code among its themselves (but not to other teams) to complete your project.
With regard to the above rules, it is acceptable to search the internet to solve programming problems of the "how to" and bug type. You are responsible for not violating copyright laws when taking code solutions that are found on the internet. If you cannot ascertain that copying is permitted, you cannot copy the code, but must, at worst, fashion your own solution based on the solution you have found. You must document the source (including a URL) of any code that is used in part or whole (at the place of use, in source code comments), just as you document your sources in an English paper or essay.
With regard to the above rules, it is acceptable to use pre-existing third-party libraries (i.e., jar files), as long as they have a license that permits such use. You are responsible for not violating said licenses. If there is no license or explicit permission, use is prohibited. You must document (in your project code) the use of third-party libraries, including a URL that points to the home of the library.
With regard to the above rules, it is permissible to use an AI code generator such as Github Copilot to help you generate code. Consistent with the rules on using website code and libraries, you must document, in source code comments, which generator (including version number) was used, and the final prompt(s) used to generate the code. It is understood that you edit the code after generation; you must still cite the use.