1. Software Engineering CS 3733 2009 B Prof. George Heineman

2. Outline Course Details – Found on Web – Expected work-level Java Crash course planned next week A1 division OO Introduction (c) 2009, Heineman 9/08/20092CS 509 : Design of Software Systems

3. Course Structure Task1: Requirements Analysis Document (RAD) – Individual Project – Individual Project (OO coding) Task2: Implementation – Completed implementation of Task1 RAD – Product-line “Family” with planned extensions – Completed JUnit testing with code coverage metrics Task3: Add new “Product-line” member – Complete “options packages” specified in Task1 – Document and describe addition. Extension Tutorial – Validate via JUnit testing (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems3

4. Software Engineering Modeling – Represent information in appropriate abstractions – Key: Maintain models as software process progresses – Key: Traceability from start to finish Problem Solving – Learn how to make important design decisions – Key: Flexibility and Extensibility – Key: Maximize return on investment (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems4

5. (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems5 Software Engineering Process Problem Statement – Non-Functional Requirements – Functional Model [Use Case] Analysis – Analysis object model [Class Diagram] – Dynamic model [Sequence Diagram] System Design – Design Goals – Design object model and Architecture – Sub-system decomposition Object Design – Object design model [Class Diagram] Implementation & Test Final Validation

6. (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems6 Task 1.1:Requirements Elicitation Define purpose of system – Actors: external entities that interact with system – Use cases: sequences of events describing actions between actor and system Describe all functionality from external viewpoint – Use cases fully partition system description System

7. (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems7 Task 1.1:Requirements Elicitation Necessary step before Analysis – Represents same information, just structured differently RE goal – Capture functional model & non-functional reqs Analysis goal – Construct analysis object model – Determine dynamic model (behavior of system) – In this class, less attention given to [DM] Requirements Specification Analysis Model

8. Requirements Elicitation Activities (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems8 Identify Actors Identify Scenarios Identify Use Cases Identify Non- Functional Require- ments Refine Use Cases Consolidate Use Cases time

9. TicTacToe Experimenter (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems9

10. (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems10 Modeling Abstract representation of a system – Focus on relevant details – Hide non-interesting details Application Domain Model – Model of real-world system, as observed and relevant Solution Domain Model – Model of the construction of an application

11. (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems11 Application Domain Represent all aspects of user’s problem – KombatSolitaire application – Client-side functionality – Server-side functionality May change (because the world changes) – New type of solitaire plugins – New types of required functionality

12. Solution Domain Modeling desired system – Produces model that can lead to a number of systems – Rich details May change (because technology changes) – New languages, tools, standards (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems12

13. Object-oriented (OO) Paradigm Combines Application and solution domain modeling – No longer separate activities Start with Application Domain Model – Objects and Relationships Introduce Solution Domain Model as objects Solution Domain is transformation of Application Domain (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems13

14. OO design process Analyze problem to identify objects Generalize objects to identify classes Decompose problem as interacting objects Encapsulation – Gather into one unit all aspects of the real-world entity modeled by that unit – Data as well as Actions (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems14

15. Class Solitaire Discussion What needs to be modeled (c) 2009, Heineman 9/08/2009CS 509 : Design of Software Systems15