面向对象分析复习

The five attributes of a complex system

• Hierarchic structure

• Relative Primitives

  • The choice of what components in a system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system

• Separation of Concerns

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

• Common Patterns

  • Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements

• Stable Intermediate Forms

  • A complex system designed from scratch never works and cannot be patched up to make it work

 

 

 

The meaning of 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

• We like to use an principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less

 

The Meaning of Encapsulation

Encapsulation is most often achieved through information hiding, which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation fo its methods

 

The Meaning of Modularity

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

• For large software, a solution is to group logically related classes and objects in the same module and to expose only those elements that other modules absolutely must see

 

OOP的四大特征

抽象，封装，多态，继承

 

State

• Consider a ticket machine in subway. How do you define this class

• 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

• We mya say that all objects within a system encapsulate some state and that all of the state within a system is encapsulated by objects

 

Behavior

• No object exists in isolation. Rather, objects are acted on and themselves act on other objects. Behavior is how an object acts and reacts, in terms of its state changes and message passing.

• Most interesting objects do not have state that is static; rather, their state has properties whose values are modified and retrieved as the object is acted on. The behavior of an object is embodied in the sum of its operations

Interface and Implementation

• The implementation of a class primarily consists of the implementation of all of the operations defined in the interface of the class

  1. Public: a declaration that is accessible to all clients

  2. Protected: a declaration that is accessible only to the class itself

  3. Private: a declaration that is accessible only to the class itself

  4. Package: a declaration that is accessible only by classes in the smae package

• Consider two objects, A and B, with a link between the two. In order for A to send a message to B, B must be visible to A in some manner.

 

Measuring the Quality of an Abstraction

1. Coupling(weakly coupled classes are desirable; not for inheritance)

2. Cohesion(the elements of a class or module all work together to provide some well-bounded behavior)

3. Sufficiency(captures enough characteristics of the abstraction to permit meaningful and efficient interaction. If not, easy to detect when using it)

4. Completeness(Completeness is a subjective matter, and it can be overdone)

5. Primitiveness(Primitive operations are those that can be efficiently implemented only if given access to the underlying representation fo the abstraction)

Relationships among Classes

• Consider for a moment the similarities and differences among the following classes of objects: flowers, daisies, red roses, yellow, roses, petals, and ladybugs. We can make the following observations

  • A daisy is a kind of flower

  • A rose is a different kind of flower

  • Red roses and yellow roses are both kinds of roses

  • A petal is aprt of both kinds of flowers

  • Ladybugs eat certain pests such as aphids, which may be infesting certain kinds of flowers

• From this simple example we conclude that classes, like objects, do not exist in isolation. Rather, for a particular problem domain, the key abstractions are usually related in a variety of interesting ways, forming the class structure of ourr design

• There are three basic kinds of class relationships

  • The first of these is generalization/specialization, denoting an "is a" relationship. FOr instance, a rose is a kind of flower, meaning that a rose is a specialized subclass of the more general class, flower.

  • The second is whole/part, which denotes a "part of" relationship. Thus, a petal is not a kind of a flower: it is a part of a flower

  • The third is association, which denoted some semantic dependency among otherwise unrelated classes, such as between ladybugs and flowers. As another example, roses and candles are largely independent classes, but they both represenet things that we might use to decorate a dinner table.

 

Behavior Analysis

1. More akin to conceptual clustering: We form classes based on groups of objects that exhibit similar behavior

2. In this manner, we group things that have common responsibilities, and we from hierarchies of classes involving super classes that embody general responsibilities and subclasses that specialize their behavior

Domain Analysis

1. Domain analysis 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

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

• Briefly, we can apply use case analysis as early as requiremnets analysis, at which time end users, other domain experts, and the development team enumerate the scenarios that are fundamental to the system's operation.

• Analysis then proceeds by a study of each scenario. As the team walks through each cenario, they must identify the objects that participate in the scenario, the responsibilities of each object, and the ways those objects collaborate with other objects, in therms of the operations each invokes on the other

Structured Analysis

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

• This approach starts with an essential model of the system, as described by data flow diagrams and the other products of structured analysis, From this model, we may proceed to identify the meaningful classes and obejcts in our problem domain in three different way

• We must strongly emphasize that structured design, as normally coupled with structured analysis, is entirely orthogonal to the principles of object-oriented

 

Inception

1. Purpose: The purpose of the Inception phase is to ensure that the project is both valuable and feasible

2. Activities: During the inception phase, you establish and prioritize the core requirements of the system, obtain agreement with the customer on what is to be built, make sure you understand the key risks associated with building the system, and decide what development envirnment to use

3. Work Products: THe primary work products of the inception phase are a vision of what is to be built, behavioral prototypes, an initial risk list, the identification of the key architectural mechanisms, and the development environment

4. Milestone: Scope is Understood

Elaboration

• Purpose: The intent is to identify architectural flaws early and to establish common policies that yield a simpler architecture

• Activities: The Elaboration phase involves making architectural decisions, establishing the architectural framework, implementing the framework, testing the framework. testing the framework, and refining the framework based on the result of the testing

• Work Products: During the Elaboration phase, the architecture is validated by creating a series of executable architectural releases that partially satisfy the semantics of the key end-user scenarios

• Milestone: Architecture is Stable

Construction

• Purpose: The Construction phase is when you move from discovery into production, where production can be thought of as " a controlled methodological process of raising product quality to the point where the product can be shipped

• Activities: During the construction phase, the development of the system is completed, based on the baselined architecture produced during the Elaboration phase

• Work Products: During the iterations of the Construction phase, a series of executable releases are produced that satisfy the semantics of the remaining end-user scenarios

• Milestone: System is ready for end-user testing

Transition

• Purpose: The Transition phase is when you ensure that the software is acceptable to its end users

• Activities: During the Transition phase, the product is provided to the user community for evaluation and testing

• Work Products: The work products produced during the Transition phase include the packaged product, any supporting

• Milestone: System is ready to be deployed

Testing

• Unit testing involves testing individual classes and mechanisms. It is the responsibility of the application engineer who implemented the structure

• Component testing, which involves integration testing a complete component, is the responsibility of the component lead. Component tests can be used as regression tests for each newly released version of the component

• System testing involves integration testing the system as a whole and is the responsibility of the quality assurance team. System tests are also typically used as regression tests by the integration team when assembling new releases

 

The Benefits of Object-Oriented Development

• Appeals to the working of human cognition

• Leads to systems that are more resilient to change

• Encourages the reuse of woftware components

• Reduces development risk

• Exploits the expressive power of object-oriented programming languages

•