310 likes | 464 Views
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.
E N D
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 • Abstraction • Decomposition • 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