SOFTWARE ENGINEERING A - L
Academic Year 2024/2025 - Teacher: EMILIANO ALESSIO TRAMONTANAExpected Learning Outcomes
General goals described according to the expected learning results.
1. Knowledge and understanding: the student will have knowledge on object-oriented mechanisms, the modularity issues, the development process.
2. Applying knowledge and understanding: the student will be able to design, document, and implement object-oriented software systems, will be able to recognise the developer roles, and will be able to implement tests for assessing the code.
3. Making judgements: the student will be able to analyse the modularity of software systems.
4. Communication skills: the student will be able to describe software components using a proper technical language.
5. Learning skills: the student will be able to solve the typical problems faced during the design and implemntation, by studying, analysing and using novel object-oriented technologies, according to the general principles given.
Course Structure
Frontal lessons.
Slides used for the lessons are given in the web page of the teacher on the website of the Laurea degree (www.dmi.unict.it/tramonta/)
Should remote teaching be needed, then some adjustments to the above might be introduced, while honouring the programme outlined in the syllabus.
Students having some disabilities should communicate, sufficiently before the exam date, the teacher, the CInAP responsible in the DMI and CInAP that they want to have some assistance during the exam, the type of such assistance will be described by CInAP.
Required Prerequisites
Attendance of Lessons
Detailed Course Content
Software development processes, such as waterfall, evolutive and agile (spiral, XP, Scrum), activities and their timing. Requirement engineering: gathering and organising requirements. UML notation: use cases, activities, states, classes, sequences and collaboration diagrams. Brief introduction on code repositories and versioning: Git.
Object oriented design, inheritance and polymorphism. Quality issues. Design Patterns are described by means of objectives, contexts, problems solved, examples, solution with diagrams and code: Singleton, Factory Method, Prototype, Template Method, Adapter, Bridge, Composite, Decorator, Facade, Chain of Responsibility, Mediator, Observer, State, Command.
Refactoring techniques.
Stream Java and parallelism.
Software metrics and software evolution.
Software validation by means of testing.
Textbook Information
- I. Sommerville. Ingegneria del Software. Pearson Addison-Wesley.
- E. Gamma, R. Helm, R. Johnson, J. Vlissiders. Design Patterns – Elements of Reusable Object-Oriented Software. Pearson Addison-Wesley.
- M. Fowler. UML Distilled. Pearson. 2010
- R.-G. Urma, M. Fusco, A. Mycroft. Java 8 in Action: Lambdas, streams, and functional-style programming. Manning. 2015
- K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley. 1999
- M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley.
- K. Beck. Implementation Patterns. Addison-Wesley.
Course Planning
| Subjects | Text References | |
|---|---|---|
| 1 | Obiettivi dell’ingegneria del software. Caratteristiche del software: complessità, modificabilità, correttezza, specifiche, test | [1] |
| 2 | Caratteristiche del software: astrazioni (classi). Principio di singola responsabilità per classi e metodi. | [1, 2] |
| 3 | Qualità del codice e anti-pattern (God class, Spaghetti Code). Progettazione ed implementazione di test. | [1, 2] |
| 4 | Tecniche di Refactoring: estrai metodo, sostituisci temp con query, dividi variabile temp. | [6] |
| 5 | Design pattern Singleton. Creazione di istanze di classi. Metodi statici. Visibilità di classi, attributi e metodi. Concetti di information hiding, coesione, coupling. Concetti e meccanismi di ereditarietà e polimorfismo. | [1, 2] |
| 6 | Design Pattern Factory Method (con varianti riflessiva, object pool, dependency injection). | [2] |
| 7 | Identificazione e progettazione classi, uso di interfacce, ereditarietà e polimorfismo. Compatibilità di tipi. Dispatch di chiamate di metodo. Override e overload. | [1, 2] |
| 8 | La notazione UML per i diagrammi delle classi, di sequenza, di collaborazione. | [3] |
| 9 | Design pattern Adapter (versione Object e Class), e Façade. | [2] |
| 10 | Diagrammi UML degli stati. Design pattern State | [2, 3] |
| 11 | Design pattern Observer e Publish-Subscribe. | [2] |
| 12 | Riconoscimento di design pattern dal codice e dai diagrammi UML delle classi | [2] |
| 13 | Design pattern MVC, Mediator, e Decorator. | [2] |
| 14 | Processi di sviluppo agili: introduzione alle pratiche del processo extreme programming (XP). | [5] |
| 15 | Processo XP: pratiche di pianificazione (story card e CRC), pair programming, design semplice, refactoring, piccole release, standard di codifica, cliente in sede, test. Cenni di processo Scrum. | [5] |
| 16 | Fasi per lo sviluppo del software: raccolta e analisi requisiti, progettazione, codifica, convalida, evoluzione. | [1] |
| 17 | Processi di sviluppo del software: cascata, evolutivi e a spirale. | [1] |
| 18 | Requisiti del software: raccolta, tipi di requisiti, linee guida per la scrittura dei requisiti. | [1] |
| 19 | Progettazione ed implementazione con Java Stream e parallelismo. Filter, map, reduce. Tipi Predicate, Function, Supplier, Optional. | [4] |
| 20 | Esempi di programmazione con Stream Java, e concorrenza con stream | [4] |
| 21 | Design pattern Composite, Chain of Responsibility. Conseguenze sul codice dell'adozione di vari design pattern | [2] |
| 22 | Design pattern Bridge. La notazione UML dei diagrammi dei casi d’uso, e delle attività. | [2, 3] |
| 23 | Evoluzione del software, categorie di cambiamenti e gestione dei cambiamenti. Leggi di Lehman. | [1] |
| 24 | Metriche sul software: complessità ciclomatica, linee di codice. Metriche per sistemi ad oggetti: suite di Chidamber e Kemerer. Fase di test. Test di componenti, metriche di copertura del codice. Test regressivi. | [1] |
Learning Assessment
Learning Assessment Procedures
The exam consists of a written test and oral interview. The written test takes place at 9:00 AM on the day of the exam, unless otherwise communicated. The written test lasts one hour and consists of various multiple-choice questions and two open-ended questions that require code implementation and the drawing of diagrams. Passing the written test allows you to proceed to the oral part of the exam, which will be scheduled on days following the written test and communicated in advance.
An excellent evaluation of the written test will be given when the number of correct answers to multiple-choice questions is close to the total number of questions, and when the answers to the open-ended questions are correct and precise. A sufficient evaluation will be given when the number of correct answers to multiple-choice questions is close to half of the total number of questions, and when the answers to the open-ended questions are partially correct or not given in a complete manner.
The exam will be evaluated excellently (marks 28 to 30 cum laude) if you demonstrate a deep understanding of the course concepts and precision in their presentation. An intermediate grade (marks 24 to 27) will be given in cases where the exam shows a partial understanding of the topics. A barely passing grade (marks 18 to 23) will be awarded when, despite partial knowledge of the topics, they are presented superficially and with some errors.
Students need to book their exam using the website SmartEdu.
The completion and presentation of a project are optional.
The assessment of learning may also be conducted remotely if conditions require it.
Examples of frequently asked questions and / or exercises
Describe the goals of a design pattern
Describe the benefits that a design pattern provides in relation to the produced code
Describe how a design pattern actually works
Implement a class for a design pattern
Implement data selection and transformation by using Java Stream
Describe method filter (map or reduce), give the syntax and an example of use
Describe type Predicate (Function or Supplier)