1,Introduction(cont’d) Different thinking way,discovery process And communication between user and analyst Revolutionaries OO is a radical change that renders conventional Methodologies and ways of thinking about Design obsolete Yourdon: Object-Oriented methodologists Synthesis OO as simply an accumulation of sound Software engineering principles that adopters Can graft onto their existing methodologies with relative case OOSDM : essentially an elaboration foundation: structured design

1,Introduction(cont’d) Object-oriented approach is a refinement of some of the best software engineering ideas of the past Not a Evolutionary approach !!! Incremental : minor change Radical : different principles, draw new tech.and problem-solving skills

1,Introduction(cont’d) OO A&D: Radical change: strong negative impact greater expense risk different management strategies More maturity conventional methods existed Radical or incremental is a crucial to the future of OO and formulating a transition strategy.

1, Introduction (cont’d) No comprehensive comparing analysis between OOM and conventional Methodologies Some comparing on analysis & design of OO. Loy: insightful commentary on OO versus Conventional methodologies Now This research: fill the gap left by others by analysis several leading Conventional and OO ADM, point-by-point comparison. 6 analysis+ 5 design

2, Analysis Methodologies Conventional • DeMacro Structured analysis • Yourdon modern structured analysis • Martin Information engineering analysis Object-Oriented • Coad and Yourdon Object-oriented analysis • Shlaer and Mellor Object-oriented analysis • Bailin Object –oriented requirements specifications

2.1 Conventional Methodologies Larger/complicated System built Late 1960s: system development life cycle(SDLC) -- Evolution of modern methodologies Hardware performance Adoption of high level language SDLC : bring new order to develop process

2.1.1 Structured methodologies SDLC give develop a measure of control, but little help in improve the productivity and quality of analysis and design. 1970’s: structured methodologies developed to promote more effective analysis and more stable /maintainable designs. Early : more largely process-oriented:minor on modeling of entities and data. Critical contributions: Yourdon/Constantine, Demarco, Ward/Meller

2.1.1.1 Tools for structured methodologies Dataflow diagram(DFD): Process/flow of data Data_dictionary : definition, ”encyclopedias” Entity relationship diagram(ERD): Hierarchy diagram: simple top-down connection Mini-spec: English specification of logic, process State-transition diagram: possible states Structure chart : architecture of system

2.1.1.2 Three main Structured methodologies in conventionally Yourdon/Constanine: Demarco’s: Ward& Meller:

2.1.1.2 Yourdon Constanine Provided a method for developing a system architecture that conformed to following engineering principles: Loosely coupled modules Module cohesion Structure chart :primary tool for modeling a system design DataFlow diagram: Modeling process Hierarchy diagram: Defining data structure

2.1.1.2 DeMarco’s Enlarge structure approach to encompass analysis Structured analysis: modeling of existed systems( in DFD) modeling of the system to be developed (DFD, MS, DD) Emphasis on: modeling process Goal: top-down decomposition of the functions to be performed by the target system

2.1.1.2 Ward& Meller’s Continuing the structure tradition Significant extensions to structured analysis to better support modeling of real-time system Added ERD and STD to structured analysis

2.1.1.3 modern Structured Analysis Yourdon update: different from DeMarco’s No longer recommends modeling of current implemented system Adds a preliminary phase to develop an “ essential model” of the system Substitutes a technique” event partitioning” for top-down functional decomposition as the preferred technique for constructing DFD Places more emphasis on info. Modeling(ERD) and behavior modeling(STD) Encourages prototyping

2.1.2 Information Engineering Late 1970’s~early 1980s, planning and modeling of data More central role in system development. culminating in the development of data-oriented methodologies : information engineering 1970s relational database model, entity-relationship modeling eling

2.1.2.1 Assumptions of Information Engineering Two assumptions: Organizational data provides a more stable foundation for a system design than organizational procedure. Data should be viewed as an organizational resources independent of the systems that(current) process the data. Creation of anew info. Systems subfunction, data administration To help analyze, define, store, control organizational data.

2.1.2.2 Martin Info.Engineering A comprehensive methodology : Extends the data –oriented approach across the entire development life cycle. Evolved forward through the life cycle from planning and analysis (Structured , backward from programming) Four Phases:( p25) Information strategy planning, Business area analysis System design Construction Business Unit Project specific

2.1.2.2 Martin Info. Engineering Enterprise modeling Critical-success-factors analysis Data modeling Process modeling Joint-requirements planning Joint application design Time-box methodology Prototyping Much broader range of analysis techniques and modeling tools:

2.1.2.2 Tools of Martin Info.Engineering Action diagram :detailed procedural logic/structured English Bubble chart : low-level diagram, aide to normalization Dataflow diagram: Data_model diagram: Entities/relational, ERD Data-Structure diagram:data structure in format appropriate Encyclopedia: more comprehensive data dictionary Enterprise model: high level define the functional areas of Org. Entity-Process matrix: cross reference to entities and process Process-decomposition diagram: hierarchical chart Process-dependency diagram:processes diagram with lables State-transition diagram:

2.2 Object-Oriented Analysis Methodologies Goal: development of an accurate and complete representation of the problem domain. Quite young: too early to predict as standard Three methodologies: in single point in time ( from 1980~1990), not comprehensive review

2.2.1 Three OO analysis methodologies Bailin Object_oriented requirements specification(OOS) response to a perceived: incompatibility between conventional structured analysis and object-oriented design. Coad and Yourdon object-oriented analysis Upon the best concepts from Info.modeling, OOPL, knowledge-based system Shlaer and Mellor Object-oriented analysis based on the courses of several years of consulting practice in information modeling

2.2.2 Tools for 3 OO methodologies : Bailin’s Entity-relationship diagram Entity_dataflow diagram(EDFD) variant on conventional DFD each process contains either an active entity or some function related to an active entity Entity dictionary: a repository of entity names & descriptions

2.2.2. Tools for 3 OOMethodologies:Coad & Yourdon’s Class and object diagram: 5 layers class & object; structure; subjects; attributes; service. Object-state diagram: simple diagram shows all possible states of an object and the transitions between states. Service chart: flowchart-like diagram of logic within an individual service

2.2.2 Tools for 3 OO methodologies:Shlaer & Mellor’s Action_dataflow diagram Domain Chart: domains to the implementation of OOA Information structure diagram:variant of ERD show objects Object and attributes description: text description of object Object-Access Model: synchronous interactions state at global system level Object-communication Model:asynchronous interactions Process description: a narrative description of process Relationship Specification: text description of each relationship State Model: conform the conventional notation for STD. Subsystem access Model: synchronous interaction between OAM Subsystem communication model: asynchronous interaction OCM Subsystem relationship model: relationship of info. Models

2.2.3 Procedures of 3 OO Analysis Methodologies:Bailin’s Groups functions together only if they “operate on the same data abstraction” Distinguishes between entities & functions Distinguishes between two classes of entities: active (important operations) passive(lesser important: black box). 7 steps procedure: End result of OOS is an entity relationship diagram with a hierarchy of entity DFD.

2.2.3 Procedures of 3 OO analysis methodologies:Bailin’s Identify key problem domain entities Distinguish between active and passive entities Establish dataflows between active entities Decompose entities (or functions)into subentities and /or functions. Check for new entities Group functions under new entities Assign entities to appropriate domains.

2.2.3 Procedures of 3 OO analysis Methodologies:Coad & Yourdon OOA results in 5 layers model of the problem domain where each level built on previous layers Define objects and classes: Define structures: relationship Define subject areas Define attributes: characteristics of objects Define services: Primary Tools: class& object diagrams,service charts Similar to: modern structured analysis, Info.Modeling Differs: providing constructs for modeling exclusive services and message connection

2.2.3 procedures of 3 OO Analysis Methodologies :Shlaer & Mellor’s Foundation was: Information Modeling Two other views of target system: state model & a process model Three way view of the system(info., state, process) is proposed as a complete description of the problem domain. Support 3 essential principles of OO: Classification, inheritance encapsulation Six –step procedure

2.2.3 Procedures of 3 OOAnalysis methodologies:Shlaer& Mellor 6 steps: Develop an information model Define Object life cycle Define the dynamics of relationships:Time Define system dynamics: time & control Develop process(4) models Define domains(4) and subsystems.

2.4 Comparison of analysis methodologies 11 modeling dimensions: OO versus conventional analysis: stem from the OO requirement of encapsulated operations Conventional:provide tools to create a functional decomposition of operations, and to model end-to-end processing sequences.Not true in OOA. All OOA recognize a need to develop some sort of model of system operations

2.4 Comparison of analysis OOA Similarities Overlap significantly(same concept but different notations, terminology) Entities(object) and relationship establish a foundation for later stage of analysis Similar RED contents Coad & Yourdon refer explicitly to: OO concepts : inheritance and object decomposition

2.4 Comparison of analysis Methodologies OOA Differences: 3 areas Depiction of entity states Emphasis in Shlaer & Mellor Coad & Yourdon some Bailin: no formal means ( STD ????) Definition of exclusive services Coad&Yourdon, Shlaer most detailed Bailin: less details Attention to attribute modeling: Bailin low emphasis, but Coad & Yourdon did more

2.4 Comparison of OO analysis Methodologies OOA Differences Shlaer & Mellor support some concepts not address by Coad/Yourdon , or Bailin A distinction between asynchronous and synchronous control The use of timers to generate future events The concepts of a dynamic relationship and its role in handling contention between concurrent processes.

2.4 Comparison of Analysis Methodologies OOA: incremental versus radical change radical departure from older process-oriented : in DeMarco structured analysis Only incremental change from: data-oriented : Martin Information engineering Here all OOA contain heavy information modeling component. Significant change: Shlaer & Mellor OOA emphasis on modeling object life cycle.

3, Design Methodologies Design: the process of mapping system requirements defined during analysis to an abstract representation of a specific system-based implementation .meeting cost and performance constraints. Wasserman et.al. OO structured design(OOSD) Booch OO Design Wirfs-Brock et.al. Responsibility driven design(RDD)

3, Design Methodologies Conventioal Design • Yourdon and Constrantines structured design • Martin information engineering design Object-Oriented Design • Wasserman et al. object-oriented structured design • Booch object-oriented design • Wirfs-brock et al. responsibility driven design

3.1 Tools and procedures steps of OOD:Wasserman’s OOSD OO Structured Design: Goal: Provide a standard design notation that can support every software design( OO & conventional approach both) Provide Detailed notation for describing an architectural design. Primary Tool: OO structured chart ( classical structure chart+ notations )

3.1 Tools & Procedures steps of OO design:Wasserman’s OOSD OO structure chart: used show multiple inheritance, message passing, polymorphism, dynamic binding. OOSD: supports concept of monitor ( asynchronous processes in real-time systems) Provides a foundation for representing design decisions associated with the physical design

3.1 Tools & Procedures steps for OO design:Booch OOD Pioneered the field of OOD Ada Language specific in 1980s Expand and generalize: alternative of structured design not extension of it. Reluctant to prescribe a fixed ordering of phases for OOD. 4 major steps must be performed identify classes and objects Identify the semantics of classes & objects. Identify relationships between classes & objects Implement classes and objects.

3.1, Tools and Procedures of OOD : Booch OOD Tools: Class diagrams & class templates Module diagram & templates Object diagrams: dynamics of some objects Timing diagram: control and ordering of events Operation templates: services Process diagrams & templates State transition diagram

3.1 Tools and procedures of OOD:Wirfs-Brock: RDD Responsibility-driven design(RDD) Based on a client-server model of computing Client,servers are different objects. Services and responsibilities correspond to methods. Focus of attention during design on contacts between client and server. More on object interactions and encapsulation Two phases and 6 steps

3.1 Tools and Procedures of OO Design:Wirfs_Brock RDD 2 phases and 6 steps Find classes Find Responsibilities and assign to classes Find collaborations First Exploration phase Define hierarchies Define subsystem Define protocols Second analysis Phase

3.1 Tools and procedures of OOD:Wrfs_Brock: RRD Tools Class cards:physical card to record text describing classes Class Specification : expanded of class cards Collaborations graph :diagram with paths Hierarchy diagram : inheritance relationships Subsystem card : physical card for record Subsystem specification: same as class specification Venn diagram : overlap of responsibilities

3.2 Comparison of design Methodologies OOD versus Conventional Design No conventional support: definition of classes, inheritance, methods or message protocols. Both provide tools that define a hierarchy of modules Object is primary unit of modularity in OOD modules only contain procedural code in conventional design

3.2 Comparison of design methodologies OOD versus conventional design Greatest overlap: Booch OOD and information Engineering ( tool for defining end-to-end processing sequences) ( detailed definition of procedural logic).

3.2 Comparison of design Methodologies :OOD Differences In data design Booch detailed procedure for designing data. Wasserman, Wirfs_Brock little on data design. Level of detail in describing the process of OOD Wirfs_Brock: thorough description of design process Booch offers less Wasserman: No procedural description Level of detail provided by diagram notations Wasserman, Booch :comprehensive notations Wirfs_Brock : less

3.2 Comparison of OODIncremental /radical change? OOD: clearly a radical change from process or data-oriented methodologies Important is not whether OO concepts are radically new in some absolute sense, but rather whether they are radically new to the population of potential adopters?

4, Transition from analysis to design Analysis: a process of extracting and codifying user requirements and establishing an accurate model of the problem domain. Design: process of mapping requirements to a system implementation that conforms to desired cost, performance, and quality parameters

Contents

Contents

Presentation Transcript

Contents

Contents

Contents

Contents

Contents

Contents

Contents

CONTENTS

Contents

Contents