We've completed our walk through the analysis phase or analyze phase of the systems development life cycle. We've learned how to prepare requirements, test cases, use cases, we've learned how to draw process models and data models. We've done a lot. However, the business analyst's job is not done once the analysis phase concludes. The BA continues to have responsibilities in both design and implementation. We're going to use this module to talk about the BA's responsibilities in these phases, as well as introduce you to the basic vocabulary used in design and implementation. This is so that you can be aware and participate intelligently in conversations about design and implementation of systems. We've covered planning documentation like project plans, work breakdown structures, and many others. In analysis phase, we talked about requirements, test cases, use cases, data models, as well as process models. Now, we're going to talk about translating our requirements into actual system specifications, and then the implementation of those. We'll talk about things like building versus buying systems, as well as how we kind of translate a requirements into actual specifications that programmers can implement. Let's begin our discussion by talking about something called object-oriented programming. After this video, you'll be able to define the object-oriented approach to systems development, as well as give examples of a class, object, and method. Finally, you'll be able to describe the relationship of something called UML or the unified modeling language to object-oriented development. Right now, it might seem like an alphabet soup, and perhaps you're confused at work, but this will help you sort out the differences between all these various terms. This isn't an object-oriented programming course, don't worry, you won't see any computer code on the screen here. The idea is to simply introduce you to the vocabulary that you're likely to hear as system implementors do their work, so that, again, you can participate in the discussion in an intelligent way. The traditional approach to computer programming involved it's what we call procedural approach. We would give instructions like we would give instructions to a robot. So, for example, if you wanted someone to pass you the turkey, you wouldn't say, "Pass the turkey." You would say, "Lift your right hand and move it until it makes contact with the turkey. Pick up the turkey and then pass it to me." It'd be silly obviously to talk that way. It's a silly in systems development as it is at the Thanksgiving dinner table. So, in object-oriented programming world, we set up the system such that we can just say, "Pass the turkey." This makes our systems much easier to maintain over time, as well as much easier to understand. Developers found, after a long time, that the old procedural approach had an effective limit to how big the system could be before no human could understand it. Object-oriented approaches help us decompose the system functionality in such a way that humans can wrap their head around the design of the system. Again, we're not going to teach you how to be a developer here, but we'll just introduce you to the terminology that enables this. Let's begin with a philosophical discussion as to whether the object-oriented approach was evolutionary or revolutionary. The textbook on which you base this course makes a couple of different arguments. One, is that it's an exciting enhancement, the systems analysis design, it is the application of object-oriented approach. On the other hand, the incorporation of objects as an evolving process in which OO techniques are gradually integrated into mainstream SDLC. In practice, what I think you'll find is that many large software projects do have an object-oriented orientation to them. On the other hand, most smaller development efforts, for example, a small script to process some data, still use the old procedural approach. In an object-oriented project, you're likely to hear more about use cases. We've already studied use cases, so you know what they are. We also typically use a more iterative design approach. Object-oriented projects by definition tend to be bigger than smaller procedural projects which might be just a single developer, and so we typically introduce a lot more formal methodologies. This could be traditional methodologies like the SDLC or agile methodologies which we've already talked about are really just an innovative take on the traditional SDLC. One thing that's big in object-oriented environments is something called UML. UML stands for the Unified Modeling Language, and it's not necessarily a computer language per se, instead, it's a diagramming language. So, we use UML to draw diagrams, not unlike these diagrams we've already seen. In fact, use case diagrams which we covered earlier in this course are one type of UML diagram. In this section of the course, we'll explore other types of UML diagrams. On the technical side of things, you're likely to hear developers on an object-oriented project talking about things like classes, objects, methods, states, inheritance, and so on. We'll talk a little bit about what these concepts mean, again, so that you can participate in the discussion. Then finally, we'll overview some additional specific UML diagrams, we've already seen in use case diagram. We'll take a look at things like class diagrams, package diagrams, activity diagrams, as well as the family of UML diagrams that's available. Object-oriented projects generally make heavy use of use cases. The use case is the primary analysis phase modeling tool for many old projects because they focus on the user's interactions with the system. The object-oriented approach attempts to effectively model the real-world inside of the computer program. We do that by taking effectively the nouns from our analysis, so we might have a person, an order, and so on, and we turn those into classes in our system. The kinds of things that a human might do with those objects, we then turn into operations or processes that we call methods in the system. This is just some of the vocabulary you're likely to hear on an object-oriented project. Also, object-oriented projects typically make use of more iterative methodologies. So, instead of a traditional waterfall, which is what we've used to walk through the course, instead, what you'd have if something looks much more like the RAD, or Rapid Application Development methodology that we presented earlier in the course. In fact, if I go to the textbook on which we base this course, and I look at the diagrams from Chapter two where we introduced RAD and Chapter 14 where we talk about object-oriented programming, you'll notice that they're almost identical. I mentioned earlier UML or the unified modeling language. This is not really a computer language per se, but it's a family of diagramming conventions that lend specific syntax to special types of diagrams. Now, depending on the kind of version of UML you're looking at, you might have in this particular case, we have 14 diagrams, and there are quite a few more. We're not going to walk through all of these, but we'll introduce you to some of the most common ones and show you examples of them on the screen, so that when you encounter them at work or wherever else, you at least know what they are, and a little bit about how to read them properly. Let's talk through some of the object-oriented concepts that we introduced a few slides ago, and let's look at what these mean in a more concrete sense. We're going to start with the basis of all object-oriented programming which is the concept of an object. Objects are effectively instances of something called a class. You can think of a class as a specific kind of person, place, event, or thing about what you want to capture information. An object is a specific person, place, event, or thing about what you want to capture information. In the example here, you can see we might have a class in our system called patient, and we might create an object based on the patient for the specific patients, so specific patient would have a name, and a birth date, and other attributes that we might want to collect. There are a lot of different analogies or metaphors that instructors use to communicate the relationship between classes and objects. One I find that resonates quite well is the idea of a cookie cutter. When you make cookies you have a cookie cutter that might be in the shape of a star, circle, or whatever it might be. You then use that to stamp out individual cookies. The cookie cutter is the class and the individual cookies that you make with that are effectively the objects. The technical terminology that we would use is that an object is an instance of a particular class. Let's take a look at that with a concrete example. We might have a class to represent a vehicle. We can call that class car. That class will have several attributes, so all of our vehicles, for example, have a vehicle ID number, particular color, maybe horsepower, number of cylinders, miles per gallon, and so on. You can probably sit around and think of a number of attributes that every car has. There's also some things that we can do with a car. We can retrieve information about its maintenance history or we can calculate when we need to take it in for its next oil change. These are called methods. So, the class is a car, it has attributes that you see on the left here and some methods, and you can probably think of some others. We would then use that class to create a specific instance or object inside of our computer program that represents a specific vehicle. In this case, the specific vehicle might be your 68 Volkswagen. It has a particular vehicle ID number here, it's a specific color, number of horsepower, cylinders, and so on. The methods would get the maintenance record for that specific car or to calculate the next oil change, again, for that specific car. Objects also have an internal state and that could be track any number of things. But in this example, we might use the state to track the ownership state of the vehicle. So, it's owned, for sale, maybe under offer, or sold. Hopefully, this helps you understand the basic relationship between classes and objects. In future videos, we'll dive into more of the object-oriented world to get you oriented and give you some context for participating on these types of projects.
