Software Engineering Design & UML

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

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.

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.

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…

Ideal Program Division Control, UI Data Algorithms

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.

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.

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.

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.

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.

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.

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, …

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.

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

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

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

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

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.

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.

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

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

Design

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.

Design

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

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

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.

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

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!