Lecture 1
Course Introduction
DT249 Software Engineering 2
Pat Browne
Patrick.Browne@comp.dit.ie
http://www.comp.dit.ie/pbrowne/
Lecture 1
1
Tech Support
For your tech. support see:
http://support.dit.ie/ictsupport
http://www.comp.dit.ie/techsupport
If you are having any technical
difficulties logging into the PCs in
the labs please contact
student_tech@comp.dit.ie
Lecture 1
2
Accounts
• Your student login is :
Username: your name
Password: Student number ( Lower case
letter )
Domain:
Student.
Class Disk is:
StudentDistrib$ on 'lugh' (P:)
The lectures are at:….
Lecture 1
3
Description
• This module focuses on an engineering
approach to systems development. The
module studies systems analysis and design
in the context of object oriented
development. On successful completion of
the course students are expected to be able
to apply object oriented analysis and design
techniques. Students are also expected to
appreciate and understand the different
approaches to object oriented design.
Lecture 1
4
Course Aims
• To provide the students with an understanding and
appreciation of the role of systems analysis and
design, building and testing within an object
oriented system development life cycle approach.
To teach the different techniques used in object
oriented analysis and design. To teach testing
strategies and techniques and the application of
testing techniques to object oriented systems. To
provide the student with a theoretical knowledge
of the principles, and processes and techniques
involved in building high quality software
systems.
Lecture 1
5
Learning Outcomes
• On successful completion of this module, the student will be
able to:
• Identify and critically evaluate the different approaches to
object oriented software development.
• Use appropriate methods and techniques to perform an object
oriented analysis and design for a given case study.
• Evaluate and develop appropriate testing strategies.
Implement a test process and develop test cases.
• Evaluate and use the various tools available to the software
engineer.
• Use advanced software architectures, patterns, components
and frameworks.
• Use the appropriate theory to address practical software
problems.
Lecture 1
6
Syllabus:
• Review of the software development
process: Life cycle models; development
approaches; object oriented development, the
strengths and weaknesses of different
approaches.
• Object oriented principles and concepts:
objects, classes, instances, encapsulation,
abstraction, generalisation, specialisation,
aggregation, inheritance, polymorphism,
messaging.
Lecture 1
7
Syllabus:
• Object oriented life cycle: Inception,
elaboration, construction, transition, UML,
object oriented methodologies.
Analysis and design techniques: Requirements
gathering, feasibility studies, functional and
non-functional requirements, fact-finding
techniques. Techniques for modelling classes
and transactions. Notation used. File and
database organisations and structure, using a
database with an object oriented developed
system.
Lecture 1
8
Syllabus:
• Review of object orientation: Basic object
concepts including: encapsulation, inheritance,
abstraction, objects instances, classes,
polymorphism messages and communicating
agents, OO language features.
Lecture 1
9
Syllabus:
• Examples of object oriented techniques
required: further study of the UML including:
class diagrams, business and interface classes,
use case diagrams, object sequence diagrams,
object collaboration diagrams, state transition
diagrams, component deployment diagrams,
Object Constraint Language (OCL), action
semantics.
Lecture 1
10
Syllabus:
• Advanced object oriented concepts: refactoring, responsibility driven design, use
case driven design, design by contract,
coordination contracts, patterns, architectures,
frameworks, subsystems, components.
• Testing: validation and verification, the
review process, the testing process, test
strategies, system testing, model testing,
testing tools, the management of testing.
Lecture 1
11
Main Topics
• Responsibility Driven Design.
• Use case driven design.
• Rational Unified Process.
• The Unified Modelling Language (UML)
• Argo and other case tools
• Object Constraint Language (OCL)
• Time in systems.
• Design by contract
• Executable UML
Lecture 1
12
Main Texts
• Essential Reading:
• Practical Object-Oriented Design with UML, Mark
Priestly(2003), McGraw Hill, ISBN: 0077103939.
• Supplemental Reading:
• UML Distilled 3rd Ed. Fowler (2004), Addison
Wesley, ISBN:0-321-19368-7
• Model Driven Architecture with Executable UML,
Raistrick et al (2004)., Cambridge, ISBN
0521537711
• Object-Oriented Methods: Principles and Practice
(3rd Edition) by Ian Graham (2000), AddisonWesley, ISBN: 0-201-61913-X.
• The Object Constraint Language: Getting Your
Models Ready for MDA, 2/E, by, Warmer and
Lecture 1
Kleppe. Addison Wesley,
ISBN: 0-321-17936-6
13
Further reading
• UML for Database Design: Maiburg and
Maksimchuk, Addison Wesley, ISBN 0201-72163-5.
• Object Design: Rebecca Wirfs-Brock and
Alan McKean, Addison Wesley, ISBN 0201-37943-0.
• The CRC Book: Bellin and Suchman
Simone, Addison Wesley, ISBN
0201895358.
• Software Design using Java 2: Lano,
Fiadeiro, Andrade, Palgrave 1-4039-02305
Lecture 1
14
Further reading
• Information modelling and relational
databases: by Terry Halpin, Morgan
Kaufman ISBN.
• Designing Object-Oriented Software:
Wirfs-Broock, Wilkerson and Wiener.
Prentice-Hall
Lecture 1
15
Traditional System Lifecycle
and
Iterative Approaches
Traditional Systems Lifecycle
• PROJECT DEFINITION
• SYSTEM STUDY
• DESIGN
• PROGRAMMING
• INSTALLATION
• POSTINSTALLATION REVIEW
Traditional Systems Lifecycle
•
PROJECT DEFINITION: Is there a problem? Can it be solved with a
project? Makes a preliminary study to determine why a new system project is
required and to state project objectives. The output of this phase is a project
plan (or project proposal)
• SYSTEM STUDY: Analyze problems in existing systems; define objectives
evaluate alternatives. Determines requirements for the proposed new system.
Using these findings, the study phase performs a cost-benefit analysis to
determine if proposed system solutions are feasible. The output of this phase is
a detailed system proposal.
Traditional Systems Lifecycle
• DESIGN: Logical & physical specifications for systems solution. Produces the
blueprint of specifications for the new system's inputs, outputs, processing,
database, procedures and controls.
• PROGRAMMING: Develop software code. : Translates the design
specifications into software for the computer.
• INSTALLATION: Test the programs, train the staff, convert to new system.
Usually includes a systems acceptance test. An acceptance test consists of a set
of performance criteria which the system must pass before it is accepted by
the user (or organization) e.g. the system must be able to process 2000
customer transactions per hour.
• POSTINSTALLATION REVIEW :The system is operational; users and
technical specialists conduct a post-implementation audit. The system is
maintained to meet new requirements or processing efficiency On-going
evaluation, modifications for improvement to meet new requirements. Did the
system produce the expected benefits?
Traditional Systems Lifecycle
•
The advantages of using TSL for building information systems are:
•
It is highly structured, well defined steps/roles.
•
It has a rigorous and formal approach to requirements and
specifications and tight controls over the system building process.
•
It is appropriate for building large transaction processing and
management information systems and for building complex technical
systems.
Traditional Systems Lifecycle
•
The disadvantages of this method are:
 It is very costly and time-consuming.
 It is inflexible and discourages change even
though requirements will change during the
project due to the long time this method
requires.
• It is ill-suited to decision-oriented applications
which can be rather unstructured and for which
requirements are difficult to define.
Traditional Systems Lifecycle
•
The disadvantages of this method are:
 It assumes that each stage is completed
before the next stage starts, there is no
overlap or iteration.
TLC usually uses structure
methods
• In general the traditional system life cycle
structured methods use structured system
development, which are top down, step by
step, each step builds on previous.
Structured Systems Analysis defines system
inputs, processes, outputs partitions system
into subsystems or modules. It uses logical,
graphical model of information flow using
data flow diagrams and textual descriptions.
TLC usually uses structure
methods
• The main tools of Structured Systems Analysis are:
• DATA FLOW DIAGRAM: Graphical display of component
processes, flow of data. Enables users or developers to view
proposed system at any level of detail.
• DATA DICTIONARY: Controlled definitions of descriptions of all
data, such as variable names & types of data. DD are often
implemented in software, particularly for database development.
• PROCESS SPECIFICATIONS: Describes logic of processes at
module level. These are often textual descriptions
• Structured Systems Analysis during the analysis phase of the
system development life cycle. It is used to build a logical model
of the system using the tools described above.
TLC usually uses structure
methods
• Prototyping can be included in either approach to
clarify requirements, however it is more closely
integrated in OO approaches. Prototyping is the
process of building experimental system to
demonstrate, evaluate approach; users refine needs
Prototype: preliminary working version of information
system for demonstration, evaluation purposes
Iterative process. Steps: identify user’s requirements;
Develop prototype; Use prototype; Revise & enhance
prototype; best for design of end-user interface: can
show how end-user interacts with system. Managing
prototyping has its own problems, when is prototype
complete?
TLC & Structure Methods
• Structured methodologies recognise the need to spend
sufficient time during the early stages to ensure a clear and
comprehensive understanding of the current system, its
problems and requirements.
• This is essentially the task of enabling the analyst to
understand the system under consideration from the point
of view of the managers, system users, customers and
technical support. Analysis begins with the user providing
a brief report of the problems and requirements as they see
them in their system. The analyst will gather information
about the personnel and facts that they provide and build a
clear specification of the system, its objectives and its
requirements