Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Engineering 2 (Refactoring (Changing code to make it easier to…
Software Engineering 2
Design Issues
Tame Problem - Easy to see what the problem is, but hard to solve. Is normally either correct or completely wrong (there is no middle ground). Eg. Traversal algorithms, game tree problems etc.
Wicked Problem - Hard to understand what the actual problem is, and cannot be fully completed. Instead, the best case is that it is solved "well enough". Eg. Translation programs, automated systems, etc.
Refactoring
Changing code to make it easier to read, without changing the behaviour.
Tests should be run after each re-factor step. Since code hasn't been changed, no new tests will be needed.
Extract Method - Creates a new method when code that seems separate from that around it, is found. It does this by copying code into the new method, and making private variables where needed. One of the most popular refactoring processes.
Bad Smells - Eg. Duplicated code, long methods, lots of parameters in a method, large classes, etc.
Inline Method - Deals with long chains of methods that call other methods and variables in other classes. It does this by swapping the data between the classes so that everything is all in one place, and things do not call each other more than necessary.
Assignments to parameters - Basically removes parameters being changed inside of methods, so adds a new variable which is set instead. This makes code easier to read.
Extract Class - Splits a class into many, when a class has too many attributes and where they can be grouped up nicely.
Inline Class - Used on small and simple classes, to merge them into another.
Replace parameter with method - Any long processes, that take a piece of input data and changes it to produce an output, are moved into a separate method.
Move Method - Basically moves a method from one class to another if, for example, the method uses many pieces of data in that class.
Structured Design
Top down - Start with a single class, and evolve the diagram from that, where you can only move from one state to another, by doing specific things.
Bottom up - Start with a group of classes, and then add the associations and dependencies between them.
Inside out - Starts with a small group of classes, which all relate to each other, and builds from there when needed.
Mixed - Start with top down and build a skeleton frame of classes. Then, use bottom up to develop those classes in small groups.
SE Processes
Waterfall Model
- Requirement Analysis and Project Planning
- System and Software Design
- Implementation and Unit Testing
- Integration and System Testing
- Operation and Maintenance
Each phase is done in a linear order, and is done to complete perfection before moving on. Documentation is a major aspect.
Feedback loop - If a problem is found at a previous step, then the progression is halted until the problem has been fixed, documentation updated and the client informed.
Rapid Prototyping during RA - A variation of waterfall, where throw away prototypes are created quickly, to get an idea of the general requirements of the system.
Iterative Models
A skeleton of the system is first created, and then a list of sections is made. Each system is fully completed before moving onto the next.
-
-
-
-
Spiral - An iterative model, which has cycles of between 6 months - 2 years. After each cycle, it is decided whether or not to continue with the project, by assessing the time and cost of the project remaining. Ideal for very large, complicated projects.
RUP
-
Elaboration Phase
High level design and analysis, resulting in a conceptual model and set of use cases. All potential risks are also outlined.
Requirement Risks - Misunderstanding of the requirements, that make sense in the writers head but not necessarily in their teams. UML diagrams are used to outline these better.
Technological Risks - The software used may not be able to carry out the processes and features required. To solve this, prototypes can be made, so that the team can test if the software is sufficient.
Skills Risks - When the developers may not have the required skills to work on the system. This may involve experts being needed, or consultants to train the devs.
Construction Phase
Tacked in small iterations, where they focus on one or many use cases.
Planning - A plan needs to made, outlining the order in which use cases should be tackled, and how much time should be spent on each. These should be ranked on value and risk.
Iteration - Design your code accordingly to the use case, a test regularly throughout the process. Documentation is sometimes needed after the iteration.
Transition Phase - A small phase just before the system version is released. May include beta testing, where bugs found are put into a new RUP for a hotfix. Often also involves refactoring.
Agile Methods
Used for very large systems, or systems that would take years to create, helps to reduce that time.
Produces useful software quickly, with minimal or generated documentation.
Prototypes and meetings are done with the client very regularly, to gain feedback. Any changes needed can be done fairly easily this way.
Extreme Programming - An agile method where the client writes user stories for each piece of functionality, and then this is used to design the implementation. The client is often needed as a fully fledged member of the team.