Welcome to course number two in the series on Secure Software Design. In course number one, we talked about design as an element of the software development life cycle. In this course we'll talk about design as an abstraction. You might be wondering what's the difference between design in the software development lifecycle and design as an abstraction. When we look at the role of design in the SDLC, we think about it in the context of its position between requirements and implementation or code in unit test. In a sense, design would be a bridge between those two phases, excepting requirements and outputting instructions to the developers. But this ignores the idea that design serves a purpose besides providing a path between requirements and implementation. Since we can think of design occurring at a higher level than implementation, design also serves as a high point of perspective on implementation. A UML on an E sized page can be the equivalent of 10,000 lines of code. In implementation we're down in the lines of code and sometimes it's difficult to see the whole scope of the project or even a portion of the project. This is much easier to do at the design level, because design is more general than implementation. We tend not to get lost in the weeds. As Frank Lloyd Wright said, you can use an eraser on the drafting table or a sledge hammer on the construction site. The idea here is that it's much easier to change the design than the implementation that follows it. And I have to say this is talking about design in a correct way. I have been on projects where design actually followed implementation. The contract specify that there must be a UML Unified Modeling Language class diagram for the code. The easiest way to produce this without thinking I might add, was to use a tool that created the diagram from the code. While this might have served contract obligations, it did not help the project any. You have perhaps experienced something like this when writing papers for school. I can remember in high school when teachers wanted students to turn in an outline of the paper before the actual writing process began. Like many students I felt that outlining was unnecessary and a nuisance. We basically refused to do it and perhaps it was because the papers were short and the subject simple it was easy. But when writing a Ph.D. dissertation you can't just write what you're thinking about for 350 pages and have it make sense to another reader. When approaching a project that size, there needs to be a higher level of view so that when the final document is written, it follows a logical and easy to understand path and so does with software. And it is very much like the paper writing process. The design casts the overall form of the project. It can be adjusted rather easily if the parts aren't quite right or of the flow of the work through the software isn't quite what it should be. In this diagram, we are representing two different ways to design a class for a stack, one of the basic data structures in computer science. On the left, we have a stack class which is derived from an array list. Now this is Java we're talking about, similar structures exist in C# and C++. On the right, is a different design for the same thing. In this case, the array list is a member variable of the stat class. Functionally, we can do the same thing with either design. The implementation is of course quite different. It would take several several hours of coding to recast the design from the left side to the right side. The actual design doesn't take much time at all to alter. For me, design is my favorite part of the project. I don't have to interact with lots and lots of people like the requirements phase and I don't need a compiler a database, an integrated development environment to do my work. I can sit in a coffee shop with my notebook and just draw. Drawing. Isn't that interesting? Requirements are written in words. Implementation is done in source code language. In design, we're drawing boxes and circles and connecting them with lines and arrows, that's different. And the big difference here is that we are visualizing, we're seeing. When we have diagrams of things. We're using the visual parts of our brains to understand the situation. That's different from using the language processing areas of our minds. In many languages, "I see" is equivalent to "I understand". So in design we are understanding the problem and hopefully it's solution. Think about how difficult it would be to solve a maze if you had a textual description of the maze. Seeing a drawing of the maze would yield a solution in a much shorter time than in reading a document with a linguistic process. So in design we have a process which is much more than the thing that bridges requirements and implementation. We have a step that requires understanding. Right now, we're in the middle of a semester at UCCS. I have students struggling with programming assignments who come to my office to ask for help. And our time is spent at the white board, drawing things. The students have what could be called the requirements in the form of a homework assignment sheet. So often though, understanding the requirement means a drawing. One student said to me earlier this week, the coding isn't so hard, it's understanding the problem. Bingo. That's why we worked so hard on design. Remember design is the visual phase in the software development. But the problem is not understood in this phase. It never will be.
