блогер
Регистрация: Aug 2005
Адрес: www.artcraft.cz
Сообщений: 1,967
|
фрагмент из книжки Advanced ActionScript 3 with Design Patterns.
кто переведёт?
Цитата:
Chapter 1. Designing Applications
One of the most frequent questions ActionScript developers ask is, "How do I know what constitutes a class?" This question strikes at the heart of a larger dilemma, which is: What are the steps for building a successful application from start to finishfrom concept to completion? This is a big topic to tackle. Many people dedicate themselves to understanding and improving methodologies to answer this question.
The difficulty with teaching someone how to design and build an application from start to finish is that it requires elements that are difficult to talk about much less teach. It requires being able and willing to look at the big picture as well as looking at things from many perspectives. It requires creative thinking as well as abstraction. It requires practice and experience. But there are steps you can follow to help with the learning process. There are technologies you can use to assist you in developing your ActionScript classes. This chapter outlines some of the steps and technologies that have proven useful for many ActionScript developers.
Some methodologies say there are five steps for building applications; other methodologies say there are eight steps; still others can't decide how many steps it takes. In general, most developers agree that there are at least three phases to building successful applications:
1. Analysis
2. Design
3. Implementation
In addition, most developers also agree that testing is a vital part of the application development process. Although not always considered a core phase we'll also look at testing as a fourth important phase.
As we look at each of these phases, remember that they are not necessarily linear. You can go back to an earlier step at any point if necessary. During the design phase, for example, you might realize that you forgot about an important use case for your application. At that point, you can return to the analysis phase. However, you should be as thorough as possible at each step. Don't jump to the design phase too early just because you can. The more thorough and complete you are with each phase before moving to the next, the more successful your application is likely to be. Additionally, thoroughness at each phase helps minimize the risk that you'll have to make major architectural changes later on, which could severely impact schedules and project success.
The Analysis Phase
The analysis phase is concerned exclusively with what the application is supposed to do. The question of how the application will accomplish the goal is deferred to the design and implementation phases. In many ways, the analysis phase can be the most challenging because it requires that you take (often vague) ideas and translate them into specific functional requirements. You must create a map of what the application looks like from a distance. Although you can get away with a minimal analysis phase for a small project, the analysis phase becomes increasingly important for a project's success as the project increases in size and scope. Although you might be able to walk around your neighborhood without a map, if you wanted to cross the country, you'll undoubtedly agree that you need a map. This is true of application development as well.
All too often, the analysis phase is glanced over or deemphasized. Poor analysis leads to frustration for all parties involved (the developers who have to constantly make guesses and refector, the managers who have the responsibility to see the project through to a successful completion, the client who wants the working application, customers that have to use the application that may suffer from limited feature sets and bugs due to poor analysis, etc.). The goal of analysis is to provide a clear specification that outlines the needs of the user. Unlike later phases, the analysis phase should be as non-technical as possible.
The outcome of the analysis phase is generally a document that outlines the functional requirements. However, it's important to understand that there are many ways to approach gathering these requirements, and the resultant document has no one required format. What is most important is that you, your team, and/or your company uses an approach and document format that works best for you while still achieving the goal of clearly defining this map for the application you want to build.
Although there's no one required approach or format, we'll present one common approach to analysis using use cases. If you are new to the idea of doing formalized analysis then you may find it useful to try using use cases. We also encourage you to research other techniques and document formats to find what works best for you.
Introducing Use Cases
One way to define the functional requirements of an application is simply to list everything that the application should be able to do. Although that approach is not necessarily wrong, it is naïve in that it fails to take into account the real-world use of the application. Applications don't exist in isolation; they interface with all sorts of users. Therefore, it's much more realistic and useful to approach the functional requirements from the standpoint of how the application is used. This approach naturally leads to a kind of functional requirement called use cases.
Use cases present the application requirements by showing various ways in which users might interact with the application. The following is an example of a simple use case:
- Generate Map: The user submits a form with a street address. The system displays a physical map of the street address, with the map zoomed in at the default level.
Use cases can be formatted in many ways. Generally, use case experts talk about three basic formats.
Brief: One paragraph outlining the main success scenario. The preceding example was in the brief format.
Casual: Multiple paragraphs outlining not only the main success scenario, but also alternative scenarios. The following is an example of a casual format use case:
- Generate Map
Main success scenario: The user submits a form with a street address. The system displays a physical map of the street address, with the map zoomed in at the default level.
Alternative scenarios: If the address is invalid, the address form is redisplayed with an error message notifying the user why the operation failed.
If the default zoom level is unavailable for the requested address, display a map at the greatest zoom level available for the location.
Formal: The most elaborate of the formats for a use case document. This format lists all the steps for the use case as well as supporting data such as actors and conditions. The formal use case is discussed in more detail in the next section.
Writing Formal Use Cases
Typically you'll want to create formal use cases for a functional requirements document. In this section we'll look at how to create a formal use case. A formal use case can include the following sections:
- Primary actor: A description of the user who drives the operations outlined by the use case. The description of the primary actor can include things such as the role of the user (e.g. anonymous, basic, administrator, etc.) as well as characteristics of the user that may be relevant to how they interact with the application (e.g. age, disabilities, etc.)
- Preconditions: Those conditions that must be met for the use case to proceed.
- Main success scenario: A more granular, step-based description of the way the application works than is given in the basic or casual formats.
- Alternative scenarios: More granular, step-based descriptions of the ways the application will handle alternative uses than are given in the casual format.
- Special requirements: A list of requirements for the use case that don't fit as part of the main or alternative scenarios.
- Open issues: A list of notes including questions that must be answered to fully implement a solution for the use case.
The following is an example of a formal use case. Note that this example does not have any open issues.
- Generate Map
Primary actor: Customer
Preconditions: Customer is already viewing the form that allows the user to specify an address and click a button to submit the form.
- Main success scenario:
1. Customer fills out address form.
2. Customer submits address data.
3. System requests map data from mapping service.
4. System draws map at default zoom level.
- Alternative Scenarios:
3a. System detects invalid address format and redisplays form with error message.
3b. Mapping service is unavailable and system displays error message.
4a. Data is not available for default zoom level and system displays map at next highest available zoom level.
- Special Requirements:
This portion of the application must be accessible (508 compliant).
Now that we've had a chance to see the structure of a formal use case, we'll next look at how to start writing these use cases for an application.
...
|
__________________
Хороший отдых - половина работы.
|
25.08.2007, 13:44
Линейный вид
