1. English version of the e-book download: http://hnwhb.go.nese.net/prentice Hall - UML for Java Programmers.rar 2. Fully translated Chinese E-book Download Http://61.172.250.46/YANG/Private /BLOG /UML_FOR_JAVA_PROGRAMMERS_CN.RAR Related Website (Unfortunately, I can't connect) http://uml4java.go.nease.net/ 3. First Chapter 1 UML Overview of Java Programmers 1. UML (Unified Modeling Language) Three levels: 1. Conceptual layer (Conceptual) is close to the human natural language with ambitionless format 2. Specification (Specification)
3. Implementation specification layer and realization layer proximity code, no dismissal, strict format
2. UML is divided into three categories: 1. Static diagrams depict the logical relationships, objects, data structures, and the logical relationships existing between them. 2. Dynamic diagrams depicts how software execution processes and software entity status changes during operation. 3. Physical Diagrams depicts physical entities, such as: source files, library files, byte files, data files, etc., and the logical relationships thereafter. 3. Class map (static map) 1. Rectangular representation class, arrows expressed relationship. 2. All relationships in the figure are called associations, and the name of the object is associated. 4. Object chart (dynamic diagram) can be seen as a snapshot of memory, information in the main reactor in the runtime. 1. The object name is underlined. The name of the object type is followed by the colon. 2. The relationship link between the objects (LINKS), the link is named similarly to the variable name of the referenced object. 5. Sequence diagram (dynamic diagram) Several terms: 1. Guards 2. Construction 3. Data TOKEN 4. Activation 6. Co-collaboration map (dynamic diagram) number of sequences Structure 7. The different point of the collaboration map and the sequence diagram: the information they contain is the same: the relationship between the collaborative diagram describes the object, the sequence diagram describes the presence of the message executed. 8. Status diagram (dynamic diagram) The arrow in the FINATE MACHINES diagram is called transition 4. Chapter 2 Using Figure 1. Why do you want to make a model? The purpose of making a model is to prove whether the model can work normally. A model must have an available inspection standard. 2. Timing using UML: 1. You need to use it to determine if some things are available. 2. Use UML to verify that it is more cost-effective than using coding. 3. Effective use of UML 1. Use UML to communicate design concepts between developers. Use UML to create a specific algorithm corresponding to the specific algorithm, is not convenient. UML is useful for "road map" that creates large software structure. Through the UML map, you can clearly discover the dependencies between classes and classes and the structure of the entire system. 2. Reserved and abandon most UML maps are short-lived and should be discarded. Simply record on whiteboard or white paper. However, the following reviews should be saved: 1. The UML diagram of a general design solution in the system.
2. Record complex protocols, it is difficult to understand the UML diagram for code. 3. Provides a UML diagram that is less related to the "road map" within the system range. 4. It is easier to express the UML map of design intent than the code. These preserved UML maps should be repeatedly refined and modified, and the final version should be saved in the public area that the team can access. The UML map for long-term saving and temporary creation should be stored separately. 3. Iterative refinement first studies dynamic scenes and then determines the inherent meaning of the static structure. Multiple iterations for dynamic diagrams (such as collaboration) and static elements (such as: class diagrams) are continuously improved. 4. The timing that is best suited to create a document: The team completed all the work, the project is coming to an end. 5. Use the Interface to implement an event mechanism to avoid Button's dependence on Dialler. This can be dial after the button is pressed, or something else can be done. 6. The adapter adapter is also called an adapter for effective compatibility with different components of one or more pieces of instruments. The role of the adapter: implement the interface, forward the message. 7. When drawing UML graphs, you should imagine how to translate into code. 8. The goal of the UML map is not how it is correct, but to discuss someone understand it, so the UML map should be as simple as possible. 9. When do you draw a UML map: 1. Many people participate in the development, and these people need to understand the design structure of a particular part of the system, start painting the UML map. Everyone declares that it has been understood, stop the painting UML map. 2. There is an opinion between a design point between two or more people, and it is necessary to draw a UML map when discussing. After the discussion is completed, after the decision, stop the painting UML map. 3. Think about a design, draw a UML map. After thinking about maturity and complete the corresponding code, stop the Painting UML map. 4. When you explain to others or explain the logical structure of a code, start painting the UML map. When you find out more clever, stop the CD. 5. When the project is fast, the customer needs a UML map and a document, starting to draw a UML map. 10. Stop painting UML map: 1. Drawing is not a must-have. 2. Good designers can only encode and draw UML maps when they need it. 3. Do not draw a UML diagram for creating a comprehensive document before the coding, which is a waste of time. 4. Do not draw for others to encode. 11. UML Case Tool: 1. The UML Case Tools: 1. Genuine prices are expensive 2. You need to learn the cycle 2. Automatically draw the collaboration system of the UML map, you should consider it when you don't use it in your manual collaboration system. 3. The UML Case tool is used in the project or the UML Case tool integrated with the IDE, and the performance experiment should be performed first.
12. The documentation must establish a document, but you must create a document with cautiously. Software documents should be simple to simply 赅 A software document is usually inversely compared with the size of the document. Wiki is a good way to write a document in a team. 5. Chapter 3 Class Diagram 1. Class diagram depicts the information of the class itself, and the relationship between the class. 2. Category uses a square representation "-" indicates private (" " means public (PUBLIC), "#" indicates protected (Protected) Figure UML-5-2-1 Figure UML-5-2-1 PUBLIC CLASS DIALLER {Private Vector Digits; Int Ndigits; Public Void Digit (INT N); Protected Boolean Recordddigit (INT N);}; 3. In most cases, the object instance holds a reference to other objects . Figure UML-5-3-1 Figure UML-5-3-1 Corresponding code public class phone {private button itsbuttons [15];}; 4. Multiple Figure UML-5-4-1 Figure UML-5-4 -1 Corresponding code PBLIC CLASPNEBOOK {private vector itspnos;}; "*" indicates a lot, so Phonebook's member variable ITSPNOS is often used by Vector, List, or other containers. 5. Inheritance Convention: In order to facilitate distinguishing, the inheritance relationship is usually used in the vertical direction, and the associated is expressed in the horizontal direction. In UML, inheritance arrows refer to the base class. Figure UML-5-5-1 Figure UML-5-5-1 Corresponding code public class employee {...}; public class salaies {...}; dotted inheritance arrow indicates an interface. The dotted inheritance arrow points to the implemented interface. When drawing a dotted line on a whiteboard, you can replace it with a solid line.
Figure UML-5-5-2 Figure UML-5-5-2 Corresponding code interface buttonListener {...}; public class buttondialleradapter Implements ButtonListener {...}; another means of implementing an interface: Figure UML- 5-5-3 6. In a UML diagram, all methods will cause confusion, so only a batch of representative methods will make UML maps clearer. 7. Details and modifiers are not needed, but sometimes they are useful. 1. The structure of the structure of the class is displayed between a pair of double corner brackets and placed on the name of the class. Java has two standard constructive: 1. All member functions of Interface Interface are abstract 2. All member variables for Utility Utility and member functions are static. The structure of the class can be defined by themselves, but people who must read the UML map understand their meaning. 2. Abstract classes, abstract methods use oblique words or use {Abstract} properties to represent an abstract class or an abstract method. Figure UML-5-7-2-1 corresponding code PUBLIC Abstract Class Shape {Private Point Itsanchorpoint; Public Abstract Void Draw ();}; 3. Property 1. Attribute is not class Some, but can be used to represent additional information. Properties can be customized. 2. Form of attributes: Separate with a comma, consisting of the name, value pair. Such as: {author = matin, date = 20020429, file = shape.java, private} 3. The default value of an attribute is true, so {Abstract} equivalent to {Abstract = true} 4. The property is written in the class name Below. 5. An informal agreement: {Abstract} on the whiteboard can be short-handed into {a} 6. Generally only use {Abstract} properties. 4. AGGREGATION polymerization is a special form of association, indicating a whole / part / part relationship.
To prevent confusion, avoid using aggregated Figure UML-5-7-4-1 Figure UML-5-7-4-1 Code PUBLIC Class Whole {Private Part ITSPART;}; 5. Composition combination is one Special polymer form combination is very small involved in a depth replication problem. Figure UML-5-7-5-1 Figure UML-5-7-5-1 Corresponding code public class owner {private ward itSward;}; 6. MultiPicity object to hold an array or vector of other objects Or they can hold many of the same type but different instances. Multiple expression: The number is accurate, using an array as a container. * Or 0 .. * 0 or 0 to countless, use vector as container 0..1 0 or 1, usually implemented in Java to be implemented with an empty reference. 1. * 1 to countless, use vector as container 3..5 to 5, using array for container 0, 2..5, 9 .. * illegal expressions Figure UML-5-7-7-7-7-7-7-7-7 6-1 Figure UML-5-7-6-1 Corresponding Code Public Class BinaryTreenode {Private BinaryTreenode LeftNode; Private BinaryTreenode RightNode;}; 7. Associated Table 1. <> Standard UML Tag Source Object Creates a target object, The target object is then passed to other objects of the system. This association can be applied to factory models. Figure UML-5-7-7-1 Figure UML-5-7-7-1 Corresponding Code PUBLIC CLASS A {Public B Makeb () {Return New B ();}}}};
> Standard UML Tag Source Objects created an instance of a target object, regarding this instance as a local variable. Figure UML-5-7-7-2 with Figure UML-5-7-7-1, the structure associated with the figure is changed to <> Figure UML-5-7-7-2 Code PUBLIC CLASS A {PUBLIC Void f () {b b = new b (); // use b}}; 3. <
> Standard UML Tag Source objects The member function of the source object uses the instance of the target object as a parameter, and the source object does not save an instance of the target object. Figure UML-5-7-7-3 is changed to the structural type associated with Figure UML-5-7-7-1,
> Figures UML-5-7-7-3 Corresponding code public class a {public void f (b) {// use b}}; 4. <
> When the non-standard UML tag source object passes a member function of the target object, it is used
> <
> Can be applied to multiple patterns, such as Proxy, Decorator, and Composite7. Fighe UML-5-7-7-4 is changed to the configuration of Figure UML-5-7-7-1, the structure associated with
> Figure UML-5-7-7-4 Corresponding code public class a {private b itsb; public void f () {itSb.f ();}}; 8. Internal class Figure UML-5-7-8-8-8 1 Figure UML-5-7-8-1 Corresponding code PUBLIC CLASS A {Private Class B {...}}; 9. Anonymous Internal class UML has not provided official support for anonymous internal classes to provide an unofficial representation There is a <
> The structural embedding class is expressed. Figure UML-5-7-9-1 Figure UML-5-7-9-1 Corresponding code public class window {public void f () {actionListener L = new actionListener () {// importation};}}; 10 The associated class association class can further show how a special association is implemented. For example: For multiple sex associations, what container, Figure UML-5-7-10-1, Figure UML-5-7-10-1, corresponding code public class address {private vector itSlines;}; specific forms that associate classes can indicate References include unfixed references 2. SoftReference 3. Phantomreference Java 2 Reference Class Type Guide - How to effectively use SoftReference, WeakReference and PhantomReference http: // www -900.ibm.com/developerWorks/cn/java/J-REFS/index.shtml 11. Associated qualifiers use the associated qualifier when a certain type of keyword or tag is associated with the target object instance. Figure UML-5-7-11-1 Figure UML-5-7-11-1 Corresponding code public class loginservlet {private string Empid; public string getName () {Employee E = DB.GetName (EMPID); Return E. GetName ();}}; associated qualifier uses less use 12. Use less UML far more than UML.
6. Chapter 4 Sequence Diagram Dynamics P43 1. Points: 1. Do not establish a sequence diagram for each class, each method, which is too wasteful. 2. The sequence diagram should be used to represent the connection between the objects rather than the specific algorithm details. 3. The sequence diagram should not have a lot of objects and messages to return, and the essence should be grasped. 4. Try not to describe each small detail with a sequence diagram. 5. When the code can clearly explain itself, the picture is extra, wasteful. 6. It should be made to more code to clearly describe yourself, fewer use pictures. (Ie the readability of the enhanced code) 7. The small sequence diagram is easier to understand than the big serial diagram, so it is more practical. 8. The high-level graph is more useful than the low layer map because the commonality ratio is much different. 9. Sequence diagrams on the whiteboard for expressing and communicating with colleagues. The sequence diagram in the document is used to capture the outstanding system collaboration of the core. 2. Related terms: object, life lines, messages, data tags, activity Time in the same direction. Represents objects or participants' life cycles. 2. Different objects and classes: There is a horizontal line below the object name in the rectangle box, and there is no horizontal line below the class name. 3. A object or class participating in collaboration is placed laterally in the top of the sequence diagram. 4. Title Figure 1. Indicates anonymous participants, generally starting and ending from the messages. 2. Not all sequence diagrams have a person map, but most of them have. 5. Message 1. Represents an object to call another object (or class) member function. 2. The horizontal arrow between the lifeline, the arrow is the message name. 3. The parameters of the message are represented by data tags below the arrow, or placed in parentheses behind the message name. 6. Activation 1. Optional, most cases do not use 2. Along the vertical long strip of the lifeline 7. Return value indicates the left arrow of the return value without tagname. 8. Represents a way to create an object: A message that does not mark the name pointing to an object being created. 9. Represents a method of recovering an object: The life line of an object is terminated on one "X". The message arrow points to this "x", indicating that an object is reclaimed by GC.
10. A "loop" method: P49 Figure 4-8 Recycle expression prefix: * [while id: = idlist.next ()] 11. Represents "branch" method: P49 Figure 4-8 12. Tet time Message 1. A complete horizontal arrow for time. 2. Tet time, with the horizontal arrow with an angle. 13. Asynchronous message 1. Synchronize messages, use solid arrows. 2. Asynchronous messages, use the hollow arrow to repay the message to the control right after sending the message. 3. Sequence diagrams can be found in the asynchronous system of competition conditions (RACE CONDition). 14. Method of "Multithread": P54 Figure 4-12 Message Name Adding a thread tag prefix to display several different thread control. 15. A method of "Active Objects": Active object uses a bold box to represent 16. Method for "to send messages to interface": 1. Name the object to the interface, then use the general object . Here you emphasize the object in line with the interface, not an instantiation of the interface. P55 Figure 4-15 2. Although it is clearly known that the object's class type, still indicates that the message is sent to an interface. P55 Figure 4-16 7. Chapter 5 Model Illustration (USE Case) Static Figure P57 1. Concept: 1. Use cases are textual descriptions for action (behavioral) requirements. 2. One case is a description of the behavior of a system. This description is written from the perspective of one user. 3. An example captures a visual sequence of an event. This event is a response process of a system for a single user's incentive (STIMUS). 4. Using an example does not describe the mechanism hidden by the system, it only describes those who are visible. 2. Points: 1. It is a simple to keep the use case. 2. For those who have changed changes, they don't need premature to capture details. 3. The use case is written instead of drawing. 4. Prematurely use cases to record details that will change tomorrow will not be worth it. Unless these use cases will be implemented in recent weeks. The name of these use cases can be listed first, and maintain it. When they are being implemented, fill the details. 5. In all UML diagrams, the use case map is the easiest confusion and is most useless. But except the system boundary map. 3. Actair Cockburn's "Effective Writing Case" book can be found in other elements of the participant, secondary participants, pre-condition, and rear conditions.
4. System Boundary Figure 1. Uses: There are too little information provided by developers, but can be used as materials explained to customers. 2. Features: 1. Rectangular represents the system boundary. 2. Anything in the rectangle is part of the system that needs to be developed. 3. The rectangular exterior is a participant (ACTORS) interacting with the system. 4. Participants are external entities that provide incentives for the system. 5. Participants are usually human users, or other systems, even equipment, such as real time clocks. 6. Use example in the rectangle (elliptical with name) and the participant who stimulates its participants, and there is no arrow on the connection. 7. Try to ignore the use case relationship, because the use of the relationship will cause "expansion" or "generalization" debate.
8. Chapter 6 Object-Oriented Design (OOD) Principle P61 1. Learning the purpose of the five design principles to assess whether a group of UML maps or a batch of code is properly designed. 2. Appropriately designed system: It is easy to understand, it is easy to change, it is easy to be reused. It is not particularly difficult to develop difficult, simple, concise and economical. 3. Different ingredients of poor design: 1. Rigidity is difficult to modify. For a change, we must modify several places. 2. Fragility's modification of a certain part will make the problem that is not coherent. 3. Immobility is difficult to remove into components that can be reused. 4. Binding between viscosity modules is too close, editing, compiling and testing. 5. Unnecessary complexity 6. Unnecessary repetition (Needless Repetition) There is a lot of copy paste, and the code looks similar. 7. Opacity code cannot be clearly described. 4. Depending on the chaotic code is like the Italian fine noodles 5. Five Design Principles 1. Single Responsibility Principle (SRP) Single Responsibility PrinciPle P62 1. A class should have only one change 2. A class to handle things Too much, it will exude the fragility of vulnerability. 3. The example in the book is a class EMPLOYEE that is necessary to calculate the salary and read and write disk. 2. Open-Closed Principles (OCP) Open-Close PrinciPle P64 1. You should be able to change a surrounding environment without changing the class itself. 2. Regular violation of the OCP principle is the implementation of the GUI violates OCP, put all the behaviors into a class that uses the GUI API. Follow the OCP system, separating the manipulation of the GUI and the operation of the data.
3. Examples of books are a GUI implementation of data and operation P65 Figure 6-6 4. Unit test Self shunt man.com/Resources/articles/selfshunptrn.pdf 5. Design follows OCP In principle, you can change the surrounding environment of Dialog and Model to a test environment without any modifications to Dialog and Model. 6. Use abstraction (referred to as an interface and abstract class) to follow the key to the principle of OCP. 7. Methods to follow the principle of OCP: Usually prepare simple unit tests before writing actual code. This unit test is written using Test-First (test priority) method. 3. Liskov Replacement Principle (LSP) Liskov Substitution PrinciPle P77 1. Avoid derived methods illegally or degraded, and a base class should not need to know this derived class. 2. Users of the base class, should not be required to do special processing in order to use their derived classes. The special treatment here refers to the use of instanceOf or down-to-Downcast operation. 3. Two cases of violation of the principle of the LSP: 1. If you have an illegal use when calling a member function of a derived class, it has to throw an exception. 2. Use a degraded derivative method, degradation means that this method does not do. 4. Solution to violations of the LSP is to find a base class for derived classes, rather than barely derive from existing base classes. 5. Examples in the book are the troubles of the volunteer class as the derived class of EMPLOYEE. 4. Dependency Invert Principles (DIP) Dependency Invertion PrinciPle P79 1. Replace the specific class that relies on easily change with dependent interfaces and abstractions. 2. Follow the DIP principle to reduce changes in the influence of the system and reduce system sensitivity. 3. The specific class derived from abstract classes and interfaces is much more frequent than abstract classes and interfaces, so they rely on abstraction (referring to interfaces and abstraction), and do not rely on those that are easy to change. If you want to inherit a class, inherit from an abstract class. If you want to hold a category reference, it is referenced from an abstract class. If you want to call a function, call it from an abstract function.
4. Easy to change the specific classes: 1. Those specific classes that are being developed. 2. Those classes that are easy to change to capture business logic. 3. The VECTOR class or the String class is not a specific class that is easy to change. 5. Follow the DIP principles: Create and depend on the interface for those that are easy to change. 5. Interface Isolation Principle (ISP) Interface Separate PrinciPle P79 1. Give an interface to each user of an object, this interface only the user needs. 2. Fertilizer (FAT Class) A class with a pile method. 3. Trouble caused by fertilizers: The user of the fertilizer does not use most of the methods, but will be affected by changes in these methods. 4. Follow the ISP principles: Provide an interface that only contains the methods they need for fertilizers. 6. Application method of design principles: 1. Try to make the system time to follow all principles are unwise. 2. The best way to apply these principles is the reactively method: When there is a structural problem in the first time, or when the change in one module is the first time the change is affected by other modules , Try to apply these principles to solve the problem. 9. Chapter 7 DX Practice P83 1. What is DX practice? 1. DX practice is a set of rules, lightweight development processes.
2. DX practice is actually XP (extreme programming) practice, XP is in DX.
3. DX practice is a short cycle iterative process all things. All things include demand analysis, design implementation, testing, and documentation. The short cycle (ie iterative cycle) is two weeks.
2. Initial exploration 1. The first iteration exploration is demand, and it is generally not necessary to spend two weeks.
2. Customers are people responsible for demand and responsible for decisions.
3. Contents discussed with customers: 1. How to operate, some must function. It is not used as a detailed record, the goal is to understand the overall situation of the system.
2. Identify the use case to record the exemplary name on the index card, the card is User Story. Other important information can also be remembered on the card.
3. Feature Evaluation: 1. Evaluate the User Story and the calculation factor.
2. Evaluation Method: 1. As a found result, the evaluation result is based on the difficulty degree of new USER Story.
2. Use the number of days of "Perfect Programming" as a standard. "Perfect Programming" is not subject to any interference, programming in an extremely ideal environment. 3. After the evaluation, the User Story is merged and split. The number of days of the User Story should be controlled between 1 day to 4 days. Avoid overestimating your own strength, or assessing too conservative.
4. It takes two to three days, soon roughly realizes two, three more interesting User Story. The aim is to verify the evaluation, get the number of points, and the correspondence between the human sky. The person here is a rough implementation. Realization of quality and quantity is generally three times the rough implementation.
4. Explore 1. Calculate the initial speed initial speed = (3 multiplied by a rough realization) divided by the total number of use storys implemented by rough implementation.
5. Plan with the calculated speed as a standard, calculate the Story that needs to be completed in each iterative cycle.
6. Publish plan 1. Typical once release cycle, including six iterative cycles, if the team has five people, one iterative cycle is two weeks (ten working days), then one iterative cycle is 50 people, once The release cycle is 300 people.
2. The number of points that can be completed once a release cycle = 300 people × speed.
3. The customer picked out the most important and effective User Story of the total number of points (300 people × speed), as a release plan.
7. Iterative Plan 1. One iteration period is 50 people.
2. The number of points that can be completed in one iteration cycle = 50 people × speed.
3. Divide the User Story into the task. The task here is a simple task that a single developer can be responsible for 4 to 10 people hours. This subdivision requires customers to assist in identifying important and secondary user interfaces.
4. End of segmentation, developers pick the task that meets their own budget. For the remaining tasks, it is necessary to share. The last unresser, and the customer is discussed whether the customer has moved to the next iterative cycle. Until all tasks are allocated.
8. The midpoint is completed according to the number of points of the task in the previous iterative cycle, and the task is adjusted, canceled or increasing the task on the remaining tasks in the rear half.
9. Speed Feedback 1. The time for the end of the iterative period cannot be changed.
2. Recalcate the speed according to the actual completed point, as the basis for the next iterative cycle.
3. The new speed is the actual point of the last iterative cycle.
10. Connect the iteration and management phase 1. The four management phases of the "Unified Process" project: 1. Initial phase determines the feasibility and business case.
2. The refinement phase determines the system architecture and creates a relatively reliable implementation plan.
3. System implementation starts in the construction phase.
4. Turn over the phase installation system, test with the user (UAT test).
11. An iterative cycle includes: 1. Analysis requirements
2. Design solution
3. Implementation solutions only consider the User Story that needs to be processed during the current iteration.
12. Tuning to develop two developers working with the same machine to handle the tasks they are responsible.
13. Acceptable test 1. At the beginning of each iteration period, the client and QA enrich the User Story to the USE CASE, and write executable acceptance test cases.
2. For programmer acceptance test cases is a demand document.
3. Among the entire iterative cycle, the programmer continues to run the test case to ensure the correct test test. 14. Unit test 1. The code is not moved, and the test is first.
2. If you have any unit tests, you cannot write new product code.
3. The process of extreme iteration: 1. First write a unit test code of 5 to 10 lines.
2. Then in order to make this unit test code can be compiled, start writing and constantly enrich product code.
3. Once the unit test passes, you can add a new code to start a new iteration.
4. A test cycle is usually 1 to 10 minutes.
4. The purpose of the extreme iteration: whether it is progressing now, the product code before a few minutes can always run.
5. Unit test is also a form of documentation.
6. The information provided by the unit test code is: 1. How to call a specific API.
2. How to create a specific object.
7. This form of document is clear, accurate, compileable and executable.
15. Reconstruction: 1. Just use a large number of unit tests and acceptance tests to rely on mountains, you can reassurely modify any part of the need to modify.
2. Under the premise of do not change the behavior of the program, the internal structure of the improved program is reconstructed.
3. After the intermediate programming is over, it is a few minutes of sub-step reconstruction and then tested.
4. Never leave the bad code to the next day.
16. Open Office Environment: 1. There is very frequent communication and communication between members, you can quickly ask questions, get the fastest response and suggestions. Doing mutual relying on each other, crossing the code. Easy to make a pair programming.
17. Sustained integration: 1. CHECK IN rules: Only the code that tests and accepts tests through unit tests can CHECK IN.
2. Sustained integration can avoid project progress to an end to come to a very huge ultimate integration.
18. Documentation: 1. Martin document The first right law: only write the meaningful document that truly needs.
2. Don't specifically use class diagrams to capture all the needs.
3. Do not need to capture all USE Case in the sequence diagram.
4. Only when you really need to use these tools, otherwise you will let them go.
10. Packages P92 1. Two types of important packages of Java: 1. Sourcecap package. Package
2. Binary components. .jar
2. Java packages 1. Java packages is Name Spaces. They allow programmers to create small private spaces in order to declare classes. The names of these classes will not have conflicts with classes of the same name in other packages.
2. Several ways to represent a package in UML: 1. The icon of the package is a rectangular box, with a label on the top, like a folder. The complete package name is displayed in the middle of the rectangle. P92 Figure 8-1
2. You can also write the full package name in the tag on the rectangular box. The remaining large rectangle is listed in the package all classes defined in the package. P92 Figure 8-2
3. You can use the nested structure containing the relationship display package. P93 Figure 8-3
3. Dependencies in the same package often rely on the code in another package. This dependence is represented in UML (dependency). P93 Figure 8-4import does not create a real dependency, only the call function will create a dependency.
3. Binary components. JAR file (binary component) 1. UML represents a .jar component's way P94 Figure 8-5
2. A component often contains one or more packages, so the dependency between components is usually a subset of dependencies between packets.
4. Principles of Package Design 1. Follow the principles: 1. Easy class is placed together. 2. The class that is changed will be separated from a variety of reasons. 3. Independently open the category and uncommon-changing classes that often changes. 4. Separation system's high-level structure and underlying implementation details.
2. Release / Reuse Equivalency PrinciPle (Rep) 1. A group of reused classes should be placed in a package. This package is then published and tracked by those developers who use their developers.
2. Creating a package is to facilitate others to reuse.
3. The granularity of the reuse is the particle size released. The smallest thing for reuse is worthy of others to release and track.
3. The Common Closure Principle (CCP) 1. CCP is equivalent to the Single Liability Principle of OOD (SRP)
2. The class to be modified is placed in a package due to the same reason.
4. The Common Reuse Principle (CRP) 1. CRP is equivalent to OOD interface isolation principle (ISP)
2. The package that is only used by a customer should be as separated by a package that is used by a plurality of different customers.
3. Avoid modifications to a class in the package affect other customers who do not use this class.
5. The Acyclic Dependencies Principle (ADP) 1. The loop dependence of the package will result in compilation and development issues.
2. Avoid cyclic dependence in the dependent figure.
3. You can use the JDEPEND to check if there is loop dependence.
6. The Stable Dependencies Principle (SDP) 1. Package should not rely on those packages that are more unstable (easier to change) than them.
2. The package that each package is dependent is more stable than relying on their packages.
3. If a package has multiple dependencies, it relies on a changing package that is prone to changing, and the result will cause this package to change.
7. Stable Abstract Principle (SAP) 1. SAP is equivalent to OOD Open - Closed Principles (OCP)
2. In order to ensure that the stable package is easy to control, the stable package should be abstract. The more stabilized the package should be abstract. The larger the proportion of abstract classes and interfaces, the more abstract. 3. SDP principles and SAP principles are combined into the principle of the rendering of the package version.
4. Combined with the SDP principles and SAP principles can be obtained: 1. Stability increases with the increase in its dependence.
2. Abstractability should increase as stability.
3. So, abstraction should increase the increase in dependencies.
5. The package dependent map is helpful for solving the dependency loop problem and judging the compilation order.
11. Chapter 9 Object Diams P98 1. UML object map is like a snapshot of the system running.
2. The information contained in the object map is: 1. The system is at a particular moment, or the system is in an internal structure when a particular state.
2. The object and relationship are actually used.
3. The system is based on different input changes.
3. The object map is rarely used.
4. The tags used by the object map are the same as the class diagrams.
5. Another useful object of the object map is in the multi-threaded system. 1. Active object (Active Object) is represented by a thick line.
2. Active object is like a thread controller. They include methods of controlling threads, such as Start, STOP, SetPrioring, etc. P102 Figure 9-4
6. In multi-threaded systems, the object map is more expressive than class diagrams: this program structure is established at runtime, which is a structure of the object rather than the structure of the class.
7. Many object maps can be inferred from class diagrams, so fewer object map applications are relatively small.
12. Chapter 10 Stat Diagrams P103 1. State Transition Diagrams (STD) P103 Figure 10-1 1. State The state is represented using a circular corner rectangle.
2. The name of the state is placed in the frame of the circular corner rectangle.
3. The action triggered when entering or exiting the state. Placed in the frame of the circular corner rectangle.
4. Conversion between states Use the arrow to indicate the arrow to indicate the origin to the target state.
5. Status Conversion Arrow The tag: 1. Trigger the name of each event of the conversion.
2. Action that is executed when the conversion is triggered.
6. Initial Pseudo State is represented using a solid black circle. It indicated the starting state of the finite state machine lifecycle.
7. Super State Host State Suitable for multiple status to respond to certain events in the same way. Painting a super-state encloses those similar states, and then simply draw a state to convert arrows from each state.
The transition of the super state can be overloaded overloaded by the transformation of the sub-state. P106 Figure 10-5
Entry, EXIT, and special events are both super-state and general states.
Note: Event call sequence of super-state and its sub-status. P106 Figure 10-6
8. Dedicated events indicate the state of the circular corner rectangle of the state contains multi-pair events and actions. Writing form of events and action: Event / Action Two standard events are entry and exit.
You can customize the event.
9. The initial pseudo-state and end pseudo-state. The initial pseudo-state does not need an event, but there can be an action. This action is that after the finite state machine is created, the first one is called.
The action when converting to the end pseudo state is an action that is finally executed by a limited state machine.
10. Use of limited state machine diagrams: For systems that are increasing (ie, frequent changes), create STTS (State Transition Tables) in the document to use STDS (State Transition Diagrams).
Using a text language is more simple than graphics in development and maintenance of a limited state machine.
