CSC535 – Object Oriented Software Development Introduction

CSC535 – Object Oriented Software Development

Introduction

Ground Rules – Attendance • Attendance is imperative

– If you must miss a class, contact me ahead of time– If the miss is unplanned, contact me as soon as

you can after the class– If you must miss multiple classes, your grade will

suffer– As you probably know, some of my lecture

material comes from the book, much does not• Thus you need to attend lectures and read the book

Ground Rules – Participation • Participation in class discussions

enhances the learning experience– You all have software development (or

general project development) experiences to share

– Doing so will benefit everyone

Ground Rules – Activities• You will be working in groups on a term-long

project– Team work is one of the primary reasons the

object-oriented software development process was created

– I will give you time to meet as a team during class– Meeting outside of class is up to the team, you

should all have access codes to the computer science lab for this purpose

Ground Rules – Exams/Homework• As of now I am undecided whether we

will have an in class exam and final or not– But I am leaning towards having one– More on this later

• Similar comments regarding individual homework assignments

The book

• UML Distilled, Third Edition– Martin Fowler– Publisher: Addison-Wesley – ISBN-10: 0321193687 – ISBN-13: 978-0321193681

Chapter 1

Introduction

Programming Languages

• The hierarchy

Architecture Independent

Architecture Dependent

Architecture Dependent

High Level Language Statement


Assembly Language Statement


Machine Code Statement






…

…


• Translation

Compiler

Assembler

Linker/Loader











…

…


• Abstraction

Highly Abstract

Moderately Abstract

Not Abstract











…

…


• All three are implementation languages– They are used directly to create programs that will

run on real computers– All of the languages convey information about

what the architecture will do (what will happen within the AND, OR, and NOT gates)

– None of the languages convey information about the design

• Although the design may be extracted from the code, but typically with great difficulty


• What does this do?mov A, R1subb A, R5jnc eLTmov R2, #0x06sjmp endLTeLT:mov R2, #0x07

endLT:nop

if (R1 < R5) R2 = 6else R2 = 7


• Programming languages are good for writing code

• Programming languages are not good for designing software systems

• They do not convey an level of abstraction that is easily understood by humans

Unified Modeling Language• UML is a design language, first and foremost

– Although it can be used to generate code (more later)

• UML is a graphical notation for describing and designing software systems– Although it can be used for designing non-

software systems

Unified Modeling Language• UML is not synonymous with object-

oriented design/programming– Although it’s introduction in 1997 was to

encourage the use of object-oriented design approaches

• UML is not used for drawing flowcharts

Use of UML

• UML can be used in three different modes (or styles)– Sketch– Blueprint– Programming language

• UML can be used in two different directions– Forward – used to design a new system– Reverse – used to document an existing system

Sketch Mode

• Goal: to communicate “some” aspects of a design

• Forward engineering: capture the main concepts of the design for the purpose of converting to code

• Reverse engineering: convert detailed code to a higher level of abstraction for the purpose of understanding

Sketch Mode

• Informal – you don’t have to follow any strict rules

• Dynamic – designs will change• Collaboration – facilitates multiple people

contributing to the design• Typical media – white board, sketch pads,

lots of scratch paper• Tools – no special tools required

Blueprint Mode

• Goal: to communicate a “complete” design to the programmers

• Forward engineering: code is written from the UML documents with no design alterations

• Reverse engineering: convert detailed code to a higher level of abstraction for the purpose of understanding

Blueprint Mode

• Formal – strict rules must be followed so that the programmers know exactly what the designers want done

• Semi-Dynamic – designs may change but change can be costly at this time

• Collaboration – ideally the programmers need not talk to the designers

• Typical media – printed documents• Tools

– Forward: drawing tools and meta-data repository

– Reverse: compiler with UML generator in place of the assembly code generator

Programming Language Mode• Goal: to generate executable code

• Forward engineering: the UML is the code

• Reverse engineering: not needed

Programming Language Mode• Formal – strict rules must be followed so that code

can be generated• Static – the UML is the code, to change the code you

change the UML• Collaboration – only at the module (or package) level

(same as conventional programming)• Typical media – printed documents• Tools – code generating UML tool (they exist but are

not great)

UML Modes

• Sketch mode is the most common usage

UML Perspectives

• Software– Some UML artifacts (we’ll define these

later) map directly to code

• Conceptual– Some UML artifacts map directly to

deployment (placement of software rather than design of the software)

So, What is UML?

• A graphical design notation– The diagrams (graphical notation)

themselves capture the “syntax” of the system being designed

• Meta-models– The concepts conveyed by the diagrams

capture the “semantics” of the system being designed

UML Diagrams

• UML 2.0 contains thirteen (13) diagram types– Each has it’s “typical” usage and elements

– There is no “strict” rules on when or how to use each diagram

– There is no “strict” rules as to what elements each diagram will contain

– Obviously, in programming language mode strict rules must be followed

• Basically, UML provides a set of design guidelines that will help you be successful in your design phase

UML Diagrams

• The diagrams are descriptive– They are used to convey ideas– You will hear “most people use them this

way…”

• The diagrams are not prescriptive– They do not tell you how and what to do– You won’t hear “you have to use them this

way…” (except in programming mode)

Class Structure

Project Based

• You will be the design team– 3-5 members

• I will be– The customer

– The technical advisor

• I will not be– A system designer

– A programmer

– An arbiter

Project Based

• Your team will– Manage itself– Produce a design (all aspects – more later)– Produce an implementation (code)– Produce system documentation– Perform design reviews– Perform product demonstrations– Use UML in a forward-engineered, sketch/blueprint

mode (closer to blueprint than sketch)

Project Based

• Team management– Create the system design– Create the system documentation– Maintain a schedule– Maintain a repository (backup, librarian)– Write, test, debug code– etc. etc. etc.

Project Based

• Management – I will not tell you how to run your team– I will not tell you how to divide work amongst your

team members

• But– All team members will be responsible for all

aspects of the project– All team members must understand all aspects of

the project

Startup

• Form teams

• Choose a team name and a logo

• Create document letter head – Presentation material (suggest PowerPoint

or Keynote)– Documentation (suggest Word and Visio)

• Review the project specification

Deliverables

• You will be given deliverables and dates throughout the term

• First deliverable – due June 3, 2010– Team name– Team logo– Team member names and email addresses– A set of items (questions) that you believe require

clarification from the customer before you can proceed with the design

– Bibliography of resources used

Deliverables

• All “written” submissions should be on team letterhead– Source code and UML diagrams will be

addressed as they are introduced into the list of deliverables

Evaluation Criteria

• Grading will be based on:– Following instructions.

– Meeting deadlines.

– Working as a team.

– Quality of workmanship.• How closely the design matches the code.

• How well the design documents are written.

• How well the code is written.– Usage of OO constructs.– Coding standards.– Comments.

– Does the program meet the specification and work properly?

– Quality of presentations.

Evaluation Criteria

• An actual grading scale based on the above items will be provided. For the time being, assume that they are all equally important and thus, equally weighted.

Documents

CSC535 – Object Oriented Software Development Introduction