Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
This first step can have other names, even just analysis, but Requirements is a good word. What is the application required to do, what must it do? Now the core of your requirements or what are called functional requirements, literally, what are the features, the capabilities of the application? What does it need to do? But there are other non-functional requirements like what kind of help or documentation needs to be provided? Are there legal requirements? If you're building a system that does banking transactions or stores healthcare data, then there may be laws that you need to comply with.
And do you know those details? If you don't, who does? Performance requirements, response time, how many people does this app need to support simultaneously? Support requirements, if there's an issue with the web application at 2 a.m. on a Sunday morning, what needs to happen? And security can be considered either non-functional or functional requirement depending on the app. Now if you're doing the app for someone else, you'd get a lot of this from your customer, your client. Now if you are the driving force behind the app, if it's your idea, it's easy to think that you've thought about this, you know all this already, you can skip this step, but that's almost always a mistake.
Most solo developers or small teams have a dozen semi-formed ideas about some of the cool features the application could have. But we're trying to get away from that here. We can't design half a feature. So not the hundred different things it might do or could do, but at least initially what the app must do. Now requirements can be phrased very simply. You'll often see requirements begin with the phrase system must or application must or program must, depending on which term you prefer.
So system must display the heart rate, temperature, and blood pressure of a patient connected to the monitor. Application must allow a user to search by a customer's last name, telephone number, or order number. Program must allow receipts to be generated via email. You can do these as fairly short, simple, succinct statements, must allow the user to create a 140-character message, must continue to function without network connection. Or you could have something a little bit more complicated as long as it's very specific.
Now on the other hand, what we could also have are a few non-functional requirement examples. So system must respond to searches within 2 seconds. This is not actually a feature, but it is something that is required. Helpdesk should be available by telephone, Mon-Fri, 8 a.m. to 6 p.m. We can talk about the laws that we need to comply with or uptime of response time. All these are considered non-functional requirements. Now the bigger the application and the bigger your organization, the more formal you're going to need to be about all of this.
Now what we're doing here-- typically called requirements analysis--is a discipline all of in itself, and if you need to take deeper than we can cover here, there are some great books on the subject that will provide a structure for doing this. Now one common approach if you need to be a bit more formal is something called FURPS or FURPS+. It sounds intimidating, really isn't. It's a simple mnemonic, it's a checklist, it's designed to prompt you, did you think about this? So starting with the letter F we have Functional requirements, the features of the app.
Usability, help, documentation, tutorials. Reliability, disaster recovery, acceptable failure rates. Are these things you need to think about now or later or not at all? Performance, availability, capacity, resources, and supportability, not just things like who maintains it, but also could this be internationalized? Would it need to be internationalized? Now often our non-functional requirements are all about the -ilities, maintainability, reliability, usability, availability.
Now in FURPS+ we add four more. We have the idea of Design requirements, it's a constraint. So must be an iPhone app or must require relational database. Not actually a feature of the app, but something you need to pay attention to. We can have Implementation requirements, so things like what's the language we're going to use? Do we have to comply with certain standards or perhaps even a methodology? Now an Interface requirement typically refers not to the user interface but to any external system that you need to interface with, and you need to specify this now.
And a Physical requirement specifies an actual physical constraint. Everything from needs to run on a device with a camera to must ship with 50 Gigabytes of DVDs. But this is not instructions, it's simply a checklist. But again, first time through what you're going for is the absolute minimum set of requirements, and that's the concept to hang on to here. Not what is nice to have, not what is optional, not all the dream features of you or your customer, only what is required.
Now it's a common mistake that people try to be exhaustive to try and have answers for everything upfront. But in an agile-iterative approach, it's perfectly acceptable to go through this and have not applicable or to be determined for some of these. And I'll say this again, you're not looking for completeness or even expecting it. Don't expect to write this once and freeze it, your requirements will change. Now technically what we're doing here has nothing to do with object orientation. If at this stage you use words like polymorphism or abstraction, you're way off base.
We don't even expect the word class or object here. So what do we expect from this? Something written down, anything from a set of bullet points on a whiteboard to a complete requirements document in a more formal process. But we need something to feed into the next part of our process to allow us to describe the application in a little bit more detail.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.