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: –ISBN-13:

Chapter 1 Introduction

Programming Languages The hierarchy Architecture Independent Architecture Dependent High Level Language Statement Assembly Language Statement Machine Code Statement Assembly Language Statement Machine Code Statement … …

Programming Languages Translation Compiler Assembler Linker/Loader High Level Language Statement Assembly Language Statement Machine Code Statement Assembly Language Statement Machine Code Statement … …

Programming Languages Abstraction Highly Abstract Moderately Abstract Not Abstract High Level Language Statement Assembly Language Statement Machine Code Statement Assembly Language Statement Machine Code Statement … …

Programming Languages 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

Programming Languages What does this do? mov A, R1 subb A, R5 jnc eLT mov R2, #0x06 sjmp endLT eLT: mov R2, #0x07 endLT: nop if (R1 < R5) R2 = 6 else R2 = 7

Programming Languages 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 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.