The document discusses Object-Oriented Analysis and Design (OOAD). It summarizes several chapters from a book on OOAD, including complexity in software, the object model, classes and objects, classification, UML notation, development processes, and pragmatics. The author provides their opinion of the book, noting it has some good information but is difficult to read in places. Overall, the discussion emphasizes that design requires balancing trade-offs and making informed choices based on each project's overall criteria.

1. B Y : I S A A C C A R T E R
Object-Oriented Analysis and
Design

2. WHAT HAVE I BEEN UP TOO?
• Started a Raspberry Pi Meetup for DC
• Currently working on a location
• Work at 5AM never ends
• Started up a book club here at 5AM
• Beginning to do development on Linux Mint
• You will learn a ton when you work on an open source
project
• I been doing some podcasting

3. DIFFERENT KIND OF JUG
• Not much code at all
• Going to be asking you guys a lot of questions.
• There is no right or wrong answer
• Provides us a chance to learn from each other.
• Which is why we are here

4. DESIGN PATTERNS AND ME
• I’ve reached that point where I think more about
the design of the project
• Many books written about OO programming and
design
• We are going to cover one tonight

5. Source of the talk
• Object-Oriented Analysis and Design With
Applications (3rd Edition)

6. HOW THE BOOK IS BROKEN DOWN
• Section 1 - Concepts
• Chapter 1: Complexity
• Chapter 2: The Object Model
• Chapter 3: Classes and Objects
• Chapter 4: Classification
• Section 2 - Method
• Chapter 5: Notation
• Chapter 6: Process
• Chapter 7: Pragmatics
• Section 3 - Applications
• Chapter 8 – 12

7. QUESTION?
• When you think about OOAD, what are some things
that come to mind?

8. Chapter 1: Complexity
• Software is inherently complex
• The complexity of software often exceeds the brain’s
capacity
• Our job as a software engineer is to create the
illusion of simplicity
• Complex systems can be viewed by focusing on
either things or processes

9. QUESTION?
• What does good code look like?
• I can tell you what bad code is in small chunks, but
as an entire project as a whole or a system….how
can you tell what’s good and what’s bad?

10. CHAPTER 2: THE OBJECT MODEL
• Encompasses the principles of OO programming
• Encapsulation, Abstraction, Modularity, Hierarchy, Typing,
Concurrency, and Persistence
• Modularity is the property of a system that has
decomposed into a set of cohesive and loosely
coupled modules
• Typing is the enforcement of the class of an object

11. QUESTION?
• Are getters/setters evil?

12. THINK ABOUT THIS…
Dog dog = new Dog();
Ball ball = dog.getBall();
V/S
Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

13. CHAPTER 3: CLASSES AND OBJECTS
• What is and What isn’t an object?
• Relationships are important among classes
• Multiplicity
• One-to-one, Many-to-many
• Inheritance
• Multiple Inheritance
• Role of Classes and Objects in Analysis and Design
• Identify the classes that form the vocab of the domain
• Create the structures for sets of objects to work together to
satisfy the requirements of the problem

14. QUESTION?
• Should every class have an interface?

15. CHAPTER 4: CLASSIFICATION
• How a class or object is named a fundamental issue
in OOAD
• This is how we discover what an object can do

16. QUESTION
• What’s some of issues that we run into when naming
an object or method?
• I constantly run into “writer’s block” when naming
something, how can I get around that problem?

17. CHAPTER 5: NOTATION
• UML Diagrams
• Broken down into two sections
• Structure Diagrams
• Behavior Diagrams
• Can also include Interaction Diagrams
• Many kinds of diagrams
• I have used…
• Package Diagram
• Use Case Diagram
• Sequence Diagram
• Activity Diagram
• Used them to help create a SAD for a project

18. QUESTION?
• Does anyone use UML diagrams in their daily work?
• Does anyone feel that UML diagrams are pointless?

19. CHAPTER 6: PROCESS
• Talked about how to create a solid development
process
• We have steps in place here at 5AM.
• Prior to development
• During development
• Post-development

20. CHAPTER 7: PRAGMATICS
• Planning
• We live and breath Scrum here at 5AM
• Tools
• Jenkins helps us create solid OO code

21. QUESTION
• What are some of the benefits of OO
development?
• What are some of the risks of OO development?

22. CHAPTERS 8 -12
• Each chapter sets the stage for a different scenario
and walks through the first 7 chapters on how to
implement each chapter
• Satellite-based Navigation system
• Traffic management system
• AI / Cryptanalysis system
• Weather monitoring station
• Vacation tracking system

23. IMHO OF THE BOOK
• Not really the best book over OOAD
• Five chapters dedicated to applying it, which made
them extremely hard to read
• Two chapters covering applying agile to OO
thinking
• I would still recommend reading it since there’s
nothing wrong with gaining more knowledge

24. SUMMARY
• Design, by nature, is a series of trade-offs
• Every choice has a good side and a bad side
• Make “informed” OO choices by the context of the
overall criteria, not because “of blind
programming”

25. SOURCES
• http://www.javaworld.com/article/2073723/core-
java/why-getter-and-setter-methods-are-
evil.html?page=2
• http://blog.shaunfinglas.co.uk/2015/04/getters-and-
setters-are-evil-redux.html
• http://www.amazon.com/Object-Oriented-
Analysis-Design-Applications-
3rd/dp/020189551X/ref=sr_1_2?s=books&ie=UTF8&qi
d=1434425605&sr=1-
2&keywords=object+oriented+analysis+and+design