S1: Meeting 4
- Administrative Issues
- Note: HW2 due today
- Statistical Summary from HW#1
- Today's Topics for Discussion + Readings
- Object Oriented Analysis (Specification): Chapter 9 (pp. 268-289)
- 1.6 Terminology, Life-Cycle View (Fig. 1.7, pp. 20)
- 9.1-2 Object-Oriented Analysis/Specification
- 9.3 A Case-Study: Elevator Problem
- 9.4 Implication for Life-Cycle
- 9.5 CASE Tools
- 9.6 MSG Case Study
- O. O. Analysis: An alternative to structured specifications
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S2: Terminology
- Objects: basic elements to model the world around us
- Has Identity - each object is uniquely identifiable
- Has State : the characteristics of the object
- Has Behaviour : what the object does
- can be classified into types using commonalities
- e.g. Cat type, Dog type,..
- may be composed of other objects
- e.g. a car is composed of an engine, wheels, doors, etc.
- object-orientation:
- Modeling systems as a collection of interacting objects
- Claim: a more natural representation ?
- Claim: Aids in reusability
- Goal: use prefabricated good-quality components
- to improve quality of new software
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S3: Terminology (Contd.)
- Object model components
- Objects, Object identity
- Encapsulation and information hiding
- Classes
- Inheritance
- Aggregation
- Behaviour/message passing
- Polymorphism
- We assume that the audience knows these terms
- Csci 3321 (C++) and Csci 5106 (Programming Lang.)
- Relationship to existing paradigms
- an evolution from traditional structured methods
- Brings together
- Process based views (e.g. Structured Analysis)
- Data basd views (e.g. Entity Relationship)
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S4: 1.6 Terminology, Life-Cycle View
- Benefits of object-orientation
- Improved modularity via information hiding
- Permits reuse through inheritance
- Problems with object-orientation
- Reusability is not as easy as claimed
- Polymorphism = > can be difficult to understand
- e.g. in a deep implementation inheritance hierachy
- Life-cycle implications
- Distinction b/w phases are blurred
- Fountain Model (Fig. 9.9, pp. 282) - overlapping circles
- Many concepts are used in multiple phases
- Objects in specs, design, implementation (Fig. 1.7, pp. 20)
- Less restrictions on going back to earlier phases
- repeated iteration is an intrinsic quality of... OOA"
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S5: 9.2 Object Oriented Analysis/Specifications
- Components of OO Specifications (p. 271):
- Class Diagram (data )
- Dynamic model (control logic)
- Functional model (data flow, processes)
- Start with class modeling (p. 271)
- Then work on all three steps, allowing progress
- in each to change the others (p. 271)
- Q? Develop an OO Specification of a software to
- support the above defined development process:
- Identify 3 classes
- Identify 3 steps and control flow
- Propose 3 desired functionalities for this software
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S6: Class modeling
- ...has 3 stages
- Concise problem definition: e.g. 1 sentence (p. 272)
- Informal specification, e.g.1 paragraph (p. 272-273)
- Class diagram (p. 273)
- Getting Class Diagram from Informal Specs
- a noun in the informal specs = > a class
- except nouns whose state is not affected by the spftware
- e.g. 'Building' in elevator example (pp. 273)
- candidate methods for the classes
- Result: Fig. 9.1 (pp. 274)
- What next ? control logic or process model ?
- 9.2 suggests: iterate among all 3
- so order is not important
- A review of class diagram by an Engineer
- elevator-controller class added (Fig. 9.2, pp.274)
- BTW: Entity-Relationship Diagram -- > relational table
- conversion will also introduce it! (Csci 5702)
- for the many-many association floor-button & elevators
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S7: Dynamic Modeling
- Steps
- scenarios (Example: Figs. 9.3 & 9.4 for elevator)
- control flow diagram to capture scenarios
- Ex.: Fig 9.5 for elevator-controller
- Ex. 9.1 for other classes
- e.g. State transition diagram
- Q? Is Fig. 9.5 a STD ?
- Q? Trace scenarios in Fig. 9.3 & 9.4 thru' Fig. 9.5
- Functional modeling (overall control strategy) (section 9.3.3)
- Make a DFD-like diagram
- Difference between DFD and functional model:
- DFD data stores are generally files
- functional model data stores are objects
- e.g. simple variables, files, etc. (pp. 279, para 2)
- notation: REQUESTS vs. Requests
- What next? Iteration (pp. 279, last 2 para)
- Does class diagram need revision? (Fig. 9.7)
- Does dynamic model need revision? (Fig. 9.8)
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S8: 9.5 CASE Tools
- Many CASE Tools support OO Paradigm
- Drawing, consistency checker
- Data dictionary
- Examples
- Software through Pictures
- Rational ROSE amd UML
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S9: 9.6 MSG Case Study
- Class Diagram (Data)
- Compare with Step 5 of Appendix D (pp. 498)
- Why only 2 classes?
- Q? Are other data items derived?
- Compare with Entity Relationship Diagram (Section 8.5)
- Functional Model (Fig. 9.12)
- Compare with DFD (Fig. 8.27)
- Distinction between files and internal variables
- Dynamic Model (Fig. 9.11)
- Compare with Step 4 of Appendix D
- Flow information is new
- allows scenarios enumeration, analysis
- Compare with DFD (Fig. 9.12)
- Q. Is Fig. 9.11 level 2 DFD for "verify trans. type & validity"?
- Q. Is Fig. 9.11 a state transition diagram?
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)