Jeet ooad unit-2

1,575 views

Published on

Object Oriented Analysis and Design unit 2

Published in: Education, Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
1,575
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
48
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Jeet ooad unit-2

  1. 1. Unit -2•Review of Unit -1•SDLC(Software Dev. Life Cycle)•Process Model•Different OO Method for Modeling
  2. 2. Object DefinitionTwo aspects: Information:1) has a unique identity2) has a description of its structure3) has a state representing its current condition Behavior:1) what can an object do?2) what can be done to it?
  3. 3. Example of an Object - Printer1) information: a) serial number b) model c) speed d) memory e) status2) behavior: a) print file b) stop printing c) empty the queue
  4. 4.  Class Definition-1) any uniquely identified abstraction of a set of logicallyrelated instances that share similar characteristics2) rules that define objects3) a definition or template that describes how to build anaccurate representation of a specific type of objectsExamples: agency, citizen, car, etc.Objects are created using class definitions as templates.
  5. 5.  Attribute DefinitionAttribute is a named property of a class describing a range of values that instances of the class may hold for that property.An attribute has a type and defines the type of its instances.Only the object is able to change the values of its own attributes.The set of attribute values defines the state of the object.
  6. 6.  Operation Definition-Operation is the implementation of a service that can be requested from any object of a given class.An operation could be:1. a question - does not change the values of the attributes2. a command – may change the values of the attributes
  7. 7.  Relationships:• between classes (relations)• between objects (links)• Three kinds of relations between classes:1) association2) aggregation3) composition
  8. 8. 1. the simplest form of Association Name relation between classes2. peer-to-peer relations University3. one object is aware of the Professor Works for existence of another object4. implemented in objects as references Association Class
  9. 9. 1. a restrictive form of “part-of” association2. objects are assembled to create a more complex object3. assembly may be physical or logical4. defines a single point of control for participating objects5. the aggregate object coordinates its parts
  10. 10. 1. a stricter form of aggregation2. lifespan of individual objects depend on the on lifespan of the aggregate object.3. parts cannot exist on their own4. there is a create-delete dependency of the parts to the whole
  11. 11. 1. a class that lacks a complete implementation providesoperations without implementing some methods.2. cannot be used to create objects; cannot be instantiated3. a concrete sub-class must provide methods forunimplemented operations
  12. 12. 1. has methods for all operations2. can be instantiated3. methods may be:a) defined in the class orb) inherited from a super-class
  13. 13. Discriminator – an attribute that defines sub-classesExample: “status” of agency staff is a possible discriminator to derive “management”, “senior” and “junior” sub-classes.
  14. 14.  Introduction of Software Development Life Cycle Different Views of SDLC Process Model used in SDLC Unified Process Model
  15. 15.  Software is like humans. It has a life cycle. Software in a system is conceptualized first. It becomes obsolescent at the end. The period in between is called the software life cycle.
  16. 16.  SDLC: process of building, deploying, using, and updating an information system Text focus: initial development project Chief variations of SDLC (a) Predictive: project planned entirely in advance (b) Adaptive: planning leaves room for contingencies Pure approaches to SDLC are rare Most projects have predictive and adaptive elements
  17. 17.  Five activities or phases in a project Planning, analysis, design, implementation, support Pure waterfall approach (predictive SDLC) Assumes project phases can be sequentially executed Project drops over the “waterfall” into the next phase Modified waterfall approach Tempers pure waterfall by recognizing phase overlap Informs many current projects and company systems
  18. 18.  When there is uncertainty regarding what’s required or how it can be built Assumes requirements are known before design begins  sometimes needs experience with product before requirements can be fully understood Assumes requirements remain static over development cycle  product delivered meets delivery-time needs Assumes sufficient design knowledge to build product  best for well-understood product  in able to cater software special properties or partially understood issues  doesn’t emphasize or encourage software reuse Problem if environment changes  request changes in programs
  19. 19.  Goal is user satisfaction  how do we determine system is ready for delivery  is it now an operational system that satisfies users’needs  is it correct and operating as we thought it should ?  Does it pass an evaluation process ?
  20. 20.  Test according to  how it has been built  what it should do 4 quality measures  correspondence  measures how well delivered system matches needs of operational environment, as described in original requirements statement  validation  task of predicting correspondence (true correspondence only determined after system is in place)  correctness  measures consistency of product requirements with respect to design specification  verification  exercise of determining correctness (correctness objective => always possible to determine if product precisely satisfies requirements of specification)
  21. 21.  Verification  am I building the product right ?  Begin after specification accepted Validation  am I building the right product ?  Subjective - is specification appropriate ? Uncover true users’ needs , therefore establish proper design ?  Begins as soon as project starts Verification & validation independent of each other  even if product follows spec, it may be a wrong product if specification is wrong  eg: report missing, initial design no longer reflect current needs  If specification informal, difficult to separate verification and validation
  22. 22.  The spiral model: early form of adaptive SDLC Activities radiate from center starting point Prototypes are artifacts of each phase Iterative problem solving: repeats activities Several approaches to structuring iterations Define and implement the key system functions Focus on one subsystem at a time Define by complexity or risk of certain components Complete parts incrementally
  23. 23.  UP life cycle Includes (4) phases which consist of iterations Iterations are “mini-projects” Inception: develop and refine system vision Elaboration: define requirements and core architecture Construction: continue design and implementation Transition: move the system into operational mode
  24. 24.  Inception (Make the Business Case) Elaboration (Define the system architecture) Construction (Construct the system) Transition (Integrate the system with the usingorganization)
  25. 25.  System development methodology Provides guidelines every activity in system development Includes specific models, tools, and techniques UP is a system development methodology Process is a synonym for methodology Methodologies supported with documentation
  26. 26.  Model abstract (separate) aspects of the real world Models come in many forms Physical analogs, mathematical, graphical System development models are highly abstract Depict inputs, outputs, processes, data, objects, interactions, locations, networks, and devices Unified Modeling Language (UML): standard notation PERT or Gantt charts: model project itself
  27. 27.  Tool: software used to create models or components Example tools-o Project management software tools (Microsoft Project)o Integrated development environments (IDEs)o Code generatorso Computer-aided system engineering (CASE)
  28. 28.  Technique Collection of guidelines Enables an analyst to complete an activity or task Example techniques Domain-modeling , use case modeling, software testing, user-interviewing techniques, relational database design techniques Proven techniques are embraced as “Best Practices”

×