OOSE web page this is where your notes are:

1
Introduction

• Welcome!
• OOSE web page - this is where your notes are
• http//gawain.soc.staffs.ac.uk/modules/levelm/oos
  e/oose.htm
• 12 week module - 2 hrs a week contact 2 hours
  blended
• Module team Ritchie and myself
• We are particularly interested in equipping and
  selling all of you with doing OO software
  engineering (SE) skills within the learning
  outcomes of the module descriptor

2
What is the module about?

• As you can see from the schedule this is a
  practical module
• New skills (see next slide)
• It must be underpinned with background reading
  and wider SE practice where directed
• As always we only have 12 weeks and so do not get
  overwhelmed by the subject matter

3
Skills include

• A summary of the software engineering skills to
  impart to you-
• How to program using OO software engineering
  techniques
• OO Web development skills
• Awareness and use of object oriented methods
  (UML)
• Database integration
• Good practice

4
In context

• Other aspects of software engineering are covered
  by other modules
• Project management/Systems Analysis/Communications
  /Computer hardware and software
• All the above topics come under the umbrella of
  software engineering
• can seem confusing until you realise that
  software engineering involves a set of stages and
  tools

5
Reference books

• Discuss refer to module pages
• Traditional SE books
• OO books
• UML books
• JSP books

6
SE scope

• We need to understand what software engineering
  is and how it came about
• Why use it?
• How to use it - the lifecycles
• Improvements
• Future of software engineering

7
What is SE?

• An approach to software development to embody the
  same discipline and rigor found in the
  engineering world
• Advantages include
• Speed/productivity
• Re-use
• Measurable

8
History 1

• The software crisis, recognised C1969. -
  threatened the progress of the computer industry
• People-time was and still is relatively
  expensive, machine-time is cheap.
• Programming was and still is very time intensive.
• Products need support - this is probably more
  than ever
• Software is complex imagine creating a car with
  no drawings, specifications or planning.
• Software lives it somewhat erodes with age

9
Trends as at 2007ltdiscussgt

• The price of computer hardware is still falling
  fast.
• The cost of computer software is still high
• More and more products are incorporating
  microprocessors (and thus software),e.g car
  engines, cameras, TV sets and mobile phones
• Tens of millions of personal computers are in
  use, often in strategic roles.

10
Trends as at 2007

• Personal, corporate, national and international
  economies are increasingly dependent on computers
  and their software.
• Some commercial software is still written in old
  COBOL (and new Object Cobol!) and has been
  modified and patched by generations of engineers
• Some of our most complex feats of engineering are
  computer programs.

11
Programming programming Development

• Programming is much more than just writing code.
• Programming involves (at least) the following
  activities-
• Problem analysis,
• Planning,
• Code and interface design,
• Coding, Debugging and Testing,
• Documenting each activity.
• Do you all agree?

12
And incorporates documentation

• Documentation is more than just a listing of the
  finished program.
• Documentation involves all of the following-
• Records of the analysis of the problem,
• The time resource plan,
• Technical and User documents,
• Records of all bugs and bug fixes,
• Records of test input and output.

13
The people aspect

• IT personnel now expected to have skills which
  are in the top eleven demanded
• 1.     SQL (up 16)2.     C (28)3.     Office
  (8)4.     Java (11)5.     C
  (10)6.     Oracle (1)7.     Unix
  (-3)8.     SQL Server (21)9.     .NET
  (28)10.     C (52)11.     Visual Basic (4)
• Different roles with a software development
  project
• People may join or leave a development team.

14
Software Development Lifecycles.

• Software engineering helps to co-ordinate the
  team so that they are on the same page
• How does it help?
• Lifecycles
• Automation of tasks
• Since the software crisis of the 70s, software
  developers have been looking for a solution
• to increase programmer productivity
• to increase the quality of software
• to decrease software production costs
• Why? Because industry (the users) were fed up
  waiting for software and because it was costly

15
Software DevelopmentLife Cycle(SDLC) - Classical

• Software Engineering has identified several
  classical life cycles with different
  complexities, different aims and different
  outcomes.
• Its up to you which one you choose and can of
  course be a combination of more than one
• SDLCs include (see tutorial session for links)
• Cyclic
• Waterfall/Cascade
• Evolutionary
• V
• DSDM

16
Nature of SDLCs

• All life cycles describe a process that you use
  to produce software
• They are practical and are worth employing?
  ltdiscussgt
• You need to have some understanding of all of
  them
• They all have common features - stages
• Systems Analysis and Design or Requirements
  engineering module typically involves a couple of
  stages in the software development life cycle

17
Cyclic

• Cyclic features
• Easy to use
• Useful for bespoke/one off systems with no
  maintenance
• No definitive start or finish to the process
• Includes a recognition of management involvement
• Can be difficult to control

18
Cyclic
Idea for a project or product
Contract for a Project
Concepts/ Feasibility
Requirements/ Specification
Management yes/no
Next version
Design and Code
Testing and Acceptance
Maintenance
19
Waterfall

• One of the most famous SDLCs - a waterfall
  because the stages of the lifecycle follow the
  premise of one stage following another
• Still shows a somewhat cyclic nature to software
  development.
• Shows the possibility of rework.
• Includes maintenance as a vital part of the
  cycle.
• No inbuilt control or management recognition (a
  weakness)

20
SDLC (waterfall)
System/Software Requirements
Analysis
Design
Code
Test
Release
Maintenance
21
Evo

• The Evolutionary life cycle is quite different
  from most other cycles.
• Tom Gilb is credited with this SDLC
• Its main principle is that of the surrounding
  environment and therefore the requirements
  continually change!/evolve
• Therefore an SDLC must reflect this position
• Evo produces many small steps/ products towards
  an overall goal.
• It is VERY difficult to control.
• Many people argue that it is the ONLY way to
  achieve a quality product

22
Evo

• Evos guiding principles are -
• Deliver something to a real end-user
• Measure the added-value to the user in all
  critical dimensions
• Adjust both design and objectives based on
  observed realities.

23
Evo
Evolutionary Life Cycle.
initial objectives
revised course towards new objectives
heading towards initial objectives
useful delivery to user steps
changed objectives
24
V

• The V life cycle is an extension of the
  waterfall life cycle.
• It includes elements of Quality Assurance at
  every stage.
• Looks at the whole of the project
• No obvious management, but inbuilt control
  through QA.

25
V
Maintenance
Requirements Acceptance Test
Analysis System Test
High level Design
Integration Test
Low level Design
Module Test
Code Unit Test
V Life Cycle
26
DSDM

• Based on RAD
• Definition
• DSDM.org

27
Object-Oriented Methodology

• Object oriented technology is based on a few
  simple concepts that, when combined, produce
  significant improvements in software engineering.
• Everything IT is now object based ltdiscussgt
• Unfortunately, the basic concepts of the
  technology often get lost in the excitement of
  advanced features and advantageous features.
• The basic characteristics of the OOM follow but
  are only meant as being introductory
• It is interesting that the release of Office 2007
  is built on entirely OO principles

28
Object-Oriented Technology

• Characteristics cornerstones of Object Oriented
  Technology
• Identity
• Classification
• Polymorphism
• Inheritance
• We will be using the Unified Modelling Language
  (UML) to follow on own methodology through the
  module schedule
• More about UML next week

29
Identify modelling

• The term Object Oriented means that we organise
  the software as a collection of discrete objects.
• An object is a software package that contains the
  related data and the procedures.
• Although objects can be used for any purpose,
  they are most frequently used to represent
  real-world objects
• ..such as products, customers and sales orders.
• The basic idea is to define software objects that
  can interact with each other just as their real
  world counterparts do, modelling the way a system
  works and providing a natural foundation for
  building systems to manage that business.

30
Classification

• In principle, packaging data and procedures
  together makes perfect sense. In practice, it
  raises an awkward problem.
• Suppose we have many objects of the same general
  type- for example a thousand product objects,
  each of which could report its current price. Any
  data these objects contained could easily be
  unique for each object.
• Stock number, price, storage dimensions, stock on
  hand, reorder quantity, etc would differ from one
  product to the next.
• But the methods for dealing with these data might
  well be the same. Do we have to copy these
  methods and duplicate them in every object?
• No, this would be ridiculously inefficient.
• All object-oriented languages provide a simple
  way of capturing these commonalties in a single
  place.
• That place is called a class. The class acts as a
  kind of template for objects of similar nature.

31
Polymorphism

• Polymorphism is a Greek word meaning (many
  forms).
• It is used to express the fact that the same
  message can be sent to many different objects and
  interpreted in different ways by each object.
• For example, we could send the message "move" to
  many different kinds of objects. They would all
  respond to the same message, but they might do so
  in very different ways.
• E.g. The move operation will behave differently
  for a window and differently for a chess piece.

32
Inheritance

• Inheritance is the sharing of attributes and
  operations among classes on a hierarchical
  relationship.
• A class can be defined as a generalized form and
  then it specialized in a subclass.
• Each subclass inherits all the properties of its
  superclass and adds its own properties in it.
• For example, a car and a bicycle are subclasses
  of a class road vehicle, as they both inherits
  all the qualities of a road vehicle and add their
  own properties to it.

33
Object Oriented Methodology

• By utilising object technology, a wide-range of
  applications can be engineered
• The aim is to produce a system that is
• robust
• easy to maintain and structured
• easy to understand hopefully!
• OOM itself is a framework by which to create
  these systems.
• A variety of steps can be taken to achieve these
  aims. Youll be using some yourselves from next
  week
• Use Cases, Class Diagrams, Sequence diagrams etc

34
Conclusion

• Software Development life cycles describe the
  process used to produce software.
• Questions to always ask
• What does it achieve?
• What doesnt it achieve?
• How could you alter it to be better?

35
Insight ability to reflect

• You must identify your life cycle.
• You must identify the requirements for your life
  cycle
• You should look at possible ways to improve it.
• Question - Should there be one life cycle for
  the team/project?
• What are the benefits and problems of such a
  suggestion?
• What are you going to do about it?
• Anecdotes from JCW

36
Conclusion contd

• As we have discussed - some of the life cycles
  dont include recognition of project management
  and control
• Project management and control is CRUCIAL and you
  will find in industry/books reference being made
  to the Project Development Life Cycle(PDLC)
• The SDLC fits inside a PDLC - it is the life
  cycle for the software development part of the
  project(of course that may be the whole of the
  project)

37
The complete software developer?

• A Software Engineer!
• SE includes both technical and non-technical
  elements, so software engineers must be able to
  communicate well, both orally and in writing.
• They must have a thorough knowledge of computer
  systems and must understand the importance of
  project management, user feedback, documentation
  and quality control
• So easy .!!!

38
The future

• SE still relevant in 2007 as in 1970
• Tools have changed and will continue to do so
• CASE tools have had limited success - specialised
  tools tend to be used for each stage
• Modelling, Design, Testing, Optimisation etc.
• UML is interesting as it is universal
• New set of challenges have appeared in the latter
  part of the 1990s - web development we will
  look at this later on in the module when we cover
  JSP
• Requirements capture as important as ever for the
  success of a project.this has not changed in
  being still the area most prone to getting it
  wrong
• Still evidence of projects failing however..why?
  ltdiscussgt