1. The Basics of OOP Design

2. Objectives Review the systems development lifecycle
Summarize various design methodologies
And their utility in particular settings
Introduce BizAgi and UML

3. The Systems Development Lifecycle
The traditional waterfall approach
Planning
Analysis
Design
Logical
Physical
Testing
Implementation
Audit

4. Planning Feasibility study
Technical feasibility
Economic feasibility
Operational feasibility
And then we set up the project management team
And here is where you will learn I’m not a waterfall person

5. Analysis The result is a list of specifications of
What the software should do?
Who will use it?
What is the business value?
The process involves
Understand as-is system
Design the to-be system
You saw that last week

6. Design What do we create to meet the specifications?
Who designs the project (In this class, we assume it’s you)
Steps
Design the architecture
Design the entities
Design the user interface
In a physical design we need to decide on technologies and hardware

7. Implementation Here we built it Populate it Plan to deploy it
Construct it
Populate it
Load the data
And this process takes time and is iterative
Plan to deploy it
Development, test, production
Go live plans (pilot study, phased, parallel, plunge)

8. Testing You can never test enough and you can never be to good at it
Unit testing
Extreme programming workflow

9. Audit
How did we do?

10. Methodologies Waterfall Parallel That’s what I just showed
We try to parallelize (student records implemented at the same time as financials)
or pipeline tasks (start something before something else is finished

11. Methodologies (RAD) Rapid Application Development (RAD)
Not so much a methodology as a family of them
Phased development
Hybrid of waterfall and prototyping
We develop successive versions
Prototyping
Quick and dirty programs to demonstrate proof of concept

12. Methodologies (Agile)
Another family based on a 12-point manifesto
My summary
Deliver software versions early, continuously and rigorously
Stakeholders work closely with developers
Face-to-face communication between developers
We measure working software (outputs)
Simplicity

13. Methodologies (Extreme)
I’ll call extreme and agile method
Four similar principles to agile
Communication
Simplicity (KISS)
Feedback
Courage – quality first

14. Methodologies (Scrum)
From a rugby term – to restart a game
It’s the chaos principle
Plans fall apart so scramble to get a new plan

15. The Design Question And so where does all that put project management
Hard to pin down everything when we cannot even have a plan
So which if any methodology do we use and when?

16. Some Answers to the Design Question
If users are unclear, they need prototypes
The more complex, the more design needed
Usually more waterfall-based
For systems to be reliable, they must undergo extensive testing
And we have some good testing methods like unit testing for code

17. Switching Gears to OOP

18. Section Introduction
In this section of the chapter, we switch gears and discuss object-oriented system design
But what does that have to do with process?
All of these ERPs are based on familiar concepts and well-vetted concepts of OOP
So if I’m an IT guy automating a process, I’m working with ERPs and Web Services and the processes exposed by those services
My discussion might vary from your book’s but we are

19. Key Terms (Programming Object)
Programming objects are designed to mimic real-world objects
Television set / DVD
Objects (classes) have two important characteristics
State: Current data about the object
A dog has a name, color, etc… These data items are called attributes
Behavior: Things the object can do
A dog can bark, fetch, sit, etc..,
The text boxes and buttons with which you are familiar are programming objects

20. Key Terms (Class)
A class is a template or building block for an object
We say that an object is an instance of a class
In manufacturing, we create several bicycles from the same template
We create several text box objects on a Visual Basic form from the TextBox class

21. Key Terms (Class)
Classes are often modeled using UML class diagrams

22. Classes (Parts) Think of a class having three parts Data
The class describes what can be stored, the instance (object) stores a value
The nouns of a sentence
Methods
What you can do with the object
Make a bank deposit
And these are processes
Messages
Messages, triggers, events
They are known by many names

23. Key Terms (Inheritance)
Some classes have share characteristics with other classes
Mountain bikes, road bikes, etc… all have shared characteristics
Students are all people
An “IS A” relationship
OOP allows us to inherit state and behavior from other classes
The parent classes is called the superclass
The derived class is called the subclass
I’ll omit polymorphism for now

24. And now the 3rd Gear – Design in an Object-oriented world

25. Introduction to the Unified Process
We could spend the whole year talking about the Unified Process and the Unified Modeling Language (UML)
The Unified Process is a methodology that describes what UML tools to use in which modeling circumstances
It helps us to design programming objects upon which just about everything is built
And the focus is on modeling workflow

26. Unified Process: Phases
The process is “waterfall-like”
Inception
Elaboration
Construction
Transition

27. Unified Process: Inception
The planning and feasibility phase of the SDLC

28. Unified Process: Elaboration
This is the design process
We design
The classes
The data stored in the class and state
The responsibility of methods
The messages

29. Unified Process: Construction
The software gets built
Testing

30. Unified Process: Transition
Testing
This is really the deployment phase of the process

31. UML and Workflow
UML sees the world as workflows categorized into different types
Structural diagrams
Behaviorial diagrams
This models the idea of design pattersn
UML activity diagrams describe the dynamic aspects of a system
Statechart diagrams also model dynamic aspects of the systems
Use-case diagrams
Interaction diagrams

32. Structural Diagrams
UML class diagrams model the static view of an application
Object diagrams are similar to class diagrams but depict object class instances and their values
Component diagrams represent the implementation view
Deployment diagrams depict where components are deployed

33. Behavioral Diagrams
Depict the what a system does and the dynamic view of the system
Use case diagram
Sequence diagrams
Collaboration diagrams
Statechart diagrams
Activity diagrams

34. UML Class Diagrams
The class diagrams model the objects that make up an application and their relationship between each other
They identify
Classes
Properties
Methods
Inheritance

35. UML Object Diagrams They are an “instance” of a class diagram
They are derived from a parent class diagram
They depict the a class instance at a moment in time
They are really a snapshot take at an instance in time

36. UML Component Diagrams
It describes physical components, like software and libraries, rather than a system’s functionality
We usually represent a system with many component diagrams.

37. UML Deployment Diagrams

38. UML Activity Diagrams They describe the operation of the system
They depict parallel, branched and sequential flow

39. UML Statechart Diagrams

40. My Summary