Chapter 1, Introduction to Software Engineering

Con

quer

ing

Com

plex

and

Cha

ngin

g S

yste

ms

Ob

ject

-Ori

ente

d S

oftw

are

En

gin

eeri

ng

Chapter 1,Introduction to Software Engineering

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.


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


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


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


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


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

http://www.cs.unb.ca/profs/nickerson/courses/CS3013ci.htm


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


BidderBidderAuction a Textbook

SellerSellerNotification of Sale

Add User

Internet

AdministratorAdministrator

Add Textbook

Basic Software Architecture for e-Textbook Project


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


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


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.

mailto:[email protected]




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

http://stdsbbs.ieee.org/groups/610/p610home.html

http://www.pcwebopaedia.com/webreference/software_engineering.htm

Activities

Modeling Problem-solving Knowledge AcquisitionRationale 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.



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


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


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


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


Figure 1-1. Software engineering concepts, depicted as a UML class diagram (OMG, 1998).

consumes

Activity

WorkProduct ResourcesTask

Equipment

Time

Participant

Document

Model

System

is produced by *

*

**

Project


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.


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


Notations, Methods, and MethodologiesNotation

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.


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


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


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

Bill

Zone

Balance

TicketTransaction


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


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 Interface Updater

Local Tariff Central Tariff


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


Testing find differences between the system and its models

by execution with sample dataUnit 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


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


Project managementoversight 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 teamsmonitor the status of the project intervene when deviations occur

Software life CycleA general model of the software development

process

Chapter 1, Introduction to Software Engineering

Documents