accustomed – used to
Whoever is guarding me should get accustomed to being humiliated when I decide to score a basket.

gloats – not displaying good sportsmanship
I admit, Tim Tebow was a great college football player, but it seemed as though he gloated every time he would fire-up and motivate his team.

whine – constantly complaining
Rasheed Wallace is known as a whiner because he keeps complaining that he never commits a foul.

veteran – someone who is experienced
Juwan Howard is a basketball veteran who appears not to retire anytime soon.

soar - fly high
My kids love riding in planes and soaring across the pacific ocean.

vengeance - to give a hurt for a hurt
My vengeance towards the opposition is justified because they intervened in family matters they had no business in.

descend - go down or come down or fall
While approaching our destination, the plane started to slowly descend.

clench - grip or hold very tightly
When riding a motorcycle at speeds exceeding the speed limit, it’s a good idea to clench the handle bars.

adorn – to decorate
My girlfriend’s dress was adorned with glitzy and sparkling sequins.

former – previous or first
My former employer disappointed me because there was no trust in our employee-company relationship.

abates – subsides or stops
Before walking up the hill to my car, I must wait till the pouring rain abates.

enthrall – to captivate
Growing up in the eighties, I remember vividly watching the lakers/celtics rivalry intensify in the playoffs. The one play that enthralled me to excel in basketball, was Magic Johnson’s game winning hook shot in the waning moments of game six of the NBA finals.

ponder – to weigh
In a year from now, I need to ponder my career options: either remain at my current job or attempt to follow my dream job.

endure – to keep going
It’s only been a month, but I must endure the rigors of eating a healthy diet and exercising to achieve my ultimate goal of losing twenty pounds.

elicit – bring forth or draw out
The crime investigators had difficulty eliciting a confession from the alleged murder suspect.

sheer – complete, or very thin or transparent.
I was in sheer glee when Louisville upset number one ranked Syracuse in college basketball.

ardent – passionate
I’m starting to be more ardent about programming in .net and working with Microsoft technologies in general.

scrutinize – examining
When a bug is discovered in an application, I meticulously scrutinize the code that generated the error.

regale – to delight or entertain
I hate it when Jayne invites her girlfriend’s boyfriends over because I then have to regale them.

procure – obtain
To procure a license in Hawaii, you’d have to be at least eighteen years of age and have 20/20 vision.

1 thru 5 – Make sure your software does what the customer wants it to do.
6 thru 7.5 – Apply basic OO principles to add flexibility.
7.5 thru End – Strive for a maintainable reusable design.

Steps in Lifecycle
1. Develop feature list from statement of work.
! Your feature lists are all about understanding what your software is supposed to do.
! Your use case diagrams let you start thinking about how your software will be used, without getting into a bunch of unnecessary details.

2. Develop use case diagram – make sure use cases covered all features.
! Use cases reflect usage, features reflect functionality. Your system must do those features, in order for the uses cases to work.
! The features in your system  are what the system does, and are not always reflected in your use cases, which show how the system is used.
! Features & use cases work together, but they are not the same thing.

3. Break up into different modules

4. Take each use-case and turn it to a set of requirements we can tackle.
! If you get stuck at a use-case, take a step back and fully understand the problem.

5. Textual analysis – Figure out nouns (classes) and verbs (methods or operations) from text analysis of use case.

6. Preliminary design – using candidate nouns and verbs, draw class diagram (UML).
! Your design decisions should be based on how your system will be used, as well as good OO principles.

7. Implementation – write code.
! You should only expose clients of your code to the classes that they need to interact with. Classes that clients don’t interact with can be changed with minimal client code being affected.
! Test your iteration.
!  Move on to next iteration.

4. Requirements – write use case.
! It’s your job to balance making sure the customer gets the functionality they want with making sure your code stays flexible and well-designed.

5. Textual analysis – nouns & verbs.

6. Preliminary design – class diagram.

7. Implementation
! Sometimes the best code for a particular problem has already been written. Don’t get hung up on writing code yourself if someone already has a working solution.

OOA&D is about having lots of options. There is never one right way to solve a problem, so the more options you have, the better chance you’ll find a good solution to every problem.

Two Choices
1. Feature Driven Development
- when you pick a specific feature in your application (plan, analyze, and develop that feature to completion).
- granular (small)
- show working code faster

2. Use Case Driven
- pick a scenario through a use case, and write code to support that complete scenario through the use case.
- big picture
- complete process

Both approaches to iterating are driven by good requirements. Because requirements come from customer, both approaches focus on delivering what customer wants.

Analysis of feature leads to new features and design.

! Test software for every possible usage you can think of. Be creative! Don’t forget to test for incorrect usage too.  You’ll catch errors early, and make your customers very happy.

! Test driven development focuses on getting the behavior of your classes right.

! Good software is built iteratively. Analyze, design, and then iterate again, working on smaller and smaller parts of your application.

! Each time you iterate, reevaluate your design decisions and don’t be afraid to change something if it makes sense for your design.

Test Cases
1. Should have an ID and a name
2. Test one specific thing
3. Should have input you supply
4. Should have output you expect
5. Have starting state

Programming by Contract – working with client code to agree on how you’ll handle problem situations.
Programming Defensively – making sure client gets a “safe” response, no matter what client wants to have happen.

Tools
Programming Practices
1. Programming by Contract sets up an agreement about how your software behaves that you and users of your software agree to abide by.
2. Defensive Programming doesn’t trust other software, and does extensive, error, and data checking to ensure the other software doesn’t give you a bad or unsafe information.

Development Approaches
1. Use Case driven development takes a simple use case in your system, & focuses on completing the code to implement that entire use case, including all of its scenarios, before moving on to anything else in the application.
2. Feature driven development focuses on a single feature, & codes all the behavior of that feature, before moving on to anything else in application.
3. Test driven development writes test scenarios for a piece of functionality before writing the code for that functionality.  Then you write software to pass all the tests.

4. Good software development usually incorporates all of these development models at different stages of the development cycle.

Solution:
Loaded the Windows XP CD on startup and repaired the Windows XP installation on the laptop’s local drive.  Laptop was infected with multiple severe viruses.  Installed Microsoft Security Essentials and Malwarebytes and multi-scanned all drives to remove the pesky viruses.  Reapplied Microsoft Windows XP service packs and security patches.  Uninstalled expired and non-essential programs from laptop.

Viruses Removed:
1. Exloit:HTML/Repl.D
2. Trojan:Win32/Alureon.CO
3. TrojanDownloader:ASX/Wimad.AT
4. Trojan:Win32/FakeSpypro
5. Trojan:Win32/Meredrop

! Using proven OO design principles results in maintainable, flexible, & extensible software.

1. Open Closed Principle (OCP)
- Classes should be open for extension & closed for modification.

2. Don’t Repeat Yourself (DRY)
- Avoid duplicate code by abstracting out things that are common & placing those things in a single location.
- it’s about having each piece of information & behavior in your system in a single sensible place.

3. Single Responsibility Principle (SRP)
- Every object in your system should have a single responsibility & all the object’s services should be focused on carrying out that single responsibility.
- also know as cohesion.

4. Liskov Substitution Principle (LSP)
- subtypes must be substitutable for their base types.
- the LSP is all about well designed inheritance. When you inherit from base class, you must be able to substitute your subclass for that base class without things going wrong. Otherwise you’ve used inheritance incorrectly.

Options Besides Inheritance
1. Delegation - is when you hand over the responsibility for a particular task to another class or method. If you need to use functionality in another class, but don’t want to change that functionality, consider using delegation instead of inheritance.

2. Composition - allows you to use behavior from a family of other classes, and to change that behavior at runtime. Use composition to assemble behaviors from other classes. The object composed of other behaviors owns those behavior. When object is destroyed, so are all of its behaviors.

3. Aggregation - when class is used as part of another class, but still exists outside of that other class.

! If you favor delegation, composition, & aggregation over inheritance, your software will usually be more flexible, & easier to maintain, extend, & reuse.

Solution:
Dell documentation suggests diagnostic results indicate memory not detected. Opened computer and reseated memory firmly to the motherboard. Air dusted the interior to promote air flow and reduce heating.