Conquering Complex and Changing Systems Object-Oriented

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

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. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6

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 Requirements: You have taken the prerequisite course CS2013 Software Engineering I or You have practical experience with maintaining or developing a large software system UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8

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

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11

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

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). 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 ). 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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13

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

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 1 Objects and relationships in problem domain 2 Object 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. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15

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

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20

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

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. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23

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. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24

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: Participating actor: Entry condition: Flow of events: Exit condition: Special requirements: PurchaseOneWayTicket Initialized by Traveler 1. Traveler stands in front of the ticket distributor at a station 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 6. Traveler holds a valid ticket and the change If the transaction is not completed after 1 minute of inactivity, TicketDistributor returns all inserted money UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26

Transaction Ticket Zone valid for results in Coin amount paid Balance Bill 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. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28

Updater Traveler Interface Local Tariff Central Tariff 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. UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32

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 UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33