Introduction to Software Design PDF

Summary

Introduction to Software Design and testing lecture notes from the ETS de Ingeniería Informática at the UNIVERSIDAD DE SEVILLA covering various topics around software design. Including frameworks, design patterns and examples of real-world applications.

Full Transcript

Introduction to Software Design and Testing Design & Tests 1 E.T.S. de Ingeniería Informática In this lesson 2 In this lesson 3 Contents Design – Main concepts around design – Why is software...

Introduction to Software Design and Testing Design & Tests 1 E.T.S. de Ingeniería Informática In this lesson 2 In this lesson 3 Contents Design – Main concepts around design – Why is software design important – Frameworks & Design Patterns Design of our architecture (a Spring Boot Application with Spring MVC) – MVC – MVC in Spring Services Entities Repositories – Spring controllers – React Views – Overview of a Spring Boot Application 4 Main concepts around design 5 What is software design? 6 Design (in general) “A design is a plan or specification for the construction of an object or system” “The process of developing a design” Wikipedia 7 Software Design “The process of defining the architecture, components, interfaces, and other characteristics of a system or component (and the result of that process)” ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/IEC/IEEE, 2010. 8 Software design “Software design is an iterative process by which the requirements are translated into a "blueprint" for building the software.” R. Pressman 9 Software Design vs Software Requirements Software requirements define “what” your system needs to do. Users Requirements Engineering Backlog / User Stories Field Business Rules observation Non-functional requirements Software Design defines “how” to create a system that meets those requirements Design + Working software Implementation Backlog / User Stories Business Rules 10 Non-functional requirements Design is making decisions about our application 11 Examples of design decisions (as questions) How many modules should have the system? Should we use a layered architecture or pipes and filters/microservices architecture/etc.? Which class should implement this method/functionality? This constraint should be implemented in the services layer/business logic or as a constraint in the DB (maybe using triggers)? 12 Design is a “wicked” problem There is no definitive/unambiguous/analytical formulation Solutions are not right or totally wrong, but better/worse There is no stopping rule, i.e. we do not know when have we found the best possible solution, we only know if we have found a good enough solution (by now). 13 Cruft: The difference between the current code and how it would ideally be 14 https://www.martinfowler.com/bliki/TechnicalDebt.html The impact of cruft 15 https://www.martinfowler.com/articles/is-quality-worth-cost.html Be careful, your changes might affect the future 16 Technical debt What can we do? 18 How to face this problem Design is never done Design is performed iteratively Reuse the knowledge (and designs) of experienced designers: – Desing principles – Design Patterns – Frameworks 19 Design principles Key concepts to consider for the effective design of software systems. 20 Design principles Don’t Repeat Yourself (DRY). “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code. The principle was formulated by Andy Hunt and Dave Thomas in 21 The Pragmatic Programmer Design principles Keep It Simple, Stupid! (KISS). Most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. “Simplicity is the ultimate form of sophistication” Leonardo Da Vinci 22 Design principles You Aren't Gonna Need It (YAGNI). XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them.“ Yagni is only viable if the code is easy to change, so expending effort on improving the source code of already implemented features (refactoring) isn't a violation of yagni because refactoring makes the code healthier and more malleable. 23 Design principles Separation of concerns: each element of the system has a single responsibility Decomposition. Divide the problems into simpler/ smaller problems (Divide & Conquer) 24 Design principles Information hiding: Design modules so that the information (algorithms and data) contained in a module is inaccessible to those who do not need it. The modules should exchange only that information necessary to achieve the function of the software. Objective: Avoid unnecessary dependencies to ease software maintainability Functional independence is achieved by developing nearsighted modules that are averse to excessive interaction with other modules. R. Pressman 25 Design principles Protected variations. Trying to hide / protect changes to the rest of the system. Objective: Minimize the impact of changes. 26 Design principles Cohesion. It is a qualitative indicator of the degree to which a module focuses on doing one thing. The cohesion of a design should be high. An element is highly cohesive if all elements work together to provide a well-defined behavior Grady Booch 27 Design principles Coupling. Is a qualitative indicator of the degree to which a module is connected to others and the outside world. The coupling should be low. 28 Design patterns A pattern is a general Descripción de lossolution to a recurring subsistemas design problem y componentes de that expresses a un sistema relationship softwarebetween y de lasainterrelaciones context, a problem, andellos. entre a solution. A pattern is not a complete solution but a guide/skeleton that must be adapted to each specific problem. Intuitive Idea: "When you find this problem, apply this solution”. Problem Solution 29 The power of Design Patterns Design Patterns give you a shared vocabulary with other developers. – Patterns allow you to say more with less Design patterns also elevate your thinking about software, by letting you think at the pattern level, not the nitty- gritty object/ or source code level. Design patterns are tools for Design Toolbox, that allow you to create flexible designs that are maintainable and can cope with change 30 Libraries A library providesde Descripción reusable code that canybecomponentes los subsistemas used by application de undevelopers. sistema software y de las interrelaciones entre ellos. ▪ Examples: Library of mathematical functions Math.lib, or Guava (the library of Google for JAVA). ▪ Libraries can be added to the program at compilation time (ex. lib, jar) or at runtime (ex. DLLs). ▪ The development of libraries may be a good idea to facilitate the use of our applications by others. Ex. Amazon SDK for Java. 31 Frameworks A Descripción framework isde an los integrated set of software subsistemas artefacts (such y componentes de unassistema classes and configuration software yfiles) thatinterrelaciones de las implement a reusable entre architecture ellos. for the development of related applications. They lack the specific functionality of the application, but usually provide the implementation of the common functionality such as security, user interface components, etc. The frameworks often implement different patterns and architectural styles. Using frameworks will largely determine the system architecture. 32 Libraries vs. frameworks Library Framework Code of our application Frameworks & Architectural design Frameworks usually involve an architectural design (or a discrete set of architectural styles) You must choose a framework that meets your choice of architectural style Most of the remaining architectural decisions are made by you! 34 Our Architecture Single Page Global Presentation Layer (React) Application Users API Matches API Statistics API Layered Backend Monolith (Spring Boot) Monolithic Architecture RESTful API Business Logic Resources DATA BASE 35 Single Page Application (SPA) A SPA is a web application that literally has one page, a single HTML page is loaded in the browser and is not reloaded during use. When users interact with the page, the application dynamically rewrites/updates the current page rather than loading a new page from the server. Since the HTML is rendered and manipulated client-side, the size of the payload is decreased because the server returns only JSON, not HTML. Many popular JavaScript frameworks, including Vue.js, AngularJS, Ember.js, Meteor.js, and React, have adopted SPA principles. 36 Single Page Application (SPA) 37 Single Page Application ▪ Advantages: Fast and fluid response time Simple to build and debug Smooth transition to mobile development Good integration with layers and microservices architectures ▪ Disadvantages: Long initial wait time You still need to wait for data Requires specific javascript frameworks (additional complexity) SEO implications 38 Can I use spring boot to implement a microservices architecture? Spring boot is the most popular framework for microservices development in java. To implement a SPA as global presentation layer for the microservices you need to integrate a modern javascript framework such as Angular, React, etc. We will create a SPA, but we don`t use a micro-services architecture, all our APIs are deployed as a monolith  39 Architectural design (of a Spring Boot application with Spring MVC) 40 How does a Spring Boot aplication with Spring MVC look like? 41 Launching and debugging https://github.com/gii-is-DP1/react-petclinic The first time you have to download the libraries by running Maven – Install (or using mvnw install in a terminal) You should have installed Lombok in your development environment, otherwise, you will experience weird errors, you have a video in EV! After that, just launch class PetclinicApplication as a regular Java app (Click Run as → Java application) For debugging is exactly the same (Debug as → Java application). Alternatively, you can run it using mvnw spring-boot:run in a terminal. On the frontend folder use npm start in a terminal You can access the app at http://localhost:3000 42 HTTP + URIs + AJAX Backend 1. HTTP Request to the page Spring 2. HTML + boot JavaScript + CSS Frontend WEB SERVER Development 5. Data 4. SQL Queries server (only used during development for hot reloading and WEB SERVER 43 other useful features) DATABASE About the database The current configuration uses an in-memory database called H2 Each time the app starts, the database is created and populated. You can change src/main/resources/db/hsqldb/data.sql to change the initial population of the database You can access a console for the database at: http://localhost:8080/h2-console/ – User is “sa” without password – Make sure the URL of the database is the one that appears in the log when the application starts (usually it’s jdbc:h2:mem:testdb) 44 About the servers The current configuration uses an embebed Tomcat server for backend (port 8080)and a node development server for the frontend (port 3000) Each time the app starts, the server is started You can change src/main/resources/application.properties and set the property server.port to change the port on which the backend server is listening for requests (you need to change frontend code to use the new backend port, specifically the file package.json) The static resources (images, icons, fonts, css, etc.) served by the node development server are located at frontend/src/static folder 45 One additional remark Eclipse (and other IDEs) usually recompiles automatically every java file you change. The configuration of the project is designed to restart the backend server once a change is detected, so you don’t need to stop and restart the app when a change is made The same is valid for changes in the jsx/js files for the frontend server, you don´t need to stop it manually when you make changes (hence the utility of using a dedicated development server instead of serving the files from the tomcat directly). 46 The Model View Controller (MVC) Pattern Architectural pattern that structures an application in three different components – Model: It is the representation of the information. It includes both the data and the business logic that is necessary to work with them. No business logic should be placed outside the model. – View: It is the presentation of the model in a way the user can interact with it. It is usually done by means of an User Interface o Rest API – Controller: It responds to events in the user interface (HTTP requests in our case), invokes changes in the model, and, probably, in the view. 47 Model 48 500 feet view: The Model-View-Controller (MVC) pattern in RESTful API Spring Spring 4.- Updated data boot & status Controller 2.-Invoke business logic 1.- User events 3.- Updated data (HTTP requests) & status Spring boot View Model Service Entities Entities invokes Entities SQL Queries Repository returns DATABASE 49 The model includes three elements: Entities Repositories Services 50 Entities A domain object whose data is persisted in the database and has its own identity In the example they all inherit from a class (BaseEntity). They have annotations that indicate how to map attributes to tables in the database They are JPA Entities Let’s have a look at Pet 51 Repositories It provides methods for retrieving and saving domain objects to the database There is usually one repository per entity. In the example, they are done in two different levels of interfaces assuming that other repositories could be implemented. We try to have a repository per entity. Let’s have a look at PetRepository 52 Services They expose the functionality of the domain as an API The are usually organised in terms of entities. They should perform domain-related validation, but not input- related validation, which is placed in the controller. An example of input-related validation is check if the name is not empty. A domain-related validation involves checking if the user does not have another appointment in the same time slot. – As a rule of thumb, they should not include validation that could be performed using client-side Javascript. They should include annotation @Transactional if they involve saving/modifying/deleting something into the database. Services are usually organized in terms of entities. Let’s have a look at PetService 53 Controllers 54 Controllers in Spring They respond to events in the user interface (HTTP requests in our case), invokes changes in the model, and, probably, return data to the view as JSON Spring provides a way to map an HTTP request to a method by annotating them with @GetMapping or @PostMapping. RESTful Controllers are responsible for: – Validating the input provided by the views (only input-related validation) – Transforming this input into entities if necessary – Calling services (only one method per request in 99% of cases) to perform an action. – Return the appropriate status code and JSON 55 Views Views represent the information provided by the controller Spring MVC is view agnostic, so it does not push you to use an specific view techonology such as JSP or Thymeleaf. This enables the integration of SPA frameworks such as Vue.js, AngularJS, Ember.js, Meteor.js, and React In our project we will use React and JSX components to create Views 56 Some notes about security Security configuration can be found at src/main/java/org/springframework/samples/petclinic/config uration/SecurityConfiguration.java At this point we will show you only the configuration required 57 The architecture of a Spring Boot web application View Restfull Controllers React/JSX Filters Alta Listado Usuarios … Mascotas API Vets Listado Usuarios … Alta Mascotas jwt … CONFIGURATION STATIC ASSETS SECURITY Domain Services Domain model (entities) Servicio Servicio … Usuarios … Mascotas Usuario Mascota … Vet Resources Repo. Repo. Repo. Usuarios Mascotas … Veterinarios DB 58 The architecture of a Spring Boot web application Layers Web/View Layer Front Template Intercepting Controller View Filter RESTful Controllers React/JSXs Filters Listado Alta API Vets Listado … Alta jwt Usuarios … Mascotas Usuarios Mascota … CONFIGURATION STATIC ASSETS SECURITY Domain Layer Metadata Mapper Services Domain model (entities) Servicio Servicio … Usuarios … Mascotas Usuario Mascota … Vet Data Mapper Resources Layer Table Data Gateway Repo. Repo. Repo. Usuarios Mascotas … Veterinarios DB 59 This is the global view: MVC + three layers architecture Presentation Layer Spring boot Change view Controller Update/Query data User events Business Logic layer (HTTP requests) Spring boot View Model Service Resource layer Entities Entities invokes Entities SQL Queries Repository returns DATABASE 60 Mapping of architectural elements into project’s folder src ├─ main sample │ ├── java/org/springframework/simples/petclinic │ │ ├── configuration │ │ ├── model Required Super entities Entities │ │ ├── owner │ │ │ ├── Owner.java │ │ │ ├── OwnerController.java │ │ │ ├── OwnerRepository.java Controllers │ │ │ └── OwnerService.java │ │ ├── pet … │ │ ├── vet …. Repositories │ │ ├── auth │ │ ├── web Authorization controllers │ │ └── util │ └── resources Services │ ├── data.sql Database population scripts │ ├── diagrams │ └── application.properties UML Diagrams | └── test/org/springframework/simples/petclinic Application configuration fronted | └ src | ├─ static Static resources (images, css, icons, etc.)... Views. - - 61 Wrapping up 62 Main concepts around design What software design is The factors that affect software design The importance, extent, and results of the design process Design principles and design patterns SPAs Frameworks vs Libraries 63 Architecture of a Spring MVC application MVC Spring MVC Services Repositores Controllers Views 64 Reminders 65 Reminder 3: Each group must choose a game We will provide a link to a spreadsheet where each group will choose among the available games (in EV). For each theory group (G1, G2, G3, GIng), no game will be chosen by more than one project group (no games repeated in a theory group) ➔ Run!!!! You should take into account game complexity OPENING OF GAME CHOICE FORMS: 18 Sept 8:00 am DEADLINE: 20 September! 66 Reminder 4: Each project group must play a game and create a video explaining the rules Upload a video explaining the rules to the GitHub repository of the project or Youtube. DEADLINE: 27 September! 67 Reminder 5: Read, sign & upload your learning commitment contract It is an agreement designed to outline the goals, expectations, and responsibilities of students participating in a specific group project. It contains an explicit statement of the game you choose as a group, the grade you aim for, and the modules that you plan to develop All the members of the group must read and sign it and upload (in pdf format) to the docs folder of your project repo (upload one single document signed by all the members) DEADLINE: 8 October! 68 Sprint 1 Deadline 8 Oct. 2023 08:30:00 69 References 70 Bibliography Pressman R.S. Ingeniería del software: Un enfoque práctico. McGraw-Hill. 7ª edición. 2009. (Chapters 8 & 12) Sommerville I. Ingeniería de Software. Pearson. 9ª edición. 2011. (Chapters 6, 7 and 16) Bass L., Clemments P, Kazman R. Software Architecture in Practice. Addison-Wesley Professional. 3rd edition. 2003 (Chapters 1 and 2) 71 Bibliography Buschmann F. et al.Pattern-Oriented Software Architecture. John Wiley & Sons. 1996 (Chapter 2) Douglas C Schmidt, Aniruddha Gokhale, and Balachandran Natarajan. 2004. Leveraging Application Frameworks. Queue 2, 5 (July 2004), 66-75. http://dx.doi.org/10.1145/1016998.1017005 ISO/IEC/IEEE 24765:2010. Systems and Software Engineering—Vocabulary, ISO/IEC/IEEE, 2010. 72 Disclaimer and Terms of Use All material displayed on this presentation is for teaching and personal use only. Many of the images that have been used in the presentation are Royalty Free images taken from http://www.everystockphoto.com/. Other images have been sourced directly from the Public domain, from where in most cases it is unclear whether copyright has been explicitly claimed. Our intention is not to infringe any artist’s copyright, whether written or visual. We do not claim ownership of any image that has been freely obtained from the public domain. In the event that we have freely obtained an image or quotation that has been placed in the public domain and in doing so have inadvertently used a copyrighted image without the copyright holder’s express permission we ask that the copyright holder writes to us directly, upon which we will contact the copyright holder to request full written permission to use the quote or images.

Use Quizgecko on...
Browser
Browser