Software method reading notes (iii)

Business modeling maps out the identification of system use cases: in a business sequence diagram, messages from the external point to the research system can be mapped to the system's use cases.
Considerations for identifying system use cases:
First, the main performer and the auxiliary performer: the main performer points from the performer to the use case, while the secondary performer points to the performer from the use case, the main performer initiates the interaction of the use case, and the secondary performer passively participates in the interaction. Scenario: The main performer is required to execute the use case, which requires the help of a secondary performer.
Second, do not put the arrows to the auxiliary performer as the direction of data transmission.
Third, the primary and secondary performers are for a use case, a system in this use case as the main performer, you can also act as a secondary performer in another use case. Generally speaking, the auxiliary executor is the human flesh system situation is relatively few, more time is another non-intelligent system.
Iv. use cases are stakeholders willing to"buy"of the system, a"usage", as long as the stakeholders are willing"buy", of course, the more the better.
V. Demand is not considered"Multiplexing", if in consideration of"Multiplexing", it is important to tiglate whether they have switched to a design perspective to think about problems.
Six, for different performers, different business processes, the system provides the value can be large or small, regardless of size are use cases.
Vii. naming of Use cases. Use case naming takes"movable-Object structure", the object can be added attribute, the subject of a sentence cut off, the rest can do the name of the use case.
Common mistakes: Research business processes, do business modeling, as far as possible from the business sequence diagram to map out the system use cases, such a system use case is not deceptive.
First, the steps as a function example.IncludeThe purpose of the (include) relationship is to reuse a collection of steps that recurs across multiple use cases, often with multiple large use casesIncludea small use case.
TwoCRUDproblem. Adding, retrieving, modifying, and deleting the names of the tables in the database gets the name of the use case or merges the four operations called"XXManagement".
Third, play"Multiplexing": The implementation of the use case is different, the stakeholder interests behind the difference, can not be simply combined reuse for one operation.
A plurality of main performers point to the same use case. If the use case diagram is complete, modifications to this error can be made by generalizing the abstract performer or by dividing it into several different use-case methods. The latter one is more common.
V. Playing"level". Never swap"Research Objects", and never"the vision as a system function".
Six, play"Subsystem": Use cases can be separated by a lot of use cases , but the use case package is the division of system functions outside the system, while subsystems are based on the coupling and cohesion of internal components.
VII: Fuzzy value: When the system often cannot commit to the expected value of the performer, then the value is not the executor's use case. When the main performer executes the use case, the use case is correct, or the use case is incorrect if it is necessary for the secondary performer to provide real-time help.
About"XXManagement"use case: This use case cannot be mapped from the orchestration, but the system needs them to support it. Only use cases that support the management of basic data"XXManagement"to clean the battlefield. "XXManagement"Such use cases are often used for administrators to manage basic data, and are all stereotyped.
of software Engineering"Bottom": How can I make this code easier to maintain and extend? What does this code mean for the stakeholders to achieve the functionality and performance?

2).system use Case specification: that is, as a use case to organize the requirements of the specification, we need to write the use case specification to encapsulate the various related requirements behind the use of expression, and the class diagram to show the contents of the use case.
What the use case contains:
A.Preconditions and Post conditions: Use cases express requirements in the form of contracts through preconditions and post conditions.    It can be imagined that a post condition can be achieved when the pre-condition is met, followed by the path steps described.
Post-condition classification: Minimal back-up and successful post-placement. The minimum post refers to the constraint that should be satisfied in the case of the failure of the use case, while the successful Post refers to the constraint that the system needs to satisfy when the use case succeeds.
Requirements for pre-and post-conditions:
First, the precondition, the post condition must be the system can detect.
The precondition must be the system can detect before the use case starts.
Third, the pre-condition is the constraint, not the action.
Four, the front-facing conditions to have a systematic taste.
Five, the issue of login: login is not a use case, can not be seen from the sign-in extension production orders and other functions, the extension of the true meaning is branch. The correct approach should be to change the login to be included in other use cases included in the use case, when writing the use case specification found that the order, check, and other use cases have login steps, in order to save the workload of these form a small target set of steps to isolate a use case can only be included in other use cases. such as: Member login, parenthesis sign-in indicates that this is a included use case, his steps and constraints are described in another place.

Stakeholder interest Requirements: The precondition is the starting point, the post-condition is the end point, this middle of the most content is the stakeholder interests, that is: what kind of people worry about what, hope for what, if there is no stakeholder benefit is difficult to get the right demand. Recognizing that demand is determined by the balance and conflict of stakeholder interests can help us to reach the core of our needs.
First, how to find stakeholders: Positioning the use case stakeholder scenario: If this use case of the system does not work well, who or which system will suffer? Who would worry about their direct interests being violated?
Trigger the search for stakeholders from the performer: if the performer is a person, it is the use case stakeholder. Otherwise, the performer does not have a benefit proposition, not a stakeholder, but pay attention to the possible stakeholders behind it.
From"Upstream"looking for stakeholders: The performer uses the system to make a use case, and requires some resources that the provider of these resources may be a stakeholder.
From"downstream"looking for stakeholders: The performer uses the system to make a use case, which can have consequences, and the people affected by the consequences are also stakeholders.
From"the owner of the information"finding stakeholders: the benefits of some people (or perhaps unaware of the existence of the system) involved in use cases are affected by the system's good or bad. As the strategic environment changes, the organization needs to adjust, the original good system really wants to change, this is the real demand change.
From"arrange for the stakeholder"find the main stakeholder: whether the stakeholder row is accurate, directly affect the content of the demand, developers do not only stare at the"User"and ignoring the front-row stakeholders. There is no certain criteria, can only be summarized according to the characteristics of the improved organization.
“brother, Ming accounts": When describing stakeholder interests, the different interests of different stakeholders should be reflected. After listing stakeholder interests, the interests of the front-row stakeholders need to be balanced and balanced against those of other stakeholders. Stakeholder interests in the use case specification can be reflected in different stakeholders for different use cases have different benefits of the characteristics.
“Basic Path": We need to write out paths, steps, and supplemental constraints that balance the interests of all stakeholders. Use cases need to have a basic path, several extension paths, first separate the basic path first written out, because it represents the use case core value of the path.
Key points of the writing path step:
1.)follow the interactive four-step script: The performer interacts with the system from round to end until the goal is reached. Each round step is divided intoTwo categories: request, response (some rounds may not validate and change), where parentheses indicate operations within the system.
2.)use the active statement to clarify responsibility: put the person responsible for the action in the subject position, withCockburnwords are"where's the ball?".
3.)the subject can only be the main performer or system. When writing a requirement, the system is treated as a black box, describing only the functions and performance that it provides externally, and how the system constructs a scope that is not part of the requirements description.
4.)Use the concept of the core domain: The path step is a functional requirement and should be described using the concept of the core domain, that is, to say" Speak". Should avoid"Technology","Business"and other nouns, and swap"Core Domain","non-core domain"to replace.
5.)do not involve the details of the interactive design: Avoid bringing the interface details into the requirements. "people have glasses."not demand, demand is"people can see".
Criteria for demand: demand is a question"is that okay?", but not"Is that okay?". Requirements do need to be written in thin, need to write the needs (problems) thin, rather than the design (solution) write thin.

Software method reading notes (iii)