Skills List for Designers/Developers

This detailed skills list was developed by members of the Object Oriented Specialty Track. The skills
list is intended to be used in evaluating courses as candidates for inclusion in the Object Oriented Specialty
Track, a special curriculum under development for Lucent's Learning and Performance Center.

This list is focused primarily on the needs of designer/developers. These individuals need to be able to function as a part of a development team, fitting into a variety of development roles from architect to tester. Broad exposure to all Object Oriented skills is desirable, and specific knowledge of development techniques is stressed.

The skills list is broken down into multiple categories. Within each category are specific skills or competencies
that students of Object Oriented design and implementation should master.

Detailed listing of skills

Object Oriented Concepts

Abstraction

deal with implementation details
bring it to problem space
think abstractly
provide multiple concrete examples

students pull abstraction from concrete examples

hiding the details

one object can't know everything
"Who knows this?"

essential vs. accidental complexities
layering - building upon existing modules

inheritance examples

breaking things up => modularity

splitting work between multiple developers

Polymorphism, Inheritance

what they are
rationale:

"why use it?"
what does it accomplish?

how to do it?

language-specific (C++ /virtual/overloading/templates)
design

present the Smalltalk inheritance model
class/inheritance

Encapsulation

how is this different from abstraction?
modularity
public vs. private namespaces or knowledge
encapsulated data vs. functions
assignment of responsibilities
"what does it know?" -- encapsulation of knowledge
How systems mature over time

you get better encapsulations over time.

Why to use encapsulation?

horror stories

An object-oriented way of defining a set of classes and distributing responsibilities across the classes

Important abstractions become classes
focus on responsibilities
group objects together that have similar responsibilities
data based design vs. OO design

shift focus to responsibilities
issue: data vs. behavioral design
skills:

extract responsibilities from Use Cases and/or Scenarios
noun/verb blitz (objects/actions)

refinement of knowledge
coupling and cohesion
distribution of responsibilities across

subsystems
profiles

role playing (anthropomorphizing objects)
CRH is a "way to do it"
collaboration

Knowing what standard OO patterns are, and how to apply them

What are patterns?
Architectural patterns
The patterns community
Pattern languages
Pattern notations (pattern normal form)
Pattern collections (GoF, POSA)
Motivations for using patterns

ramp up for new team members

patterns are a good way to "ramp up" (Opdyke)

patterns are "captured knowledge"

You need to know when you should be looking through patterns during the development process (possibly at several points in the process)
you should also have lunchtime patterns study groups

permanent documentation

"Patterns Mining"

How to select and apply a pattern

distinguish implementation from the pattern
examples of applied patterns
Designing systems with (multiple) Patterns

How to review a pattern in a team setting
How to write a pattern

Ability to recognize good and bad OO designs

Examples of Good and Bad Designs

Riel heuristics

include "why"

design goals

Change: What kind of change are you prepared for?

Dimensions of ways that designs are good and bad:

Complexity of modules
isolation
Names of classes are not clear or descriptive
duplicate classes
change history

Design refinement

Recognize when, where, and how to do it

Impact analysis of changes
Tradeoffs

efficiency/flexibility
space/time

OO analysis and design: why we use them, what are the benefits, and examples of good processes and notations

better for evolution and reuse
compared to what?

doing analysis and design without OO
"hacking" without doing analysis and design

aspects of OO have been around for decades
technology provides better mapping of design to implementation
more "fun" in design

it isn't just the coders who have the fun
teams/role playing

If we are designing an evolving system, then:

interactions are/should be more likely to change than "insides" of objects

OO models the "real world"

spiral vs. waterfall
cost, quality, and schedule considerations

how the scheduling is different for OO
delivered code before requirements are complete

drivers:

data
behavior
events
interfaces/constraints
unknowns/risks
choice of methodology depends upon which of these is "in control"

exercises:

OOPSLA '97 educators symposium coffee machine example: showing the ability to handle change
Metaobject Protocol

Knowledge of at least two OO programming languages

Language list:

C++
Java
Smalltalk
CLOS
Self
Eiffel
Objective C

Language-specific topics:

core language
packages/extensions
idioms

Advantages/contributions of various languages

Eiffel: interfaces, contracts
Smalltalk: everything is an object
CLOS: introspection

Trips and Pratfalls
efficient application of the language

run-time, space, developer resources

language comparisons

semantics
object management

interoperability

Practice using standard libraries and standard programming idioms

Details according to the individual languages to be provided

OO techniques and notations that are used to record and communicate analysis/design decisions

CRC [CRH]
Use cases / Scenarios
Harel Statecharts
applied patterns
survey of OO notations
CASE

survey of CASE tools
code analysis tools (McCabe, Scott Meyers guidelines checkers)
critical evaluation/selection criteriea for tools and methodology support
role of CASE tools

don't overspecify; use the tools and notations to describe things at the right level to communicate

appropriate use of tools and notations; realistic expectations
multiple potential uses for high-level design
CASE tools as "enabling technology"
living with legacy

moving legacy into an OO world

The proper use of iterative development techniques and prototypes

Difference between prototype and iterative development
Staggered delivery of features
How to set expectations with managers
Prototype to manage unknowns
phases

feature/function growth
consolidation and improvement after prototyping work

What not to do
Iterative lifecycles

cross-listed in management track
estimation
management of timelines

understanding implications of discovery costs

making changes to an existing system forces people to revisit existing designs. OO can help with this.

Strategies for software developers applying OO appropriately to their development jobs

case studies
jump starts
workshops
suitcasing courses to projects
design consulting with project teams
domain examples
implementing in non-OO languages
when not to use it
"senior project"
typical objections to OO technology, and how to handle them

too expensive
"can't afford the luxury of design"

how to find OO projects
looking for patterns or concepts within existing systems
deriving patterns or concepts from requirements
LPC should advocate Mercenary Analysts

internal consultants for analysis and design (ORCA)
reviewers with domain knowledge (SARB)

Skills in using objects in distributed/heterogeneous environments

CORBA
Half-Object Plus Protocol pattern and distribution patterns
encapsulation to achieve portability and interoperability

wrapping
threads

performance issues
Doug Schmidt C++ Report articles
What about Microsoft?

DCOM, ActiveX
Advantage of selling your soul

Java and Java Beans
Emerging technologies

importance of staying current

Skills List for Designers/Developers

Categories

Detailed listing of skills