CSCE 240 – Intro to Software Engineering

Lecture 2

Quote of the Day

“Relativity applies to physics, not ethics.”

-Albert Einstein

Overview

Finish Chapter 1

Begin Chapter 2

Discuss Homework 1

Software Engineering code of ethics(IEEE)

Software Engineers shall:Act consistently with the public interestAct in the best interests of their client or employer as long as this is consistent with the public interestDevelop and maintain their product to the highest standards possible

SE code of ethics(continued)

Maintain integrity and independence when making professional judgments.Promote an ethical approach in management.Advance the integrity and reputation of the profession as long as doing so is with the public interest.

SE code of ethics(continued again)

Be fair and supportive of colleagues.

Participate in lifelong learning

Types of SE ProjectsEvolutionary projects – modifying an existing system(maintenance/upgrade)

Corrective – fix defects (patches). Adaptive – modifying system to account for

changes in its environment(moving from win2k to XP).

Enhancement – adding new features Re-engineering – fine tuning the internal workings

of the system without changing the features.

Types of SE Projects (continued)

“Green field projects” – projects build from scratch with no other system to build on or modify(starting fresh).Component/Framework project – build from existing components which are assembled and modified to the needs of the current project(Lego blocks). Very reuse friendly.

SE project activitiesRequirements and Specification (What)Design (How)ModelingProgrammingQuality Assurance (Testing)DeploymentManagement of Design ProcessMaintenance

Requirements and Specification

Domain Analysis – understand background to better understand problem.Define Problem – detail exact problem(s) to solve with system.Requirements Gathering – get all stakeholders ideas about what the system should do.

Requirements and Specification(continued)Requirements Analysis – organize all requirements gathered in an ordered fashion then decide what software should do.Requirements Specification – produce a precise set of requirements for what the software system SHALL do. (no implementation details included).

DesignSystems Engineering – hardware vs. software implementation. Software Architecture – how software is organized and how the various parts (subsystems) interact.Detailed Design – detail how to construction of subsystemsUser Interface Design – detail how user interacts with system.Data Storage – how data is managed/stored by system.

ModelingUse case modeling (Use case diagrams)

Structural modeling (Class Diagrams)

Dynamic and behavioral modeling (State/Sequence diagrams)

Quality AssuranceReviews and Inspections – frequent evaluation of designs or code to assure customers requirements are being met.

Testing – testing software to assure it behaves as intended.

Quality Assurance (continued)

Verification – are the requirements being met?

Validation – does the software system solve the customers problem?

ManagementEstimating Cost

Estimating Cost

Planning – managing people involved in project to avoid wasted or duplicated effort.

SE Problems and RisksComplexity – software systems tend to be complex. Poor understanding of the problem, feature creep and gold plating all contribute to this problem. Technology changes rapidly – computers tend to evolve quickly and systems can often be based upon untried technologies.

SE Problems and Risks (continued)

Does software actually match customers needs – never sure until software is delivered. Try to understand problem domain as well as possible.Taking on a job not properly qualified or staffed for – SE firms are intended to make money. This desire for profit can lead to over extending of resources.

SE Problems and Risks (continued)

Requirements and Technology always change – carefully document changes and try to manage any risks associated with these changes.Politics – any industry involving people will have people not happy with systems, or who have ulterior motives for wanting to see a software project succeed or fail.

Chapter 2

Object Orientation

What is the object oriented paradigm?

“It is an approach to the solution of problems in which all computations are performed in the context of objects. The objects are instances of programming constructs, normally called classes, which are data abstractions and which contain procedural abstraction abstractions that operate on objects.”

Procedural vs. OO

main

perform transaction

compute feesif checking then xxx if savings then xxx etc.

compute interestif checking then xxx if savings then xxx etc.

debitcredit

Accountcreditdebit

SavingsAccount

compute interestcompute fees

CheckingAccount

compute interestcompute fees

main

perform transaction

compute feesif checking then xxx if savings then xxx etc.

compute interestif checking then xxx if savings then xxx etc.

debitcredit

Accountcreditdebit

SavingsAccount

compute interestcompute fees

CheckingAccount

compute interestcompute fees

Objects + ClassesObject – “A chunk of structured data in a running software system” – also – an instance of a class

Class – “A unit of data abstraction in an O-O program.” – also – a set of objects with the same behavior and properties.

ClassesContain:

Attributes – data stored within class (variables)

Methods – procedures which implement behavior in classes.

Object or ClassFruit?Apple?Food?Dog?Cat?Pet?Animal?

Reading for Next time

Read Chapter 2

For next timeFinish Chapter 2 on objects and classes

Very very brief look at some UML

If time permits, begin chapter 3 on reuse.