Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
114 Cards in this Set
- Front
- Back
|
Object Oriented Design
|
Designing the software for each of the classes identified in the analysis.
|
|
|
Analysis
|
Requirements, OO, and focuses on finding and describing the concepts in the problem domain
|
|
|
Design
|
A conceptual solution that fulfills the requriements, focuses on good design and collaboration
|
|
|
Domain Models
|
Shows the important concepts in a system and how they interact
|
|
|
Interaction Diagrams
|
Shows how the objects interact with each other over time
|
|
|
Class Diagrams
|
Enumerates the fields and methods within a class/object
|
|
|
UML
|
Universal Modeling Language - sketch, blue print, as a programming language
|
|
|
Agile Modeling
|
It is the use of light/quick
|
|
|
Unified Process
|
A structure to develop large software systems - Waterfall, XP, scrum
|
|
|
Waterfall method
|
Development Flows downward like a waterfall through the steps: Requirements analysis
Design, Implementation, Integration, Testing (validation), Installation, Maintenance |
|
|
Xtreme Programming
|
Has 5 core values: Communication, Simplicity, Feedback, Courage, Respect
|
|
|
Scrum
|
Characteristics: Living Backlog, sprints, scrum, brief planning, brief heartbeat
|
|
|
Phases of Development
|
Requirements, design, implementation, testing, maintenance
|
|
|
U.P. continued
|
Phases: Inception(understand the problem), elaboration(Refining the solution), construction(working on the not-as-hard-parts), Transition (beta testing) Coding in all 4
|
|
|
Design Patterns
|
Gang of Four - A reference for design patterns viewed as best practices for situations for problems that occur over and over again - creational, structural, and behavorial
|
|
|
Iterator Design Pattern
|
Access contents of a collection without exposing its internal structure, support multiple simultaneous traversals of a collection, provide a uniform interface for traversing different collection.
|
|
|
Inception
|
Envision the product scope, vision, and business case - Is this worth investing in? Is this worth it? Feasible? Rough Cost? Start creating artifacts
|
|
|
"Waterfall" Inception
|
It is short, not many requirements, loose plans, not too much detail just enough to make smart decisions
|
|
|
"Waterfall" Requirements
|
This is bad because it is hard or impossible to change design requirements and therefore the product is not what the user wanted.
|
|
|
Evolutionary Requirements
|
Can change as the needs do...some parts are:
Functional Usability Reliability Performance Supportability |
|
|
Use Cases
|
An english description of the user using the system. Talks about the possible flows of a specific task through the system is very high level. Involves actors.
|
|
|
Actors
|
A "thing" in the system that has a behavior in the system: Person, computer, organization. Types:
Primary actor Supporting actor Offstage actor |
|
|
Use Case Types
|
Brief: One paragraph summary that covers the optimal path
Casual: Multiparagraph that can cover multiple scenarios Fully Dressed: Highly Detailed things such as scope actors scenarios and other types of data necessary to fully explain the system. |
|
|
UML Use case
|
Has a central network where all of the actors plug into the network and shows generally how they change or interact with it. Black Box and use an actor or goal perspective.
|
|
|
Use Case: The Big Picture
|
Waterfall they are all defined up front (BAD)
UP: it is an iterative process and the ideas develop over time |
|
|
Vision
|
Introduction, positioning(business ideas), stakeholders, overview, features, other requirements
|
|
|
Supplementary Specification
|
Anything that helps describe limits of the system that are not included in the use case
|
|
|
Domain Business Rules
|
The rules that dictate how a Business may operate.
|
|
|
Observer Design Pattern
|
Solves the issue of how do we notify objects that a state of an object has changed. Subject->Observer The subject has a list of observers and notifies them of a state change.
|
|
|
Elaboration
|
The building of how risk and high value parts of a system - a use case is built in different iterations more important parts first - Define most of the other parts
|
|
|
"Waterfall" elaboration
|
only 1 iteration the program is done from start to finish
|
|
|
Artifacts during elaboration
|
Domain model, design model, Architect doc, data model, Use case storyboards
|
|
|
Plan the next Iteration
|
Consider risk and priority - high medium low and some complexities
|
|
|
Domain Model
|
A visual representation of real situation conceptual classes - not objects!! Conceptual Classes
|
|
|
Conceptual Classes
|
Reuse/modify existing models
Use a category list Identify noun phrases |
|
|
Mediator Class
|
A class that encapsulates the control of communication between various objects - Colleagues comminucate via the concrete mediators - Decouples classes and centralizes control
|
|
|
Overloading
|
Creating a bunch of the same functions but adding new parameters
|
|
|
Overriding
|
Over writing the function that is inherited giving it new functionality
|
|
|
Problems - Multiple Inheritance
|
Two functions with the same name from the two parents which one do we use. The ancestor is inherited twice does this become a problem
|
|
|
Virtual Method Tables
|
Defining a function as virtual allows a child to call a function that is defined twice and based on where it came from can look up the proper function
|
|
|
Normal Multiple Inheritance
|
No ancestor is repeated - no class is repeated in the hierarchy
|
|
|
Shared Multiple Inheritance
|
Multiple instances of the same class in the hierarchy
|
|
|
Mix-in Inheritance
|
Only the base class contains the implementation of the inherited functions all higher level classes are abstract function methods
|
|
|
Singleton Design Pattern
|
A design pattern that only allows one instantiation of a class - Provides a global point of access to the instantiation
|
|
|
System Sequence Diagram
|
Shows a particular scenario for a use case and the events that external actors generate, their order, and the possible inner system events
|
|
|
Operation Contracts
|
A set of pre and post conditions for an operation :
-Identify system operations from the SSD -Expand upon non-obvious system operations -Use the categories for the post-conditions |
|
|
Strategy Design Pattern
|
This design pattern allows for multiple strategies to solve a problem to be swapped in at runtime - using inheritance there is a composite and all specific strategies inherit from it and the composite parent dispatches the problem to the correct implementation
|
|
|
Single Responsibility Principle
|
A class should have only one reason to change - if something changes only one dependancy changes
|
|
|
Open-Closed Principle
|
Software entities should be open for extension but closed for modification - meaning that an extra class can expand on another but this addition should not need modification
|
|
|
Interface Segregation Principle
|
Clients should not depend upon methods that they do not use -
|
|
|
Liskov Substitution Principle
|
Subtypes must be substitutable for their base types - any subclass should have the proper fields and methods to be subbed into a class that any of its siblings can
|
|
|
Dependancy Inversion Principle
|
High level modules should not depend on low level modules - abstract the middle phases to help lower the coupling
|
|
|
Facade Design Pattern
|
This design encapsulates a complex subsystem into a single object - compiler: has many steps but user only interacts with a subset of functions, hides how complicated it is
|
|
|
Packages
|
Groups of classes and libraries that are grouped together by their relation to each other - UI packages in java
|
|
|
Layers
|
**Not a great Definition** Layers are an abstract idea of breaking the different parts of a system into abstract "layers" where similar levels of the system are "grouped" together ie the layers of a network system
|
|
|
Partitions
|
The different sub sections of a layer - UI layer - buttons, toolbars ...
|
|
|
Memento Design Pattern
|
This design solves the problem of how do we store the states of objects and allow the object to return to a that or another previous state - undo function
|
|
|
State Design Pattern
|
Change the behavior of an object when its state changes - Uses inheirtance and a state handler to dispatch to a concrete means of solving based on the state
|
|
|
GRASP
|
General Responsibility Assignment Software Patterns
|
|
|
Creator
|
Assign class B the responsibility to create an a if one or more are true:
B contains A B records A B closely uses A B has the initialization data for A |
|
|
Information Expert
|
Assign a responsibility to the class that has the information needed to fulfill it
|
|
|
Low Coupling
|
Assgin responsibilities so that coupling remains low. Use this principle to evaluate alternatives.
|
|
|
Controller
|
Assign the responsibilities to an object representing one of these choices:
Represents the overall system Represents a use case scenario within which the system operation occurs |
|
|
High Cohesion
|
Assign Responsibilities so that cohesion remains high.
|
|
|
Polymorphism
|
When related alternatives or behaviors vary by type (class), assign responsibilities for the behavior using polymorphic operations to the types for which the behavior varies
|
|
|
Pure Fabrication
|
Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept – something made up, to support high cohesion, low coupling, and reuse (an abstract idea such as a cup where the die are rolled from)
|
|
|
Indirection
|
Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled
|
|
|
Protected Variations
|
Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them
|
|
|
Adapter Design Pattern
|
A design pattern that adapts the inteface of one class into something that the client expects
|
|
|
Code Smells
|
A process of going through code and finding bad design conventions these are called smells
|
|
|
Duplicated Code
|
Code is duplicated throughout the program - Template methods or use inheritance
|
|
|
Long Method
|
Long methods are hard to understand and hard to debug and modify. Small methods have very little overhead - break the method up into different parts
|
|
|
Long Class
|
If a class does too much, code is duplicated, and it becomes hard to modify - extract smaller parts and create smaller classes
|
|
|
Long Parameter List
|
Too many parameters are hard to understand - replace the parameters with a method call
|
|
|
Divergent Change
|
A class should not be changed in different ways for different reasons - extract class
|
|
|
Shotgun Surgery
|
A single change should not affect a large number of classes - inheritance move the method/field
|
|
|
Feature Envy
|
A class should not be more interested in another class
|
|
|
Data Clumps
|
Data, like children, tend to cluster in clumps - extract the class
|
|
|
Primitive obsession
|
Should use objects instead of Multiple Primitives - wrap some of the data into classes
|
|
|
Switch Statements
|
If you have many switch statements in your code on the same datum, it becomes hard to modify
|
|
|
Parallel inheritance Hierarchies
|
All subclasses inherit from two different super classes but they are not linked - combine the super classes
|
|
|
Lazy Class
|
A class can be too small, especially after refactorings
|
|
|
Speculative Generality
|
If you have a lot of abstract classes or methods that arent doing much they can just get in the way
|
|
|
Temporary Field
|
Some variables are only valid in some situations, and shouldn’t be in the class itself - extract these fields into a class or use null creator
|
|
|
Message Chains
|
A long line of delegation is a message chain - .fooa().foob().fooc() ...
|
|
|
Middle Man
|
If half of your code is adapters, then something is wrong - remove these middle men cause they serve no encapsulation purpose
|
|
|
Inappropriate Intimacy
|
If classes are too friendly with each other, then encapsulation breaks down - since they can all see each other then why not put them together and encapsulate their data
|
|
|
Alternative Classes with different Interfaces
|
If two classes are alternatives then they should have the same interface extract move w/e
|
|
|
Incomplete Library Class
|
A library or server class is incomplete or perhaps is buggy - introduce a local foreign method
|
|
|
Data Class
|
Class that has no functionality only fields - there is no encapsulation hide data or store it elsewhere
|
|
|
Refused Bequest
|
The subclass doesnt need one of the inherited methods
|
|
|
Comments
|
Too much commenting and too little code defeats the purpose of coding
|
|
|
Bridge Design Pattern
|
A design with the intent of decoupling an abstraction from its implementation so that the two can vary independently - An abstract class inherits from another abstract so that an implementation can have all attributes plus extras
|
|
|
Test Driven Development
|
Write all the tests first and then write code that will pass said tests - allows the coder to have a solid test base for later addons and changes
|
|
|
Refactoring
|
A structured method to rewrite or restructure code without changing its external behavior, applying small transformation steps combined with re-executing test each step
|
|
|
Explaining Variable Refactoring
|
Using good variable names that are easy to understand and can lead a programmer to see the logic of the code
|
|
|
Extracting Method
|
Take a section of code that is related and extract it from one method and encapsulate it in another method
|
|
|
Encapsulate Field
|
Turn a public field private and use getters and setters to modify and access them
|
|
|
Extract Interface
|
When several clients use the same subset of a class’s interface, or two classes have part of their interfaces in common extract an interface that they can use together
|
|
|
Inline a method
|
Take a method and dissolve it and take that code and put it where that method is called - no need to encapsulate if it is used only once
|
|
|
Introduce Parameter Object
|
When you have a group of parameters that go naturally together package them up in another data field
|
|
|
Pull Up Field
|
When two classes have the same field pull it up the hierarchy tree
|
|
|
Push Down Field
|
If there is a field that is unneeded by a child then push the field out of the parent and into the child
|
|
|
Remove Parameter
|
When a parameter is no longer used by the method body remove it
|
|
|
Remove Setting Method
|
When a field can be created and then is never altered the setter can be removed
|
|
|
Rename Method
|
When the name of the method does not reveal its purpose
|
|
|
Chain of Responsability Design Pattern
|
This design pattern allows multiple recievers to handle a request from a sender without coupling the sender with all the handlers - Message is passed down the line and accepted byt the most specific handler if possible else held by very general
|
|
|
Proxy Design Pattern
|
A design pattern that encapsulates a surrogate or a place holder for antoher object to control access to it - like windows has a blank picture during load and runtime then it loads when the picture is needed
|
|
|
Agile Manifesto
|
A group of industry experts got together and made the agile alliance and devised a new means of developing that is more efficient
|
|
|
Manifesto - Points
|
Individuals and interactions over processes and tools
Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following plan |
|
|
XP
|
Customer Team Member
User Stories Short Cycles Acceptance Tests Pair Programming Test Driven Development Collective Ownership Continuous Integration Sustainable Pace Open Workspace Simple Design Refactoring |
|
|
Scrum
|
Has short sprints that take a small set of features and develops them to the end essentially releasing a fully working bug free small version of the software after every sprint - Daily meetings
|
|
|
Back Log
|
List of tasks to be completed in the project
|
|
|
Clean Room
|
Team based development and existing organizational practices
|
