WikiLabs - Schimbări recente [ro]

Fișier:Os lab skeleton.zip

Vserbu — Fri, 09 Oct 2026 13:35:35 GMT

Vserbu a încărcat o versiune nouă pentru Fișier:Os lab skeleton.zip

Pagină nouă

OS Lab 1 - Linux setup. Bash primer. C primer

Vserbu — Fri, 09 Oct 2026 13:30:31 GMT

Afișare diferențe

OS Lab 1 - Linux setup. Bash primer. C primer

Vserbu — Fri, 09 Oct 2026 13:28:54 GMT

Pagină nouă: <span id="overview"></span> = Overview = In every lab, you will write C programs, build them, and run them on Linux from a shell. In this first lab, you will set up a Linux enviro...

Afișare diferențe

Operating Systems

Vserbu — Fri, 09 Oct 2026 13:27:25 GMT

Old Lab Sessions (2025)

Fișier:Os lab skeleton.zip

Vserbu — Fri, 09 Oct 2026 13:20:32 GMT

Vserbu a încărcat Fișier:Os lab skeleton.zip

Pagină nouă

Operating Systems

Vserbu — Fri, 09 Oct 2026 12:59:54 GMT

Lab Sessions

FPGA Student Classroom tutorial

Vserbu — Tue, 06 Oct 2026 07:54:52 GMT

Step 2 - SSH

SDA Lucrarea 1

Andrei.ulmamei — Thu, 01 Oct 2026 10:03:40 GMT

Problema 3

Arhitectura Sistemelor de Calcul

Zhascsi — Tue, 29 Sep 2026 08:43:59 GMT

Laboratorul 6

Zhascsi — Tue, 29 Sep 2026 08:36:56 GMT

Laboratorul 4

Zhascsi — Tue, 29 Sep 2026 08:34:34 GMT

Laboratorul 2

Zhascsi — Tue, 29 Sep 2026 08:30:05 GMT

Laboratorul 1

Zhascsi — Tue, 29 Sep 2026 08:20:01 GMT

Lab 7

Andrei.ulmamei — Sat, 26 Sep 2026 10:40:37 GMT

Pagină nouă: = Lab 7 — Final Integration, Demonstration and Code Review = == Objectives == This laboratory is the final project session. The objective is to demonstrate that the semester p...

Pagină nouă

= Lab 7 — Final Integration, Demonstration and Code Review =

== Objectives ==

This laboratory is the final project session.

The objective is to demonstrate that the semester project is complete, reproducible, technically understood by the team and ready for evaluation.

Unlike the previous laboratories, this session is centered on:

* final integration;
* project demonstration;
* architecture explanation;
* code walkthrough;
* technical discussion;
* verification of tests and documentation;
* evaluation of project quality;
* final submission.

By the end of this laboratory, each team should be able to:

* run the project from a clean and documented setup;
* demonstrate the primary application workflow;
* explain the architecture of the project;
* explain the responsibility of the main modules;
* justify important design decisions;
* explain how errors are handled;
* explain how the project is tested;
* discuss one important technical problem encountered during development;
* identify known limitations;
* show that the repository is complete and clean;
* answer technical questions about its own implementation.

__TOC__

== 1. Final laboratory structure ==

A possible structure for the two-hour session is:

{| class="wikitable" style="width:100%;"
! Time
! Activity
|-
| 0–10 min
| Final setup and repository verification
|-
| 10–80 min
| Project demonstrations
|-
| 80–105 min
| Code walkthrough and technical discussion
|-
| 105–115 min
| Final repository and documentation checks
|-
| 115–120 min
| Submission confirmation
|}

The exact timing depends on the number of teams.

== 2. What should be ready before the session ==

Before the final laboratory begins:

* the core feature set should be frozen;
* no P0 defects should remain;
* the main workflow should work end-to-end;
* tests should pass;
* installation instructions should be complete;
* the README should be up to date;
* known limitations should be documented;
* the repository should not contain secrets or unnecessary generated files;
* the team should have a stable demonstration scenario.

Lab 7 should not be used for major architecture changes.

== 3. Final project state ==

The expected state is:

<syntaxhighlight lang="text">
implemented
↓
tested
↓
documented
↓
reproducible
↓
demonstrable
↓
explainable
</syntaxhighlight>

A project that only runs on the original developer's machine is not yet ready for final evaluation.

== 4. Demonstration first, slides second ==

The primary evidence of a working project is the software itself.

The demonstration should focus on:

# starting the application;
# providing representative input;
# executing the main workflow;
# showing the output;
# showing one relevant error condition;
# explaining the result.

Slides may be used for context, but they should not replace a live demonstration.

== 5. Recommended demonstration structure ==

A concise demonstration can follow:

<syntaxhighlight lang="text">
Problem
↓
Input
↓
Execution
↓
Result
↓
Failure case
↓
Short technical explanation
</syntaxhighlight>

The demonstration should show the central objective of the project clearly.

== 6. Demonstration time ==

The demonstration should be concise.

A reasonable target is approximately:

<syntaxhighlight lang="text">
5–8 minutes
</syntaxhighlight>

depending on project complexity.

The objective is not to show every implemented feature.

Show the most important workflow reliably.

== 7. Demonstration reliability ==

Avoid a demonstration that depends on:

* unstable public services;
* unavailable hardware;
* unknown network connectivity;
* private local files;
* credentials not available during evaluation;
* large downloads;
* manually prepared state that cannot be reproduced.

If an external dependency is required, prepare a safe fallback demonstration strategy where possible.

== 8. Representative input ==

The demonstration should use input representative of the actual project.

For example:

{| class="wikitable" style="width:100%;"
! Project type
! Representative input
|-
| image processing
| real or realistic image
|-
| data analysis
| meaningful dataset
|-
| networking
| valid application message or packet
|-
| hardware
| real device or recorded representative data
|-
| monitoring
| realistic metric stream
|-
| file processing
| correctly structured input file
|}

Avoid demonstrating only trivial toy input when the project is designed for a more realistic workload.

== 9. Show one error condition ==

A useful final demonstration includes one expected failure.

Examples:

* invalid input;
* missing file;
* malformed configuration;
* unavailable device;
* invalid packet;
* unsupported image format;
* timeout.

The goal is to show that the project handles predictable failure conditions deliberately.

== 10. Architecture explanation ==

Each team should be able to explain the architecture in approximately one or two minutes.

A good explanation identifies:

* inputs;
* main components;
* data flow;
* external dependencies;
* outputs.

For example:

<syntaxhighlight lang="text">
CLI
│
▼
Application service
│
├── parser
├── processing pipeline
└── storage
│
▼
output file
</syntaxhighlight>

== 11. Architecture diagram ==

A simple architecture diagram is sufficient.

Avoid diagrams that show every function or variable.

Focus on major components.

Example:

<syntaxhighlight lang="text">
main
├── config
├── service
│ ├── model
│ └── processor
└── storage
</syntaxhighlight>

== 12. Explain responsibilities ==

For each main module, the team should be able to complete:

<syntaxhighlight lang="text">
This module is responsible for ...
</syntaxhighlight>

For example:

{| class="wikitable" style="width:100%;"
! Module
! Responsibility
|-
| <code>models.py</code>
| application data structures
|-
| <code>services.py</code>
| central application logic
|-
| <code>storage.py</code>
| persistent data access
|-
| <code>protocol.py</code>
| message encoding and decoding
|-
| <code>main.py</code>
| application startup and orchestration
|}

== 13. Code walkthrough ==

The code walkthrough should not attempt to read the entire repository.

Choose the most important implementation path.

For example:

<syntaxhighlight lang="text">
main()
↓
load configuration
↓
create service
↓
process input
↓
produce result
</syntaxhighlight>

Explain how the main workflow maps to the source code.

== 14. What to show during code review ==

Useful areas include:

* application entry point;
* core processing logic;
* one important model or class;
* one error-handling path;
* one representative test;
* one external integration boundary.

Do not spend presentation time showing trivial boilerplate.

== 15. Explain one design decision ==

Each team should prepare one important design decision.

For example:

<syntaxhighlight lang="text">
Why was composition used instead of inheritance?

Why was JSON selected for persistence?

Why was a pipeline separated into stages?

Why was dependency injection used?

Why was the protocol parser separated from network transport?
</syntaxhighlight>

The answer should include the reasoning and trade-offs.

== 16. Design trade-offs ==

Most design decisions have advantages and disadvantages.

A useful explanation is:

<syntaxhighlight lang="text">
We selected approach A because ...
The main advantage is ...
The main disadvantage is ...
Approach B was considered, but ...
</syntaxhighlight>

Avoid claiming that a design has no disadvantages.

== 17. Explain one technical difficulty ==

Each team should identify one meaningful technical difficulty encountered during the project.

Examples:

* parsing an undocumented format;
* synchronizing hardware communication;
* handling malformed packets;
* managing asynchronous operations;
* correcting image-processing artifacts;
* making a component testable;
* debugging a dependency issue;
* designing data serialization.

The explanation should focus on the technical reasoning used to solve the problem.

== 18. Explain the debugging process ==

A useful structure is:

<syntaxhighlight lang="text">
Observed behavior
↓
Hypothesis
↓
Diagnostic method
↓
Root cause
↓
Fix
↓
Regression test
</syntaxhighlight>

This demonstrates engineering process, not only the final result.

== 19. Testing explanation ==

The team should be able to explain:

* what is tested;
* why those areas are important;
* what is not tested;
* which tests are unit tests;
* which tests are integration tests;
* how external dependencies are handled.

== 20. Show one representative test ==

For example:

<syntaxhighlight lang="python">
def test_average_rejects_empty_list():
with pytest.raises(ValueError):
average([])
</syntaxhighlight>

or:

<syntaxhighlight lang="python">
def test_round_trip(tmp_path):
path = tmp_path / "data.json"

save_data(path, original)

restored = load_data(path)

assert restored == original
</syntaxhighlight>

The test should demonstrate meaningful project behavior.

== 21. Tests should pass ==

Before the demonstration:

<syntaxhighlight lang="bash">
pytest
</syntaxhighlight>

should complete successfully.

If some tests are intentionally skipped, the reason should be understood and documented.

== 22. Quality checks ==

Run the project's normal quality checks.

For example:

<syntaxhighlight lang="bash">
ruff check .
pytest
</syntaxhighlight>

If static type checking is part of the project:

<syntaxhighlight lang="bash">
mypy src
</syntaxhighlight>

If formatting is enforced:

<syntaxhighlight lang="bash">
ruff format --check .
</syntaxhighlight>

== 23. Final clean installation test ==

The project should have been tested in a clean environment before Lab 7.

A typical procedure:

<syntaxhighlight lang="bash">
python -m venv clean-env
source clean-env/bin/activate

python -m pip install -e .

pytest
python -m project_name
</syntaxhighlight>

If these steps fail, the project is not reproducibly packaged.

== 24. Windows clean setup ==

For Windows PowerShell:

<syntaxhighlight lang="powershell">
python -m venv clean-env
clean-env\Scripts\Activate.ps1

python -m pip install -e .

pytest
python -m project_name
</syntaxhighlight>

Document platform-specific requirements where necessary.

== 25. README final review ==

The README should contain at least:

<syntaxhighlight lang="text">
Project name
Description
Main features
Requirements
Installation
Configuration
Running
Example usage
Testing
Architecture overview
Known limitations
</syntaxhighlight>

Another developer should be able to start the project using only this information.

== 26. Repository structure ==

A final project may resemble:

<syntaxhighlight lang="text">
project/
├── README.md
├── pyproject.toml
├── .gitignore
├── src/
│ └── project_name/
│ ├── __init__.py
│ ├── main.py
│ └── ...
├── tests/
│ └── ...
└── examples/
└── ...
</syntaxhighlight>

Not every project requires the same modules.

== 27. Repository cleanliness ==

The repository should generally not contain:

<syntaxhighlight lang="text">
.venv/
__pycache__/
*.pyc
.pytest_cache/
.mypy_cache/
.ruff_cache/
.coverage
temporary output
real secrets
large accidental binaries
</syntaxhighlight>

unless a specific generated artifact is deliberately required.

== 28. Git status ==

Before submission:

<syntaxhighlight lang="bash">
git status
</syntaxhighlight>

should not show forgotten modifications or accidentally generated files.

== 29. Git history ==

Inspect:

<syntaxhighlight lang="bash">
git log --oneline --graph --decorate
</syntaxhighlight>

The history should show meaningful development rather than one final upload.

Useful examples:

<syntaxhighlight lang="text">
Add packet decoder
Implement device retry handling
Add regression tests for invalid frames
Refactor configuration loading
Document installation procedure
</syntaxhighlight>

== 30. Final commit ==

A final commit may be something like:

<syntaxhighlight lang="text">
Prepare final project release
</syntaxhighlight>

but the repository should already contain meaningful previous commits.

== 31. Tagging a release ==

Optionally, create a final release tag.

For example:

<syntaxhighlight lang="bash">
git tag v1.0.0
</syntaxhighlight>

If tags are used:

<syntaxhighlight lang="bash">
git push --tags
</syntaxhighlight>

This is optional unless required by the course.

== 32. Version consistency ==

If the project uses a version:

<syntaxhighlight lang="toml">
[project]
version = "1.0.0"
</syntaxhighlight>

ensure documentation and release tags do not contradict it.

== 33. Known limitations ==

Known limitations should remain visible in the final documentation.

For example:

<syntaxhighlight lang="text">
## Known limitations

- Only PNG input is supported.
- Device reconnect requires application restart.
- The project has only been tested on Linux.
</syntaxhighlight>

Do not remove limitations merely to make the project appear more complete.

== 34. Final acceptance test ==

Before presentation, execute one complete acceptance test.

Record:

<syntaxhighlight lang="text">
Input:
Command:
Expected output:
Actual output:
Result:
</syntaxhighlight>

The main workflow should pass.

== 35. Demonstration backup ==

For projects with fragile external dependencies, prepare a backup.

Possible backups include:

* representative recorded data;
* stored sample responses;
* local test server;
* simulated hardware interface;
* known-good sample images.

A backup should still demonstrate the project's own logic.

== 36. Do not fake the primary functionality ==

A backup may replace an unavailable external dependency.

It should not replace the actual project implementation.

For example:

<syntaxhighlight lang="text">
acceptable:
recorded sensor data → real processing pipeline

not acceptable:
precomputed final output shown instead of processing
</syntaxhighlight>

== 37. Technical questions ==

Students should be prepared for questions such as:

* Why is this component a class?
* Why is this function separate?
* Why does this module depend on that one?
* What happens if this file is missing?
* What happens if this network request times out?
* How is this behavior tested?
* What would need to change to support another input format?
* Which part was most difficult?
* Where is configuration stored?
* Why was this library selected?
* What is one limitation of the current implementation?

== 38. Questions about Python ==

The project discussion may also include concepts from Labs 1–4.

For example:

* difference between <code>==</code> and <code>is</code>;
* list/reference semantics;
* properties;
* dataclasses;
* inheritance versus composition;
* modules and packages;
* exceptions;
* context managers;
* type hints;
* pytest fixtures;
* parametrized tests;
* dependency injection.

The objective is to connect the project implementation to the Python concepts studied during the course.

== 39. Explain code ownership ==

Every team member should understand the main project architecture.

A student should not answer:

<syntaxhighlight lang="text">
"I don't know; another team member wrote that file."
</syntaxhighlight>

for central project functionality.

Specialization is reasonable, but the team should maintain shared understanding of the main system.

== 40. Team presentation ==

A possible team presentation structure is:

{| class="wikitable" style="width:100%;"
! Part
! Suggested content
|-
| 1
| problem and objective
|-
| 2
| architecture
|-
| 3
| live demonstration
|-
| 4
| important implementation detail
|-
| 5
| tests and reliability
|-
| 6
| limitation and future improvement
|}

Keep the presentation technical and concise.

== 41. Project objective ==

The first explanation should answer:

<syntaxhighlight lang="text">
What problem does this project solve?
</syntaxhighlight>

A good answer should fit in one or two sentences.

Avoid beginning with a long list of technologies.

== 42. Technology is not the objective ==

Poor:

<syntaxhighlight lang="text">
We used Python, NumPy, OpenCV,
JSON, Git and pytest.
</syntaxhighlight>

Better:

<syntaxhighlight lang="text">
The application processes thermal frames
and detects defective pixels automatically.
</syntaxhighlight>

Technologies support the project objective; they are not the objective themselves.

== 43. Explain the data flow ==

A useful technical explanation follows the data.

For example:

<syntaxhighlight lang="text">
camera frame
↓
decoder
↓
preprocessing
↓
analysis
↓
result
↓
storage/display
</syntaxhighlight>

This often makes the architecture easier to understand than describing files in arbitrary order.

== 44. Explain external dependencies ==

Identify external boundaries explicitly.

Examples:

<syntaxhighlight lang="text">
filesystem
network API
camera
serial device
database
third-party library
operating system
</syntaxhighlight>

Explain how failure at these boundaries is handled.

== 45. Explain one invariant ==

An invariant is a condition expected to remain true.

Examples:

<syntaxhighlight lang="text">
grade is always between 1 and 10
packet length matches header length
image width is always positive
device ID is unique
configuration is validated before startup
</syntaxhighlight>

Explain where the invariant is enforced.

== 46. Explain one exception path ==

Students should be able to trace one error path.

For example:

<syntaxhighlight lang="text">
missing file
↓
FileNotFoundError
↓
application boundary catches error
↓
user-friendly message
↓
application exits with failure
</syntaxhighlight>

== 47. Explain one testability decision ==

Examples:

<syntaxhighlight lang="text">
network client passed as dependency
file path passed as parameter
processing separated from input()
hardware access isolated in device.py
time source injected into function
</syntaxhighlight>

Explain how the decision makes automated testing easier.

== 48. Explain one refactoring ==

The team should identify one area improved after the MVP.

For example:

<syntaxhighlight lang="text">
Before:
main.py contained parsing,
processing and output.

After:
parser.py
processor.py
storage.py
main.py
</syntaxhighlight>

Explain why the new structure is better.

== 49. Explain one regression test ==

A useful answer is:

<syntaxhighlight lang="text">
We discovered that empty input caused
ZeroDivisionError.

We added a test for empty input,
then changed the function to raise
a meaningful ValueError.
</syntaxhighlight>

This demonstrates a complete defect-fixing workflow.

== 50. Evaluation areas ==

A project may be evaluated across several dimensions.

{| class="wikitable" style="width:100%;"
! Area
! What is considered
|-
| functionality
| Does the central application work?
|-
| correctness
| Are results and behaviors correct?
|-
| architecture
| Is the project structured coherently?
|-
| Python usage
| Does the implementation use appropriate Python constructs?
|-
| robustness
| Are expected failures handled?
|-
| testing
| Are important behaviors tested?
|-
| code quality
| Is the code readable and maintainable?
|-
| documentation
| Can the project be installed and used?
|-
| Git workflow
| Does the repository show meaningful development?
|-
| technical understanding
| Can the team explain its implementation and decisions?
|}

== 51. Functionality is necessary but not sufficient ==

A project that produces the correct output but contains:

* one giant file;
* no tests;
* hard-coded machine paths;
* undocumented dependencies;
* hidden credentials;
* unhandled errors;

is technically weaker than a project that also demonstrates software-engineering discipline.

== 52. Complexity is not automatically quality ==

Do not add complexity to appear advanced.

A smaller clear implementation is often better than:

* unnecessary inheritance;
* excessive abstraction layers;
* many external dependencies;
* unnecessary asynchronous code;
* complicated design patterns without a need.

Quality is not measured by the number of classes or libraries.

== 53. Pythonic implementation ==

The final implementation should reflect concepts from the course.

Examples include:

* direct iteration instead of unnecessary index loops;
* dataclasses for simple data models;
* context managers for resources;
* <code>pathlib</code> for paths;
* exceptions for meaningful failure conditions;
* modules with clear responsibilities;
* type hints where they improve interfaces;
* pytest for automated tests.

== 54. C++ translation should no longer dominate ==

By the final project, Python code should not look like a mechanical translation of C++.

For example:

{| class="wikitable" style="width:100%; table-layout:fixed;"
! style="width:50%;" | Less idiomatic
! style="width:50%;" | More idiomatic
|-
|
<syntaxhighlight lang="python">
for i in range(len(values)):
print(values[i])
</syntaxhighlight>
|
<syntaxhighlight lang="python">
for value in values:
print(value)
</syntaxhighlight>
|}

The same principle applies at architecture level.

== 55. Final code review checklist ==

Before submission, review:

{| class="wikitable" style="width:100%;"
! Area
! Check
|-
| naming
| names communicate intent
|-
| functions
| no obvious excessively large functions remain
|-
| classes
| responsibilities are coherent
|-
| modules
| responsibilities are clear
|-
| globals
| unnecessary mutable globals removed
|-
| errors
| expected failures handled
|-
| logging
| temporary debug output removed
|-
| paths
| machine-specific paths removed
|-
| secrets
| none committed
|-
| tests
| suite passes
|-
| documentation
| current and reproducible
|}

== 56. Final testing checklist ==

Run:

<syntaxhighlight lang="bash">
pytest
</syntaxhighlight>

Then, where configured:

<syntaxhighlight lang="bash">
ruff check .
ruff format --check .
mypy src
</syntaxhighlight>

Finally run the main application manually.

== 57. Final demonstration checklist ==

Before presenting:

<syntaxhighlight lang="text">
[ ] demo input available
[ ] application starts
[ ] dependencies installed
[ ] required hardware available
[ ] credentials/configuration available
[ ] output location writable
[ ] main workflow tested
[ ] failure example prepared
[ ] backup data available if needed
</syntaxhighlight>

== 58. Final documentation checklist ==

<syntaxhighlight lang="text">
[ ] README complete
[ ] installation tested
[ ] run command documented
[ ] configuration documented
[ ] test command documented
[ ] architecture explained
[ ] known limitations listed
[ ] sample input included where useful
</syntaxhighlight>

== 59. Final repository checklist ==

<syntaxhighlight lang="text">
[ ] git status clean
[ ] no .venv
[ ] no __pycache__
[ ] no secrets
[ ] no accidental large files
[ ] pyproject.toml correct
[ ] .gitignore correct
[ ] tests committed
[ ] documentation committed
[ ] final version committed
</syntaxhighlight>

== 60. Final submission ==

The final submission should identify the repository and the final revision clearly.

A submission should not depend on an uncommitted local working tree.

The evaluated state should correspond to a specific commit.

Optional:

<syntaxhighlight lang="bash">
git rev-parse HEAD
</syntaxhighlight>

can be used to record the exact commit identifier.

== 61. Submission commit ==

A possible final workflow is:

<syntaxhighlight lang="bash">
git status

pytest
ruff check .

git add .
git commit -m "Prepare final release"

git push
</syntaxhighlight>

Only commit if there are actual final changes.

== 62. Avoid last-minute uncontrolled changes ==

Immediately before the final demonstration, avoid:

* changing architecture;
* upgrading dependencies without need;
* replacing working libraries;
* rewriting central functionality;
* merging experimental branches.

Last-minute changes introduce unnecessary risk.

== 63. If a defect appears during the final session ==

If a non-critical problem appears:

# identify the scope;
# avoid destabilizing unrelated code;
# apply a minimal fix if safe;
# rerun relevant tests;
# document the issue if it cannot safely be fixed.

Do not perform a large redesign under presentation pressure.

== 64. If the demo fails ==

A failed demo should be approached technically.

Check:

<syntaxhighlight lang="text">
environment
configuration
dependencies
input
external service
hardware
recent code changes
logs
traceback
</syntaxhighlight>

If a prepared representative backup exists, it may be used to continue the technical discussion.

== 65. Future work ==

The final presentation may include a short future-work section.

Good examples:

* additional input formats;
* improved performance;
* GUI;
* hardware support;
* better deployment;
* more complete test coverage;
* additional algorithms.

Future work should not be used to disguise missing required functionality.

== 66. Lessons learned ==

Each team should be able to identify at least one useful technical lesson.

Examples:

<syntaxhighlight lang="text">
Separating I/O from processing made testing easier.

Hard-coded paths created portability problems.

Regression tests prevented a previously fixed bug from returning.

A smaller dependency set simplified installation.

Composition made the hardware interface easier to replace in tests.
</syntaxhighlight>

== 67. Individual understanding ==

Each student should be able to explain:

* the project objective;
* the architecture;
* the main workflow;
* at least one module in detail;
* at least one test;
* at least one error path.

The project should represent team work rather than isolated contributions that nobody else understands.

== 68. Suggested technical discussion ==

A final discussion may cover:

<syntaxhighlight lang="text">
Why this architecture?

What alternative was considered?

What was the hardest technical issue?

What would fail first at larger scale?

Which dependency is most critical?

Which component is easiest to replace?

Which part has the strongest tests?

Which part still has the largest limitation?
</syntaxhighlight>

== 69. Example final explanation ==

A concise technical explanation could be:

<syntaxhighlight lang="text">
The application reads thermal frames through
the acquisition module.

Frames are passed to the processing pipeline,
which performs correction and analysis.

The pipeline is independent from the camera
interface, so tests can use stored frames.

Results are returned to the CLI and can also
be saved through the storage module.

Hardware failures are converted into
application-specific exceptions at the
device boundary.
</syntaxhighlight>

This is more useful than describing source files in arbitrary order.

== 70. Final project maturity ==

A mature final project should demonstrate:

<syntaxhighlight lang="text">
correctness
+
structure
+
testing
+
robustness
+
documentation
+
technical understanding
</syntaxhighlight>

No single category replaces the others.

== 71. Exercise 1 — Final architecture explanation ==

Prepare a diagram containing no more than approximately 5–8 major components.

For every component, write one responsibility.

Practice explaining the architecture in less than two minutes.

== 72. Exercise 2 — Main workflow walkthrough ==

Trace one real input through the project.

Document:

<syntaxhighlight lang="text">
Input:
Entry point:
Modules involved:
Important transformation:
Output:
</syntaxhighlight>

Use this path during the code walkthrough.

== 73. Exercise 3 — Design decision ==

Choose one design decision and document:

<syntaxhighlight lang="text">
Decision:
Alternative:
Reason:
Advantage:
Disadvantage:
</syntaxhighlight>

Be prepared to explain it during evaluation.

== 74. Exercise 4 — Technical difficulty ==

Document:

<syntaxhighlight lang="text">
Problem:
Observed behavior:
Root cause:
Diagnostic method:
Solution:
Regression prevention:
</syntaxhighlight>

Use a real difficulty from the project.

== 75. Exercise 5 — Test walkthrough ==

Choose one meaningful test.

Explain:

* what behavior it verifies;
* why the behavior matters;
* whether it is a unit or integration test;
* what would happen if the implementation were broken.

== 76. Exercise 6 — Error-path walkthrough ==

Choose one predictable failure.

Trace:

<syntaxhighlight lang="text">
failure
↓
detection
↓
exception/error
↓
handling layer
↓
user/log output
</syntaxhighlight>

== 77. Exercise 7 — Clean installation ==

Using a fresh environment:

# install the project;
# run the tests;
# run the main workflow;
# compare the process with the README.

Correct any discrepancy.

== 78. Exercise 8 — Final repository audit ==

Run:

<syntaxhighlight lang="bash">
git status
git log --oneline --graph --decorate
</syntaxhighlight>

Confirm:

* final code is committed;
* tests are committed;
* documentation is committed;
* no sensitive data exists;
* no generated files are accidentally tracked.

== 79. Exercise 9 — Demonstration rehearsal ==

Perform the demonstration exactly as it will be shown.

Measure whether it is concise enough.

Record any manual step that could fail.

Simplify the demonstration where possible.

== 80. Exercise 10 — Final self-review ==

Answer:

<syntaxhighlight lang="text">
What is the strongest part of the project?

What is the weakest part?

What is the most important limitation?

What would you improve with one more week?

Which technical decision are you most prepared to defend?
</syntaxhighlight>

The answers should be based on the actual implementation.

== 81. Final evaluation checklist ==

{| class="wikitable" style="width:100%;"
! Area
! Final question
|-
| objective
| Is the project goal clear?
|-
| functionality
| Does the primary workflow work?
|-
| architecture
| Can the structure be explained clearly?
|-
| Python
| Is the implementation appropriate for Python?
|-
| robustness
| Are expected failures handled?
|-
| testing
| Are important behaviors tested?
|-
| reproducibility
| Can the project be installed from documentation?
|-
| repository
| Is the submitted state clean and complete?
|-
| documentation
| Is usage sufficiently explained?
|-
| understanding
| Can the team explain its own code and decisions?
|}

== 82. Course summary ==

Across the seven laboratories, the progression has been:

<syntaxhighlight lang="text">
Lab 1
Python syntax and idioms
↓
Lab 2
Object-oriented Python
↓
Lab 3
Modules, files, exceptions and typing
↓
Lab 4
Testing and software quality
↓
Lab 5
Project architecture and MVP
↓
Lab 6
Stabilization and release candidate
↓
Lab 7
Final integration and demonstration
</syntaxhighlight>

The objective of the course is therefore not only to learn Python syntax.

It is to move from:

<syntaxhighlight lang="text">
C/C++ programmer
</syntaxhighlight>

toward:

<syntaxhighlight lang="text">
Python software developer
</syntaxhighlight>

who can write code that is:

* readable;
* modular;
* testable;
* robust;
* reproducible;
* maintainable.

== 83. Final principle ==

<blockquote>
The final project should not only work. Another developer should be able to understand what it does, install it, run it, test it and modify it without depending on undocumented knowledge from the original authors.
</blockquote>

== 84. Final submission checklist ==

Before leaving the final laboratory:

<syntaxhighlight lang="text">
[ ] final repository pushed
[ ] final commit identified
[ ] tests pass
[ ] main workflow demonstrated
[ ] README complete
[ ] known limitations documented
[ ] repository clean
[ ] no secrets committed
[ ] project can be installed reproducibly
[ ] all team members understand the main architecture
</syntaxhighlight>

The project is then ready for final submission.

Lab 6

Andrei.ulmamei — Sat, 26 Sep 2026 10:12:53 GMT

Pagină nouă: = Lab 6 — Project Development II = == Objectives == This laboratory continues the supervised development of the semester project. The objective is to move from a working minim...

Pagină nouă

= Lab 6 — Project Development II =

== Objectives ==

This laboratory continues the supervised development of the semester project.

The objective is to move from a working minimum viable product to a stable '''release candidate'''.

At this stage, the central functionality should already exist. The focus is therefore on completing missing features, improving reliability, removing technical debt, expanding tests, documenting the project and ensuring that another person can install and run it reproducibly.

After completing this laboratory, you should be able to:

* identify and prioritize remaining work;
* distinguish critical defects from optional improvements;
* complete the central functionality of the project;
* add regression tests for discovered bugs;
* test important edge cases;
* refactor code safely using tests;
* improve logging and diagnostics;
* improve project documentation;
* validate installation from a clean environment;
* verify dependency declarations;
* document known limitations;
* prepare a stable release candidate.

Most of the laboratory should be spent working directly on the project.

__TOC__

== 1. Laboratory structure ==

{| class="wikitable" style="width:100%;"
! Time
! Activity
|-
| 0–15 min
| Project status and remaining-work review
|-
| 15–30 min
| Short discussion: release quality and regression testing
|-
| 30–90 min
| Supervised implementation and refactoring
|-
| 90–105 min
| Test and documentation review
|-
| 105–120 min
| Release-candidate verification
|}

== 2. From MVP to release candidate ==

The MVP demonstrated that the main technical idea works.

A release candidate should demonstrate that the project is close to final delivery.

<syntaxhighlight lang="text">
prototype
↓
MVP
↓
feature complete
↓
tested
↓
documented
↓
release candidate
↓
final release
</syntaxhighlight>

A release candidate does not need to be perfect, but no major known defect should prevent the primary workflow from operating correctly.

== 3. Feature completeness ==

Before adding new features, classify remaining work.

{| class="wikitable" style="width:100%;"
! Category
! Meaning
|-
| required
| necessary for the project to satisfy its main objective
|-
| important
| significantly improves usability or robustness
|-
| optional
| useful enhancement but not required
|-
| experimental
| interesting idea that may not be stable enough for final integration
|}

Required functionality should be completed before optional extensions.

== 4. Priority levels ==

A simple priority system is sufficient.

{| class="wikitable" style="width:100%;"
! Priority
! Meaning
|-
| P0
| application cannot perform its primary function
|-
| P1
| major defect affecting normal use
|-
| P2
| important improvement or non-critical defect
|-
| P3
| optional improvement
|}

P0 and P1 issues should be resolved before adding new optional features.

== 5. Remaining-work list ==

Maintain a short actionable list.

<syntaxhighlight lang="text">
[ ] Handle malformed input
[ ] Add timeout handling
[ ] Add pipeline tests
[ ] Document configuration
[ ] Remove debug output
[ ] Verify clean installation
</syntaxhighlight>

Avoid vague items such as:

<syntaxhighlight lang="text">
[ ] Improve code
[ ] Fix things
[ ] Finish project
</syntaxhighlight>

== 6. Stable software before more features ==

At this stage, a smaller stable project is generally preferable to a larger unstable one.

Prefer:

<syntaxhighlight lang="text">
working feature A
working feature B
working feature C
</syntaxhighlight>

over:

<syntaxhighlight lang="text">
feature A mostly works
feature B sometimes works
feature C works
feature D unfinished
feature E experimental
</syntaxhighlight>

== 7. Regression testing ==

When a defect is discovered:

<syntaxhighlight lang="text">
discover bug
↓
reproduce bug
↓
write failing test
↓
fix implementation
↓
test passes
↓
keep test permanently
</syntaxhighlight>

The resulting test is a '''regression test'''.

== 8. Regression test example ==

Suppose:

<syntaxhighlight lang="python">
def average(values):
return sum(values) / len(values)
</syntaxhighlight>

The function fails incorrectly for an empty list.

Add a test:

<syntaxhighlight lang="python">
import pytest

def test_average_rejects_empty_list():
with pytest.raises(ValueError):
average([])
</syntaxhighlight>

Then update the function:

<syntaxhighlight lang="python">
def average(values):
if not values:
raise ValueError(
"values cannot be empty"
)

return sum(values) / len(values)
</syntaxhighlight>

The test should remain in the project after the defect is fixed.

== 9. Edge-case review ==

Normal input is not sufficient.

For numerical data, consider:

<syntaxhighlight lang="text">
minimum valid value
maximum valid value
zero
negative values
very large values
empty input
one-element input
</syntaxhighlight>

For text:

<syntaxhighlight lang="text">
empty string
whitespace-only string
Unicode characters
very long strings
unexpected encoding
</syntaxhighlight>

For files:

<syntaxhighlight lang="text">
missing file
empty file
malformed file
permission error
missing output directory
unexpected format
</syntaxhighlight>

== 10. Network projects ==

Network projects should consider:

* connection refused;
* timeout;
* server unavailable;
* malformed response;
* unexpected status code;
* lost connection;
* incomplete message.

Do not assume every network operation succeeds.

== 11. Hardware projects ==

Hardware projects should consider:

* device unavailable;
* device disconnected;
* incomplete data;
* invalid data;
* timeout;
* permission error;
* unsupported device or firmware version.

Expected hardware failures should produce understandable application behavior.

== 12. Image-processing projects ==

Image-processing projects should consider:

* unsupported format;
* invalid dimensions;
* empty image;
* grayscale versus color input;
* unexpected channel count;
* corrupted input;
* very large images.

Validate assumptions close to the input boundary.

== 13. Public behavior versus implementation detail ==

Tests should focus on public behavior.

Prefer:

<syntaxhighlight lang="python">
result = process(image)

assert result.shape == expected_shape
</syntaxhighlight>

over:

<syntaxhighlight lang="python">
assert processor._temporary_buffer == ...
</syntaxhighlight>

Private implementation details should remain free to change during refactoring.

== 14. Do not delete inconvenient tests ==

If a valid test fails after a code change, investigate the reason.

A test should normally be removed only when:

* the requirement changed;
* the tested behavior no longer exists;
* the test itself is incorrect.

== 15. Test organization ==

A larger project can organize tests by component:

<syntaxhighlight lang="text">
tests/
├── test_models.py
├── test_services.py
├── test_storage.py
├── test_protocol.py
└── test_pipeline.py
</syntaxhighlight>

For larger projects:

<syntaxhighlight lang="text">
tests/
├── unit/
│ ├── test_filters.py
│ └── test_protocol.py
└── integration/
├── test_storage.py
└── test_pipeline.py
</syntaxhighlight>

Use the simplest structure that remains understandable.

== 16. Unit versus integration tests ==

{| class="wikitable" style="width:100%;"
! Example
! Type
|-
| validate one grade value
| unit
|-
| decode one packet
| unit
|-
| encode and then decode a packet
| integration
|-
| save and reload data from a temporary file
| integration
|-
| run a complete processing pipeline
| integration
|}

Both kinds of tests are useful.

== 17. End-to-end testing ==

An end-to-end test exercises a complete workflow.

<syntaxhighlight lang="text">
input
↓
application
↓
processing
↓
output
</syntaxhighlight>

End-to-end tests are valuable but should not replace focused unit tests.

== 18. Testing CLI applications ==

Separate argument parsing from application logic.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! style="width:50%;" | Tightly coupled
! style="width:50%;" | Easier to test
|-
|
<syntaxhighlight lang="python">
def main():
args = parse_args()

# All processing here.
...
</syntaxhighlight>
|
<syntaxhighlight lang="python">
def process_file(
input_path,
output_path,
):
...

def main():
args = parse_args()

process_file(
args.input,
args.output,
)
</syntaxhighlight>
|}

The processing function can now be tested without command-line parsing.

== 19. Deterministic tests ==

Good tests produce the same result every time under the same conditions.

Avoid uncontrolled dependencies on:

* current time;
* random values;
* network availability;
* arbitrary filesystem state;
* execution order.

For controlled randomness:

<syntaxhighlight lang="python">
import random

rng = random.Random(1234)
</syntaxhighlight>

== 20. Refactoring with tests ==

Use short cycles:

<syntaxhighlight lang="text">
run tests
↓
all pass
↓
small refactor
↓
run tests
↓
all pass
↓
commit
</syntaxhighlight>

Do not perform a very large refactoring before checking whether behavior is still correct.

== 21. Refactoring nested control flow ==

Before:

<syntaxhighlight lang="python">
def process(record):
if record is not None:
if record.valid:
if record.enabled:
return transform(record)

return None
</syntaxhighlight>

Using guard clauses:

<syntaxhighlight lang="python">
def process(record):
if record is None:
return None

if not record.valid:
return None

if not record.enabled:
return None

return transform(record)
</syntaxhighlight>

The second version reduces nesting.

== 22. Refactoring long conditions ==

Before:

<syntaxhighlight lang="python">
if (
device.connected
and device.enabled
and not device.error
and device.temperature < 80
and device.mode == "ready"
):
...
</syntaxhighlight>

After:

<syntaxhighlight lang="python">
def is_ready(device):
return (
device.connected
and device.enabled
and not device.error
and device.temperature < 80
and device.mode == "ready"
)

if is_ready(device):
...
</syntaxhighlight>

The function name expresses the meaning of the condition.

== 23. Structured data instead of loose dictionaries ==

For stable domain data, a dataclass may be clearer than an unstructured dictionary.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! style="width:50%;" | Dictionary
! style="width:50%;" | Dataclass
|-
|
<syntaxhighlight lang="python">
student = {
"name": "Alice",
"grade": 9.5,
"year": 2,
}
</syntaxhighlight>
|
<syntaxhighlight lang="python">
from dataclasses import dataclass

@dataclass
class Student:
name: str
grade: float
year: int
</syntaxhighlight>
|}

Do not convert every dictionary into a class. Use the structure that best represents the data.

== 24. Avoid over-refactoring ==

Refactor when it improves:

* clarity;
* correctness;
* maintainability;
* testability;
* reuse.

Do not introduce abstractions simply to make the architecture appear more complicated.

== 25. Logging review ==

Search for temporary debug output such as:

<syntaxhighlight lang="text">
print("debug")
print(variable)
print("here")
print("test")
</syntaxhighlight>

For each occurrence, decide whether it should be:

* removed;
* replaced with logging;
* retained as intentional user output.

== 26. Logging levels ==

{| class="wikitable" style="width:100%;"
! Level
! Typical use
|-
| DEBUG
| detailed internal processing information
|-
| INFO
| normal application events
|-
| WARNING
| unusual condition from which execution can continue
|-
| ERROR
| requested operation failed
|-
| CRITICAL
| application cannot continue
|}

== 27. Useful logging context ==

Poor:

<syntaxhighlight lang="python">
logger.error("Failed")
</syntaxhighlight>

Better:

<syntaxhighlight lang="python">
logger.error(
"Failed to load configuration from %s",
path,
)
</syntaxhighlight>

Diagnostic messages should contain enough context to be useful.

== 28. Exception logging ==

Inside an exception handler:

<syntaxhighlight lang="python">
try:
load_device()
except DeviceError:
logger.exception(
"Device initialization failed"
)
raise
</syntaxhighlight>

<code>logger.exception()</code> includes traceback information.

== 29. User-facing errors ==

Expected errors should usually produce concise user-facing messages.

For example:

<syntaxhighlight lang="text">
Error: input file 'data.json' does not exist.
</syntaxhighlight>

A predictable user error does not normally require displaying an internal traceback.

== 30. Documentation layers ==

{| class="wikitable" style="width:100%;"
! Documentation
! Audience
|-
| README
| user or developer starting the project
|-
| docstrings
| developer using functions and classes
|-
| comments
| developer understanding non-obvious implementation decisions
|-
| release notes
| user/evaluator understanding changes and limitations
|}

== 31. README checklist ==

The README should include:

* project name;
* short description;
* main features;
* requirements;
* installation;
* configuration;
* how to run;
* example usage;
* how to run tests;
* high-level architecture;
* known limitations.

== 32. Reproducible installation ==

Installation instructions should be explicit.

<syntaxhighlight lang="bash">
git clone ...
cd project

python -m venv .venv
source .venv/bin/activate

python -m pip install -e .
</syntaxhighlight>

Windows PowerShell:

<syntaxhighlight lang="powershell">
.venv\Scripts\Activate.ps1
</syntaxhighlight>

== 33. Running instructions ==

Document the actual command.

For example:

<syntaxhighlight lang="bash">
python -m project_name
</syntaxhighlight>

or:

<syntaxhighlight lang="bash">
python -m project_name \
--input data/input.json \
--output results/output.json
</syntaxhighlight>

== 34. Document configuration ==

If a project uses:

<syntaxhighlight lang="json">
{
"server": "localhost",
"port": 8000,
"timeout": 5.0
}
</syntaxhighlight>

document every field.

{| class="wikitable" style="width:100%;"
! Field
! Meaning
|-
| <code>server</code>
| remote server hostname
|-
| <code>port</code>
| remote service port
|-
| <code>timeout</code>
| request timeout in seconds
|}

== 35. Environment variables ==

Do not document or commit real secrets.

Document variable names:

<syntaxhighlight lang="text">
API_KEY
SERVER_URL
LOG_LEVEL
</syntaxhighlight>

Example:

<syntaxhighlight lang="bash">
export API_KEY="..."
</syntaxhighlight>

== 36. Docstrings ==

Use docstrings when behavior is not obvious.

<syntaxhighlight lang="python">
def normalize(
values: list[float],
) -> list[float]:
'''Scale values to the interval [0, 1].

Raises:
ValueError: If all values are equal.
'''
...
</syntaxhighlight>

Do not duplicate obvious type information already expressed by type hints.

== 37. Public versus internal API ==

Internal names can begin with an underscore.

<syntaxhighlight lang="python">
def _parse_header(data):
...

def load_frame(path):
...
</syntaxhighlight>

This indicates that <code>_parse_header()</code> is an implementation detail.

== 38. Keep the public API small ==

Prefer a small meaningful interface:

<syntaxhighlight lang="python">
load_image()
process_image()
save_image()
</syntaxhighlight>

rather than exposing every internal intermediate operation.

== 39. Clean-environment verification ==

Do not rely on globally installed packages.

A useful verification is:

<syntaxhighlight lang="bash">
python -m venv test-env
source test-env/bin/activate

python -m pip install -e .
pytest
</syntaxhighlight>

If this fails, installation instructions or dependency declarations are incomplete.

== 40. Verify declared dependencies ==

If code contains:

<syntaxhighlight lang="python">
import requests
import numpy
</syntaxhighlight>

the required packages must be declared in project metadata.

Another machine should not depend on packages that happened to be installed on the developer's system.

== 41. Remove unused dependencies ==

If the project declares:

<syntaxhighlight lang="toml">
dependencies = [
"requests",
"numpy",
"pandas",
"matplotlib",
"opencv-python",
]
</syntaxhighlight>

but only uses <code>requests</code> and <code>numpy</code>, remove unnecessary packages.

== 42. Version constraints ==

Avoid unnecessarily strict pinning unless required.

Possibly too strict:

<syntaxhighlight lang="toml">
dependencies = [
"requests==2.32.4",
]
</syntaxhighlight>

Potentially more flexible:

<syntaxhighlight lang="toml">
dependencies = [
"requests>=2.32,<3",
]
</syntaxhighlight>

The exact constraint depends on project compatibility requirements.

== 43. Supported Python version ==

Declare the expected Python version:

<syntaxhighlight lang="toml">
[project]
requires-python = ">=3.11"
</syntaxhighlight>

Do not claim compatibility with an older version while using unsupported newer syntax.

== 44. Clean repository ==

The repository should generally exclude generated content such as:

<syntaxhighlight lang="text">
.venv/
__pycache__/
*.pyc
.coverage
.pytest_cache/
.mypy_cache/
.ruff_cache/
build/
dist/
</syntaxhighlight>

== 45. Example .gitignore ==

<syntaxhighlight lang="text">
.venv/
__pycache__/
*.pyc

.pytest_cache/
.mypy_cache/
.ruff_cache/

.coverage
htmlcov/

build/
dist/
*.egg-info/
</syntaxhighlight>

Add project-specific generated files where appropriate.

== 46. Sample data ==

If the project requires sample input for demonstration, include a small suitable example.

<syntaxhighlight lang="text">
examples/
├── sample_input.json
└── expected_output.json
</syntaxhighlight>

Do not rely on private local data that cannot be reproduced.

== 47. Sample configuration ==

For machine-specific configuration, provide:

<syntaxhighlight lang="text">
config.example.json
</syntaxhighlight>

rather than committing real credentials in:

<syntaxhighlight lang="text">
config.json
</syntaxhighlight>

== 48. Security review ==

Check for accidental secrets:

* passwords;
* API keys;
* private keys;
* access tokens;
* database credentials;
* credential-bearing URLs.

If a credential was committed, removing it from the latest version may not be sufficient. The credential should be rotated.

== 49. Input validation review ==

Review every external input boundary:

* command-line arguments;
* configuration;
* files;
* network messages;
* user input;
* hardware data;
* API responses.

Ask:

<syntaxhighlight lang="text">
What assumptions does this code make?
</syntaxhighlight>

Validate important assumptions before processing the data.

== 50. Serialization round trip ==

If data is stored and later loaded, test a round trip.

<syntaxhighlight lang="text">
object
↓
serialize
↓
file
↓
deserialize
↓
object
</syntaxhighlight>

Example:

<syntaxhighlight lang="python">
def test_round_trip(tmp_path):
path = tmp_path / "data.json"

original = [
Student("Alice", 9.5),
Student("Bob", 8.0),
]

save_students(path, original)

restored = load_students(path)

assert restored == original
</syntaxhighlight>

== 51. Performance sanity check ==

Full optimization is not required, but the application should be tested on representative input.

If the intended workload is:

<syntaxhighlight lang="text">
100000 records
100 images
continuous packets
large matrices
</syntaxhighlight>

do not test only with one tiny input and assume performance is acceptable.

== 52. Resource review ==

Check for:

* files left open;
* sockets not closed;
* unnecessary large copies;
* unbounded queues/lists;
* repeated loading of large data;
* infinite retry loops;
* threads or processes not terminated.

Use context managers where appropriate.

== 53. Graceful shutdown ==

Applications managing external resources should stop predictably.

Example:

<syntaxhighlight lang="python">
try:
application.run()
finally:
application.close()
</syntaxhighlight>

When appropriate, make resources context managers.

== 54. Keyboard interrupt ==

A CLI application may handle <code>Ctrl+C</code> cleanly:

<syntaxhighlight lang="python">
def main():
try:
run()
except KeyboardInterrupt:
print("\nInterrupted.")
</syntaxhighlight>

Only add this behavior when it improves the application.

== 55. Release version ==

The project should have a version identifier.

<syntaxhighlight lang="toml">
[project]
version = "0.9.0"
</syntaxhighlight>

A release candidate can be described as:

<syntaxhighlight lang="text">
0.9.0-rc1
</syntaxhighlight>

== 56. Release notes ==

A short release note can contain:

<syntaxhighlight lang="text">
Version
Main features
Important fixes
Known limitations
Installation notes
</syntaxhighlight>

It does not need to be long.

== 57. Known limitations ==

Document real limitations explicitly.

Examples:

<syntaxhighlight lang="text">
Only PNG input is supported.
IPv6 is not supported.
The program has only been tested on Linux.
Maximum tested image size is 4096×4096.
Device reconnect requires restart.
</syntaxhighlight>

== 58. Known issue versus critical defect ==

A known issue may remain if:

* it does not prevent the primary workflow;
* its scope is clear;
* fixing it immediately would create disproportionate risk.

A critical defect should not simply be renamed a limitation.

== 59. Manual acceptance test ==

In addition to automated tests, perform a manual end-to-end test.

<syntaxhighlight lang="text">
[ ] clean startup
[ ] representative input accepted
[ ] main feature works
[ ] output correct
[ ] expected error handled
[ ] application exits cleanly
</syntaxhighlight>

== 60. Clean-machine test ==

Ask:

<syntaxhighlight lang="text">
Could another student clone this repository
and run the project using only the README?
</syntaxhighlight>

Test it:

# create a clean environment;
# install dependencies;
# run tests;
# start the application;
# follow only documented steps.

== 61. Project review checklist ==

{| class="wikitable" style="width:100%;"
! Area
! Question
|-
| features
| Are all required features implemented?
|-
| defects
| Are any P0 or P1 defects open?
|-
| tests
| Are central behavior and major failures tested?
|-
| architecture
| Is remaining technical debt acceptable?
|-
| logging
| Are diagnostics useful and appropriately leveled?
|-
| errors
| Are expected failures handled?
|-
| documentation
| Can another user install and run the project?
|-
| dependencies
| Are all required packages declared?
|-
| repository
| Is generated and sensitive content excluded?
|-
| release
| Can the application be demonstrated reliably?
|}

== 62. Exercise 1 — Remaining-work triage ==

List all remaining tasks.

Assign:

<syntaxhighlight lang="text">
P0
P1
P2
P3
</syntaxhighlight>

Resolve P0 and P1 issues before optional work.

== 63. Exercise 2 — Regression test ==

Choose one defect discovered since Lab 5.

Then:

# reproduce the defect;
# add a failing automated test;
# fix the implementation;
# confirm the new test passes;
# run the complete test suite.

== 64. Exercise 3 — Edge-case audit ==

Choose the most important input to the project.

Document at least five edge cases.

{| class="wikitable" style="width:100%;"
! Input
! Expected behavior
|-
| empty input
| clear validation error or defined empty result
|-
| valid minimal input
| processed successfully
|-
| malformed input
| parsing error reported
|-
| missing input
| missing-resource error
|-
| large representative input
| completes within reasonable resources
|}

Add missing tests where practical.

== 65. Exercise 4 — Test-suite cleanup ==

Review the test suite for:

* duplicated setup;
* unclear names;
* order dependencies;
* permanent local test files;
* unnecessary real network access;
* missing assertions;
* disabled tests.

Refactor where appropriate.

== 66. Exercise 5 — Refactoring checkpoint ==

Choose one area with technical debt:

* long function;
* large class;
* duplicated logic;
* deep nesting;
* hard-coded configuration;
* global state.

Use:

<syntaxhighlight lang="text">
tests pass
↓
small refactor
↓
tests pass
↓
commit
</syntaxhighlight>

== 67. Exercise 6 — Logging audit ==

Search for:

<syntaxhighlight lang="text">
print(
logger.debug(
logger.info(
logger.warning(
logger.error(
logger.exception(
</syntaxhighlight>

Check that:

* user output intentionally uses <code>print()</code>;
* diagnostics use logging;
* levels are appropriate;
* errors include context;
* secrets are never logged.

== 68. Exercise 7 — README installation test ==

Follow the README in a clean environment.

Record every missing step.

Update the README until no undocumented knowledge is required to start the project.

== 69. Exercise 8 — Dependency verification ==

Create a fresh virtual environment.

Install the project using its documented procedure.

Then run:

<syntaxhighlight lang="bash">
pytest
ruff check .
</syntaxhighlight>

If used by the project:

<syntaxhighlight lang="bash">
mypy src
</syntaxhighlight>

Fix dependency or configuration problems.

== 70. Exercise 9 — Repository audit ==

Run:

<syntaxhighlight lang="bash">
git status
</syntaxhighlight>

Inspect the repository for:

* virtual environments;
* caches;
* generated output;
* secrets;
* large temporary files;
* local configuration;
* editor-specific files.

Update <code>.gitignore</code> if required.

== 71. Exercise 10 — Known limitations ==

Add:

<syntaxhighlight lang="text">
## Known limitations
</syntaxhighlight>

to the README.

List only real limitations of the current implementation.

== 72. Exercise 11 — Release notes ==

Write:

<syntaxhighlight lang="text">
Release candidate: 0.9

Implemented:
- ...

Fixed:
- ...

Known limitations:
- ...

Run:
- ...
</syntaxhighlight>

== 73. Exercise 12 — Acceptance test ==

Execute the complete main workflow.

Record:

<syntaxhighlight lang="text">
Input:
Command:
Expected output:
Actual output:
Result: PASS / FAIL
</syntaxhighlight>

A failure in the primary workflow should be treated as a high-priority issue.

== 74. Release-candidate requirements ==

By the end of Lab 6:

{| class="wikitable" style="width:100%;"
! Requirement
! Expected state
|-
| core functionality
| complete
|-
| P0 defects
| none known
|-
| P1 defects
| ideally none
|-
| tests
| central functionality and major failures covered
|-
| regression tests
| added for important discovered defects
|-
| documentation
| installation and usage complete
|-
| dependencies
| reproducible in a clean environment
|-
| logging
| temporary debug output removed
|-
| repository
| clean and free of secrets
|-
| limitations
| explicitly documented
|-
| demonstration
| repeatable end-to-end
|}

== 75. Instructor review ==

{| class="wikitable" style="width:100%;"
! Area
! Review question
|-
| stability
| Does the primary workflow work consistently?
|-
| completeness
| Are required features implemented?
|-
| testing
| Are important edge cases tested?
|-
| regression
| Were discovered defects converted into tests?
|-
| design
| Is the architecture still understandable?
|-
| documentation
| Can the project be installed without assistance?
|-
| robustness
| Are predictable failures handled?
|-
| release readiness
| Can the team demonstrate the project reliably?
|}

== 76. C/C++ habits to reconsider ==

{| class="wikitable" style="width:100%;"
! C/C++ habit
! Typical Python project approach
|-
| rely mainly on compile success
| verify tests, linting and runtime behavior
|-
| test manually only at the end
| maintain regression tests continuously
|-
| treat documentation as optional
| document installation, configuration and execution
|-
| assume the developer machine represents deployment
| verify in a clean virtual environment
|-
| leave debug output in code
| use structured logging
|-
| keep redesigning until submission
| stabilize architecture before final delivery
|-
| add features until the last moment
| freeze core features and focus on reliability
|}

== 77. Feature freeze ==

After Lab 6, the project should enter a practical '''feature freeze'''.

This means:

* no major architecture changes;
* no unnecessary new dependencies;
* no large experimental features;
* focus on defects;
* focus on documentation;
* focus on final demonstration reliability.

Small low-risk improvements may still be made.

== 78. Final preparation order ==

A useful order is:

<syntaxhighlight lang="text">
critical defects
↓
required features
↓
tests
↓
documentation
↓
clean installation
↓
demo preparation
↓
optional polish
</syntaxhighlight>

Do not prioritize presentation polish while critical project defects remain.

== 79. Summary ==

Lab 6 is primarily a stabilization laboratory.

The project should move from:

<syntaxhighlight lang="text">
"It basically works."
</syntaxhighlight>

to:

<syntaxhighlight lang="text">
"It can be installed,
tested,
run,
demonstrated,
and understood
by another person."
</syntaxhighlight>

The central idea is:

<blockquote>
A release candidate is not simply code with all planned features. It is software whose behavior, dependencies, limitations and execution procedure are sufficiently controlled to be demonstrated and evaluated reliably.
</blockquote>

== 80. Preparation for Lab 7 ==

Before the final laboratory:

# freeze the main feature set;
# fix remaining critical defects;
# run the complete automated test suite;
# perform a clean-environment installation;
# verify the README;
# document known limitations;
# prepare a stable demonstration dataset or scenario;
# ensure the demonstration does not depend on unavailable external resources;
# prepare a concise architecture explanation;
# prepare to explain one important design decision;
# prepare to explain one significant technical difficulty.

In '''Lab 7''', each team will perform the final demonstration, code walkthrough and technical discussion.

Lab 5

Andrei.ulmamei — Mon, 14 Sep 2026 06:22:15 GMT

Pagină nouă: = Lab 5 — Project Development I = == Objectives == This laboratory marks the transition from language-oriented laboratories to supervised project development. The main objecti...

Afișare diferențe

Lab 4

Andrei.ulmamei — Mon, 14 Sep 2026 06:15:53 GMT

Pagină nouă: = Lab 4 — Testing, Debugging and Software Quality = == Objectives == This laboratory introduces software testing and quality practices for Python projects. Students already kn...

Afișare diferențe

Lab 3

Andrei.ulmamei — Mon, 14 Sep 2026 06:07:52 GMT

Pagină nouă: = Lab 3 — Modules, Packages, Files, Exceptions and Type Hints = == Objectives == This laboratory moves from individual Python scripts and classes to the structure of complete P...

Afișare diferențe

Lab 2

Andrei.ulmamei — Mon, 14 Sep 2026 06:01:20 GMT

Pagină nouă: = Lab 2 — Object-Oriented Programming in Python = == Objectives == This laboratory introduces object-oriented programming in Python to students who already know object-oriented...

Afișare diferențe

Python Project

Andrei.ulmamei — Mon, 14 Sep 2026 05:54:59 GMT

Python Project

Lab 1

Andrei.ulmamei — Mon, 14 Sep 2026 05:51:19 GMT

Lab 1 — Python for C/C++ Programmers

Afișare diferențe

Lab 1

Andrei.ulmamei — Mon, 14 Sep 2026 05:20:38 GMT

Pagină nouă: = Lab 1 — Python for C/C++ Programmers = == Objectives == The purpose of this laboratory is to introduce Python to students who already have experience with procedural programm...

Pagină nouă

= Lab 1 — Python for C/C++ Programmers =

== Objectives ==

The purpose of this laboratory is to introduce Python to students who already have experience with procedural programming in C and object-oriented programming in C++.

The focus is therefore not on learning programming concepts from scratch, but on understanding how concepts already familiar from C/C++ are expressed in Python.

After completing this laboratory, you should be able to:

* understand the basic syntax of Python;
* recognize the main differences between Python and C/C++;
* work with Python's fundamental data types;
* use conditional statements and loops;
* work with lists, dictionaries, sets and tuples;
* define and call functions;
* understand basic Python object/reference semantics;
* recognize several common Python idioms;
* create and execute a simple Python project.

Throughout this laboratory, equivalent or similar C/C++ and Python code will be presented side by side.

**TOC**

== 1. Running a Python program ==

A C/C++ program normally has to be compiled before it is executed. Python programs are usually executed directly by the Python interpreter.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! style="width:50%;" | C/C++
! style="width:50%;" | Python
|-
| <syntaxhighlight lang="cpp">
#include <iostream>

int main()
{
std::cout << "Hello, world!\n";
return 0;
} </syntaxhighlight>
| <syntaxhighlight lang="python">
print("Hello, world!") </syntaxhighlight>
|}

A Python source file normally uses the extension:

<syntaxhighlight lang="text">
.py
</syntaxhighlight>

For example:

<syntaxhighlight lang="text">
hello.py
</syntaxhighlight>

It can be executed using:

<syntaxhighlight lang="bash">
python3 hello.py
</syntaxhighlight>

Unlike C/C++, Python does not require a special <code>main()</code> function.

However, larger Python programs commonly use:

{| class="wikitable" style="width:100%; table-layout:fixed;"
! style="width:50%;" | C/C++
! style="width:50%;" | Python
|-
| <syntaxhighlight lang="cpp">
#include <iostream>

int main()
{
std::cout << "Program started\n";

```
return 0;
```

} </syntaxhighlight>
| <syntaxhighlight lang="python">
def main():
print("Program started")

if **name** == "**main**":
main() </syntaxhighlight>
|}

The Python version is not mandatory, but this pattern will become useful when programs are split into multiple modules.

== 2. Blocks and indentation ==

In C and C++, braces delimit blocks of code.

Python uses '''indentation''' instead.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
if (x > 10) {
std::cout << "Large\n";
std::cout << "Value: " << x << "\n";
}
</syntaxhighlight>
|
<syntaxhighlight lang="python">
if x > 10:
print("Large")
print("Value:", x)
</syntaxhighlight>
|}

Indentation in Python is part of the language syntax.

The standard convention is '''4 spaces per indentation level'''.

For example, the following code is incorrect:

<syntaxhighlight lang="python">
if x > 10:
print("Large")
</syntaxhighlight>

Python will report an <code>IndentationError</code>.

== 3. Variables and types ==

C/C++ variables have a declared static type.

Python variables do not require explicit type declarations.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
int count = 10;
double temperature = 23.5;
bool enabled = true;
std::string name = "Alice";
</syntaxhighlight>
|
<syntaxhighlight lang="python">
count = 10
temperature = 23.5
enabled = True
name = "Alice"
</syntaxhighlight>
|}

Python is '''dynamically typed'''.

This means that a variable name can later refer to an object of another type.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
int value = 10;

// Not allowed:
// value = "hello"; </syntaxhighlight>
| <syntaxhighlight lang="python">
value = 10
value = "hello" </syntaxhighlight>
|}

This does '''not''' mean that Python has no types.

Objects still have types:

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
int value = 10;

std::cout << typeid(value).name(); </syntaxhighlight>
| <syntaxhighlight lang="python">
value = 10

print(type(value)) </syntaxhighlight>
|}

Python will produce:

<syntaxhighlight lang="text">
<class 'int'>
</syntaxhighlight>

=== Common basic types ===

{| class="wikitable"
! C/C++ type
! Python equivalent

| ! Example |
| ---------------------------------------- |
| <code>int</code> |
| <code>int</code> |
| <code>42</code> |
| - |
| <code>float</code> / <code>double</code> |
| <code>float</code> |
| <code>3.14</code> |
| - |
| <code>bool</code> |
| <code>bool</code> |
| <code>True</code>, <code>False</code> |
| - |
| <code>char</code> |
| no separate character type |
| <code>"A"</code> |
| - |
| <code>std::string</code> |
| <code>str</code> |
| <code>"Hello"</code> |
| - |
| <code>nullptr</code> |
| <code>None</code> |
| <code>None</code> |
| } |

== 4. Constants ==

C++ can enforce that a value cannot be modified using <code>const</code>.

Python does not enforce constants at language level.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
const double PI = 3.1415926535;
const int MAX_USERS = 100;
</syntaxhighlight>
|
<syntaxhighlight lang="python">
PI = 3.1415926535
MAX_USERS = 100
</syntaxhighlight>
|}

By convention, Python names that should be treated as constants are written using uppercase letters.

Nothing prevents the programmer from changing them.

== 5. Arithmetic operators ==

Most arithmetic operators are identical.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
int a = 10;
int b = 3;

int sum = a + b;
int diff = a - b;
int prod = a * b;
int div = a / b;
int rem = a % b; </syntaxhighlight>
| <syntaxhighlight lang="python">
a = 10
b = 3

sum_ = a + b
diff = a - b
prod = a * b
div = a // b
rem = a % b </syntaxhighlight>
|}

There is an important difference between <code>/</code> and <code>//</code>.

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
int a = 10;
int b = 3;

std::cout << a / b; // 3 </syntaxhighlight>
| <syntaxhighlight lang="python">
a = 10
b = 3

print(a / b) # 3.3333333333333335
print(a // b) # 3 </syntaxhighlight>
|}

Python also provides an exponentiation operator:

{| class="wikitable" style="width:100%; table-layout:fixed;"
! C/C++

| ! Python |
| -------- |
| |

<syntaxhighlight lang="cpp">
#include <cmath>

double result = std::pow(2, 8); </syntaxhighlight>
| <syntaxhighlight lang="python">
result = 2 ** 8 </syntaxhighlight>
|}

== 6. Printing values ==

Output using <code>std::cout</code> is replaced by the built-in <code>print()</code> function.

{| class="wikitable" style="width:100%; tab

Python Project

Andrei.ulmamei — Mon, 14 Sep 2026 05:20:27 GMT

Pagină nouă: Lab 1

Pagină nouă

[[Lab 1]]

Pagina principală

Andrei.ulmamei — Mon, 14 Sep 2026 05:20:18 GMT

Platforme de aplicatii sau laborator

@@ Linia 3: / Linia 3: @@
 * Lab. 1 - [[OS Lab 1 - Linux setup. Bash primer. C primer]]
-== Old Lab Sessions (2025) ==
+=== Old Lab Sessions (2025) ===
 * Lab 1 - [[OS Lab 1 - Installing Linux]]

← Versiunea anterioară		Versiunea de la data 9 octombrie 2026 12:59
Linia 1:		Linia 1:
	== Lab Sessions ==		== Lab Sessions ==
		+
		+	* Lab. 1 - [[OS Lab 1 - Linux setup. Bash primer. C primer]]
		+
		+	== Old Lab Sessions (2025) ==

	* Lab 1 - [[OS Lab 1 - Installing Linux]]		* Lab 1 - [[OS Lab 1 - Installing Linux]]

@@ Linia 48: / Linia 48: @@
 Replace `myname` and `station07` with your assigned username and workstation.
-Once connected, launch a VNC instance with:
+Once connected, set up VNC settings with:
 <syntaxhighlight lang="bash">
-vncserver -localhost no
+arh-setup-vnc-config
 </syntaxhighlight>
@@ Linia 57: / Linia 65: @@
 <syntaxhighlight lang="bash">
-vncserver -list
+tigervncserver -list
 </syntaxhighlight>
@@ Linia 63: / Linia 71: @@
 <syntaxhighlight lang="bash">
-vncserver -kill :3
+tigervncserver -kill :3
 </syntaxhighlight>

@@ Linia 515: / Linia 515: @@
 #include <stdio.h>
 struct studenti{
-char n[128];
+    char n[128];
-char m[128];
+    char m[128];
-float a,b,c,d;
+    float a,b,c,d;
 };
 int main(){
-int n,i;
+    int n,i;
-struct studenti s[n];
+    struct studenti s[n];
-scanf("%d", &n);
+    scanf("%d", &n);
-for(i=0;i<n;i++)
+    for(i=0;i<n;i++)
-scanf("%s%s%f%f%f%f",&s[i].n,&s[i].m,&s[i].a,&s[i].b,&s[i].c,&s[i].d);
+        scanf("%s%s%f%f%f%f",&s[i].n,&s[i].m,&s[i].a,&s[i].b,&s[i].c,&s[i].d);
-for(i=n;i>0;i--){
+    for(i=n;i>0;i--){
-float m=(s[i].a+s[i].b+s[i].c+s[i].d)/4;
+        float m=(s[i].a+s[i].b+s[i].c+s[i].d)/4;
-if(s[i].a>5&&s[i].b>5&&s[i].c>5&&s[i].d>5||m>=6){
+        if(s[i].a>5&&s[i].b>5&&s[i].c>5&&s[i].d>5||m>=6){
-printf("%s %s %.2f\n",s[i].n,s[i].m,m);
+            printf("%s %s %.2f\n",s[i].n,s[i].m,m);
-−
+        }
-−
+    }
-return 0;
+    return 0;
+}
 </syntaxhighlight>

@@ Linia 8: / Linia 8: @@
 [[Tutorial Vivado]]
-[https://wiki.dcae.pub.ro/images/8/89/QuartusNewProjectTutorial.pdf Quartus New Project Tutorial]
+<!--[https://wiki.dcae.pub.ro/images/8/89/QuartusNewProjectTutorial.pdf Quartus New Project Tutorial]-->
-[http://www.emmelmann.org/Library/Tutorials/docs/verilog_ref_guide/vlog_ref_top.html Verilog Quick Reference Guide]
+[https://chipverify.com/systemverilog/systemverilog-quick-refresher SystemVerilog Quick Refresher]
 == Suport software ==
@@ Linia 17: / Linia 18: @@
 [[Tutorial instalare Vivado]]
 === Intel ===
 [http://fpgasoftware.intel.com/14.1/?edition=web&platform=windows&download_manager=dlm3 Quartus II Web Edition 14.1].
@@ Linia 24: / Linia 26: @@
 Pentru a seta calea simulatorului Modelsim pentru Quartus Lite 18.1 din meniul Tools -> Options ... -> EDA Tool Options se alege pentru ModelSim Altera calea
 /opt/intelFPGA_lite/18.1/modelsim_ase/bin
 == [http://users.dcae.pub.ro/~zhascsi/exam/asc/asc_1.pdf colocviu] ==
 == [http://users.dcae.pub.ro/~zhascsi/exam/asc/part.txt refacere partial] ==

@@ Linia 16: / Linia 16: @@
 Așadar logica de generare a semnalului '''fw1''' poate fi descrisă astfel:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
             //                                                      ADD                      SUB                      LOAD                     STORE
 assign fw1 = (r2_dest == r1_sursa1) & regs_wen & ((r1_opcode == 4'b0001) | (r1_opcode == 4'b0010) | (r1_opcode == 4'b1001) | (r1_opcode == 4'b1010));
@@ Linia 23: / Linia 23: @@
 În mod asemănător se descrie generarea semnalului '''fw2''':
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 assign fw2 =               // <<<<< COMPLETAȚI CODUL !
 </syntaxhighlight>
@@ Linia 44: / Linia 44: @@
 Pentru testarea calculatorului se modifică programul anterior eliminând instrucțiunile NOP dintre instrucțiunile ce folosesc una rezultatul alteia:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
    LOADC R0 #255
    LOADC R1 #254
@@ Linia 72: / Linia 72: @@
 Nivelul de execuție se completează cu logica generării semnalului de control ''pc_load '' ce va determina actualizarea PC și înlocuirea cu ''NOP'' a instrucțiunilor mai noi ce deja au intrat în pipeline:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 assign pc_load = r2_opcode == 4'b1100;
 </syntaxhighlight>
@@ Linia 81: / Linia 81: @@
 La execuția instrucțiunii ''JMP'' contorul de program, PC, se va încărca cu adresa de salt. Descrierea PC din laboratorul precedent se completează cu o ramură corespunzătoare condiționată de semnalul '''pc_load ''':
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
-always @(posedge clk) begin
+always_ff @(posedge clk) begin
      if(rst)
          pc <= 0;
@@ Linia 96: / Linia 96: @@
 Adresa de salt este byte-ul inferior al instrucțiunii. Când instrucțiunea de salt ajunge în nivelul de execuție, byte-ul inferior este accesibil ca operand 2:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 assign pc_target = r2_operand2;
 </syntaxhighlight>
@@ Linia 102: / Linia 102: @@
 De asemenea, pentru ca acest byte să ajungă în întregime ca operand 2 în execuție, operandul 2 al instrucțiunii ''JMP'' trebuie selectat în etapa READ la fel cum este selectat acesta pentru instrucțiunea ''LOADC''. Codul de selecție se modifică astfel:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 assign operand2 = ((r1_opcode == 4'b1000) | (r1_opcode == 4'b1100)) ? r1_instr_data : rdata2; // LOADC sau JMP
 </syntaxhighlight>
@@ Linia 108: / Linia 108: @@
 La sfârșitul execuției instrucțiunii de salt, instrucțiunile mai noi ce sunt deja în nivelurile inferioare de pipeline se înlocuiesc cu instrucțiuni ''NOP''. Astfel registrul pipeline R1 se va încărca cu instrucțiunea ''NOP'' (ce are codul binar 'b0000) dacă semnalul de control '''pc_load ''' este activ:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
-always @(posedge clk) begin
+always_ff @(posedge clk) begin
      if(rst)
          r1 <= 0;
@@ Linia 129: / Linia 129: @@
 Pentru testarea calculatorului se modifică programul din memoria de program astfel:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
    LOADC R0 #255
    LOADC R1 #254

@@ Linia 7: / Linia 7: @@
 La nivel funcţional, fără a fi preocupaţi de implementarea efectivă, ALU poate fi privit ca un bloc multifuncţional a cărui funcţie este selectată de codul operaţiei instrucţiunii:
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
-always @(*) begin
+always_comb begin
      case(opcode)
 'b0001: result = operand1 + operand2;
@@ Linia 59: / Linia 59: @@
 Biții indicatori sunt calculați pentru fiecare operație și reflectă starea rezultatului. Procesorul implementat în laborator are doi indicatori, '''Z''' și '''N'''. Dacă rezultatul este zero se activează bitul '''Z''' (zero). Dacă rezultatul este negativ se activează ieșirea '''N''' (negativ). Operația de comparație poate fi implementată ca o operație de scădere fără destinație (se salvează în procesor doar biții indicatori nu și rezultatul):
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 assign Z = (result == 0);
 assign N = result[7]; // în complement față de 2 bitul MSB este bit de semn
@@ Linia 74: / Linia 74: @@
 Scrierea în setul de registre este secvențială, pe frontul semnalului de ceas de la intrarea '''clk''' (nereprezentată în figura de mai sus).
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
-reg [7:0] registru [0:15]; // set de 16 registre a câte 8 biți fiecare
+logic [7:0] registru [0:15]; // set de 16 registre a câte 8 biți fiecare
 // portul de scriere
-always @(posedge clk) begin
+always_ff @(posedge clk) begin
      if(wen) registru[waddr] <= wdata; // scriere sincronă - pe ceas - a valorii de la intrarea de date wdata în registrul destinație
 end
@@ Linia 100: / Linia 100: @@
 ==== generarea ceasului ====
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 initial begin
      clk = 0;                 // initialization at time 0
@@ Linia 109: / Linia 109: @@
 ==== generarea semnalului de reset ====
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 initial begin
      rst = 0;
@@ Linia 126: / Linia 126: @@
 Semnalul '''wen''' nu face parte din instrucțiune. În laboratorul 2 el va fi generat de unitatea de control a procesorului (UCP) în funcție de codul instrucțiunii. De exemplu instrucțiunea CMP nu modifică niciun registru ci doar biții indicatori, prin urmare '''wen''' va fi în permanență '''0''' pe durata procesării acestei instrucțiuni.
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 initial begin
      opcode = 4'b0000; dest = 4'd0; sursa1 = 4'd0; sursa2 = 4'd0; wen = 1'b0;
@@ Linia 144: / Linia 144: @@
 a)
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
-always @(posedge clk) begin
+always_ff @(posedge clk) begin
      if(rst) begin
          registru[0] = 13;
@@ Linia 158: / Linia 158: @@
 b)
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
 initial begin
      registru[0] = 13;
@@ Linia 168: / Linia 168: @@
 Dacă blocul '''initial''' este scris în modulul de testare iar variabilele inițializate sunt din interiorul modului testat sau chiar dintr-un submodul al acestuia, numele acestora trebuie să fie complet, corespunzător ierarhiei.
-<syntaxhighlight lang="Verilog">
+<syntaxhighlight lang="SystemVerilog">
      ralu.regs.registru[0] = 13;
 </syntaxhighlight>

← Versiunea anterioară		Versiunea de la data 14 septembrie 2026 05:54
(Nu s-a afișat o versiune intermediară efectuată de același utilizator)
Linia 1:		Linia 1:
−	[[Lab 1]]	+	= Python Project =
		+
		+	This course introduces Python programming to students who already have experience with procedural programming in C and object-oriented programming in C++.
		+
		+	The laboratories focus on the differences between C/C++ and Python, Python-specific programming concepts, and the development of a complete software project.
		+
		+	== Laboratories ==
		+
		+	* [[Lab 1\|Lab 1 — Python for C/C++ Programmers]]
		+	* [[Lab 2\|Lab 2 — Object-Oriented Programming in Python]]
		+	* [[Lab 3\|Lab 3 — Modules, Packages, Files and Type Hints]]
		+	* [[Lab 4\|Lab 4 — Testing and Software Quality]]
		+	* [[Lab 5\|Lab 5 — Project Development I]]
		+	* [[Lab 6\|Lab 6 — Project Development II]]
		+	* [[Lab 7\|Lab 7 — Final Integration and Presentation]]
		+
		+	== Course structure ==
		+
		+	The course consists of '''7 laboratory meetings''', each with a duration of '''2 hours'''.
		+
		+	The first laboratories introduce the Python language and its software ecosystem, while the later meetings are primarily dedicated to the semester project.
		+
		+	{\| class="wikitable" style="width:100%;"
		+	! Laboratory
		+	! Main topic
		+	! Type
		+	\|-
		+	\| [[Lab 1]]
		+	\| Python for C/C++ programmers
		+	\| Theory + exercises
		+	\|-
		+	\| [[Lab 2]]
		+	\| Object-oriented programming and the Python object model
		+	\| Theory + exercises
		+	\|-
		+	\| [[Lab 3]]
		+	\| Modules, packages, files, exceptions and type hints
		+	\| Theory + exercises
		+	\|-
		+	\| [[Lab 4]]
		+	\| Testing, debugging and software quality
		+	\| Theory + project
		+	\|-
		+	\| [[Lab 5]]
		+	\| Project implementation
		+	\| Project work
		+	\|-
		+	\| [[Lab 6]]
		+	\| Testing, refactoring and documentation
		+	\| Project work
		+	\|-
		+	\| [[Lab 7]]
		+	\| Final integration, demonstration and code review
		+	\| Project work + presentation
		+	\|}
		+
		+	== Semester project ==
		+
		+	During the course, students will develop a Python software project individually or in teams.
		+
		+	The project should demonstrate the ability to:
		+
		+	* organize a Python project into multiple modules;
		+	* use appropriate Python data structures and language features;
		+	* use external libraries where appropriate;
		+	* handle invalid input and exceptional situations;
		+	* write readable and maintainable code;
		+	* use Git for version control;
		+	* document the application;
		+	* test the main functionality of the application.
		+
		+	The objective is not simply to translate C/C++ programs into Python, but to learn how to design and implement software using Python's own abstractions, conventions and ecosystem.
		+
		+	== Recommended software ==
		+
		+	Students should have the following software available:
		+
		+	* Python 3;
		+	* Git;
		+	* a text editor or IDE;
		+	* a terminal;
		+	* access to the course Git repository.
		+
		+	Recommended development environments include:
		+
		+	* Visual Studio Code;
		+	* PyCharm;
		+	* any editor with Python and Git support.

@@ Linia 29: / Linia 29: @@
 * [[Reconfigurable Computing]]
 * [[Operating Systems]]
 == Materiale vechi CID ==