At the end of the initiation phase, high-level use cases can be used as a basis for planning the rest of the project (Chapter 4). To save space for an in-depth presentation of the topics, most of the exercises can be accessed on the Internet.
CHAPTER
This book
A technique for expanding use cases that reduces the disparity between descriptions created by different analysts (the concept of mandatory and complementary steps allows one to decide exactly how many steps a use case should have). An interface design presented using IFML (Interaction Flow Modeling Language), a brand new OMG standard for interface modeling.
Object-oriented systems development
An original approach to writing system commands and queries is contracted with the use of the object constraint language, OCL (Object Management Group, 2010) that allows automatic generation of executable code, and not just post-condition checking, as current tools do . A systematic technique to generate dynamic object models from OCL contracts, which follows good design patterns and significantly reduces the amount of code needed to run an application, avoiding, for example, redundant validations.
Unified Modeling Language (UML)
Unified Process (UP)
2RUP (Rational Unified Process) is the oldest and best known implementation of Unified Process. Depending on the prioritization of use cases, it is expected that the number of changes applied to the software architecture will decrease as the project progresses during development.
The process so far
Questions
Introduction to business modeling
In this case, the purpose of business modeling is not only to find the requirements, but to verify the effective viability of the new business. Well-defined and stable requirements at the beginning of the project (for example, creating a replacement for an existing system) reduce the need to perform intensive business modeling.
General view of the system
The system overview is the basic document of the contract between the client and the developer. The system it supports must manage the company's acquisition and sales processes.
Business use cases
- Business actors and business workers
- Automation opportunities
The business use case diagram shows that the automation project will include book buying and selling processes and the clerk role. The next step leading to requirements analysis is a detailed study of the business use cases that will be automated.
Business activity diagram
- Basic elements
- Control flow nodes
The flows coming out of the decision node must have wait conditions (a logical expression in parentheses). The diagram in Figure 2.8 is still a very crude representation of the actual process of selling books.
State-dependent aspects of a business
For example, a book may or may not be a special offer from the time it is ordered from the publisher to the time it reaches final status as released or sold. Thus, a book can be modeled with two simultaneous states: the first state determines whether it is a special offer or not, and the second state determines the offer.
Remarks
The process so far
Questions
Introduction to high-level requirements
The short version of the use cases correspond to the high-level requirements, and the extended use cases correspond to the full set of requirements. Determining and analyzing requirements therefore corresponds to discovering the use cases of the system and their properties.
System actors
In some situations it can also happen that a function corresponds to a single use case and vice versa. This usually happens with very simple use cases such as reports and entity management.
System use cases
- Single session
- Interactive
- Consistent result
- Essential
- Brief
- System boundary
The above internal processes are either part of a use case (such as Calculate Taxes is part of Buying Books), or additional requirements (such as Storing data in a relational database). In that case, when modeling system use cases, the Clerk disappears, and the use case is executed by the customer itself.
How to find system use cases in the business model
However, the activities performed by the business workerClerk that are automated become internal actions in the system. The system usage model completed with information found on the state machine diagram in Figure 2.15.
Requirements
- Requirements elicitation
- Eliciting requirements is not design!
- Requirements challenges
- Evident and hidden functional requirements
- Nonfunctional requirements
- Permanence and transience of nonfunctional requirements
- Mandatory and desired requirements
- Supplementary requirements
It is more expensive and complex to develop the system (for example, it must contain functionalities for changing the currency). It is easier and faster to maintain the system (if the currency changes, the system is already prepared with a simple reconfiguration). Security Confidentiality To what extent should the information and functions of the system be available only to those authorized to access it.
Should the system be designed so that its parts can be reused in future projects. To what extent should the system be responsible for achieving these goals in a complete and correct manner. Effectiveness Effectiveness What kind of return on investment (ROI) should the system provide the customer.
Comfort To what extent must the system maintain or improve physical and mental user comfort. To what extent must the system be used efficiently, effectively, without risk and with user satisfaction in its contexts of use.
Preliminary conceptual model
At the same time, by observing the conceptual model, an analyst could notice whether the use case diagram is sufficiently complete. At that point, the team could decide to change the name of the use case to the Pay order. Perhaps the name of the use case at that time should be changed to Register order return.
The decisions to change use case names to clean up the vocabulary are already implemented in Figure 3.10. For example, a query for information about a book, given its ISBN, should not be considered a report use case because that query is already included in the CRUD use case. If this list is to be consulted only at the moment an order actually arrives and is to be recorded, then the query must be considered part of the Receive Books use case and must not be included in the diagram.
Also, CRUD and report use cases cannot be included in the main use case diagram if the system is at least moderately sized. They should be listed somewhere else (for example, a spreadsheet or a separate use case diagram), so as not to contaminate the main use case diagram.
The process so far
Questions
This chapter shows how to plan and develop a project using iterations, risk analysis, and effort estimation based on high-level use cases. It explains how the effort to develop the project is estimated based on the perceived complexity of each use case and other functions of the system and the development team. Finally, the chapter explains how to organize a series of incremental iterations based on a prioritized list of use cases and risks, which is the backbone of the development plan with the Unified Process.
Introduction to effort estimation and risk analysis in software projects
- Ad hoc techniques
- Parametric techniques
- Risk analysis
The advantage is that the project will not cost more than expected, but often the scope of the system will not be completely covered. The cost of the project is equal to the price that is believed to win the contract. The same amount of source lines of code may take more or less time to develop depending on the technical complexity of the system.
In both methods, effort multipliers are a numerical index that is multiplied by the estimated system size to produce the effort estimate. The team must discover and be aware of conditions that may cause problems in a project. Usually at least two attributes must be identified: the probability of the occurrence of the condition causing the risk and the impact the risk has on the project.
The project manager must therefore be aware of it and pay close attention to the status of the risks during the entire project. Development system: Is there sufficient hardware and other tools for the development of the project.
Use case point analysis 6
- UAW unadjusted actor weight
- UUCW unadjusted use case weight
- UUCP unadjusted use case points
Another problem with use case point analysis is that the team's understanding of what constitutes a use case can lead to disparate estimates. The technique of use case point analysis is included in the Unified Process because that process is strongly based on use cases. Use case point analysis is based on the quantity and complexity of system actors and use cases, which corresponds to the unadjusted use case points (UUCP) value.
Human actors interacting with the system through a graphical user interface are considered complex and receive 3 use case points. An alternative way to estimate the complexity of a use case is by the number of classes needed to implement the use case functions. Another way to estimate the complexity of a use case is by analyzing its risk.
Applying that technique to the example of Figure 3.11, there are eight use cases stereotyped as reports, which receive 85540 use case points. Finally, there are 10 use cases without any stereotype with higher risk, which receive 10155150 use case points.
- TCF technical complexity factor
- EF environmental factors
- UCP adjusted use case points
T2 Response Time/Performance Goals: What is the importance of an application's response time to its users. The application requires six or more of the items below, but there is no user performance requirement. The following items should be considered to evaluate the end-user performance item:9.
In addition to 3, a security plan must be developed and tested to support access control to the application. Already existing code that may need to be modified will be used in small parts of the application. There are formal specific user training requirements and the application must be designed to facilitate training.
The application must be designed to be accessible only to authorized users. E2 Experience in the application: This factor assesses the team's familiarity with the application area or domain.
UUCP TCF EF For the running example we obtain
- Effort
- Calendar time and average team size
- Counting methods for detailed use cases
- Planning an iterative project
- Estimating the duration of iterations
- Number of iterations
- Effort per use case point
- Team load capacity
- Defining use case priority
- Planning phase and iterations
- The process so far
- Questions
- Introduction to expanded use cases
- Main flow
- Alternate flows
- Scenarios
- Variants
- Exception handling
- Writing recommendations
- Essential versus real use case
- Explicit information
- Identification and selection
- Mandatory steps
- Complementary steps
- Unsuitable steps
- Included use cases and fragments
- Expansion of stereotyped use cases
- Report expanded
- CRUD expanded
- Other sections of an expanded use case
- Stakeholders
- Preconditions
- Success post-conditions
- Open issues
- System sequence diagrams
- Elements of a sequence diagram
- Expanded use cases as system sequence diagrams
- Connecting the interface to the fac¸ade-controller
- Stateless strategy
- Stateful strategy
- Alternate flows in system sequence diagrams
- The process so far
- Questions
- Introduction to conceptual modeling
- Attributes
- Attribute types
- Initial values
- Derived attributes
- Enumerations
- Primitive types
- Concepts
- Unique attributes
- System control class
- Associations
- Role multiplicity
- Association direction
- Derived association
- Aggregation and composition
- n-ary associations
- Collections
- Ordered set
- Sequence
- Partition
- Relation
- Organization of the conceptual model
- Generalization, specialization, and inheritance
- Association classes
Typically, a use case has a main scenario (execution of the main flow) and alternate scenarios (executions of the main flow that bypass one or more alternate flows). These two possible ends can be represented as mainstream versions of each use case. However, this is not necessary to understand the information flow of the use case.
For example, the system must inform the actor about the total value of the purchase in the use case Order Books. If the client is not immediately available, this doubt should be recorded in the use cases section. Design the system sequence diagram for the main flow of the use case of Figure 5.2, choosing one of the following strategies: stateless or stateful.
