1. Lecture 11 Lecture 1 Course Introduction DT249 Software Engineering 2 Pat Browne Patrick.Browne@comp.dit.ie http://www.comp.dit.ie/pbrowne/

2. Lecture 12 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

3. Lecture 13 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. Lecture 14 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. Lecture 15 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. Lecture 16 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. Lecture 17 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. Lecture 18 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. Lecture 19 Syllabus: Review of object orientation: Basic object concepts including: encapsulation, inheritance, abstraction, objects instances, classes, polymorphism messages and communicating agents, OO language features.

10. Lecture 110 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. Lecture 111 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. Lecture 112 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. Lecture 113 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), 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. Lecture 114 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. Lecture 115 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 Lifecycle and Iterative Approaches

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

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