20 topics
Software engineering help, from merge conflicts to class diagrams
Git has stopped mid-merge, your file is full of angle brackets, and the group project is due tomorrow. Software engineering is the course where the problems stop being about whether your code runs and start being about working on one codebase with four other people who edited the same method. Nothing in a first programming course prepares you for that, which is why it hurts.
Where students get stuck
A merge conflict opened and I don't know which side to keep
Usually neither side alone. The markers show your branch's version above and the incoming version below, and the correct result is often a combination of both changes, since two people edited the same region for two different reasons. Read both, work out what each was trying to achieve, then write the version that achieves both and delete every marker line. Run the tests afterwards, because a conflict resolved to something that compiles is not the same as one resolved to something correct.
I don't know what I'm supposed to test
Test the behaviour promised by the method's contract, not the lines inside it. For each input parameter, write one case in the normal range, one at each boundary, and one that is invalid. Empty list, single element, list of the maximum size, null. Then test any branch that changes the outcome. A test that reproduces the internal implementation step by step passes forever and catches nothing, because it breaks when you refactor and stays green when the logic is wrong.
Aggregation, composition, association — which diamond do I draw?
Ask what happens when the container is destroyed. Composition, the filled diamond, means the parts die with it: delete an order and its line items are meaningless, so they go too. Aggregation, the hollow diamond, means the parts outlive it: disband a team and the employees still exist. Plain association, a bare line, means the two classes simply know about each other with no ownership at all. Answer the destruction question in a sentence first and the correct symbol follows without guessing.
Everyone on my team commits to one branch and it keeps breaking
The problem is that nothing separates work in progress from work that is finished. Each person takes a branch per feature, pushes it, and opens a pull request that someone else reads before it lands. Two things follow immediately: the main branch always builds, and every change gets a second pair of eyes. Also pull from main into your branch daily. Conflicts are proportional to how long a branch has diverged, and a week-old branch is a genuinely miserable merge.
Functional or non-functional requirement? I keep miscategorising
Functional requirements are things the system does — the user can reset a password, the report exports to CSV. Non-functional requirements are constraints on how well it does them: response under two seconds, available 99.9% of the time, usable on a screen reader. The test is whether you could still describe the feature with the requirement removed. If yes, it was a quality constraint. Non-functional ones are graded harder because students write them unmeasurably, so attach a number to every one.
What's covered
Software Engineering topics you can work through with a tutor, generate practice on, or turn into flashcards and a study plan.
Requirements and planning
- Eliciting and writing requirements
- Functional versus non-functional requirements
- User stories and acceptance criteria
- Use case diagrams and scenarios
- Estimation and project scheduling
Design and modelling
- UML class, sequence, and state diagrams
- Object-oriented design principles and SOLID
- Design patterns: factory, observer, strategy, singleton
- Coupling, cohesion, and separation of concerns
- Software architecture: layered, client-server, microservices
Quality and testing
- Unit, integration, and system testing
- Test-driven development
- Boundary values and equivalence partitioning
- Code review and static analysis
- Refactoring and technical debt
Process and collaboration
- Waterfall, Agile, and Scrum
- Sprints, standups, and retrospectives
- Git branching, pull requests, and merge conflicts
- Continuous integration and deployment
- Documentation and maintenance
Software Engineering questions
Can it help with a group project where the problem is people, not code?
Partly. It can help you set up the branching and review workflow that removes the most common source of friction, and rehearse how to raise a blocked task in a standup. It cannot manage your teammates, and it will not write their share.
Will it draw my UML diagram for me?
It works one out with you on the whiteboard, asking what each class owns and what happens when it is destroyed. That conversation is what the assignment is assessing, and a diagram handed to you tends to collapse under the first follow-up question from a marker.
I have to present my design to the class. Can it help me prepare?
Yes. Talk through the architecture out loud to it as though it were the panel, and it will push back on the decisions you cannot justify. Being asked why not a different pattern before the real session is more useful than rereading the slides.
My design document needs to hit a rubric. Can it check the draft?
Paste the draft and the rubric together and it gives feedback against those criteria. Design documents commonly lose marks for missing alternatives considered and trade-offs, which is easy to fix once someone points at the gap.
Stuck on software engineering right now?
Talk it through out loud, share your screen, and watch it worked out step by step on a whiteboard.
Start free — no card