Overview
1. Rough analysis of the development process. Two things to do in software development: demand (what to do) and design (how to do)
2. Detailed analysis of development processes: business modeling, demand |||| Analysis, design, implementation, testing.
a) Business modeling can be skilled
b) Analysis and design may merge
3. All development methods are to satisfy the above flow. For example, the previous waterfall model, new RUP, XP, and MS methods. However, the current new method is the use case drive, the architecture is core, iterative.
4. The entire product flow throughout the UP includes multiple loops, each cycle includes multiple stages, each of which includes multiple iterations, each iteration, multiple workflows. The first stage decides whether it is feasible, refine the stage to complete the architecture, and complete most of the encoding during the construction phase, and the shipping version is generated. Each iteration will pass all core workflows, but the side focus is different.
5. Each iterative step: demand, analysis, design, implementation, test five core workflows.
6. In order to support UP, UML is usually used. But UML is not only applied to UP.
7. Difficulties are not how to paint, but what is painting.
Development Process 0: Business Modeling
1. In 8.pdf
2. Objective: Describe reality and help find software needs. Business processes are business use cases. Business use provides value for business executors. What is IBM? A bunch of value streams.
3. It is not necessary, not necessarily related to software development.
4. Business construction models help clearly.
5. Results Workpiece: Business Example Model and Business Object Model
6. Business modeling steps:
a) Determine business unit: Contains the organization of most people using the system.
b) Identify business executivers
c) identify business use cases. Note that business use cases must be available. Generally, a subsystem is generally granulated. Two ways to identify.
d) Detailed Description Business Example: Insert a text using an active diagram ( Note Number Basic Path).
e) Establish a business object model
7. Event map
Starting point, end point, activity, lane, migration and migration conditions, determination, parallel, object flow.
8. Establish business object model: people, things and relationships in real life. Includes business workers and business entities.
9. Improvement point of business model to system model
a) Information automatic flow
b) Interpretation of complex business logic
c) Access and operate business entities
d) automatic work
10. Possible correspondence to the system model
a) Business use case-> system (subsystem)
b) Business executive -> system executor
c) Business workers -> system executor
d) activity -> system use case
e) business workers, business executors, business entities -> physical classes
Development process 1 demand
1. 2.pdf
2. Vision: Why is it developed? The vision goal must be measurable.
3. Features and countermeasures for demand:
a) difficult to capture -> From the perspective of users
B) Violet -> Reasonable Structure
4. The use case is a reasonable method that satisfies the above two conditions. Use an example document is a demand document.
5. Use example: There is a hierarchical demand form, so it is easy to generate a reasonable structure.
Use a low precision, stable
path
step
Supplementary constraints high precision, unstable 6. Steps:
a) identify the executor
b) Identification
c) Writing case example document
d) By relationwork
e) Sort and subcontract of use case
7. System executor: Anything that interacts with the system directly with the system outside the system.
a) outside the system
b) through the system boundary
c) interact directly with the system
d) meaningful interaction
e) anything
8. Use an example instance is a series of actions executed in the system, which will generate the value results visible to a particular executor. One case is defined as a set of use case instances.
a) Value results -> meaningful goals
b) System execution -> value results are generated by system
c) Visualists visible -> Business language, user point of view
d) A set of use case examples -> The size of the use case
9. Name the case: the movie structure, avoid an inwenty words and weak names.
10. There is no particle size using an example, do not take the step as an example. Try not to use crUd as an example, because they generally do not provide value, too careful, is considered from the perspective of the database. Multiple use cases may also operate the same data, and a plurality of data operations may be hidden behind a use case. If it is determined as crUd, merge into managed ***, you can use create as a master path, read, update, delete as other optional paths. Do not involve interface details.
11. There is such a paragraph in the book "Patterns for Effective Use Cases:
It is relatively easy to identify low-level transactions while it can be difficult to identify useful services. It is usually easier to describe the individual routine transactions that a system may provide than it is to discover what the user really wants to do with the system . Doing it the easy way often leads to the so-called 'CRUD' (Create, Read, Update, and Delete) style use cases. It is not unusual to see use cases with names like "Create Employee Record", "Read Employee Record ", or" Delete Employee Record ". While such use cases may be technically correct, they do not capture what is valuable to the user. Is creating an employee record important, or do we theyreally want to" Hire Employee "?
12. There is only one master executor for each use case.
13. Does each use case meet the vision? Whether all the vision is satisfied by using the case?
14. Writing use case document. See UCText.pdf file.
a) number, name
b) executor
c) front conditions, post conditions
d) the interests of the people. People involved in the use of care.
e) Basic path f) extended path.
g) Field list, business rules, non-functional requirements, design constraints. They collectively refer to supplementary constraints.
1) Field list: Describe each step, including connotation and extension.
15. Use case relationship: (not important)
a) Extension: Separate the extended path. See UC4.
b) Contains: Extracting a common path for easy reuse.
c) Generalization: Different technologies for the same business purpose. It can be replaced with an extension.
Development process 2 analysis class diagram
1. 4.pdf
2. Functional distribution, from the perspective of the process of decomposition, from the object-oriented perspective is collaboration.
3. Use examples to convert to classes, objects, relationships, responsibilities, and collaboration by analyzing and designing. The use case is the appearance, the latter is a mechanism.
4. The object has status, behavior, and identity.
5. Category: Share the collection of public structure and behavior.
6. Steps to analyze graphs
a) Identification class and attribute
b) Identification between the identification class
c) the association between the identification class
d) (note, do not analyze behavior)
7. Method for identifying classes and properties:
Use case-extract à list table - Identify à and attributes, while refer to the domain model.
The basic path of the use case is obtained, the expansion of the Luojing and the supplementary constraint.
8. Two analysis routes: physical drivers and responsibilities.
9. Review graph:
a) Properties of class: What is
b) may have redundancy, but sometimes redundancy is reasonable
c) Handling complex structural properties: If 1 pair 1, you can deploy in the original class; if 1: n, independently exit formation of associations.
d) Whether attributes make sense to all objects of the class. If not, decompose only the properties of some objects to the subclass.
10. Class relationship:
a) Generalization: collection relationship, subclasses have superclad characteristics by inheriting
b) Association: Individual relationship, objects with other objects by assembly
11. Method for identifying generalization: A object is always B object, B object is sometimes a object. A generalization relationship should not be formed between classes in different fields.
12. The meaning of the association: an object is a static dependency of another object. Includes connection, polymerization, and combinations. Different from dependence, dependence is dynamic.
13. Differences between aggregation and combinations: all the relationship between the overall and part, the combination is more than the polymerization relationship. Reflected in C , the combination is the value, and the polymerization is the pointer. When the combination object is dead, the combined object will be dead; but the polymerization will not be.
14. Beware of database habits: If there is already an association, the corresponding attribute should be deleted.
15. Analyze common mode
Development process 3 analysis sequence diagram
1. 5.pdf
2. Complete responsibility allocation by painting sequence map
3. In the analysis phase, all classes are mainly divided into boundary classes, control classes, and entity classes.
a) Boundation class: Each executor of the use case is imaged as a boundary class. Responsible for interacting with outside
b) Control class: An example map is a control class. Responsible for controlling the event stream, responsible for assigning responsibility for entity class.
c) Entity class: modeling the information and related behavior necessary to store. One case may have multiple entities. A solid class can also be applied to multiple use cases. It is the main responsibility of business behavior.
4. Mapping of sequence diagrams and class diagrams (example)
a) Introduction to the message: The operation of the class object ---- Responsibility. b) The outlet of the message: Class object completes the cooperation required for operation ---- collaboration.
5. Sequential drawing points
a) Location: Under each use case, the path to the corresponding example
b) Basic path: a picture
c) Simple extension points: merge to the basic path, use text description conditions
d) Complex extension points: a separate figure, and the Note connection between the main map
6. Responsibility between the entity class
a) Total principle: low coupling, high cohesion
b) Three important principles:
I. expert principle: assign responsibility to experts
Ii. Board principle: When the polymerization / combination occurs, the call to the polymerization is required to have a polymerization.
Iii. Visual principle: There is only messaging between classes that happen.
c) The new entity class may be generated when assigning responsibility.
7. Status diagram
a) Take an object from all sequential diagrams (one physical class may be applied to multiple use cases).
b) Status: A combination of attribute values for the same behavior in the system.
c) Migration: Attribute value changes lead to behavioral changes.
Development process 4 design
1. 6.pdf
2. Analyze the emphasis on business concepts and design emphasis on platform implementation. The two are sometimes merged.
3. The whole software is divided into: represents the layer, the business layer, and the logic layer.
4. Data layer
a) Mapping storage
b) Construct the data source layer
5. Mapping storage
a) Map class and attribute: class-> table, object -> line, attribute -> column
b) Mapping generalization relationship: superclass and subclasses are mapped into tables, and the hyperbited primary key is the primary key of all classes.
c) Mapping connection relationship: 1 pair 0..1 (foreign bond is placed in 0..1), 1 pair 1 (outside of any end), 1, more (foreign bonds), more (Add a third sheet)
d) mapping
e) Mapping
6. Modeling tool automatic mapping
7. Construct the data source layer ("Database Design Mode")
a) Table data entry
b) line data entrance
c) Activity record
d) Data mapping device (O / R mapping)
8. Business layer mode:
Transaction script, domain model, table module, service layer.
9. Interface layer (MVC, Struts)
10. Design mode
11. Test: Unit test.
12. Implement the view: build graphs and deployment diagrams.
