赵朝阳
2007-10-15
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 | Controller；Server；Proxy 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 Design：Key Abstraction; Mechanism
l Identify the classes that form the vocabulary of the problem domain（Key Abstraction）
l Invent the structures whereby sets of objects work together to provide the
behaviors that satisfy the requirements of the problem（Mechanism）
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: Reusability；Complexity；Applicability；Implementation 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 wasn’t ‘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万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
