Project Design And Uml Class Diagrams

Hello and welcome back to the video lecture series for introduction to the art of programming using Scala in the last video, we started doing an analysis of our project. We used a use case diagram to look at the things that the project would do in this video we're going to kind of step forward to the next phase of software design after we've done a complete analysis, or at least complete enough that we can get things going. Oh, we want to switch to design. You know, in the Disney analysis phase. You're, not only not coding you're, not even thinking about code, you're, you're, really just thinking about what is the program going to do? What is the interface going to be like? What are the options that the user can can select in here?

When you hit the design phase, you start to answer the question, how am I going to make that happen? How am I going to bring that about in code? Now, the design phase does not actually include coding. Normally it's its, just thinking about how you're going to put that. Together in the code, and if you're working in a class-based object-oriented language, like Scala, a lot of times a big part of the design is laying out the classes that you're going to use. Now it turns out that for the design aspect, there are lots of different diagrammatic ways of looking at the problem, and we're just going to focus on one here in some ways it's, the simplest that's, the easiest one for us to stay understand based upon the things that we've done so far, and that we'll be doing.

Here and that's class diagrams. So what I'm going to do is I want to start building a class diagram for the project that we started talking about last time this electronic classroom. So once again, I am working in created, you can decide how you want to do your UML. There are lots of UML tools out there. In addition to being lots of UML tools, it is perfectly valid to use, pencil and paper because UML is intended to make it easy to work with pencil and paper. So a class diagram is fairly simple as.

They imply primarily what you're doing is you're, laying out classes. And so in the case of our electronic classroom, oh I can kind of layout I'm going to have at least two mains. Now, I didn't really hit this in the analysis. I was going to mention the fact that we were drawing a client. There would have to be a server and I can reflect that here in this I'll make a client main. And technically, this is an object and just to make that clear I will put a little annotation of top saying, this is an.

Object and our classes have three different sections to them. So when you build a class, you have a box, and it's divided into three areas. The top area is giving you the name and as well as any little annotations for. So as I said, in this case, I want to make it clear that this is not just a class. This is an object declaration, that's going in there, object, declarations aren't part of the standard UML class diagram description because they're kind of specific to Scala it's. The'll see in the next. Chapter another thing that is specific to Scala and doesn't quite match what's in standard UML, but we can still continue using the UML diagrams they'll allow us to communicate what we want to.

Because remember, the big idea of the UML diagrams is to let us lay out ideas and to be able to communicate with other people in some ways we're, not worried that much about the details. There are tools that will take UML diagrams and convert them and build a code template kind of stubbing out the code. From the diagram or go the other way, they'll take code, and they'll generate diagram for you. There are those tools they generally cost money, and we're, not dealing with that here we're interested in the UML for the sake of communication.

So my client main is going to have a main method in it and I will go ahead and also create a server. Main also I will annotate this as an object. No deaf, just main plus main arms is an array of string. So you can see this little plus sign here, uh in standard UML, you. Denote disabilities, and we talked about disabilities previously in chapter 16 when we're talking about object orientation, you denote disabilities with a symbol. And so public visibility is denoted with a plus private visibility is denoted with minus and the protection visibility, which we haven't really talked about yet will hit on that in the next chapter is a pound sign or a hash.

So here I have the two main objects that I'm going to use. And what other types of classes are we going to need so. When we think about this, this application, inevitably, there is some type of class that represents the students, so I'm, probably going to have a class for student, not exactly certain at this point. What I might put inside here.

What information does the student need to know, I guess, the student probably needs to know their name it's, a string. They probably need to know their password also a string. So that we can do authentication on them. We might want to have some form of an ID number on them, which. Could be a string or actually a numeric value, and there might be some other things such as what courses they're taking, and we can come back and refine that later on, but that's, a reasonable starting point for us. There will be a very similar class for the instructor instructors should probably also have names.

It will also have passwords it's possible that they will. We will want them to have an ID just so they have something that is a unique. Identifier in case, two instructors have the same. Name or whatnot, and it could be actually, we might have both a regular a full name and a username as well. And we could add that into here. Okay.

So those are two of the classes that we might put into our UML diagram. In addition to these, we have kind of the main data for that. Your program needs to keep track of every semester all the courses that are in that semester.

And then each course needs to keep track of what students are in it as well as things like the quizzes and tests and. Exercises and all of that stuff. And once again, the have that problem of paralysis by analysis, it is possible to try to think of every single method in every single property and everything that you want to put in every single class that is inside a project while you don't want to shortchange the design process.

You actually do want to work on doing it. You don't want to paralyze yourself by spending all of your time doing absolutely everything and making sure that you have every single detail. In there because the reality is you won't, it's, almost impossible for you to come up with every single detail that you might need, but I do want to go through just a little of this. So that we can show at least one other feature of an um of UML class.

Diagrams let's see do believe that I have the ability to zoom out just a little there. We go. Okay. You might not be able to read the text.

So well of that zoom level, if there's something in between the 60 and 175 that works pretty well. Okay, um, so a semester keeps track of courses there are multiple courses associated with each semester. And so we can come inside here and say, okay, well, this has some type of sequence of courses is a sequence, of course, and we could decide to be more specific about that later. But one of the things that also goes into a class diagram. In addition to little boxes with all the classes, just like the use case diagram.

We can draw lines between things. And so, for example, the fact that this says. That a semester includes courses, uh means that there is a dependency in between here, and you can utilize their different ways of denoting dependencies.

In this case, the semester is composed of courses. So we can put that on there to say that there are multiple courses that are inside a semester you'll note that there is a particular Arrowhead that is on here for this type of Association we'll, see later on that. There are other types of things associations between things. Our. Courses, for example might well, every course needs to keep track of the instructors are allowed to edit it. And it also needs to keep track of the students that are in the course.

And so here again, we have a dependency courses are composed of students, and they're composed of instructors. Well, isn't that that's a fun little feature. Um courses are in addition going to keep track of whatever activities you have. So we might start playing around with us further and saying, okay. So we're going to have.

Something that represents a class that represents a quiz in here, and the quiz is going to have some questions associated with it, we'll have to think more about the details of that. And one of the things about this is that we have, for example, have a quiz, and we'll have a test, and we'll probably have some form of an exercise, and I'm going through this step right now without putting anything in here, just to show that in some ways we have these things, and they are related to one another, and that. Was going to wind up being significant to us.

Now the fact that the class diagram includes these lines that are connecting things winds up being pretty significant. Now at first, it might seem to you. Well, this really doesn't tell me all that much.

But it turns out if you draw all the dependencies between classes in a class diagram, the class diagram really helps to let you see what aspects of the code are very critical. Realizing here that our server is probably going to keep track of all. Of the different semesters, which will then be a sequence of semester. And then of course, that means that it connects to there as a composition.

So it is composed of semesters along with other information. And so you can imagine as this gets bigger and bigger and bigger. We might have a situation where you can look at it. And imagine you had one class.

So let's say, this course, had like 12 arrows coming in to it. The that would mean there were 12 different things that were dependent. Upon course, that.

Right there is a significant sign to about your software that that course because so many things depend upon it, a needs to be written well. And it probably needs to be designed well, early because it's, one of these things that when you have a lot of dependencies upon a class changes to that class propagate out through the code. And so if you had 12 lines coming into, the course, changing course, might break 12 other classes that were somewhere in your project, and that would be bad. So you. Like to have a diagram you're, not going to get away with no arrows between things you're, definitely going to have some arrows between stuff, but you don't want to have areas that have lots and lots of arrows coming in to them, because then your entire code is highly dependent upon that.

And that becomes an easy breaking point. Your code gets a little fragile because of that. So hopefully you can see how these class diagrams will help you when thinking about your software and trying to lay. Things out, um, you can see the general structure they're just little boxes.

They have three segments. The name of the class, the properties, your data members that go inside and whatever methods we have. And we have not filled this in very much you'll. Even notice one thing that's, that's listed here, there's a simple class and I would use this more if I were doing stuff for example, on a whiteboard. But if I really don't care at all about what is inside of something okay, let's just say, I had an answer and. I really don't care what the properties or the methods of this are I could use the simple class, and it's just a box.

And it just has a name in there. And quite honestly, when I am drawing things on a whiteboard, that's about the level that I do for anything that I don't have to be writing down methods for just like with the use case. These diagrams are for communicating ideas. And to help us see things from a different perspective that is hopefully more valuable than trying to write prose down.

For everything so that's it for this video and next time we will come back, and we'll start trying to write out some code for this, and we'll quite possibly revisit the diagrams occasionally to update them. So they can reflect the aspects of the code.

Dated : 25-Mar-2022

Leave Your Comment