CS350/550Software Engineering

Lecture 1

Class Work

• The main part of the class is a practical software engineering project, in teams of 3-5 people

• There will also be homeworks building on each other

• Class participation is essential

Class participation

• You will need to create documents and present them in class

• You will need to criticize other people’s presentations – You may need to build on them

• You will need to ask questions– Because software engineers must ask the

right questions of a customer

Assignment #1

• Think of ideas for the class project– More than one would be great

• It should be a useful idea (somebody actually can use it)

• It should be feasible in one semester– Not too big, not too small

• Due next Tuesday

• You will have to present them next week

Who are you?

• Good programmer in some language– Survey class for languages– You only wrote programs for your teacher to

grade, and then you forgot about it

• No experience in analyzing or designing systems– what you will probably do in the real world

• Want to learn technical aspects of designing complex systems

Objectives of Class

• Appreciate Software Engineering– Build complex systems that frequently change

• Understand how to produce a quality system in time, and deal with complexity and change

• Acquire technical knowledge

• Acquire managerial knowledge (a little)

Why Software Engineering

• Why don’t you just sit down and start typing a program?

• Software systems are so big and complex– And they can change

• You need these techniques to control the construction of software systems

• I want you to appreciate the fact that without some rigid process, this is impossible

Software is buggy

• Everybody knows stories of buggy software that can waste lots of money or even kill people

• If we design things carefully, we can have fewer bugs– Probably not no bugs

You will learn

• How to model a system– UML is a language that was created for this

purpose– Object-oriented vs functional decomposition

• What is the software lifecycle

• Component based techniques– Using design patterns for reuse

• How to run projects

Software Engineering Definition

• Collection of techniques (methodology) and tools that help with the production of – A high quality software system– With a given budget– Before a given deadline

while change occurs

Factors affecting quality

• Complexity– No single programmer can understand it– Fixing one bug causes another one

• Change– Each change increases complexity and

erodes the structure of a system– At some point, it is too expensive to make a

change, and system cannot perform its function

Why are software systems complex?

• The problem domain is difficult

• The development process is difficult to manage

• Software offers extreme flexibility

• Continuous systems are modeled discretely

Software Engineering

• Analysis: Understand problem and break it into pieces

• Synthesis: Put pieces back together

Dealing with complexity

1. Abstraction

2. Decomposition

3. Hierarchy

1. Abstraction

• Inherent human limitation to deal with complexity

• Chunking: Group collections of objects

• Ignore unessential details Models

2. Decomposition

• Divide and Conquer

• Functional Decomposition

• Object-oriented Decomposition

Functional Decomposition

• System decomposed into modules

• Each module is a function in application domain

• Modules can be decomposed into smaller modules

Object-oriented Decomposition

• System decomposed into classes (objects)

• Each class is a major abstraction in application domain

• Classes can be decomposed into smaller classes

Functional Decomposition

• Functionality is spread all over the system

• Maintainer must understand whole system to make a single change

• Consequence– Code is harder to understand– Complex code is harder to maintain– User interface can be awkward and non-

intuitive

3. Hierarchy

• We got abstractions and decomposition

• Another way to deal with complexity is to provide relationships between chunks

• One of the most important relationships is hierarchy– “part-of” hierarchy– “is-kind-of” hierarchy

Where are we?

• 3 ways to deal with complexity– Abstraction, decomposition, hierarchy

• Object-oriented decomposition is a good methodology– Depending on purpose of system, different

objects can be found

• How to do it right– Our approach is to start with a description of

the functionality, then proceed to object model

Software Lifecycle Definition

• Software Lifecycle:– Set of activities and their relationship to each

other to support the development of a software system

• Typical Lifecycle questions:– Which activities should I select?– What are the dependencies between them?– How should I schedule them?

Software Lifecycle Activities

• Requirements Elicitation

• Analysis

• System Design

• Object Design

• Implementation

• Testing

Requirements Elicitation

• Client and Developers define the purpose of the system

• Result is actors and use cases (model)

• Actor = role somebody or something plays

• Use Case = sequence of events that describes possible actions of user with system

Analysis

• Developer transforms use cases into an object model that completely describes the system

• Client should understand result of analysis

System Design

• Developers define design goals and decompose system into smaller subsystems

• Also select strategies for building system

• Client cannot understand this

Object Design

• Developer designs solution domain objects

• Result of object design is detailed object model with constraints and precise descriptions of each element

Implementation

• Developers transform solution domain model into source code

• Note that only this small part of development involves programming

Testing

• Developers find differences between the system and its model by executing the system with sample input data sets

• Unit testing, integration testing, system testing

Reusability

• A good software design solves a specific problem but is general enough to address future problems (changing requirements)

• Software engineers create reusable software, and reuse solutions others have created

• Using design patterns

Design Patterns

• A set of classes that provide a template solution to a recurring design problem

• On a higher level than data structures