INTRODUCTION TO SOFTWARE ENGINEERING

1. • Authors: William M. Buchanan Joseph Picone • Contact Information: ECE 4512 / 4522 Box 9571 Mississippi State University Mississippi State, Mississippi 39762 Tel: 662-325-3149 Fax: 662-325-2298 INTRODUCTION TO SOFTWARE ENGINEERING DESIGN I • Email: {buchanan, picone}@ece.msstate.edu

2. INTRODUCTION THE EUREKA STORY

3. INTRODUCTION SENIOR DESIGN DELIVERABLES • Four homework assignments: • Physical Model: drawings showing externally visible objects • Use Cases: two use cases representing correct (“sunny”) and problematic (“rainy”) behavior • Information Model: a diagram of how externally visible objects interact with one another • Process Model: a detailed state machine showing how one of your most interesting objects is implemented

4. OVERVIEW BILL’S AMAZING VENDING MACHINE

5. OVERVIEW USE CASES

6. OVERVIEW INFORMATION MODEL

7. OVERVIEW STATE AND PROCESS MODEL

8. OVERVIEW OBJECT COMMUNICATION MODEL

9. USE CASES FIRST DELIVERABLE: PHYSICAL MODEL • Labeled line drawings or pictures of your externally visible objects Picture or Labeled Line Drawing

10. USE CASES DESCRIBES USER INTERACTIONS

11. USE CASES STATE MACHINE REPRESENTATION

12. USE CASES MODELING DATA FLOW

13. USE CASES SECOND DELIVERABLE

14. INFORMATION MODEL RELATIONSHIPS, OBJECTS, ATTRIBUTES

15. INFORMATION MODEL RELATIONSHIPS, OBJECTS, ATTRIBUTES

16. INFORMATION MODEL PROPERTIES • Consists of objects (e.g., attributes) and relationships (e.g., one-to-one, one-to-many) • Object definition: a set of real-world things with common characteristics; all instances of an object behave the same • Objects are: • Tangible things that make up the problem • Roles played by people or organizations • Incidents (e.g. accidents, system crashes, service calls) • Interactions with a transaction or contract quality (e.g., purchase related to buyer, seller, and thing purchased) • Table Specifications (e.g., definition of attributes) • Designed through an iterative process

17. INFORMATION MODEL KEYS TO SUCCESS • Imagine you’re a specific instance of an object when evaluating relationships; e.g. one-to-one, one-to-many, etc. • Answer questions about relationships from the mindset of an object instance • Understand that relationships represent information exchange agreements between objects • Don’t create an object unless you’re absolutely convinced you’ve got to have it • Objects are work - more often than not, a lot of work

18. INFORMATION MODEL THIRD DELIVERABLE

19. PROCESS MODEL OBJECT-ORIENTED ANALYSIS (OOA) • A different way to see, discover, and describe the same old problems • Describe the solution in terms of the problem • OOA Models represent a higher layer of abstraction • When used in product development, the goal is to maintain the models, not the code Object-oriented development produces the code Object-oriented analysis describes the problem using coupled graphical equations: information, state, and process models

20. PROCESS MODEL DEFINITIONS • What is Object-Oriented Development? • Performance specification • Template creation • Code generation • What is Object-Oriented Analysis? • Behavior specification using models (models reflect the major components of the problem) • Behavior simulation by walking through (or executing) the models

21. PROCESS MODEL THE OOA LEARNING CURVE

22. PROCESS MODEL FOURTH DELIVERABLE

23. SUMMARY THE COMPLETE PICTURE