04-Analysis - Domain analysis Goal build an object-oriented...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Domain analysis z Goal: build an object-oriented model of the real- world system (or imaginary world) z Slicing the soup: OOA vs. OOD – OOA concerned with “what”, not “how” – OOA activities focus on the domain layer z Common OOA activities: identify classes, assign (some) responsibilities to classes – Larman’s OOA: domain model (classes, associations, attributes), and system operations z Includes static and dynamic views of the domain – DA artifacts for CS 50 project: see assignment 3 Domain analysis activities z Static view – model the domain – Identify domain concepts – Identify associations between the concepts z Now ready to start drawing domain model – a visual representation of these concepts and associations – Identify attributes of the concepts z Usually add to drawing (CS 50: add to class specifications) z Dynamic view – model the system behavior – Make system sequence diagrams – Write system operation contracts Identifying concepts z Class = major abstraction (i.e.,not just an attribute) z How to find candidate classes? – Think/brainstorm about the domain z Ask Who? What? When? Where? z But save the How? questions for OOD – Use a concept category list – e.g., pp. 140-141 in text – Identify the nouns & noun phrases in problem statement, use case descriptions, other … z Consider all as candidates to start; refine later – i.e., a candidate class turns out to be just an attribute z But common error to decide too early Suggest: start CRC cards now z 1 card for each candidate class, showing: – Class name – do now – Responsibilities – knowledge now, operations in OOD – Collaborators – some now, more in OOD z CRC cards are useful for both OOA and OOD: – OOA – help sort out classes; use to lay out diagrams – OOD – role-playing to find operations; more diagrams Collaborators Responsibilities Class (name) Split cards into 3 piles 1. Critical classes – must include 2. Totally irrelevant classes – must reject – Set aside, but record as irrelevant in glossary 3. Classes you are still undecided about – ask yourself questions like the following: – Is it same as another class? Is it an instance? – Is it actually outside the system? (like a person) – Does it have unique knowledge/responsibilities? – Is it needed by other classes? z Keep updating the piles as more is learned! Choosing concept names z Note: if you can’t think of a simple, clear name , maybe you have a bad abstraction! z A good test: Can a person with domain knowledge (not CS knowledge) describe the abstraction based on its name alone?
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 04/21/2009 for the course CS 50 taught by Professor Staff during the Winter '08 term at UCSB.

Page1 / 5

04-Analysis - Domain analysis Goal build an object-oriented...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online