Slides presented at MCJUG concerning OOAD.

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