| Software Architecture | Code: 22.618 : 6 |
Continuous advances in computing and telecommunications are changing the way software is developed. In particular, the relentless increase in the power of personal computers and mobile devices, the lowering of hardware costs and the emergence of global data networks have made possible a particularly favourable infrastructure for the use of open and distributed systems.
These changes have caused, among other things, traditional software design and development methods (seen in the subjects of Software Engineering and Analysis and pattern design) are insufficient, since, more or less implicitly, they assume that the application to be developed will run in a basically centralized environment. Therefore, traditional methods are unable to naturally manage the complexity of the requirements of this new type of system. On the other hand, the aspects closest to the analysis and specification of requirements studied in the subject Requirements Engineering they do not change with respect to what has been seen in the subjects prior to this and, therefore, they are not repeated here.
This subject serves as an introduction to the software architectures as a framework for the design and development of distributed applications where the fundamentals, techniques and skills applicable in the modern definition of software architectures are studied and put into practice, and the knowledge acquired in the previous subjects are complemented. The design of the architecture of the software systems allows to describe in an abstract and high-level way both the functionality of the system and many other non-functional aspects of it (distribution, reliability, security, adaptability, performance, etc.). This description of the system is usually defined from an architectural style, a classification of software systems into large families that follow a common structural pattern. Among the architectural styles more common for distributed systems are systems organized in microservices, multiple layers, client-server systems or systems peer-tone-peer.
The design of the application in terms of software microservices has to be refined, subsequently, to adapt and implement it in a specific distributed software technology. These architectures can be implemented using any programming paradigm (object-oriented, structured...). In our specific case, the reference language will be Java that allows for developing distributed applications with microservices architectures. These microservices are those that will be used to implement and test the architectural elements described in the system architecture.
Finally, some good practices in the development and production of software in distributed architectures are collected. Some of the key concepts are worked on when developing and putting into production, such as the continuous delivery, DevOps culture and container-based deployment.
This subject is framed within the itinerary of Software Engineering of the degree of Computer Engineering, constituting an extension in several dimensions of the basic knowledge of software engineering included both to the specific itinerary and in the compulsory subjects of the degree.
In order to successfully take this subject, students are required to have prior knowledge of object-oriented technology. Specifically, you have to know the fundamentals of object-oriented programming and the basic notations of UML, as they are studied, for example, in the subjects Software Engineering and Analysis and pattern design of this same degree.
This subject will be especially useful to all future professionals dedicated to software development according to a current conception. The field of software development changes day by day, and as mentioned at the beginning, both distributed systems and microservices systems are becoming more and more important.
On the other hand, it is also important for every computer engineer to acquire the basic skills in the installation, configuration and use of the various support tools very popular in the market for the development, deployment and execution of software applications. In this subject, an intensive task will be carried out in this sense to consolidate these skills through the support of a specialized classroom of Laboratory. Therefore, the use of automatic virtual machines with already configured environments will be avoided as much as possible and instead the use of individual tools that the student will have to learn how to install and configure manually will be encouraged.
To have overcome the subjects Software Engineering and Analysis and design with patterns or having the equivalent knowledge is the precondition to be able to take this subject.
It is also essential that the student has a good level of Java to be able to pass the subject. The subject has a significant part of practical work in Java that assumes an important knowledge and practice in this language. It is not recommended that the student take this subject until a good level of Java has been achieved, since otherwise s/he will be most probably forced to repeat the subject.
It is advisable to have passed the following subjects of the Degree:
Software Engineering and Analysis and design with patterns.
Transversal competences of the Degree in Computer Engineering:
- Ability to communicate in writing in the academic and professional field.
- Use and application of ICT in the academic and professional field.
- Ability to adapt to technologies and future environments by updating professional skills.
- Know how to propose and assess different technological alternatives to solve a specific problem.
- Ability to analyze a problem at the level of abstraction appropriate to each situation and apply the skills and knowledge acquired to address and solve it.
- Know how to build computer applications through development, integration and reuse techniques.
- Application of the specific techniques of Software Engineering to the different stages of the life cycle of a project.
The general objective of the subject is that the student acquires the basic knowledge for the development of distributed applications based on microservices. This objective is specified in the following specific objectives:
- Explain the fundamentals of software architecture and the characteristics of an architecture.
- Present arguments about the strengths and weaknesses of different architectural styles and how these influence the decision of the most suitable architectural style or styles for a given application.
- To place the new emerging paradigms of software engineering within the framework of software architectures.
- Present arguments that show the benefits and also the risks and costs of a microservices architecture to solve a specific problem.
- Propose the design of a microservices architecture and its decomposition from a case study.
- Implement microservices focused on business logic and data access.
- Deploy microservices with own state, synchronous intercom, and data consistency.
- Apply basic concepts of microservices architecture.
- Master the basic technologies necessary for the implementation of microservices.
- Recognize the testing and quality factors of a specification/design.
- Formally assess the testing and quality of an implementation.
- Identify the most important models and software quality standards.
- Recognizing the factors of delivery, deployment, and integration continues.
- Interpret agile culture in software development.
- Implement a pipeline of delivery, deployment and continuous integration.
- Present arguments about the advantages and costs of containers and orchestration platforms.
- Prepare a good final delivery report to a potential client.
The subject is structured in 5 main activities, each with its specific contents:
Activity 1: "Distributed software architectures: a solution for every problem"
- Book "Fundamentals of Software Architecture" (Richards & Ford): Chapter 1. Introduction.
- Book "Fundamentals of Software Architecture" (Richards & Ford): Part I Foundations (Chapters 2 - 8)
- Book "Fundamentals of Software Architecture" (Richards & Ford): Part II Architecture Styles (Chapters 9 - 18).
Activity 2: "Hexagonal architectures and microservices design: a nice relationship"
- Book "Microservices patterns" (Richardson): Chapter 1. Section 6: "The Microservice architecture pattern language".
- Book "Microservices patterns" (Richardson): Chapter 2: "Decomposition strategies".
- Book "Microservices patterns" (Richardson): Chapter 3: "Interprocess communication in a microservice architecture"
- Book "Microservices patterns" (Richardson): Chapter 5: "Designing business logic in a microservice architecture".
Activity 3: "From the creation to the interconnection of microservices"
- Book "Microservices Patterns" (Chris Richardson): Chapter 6: "Developing business logic with event sourcing". Introduction.
- Book "Microservices Patterns" (Chris Richardson): Chapter 6: "Developing business logic with event sourcing".
- Book "Microservices patterns" (Richardson): Chapter 7: "Implementing queries in a microservice architecture"
- Book "Microservices patterns" (Richardson): Chapter 8: "External API patterns".
Activity 4: "Distributed software quality: inherent, transversal and critical"
- Book "Microservices Patterns" (Chris Richardson): Chapter 9. "Testing microservices: Part 1". Introduction.
- Book "Microservices Patterns" (Chris Richardson): Chapter 9. "Testing microservices: Part 1".
- Book "Microservices Patterns" (Chris Richardson): Chapter 10. "Testing microservices: Part 2".
- Book "Fundamentals of Software Architecture" (Richards & Ford): Part I Foundations (Chapters 3 & 6).
Activity 5: "DevOps, CD/CI and Agile Culture: Best Practices for Distributed Software Development"
- Book Microservices Patterns (Chris Richardson) Chapter 12 Deploying microservices. Introduction.
- Book Microservices Patterns (Chris Richardson) Chapter 12 Deploying microservices.
- Book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Jez Humble & Dave Farley) Part I: Chapters 1-10.
- Book "The DevOps Handbook" (Patrick Debois, John Willis, Jez Humble & Gene Kim): Chapters 1 - 4.
The main support of the teaching material are the books mentioned above, which will be distributed in digital format according to the usual channels of the UOC (Library) accessible from the classroom. All the books of the subject are original from world-leading authors in the area of distributed software development and therefore are written entirely in English.
On the other hand, the course has a Laboratory classroom with material and software tools, and an instructor with great experience in the technical part of the course, where the student will obtain all the necessary support to carry out the practical assignments. In particular, the Laboratory has software and installation manuals, training courses and solved case studies on installation and implementation, frequently asked questions (FAQs) with answers and references to external sources of information. In addition, it has forums where students can share doubts, queries and problems that the instructor responds as quickly as possible, and that all students can participate.
Assessment at the UOC is, in general, online, structured around the continuous assessment activities, the final assessment tests and exams, and the programme's final project.
Assessment activities and tests can be written texts and/or video recordings, use random questions, and synchronous or asynchronous oral tests, etc., as decided by each teaching team. The final project marks the end of the learning process and consists of an original and tutored piece of work to demonstrate that students have acquired the competencies worked on during the programme.
To verify students' identity and authorship in the assessment tests, the UOC reserves the right to use identity recognition and plagiarism detection systems. For these purposes, the UOC may make video recordings or use supervision methods or techniques while students carry out any of their academic activities.
The UOC may also require students to use electronic devices (microphones, webcams or other tools) or specific software during assessments. It is the student's responsibility to ensure that these devices work properly.
The assessment process is based on students' individual efforts, and the assumption that the student is the author of the work submitted for academic activities and that this work is original. The UOC's website on academic integrity and plagiarism has more information on this.
Submitting work that is not one's own or not original for assessment tests; copying or plagiarism; impersonation; accepting or obtaining any assignments, whether for compensation or otherwise; collaboration, cover-up or encouragement to copy; and using materials, software or devices not authorized in the course plan or instructions for the activity, including artificial intelligence and machine translation, among others, are examples of misconduct in assessments that may have serious academic and disciplinary consequences.
If students are found to be engaging in any such misconduct, they may receive a Fail (D/0) for the graded activities in the course plan (including final tests) or for the final grade for the course. This could be because they have used unauthorized materials, software or devices (such as artificial intelligence when it is not permitted, social media or internet search engines) during the tests; copied fragments of text from an external source (the internet, notes, books, articles, other students' work or tests, etc.) without the corresponding citation; purchased or sold assignments, or undertaken any other form of misconduct.
Likewise and in accordance with the UOC's academic regulations, misconduct during assessment may also be grounds for disciplinary proceedings and, where appropriate, the corresponding disciplinary measures, as established in the regulations governing the UOC community (Normativa de convivència).
In its assessment process, the UOC reserves the right to:
- Ask students to provide proof of their identity as established in the UOC's academic regulations.
- Ask students to prove the authorship of their work throughout the assessment process, in both continuous and final assessments, through a synchronous oral interview, of which a video recording or any other type of recording established by the UOC may be made. These methods seek to ensure verification of the student's identity, and their knowledge and competencies. If it is not possible to ensure the student's authorship, they may receive a D grade in the case of continuous assessment or a Fail grade in the case of the final assessment.
Artificial intelligence in assessments
The UOC understands the value and potential of artificial intelligence (AI) in education, but it also understands the risks involved if it is not used ethically, critically and responsibly. So, in each assessment activity, students will be told which AI tools and resources can be used and under what conditions. In turn, students must agree to follow the guidelines set by the UOC when it comes to completing the assessment activities and citing the tools used. Specifically, they must identify any texts or images generated by AI systems and they must not present them as their own work.
In terms of using AI, or not, to complete an activity, the instructions for assessment activities indicate the restrictions on the use of these tools. Bear in mind that using them inappropriately, such as using them in activities where they are not allowed or not citing them in activities where they are, may be considered misconduct. If in doubt, we recommend getting in touch with the course instructor and asking them before you submit your work.
|
You can only pass the course if you participate in and pass the continuous assessment. Your final mark for the course will be the mark you received in the continuous assessment. |