1 / 21

Object-Oriented Analysis and Design

Object-Oriented Analysis and Design. References. Grady Booch : Object-Oriented Analysis and Design with Applications; Addison Wesley Perdita Stevens, Rob Pooley : Using UML Software Engineering with Objects and Components, Pearson C. Larman : Applying UML and Patterns, Pearson

Download Presentation

Object-Oriented Analysis and Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object-Oriented Analysis and Design

  2. References • Grady Booch: Object-Oriented Analysis and Design with Applications; Addison Wesley • Perdita Stevens, Rob Pooley: Using UML Software Engineering with Objects and Components, Pearson • C. Larman: Applying UML and Patterns, Pearson • J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modeling and Design, PHI

  3. Complexity • Why software is inherently complex? • Complexity of problem domain • Difficulty of managing the development process • Flexibility possible through software • Problems of Characterizing the behavior of Discrete systems

  4. Consequences “The more complex the system, the more open it is to total breakdown” • adding a new sub-basement to an existing 100 storey building - builder VS. software system user – simple matter of programming • software crisis • time delay – over budget • deficient specification than requirement • squandering of human resource & loss of opportunities

  5. Complete Dismal? • successful systems for significant complexity software • Space shuttle • large business organization (eg. Microsoft) • Study, understand, comprehend the complexity first

  6. Complex System Attribute 1. Frequently, complexity takes the form of hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary components is reached.

  7. Complex System Attribute 2. The choice of what components in a system are primitive is rarely arbitrary and is largely up to the discretion of the observer of the system.

  8. Complex System Attribute 3. Intracomponent linkages are generally stronger than intercomponent linkages. This fact has the effect of seperating the high-frequency dynamics of the components – involving the internal structure of the components – from the low frequency dynamics – involving interaction among components.

  9. Complex System Attribute 4. Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements.

  10. Complex System Attribute 5. A complex systems that works is invariably found to have evolved from a simple system that worked …. A complex system designed from a scratch never works and cannot be patched up to make it work. Thus, one has to start over, beginning with a working simple system.

  11. Organized-Disorganized Complexity • Canonical form of a complex system • little orientation - old pilot – new engine aircraft • similar skills –already – new to be trained • hierarchy not single - rather generalized one • “is a” hierarchy - class concept • “part of” hierarchy - object concept • collectively aka architecture

  12. Organized-Disorganized Complexity • Limitation of the human capacity for dealing with complexity • intricacy of interaction • capability to think about many things at once ? • flight case – location, elevation, speed, heading • human comprehension is only at order of seven information • human mind takes 5 sec to accept new information

  13. Decomposition • algorithmic decomposition • straight, top-down structured • structure chart • directly from DFD & follows structured design • object oriented decomposition • depiction of key abstractions of problem domain • set of automated agents – collaboration for higher level behaviors • through message direction for a action

  14. Role of Decomposition • object oriented decomposition • yields smaller systems through the reuse of common mechanism • provides economy of expression • more resilient to change and thus better able to evolve over time – design based upon stable intermediate forms • evolve incrementally from smaller systems having already acquired confidence • separation of concerns in a large state-space

  15. Role of Abstraction • “The span of absolute judgment and the span of immediate memory impose severe limitations on the amount of information that we are able to receive, process and remember. By organizing the stimulus input simultaneously into several dimensions and successively into a sequence of chunk we manage to break … this informational bottleneck” --- • Unable to master the entirety of a complex object - ignore its essential details, dealing instead with the generalized, idealized model of the object • semantic content

  16. Role of Hierarchy • depiction of different object collaboration • pattern of interaction – mechanisms • highlight common structure and behavior • semantic content exposition

  17. Engg : as a science - an art “The conception of a design for a new structure can evolve as much a leap of the imagination and as much a synthesis experience and knowledge as any artist is required to bring to his canvas or paper. And once that design is articulated by the engineer as artist, it must be analyzed by the engineer as scientist in as rigorous an application of the scientific method as any scientist must make” - Petroski – To Engineer is Human - 1985

  18. Design Meaning • satisfies a given (perhaps informal) functional specification • conforms to limitations of the target medium • meets implicit or explicit requirements on performance and resource usage • satisfies implicit or explicit design criteria on the form of artifact • satisfies restrictions on the design process itself, such as length or cost or the tools available for doing the design

  19. Model Building Importance • Follows the principle of decomposition, abstraction and hierarchy • Each model within a design describes a specific aspect of the system under consideration • Seek to build new models upon old models (which gained confidence already) • Opportunity to evaluate each model under both expected and unusual situations

  20. Design Method Elements • Notation – Language for expressing each model • Process – The activities leading to the ordinarily construction of the system’s model • Tools – The artifacts that eliminate the tedium of model building and enforce rules about the models themselves, so that errors and inconsistencies can be exposed A sound design method is based upon a solid theoretical foundation, yet offers degrees of freedom for artistic innovation.

  21. OO Model Dynamic Model Logical Class & Object Structure Physical Module & Process Architecture Static Model

More Related