1. COP 4009 1 st Lecture August 29, 2005 COP 4009 Component-Based Software Engineering Fall 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Teaching/COP-4009-Fall-2005/index.html Introduction to Software Engineering

2. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 2 Acknowledgements  Dr. George T. Heineman –This course is based on the “CS 509 Design of Software Systems - Spring 2005” by Dr. Heineman with some adjustments to become appropriate for undergraduate students. Dr. Heineman has generously offered his course material (including the slides) and his help during preparation of this course. I am very grateful to him. –The original slides and the course material can be found at:  http://www.cs.wpi.edu/~heineman/html/teaching_/CS509/index.html  Dr. William Councill and other authors of the main textbook  Dr. Clemens Szyperski  Drs. Betty Cheng, Peter Clarke, Bernd Bruegge, and Allen Dutoit

3. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 3 Agenda  Course Introduction  Introduction to Software Engineering

4. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 4 Course Home Page  Web Page: –http://www.cs.fiu.edu/~sadjadi/Teaching/COP-4009-Fall- 2005/index.htmlhttp://www.cs.fiu.edu/~sadjadi/Teaching/COP-4009-Fall- 2005/index.html  General Information: –Office Hours: ECS 212C, M/W 17:00 – 18:00 (or by appointment).  Important Notes: –Please read your textbook before coming to class. –Pay attention to the reading assignments.

5. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 5 Prerequisite and References  Prerequisite –COP 3530COP 3530 –Knowledge of a recursive high-level language and data structures. –Familiarity with at least two high-level programming languages (e.g., C++ and Java) and the foundations of computing. –The knowledge of an undergraduate course in software engineering (e.g., CEN-4010) is desirable, but not required.  Required Text –Component-Based Software Engineering: Putting the Pieces Together, George T. Heineman and William T. Councill, Editors, Addison-Wesley, ISBN 0201704854.Component-Based Software Engineering: Putting the Pieces Together  Other reading material –Class notes.

6. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 6 Grading  Grading Policy –Class Attendance and Participation: 10%. –Writing Assignments: 20%.Writing Assignments –Term Project: 50%.  10% Interfaces and Design (HW1)  10% Testing Plan and Recorded Results (HW2)  10% Deployment and Documentation (HW2, HW3)  20% Final Implementation, Demo, and Presentation (HW3) –Final Exam: 20%.  Grading Standard –The grading scale is: A: 90 | A-:87 | B+:84 | B: 80 | B-:77 | C+:74 | C: 70 | C-:65 | D+:60 | D: 55 | D-:50. –Note that a C- is not a C.  Attendance –Attendance will be taken during each class meeting.

7. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 7 Project Objective and Grading  Objective –The primary objective of the projects is to give you practice in applying the phases of the component-based software development.  Grading Scheme –The grade for the projects is based on three deliverables for the three homeworks and the last class presentation. –Project grade represents 50% of the final grade. –Each student in a project team will be evaluated separately and may receive a different grade.

8. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 8 Agenda  Course Introduction  Introduction to Software Engineering

9. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 9 What is Software Engineering? (1)  Systematic approach for developing software  “Methods and techniques to develop and maintain quality software to solve problems.” [Pfleeger, 1990]  “Study of the principles and methodologies for developing and maintaining software systems.” [Zelkowitz, 1978]  “Software engineering is an engineering discipline which is concerned with all aspects of software production.” [Sommerville]

10. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 10 What is Software Engineering? (2)  “Practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them.” [Boehm, 1976]  “Deals with establishment of sound engineering principles and methods in order to economically obtain software that is reliable and works on real machines.” [Bauer, 1972]  “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”

11. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 11 Questions Addressed by SE  How do we ensure the quality of the software that we produce?  How do we meet growing demand and still maintain budget control?  How do we avoid disastrous time delays?

12. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 12 Why apply SE to Systems?  Provide an understandable process for system development.  Develop systems and software that are maintainable and easily changed.  Develop robust software and system.  Allow the process of creating computing-based systems to be repeatable and manageable.

13. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 13 How can we apply SE?  Modeling  Problem-solving  Knowledge acquisition  Rationale-driven

14. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 14 Modeling  “A model is an abstract representation of a system that enables us to answer questions about the system.”  Why use a model? –Systems are too large, too small, too complicated, or too expensive, to experience firsthand.  Models allow –Visualization –Comprehension

15. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 15 Problem Solving  Steps in problem solving: –Formulate the problem –Analyze the problem –Search for solutions –Decide on the appropriate solution –Specify the solution

16. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 16 Knowledge Acquisition  Domain specific knowledge.  New knowledge can affect the development process.  Knowledge acquisition is nonlinear – affects several of the software development models.  Risk assessment is important.

17. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 17 Rationale Management  Assumptions made about systems change constantly.  Application domain models stabilize, solution domain models are in constant flux. –Changes to the solution models due to:  design and implementation faults  new technology  Need to understand the context in which each design decision was made.

18. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 18 Course Outcomes  Familiarity with the Component-Based Software Engineering (CBSE) Life Cycle.  Familiarity with the object-oriented analysis, design and implementation.  Familiarity with the use of UML diagrams in CBSE.  Familiarity with the analysis, design, implementation and testing techniques in CBSE.  Familiarity with product lines.  Familiarity with software documentation in CBSE.  Familiarity with working in a large software development team.  Familiarity with technical writing.

19. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 19 Agenda  Course Introduction  Introduction to Software Engineering

20. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 20 Our Intention Requirements Software

21. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 21 Our plan of attack Requirements Analysis Design Implementation Testing Delivery and Installation

22. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 22 How it often goes Requirements Analysis D E L A Y Vaporware

23. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 23 Inherent Problems  Requirements are complex –The client does not know the functional requirements in advance.  Requirements may be changing –Technology enablers introduce new possibilities to deal with nonfunctional requirements.  Frequent changes are difficult to manage –Identifying milestones and cost estimation are difficult.  There is more than one software system –Backward compatible with existing systems

24. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 24 Terminology (1)  participants – all persons involved in a project. e.g., developers, project manager, client, end users.  role – associated with a set of tasks assigned to a participant.  system – underlying reality.  model – abstraction of the reality.  work product – an artifact produced during development.

25. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 25 Terminology (2)  deliverable – work product for client.  activity – a set of tasks performed toward a specific purpose.  milestone – end-point of a software process activity.  task – an atomic unit of work that can be managed and that consumes resources.  goal – high-level principle used to guide the project.

26. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 26 Terminology (3)  functional requirement – an area of functionality that the system must have.  nonfunctional requirement – a constraint on the system.  notation – is a graphical or textual set of rules representing a model (e.g., UML)  method – a repeatable technique for solving a specific problem e.g. sorting algorithm  methodology – a collection of methods for solving a class of problems (e.g., Unified Software Development Process).

27. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 27 Software Processes 1. Specification –requirements elicitation and analysis. 2. Development –systems design, detailed design (OO design), implementation. 3. Validation –validating system against requirements (testing). 4. Evolution –meet changing customer needs and error correction (maintenance).

28. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 28 1. Software Specification (1)  Functionality of the software and constraints (non- functional requirements) on its operation must be defined.  Involves: –Requirements elicitation –The client and developers define the purpose of the system. –Output is a description of the system in terms of actors and uses cases. –Actors include roles such as end users and other computers the system needs.

29. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 29 1. Software Specification (2)  Uses cases are general sequences of events that describe all possible actions between actor and the system for a given piece of functionality. Analysis  Objective: produce a model of the system that is correct, complete, consistent, unambiguous, realistic, and verifiable.  Developers transform the use cases into an object model that completely describes the system.  Model is checked for ambiguities and inconsistencies.  Output: Object model annotated with attributes, operations, and associations.

30. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 30 2. Software Development (1)  Producing the software that meets the specification. System Design  Goals of the project are defined.  System decomposed into smaller subsystems (architectural model).  Strategies to build system identified –HW and SW platform, data management, control flow, and security.  Output: model describing subsystem decomposition and system strategies.

31. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 31 2. Software Development (2) Object Design  Bridges the gap between analysis model and the strategies identified in the system design. Includes: –Describing object and subsystem interfaces –Selecting off–the-shelf components –Restructure object model to attain design goals  e.g., extensibility, understandability, and required performance.  Output: detailed object model annotated with constraints and supporting documentation. Implementation  Translation of the object model into source code.  No general process followed.  There are tools to assists the programmer such as CASE tools.

32. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 32 Software Development Activities Problem Domain Implementation Domain Requirements Analysis What is the problem? System Design What is the solution? Object Design What is the solution in a specific context? Implementation How is the solution constructed?

33. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 33 3. Software Validation (1)  Ensures the software does what the customer want.  The software conforms to its specification and meets the expectations of the customer. Validation: ‘Are we building the right product?’ Ensures the software meets the expectations of the customer. Verification: ‘Are we building the product right?’ Ensures the software conforms to the specification.

34. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 34 3. Software Validation (2)  Techniques –Software inspections (static):  Analyze and check system representations (e.g., requirements documents, design diagrams, and program source code). –Software testing (dynamic):  Executing an implementation of the software with test data and examining the outputs against expected results.  V&V process establishes the existence of defects.  Debugging is a process that locates and corrects these defects.

35. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 35 4. Software Evolution  Software must evolve to meet the customer needs.  Software maintenance is the process of changing a system after it has been delivered.  Reasons for maintenance –To repair faults. –To adapt the software to a different operating environment. –To add to or modify system’s functionality.

36. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 36 Attributes of Good Software  Maintainability –Ease of changing the software to meets the changing needs of the customer.  Dependability –Reliability, security and safety.  Efficiency –Responsiveness, processing time, and memory usage.  Usability –Appropriate user interface and adequate documentation.

37. First Lecture on August 29, 2005COP-4009: Component-Based Software Engineering 37 Next Week Assignments  Reading –Chapter 3: Concepts & Principles –Class project document (I will post it later and send an email afterwards).  Writing Assignment – Assigned two week from now.  Group Projects –Groups will be fully assigned during the next class. –Get familiar with each other and try to come up with a strong group ahead of time.