CS350/550 Software 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