Software Engineering CS 3733 2009 B Prof George

Software Engineering CS 3733 2009 B Prof. George Heineman

Outline • Course Details – Found on Web – Expected work-level • Java Crash

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

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/2009 CS 509 : Design of Software Systems 4

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 (c) 2009, Heineman 9/08/2009 CS 509 : Design of Software Systems 5

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 System • Describe all functionality from external viewpoint – Use cases fully partition system description (c) 2009, Heineman 9/08/2009 CS 509 : Design of Software Systems 6

Task 1. 1: Requirements Elicitation • Necessary step before Analysis – Represents same information, just structured differently • RE goal Requirements Specification Analysis Model – 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] (c) 2009, Heineman 9/08/2009 CS 509 : Design of Software Systems 7

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

Tic. Tac. Toe Experimenter (c) 2009, Heineman 9/08/2009 CS 509 : Design of Software

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 (c) 2009, Heineman 9/08/2009 CS 509 : Design of Software Systems 10

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

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/2009 CS 509 : Design of Software Systems 12

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/2009 CS 509 : Design of Software Systems 13

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/2009 CS 509 : Design of Software Systems 14