1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 1, Introduction to Software Engineering

2. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Course format  A Single Semester Course  Lectures: Theoretical foundations and background  Project: Learn how to apply them in practice  Lectures and Project work are interleaved  Labs and Assignments complement lectures and the team project  A Single Project Course  Everybody is working on the same project  Cheating Rule for CS3013  You cheat if you do not acknowledge the contribution made by others.

3. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Lecture Overview  Introduction  Objectives of Course  Project  e-Textbook System Problem Statement  Top Level Design  Syllabus  Introduction of People  Administrative Matters  Software Engineering Overview  A UML class model of software engineering  Activities  Ticket distributor example

4. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Objectives of this course  Acquire technical knowledge  Understand difference between program and software product  Be able to reconstruct the analysis and design of an existing software system  Be able to design and implement a subsystem that will be part of a larger system  Acquire managerial knowledge  produce a high quality software system within budget & time  while dealing with complexity and change

5. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Emphasis is on team-work  Participate in collaborative design  Work as a member of a project team, assuming various roles  Create and follow a project and test plan  Create the full range of documents associated with a software product  Complete a project on time

6. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 How can we accomplish this?  Course Project  e-Textbook: online used textbook auction web site  The 4 R’s:  Real Problem: University students want an easy way to find used textbooks to buy as well as a way to auction off their own used textbooks (that they no longer need)  Real Client: You  Real Data: All textbooks purchased for courses at UNB and Saint Thomas  Real Deadline: April 12, 2001

7. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Assumptions and Requirements for this Class  Assumption:  You are proficient in a programming language (Java preferred), but have no experience in analysis or design of a system  You have access to a Web Browser  Course Homepage: http://www.cs.unb.ca/profs/nickerson/courses/CS3013ci.htm http://www.cs.unb.ca/profs/nickerson/courses/CS3013ci.htm  Requirements:  You have taken the prerequisite course CS2013 Software Engineering I  or  You have practical experience with maintaining or developing a large software system

8. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Project Goals  Attempt to produce a web site with the e-Textbook auction site functionality  Implementation of three major processes:  Handling registration of used textbooks for auction.  Carrying out (in a secure fashion) the bidding process for textbooks.  Keeping track of all registered users of the e-Textbook site.  Demonstration of a conceptual prototype

9. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Bidder Auction a Textbook Seller Notification of Sale Add User Internet Administrator Add Textbook Basic Software Architecture for e-Textbook Project

10. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Teams  e-Textbook will be developed in a team-based approach  Each team will do the same e-Textbook project  You will be member of one team of four to six people  Teams will normally meet at least once per week during the lab session  Team selection is done by project management and will be announced in class, Tuesday, January 16.  Teams will be formed so that all team members have common lab times  If you wish to be part of the same team, please assign one person to send me a suggested team list by e-mail

11. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Acceptance Milestone  The acceptance criteria are established in a dialog with the client during the requirements analysis phase  The e-Textbook system will be delivered with the following artifacts on a CD-ROM  Requirements Analysis Document  System Design Document  Object Design Document  Test Manual  Source Code Depot

12. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 If you need help  Questions about Passwords, Logging into the network, Accessing the Home page:  UNB Computing Services help desk (helpdesk@unb.ca), 453-5199, room HD-11  Questions about getting into the ITD414 lab  Troy Cabel (tcabel@unb.ca), 452-6162, room GE-118tcabel@unb.ca  Jeff Geddes (jgeddes@unb.ca), 452-6102, room GE-119jgeddes@unb.ca  Questions about the Course  Brad Nickerson (bgn@unb.ca), 458-7278, room ITC304bgn@unb.ca  office hours Wednesdays, 11:30 a.m. t o 12:30, Fridays 3:30 to 5:00 p.m.

13. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Software Engineering  Software systems are complex  Impossible to understand by a single person  Many projects are never finished: "vaporware"  The problem is arbitrary complexity  Definitions  The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines (Bauer, F. L. Software Engineering. Information Processing 71., 1972).  Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1) (IEEE Std 610-1990).IEEE Std 610-1990  Software engineering is the computer science discipline concerned with developing large applications. Software engineering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting (WebReference Webopaedia ).WebReference Webopaedia  Our definition:  Software Engineering means the construction of quality software with a limited budget and a given deadline in the context of constant change  Emphasis is on both, on software and on engineering

14. Activities  Modeling  Problem-solving  Knowledge Acquisition  Rationale Driven  Helps software engineers understand implications of change

15. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Modeling  Focusing relevant details at each development stage  A model is an abstract representation of a system for answering questions about the system  Real world system: a set of phenomena  Problem model: a set of interdependent concepts describing those aspects of the real world relevant to the problem under consideration.  Model of problem domain vs. model of solution domain  OO methods: Problem D. model + Solution D. model 1Objects and relationships in problem domain 2Object and relationships in solution domain (extension from 1)  Software Development: identify and describe a system as a set of models to address the end user’s problem.

16. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16

17. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Problem Solving  Software engineering is an engineering activity  Rely on empirical methods to evaluate the benefits of different alternatives represented as models  The engineering method: 1. Formulate the problem (requirements elicitation and 2. Analyze the problem analysis) 3. Search for solutions (system design and 4. Decide on the appropriate solution object design) 5. Specify the solution (implementation)  Activities: experimentation, pattern reuse, incremental evolution, reviews of problem and solution models

18. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Knowledge Acquisition  In modeling application and solution domains  Data collection  Information organization  Knowledge formalization  Non-linear knowledge acquisition  Single piece of data can invalidate complete models  Linear software development process  Waterfall model  Non-linear software process  Risk-based development –develop higher risks first  Issue-based development –develop all issues in parallel

19. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Rationale Driven  Rationale of the system  The context and rationale in which each design decision was made  To be captured and understood by software engineer  Represents a set of issue models with larger amount of information than the solution models  Not explicit (without explicitly evaluating different alternatives)  Enables software engineers to understand the implication of a proposed change when revising a decision.  Rationale management

20. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Software Engineering Concepts  Participants and Roles  Role  a set of responsibilities  associated with a set of tasks  assigned to a participant  typical roles: end user, client, developer, project manager  Participant  any persons involved in the project  plays certain role(s)  Systems and Models  System: the underlying reality  example: ticket distributor for a train  Model: any abstraction of the reality  example: requirement, analysis, design, implementation models

21. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Figure 1-1. Software engineering concepts, depicted as a UML class diagram (OMG, 1998). consumes Activity WorkProductResourcesTask Equipment Time ParticipantDocument Model System is produced by * * ** Project

22. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22  Work Products  Artifact produced during development  Internal work product  for the project’s internal consumption  any artifact not in the contract or requested by the client  example: test plan  Deliverable  for the client  defined prior to the start of the project and specified in the contract.  Activities, Tasks, and Resources  Activity or phases: a set of tasks for a special purpose such as requirement elicitation  Task: an atomic unit of work in terms of management, to be assigned to a developer.  Resources: assets to be used to accomplish work.

23. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23  Goals, Requirements and Constraints  Goals  a high level principle to guide the project  define the attributes of the system that are important  primary goal and other goals of a project  conflicting goals  Functional requirements  area of functionality that the system must support (e.g. provide the user with a paper copy of the ticketing information)  Nonfunctional requirements  operation of the system (e.g. response back to user in less than one second 99% of the time)  examples: performance, reliability, security  Constraints  interface with an existing computer system

24. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24  Notations, Methods, and Methodologies  Notation  a graphical or textual set of rules for representing a model  Example: UML for OO modeling, Z for system specification using sets  Method  A repeatable technique for solving a specific problem  Example: sorting algorithm, version control  Methodology  a collection of methods for solving a class of problems  decompose software process into activities  examples: Unified software development process, Object Modeling Technique (OMT), Catalysis.

25. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Software Engineering Development Activities  Requirement elicitation (Client and Developer)  The client and developers define the purpose of the system  Result: description of actors and use cases for functional requirement  Example Use case name:PurchaseOneWayTicket Participating actor:Initialized by Traveler Entry condition:1. Traveler stands in front of the ticket distributor at a station Flow of events:2. Traveler selects the source and destination stations 3. TicketDistributor display the price of the ticket 4. Traveler inserts sufficient money 5. TicketDistributor issues the ticket and returns change Exit condition:6. Traveler holds a valid ticket and the change Special requirements:If the transaction is not completed after 1 minute of inactivity, TicketDistributor returns all inserted money

26. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26  Nonfunctional requirements  Reliability: The ticket distributor should be available to traveler at least 95% of the time  Performance: The ticket distributor should provide feedback to the traveler within a second after the transaction has been selected.  Analysis (Developer)  produce a model of the system that is correct, complete, consistent, unambiguous, realistic, and verifiable.  transform the use cases into an object model that completely describes the system  discover ambiguities and inconsistencies

27. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 Figure 1-3. An object model for the ticket distributor (UML class diagram). In the PurchaseOneWayTicket use case, a Traveler initiates a transaction that will result in a Ticket. A Ticket is valid only for a specified Zone. During the Transaction, the system tracks the Balance due by counting the Coins and Bills inserted. results in valid for amount paid Coin BillZoneBalanceTicketTransaction

28. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28  System Design (Developer)  define the design goals  decompose the system into smaller subsystems that can be realized by individual teams.  Select strategies for building the system  results:  strategy descriptions  subsystem decomposition  deployment diagram  Object Design (developer)  define custom objects to bridge the gap between the analysis model and the system design platform  Implementation  translate the object model into source code

29. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Figure 1-4. A subsystem decomposition for the TicketDistributor (UML class diagram, folders represent subsystems, dashed lines represent dependencies). The Traveler Interface subsystem is responsible for collecting input from the Traveler and providing feedback (e.g., display ticket price, returning change). The Local Tariff subsystem computes the price of different tickets based on a local database. The Central Tariff subsystem, located on a central computer, maintains a reference copy of the tariff database. An Updater subsystem is responsible for updating the local databases at each TicketDistributor through a network when ticket prices change. Traveler InterfaceUpdaterLocal TariffCentral Tariff

30. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Managing Software Development  Communication  exchange models and documents  report the status of work products  provide feedback on the quality of work products  raise and negotiate issues  communicate decisions  common convention and tool based  Rationale management  the problem addressed  alternatives considered  evaluation criteria used  debate, consensus, and decision  difficulty: update and maintenance

31. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31  Testing  find differences between the system and its models by execution with sample data  Unit testing  compare the object design model with each object and subsystem  Integration testing  compare the integrated subsystems with the system design  System testing  compare the system with the requirement model by running typical and exception cases

32. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32  Software Configuration Management  the process that monitors and controls changes in work products  Example changes  requirement changes –client new feature –development new/improved understanding  platform changes –new technology available  system changes –fault and repair  enable developer to track changes  configuration items to be individually revised  versions for evolution of configuration items and roll back  enable developers to control change  define baselines  assess and approve increments from the baselines

33. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33  Project management  oversight activities to ensure  the delivery of a high-quality system on time and within budget  plan and budget the project during negotiation with the client  hire developers and organize them into teams  monitor the status of the project  intervene when deviations occur  Software life Cycle  A general model of the software development process