1. Software Engineering
Design & UML

2. The Waterfall Model Marketing Analysis Design Implementation Testing
Requirements
Analysis
Specifications
Design
Architecture
Untested
Software
Implementation
Testing
Program
Maintenance

3. Design
Once the specification is completed, the next step is to determine the design for the desired system.
That is, once we know “what” sort of system is both possible and acceptable to both parties, we may then turn to the question of “how” to make that system.

4. Design
The goal of the design process is to develop the potential structure for a codified system which would fulfill the determined specification for the desired program.
Basically, we want to figure out how we would ideally code up the program before actually writing a line of code.

5. Design
This process will often involve splitting the underlying problem into multiple pieces that are simpler to solve.
This is then done, repeatedly, until these smaller problems are reduced to the object level.
One early potential split of the problem…

6. Ideal Program Division
Control, UI
Data
Algorithms

7. Ideal Program Division
The manner by which the different data elements will be represented internally does not have to be tied to its representation for input or output.
At the same time, we should design objects to make the task of input and output easier.

8. Ideal Program Division
As noted when discussing “use cases”, sometimes not all users of system should have access to the same user interface. (UI)
Each type of “actor” should only be able to use program features it needs.
As such, the true, core functionality of a program should not be linked directly to any single UI within the system.

9. Ideal Program Division
Polymorphism is often useful for allowing storage structures or general-purpose algorithms to be reusable for multiple types of data.
In essence, good use of polymorphism can often simplify the design or implementation effort of a program and enable “plug-and-play” code reuse.

10. Ideal Program Division
At other times, polymorphism can be used to allow smaller parts of functionality to be variable within a large method.
Function pointers are useful, but there are complications and aren’t always directly available in some programming languages.

11. Ideal Program Division
1111
This is actually done in Paint.NET, a freely-downloadable image editor – unfortunately, the source is no longer available, but I downloaded it once before it became restricted and looked at its architecture.
Ideal Program Division
Polymorphism can be quite useful for abstracting elements of the UI to work in multiple manners.
In photo-editing software, each “tool” that can be used to edit an image can be a separate interface.
Changing the active “interface” changes how mouse-clicks and such are interpreted, based upon the interface’s implementation of appropriate methods.

12. Class Hierarchy
As with the process of determining requirements and the specification of a program, it is often helpful to have visual diagrams to aid in the design process as well.
For design, we now wish to capture the relationships among individual classes.

13. Class Hierarchy
How can we represent these design ideas for a given programming project effectively and efficiently?
One super-common visualization tool for the design process is known as UML: the Unified Modeling Language.
Not to be confused with HTML, XML, …

14. Class Hierarchy
In UML, each class and interface gets specified, along with arrows to show the relationships among them.
Furthermore, the methods (and fields, for classes) of each are also specified.
This establishes a standardized, known interface that other coders on the team may then use for each object type.

15. UML Standard structure of a UML diagram element for a class: MyClass
- int integer_field
- string string_field
+ int get_Integer_Field()
+ void set_Integer_Field(int)
+ void doSomething(String, int)
Class Name
fields
methods

16. UML A ‘-’ indicates the private modifier, and ‘+’ the public modifier.
MyClass
- int integer_field
- string string_field
+ int get_Integer_Field()
+ void set_Integer_Field(int)
+ void doSomething(String, int)
Class Name
fields
methods

17. UML
Let’s examine how this can be useful for a program’s design through some example code: a Tic-Tac-Toe program.

18. UML <<type>> Participant
+ Position getMove(char, TicTacToeBoard &)
<<type>> indicates that Participant is a “pure” abstract class, with no fields or definitions.
Human
Computer
- MoveEvaluation getMoveInternal(char, TicTacToeBoard &)
+ Player getOtherPlayer(Player)
Denotes that the Computer class utilizes the other.
MoveEvaluation
+ Position bestPos
+ Player winner_when_minimize_opponent

19. UML
TicTacToeGame has fields of the types pointed to by solid, open-ended arrows: Participant and TicTacToeBoard.
TicTacToeGame
- Participant* player1
- Participant* player 2
- TicTacToeBoard board
TicTacToeBoard
… A lot of stuff.
I’ll spare that for now.
Participant
(abstract)
+ Position getMove(char, TicTacToeBoard &)
Participant uses the TicTacToeBoard type as a parameter for (at least) one of its methods.

20. UML
UML thus allows us to visually model the conceptual (and eventually-to-be codified) relationships among the elements of a program.
It visually represents the polymorphic nature of the different types which will be implemented.
It also models the general dependencies across types.

21. 2121
Self-reminder – show that there code!
Questions?

22. Design
Referencing back to our work in last lecture, note how we made use of some of the ideas of UML.

23. Design

24. Design
C++ header files are somewhat like a text-based form of UML for the objects they declare.
UML additionally aims to visually show the relationships between objects in a graphical manner.
For header files, you’d have to manually look across them to determine relationships.

25. Design

26. Design
While not quite using the same visual syntax as UML, we clearly established the relationships among the declared types of our program.

27. Design
Note how in an earlier lecture, we worked out the core design for the important objects in our shapes program.
BoundingBox
Shape

28. Design
Note how we never got to actually implement Shape, but we knew how to use it to implement BoundingBox.
We never actually even wrote Shape.h properly, due to time constraints.

29. Design
With UML, we clearly define the important types within the program and what would be necessary methods for them to provide
As a result, we could implement what we did, how we did, without needing to see the unimplemented parts

30. Design
In terms of a large project, those other parts could easily have been left to someone else to implement
The interfaces entirely define the interactions
Ah, the joys of abstract data types and information hiding!