Course Introduction
Lecture 1
Object Oriented Analysis and Design
K268 SENG2100
Pat Browne
http://www.comp.dit.ie/pbrowne/
Lecture 1
1
Email
For your email see:
www.studentwebmail.dit.ie
For webmail support see
http://support.dit.ie/ictsupport
The Support Centre can be contacted as follows:
Monday - Friday
9:00am - 12:30pm and 2:00pm - 5:00pm
Email : support@dit.ie
Phone : 402 3123
Also see class list at A114 first floor.
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.
Lecture 1
3
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 software testing strategies and
techniques and the application of testing
techniques to object oriented developed
systems.
Lecture 1
4
Learning Outcomes
• On completion of the course the student will:
– Understand the different approaches to object oriented
software development and methodologies supporting
them,
– Be able to use appropriate methods and techniques and
to perform an object oriented analysis and design for a
given case study,
– Know how to develop an appropriate testing strategy,
– Understand the test process and be able to develop test
cases,
– To appreciate the various tools available to assist with
object oriented analysis and design and testing.
Lecture 1
5
General Subject Matter
• This module enhances the knowledge of
system development approaches
developed in SENG1200 – Information
Systems. It 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 differences between structured and
object oriented design.
Lecture 1
6
Syllabus:
• Review of the software development
process: Life cycle models; Development
approaches; structure systems
development, object oriented
development, the strengths and
weaknesses of different approaches.
Lecture 1
7
Syllabus:
• Object Oriented Principles and Concepts:
objects, classes, instances, encapsulation,
abstraction, generalisation, specialisation,
aggregation, inheritance, polymorphism,
messaging.
• Object Oriented Life Cycle: Inception,
Elaboration, Construction, Transition,
UML, object oriented methodologies.
Lecture 1
8
Syllabus:
• 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,
normalisation, using a database with an
object oriented developed system.
Lecture 1
9
Syllabus:
• Examples of techniques required: class
diagrams, class responsibility cards
(CRC), business and interface classes, use
case diagrams, object sequence
diagrams, object collaboration diagrams,
state transition diagrams, component
deployment diagrams.
Lecture 1
10
Syllabus:
• Testing: validation and verification, the
review process, the testing process, test
strategies, V-model of testing, developing
test cases, unit testing, integration
testing, system testing, debugging,
regression testing, the management of
testing.
• Assignments
• One assignments 30%.
Lecture 1
11
Main Topics
• Designing Object-Oriented Software
• Rational Unified Process.
• Object Role Modelling.
• Unified Modeling Language (UML)
• Rational Rose and other case tools
• Object Constraint Language (OCL)
• UML for database design
• Design by contract
• A little Java
• Executable UML
Lecture 1
12
Main Texts
• Using UML: Software Engineering
with Objects and Components by
Stevens and Pooley, Addison
Wesley, ISBN 0-201-64860-1
• UML Distilled: Applying the
Standard Object Modeling Language
by Martin Fowler, Addison Wesley,
Lecture 1
13
Further reading
• UML for Database Design: Maiburg and
Maksimchuk, Addison Wesley, ISBN 0-20172163-5.
• Object Design: Rebecca Wirfs-Brock and Alan
McKean, Addison Wesley, ISBN 0-201-37943-0.
• The Object Constraint Language: Warmer and
Kleppe, Addison Wesley, ISBN 0-201-37940-6.
• The CRC Book: Bellin and Suchman Simone,
Addison Wesley, ISBN 0201895358.
• Software Design using Java 2: Lano, Fiadeiro,
Andrade, Palgrave 1-4039-0230-5
Lecture 1
14
Further reading
• Information modelling and relational
databases: by Terry Halpin, Morgan
Kaufman ISBN.
• Model Driven Architecture with Executable
UML: Raistrick, Francis, Wright, Carter,
Wilkie. Cambridge University Press.
• 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