OO UML summary and Lessons Learned

OO UML summary and Lessons Learned

First, the architecture analysis

Two UML resolver, primarily progressive, the first interpretation FIG class, second class diagram based on the increase check rules and the state and sequence diagrams of FIG.

The main idea of ​​the overall architecture has five points:

1, as far as possible to restore FIG structure itself (assembly)

2, the classification (the state diagram, a sequence diagram, a state diagram)

3, the relationship between the elements separated

4, the same type of element to be merged

5, abstract Element

 

Start with the class diagram in terms of:

1. Restore

Each class has attribution, operation

Each operation has a parameter

So there

UMLPARAMETER-->UMLOPERATION + UMLATTRIBUTION -------> UMLCLASS

A similar operation on the interface, you can inherit Class

Simply draw a class diagram their relationship is probably the case

 

We simply by json in _parent id and we can put them together this contact, bringing the completion of the reorganization.

 

For the second resolver Here are some small change (check elements of the same name):

Since FIG class checks need to check for duplicate names Class end asscociationEnd Attribution of itself. That associationEnd will belong to Class, so the contents of AbstractClass the need to increase the storage asscociationEnd (just add a container inspection methods and rules, not the overall difficulty, be made a small expansion)

 

2, the relationship between the separation elements

The main relationship is between classes, inheritance, implementation, association.

Since UMLClass is our topmost element assembly, and its relationship with the natural level, on any inside are not appropriate, and therefore chose their separate strategies.

We have established a separate Relation to store them.

Parsing json -> recognition type -> can be classified storage.

 

For the second resolver Here are some small change (Inspectorate):

Whether or repeat inspection cycle inherited inherited inspection, the relationship between these two are integrated (inheritance, implementation), and thus for ease of operation, where a selection increase RelationCheck class construct and implement an inheritance relationship configuration of FIG. And then use a variety of search methods (such as DFS) can easily solve these checks.

 

It can be seen, under this architecture, progressive twice resolver class diagram for the reconstruction of the situation will not arise, just do a small amount of expansion, to complete.

 

And then on to the next state diagram it

1. Restore

Like the class diagram, in accordance with the hierarchy :( relationship is simpler than the class diagram point)

UMLState + UMLTransition --> UMLReion --> UMLStateMachine

Restructuring can

public class AbstractStateMachine {
   private String name;
   private String id;
 
   //Region
   private String regionId;
   
   // UMLTransition
   private HashMap<String, UmlTransition> idToTranstion = new HashMap<>();
   private HashSet<AbstractTrans> transHashSet = new HashSet<>();
   
   //UMLState
   private HashSet<AbstractState> states = new HashSet<>();
   private HashMap<String, AbstractState> idToState = new HashMap<>();
   private HashMap<String, ArrayList<String>> nameToState = new HashMap<>();
   
   //RELATION
   private HashMap<AbstractState, HashSet<AbstractState>> transRelation
           = new HashMap<>();
   private HashMap<AbstractState, Integer> idToSubCount
           = new HashMap<>();

May find that how it seems Region and State level level, mainly due to the fact Region of inquiry no Dayong, StateMachine more like a puppet? ? ?

2. Consolidated

This is what I want to focus on the topic for this job.

I think this is one of the successful design point: For easy to modify, develop and design

 

State

The state machine has three states: UmlFinalState, UmlPseudostate, UmlState, state statistics need to consider these three, but the state transition is carried out in these three, so we can use a AbstractState class instead of three.

public class AbstractState {
   //0: state -1:init 1:final
   private int type;
   private String name;
   private String id;
   
   public AbstractState(int type, String name, String id) {
      ...
  }
   
   @Override
   public boolean equals(Object obj) {
       if (obj != null && obj instanceof  AbstractState) {
          ...
      }
       return false;
  }
   
   @Override
   public int hashCode() {
       return type;
  }
  ...
}
   

You do have a good modifiability, we can define, what is the common state? .

Such as for previously it has been more controversial issues such as whether to merge the initial state, simply modify the equals method can be overridden.

 

Similarly, Transiton also used the same method.

package stategraph;

import java.util.ArrayList;

public class AbstractTrans {
   private String id;
   private String name;
   private AbstractState source;
   private AbstractState target;
   private String guard;
   private ArrayList<String> triggers;
   
   public AbstractTrans(String id, String name, AbstractState source,
                        AbstractState target, String guard,
                        ArrayList<String> triggers) {
      ...
  }
   
   @Override
   public boolean equals(Object obj) {
       if (obj != null && obj instanceof  AbstractTrans) {
          ...
          }
           return false;
      }
       return false;
  }
   
   @Override
   public int hashCode() {
       return 1;
  }
 
  ...
}

Also, what is the same state, we can define this, once the rules have changed, you can also just change this place. (Although the last limit of the test data, there is no place Dayong)

 

3, separation

Here, similar to the operation of the class diagram, the architecture of FIG stored as metastasis. Note that, in consideration of integration problems, and therefore it may be encapsulated by a class AbstractTrans, rewriting can be achieved by merging the equals method.

 

The last is the most simple sequence diagram :

The overall sequence diagram is relatively simple.

1. Restore

With class diagrams, according to the hierarchy:

UMLLifeline + UMLMessage ----> UMLInteraction

Restructuring can

public class AbstractInaction {
   private String name;
   private String id;
   //UMLLifeline
   private HashMap<String, UmlLifeline> idToLifeLine = new HashMap<>();
   private HashSet<String> represent = new HashSet<>();
   private HashMap<String, ArrayList<String>> nameToLifeLine = new HashMap<>();
   //UMLMessage
   private HashMap<String, UmlMessage> idToMessage = new HashMap<>();
   //RELATION
   private HashMap<String, Integer> messageIn = new HashMap<>();
  ...
}

2, the relationship with the separation of elements? ? ?

(1) Interation affiliation with the message, not the same level

(2) simple query command, without any graph algorithms related operations

Therefore, we do not use here, just add two containers to store and look at the statistics to

 

Evolution Second, the architecture design summary and understanding of OO methods

OO architecture of four cells is enormous transition from object-oriented and process-oriented one.

A first unit, much initial design considerations functional problems, resulting in the polynomial derivation is not layered design (the factor, mixed together with other items, by the recursive processing, so that very OO)

The second unit, the elevator is designed primarily security issues multithreading. I met more difficulties, poor infrastructure has led to increased likelihood of not thread-safe. But after various reference multithreaded design patterns, and the elevator consider scheduling sub-section, the architecture has been some improvement, but the degree of hybridity code is still relatively high.

The third unit, JML part due to the TA provides a general framework, I have more to think about the design level, the overall idea and structure are improved.

The fourth unit, UML is what I consider the merits of expanding and architectural design of most of the time. More focus on the next one can easily increase the functionality of the content, and in their own debug and modify the process, come to understand very big advantage.

I think that OO design can not blindly start to consider algorithm (functional) and AC issues, more focus should be at the level of disassembly.

To the fourth unit as an example

(1) The ultimate goal of the design (interaction, the highest level)

(2) most of which is divided into several (sequence diagrams, state diagrams, FIG class)

(3) For each part, a small part of what

The main functional parts and elements considered part

For example, there are elements of state diagram of the migration, the status, function is the query.

For part of the elements have to make the appropriate level package (that is, fully demonstrated the inheritance relationship between classes, relationships)

(4) what kind of data structure? ?

(5) the specific algorithm

In fact, as long as (1) - (3) key consideration (usually hierarchical graph can be drawn on paper (such as using UML))

(4) make sure consideration (5) there is a breeze

In summary

(1) greater than write code thinking and design, functional design allows good levels to some extent more easily.

(2) OO is designed to help better, higher quality AC, if you start too much to consider AC, but just the opposite (painful lesson).

 

Third, test understanding

From the very beginning the job using the manual test, after two operations to try to start to write your own polynomial evaluation mechanism.

From the verification method of fixing the result of the uncertainty of how to multi-threaded test to verify the correctness of the preparation.

Overall the black-box testing to Junit unit test

From test to test the correctness of the running time.

Above, the test probably shows the change in thinking I OO (almost every change is ringing off the hook after the bitter experience several points)

I think the test

(1) both the accuracy and run time (accuracy and ensure good use of methods and structures implemented)

(2) both overall and unit tests (I later adopted the course of the encoding side edge JUNIT, have to say, correctness more secure)

(3) automatic evaluation is very important (using a random sample to test, by running longer period of time, to ensure coverage of the issue of black-box testing)

 

Fourth, the curriculum harvest

1, encoding capabilities: With practice this term a dozen jobs, the scale of operations so that their ability to significantly improve the code.

2, under pressure: Pro dll repeatedly modified bug, have successfully modified, there is unsuccessful modifications, this experience is indeed very ability to exercise the right to modify the code and to ensure that short period of time.

3, needs analysis capability: the contents of instructions is analyzed, and gradually transformed into a programming language.

4, as well as understanding and recognition of OO, the test of experience, this is a huge leap forward.

V. Recommendations

1, the proposed curriculum group provides platform independent testing: The testing and evaluation of errors on the test machine running time, it is recommended to open a platform for everyone, so that everyone can be tested on it, get run-time, multi-threading, and card TLE's part of the job is very helpful.

2, the local content can consider the early release of some prep tasks, so make the machine when more targeted to deal with, and will not know what to do.

3, appropriate follow-up notice requirements for the job: conducive to better develop the design.

 

Guess you like

Origin www.cnblogs.com/thunderZH-buaa/p/11075303.html