1 / 31

CS350/550 Software Engineering

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.

willis
Download Presentation

CS350/550 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS350/550Software Engineering Lecture 1

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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)

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. Software Engineering • Analysis: Understand problem and break it into pieces • Synthesis: Put pieces back together

  14. Dealing with complexity • Abstraction • Decomposition • Hierarchy

  15. 1. Abstraction • Inherent human limitation to deal with complexity • Chunking: Group collections of objects • Ignore unessential details  Models

  16. 2. Decomposition • Divide and Conquer • Functional Decomposition • Object-oriented Decomposition

  17. Functional Decomposition • System decomposed into modules • Each module is a function in application domain • Modules can be decomposed into smaller modules

  18. Object-oriented Decomposition • System decomposed into classes (objects) • Each class is a major abstraction in application domain • Classes can be decomposed into smaller classes

  19. 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

  20. 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

  21. 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

  22. 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?

  23. Software Lifecycle Activities • Requirements Elicitation • Analysis • System Design • Object Design • Implementation • Testing

  24. 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

  25. Analysis • Developer transforms use cases into an object model that completely describes the system • Client should understand result of analysis

  26. System Design • Developers define design goals and decompose system into smaller subsystems • Also select strategies for building system • Client cannot understand this

  27. Object Design • Developer designs solution domain objects • Result of object design is detailed object model with constraints and precise descriptions of each element

  28. Implementation • Developers transform solution domain model into source code • Note that only this small part of development involves programming

  29. 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

  30. 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

  31. Design Patterns • A set of classes that provide a template solution to a recurring design problem • On a higher level than data structures

More Related