Object-oriented analysis and design facts for kids

Object-oriented analysis and design (OOAD) is a way to plan and build computer systems. Imagine you're building a complex LEGO model. OOAD helps you break down the big project into smaller, manageable "objects" or pieces. Each object is like a mini-program that knows how to do certain things and holds its own information.

This approach helps computer programmers understand what a system needs to do (this is the "analysis" part) and then figure out how to build it (this is the "design" part). It's like making a detailed blueprint before you start building. OOAD uses visual models, which are like drawings, to show how all these objects work together. People who use OOAD believe that these plans should be constantly improved and changed as the project goes on, especially as new ideas come up or problems are found.

What Are Objects in Programming?

In computer programming, an object is like a self-contained unit. Think of it as a special box that holds both data (information) and the actions (functions) that can be performed on that data. For example, a "car" object might hold data like its color and speed, and actions like "start engine" or "accelerate."

The way you can interact with an object is called its interface. This is like the buttons and steering wheel in a car – they let you use the car without needing to know exactly how the engine works. When you create a computer program using objects, the program works by these objects talking to and interacting with each other.

Object-oriented design is all about figuring out what these objects should be and how they should interact to solve a problem. This problem was first identified during the "object-oriented analysis" stage, where you figure out what the system needs to do.

How Software Projects Are Built

Building software usually involves several steps, like a journey from an idea to a finished product. These steps often include:

• Analysis: Figuring out what the system needs to do.
• Design: Planning how the system will be built.
• Coding: Writing the actual computer instructions.
• Testing: Checking if the system works correctly.
• Deployment: Making the system available for people to use.

The Waterfall Model shows steps happening one after another.

Some older ways of building software, called waterfall models, are very strict. In these models, you finish one step completely before moving to the next. It's like water flowing down a waterfall – it only goes in one direction. So, you would finish all the analysis, then all the design, and then all the coding. If you found a problem during coding that meant you needed to change the design, it was seen as a big issue.

OOAD often uses an iterative approach, where steps are repeated and improved.

A more modern and common way, especially with object-oriented programming, is called iterative models. This is like building a LEGO model in small stages. You might build a part, test it, then improve it, and then build another part. In iterative models, you can work on different steps at the same time. For example, you might be doing some analysis, design, and even coding all in the same day. If you find a problem in coding, you can easily go back and adjust the design or analysis. This approach recognizes that building software is a learning process, and you often discover new things as you go along.

Most object-oriented systems are built using this iterative approach. This is why "analysis and design" are often thought about together in OOAD.

Why Use Object-Oriented Design?

Object-oriented design helps make software easier to manage and reuse. It focuses on two main ideas:

• Modularity: Breaking a big system into smaller, independent parts (objects). This makes it easier to understand and work on different parts without affecting the whole.
• Reusability: Designing objects so they can be used again in different parts of the same project or even in new projects.

A key goal of OOAD is something called the "open-closed principle." This means a software part should be:

• Open for extension: You can add new features or behaviors to it without changing its original code. For example, you can create a new type of "car" object (like an "electric car") that builds on the existing "car" object without changing the original "car" code.
• Closed for modification: Once a part is working, you shouldn't have to change its core code. This helps prevent new errors from being introduced. Objects achieve this by having clear ways to interact with them (called "methods") and by keeping some of their internal workings private.

Analysis vs. Design: What and How

The difference between analysis and design is often described as "what versus how."

• Analysis (What): In this phase, developers work with the people who will use the system to figure out exactly what the system needs to do. They focus on the goals and requirements without worrying too much about the technical details of how it will be built. For example, they might define that the system needs to "allow users to create a profile" or "process online payments." In OOAD, this often involves creating "use cases" (descriptions of how users interact with the system) and defining the main objects involved.

• Design (How): After understanding what the system needs to do, the design phase focuses on how it will be built. This is where technical decisions are made. Designers decide which programming languages, databases, and other technologies will be used. In OOAD, this means describing the specific objects, what information they hold, what actions they can perform, and how they will interact with each other. The design plan should be detailed enough for programmers to start writing the code.

Object-Oriented Design (OOD) in Detail

Object-oriented design (OOD) is the process of planning how a system of interacting objects will solve a software problem. It's about creating the blueprints for your software. You define "classes," which are like templates for objects. Then, when you create an object from a class, it gets all the features and actions defined in that class, but it can have its own unique information.

During OOD, designers take the ideas from the analysis phase (which are usually technology-independent) and add real-world limitations. These limitations can include:

• The type of computer hardware and software that will be used.
• How fast the system needs to be.
• How data will be stored (like in a database).
• How easy the system is to use.
• Budget and time limits.

OOD also involves choosing the overall structure of the software, often using special "architectural patterns" and "design patterns." These are like common solutions to recurring problems in software design.

Where Does OOD Get Its Information?

OOD uses the information gathered during the object-oriented analysis (OOA) phase. It's important to know that OOA and OOD don't always happen one after another in a strict line. Often, they happen at the same time, with ideas from one phase helping to refine the other. It's a continuous process of building and improving.

Some common sources of information for OOD include:

• Conceptual Model: This is the result of the analysis phase. It describes the main ideas and objects in the problem you're trying to solve, without worrying about how they'll be built.
• Use Cases: These are descriptions of how users interact with the system to achieve a goal. For example, a "Login" use case would describe the steps a user takes to log in. Use cases often include "system sequence diagrams" which show the order of events.
• User Interface Documentation: If available, this shows what the system's screens and buttons will look like. It helps designers visualize the final product.
• Relational Data Model: If the system will use a traditional database, this model describes how the data will be organized.

Key Ideas in Object-Oriented Design

There are five main ideas that are built into object-oriented programming languages and are central to OOD:

• Object/Class: A class is like a blueprint or a cookie cutter. It defines the properties (data) and behaviors (actions) that objects created from it will have. An object is an actual item created from a class. For example, "Car" could be a class, and "my red car" would be an object of that class.
• Information Hiding (Encapsulation): This is the ability to protect some parts of an object from being directly changed by other parts of the program. It's like a car's engine being hidden under the hood – you interact with the car through its controls, not by directly messing with the engine parts. This helps prevent mistakes.
• Inheritance: This allows a new class (called a "subclass") to take on the properties and behaviors of an existing class (called a "superclass"). It's like saying an "Electric Car" class can inherit all the basic features of a "Car" class, and then add its own unique electric car features.
• Interface: This defines a set of actions that a class promises to perform, but without saying exactly how it will perform them. It's like a contract. Any class that agrees to this contract must provide those actions.
• Polymorphism: This means "many forms." In programming, it allows you to treat objects of different classes in a similar way, as long as they share a common interface or superclass. For example, if both a "Car" object and a "Bicycle" object have a "move" action, you can tell either one to "move" without needing to know the specific details of how each one moves.

Designing the System

When designing with OOD, you'll typically:

• Define Objects and Classes: Turn the ideas from your conceptual model into actual classes.
• Identify Attributes: Decide what data each object will hold (e.g., a "Car" object might have attributes like "color" and "make").
• Use Design Patterns: Apply common, proven solutions to design problems. These are like recipes for solving specific challenges in software.
• Define Application Frameworks: Use collections of pre-written code that provide a basic structure for your application. This saves a lot of time.
• Identify Persistent Objects: Figure out which objects need to save their data even after the program is closed (like user profiles or game scores).
• Define Remote Objects: If parts of your system will communicate over a network, you'll design those connections.

What Comes Out of OOD?

The main results of object-oriented design are often visual diagrams that help programmers build the system:

• Sequence Diagram: This diagram shows how different objects interact with each other over time, like a timeline of messages being passed between them.
• Class Diagram: This diagram shows the structure of the system by displaying all the classes, their data, and how they are connected to each other. It's like a map of all your blueprints.

Important Design Principles

Some key ideas that guide good object-oriented design include:

• Dependency Injection: This is a way to give an object the things it needs to work (like a database connection) from the outside, instead of the object creating them itself. This makes the object more flexible and easier to test.
• Acyclic Dependencies Principle: This means that the different parts of your software should not create a circular dependency. For example, if Part A needs Part B, and Part B needs Part C, then Part C should not need Part A. This keeps the system organized.
• Composite Reuse Principle: This suggests that it's often better to build new objects by combining existing objects (composition) rather than always using inheritance. This can make your code more flexible.

See also