OOA&D w/UML

3 Days – Course No.  WD06

 

who should attend?

Software developers, programmers and analysts who are familiar with and experienced in software development methodologies who will be using object orientation and UML in upcoming projects. Some familiarity with OO concepts is assumed.

 

Prerequisites:

Experience in software development and familiarity with OO concepts are required. Object Orientation Overview (WD05) or equivalent experience is recommended.

 

performance objectives

Object orientation has become the predominant paradigm for virtually all modern software development. This course builds on basic concepts to apply object-oriented principles to all phases of the software development life cycle, with particular emphasis on analysis and design. Students will participate in case studies and short exercises. The Unified Modelling Language (UML) is introduced and is used as the common language in all examples and exercises.  

 

course outline

What is UML?

◦     What is UML?

◦     Why use UML?

◦     UML Diagrams

 

Gathering Requirements

◦     Why requirement analysis is a difficult task

◦     Fuzzy or incomplete requirements

◦     The importance  to get requirements right

◦     Why model?

◦     How to determine requirements

◦     Kate's Clothiers-Monthly customer invoice

◦     Use Cases

◦     What is an actor?

◦     How to identify actors

◦     How to find use cases

◦     Relationships between use cases

◦     Use case diagrams

◦     Activity diagrams

 

Discovering objects

◦     Common class patterns approach

◦     Candidate Classes for Kate's Clothiers

◦     Eliminating candidate classes

◦     Common errors in preparing a class list

 

CRC Cards

◦     What is a CRC card ?

◦     What is a responsibility ?

◦     Writing responsibilities

◦     What is a collaboration ?

◦     Using CRC cards

◦     Collaboration diagrams

◦     Why use CRC cards?

◦     Formal CRC Cards

◦     When do you use CRC Cards?

◦     When do you use collaboration diagrams?

 

UML Class Diagram

◦     UML class diagram

◦     Representing a single class

◦     Attribute compartment

◦     Visibility

◦     Operation compartment

◦     Class scope

◦     Translating CRC cards to a class diagram

◦     When do you produce a class diagram?

 

Relationships between classes

◦     Determining associations

◦     Ternary associations

◦     Eliminating redundant associations

◦     Adding associations to Kate's Clothiers

◦     Multiplicity

◦     Adding multiplicity to Kate's Clothiers

◦     Qualified associations

◦     Association class

◦     Aggregation - When to use it

◦     Composition - When to use it

◦     Add aggregation and composition to Kate's Clothiers

 

Inheritance

◦     What is inheritance?

◦     Diagramming conventions

◦     When to use inheritance

◦     Using a "type" attribute instead of two classes

◦     Multiple inheritance

◦     Good multiple inheritance

◦     Vehicle tracking system:  Attempt 1

◦     Vehicle tracking system:  Attempt 2

◦     Vehicle Tracking System:  multiple inheritance

◦     Replacing multiple inheritance with aggregation

◦     Interfaces

◦     Lollipop notation

◦     Using interfaces

 

Dynamic modelling

◦     Static and dynamic modelling

◦     When to use dynamic diagrams

◦     Sequence diagrams

◦     The layout of a sequence diagram

◦     Objects in a sequence diagram

◦     Objects: exist, are alive, are active

◦     Messages and returns

◦     Conditions and iteration markers

◦     Sequence diagrams and concurrent processes

◦     Sequence diagrams and multiple scenarios

◦     Sequence diagrams versus procedural flowcharts

◦     State diagrams

◦     The basics of UML state diagrams

◦     Guards

◦     Default state transition

◦     Substates and superstates

◦     Special events: after, when, entry, exit

◦     Errors versus events

◦     Concurrent state diagrams

 

Evaluation of Object Model

◦     Dividing into packages or modules

◦     Component diagram

◦     Deployment diagram

◦     Metrics: sinple counting and dividing

◦     Inheritance metrics

◦     Relationships among classes: tree impurity

◦     Relationships among classes: complexity

◦     Coupling

◦     Cohesion

 

Patterns

◦     Design

◦     Singleton

◦     Composite

◦     Strategy

◦     Factory