Lecture 1 Course Introduction

1
Lecture 1Course Introduction

• DT249 Software Engineering 2
• Pat Browne
• Patrick.Browne_at_comp.dit.ie
• http//www.comp.dit.ie/pbrowne/

2
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_at_comp.dit.ie

3
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.

4
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.

5
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.

6
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.

7
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.

8
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.

9
Syllabus

• Review of object orientation Basic object
  concepts including encapsulation, inheritance,
  abstraction, objects instances, classes,
  polymorphism messages and communicating agents,
  OO language features.

10
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.

11
Syllabus

• Advanced object oriented concepts re-factoring,
  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.

12
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

13
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, ISBN0-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),
  Addison-Wesley, ISBN 0-201-61913-X.
• The Object Constraint Language Getting Your
  Models Ready for MDA, 2/E, by, Warmer and Kleppe.
  Addison Wesley, ISBN 0-321-17936-6

14
Further reading

• UML for Database Design Maiburg and Maksimchuk,
  Addison Wesley, ISBN 0-201-72163-5.
• Object Design Rebecca Wirfs-Brock and Alan
  McKean, Addison Wesley, ISBN 0-201-37943-0.
• The CRC Book Bellin and Suchman Simone, Addison
  Wesley, ISBN 0201895358.
• Software Design using Java 2 Lano, Fiadeiro,
  Andrade, Palgrave 1-4039-0230-5

15
Further reading

• Information modelling and relational databases
  by Terry Halpin, Morgan Kaufman ISBN.
• Designing Object-Oriented Software Wirfs-Broock,
  Wilkerson and Wiener. Prentice-Hall

16
Traditional System LifecycleandIterative
Approaches
17
(No Transcript)
18
Traditional Systems Lifecycle

• PROJECT DEFINITION
• SYSTEM STUDY
• DESIGN
• PROGRAMMING
• INSTALLATION
• POSTINSTALLATION REVIEW

19
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.

20
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?

21
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.

22
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.

23
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.

24
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.

25
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.

26
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
  users 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?

27
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