View
217
Download
0
Tags:
Embed Size (px)
Citation preview
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