Moe's Tech Blog
[OO Design Foundation] Object Oriented Modeling 본문
Object Oriented Modeling
- involves the practice of representing key concepts through objects in software
Why Object Oriented Modeling
- keeps the code organized, flexible, and reusable.
Design in the Software Process
1. Expressing Requirements with User Stories
- Is a big part of building a software system determining what the client wants
- One of the technique for expressing requirement is user stories
Example
- From example above, note that
- Noun corresponds to object in software
- Verb helps to identify the requirements the object might have
- Also helps to identify connection between objects
2. Organizing to Categories of Objects in Design
- When breaking down an object, there are three categories of objects to consider
- 1. Entity Objects
- are most familiar.
- It corresponds to real world objects
- Example
- 1. Chair
- When you are identifying objects to include and breaking down into smaller objects, you will initially get entity objects
- are most familiar.
- 2. Boundary Objects
- Are objects that sit at the boundary of systems
- Could be an object that deals with another software system
- Example
- 1. An object that obtains information from the internet
- 2. An object that shows information to user and getting their input
- Any object that deals with another system - a user, another system, the internet - can be considered a boundary object
- Are objects that sit at the boundary of systems
- 3. Control Objects
- Are objects responsible for coordination
- Controls other objects
- Example
- 1. Mediator
- Coordinates the acitivity of many different objects so they can stay loosely coupled.
- 1. Mediator
- 1. Entity Objects
- Organizing software into entity objects, boundary objects, and control objects will allow code to be more flexible, reusable, and maintainable
Design for Quality Attributes
1. Competing Qualities and Trade-Offs
- Some software designs will involve trade-offs such as
- a. Performance
- b. Convenience
- c. Securituy
- Context is important to determine what choice of solution is right for the balance of qualities.
- Example
- 1. A home located in low crime area will need different security needs than one located in a high crime area
- For softwares, talking to stakeholders helps to understand the context
- Example
- Various qualities that influence software design
- 1. Functional Requirements describe what the system or application is expected to do
- Example
- 1. A media app has a functional requirement of being able to download a full length movie
- Example
- 2. Non-function requirements specifies how well the system or application does what it does
- Describes how the software runs in a particular situation
- Example
- 1. A media app has a non-functional requirement to download a full length movie at specific speed and to play such a movie with a certain memory limit
- There are other types to satisfy than correctness including
- 1. resource usage
- 2. efficiency
- 3. performance
- 4. reusability
- 5. flexibility
- 6. maintainability.
- The desired qualities from Functional and non-functional requirements puts contstraints on system's design.
- 1. Functional Requirements describe what the system or application is expected to do
Class Responsibility Collaborator
- Is a tool to mapout structure of the software logically when forming it's design
- completes conceptual design
- Records, organizes and refines components in your design
- Identifies components, connections and responsibilities when forming conceptual design
- conceptual design is where you give your thoughts on how you might satisfy requirements
- technical design is where how these components and connections are further refined to give them technical details
- is kept small on purpose
- Forces class to be small enough to be individually described on index cards
- has three sections
- 1. class name
- 2. responsibilties
- 3. collaborators
- are other classes that the class interacts with to fulfill its responsibilities
Example: Designing Bank Machine System
From Problems to Solutions with Design
1. Competing Qualities and Trade-Offs
- Top-down programming : maps the process in the problem to the routines to be called
- Requires a tree of routines for the eventual solution
- These routines are implemented in a programming language that supports subroutines (functions, methods)
- Goal of software design is to construct and refine models of all the objects.
- Focuses identifying entity objects from problem space initially
- Introduces control objects that receive events and coordinate actions as solution in software arises
- Also introduces boundary objects that connects to services outside of the system
- Models are often expressed using Unified Modeling Language or UML
- Models serve as a design documentation for software and can be easily mapped to skeletal source code
Four Design Principles
1. Abstraction
- Is the idea of simplifying a concept in the problem domain to its essentials within some contenxt
- Allows you to better understand a concept by breaking it down into a simplified description that ignores unimportant details
- Example
- 1. Food
- In health context, it's nutritional value and not it's cost would be part of a simplified description of food
- 1. Food
- Good abstraction
- 1. Emphasizes the essentials needed for concept and removes details that are not essential
- 2. Makes sense for the concept's purpose
- 3. Applies rule of least astonishment.
- means "abstraction captures the essential attributes and behavior for a concept with no surprises and no definitions that fall behind the scope."
- Example
- 1. A Person
- In context of building a driving app, you would care about the person in context of a driver.
- In context of building a restaurant app, you would care about the person in the context of a patron
- 2. A Student
- In context of academic setting, some essential characteristics are:
- a. The course they are currently taking
- b. Their grades in each course
- c. Their student ID number
- In context of academic setting, some essential characteristics are:
- 3. A Household Cat
- In context of cat owner, a house cat will have attributes like
- a. name
- b. color
- c. favourite nap location
- d. microcip number
- In context of cat owner, a house cat will have attributes like
- 1. A Person
- 4. Describes a concept's basic behaviors
- Example
- 1. A household cat has following basic behaviors
- a. napping
- b. grooming
- c. catching mice in the house
- d. eating
- e. using litter box
- 2. A household dog has following basic behaviors and attributes
- Behaviors: grooming, playing with toys, eating, napping, barking, using litter box
- Attributes: name, microchip number, weight, favourite nap location, favourite food, favourite toy
- 1. A household cat has following basic behaviors
- Example
- Context is critical in forming an abstraction
- If the purpose of the system or problem changes, don't be afraid to update abstraction accordingly.
2. Encapsulation
- Forms a self-contained object by undling the data and functions it requires to work, exposes an interface whereby other objects can access and use it, and restricts access to certain inside details
- Involves three ideas:
- It's about making a sort of capsule.
- Some can be accessed from outside, and some of which cannot
- 1. Bundle attribute values or data, and behaviors or functions that manipulate those values together into a self-contained object
- 2. Expose certain data and functions of that objects, which can be accessed from other objects.
- 3. Restrict sccess to certain data and functions to only within that project
- It's about making a sort of capsule.
- Defines behaviors through class methods
- Cam expose certain attributes and methods to be accessible to objects in other classes
- Why Encapsulation?
- 1. Can secure sensitive information
- Example
- 1. A student with a value of degree program and GPA
- Student class can support queries involving GPA, without revealing actual values of GPA (i.e. whether sstudent is in a good standing or not)
- 1. A student with a value of degree program and GPA
- Example
- 2. Helps with software changes
- The accessible interface of a class can remain the same, while the implementation of the attributes and methods can change
- Outside of interface, use using the class not need to know how implementation actually works.
- Outside of class, the actual steps of retrieving an attribute need not to be known (blackbox thinking)
- The accessible interface of a class can remain the same, while the implementation of the attributes and methods can change
- 3. Achieves abstraction barrier
- Reduces complexity for the user of a class
- Increases re-usability because another class only needs to know the right method to call the desiredc behavior, what arguments to supply as inputs and what appears as outputs or effects
- 1. Can secure sensitive information
- Encapsulation is a key design principle in achieving a well-written program.
- It helps to keep your software modular and easier to work with
- Keeps classes easy to manage, whjose behaviors are accessed like black boxes
3. Decomposition
- Is about taking the whole thing and dividing it up into different parts
- Or, on the flip side, it's about taking a bunch of separate parts and combining them together to form a whole
- Allows to further breakdown problems into pieces that are easier to understand and solve
- Example
- 1. Refridgerator
- by breaking it down into different parts using decomposition, you can keep the different responsibilities separate
- 1. Refridgerator
- has a general rule of thumb:
- 1. Look at the different responsibilities of some whole thing and evaluate how you can separate them into different parts with it's own specific responsibility
- Each part has a very specific purpose to help achieve the responsibilities of the whole
- Example
- 1. A car
- This can be decomposed into: Wheels, a steering wheel, a windsheld, a gas pedal, engine (and more)
- 2. A refridgerator
- This can be decomposed into: cabinet, doors, compressor, coils, freezer, ice-maker, shelves, drawers, and food if inside refridgerator
- 1. A car
- 1. Look at the different responsibilities of some whole thing and evaluate how you can separate them into different parts with it's own specific responsibility
- How parts interact within the whole:
-
- 1. Fixed / Dynamic
- A whole might have a fixed or dynamic number of certain type of part
- Fixed --> it will have exactly that number of elements during the lifetime of the whole object
- Count does change over time
- Can be determined by process of elimination
- Dynamic --> the number of objects vary during the lifetime of the whole object
- Example
- 1. Regridgerator is fixed (there is only 1 throughout lifetime)
- 2. Food in refridgerator are dynamic (part count changes over time)
- Example
- Fixed --> it will have exactly that number of elements during the lifetime of the whole object
- A whole might have a fixed or dynamic number of certain type of part
- 2. A part containing parts
- A part can contain another part
- Example
- 1. A headlamp that contains bulb
- 2. A wheel containing tire
- Example
- A part can contain another part
- 1. Fixed / Dynamic
-
- 2. Lifetime
- is about how the whole object and the part object relate
- Example
- 1. Refridgerator and freezer of one machine
- have the same lifetime
- One cannot exist without the other
- 2. Car and engine
- Closely related lifetime
- 1. Refridgerator and freezer of one machine
- Example
- of whole object and it's parts doesn't have to be relaterd
- Example
- 1. Car and headlamp
- Car exists throughout lifetime, headlamp doesn't
- 2. Refridgerator and food items
- each have different lifetime
- 1. Car and headlamp
- Example
- is about how the whole object and the part object relate
- 3. Sharing
- is about whole things contain parts that are shared among them at the same time
- Example
- 1. Daughter in one family and spouse in another family
- Two families are separate wholes, but they share the same part
- 1. Daughter in one family and spouse in another family
- Example
- is about whole things contain parts that are shared among them at the same time
- 2. Lifetime
-
- Decomposition helps to breakdown a problem into smaller pieces
4. Generalization
- Helps to reduce amount of redundancy when solving problems
- Is used frequently when designing algorithms which are meant to be used to perform same action on different sets of data
- Can be achieved by classes through inheritance
- Takes repeated, common, or shared characteristics between two or more classes (child classes) and factor them into another class (parent class)
- Parent class is also called superclass
- Child class is also called subclass
- Example
- 1. Cat and Dog
- They are both of type animal with tail and 4 legs
- They both have shared set of behaviors like walking, running and eating
- 1. Cat and Dog
Expressing Design Structure in JAVA & UML Class Diagrams
1. Abstraction in Java and UML
- You could certainly use CRC card to convert to code but there are too many ambiguities that prevent a programmer from translating CRC card to code.
- Properties in class diagram turns into member variables and operations into methods
2. Encapsulation in Java and UML
- '-' represents private attribte / method
- can only be accessed inside the class
- '+' represents public attribute / method
- Example
- 1. Modeling university student
- Getter method are methods that retrieves data and their names
- Typically begins with get and end with the name of attribute whose value you will be returning
- Often retrieves private piece of data
- Setter method changes data
- Typically begins with set and end with the name of the variables you wish to set
- Are used to set a private attribute in a safe way
3. Decomposition in Java and UML
- has three types of relationships defining interaction between whole and the parts
- 1. Association
- is a very loose interaction between two completely independent objects
- is "some" relationship
- means there is a loose relationship between two objects
- its objects may interact with each other for some time
- if one object is destroyed, the other can continue to exist
- there can be any number of items in the relationship
- one object does not belong to another
- Example
- 1. A Person and An Airline
- 0..* means
- a. an airline is associated to 0 or more person objects
- b. a person is associated to 0 or more airline objects
- 0..* means
- 2. Kitten and Yarn
- 3. Food and Wine
- 4. Student and Sport
- 5. NOT Human and Organ
- 1. A Person and An Airline
- 2. Aggregation
- is where one whole has a part but both can live independently
- is a "has-a" relationship where a whole has parts that belong to it.
- this "has-a" relationship is considered weak.
- Means, although they belong to the whole, they can also exist independently
- this "has-a" relationship is considered weak.
- may have sharing of parts among the whole in this relationship
- Example
- 1. Airplane and it's crew
- 1. Airplane and it's crew
- 3. Composition
- Is the most dependent of the decomposition relationships
- is where whole cannot exist without its parts and vice versa
- Is an exclusive containment of parts, otherwise known as strong "has-a" relationship
- Means that the whole cannot exist without parts
- if it loses any of its parts the whole cease to exist
- If the whole is destroyed, all of its parts are destroyed
- usually, you can access the parts through the whole
- Example
- 1. House and Room
- 1. House and Room
- 1. Association
4. Generalization in Java and UML
- Showing inheritance is done by connecting two classes with a solid lined arrow
- Superclass is at the head of the arrow
- Subclass is at the tail of the arrow
- Note that
- Superclass is always at the top and subclasses are always at the bottom like a family tree
- Hash symbols means that a variable / method is protected
- In JAVA, a protected attribute / method means can only be accessed by
- 1. The encapsulating class itself
- 2. All subclasses
- 3. All classes within the same package
- Abstract keyword in a class declares that it cannot be instantiated
- Class either has an implicit or explicit constructor
- 1. Implicit constructor
- Does not have its own constructor
- Does not have its own constructor
- 2. Explicit constructor
- Its subclass constructor must call it's superclass constructor
- Its subclass constructor must call it's superclass constructor
- 1. Implicit constructor
- Method in subclass can override it's superclass
- Inheritance is declared in JAVA using keyword extends
- JAVA only allows single implementation inheritance
- A subclass can only be inherited from one superclass
- In JAVA, a protected attribute / method means can only be accessed by
5. Generalization with Interfaces in Java and UML
- An interface
- only declares method signatures, and no constructors, attributes, and method bodies
- it never implements or describes how these behaviors are performed
- it does not encapsulate any attribute of the animal
- specifies the expected behaviors in the method signatures, but does not provide any implementation details
- is also used for subtyping in JAVA
- is used to provide a way for related classes to work consistently
- is indicated by the keyword 'interface' is used in JAVA
- Standard JAVA naming convention places letter "I" before an acutal name to indicate an interface
- Example
- 1. Animal
- 1. Animal
- is implemented in JAVA using the keyword 'implements'
- Example
- 1. Dog and animal interface
- 1. Dog and animal interface
- Example
- is drawn in the similar way classes are drawn in UML
- is noted in UML class diagrams using guilemets, or french quotes
- is implemented in class and interface in UML using a dotted arrow
- Class touches the tail of the arrow and the interface touches the head of the arrow
- Example
- 1. Animal and dog
- 1. Animal and dog
- Class touches the tail of the arrow and the interface touches the head of the arrow
- are a mean in which you can implement polymorphism
- polymorphism is when two classes have the same description of a behavior, but the implementation of the behavior may be different
- Example
- 1. Cat and a dog
- They both speak, but cat meows and dog barks
- They both speak, but cat meows and dog barks
- 1. Cat and a dog
- Can inherit from other interfaces
- interface inheritance should not be abused
- If you are trying to create a larger interface, interface A should only inherit from interface B if the behaviors in interface A can fully be used as a subtitution for interface B
- Example
- 1. Vehicle movement on water and under water
- Vehicle movement on water is restriceted to 2D (x-axis, and y-axis)
- Vehicle movement under water requires movement in z-direction
- we do not want to add extra behaviors to vehicle movement on 2D
- So, a second interface that inherits from the first is created
- 1. Vehicle movement on water and under water
- interface inheritance should not be abused
- Does not run into issues with multiple inheritance
- Multiple inheritance is where a child class has two or more super classes
- Multiple inheritance of class is not allowed in JAVA
- Multiple inheritance of interface is allowed in JAVA
- Example
- only declares method signatures, and no constructors, attributes, and method bodies
References
- Object-Oriented Design, University of Alberta: https://www.coursera.org/learn/object-oriented-design