Announcements. HW due today, 2 to grade this week Welcome back from Spring Break!

Transcription

1 Announcements HW due today, 2 to grade this week Welcome back from Spring Break!

2 Analysis (Domain) Modeling: Introduction Reading: Arlow and Neustadt chaps. 8, 9 (& 7) Also see Larman Chapter 10 (2 nd ed.), 9 (3 rd ed.) Analysis (Domain) modeling is a UP discipline See next figure It is not requirements It is not design It is object oriented (very) (Recall: use cases are not object oriented)

3 Disciplines in the RUP

4 Analysis Modeling Vs. Software The domain is the real world environment An analysis (domain) model is an abstract description of that environment A software system is something different! Software classes, objects, etc. are not in the real world But, the real world motivates these classes, objects, etc. Analyzing the world helps design the software later Thus, we spend time discussing the world The software itself can wait

5 Analysis (Domain) Modeling Introduction Let s analyze: model (i.e. abstractly describe) the domain A Domain Model (caps) is a UP artifact Analysis produces an analysis model (domain model) We will use UML (Unified Modeling Language) Analysis/Domain Models show: Domain entities ( conceptual classes ) Relationships among conceptual classes Conceptual class attributes

6 Example Analysis (Domain) Model See next figure Then let s do one for a POS system

7 Analysis (Domain) Model (Modified from:

8 Analysis/Domain Model Comments The notation is UML The same ideas could be stated using text, speech, etc. Note the abstractness Many details are missing Note that software components can include other things (databases, windows, methods)

9

10 Domain (Reality) Vs. Software (Not Real) Critical concept!

11 Which of these could be in a registration system analysis/domain model? Student class schedule Student Course Registration start screen Time overlaps Time overlap checker Server

12 Domain Modeling as Problem Decomposition Complex problems (like software system development projects) require decomposing the problem into pieces Problem pieces help design solution pieces Object-oriented problem decomposition uses entities (which could become classes & objects) Data! Structured (pre-object-oriented) decomposition uses processes (to become functions) Algorithms!

13 Analysis: Finding Object-Oriented Domain Entities Method 1: Conceptual Class Category List Long phrase how does it break down into pieces? Method 2: Look for nouns Nouns may be found in use cases Nouns are candidate domain entities Let s try these for the POS system

14 Using method 1 Example: POS Main Success Scenario Category list (after Larman table 10.1, 2 nd ; table 9.1, p. 140, 3 rd ) Business transaction (line item, all line items in sale) Object of a business transaction (item sold) Record of transaction (receipt) Actors (customer, cashier) Location of transaction (retail store) Major events (sales) Tangible objects (scanner, item sold) and other important pieces of the problem

15 Examples: POS system Airline reservation system Using method 1 Category list Business transaction (?,?) Object of a business transaction (?,?) Record of transaction (?,?) Actors (?,?) Location of transaction (?,?) Major events (?,?) Tangible objects (?,?) and other important pieces of the problem (?,?)

16 Method 2 Let s think of some possible conceptual classes using method 2 First, take a couple minutes to generate a Brief format use case for (POS? Student registration? Airline reservation?) List nouns Some will be good

17 POS Example: the Receipt as a Conceptual Class Should it be one? ( answer next slide)

18 POS Example: the Receipt as a Conceptual Class Should it be one? It is a part of the domain It is used in the main success scenario So it makes sense as a conceptual class

19 Conceptual Classes Entities Vs. Attributes Domain models (e.g. using UML Class Diagrams) contain both (recall Fig. earlier, also Larman 10.1, 2 nd ; 9.2, 3 rd ) so what should be a entity and what should be an attribute? Numbers, strings, & other simple data types probably best modeled as attributes Example(s)? Complicated collection of related data? Make it a conceptual class Characteristics of another entity consider it as an attribute Example: A switch has location, max. ratings, and whether it is on or off The electricity is flowing or not Which of these is/are conceptual class(es)? Which of these is/are attribute(s)? (attributes of what?)

20 Concepts Vs. Attributes II For the domain entities identified earlier, which should be conceptual classes and which should be attributes? For attributes, what conceptual classes should they be attributes of?

21 Conceptual Class Names Consider alternate names: POSterminal (from POS Terminal ) CashRegister Abstractness is good so: which term is better? Can any of our other classes usefully be given more abstract names?

22 Conceptual Class Names II Easily understood, familiar names are good Could any of our names be changed?

23 Conceptual Classes Revisited Conceptual class is domain entity Design class is in the design Implementation class is in the code Class a conceptual class, a design class, or an implementation class

24 Next: Associations in Domain Models (Chapter 11, 2 nd ed.; Sections , 3 rd ed.)