The Basics of OOP Design

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

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

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

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

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

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)

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

Audit How did we do?

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

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

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

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

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

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?

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

Switching Gears to OOP

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

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

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

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

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

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

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

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

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

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

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

Unified Process: Construction The software gets built Testing

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

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

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

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

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

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

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.

UML Deployment Diagrams

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

UML Statechart Diagrams

My Summary