 In the previous video, we talked about modeling a software design. Modeling is a way of creating an external explicit representation of the system to be built. In this video, we will look at the unified modeling language or the UML diagrams. These diagrams can help us represent the software design via multiple views and at a greater level of detail. Let's look at what these views are. Two important views of a software system are the structural view and the dynamic behavioral view. So, what is a structural view? The structural view defines the structure of the software system. They describe the things in the system and the relationships to other things. The structural view describes the logical parts of the system including the classes and relevant data and functions in these classes. They do not describe the time dependent behavior of the system. One such diagram which represents the structural view is the class diagram. The class diagram is a type of a static structure diagram that describes the structure of a system by showing the system's classes, the attributes, the operations or methods and the relationship among these objects. The diagram shown on this slide describes the class diagram of the mode-based music player. The class diagram is the main building block of object-oriented modeling. In class diagrams, the classes are represented with boxes that contain three compartments. The top compartment contains the name of the class. The middle compartment contains the attributes of the class and the bottom compartment contains the operations of the class which can be executed. We see that the class diagram models relevant classes like the user, the user voice profile, the playlist, the songs and so on. Each of these classes contain data members and functions necessary to realize certain behaviors of the mode-based music player. For example, the user mode class has a data attribute mode name which stores the current mode of the user. The detect mode function in the user mode class updates the mode name variable based on the user and the user voice profile data. The dynamic behavior view describes the behavior of the system over time. Various views include the state machine view, the activity view and the interaction view. The state machine view models the possible life histories of an object of a class. The activity view shows the flow of control among computational activities involved in performing a calculation or a workflow. The interaction view describes sequence of messages exchanged among different parts of a system. It gives a holistic view of the behavior in a system by showing the flow of control across many objects. The behaviors corresponding to the requirements of a system can be implemented using sequence diagrams. The diagram on this slide represents the sequence diagram which describes the behavior of the mode detection requirement for the mode-based music player system. The classes from the class diagram are represented in the sequence diagram on the top and they have parallel vertical lines called the lifelines. The horizontal arrows which you see are the messages exchanged between them in the order that they occur. These messages can be functions from the class diagram such as detect mode, generate playlist and so on. This sequence of messages correspond to the implementation of a given requirement or sub-requirement. In a similar fashion, sequence diagrams can be constructed to model other requirements as well. For example, the sequence diagram in this slide models the login feature for the mode-based music player. There are several other UML diagrams such as state charts, communication diagrams, activity diagrams, etc. which can be used to adequately model a given software design. Details of various UML diagrams can be found in the extra resources provided in this week. During the software design process, a subset of these UML diagrams are used to create the design model.