Course IntroductionLecture 1 Object Oriented Analysis and Design K268 SENG2100 Pat Browne http://www.comp.dit.ie/pbrowne/ Lecture 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 : email@example.com 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 firstname.lastname@example.org Lecture 1
Accounts • Your student login is : Username: your name Password: Student number ( Lower case letter ) Domain: Student. Lecture 1
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
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
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
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
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
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
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
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
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
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
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 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
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
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