UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 4.7 Free with a free account
Designing with Objects: The OOAD Approach
System Analysis and Design · Chapter 4: Requirements Validation, Modeling, and UMLSection 4.7 · lesson 30 of 699 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of System Analysis and Design.
Lesson complete
Earn the 3 college credits for System Analysis and Design
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: UML Structural Diagrams: Object Diagrams and Class Diagrams Compared and Applied →← Logical vs. Physical Data Flow Diagrams: What Sets Them ApartNext lesson: UML Structural Diagrams: Object Diagrams and Class Diagrams Compared and Applied →
In this lesson
Objects, classes, the 4 pillars, and finding classes in a requirements narrative.
- Define objects and classes, and how they relate
- Explain encapsulation, inheritance, polymorphism, and abstraction
- Distinguish OOA from OOD; apply noun/verb analysis and CRC cards
- Compare the structured and object-oriented approaches
Transcript
Everything said in the video, section by section (1,218 words). Read along, or search it.
Requirements Validation, Modeling, and UML
Designing with Objects: OOAD
Data flow diagrams treat data and processing as two separate things. Object-oriented analysis and design, or O O A D, takes a genuinely different view. This section covers objects and classes, the four principles behind the approach, and the difference between object-oriented analysis and design. Then two practical techniques for finding classes, noun and verb analysis, and CRC cards. And finally, how the object-oriented approach compares with the structured one.
The Building Blocks
Objects and Classes
O O A D models a system around objects. An object is a self-contained unit that bundles together data, and the behavior that acts on that data. Rather than treating data and process as two separate things, it keeps them together. Every object is created from a class, which acts as its blueprint. The class defines what attributes, meaning data, and what methods, meaning behavior, every object of that type will have. A Student class might define the attributes name, student I D, and G P A. And methods such as enroll, and drop course. A specific student, Maria Lopez, is then an object, or instance, of the Student class. She is one particular realization of the blueprint, with her own actual name, I D, and G P A.
The 4 Pillars (1 of 2)
Encapsulation and Inheritance
Four related principles describe what makes the object-oriented approach work. The first is encapsulation. Encapsulation bundles an object's data with the methods that operate on it, and hides the data itself behind those methods. A bank account object keeps its balance private. Outside code cannot change the balance directly. Only through methods like deposit and withdraw. And those methods can enforce rules, such as refusing a withdrawal that would overdraw the account. The second principle is inheritance. Inheritance lets a new class be built on an existing one, automatically taking on its attributes and methods, while adding or overriding its own. Savings account and checking account can both inherit from a shared account class. They pick up its account number, balance, deposit, and withdraw, without redefining any of them.
The 4 Pillars (2 of 2)
Polymorphism and Abstraction
The third principle is polymorphism. Polymorphism allows objects of different classes to respond to the same method call, each in a way that suits its own class. Calling calculate interest behaves differently on a savings account than on a checking account. Yet the calling code asks for the same method, by the same name. The fourth principle is abstraction. Abstraction means focusing on the characteristics that matter to the system, while hiding unnecessary implementation detail. Code that calls account dot deposit, with one hundred, does not need to know how the balance is stored. It only needs to know that a deposit method exists, and what it does.
Figure 4.2
3 Pillars in One Class Diagram
This class diagram shows three of those principles at once. Each class is a box with three compartments. The class name, its attributes, and its methods. In account, the attributes are marked with a minus sign, meaning private. That is encapsulation. The methods are marked with a plus sign, meaning public. They are the only way in. The hollow triangles show inheritance. Savings account and checking account both inherit from account. And both subclasses list their own calculate interest method. Each overrides the parent's version with its own. That is polymorphism in action. So a single diagram shows encapsulation, inheritance, and polymorphism, working together.
2 Phases
OOA vs. OOD
Systems analysis and design are distinct phases in the structured approach. In the same way, object-oriented analysis and object-oriented design are distinct phases here. Object-oriented analysis, or O O A, asks what real-world objects and relationships the problem involves. It identifies candidate classes, attributes, and relationships from the requirements. Its classes are business-domain classes, like student, order, and account, and its audience is business stakeholders and users. Object-oriented design, or O O D, asks how those objects will actually be implemented. It adds technical classes the business side never sees, such as a database connector, or a login screen. And its audience is developers and technical staff.
Finding Classes
Noun/Verb Analysis
How do you find candidate classes in the first place? A common technique is noun and verb analysis. You read a requirements narrative, and pull out its nouns and its verbs. Nouns tend to point to candidate classes or attributes. Verbs tend to point to candidate methods. Take this sentence. A customer places an order for one or more products, and the system calculates the total price, and sends a confirmation email. Customer, order, and product are strong candidate classes. Each is a real entity, with its own data and behavior. Total price is a noun too, but it is likely just an attribute of order, not a class of its own. Confirmation email is a judgment call. It may be an attribute, or its own class if the system tracks email history. And the verbs, places, calculates, and sends, become candidate methods. Notice the lesson. Not every noun becomes a class. Judgment is still required.
Exploring a Class
CRC Cards
Once candidate classes are identified, a CRC card offers a quick way to explore each one. CRC stands for class, responsibility, and collaboration. Traditionally written on a physical index card, it lists the class name, its responsibilities, and its collaborators. Responsibilities are what the class knows, or does. Collaborators are the other classes it must work with. Here is a partial card for order. It knows which products are included, calculates the total price, and tracks the order's status. Placed, shipped, or delivered. Its collaborators are the customer who placed it, the products, for price and availability, and the payment gateway, to process the charge. Teams often fill these cards in together, walking through a user scenario step by step. As the discussion reveals a better fit, responsibilities move from one card to another.
2 Ways of Thinking
Structured vs. Object-Oriented
The object-oriented approach is a genuinely different way of thinking about a system than the structured approach. The structured approach keeps data and process separate. Its building blocks are separate processes and data stores, and any process can act on any data store. It uses data flow diagrams and entity-relationship diagrams. And it fits systems organized around a clear sequence of processing steps. The object-oriented approach bundles data and behavior inside objects from the start. An object's data can be reached only through its own methods. It uses class diagrams, use case diagrams, and sequence diagrams. And it fits systems that map naturally onto real-world entities, and their interactions.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. A class is the blueprint. An object is one instance of it, with its own values. Encapsulation hides an object's data behind the methods that act on it. Inheritance builds a class on a parent class. Polymorphism lets one method call behave differently in each class. Abstraction exposes what matters, and hides implementation detail. O O A finds the real-world classes. O O D adds what implementation needs. And a CRC card captures a class's name, responsibilities, and collaborators.
Key Takeaways
What to Carry Forward
To pull this together. An object bundles data and behavior together, and a class is the blueprint for its objects. Encapsulation, inheritance, polymorphism, and abstraction are the four core principles. O O A identifies real-world classes from requirements. O O D adds the technical classes needed to implement them. Noun and verb analysis surfaces candidate classes and methods, but still requires judgment. CRC cards explore a class before the design is formalized. And the structured approach separates data and process, while the object-oriented approach bundles them together.
About System Analysis and Design at UPI Study
System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take System Analysis and Design with UPI Study
Where the credit goes
Universities that work with NCCRS
System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Designing with Objects: The OOAD Approach
What is the difference between a class and an object in object-oriented design?
What are the four principles of object-oriented design?
What is the difference between object-oriented analysis and object-oriented design?
How do noun/verb analysis and CRC cards help find classes?
About the System Analysis and Design course
How many college credits is System Analysis and Design?
How much does System Analysis and Design cost and what is included?
Which universities accept UPI Study credits?
How long does System Analysis and Design take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in System Analysis and Design.
69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →