Decomposition

Decomposition Strategy for handling complexity Break problems into smaller pieces A n entire program is too much to create all at once, so programmers break a problem apart into pieces. If you master the strategies of decomposition in computer science, you can apply it to problem solving in any area.

Modularity Components each have a function When deciding how to break a problem apart, make the pieces modular if possible. Each modular piece has a function. Each component accomplishes its own function. The pieces can depend on each other with the details of how other components work. In an animal, the heart pumps blood. The kidneys clean the blood. These are separate functions performed by separate components.

Modularity Components connected but independent Reusable Like an animal, computer hardware and software use modular design to break a problem apart into components. If kidneys fail, a dialysis machine can clean the blood; the heart still does its job the same way. This motherboard attaches to each of a computer's components. If a network card breaks, it can be replaced with another one. When designing and creating a network card, engineers don't have to worry about the details of how the computer's memory works; that's a different modular component. Breaking apart a big problem into pieces helps, and it helps a lot if the pieces are modular.

Design process: Agile methodology Method for developing software solutions Frequent deliverable iteration The design process for software is very similar to the design process for other forms of engineering. Programmers often use a design process that we call Agile. Agile methods emphasize frequent presentations to the client, sharing the solution developed so far. This way the client can help clarify the definition of the problem.

Agile methodology Frequent deliverable iteration One cycle called a sprint Each cycle is called a sprint and may last 1-3 weeks for a professional team. We define the problem, strategize, code and test, code and test, code and test, code and test, strategize, code and test, code and test, code and test, try it out with a user, and show the client. Then do another sprint: define, strategize, code and test, code and test, …

Organizing Agile work Backlog Sprint task list First sprint Second sprint Later sprint(s) Prioritized Top of backlog well defined User stories Task #1 for this sprint Task #2 for this sprint Task #3 for this sprint Bite-sized pieces of the top backlog item Programmers usually organize their work using two lists of things to do. One list, called the backlog, has big items on it. Each sprint, the team will try to get 1 or 2 of these backlog items completed. The backlog is prioritized, so that the next items to complete are on top. Because the problem might get redefined, the items lower on the backlog can be poorly defined or too big. The top item on the backlog should be clearly written, though, and small enough to get done in one sprint. At the end of sprint, the backlog is groomed, and items rising to the top must be broken down into clearly defined items of a good size. Each backlog item is written as a user story.

User stories in the backlog User story … ______ wants to _____ so she can _____ User stories are written in a particular format: so-and-so wants to do such-and-such so that she can do such-and-such. By focusing on who the user is and what they want to accomplish, the programmer is more likely to create a product that meets the need. User role Action Purpose

Top backlog item split into tasks Sprint task list First sprint Second sprint Later sprint(s) Task #1 for this sprint Task #2 for this sprint Task #3 for this sprint Bite-sized pieces of the top backlog item The top user story in the backlog is decomposed further into smaller tasks listed on a task list for the current sprint. The pieces are small enough that one or a few can be accomplished in a day of work.