software engineering cs 3733 2009 b prof. george heineman

Software Engineering

CS 37332009 B

Prof. George Heineman

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


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/2009


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 5(c) 2009, Heineman 9/08/2009

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


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

Actor A Actor BSystem


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]

RequirementsSpecification Analysis Model


Requirements Elicitation Activities

(c) 2009, Heineman 9/08/2009

Identify Actors

Identify Scenarios

Identify Use Cases

Identify Non-

Functional Require-

mentsRefine

Use Cases

ConsolidateUse Cases

time


TicTacToe Experimenter

(c) 2009, Heineman 9/08/2009


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


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


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


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


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


Class Solitaire Discussion

• What needs to be modeled

(c) 2009, Heineman 9/08/2009

software engineering cs 3733 2009 b prof. george heineman

Documents