S1: Meeting 4
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
      • look for verbs
    • 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)