# INTERSECT SOFTWARE DESIGN <!-- Put the link to this slide here so people can follow --> Slides: https://hackmd.io/@JamilGafur/intersect_SD Repo: https://github.com/INTERSECT-training/software-design --- # Learning Objectives Our goal is to answer the following questions! --- # What is Software Design? Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. --- ## How do you communicate a software design to help developers build a system? software design is comprised of differest aspects we will go through. This includes features, requirements, communication and so much more! --- To better understand this we will introduce a new programmer, Finly the fish (:fish:) --- ## Who is finly - Finley is a new programmers who was assigned a new project and working with Ben the bever biologist! - Finley is lost on working with his project because Ben the bever has made a massive dam of code! - This undocumented, uncommented horrible dam code is very messy and confusing! --- ![HackMD logo](https://presskit.hackmd.io/Default/HackMD_LOGO_vertical_white.png =200x200) --- ## Finlys Goal - Finly wants to help add new features to the dam and release it to the ecosystem --- ## Components to the rescue - The first step Finly is going to take is to break the dam up into different components! - These components each have different tasks that have and their dependences need to be identified - In order to make finleys & Bens life easier he visualizes these connections into a component diagram (shown below)o --- ## DAM/Regulate.py ```python! def collectWater(water): FilterWater(water) ... return water ``` --- ## DAM/Filter.py ```python! def filterWater(water) relesaseWater(water) ... return Filteredwater ``` --- ## Dam/release.py ```python! def releaseWater(water): collectWater(water) ... return water ``` --- ![HackMD logo](https://presskit.hackmd.io/Default/HackMD_LOGO_vertical_white.png =200x200) TODO: image of dam broken up into different parts --- ## Try it yourself interactive: Break out into groups, given code (here) break it into a component view diagram with requirments dependencies... after some time come back and talk about each teams work --- Finly now has different easier parts of code to focus on! --- ## Note for more information on component diagrams see [here](https://www.tutorialspoint.com/uml/uml_component_diagram.htm ) --- Finly and Ben are very happy with this diagram because * Everyone is on the same page * Everyone can work on individal sections --- Now Finly is only working on cleaning up component **C** instead of all this dam code! Ben knows they need to work on component **B** Ben and Finly know the correct parameters and how each component should work together! --- ## This is good, is more is better? Dakota the Duck is part of the team working with the dam. they love the component diagram and tries to go a step further! They introduce this diagram --- TODO: badly coupled component diagram --- [link text][https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/] they find out some key things to think about when making a component diagram --- # Try it yourself given this diagram break it down into a component diagram, how can we clean it up? --- ## Finly so far Finly has taken this dam code, created a requirments diagram with different components and is working on an individaul section! However in the component diagram Finly sees a circular diagram, this can be solved by adding designing patterns --- ## Finding the correct patterns * Finly has an understanding of what they need to work on. * However none of his code work because the dam code has everything hardcoded! * Finly find out about design pattern that makes it easier to overwrite the hardcoding * They find out about this site and learn about ***some*** design patterns:[here](https://refactoring.guru/design-patterns) --- ## Other types of design patterns https://en.wikipedia.org/wiki/Publish–subscribe_pattern --- ## Try it yourself Each group learn about different design patterns and talk about it? --- ## Refactoring * Finly finds a design pattern that would make the teams life much easier! * The team starts working on implementing the code through refactoring. * Refactoring is the process of restructuring computer code without changing or adding to its external [behavior](http://bizzark.com/2014/04/15/when-to-refactor.html) * For more [refer to Martin Fowler's book](https://martinfowler.com/books/refactoring.html) --- TODO example of refactoring wrt component diagram --- ## Managment :::danger :warning: Finly was just informed that they have a managment meeting coming up soon and are expecting an increase in members to the team! How does finley prepare for all this... ::: --- ## Documentation, Documentation, Documentation! - Finly starts to look at all of git commits and makes sure they are coherent and explainable - The team now works together to prepare documentation for new members to be on boarded and for themselves! - The documentation contains a bunch of useful information --- ## Team Documentation - The team work internally to create documentation that include - A README file that has - Requirements - Dependencies - File Structures - Connectivity/Componet Diagram - Different types of tests (see testing group) --- ## Team Documentation - The team work internally to create documentation that include - A set of usage examples - Input Parameters - Output Variables - Method Explanations - More information can be found in the CI group? --- ## Team Documentation - Once the team finished up they work on building up documentation to help onboard the new members, to do so they work on: - File strucutre - Coding convention - Test location - Contact information - Programming/Implementation Standards --- ## ilities (Non-functional requirements) The team is finishing up their first first design phase and have come a long way, over time they will keep going through this process to make the code more modular, flowing.... while doing so they keep in mind the ilities, which are - Testability - Maintainability - Reproducibility,Repeatability, Replicability - Portability - Sustainability - Extensibility - for more refer to [The 7 Software “-ilities” You Need To Know](http://codesqueeze.com/the-7-software-ilities-you-need-to-know/) ---
{"metaMigratedAt":"2023-06-17T06:32:15.936Z","metaMigratedFrom":"YAML","title":"INTERSECT Software Design","breaks":true,"description":"View the slide with \"Slide Mode\".","contributors":"[{\"id\":\"b78a01c3-928f-4cfa-91e6-f1ab352965ea\",\"add\":509,\"del\":13},{\"id\":\"39e1a2c8-7fdf-4915-b52d-5b83d236a20e\",\"add\":10387,\"del\":4355},{\"id\":\"d2568184-3975-4aa7-b88d-e4a047b3a729\",\"add\":250,\"del\":0}]"}
    377 views
   Owned this note