Hey. This is the second lecture of the course. In the second lecture, I will talk about how we can use UML to build a model to capture all the data requirements within an application domain. In particular, I will talk about how we can draw a class diagram to capture or to keep track of important objects that we have within this software system. These are all the learning objectives of this lecture. After this lecture, you will understand what is UML and how the UML can be used to model software systems. You will also appreciate that the UML is a modeling language, a language that we can use to build a model to represent a system but not a software development methodology. Finally, you will understand the basic components that we can use to draw a class diagram. For example, classes, associations, and generalization. These are all the topics that we're going to cover in this lecture. First, I'm going to give an overview about UML. Then we going to talk about different components that we can use in drawing class diagram. For example, classes, associations, association classes, generalization, etc. Also, how we can apply additional constraints on top of the class diagram. First, we will start with the overview of UML. What is UML? UML is a general-purpose visual modeling language for systems. That means we try to draw a diagram to represent a system that we're going to build. It incorporates the best practices in OO modeling techniques because we are talking about trying to capture a set of important objects within the software system. It's software development methodology or process neutral because it's not a software development methodology. Is an industry-standard OO modeling languages for modeling systems. Is very suitable for OO because in UML we're trying to capture a set of important objects within the model. If we are talking about a set of objects, then it's going to be very suitable for OO [inaudible]. But it also can be used for non-OO systems. The basic idea of UML is that we try to represent the system using a collection of important objects that exist within the software system. This is the structure of UML. Within an UML, we have different building blocks, we have different building blocks that we can use for drawing the model. For example, the important things that we have within the model, different relationships, and different diagrams that we can use to model the system. Also, we have some common mechanisms. For example, we can provide additional texture descriptions within the model. Also, we can include additional adornments, for example, you try to draw some additional things or additional adornments within the diagram. Also, some common divisions, some extra definition that you can provide to force you to think about a world in a certain way. Also, extensibility mechanisms for you to extend the model. We can build a model from different perspectives. For example, from the use-case view, logical view, implementation view, process view, or deployment view. In this lecture, I'm going to talk about the building blocks that we can use for drawing class diagram. Within UML, there are different diagrams that we can draw. In this lecture, we will talk about class diagram. In some of the upcoming lectures, we will talk about use-case diagram and also State Machine Diagram. Within class diagram, we are trying to capture all the data requirements within a software system. So we try to capture all the data requirements in a form of a collection of objects and their relationships. If we are talking about the use-case diagram, we try to capture all the functionalities provided by the system. Finally, if we are talking about the State Machine Diagram, we are talking about trying to capture all the possible states that we can have within an update. These are the three diagrams that we're going to cover within this course, the class diagram, use-case diagram, and also State Machine Diagram. Why do we build models? Let's study this example, which is pretty interesting. This may be how the customer explained about a project. Then this may be how the project leader understand it. This may be how the analyst decided it. This may be how the programmer implemented it. Then how the business consultant described it, and how the project was documented. No documentation at all. What operations installed. How the customer was billed. How he was supported, and what the customer really needs or maybe it's going to be just something simple. What's the problem here? The problem here is actually communication. Just because different stakeholders, they may have different ideas in their mind. That's why at the very beginning of the project, we need to build a model so that when we communicate, we can communicate using the model. To make sure that all the stakeholders, they're going to have the same idea in their mind by just take a look at the model. Why do we build models? Let me just talk about another example. For example, let's say when we build an airplane. Why do we want to build the model of an airplane before we actually build a plane? Because you know that the plane itself is going to be very complicated. So that's why we're going to skip some of the complicated details within the plane and then we're going to build a simpler model. This is what we call abstraction. We try to skip details and we build a model which is going to be simpler. But still somehow from the model you can visualize all the details within the plane. Then we can use the plane, that model, the model of the plane, to communicate with different stakeholders within the project. That's why we need a model. Because we need a model to communicate with different people that we have within the project. The models that we're going to build is going to describe reality. For example, the model of the airplane is going to somehow describe the actual airplane. But here we'll talk about abstraction, we try to skip details within the model of the plane. We try to show the essential details that we need for communication, and we try to filter out the non-essential details maybe just because the airplane itself is going to be can be very complicated. So we're going to skip some of the complicated things within the airplane in the model. For software development, this allows us to focus on the big picture, that means, all the important objects that we have within the software system, and this is what we mean by programming-in-the-large. By focusing on the big picture, it allows us to better deal with the complexity of software development because the software itself, source code implementation services can be very complicated. That's why instead of talking about a source code, we build a model to capture all important objects that we have within the software system. This is going to help us deal with the complexity within a software project. The result of a model is that we get better understand all the requirements within the product, putting their design, and also more maintainable software systems because we understand the software system better through a model. Why object-oriented modeling? Just because it's natural to represent things using objects. For example in the application domain, we have organizations, we have people, and then we have cars. Then people, they work for different organizations and also they own different cars. Then I just have natural to map all these things within indeed application domain as different objects that we have in the model. Within the model, we have organization, we have person, and we have car, and then we connect them together using relationships. For example, person they work for organization, and person they work for, and we connect them together using associations. For example person they works for organization and person they own different cars. It's natural to represent things using the application domain using objects, and it's going to reduce the gap between the application domain and also the model. This is natural to map things as different objects, and also better represent how people think about reality. That's why in this lecture, we're going to talk about how we can use a class diagram to capture a collection of important objects that we have within the application domain. If we are talking about OO modeling, there are different models that we can build. We can build a model to capture all the requirements within the software system. In this model, we simply try to identify all the important objects, all the important things, or all the important objects, or all the important concept that we want to keep track within the software system. Then we also can come up with a solution model. So somehow we go through analysis and design and then we build a solution model. That model is going to be the model that we're going to use for implementation. That means, when we implement, this are the objects that we're going to implement within the software system and also implementation level. Eventually we're going to implement the solution model and turn the solution model into a set of source code or a set of code objects. The same OO concepts can be used at all levels. In this course, we are going to focus on two models. One is the requirement model, to capture all the data requirements, all the important objects that we need within a software system. Also how we design, how we actually design the solution model that we're going to use for implementation. In this lecture, we focus on requirement model. Again, just keep in mind that if we are talking about the requirement model, it has nothing to do with implementation. So just given the application domain. We try to capture all important objects within the application domain, that's it. It has nothing to do with implementation. If we are talking about implementation, we are talking about the solution model. Solution model is the one that we use for implementation, but not requirement model. Requirement model is going to be simple. We know that this are things that exist within the activation domain. We try to capture all this things within a requirement model. The requirement model is going to help us understand all requirements, all the things that we need within the software system.
