CSC 506: Software Engineering and Knowledge Engineering

download report

Transcript CSC 506: Software Engineering and Knowledge Engineering

Dr. Syed Noman Hasany
Review of known methodologies
Analysis of software requirements
Real-time software
Software cost, quality, testing and measurements
Object programming
Knowledge engineering issues: knowledge representation
using rules, frames & logic, basics of logical inference, and
basics of search.
1. van Vilet, H. “Software Engineering Principles and
Practice”,John Wiley and Sons Ltd, 2000.
2. Fenton, N.E. “Software Metrics”,Chapman and Hall,
3. Wordworth, J.B. “Software Development with Hall”, 1991.
4. Wordworth, J.B. “Software Development with Z”,Addison
Wesley, 1992.
5. Knowledge Engineering: “Practice and Patterns: 16th
International Conference, EKAW 2008”, Acitrezza, Sicily,
Italy, September 29-October 2, 2008
Part 1
Work very hard to keep everything as simple as you can
We all have an intuitive notion of simplicity
We recognize simplicity
o In clear and easy to understand speaking and writing
o In uncluttered (neat and organized) forms
o In a good teacher’s explanation
o In a leader’s setting of goals and strategies
As we quickly grasp simple statements and forms, we
can easily use them as building blocks for our
thoughts and activities in work and play.
The world around us is complex and the human activities
increase the complexity.
Some of the complexity is inherent and we can do nothing
about it.
Some complexity can be reduced without penalizing
usefulness but with a net gain in elegance and quick
Many of these intuitive ideas can be applied to
programming as well.
Simpler programs are easier to use, review, document and
modify with the result of significantly reduced cost in all
phases of the process
Software engineering is also, in large part, about rendering
artifacts readable and usable by people as well as (if not
more so than) by machines.
Achieving simplicity sometimes requires extra work.
Documentation written from the point of view of the writer is
not nearly so useful as document written from the point of
view of the reader.
Achieving the reader’s perspective requires more work, but
results in a document that is vastly simpler to understand ,
to reference, to use, than one that results from an author’s
stream of consciousness.
“I had happily spend two hours pondering how to make a
simple sentence clearer” --- E. Dijkstra (the inventor of many
software Engineering principles)
Computer programs and associated documentation
Software products may be
o Generic - developed to be sold to a range of different customers
o Bespoke (custom) - developed for a single customer according to
their specification
Software engineering is an engineering
disciplinea which is concerned with all
aspects of software productionb
Engineer make things work.
Apply theories, methods and tools where appropriate
Discover solutions to problems even in the absence of
applicable theories and methods
Work and look for solutions within organizational and
financial constraints
Not only technical processes of software development, but
Software project management
Development of tools, methods and theories to support
software production
Classic Definition (1969)
o “The establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works
efficiently on real machines”
IEEE Definition (1993)
o “Software engineering (1) The application of a systematic,
disciplines, quantifiable approach to the development, operation
and maintenance of software; that is the application of engineering
to software.
(2) The study of approaches as in (1).”
Software engineers should adopt a systematic and
organised approach to their work and use appropriate tools
and techniques depending on the problem to be solved, the
development constraints and the resources available.
Computer science is concerned with theory and
fundamentals; software engineering is concerned with the
practicalities of developing and delivering useful software.
Computer science theories are currently insufficient to act
as a complete underpinning (foundation) for software
Software engineers must often use ad hoc approaches to
develop the software. (Research is in progress and will
remain in progress!)
System engineering is concerned with all aspects of
computer-based systems development including hardware,
software and process engineering. Software engineering is
part of this process
System engineers are involved in system specification,
architectural design, integration and deployment
o Process engineering focuses on the design, operation, control, and
optimization of chemical, physical, and biological processes.
Process engineering encompasses a vast range of industries, such
as chemical, petrochemical, mineral processing, advanced
material, food, pharmaceutical, and biotechnological industries. The
application of systematic computer-based methods to process
engineering is process systems engineering.
A set of activities whose goal is the development or
evolution of software
Mostly carried out by software Engineers
Generic activities in all software processes are:
o Specification - what the system should do and its
development constraints
o Development - production of the software system
o Validation - checking that the software is what the
customer wants
o Evolution - changing the software in response to
changing demands
Software costs often dominate system costs. The costs of
software on a PC are often greater than the hardware cost.
Software costs more to maintain than it does to develop.
For systems with a long life, maintenance costs may be
several times development costs
Software engineering is concerned with cost-effective
software development
Roughly 60% of costs are development costs, 40% are
testing costs. For custom software, evolution costs often
exceed development costs
Costs vary depending on the type of system being
developed and the requirements of system attributes such
as performance and system reliability
Distribution of costs depends on the development model
that is used
For software products that are (mostly) sold for PCs, the cost
profile is likely to be different. Specification costs are relatively
low. However, because they are intended for use on a range of
different configurations, they must be extensively tested.
System testing
Wat er fall mo del
Specificatio n
Dev elo pmen t
In teg ratio n and testing
It erative develo pmen t
Specificatio n
Iterativ e d ev elop ment
Compo nent-b ased software en g
Specificatio n
Sy stem tes tin g
in eerin g
Dev elo pmen t
Sy stem dev elop ment
1 00
In teg ratio n and testing
Dev elo pmen t and evo lu tio n cos ts for lo ng -lifetime sys t
1 00
20 0
Sy stem evo lu tio n
A structured approach to software development whose aim
is to facilitate the production of high-quality software in a
cost-effective way.
Methods such as Structured Analysis were first developed in
the 1970s. These methods attempted to identify the basic
functional components of a system; function-oriented
methods are still used.
In the 1980s and 1990s, these function-oriented methods
were supplemented by object-oriented (OO) methods.
These different approaches have now been integrated into a
single unified approach built around the Unified Modeling
Language (UML).
There is no ideal method. OO is good for interactive
but not appropriate for real-time systems.
 Methods include a number of different components:
 Model descriptions
o Descriptions of graphical models which should be produced (e.g.
Object models, data flow models, state machine models, etc.)
o Constraints applied to system models (e.g. every entity in the
system model must have a unique name)
o Advice on good design practice (e.g. no object should have more
than seven sub-objects associated to it)
Process guidance
o What activities to follow (e.g. objects attributes should be
documented before defining the operations associated with an
Software systems which are intended to provide automated
support for software process activities. CASE systems are
often used for method support
o Tools to support the early process activities of requirements and
o Tools to support later activities such as programming, debugging
and testing
The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable
o Maintainability
• Software must evolve to meet changing needs
o Dependability
• Software must be trustworthy
o Efficiency
• Software should not make wasteful use of system
o Usability
• Software must be usable by the users for which it was
Coping with legacy systems, coping with increasing diversity
and coping with demands for reduced delivery times
o Legacy systems
• Old, valuable systems must be maintained and
o Heterogeneity
• Systems are distributed and include a mix of hardware
and software
o Delivery
• There is increasing pressure for faster delivery of
Software engineering involves wider responsibilities than
simply the application of technical skills
Software engineers must behave in an honest and ethically
responsible way if they are to be respected as professionals
Ethical behaviour is more than simply upholding the law.
o Engineers should normally respect the confidentiality of their
employers or clients irrespective of whether or not a formal
confidentiality agreement has been signed.
o Engineers should not misrepresent their level of competence.
They should not knowingly accept work which is out with their
Intellectual property rights
o Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They
should be careful to ensure that the intellectual property of
employers and clients is protected.
Computer misuse
o Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (game playing on an employer’s machine,
say) to extremely serious (dissemination of viruses).
The professional societies in the US have cooperated to
produce a code of ethical practice.
Members of these organisations sign up to the code of
practice when they join.
The Code contains eight Principles related to the behaviour
of and decisions made by professional software engineers,
including practitioners, educators, managers, supervisors
and policy makers, as well as trainees and students of the
ACM: Association for Computing Machinery
IEEE: Institute of Electrical and Electronics Engineers