《面向对象分析与设计》摘录

原创 2007年10月16日 09:14:00

《面向对象分析与设计》摘录

赵朝阳

2007-10-15

sou_dog@hotmail.com

Section1 : Concept. 1

Complexity. 1

Object Model 3

Classes and Objects. 9

Classification. 12

Section2 : Method. 16

Notation. 16

Process. 16

Pragmatics. 16

Section3 : Applications. 16

 

Section1 : Concept

Complexity

There are always clear boundaries between the outside and inside of a given level

 

We do not find individual parts that are each responsible for only one step in a single larger process, such as photo-synthesis

 

Different levels are unified by common interface, and mail clerk usually does not interact with the chief executive

 

Much of the complexity that he must master is arbitrary complexity, it’s essential

 

The complexity of software is essential. Following is the reason:

1.      The complexity of the problem domain

The task of the software development team it to engineer the illusion of simplicity

2.      The difficulty of managing the development process

The key management challenge is always to maintain a unity and integrity of design

3.      The flexibility possible through software

       Software development remains a labor-intensive business

4.      The problems of charactering the behavior of discrete systems

 

The five attributes of successful complex software:

1.      Hierarchic structure

The architecture of a complex system is a function of its components as well as the hierarchic relationships among these components.

Hierarchic system is nearly decomposable

2.      Relative primitives

What is primitive for one observer may be at a much high level of abstraction for another

3.      Separation of concerns

Intra-component linkages are generally stronger than inter-component linkages.

The difference between intra-component and inter-component provides a clear “separation of concerns” among various parts of a system, making it possible to study each part in relative isolation

4.      Common patterns

Many complex system is a “trade-off”, and be reused

5.      Stable intermediate forms

Complex systems will evolve from simple systems much more rapidly if there are stable intermediate forms than if there are not.

 

The discovery of common abstractions and mechanisms greatly facilitates our understanding of complex systems.

 

Most interesting systems do not embody a single hierarchy

 

Two perspectives:  “is-a” hierarch(class structure) ; “part-of” hierarchy(object structure)

 

There is no absolutely right way to decompose a complex system.

 

概念

描述

Decomposition

l  Algorithm Decomposition

       Top-down structured design

l  Object-oriented Decomposition

Help us organize the inherent complexity of software systems. Yields smaller systems through the reuse of common mechanisms

Abstract

We abstract from it. Unable to master the complexity of the system, we choose to ignore its inessential details , dealing instead with the generalized , idealized model of the objet

Hierarchy

Recognize the class and object hierarchy.

l  class hierarchy ” focus on the common structure of the system

l   object hierarchy” focus on the mechanism of the system

 

“Engineer as a Science and an Art

 

We must study the principals on which object-oriented development is founded, namely

l  Main Principals:

n  Abstraction

n  Encapsulation

n  Modularity

n  Hierarchy

l  Secondary Pricipal:

n  Concurrency

n  Typing

n  Persistence

Summary

l  Software is inherently complex; the complexity of software systems often

exceeds the human intellectual capacity.

l  The task of the software development team is to engineer the illusion of

simplicity.

l  Complexity often takes the form of a hierarchy; it is useful to model both

the “is a” and the “part of” hierarchies of a complex system.

l  Complex systems generally evolve from stable intermediate forms.

l  There are fundamental limiting factors of human cognition; we can address

these constraints through the use of decomposition, abstraction, and

hierarchy.

l  Complex systems can be viewed by focusing on either things or processes;

there are compelling reasons for applying object-oriented decomposition, in

which we view the world as a meaningful collection of objects that collaborate

to achieve some higher-level behavior.

l  Object-oriented analysis and design is the method that leads us to an

object-oriented decomposition; object-oriented design uses a notation and process for constructing complex software systems and offers a rich set of models with which we may reason about different aspects of the system under consideration.

Object Model

Principles

n  Main Principals:

u  Abstraction

u  Encapsulation

u  Modularity

u  Hierarchy

n  Secondary Pricipal:

u  Concurrency

u  Typing

u  Persistence

 

Generation of Programming language

l  First generation

       Step closer to the problem space, step from the Machine world

l  Second generation

Algorithm abstraction

l  Third generation

n  The emergency of the Module

n  Data abstraction

n  Step closer to the problem domain, step from the Machine

l  Generation gap

l  Fourth generation

       OO ;  Framework

 

If procedures and functions are verbs and pieces of data are nouns, a procedure-oriented program is organized around verbs  while an object-oriented program is organized around nouns.

 

Classes, objects, modules provide an essential yet insufficient means of abstraction.

(There are other means to do abstraction)

 

The object model is a unifying concept in computer science, applicable to programming language and to the design of user interfaces, databases, and even computer architectures.

 

Object Model:

 in the object model, emphasis is placed on crisply characterizing the components of the physical or abstract system to be modeled by a

programmed system. . . . Objects have a certain ‘integrity’ which should not—in

fact, cannot—be violated. An object can only change state, behave, be manipulated,

or stand in relation to other objects in ways appropriate to that object.

Stated differently, there exist invariant properties that characterize an object and

its behavior. An elevator, for example, is characterized by invariant properties

including [that] it only travels up and down inside its shaft. . . . Any elevator simulation must incorporate these invariants, for they are integral to the notion of an elevator

 

The first person to formally identify the importance of composing systems in layers of abstraction was Dijkstra

 

OOP:

Object-oriented programming is a method of implementation in which programs

are organized as cooperative collections of objects, each of which represents an

instance of some class, and whose classes are all members of a hierarchy of

classes united via inheritance relationships

 

language is object-oriented if and only if it satisfies the following requirements:

l  It supports objects that are data abstractions with an interface of named

operations and a hidden local state.

l  Objects have an associated type [class].

l  Types [classes] may inherit attributes from super-types [super-classes]

 

OOD:

Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design

 

OOA:

Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.

 

Five main kinds of programming styles, as follow:

 Programmin Style

Core concept

Best for

Elements

Procedure-oriented

Algorithms

computation-intense operations

 

Object-oriented

Classes and objects

architectural framework

Major:

Abstraction

Encapsulation

Modularity

Hierarchy

Minor:

Typing

Concurrency

Persistence

Logic-oriented Goals

often expressed in a predicate calculus

 

 

Rule-oriented

If–then rules

knowledge base,

 

Constraint-oriented

Invariant relationships

 

 

 

Principals of Object-Oriented Programming, as follow:

Concept

Description

Memo

 

abstraction

An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.

Entity abstraction

An object that represents a useful model of a

problem domain or solution domain entity

Action abstraction

An object that provides a generalized set of

operations, all of which perform the same

kind of function

Virtual machine abstraction

An object that groups operations that are all

used by some superior level of control, or

operations that all use some junior-level set

of operations

Coincidental abstraction

An object that packages a set of operations

that have no relation to each other

encapsulation

Encapsulation provides explicit barriers among different abstractions and thus

leads to a clear separation of concerns. For example, consider again the structure

of a plant. To understand how photosynthesis works at a high level of abstraction,

we can ignore details such as the responsibilities of plant roots or the chemistry of

cell walls. Similarly, in designing a database application, it is standard practice to

write programs so that they don’t care about the physical representation of data

but depend only on a schema that denotes the data’s logical view [52]. In both of

these cases, objects at one level of abstraction are shielded from implementation

details at lower levels of abstraction.

 

Modularity

Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.

 

Hierarchy

Hierarchy is a ranking or ordering of abstractions

class structure(“is a”)

object structure ( “part of”).

Typing

Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in

very restricted ways

 

Concurrency

Concurrency is the property that distinguishes an active object from one that is not active.

 

Persistence

Persistence is the property of an object through which its existence transcends time (i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s location moves from the address space in which it was

created).

 

 

we place these abstractions in modules to produce the system’s physical architecture

 

A naive strategy might be to define each message class in its own module. As it turns out, this is a singularly poor design decision. Not only does it create a documentation nightmare, but it makes it terribly difficult for any users to find the classes they need

 

Hiding is for the prevention of accidents, not the prevention of fraud

 

Modularity packages abstractions into discrete units.

 

a module’s interface should be as narrow as possible, yet still satisfy the needs of the other modules that use it

 

The identification of classes and objects is part of the logical design of the system, but the identification of modules is part of the system’s physical design

 

The maturation of software engineering has led to the development of object-oriented analysis, design, and programming methods, all of which address the issues of programming-in-the-large.

Summary

l  There are several different programming paradigms: procedure-oriented, object-oriented, logic-oriented, rule-oriented, and constraint-oriented.

l  An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.

l  Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.

l  Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.

l  Hierarchy is a ranking or ordering of abstractions.

l  Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged or, at the most, may be interchanged only in very restricted ways.

l  Concurrency is the property that distinguishes an active object from one that is not active.

l  Persistence is the property of an object through which its existence transcends time and/or space.

Classes and Objects

The architect must understand when it is appropriate to use nails or bolts or

glue or welds

 

Concept

Description

Memo

object

An object is an entity that has state, behavior, and identity. The structure and behavior of similar objects are defined in their common class. The terms instance and object are interchangeable

Incorrent:” everything in the world is an object

Object. state

The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties

Static property

 

A property is an inherent or distinctive characteristic, trait, quality, or feature that

contributes to making an object uniquely that object

Object. behavior

Behavior is how an object acts and reacts, in terms of its state changes and message passing.

“The state of an object represents the cumulative results of its behavior”

Operations

Modifier

Selector

Iterator

Constructor

Destructor:

Roles and Responsibilities

Collectively, all of the methods associated with a particular object comprise its protocol

 

it is useful to divide this larger protocol into logical groupings of behavior

 

Objects can play many different roles

 

Objects play many different roles during their lifetimes

Objects as Machines

 

Object. identity

Identity is that property of an object which distinguishes it from all other objects

The key in database fails to identity the objects with same name.

Object

Relationship

Link

ControllerServerProxy

Synchronization

Visibility

Aggregation

 

class

A class is a set of objects that share a common structure, common behavior, and common semantics

an abstraction, the essence of an object

Relationship

generalization/speciali zation

whole/part

interface

This view of programming as contracting leads us to distinguish between the outside view and the inside view of a class

 

 

A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework

 

The design of classes and objects is an incremental, iterative process

 

The Role of Classes and Objects in Analysis

and DesignKey Abstraction; Mechanism

l  Identify the classes that form the vocabulary of the problem domainKey Abstraction

l  Invent the structures whereby sets of objects work together to provide the

behaviors that satisfy the requirements of the problemMechanism

 

Quality of an Abstraction:

1.    Coupling

The measure of the strength of association established by a connection from one module to another. Strong coupling complicates a system since a module is harder to understand, change, or correct by itself if it is highly interrelated with other modules. Complexity can be reduced by designing systems with the weakest possible coupling between modules

2.    Cohesion

Cohesion easures the degree of connectivity among the elements of a single module

3.    Sufficiency

sufficiency implies a minimal interface, a complete interface is one that covers all aspects of the abstraction

4.    Completeness

interface of the class or module captures all of the meaningful characteristics of the abstraction

5.    Primitiveness

 

We often can identify patterns of abstraction, structure, or behavior.

 

Operations:

l  Functional Semantics

fine-grained:

A good designer knows how to find the appropriate balance between too much contracting, which produces fragmentation, and too little, which yields unmanageably large modules

Decision Factor: ReusabilityComplexityApplicabilityImplementation knowledge

l  Time and Space Semantics

Choosing Relationships

Choosing the relationships among classes and among objects is linked to the selection of operations.

The Law of Demeter

The methods of a class should not depend in any way on the structure of any class[1], except the immediate (top-level) structure of their own class. Further, each method should send messages to objects belonging to a very limited set of classes only

       If the behavior of an object is more than the sum of its individual parts, creating an aggregation relationship rather than an inheritance relationship between the appropriate classes is probably superior.

Mechanisms and Visibility

Deciding on the relationship among objects is mainly a matter of designing the

mechanisms whereby these objects interact

Choosing Implementations

functionally cohesive, loosely coupled modules

Summary

l  An object has state, behavior, and identity.

l  The structure and behavior of similar objects are defined in their common class.

l  The state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties.

l  Behavior is how an object acts and reacts in terms of its state changes and message passing.

l   Identity is the property of an object that distinguishes it from all other objects.

l   A class is a set of objects that share a common structure and a common behavior.

l   The three kinds of relationships include association, inheritance, and aggregation.

l   Key abstractions[2] are the classes and objects that form the vocabulary of the problem domain.

l   A mechanism[3] is a structure whereby a set of objects work together to provide a behavior that satisfies some requirement of the problem.

l   The quality of an abstraction may be measured by its coupling, cohesion, sufficiency, completeness, and primitiveness.

 

Classification

Classification is the means whereby we order knowledge

 

In objectoriented design, recognizing the sameness among things allows us to expose the commonality within key abstractions and mechanisms and eventually leads us to smaller applications and simpler architectures.

 

The identification of classes and objects is a challenging part of object-oriented analysis and design, involves both discovery and invention

l  Through discovery, we come to recognize the key abstractions and mechanisms that form the vocabulary of our problem domain.

l  Through invention, we devise generalized abstractions as well as new mechanisms that specify how objects collaborate

 

Different observers will classify the same object in different ways

 

The Incremental and Iterative Nature of Classification

 

The approaches of Identifying Classes and Objects:

l  Classical categorization

l  Conceptual clustering

l  Prototype theory

As follows:

Approach

Description

Classical categorization

l  All the entities that have a given property or collection of properties in common form a category. Such properties are necessary and sufficient to define the category

l  We can name a thing according to the knowledge we have of its nature from its properties and effects

l  The most useful sets of properties are those whose members do not interact too much. This explains the universal popularity of that particular combination of properties: size, color, shape, and substance. Because these attributes scarcely interact at all with one another, you can put them together in any combination whatsoever to make an object that is either large or small, red or green, wooden or glass, and having the shape of a sphere or a cube

l  The particular properties that should be considered in a given situation are highly domain-specific

Conceptual clustering

l  In this approach, classes (clusters of entities) are generated by first formulating conceptual descriptions of these classes and then classifying the entities according to the descriptions

l  Conceptual clustering is closely related to fuzzy  multivalue) set theory, in which objects may belong to one or more groups, in varying degrees of fitness

l  In conceptual clustering, we group things according to distinct concepts

Prototype theory

l  Use it when there are some abstractions that have neither clearly bounded properties nor concepts.

l  a class of objects is represented by a prototypical object, and an object is considered to be a member of this class if and only if it resembles this prototype in significant ways

l  This notion of interactional properties is central to the idea of prototype theory.

l  In prototype theory, we group things according to the degree of their relationship to concrete prototypes.

 

No one scheme of classification, more than any other, represents the real structure or order of nature. Nature indifferently submits to any and all divisions which we wish to make among existing things. Some classifications may be more significant than others, but only by reference to our interests, not because they represent reality more accurately or adequately

 

Classical categorization and conceptual clustering are sufficiently expressive to account for most of the classifications we need in the design of complex software Systems

 

How to classify:

l  In our experience, we identify classes and objects first according to the properties relevant to our particular domain

we focus our attention on the problem domain

l  Next consider clustering objects by concepts (or refining our initial domain-based classification by concepts).

we focus our attention on the behavior of collaborating objects

l  If above two failed, we consider classification by association, through which clusters of objects are defined according to how closely each resembles some prototypical object

 

Object-Oriented Analysis

l  Classical Approaches

A number of methodologists have proposed various sources of classes and objects, derived from the requirements of the problem domain

l  Behavior Analysis

We form classes based on groups of objects that exhibit similar behavior

l  Domain Analysis

n  The principles we have discussed thus far are typically applied to the development of single, specific applications

n  seeks to identify the classes and objects that are common to all applications within a given domain, such as patient record tracking, bond trading, compilers, or missile avionics systems

l  Use Case Analysis

In isolation, the practices of classical analysis, behavior analysis, and domain analysis all depend on a large measure of personal experience on the part of the analyst

l  CRC Cards

CRC cards emerged as a simple yet marvelously effective way to analyze scenarios

l  Informal English Description

writing an English description of the problem (or a part of a problem) and then underlining the nouns and verbs

l  Structured Analysis

This technique appears appealing only because a large number of analysts are skilled in structured analysis, and computer-aided software engineering (CASE) tools exist that support the automation of these methods

Key Abstractions and Mechanisms

key abstraction

l  a class or object that forms part of the vocabulary of the problem domain

l  Classes and objects should be at the right level of abstraction: neither too high nor too low.

l  Make the OO as a prose

l  Often this means that the programmer must focus on the questions: how are objects of this class created? Can objects of this class be copied and/or destroyed What operations can be done on such objects? If there are no good answers to such questions, the concept probably wasnt clean in the first place, and it might be a good idea to think a bit more about the problem and the proposed solution instead of immediately starting to code around the problems

mechanism:

l  describe any structure whereby objects collaborate to provide some behavior that satisfies a requirement of the problem

l  Mechanisms are the means whereby objects collaborate to provide some higher-level behavior

Summary

l  The identification of classes and objects is a fundamental issue in object-oriented analysis and design; identification involves both discovery andinvention.

l  Classification is fundamentally a problem of clustering.

l  Classification is an incremental and iterative process, made difficult because a given set of objects may be classified in many equally proper ways.

l  The three approaches to classification include classical categorization (classification by properties), conceptual clustering (classification by concepts),and prototype theory (classification by association with a prototype).

l  Scenarios are a powerful tool of object-oriented analysis and can be used in approaches such as classical analysis, behavior analysis, domain analysis, and use case analysis.

l   Key abstractions reflect the vocabulary of the problem domain and may either be discovered from the problem domain or invented as part of the design.

l  Mechanisms denote strategic design decisions regarding the collaborative activity of many different kinds of objects.

Section2 : Method

Notation

         UML

Process

RUP/AM etc.

Pragmatics

Project Management; Release Plan; Reuse; Quality Assurance

Section3 : Applications

The first steps in the development of the system architecture are really systems

engineering steps, rather than software engineering, even for purely or mostly

software systems

 

Systems engineering     

An interdisciplinary approach and means to enable the realization of successful systems

 

Systems Architecture     

The arrangement of elements and subsystems and the allocation of functions to them to meet system requirements

 

The System context diagram define the boundaries of the problem domain, that is what is inside our system and what is not

 

“An activity diagram is helpful in understanding the high-level execution behavior of a system, without getting involved in the internal details of message passing required by a collaboration diagram”

 

Allocation of Functionality

From the highest level in the system architecture to the lowest

l  System: (Black-box) We could allocate the functionality of the entire Satellite Navigation System to another development effort. For example, a co-development effort could be pursued with the European Space Agency in the development of Galileo.

l  Segment: A prime example of allocation at the segment level is subcontracting the entire launch effort. Numerous companies provide this type of service. This would mean, of course, that we would not be developing the Launch Segment but would be defining the interfaces to it with the subcontractor team.

l  Subsystem: We could envision allocation at this level in the SNS involving the utilization of a commercially available satellite bus subsystem in the development of the Satellite Segment

l  Component: This is the level within the SNS architecture at which we would most likely allocate requirements to hardware, software, or manual operations. For example, the User Interface Subsystem of the User Segment would likely consist of two components, one hardware (an LCD screen) and one software (used to control the User

Segment).



[1] The other methods maybe depend on the role of the class in the relations among classes.

[2] The classes in the problem domain, containing business logic and the domain model.

[3] New classes to be responsible for special thing, such as draw, export etc.

 

一个完整的面向对象分析与设计例子

首先说明,接下来   这部分内容,跟面向对象没什么关系,只是描述出我们接下来 "需要做什么 ".  大家都知道电梯是怎么回事了,所以获取需求的过程我就不啰嗦了,直接把最后结果描述出来.(对于计算机专...
  • ls519585292
  • ls519585292
  • 2015年07月18日 11:46
  • 3432

Java面向对象的设计和分析

第一讲    面向对象思想 一、面向对象设计的重要经验         谁拥有数据,谁就对外提供操作这些数据的方法。 二、事例分析 1、人在黑板上画圈:         对象:person,...
  • hua631150873
  • hua631150873
  • 2013年09月17日 20:43
  • 1689

面向对象设计UML常用工具比较和品评

面向对象设计中,少不了UML建模工具相信大家有所了解。 那么你对UML建模工具Visio 、Rational Rose、PowerDesign、Enterprise Architect等工具比较之间...
  • wlanye
  • wlanye
  • 2015年01月07日 22:03
  • 1709

面向对象分析与设计——前言

书  名 面向对象分析与设计(第3版) 英文名 Object-Oriented Analysis and Design with Applications(Thi...
  • wangfei_edu
  • wangfei_edu
  • 2014年10月22日 08:40
  • 273

面向对象分析与设计(第三版)目录

http://www.kaoshi.sh.cn/book/30355/ 面向对象分析与设计(第三版) [美]Grady Booch 第1部分 概念 第1章 复杂性 2 1.1 复杂系...
  • iicup
  • iicup
  • 2011年08月03日 16:20
  • 546

[OOAD]面向对象分析与设计第一章学习总结

一、面向对象的基本思想 面向对象方法是一种运用对象、类、继承、聚合、关联、消息和封装等概念和原则来构造软件系统的开发方法。 面向对象方法的基本思想如下: (1)客观世界中的事物都是对象,对象间存...
  • lwfwylb
  • lwfwylb
  • 2013年06月06日 14:28
  • 650

面向对象分析与设计示例:骰子游戏

代码:class Die { int faceValue; public Die() { faceValue = 0; } public int getFa...
  • u011239443
  • u011239443
  • 2016年09月19日 16:16
  • 657

基于UML的面向对象分析与设计

[转自:http://www.uml.org.cn/mxdx/200901071.asp] 摘要 本文以实例的方式,展示了如果使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对...
  • yuanlong_zheng
  • yuanlong_zheng
  • 2012年04月04日 22:15
  • 720

UML的面向对象分析设计过程浅析

UML的面向对象分析设计过程浅析(转)   2010-12-12 23:32:00|  分类: uml|字号 订阅 UML面向对象技术的基本特征主要有抽象性、封装性...
  • legend_x
  • legend_x
  • 2013年12月27日 18:52
  • 703

面向对象分析与设计——过程

6           过程 以为有银弹;按指南步骤去做(滋生进度谎言);完全忽略文档,或文档驱动。   6.1   首要原则 6.1.1   成功项目的特征          成功的软件...
  • wangfei_edu
  • wangfei_edu
  • 2014年10月22日 13:04
  • 693
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:《面向对象分析与设计》摘录
举报原因:
原因补充:

(最多只允许输入30个字)