Bài Giảng Phân tích thiết kế hướng đối tượng (phần 2)

Chia sẻ: Nguyen Kien | Ngày: | Loại File: PPT | Số trang:48

Thêm vào BST

Báo xấu

150
lượt xem 38
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Inception Lecture 2 Hoa Sen University 1 .Agenda       Recap Inception overview Evolutionary Requirements Use cases Other requirements Assignment 1 instruction Hoa Sen University 2 .What we learned last week  Difference

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài Giảng Phân tích thiết kế hướng đối tượng (phần 2)

Inception Lecture 2 Hoa Sen University 1
Agenda  Recap  Inception overview  Evolutionary Requirements  Use cases  Other requirements  Assignment 1 instruction Hoa Sen University 2
What we learned last week  Difference between analysis and design  Different focuses of functional decomposition and object-oriented approach  Benefit of OO approach  UML  Iterative development  Agile modelling Hoa Sen University 3
Inception Questions  What is the vision and the business case for this project?  Feasible?  Buy and/or build?  Rough estimate of cost: $10K, $100K, $1M, …  Should we proceed or stop? Hoa Sen University 4
Goals of Inception  “…to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system.”  Envision the product scope, vision and business case  Do the stakeholders have basic agreement on the vision of the project? Is it worth investigating seriously? Hoa Sen University 5
Artefacts in Inception Artefacts Comments Vision and Business Describe the high-level goals and constraints, the business case, and Case provides an executive summary Use-Case Model Describes the functional requirements. During inception, the names of most use cases will be identified, and perhaps 10% of the use cases will be analysed in detail Supplementary Other requirements specification Glossary Key domain terminology, and data dictionary Risk List & Risk Describes the risks (business, technical, resource, schedule) and ideas for Management plan their mitigation or response Prototypes and proof-of- To clarify the vision, and validate technical ideas concepts Iteration Plan Describes what to do in the first elaboration iteration Phase Plan & Software Low-precision guess for elaboration phase duration and effort. Tools, Development plan people, education, and other resources Development Case A description of the customized UP steps and artefacts for this project. Hoa Sen University 6
It is not an inception if  It takes more than a few weeks  You attempt to define most requirements  Estimates are expected to be reliable  You define a concrete architecture  No business case or vision document  Too little or too much use case modelling Hoa Sen University 7
Hoa Sen University 8
Understanding Requirements  “Capabilities and conditions to which the system and project must conform” [Jacobson et al., 1999]  Challenges: {find, communicate, record, manage} the requirements  Requirements always change, so effective management is critical Hoa Sen University 9
Evolutionary vs. Waterfall requirements  UP embraces change in requirements as a fundamental driver on projects  Start production-quality programming and testing long before most of the requirements have been analysed or specified. Hoa Sen University 10
The FURPS+ Model  Functional – features, capabilities, security  Usability – human factors, help, documentation  Reliability – failure frequency, recoverability  Performance – response times, throughput, accuracy, availability, resource utilization  Supportability – adaptability, maintainability, internationalization, configurability Hoa Sen University 11
The FURPS+ Model  Implementation – resource limitations, languages/tools, hardware  Interface – with legacy systems  Operations – sysop management  Packaging – delivery, installation  Legal – licensing, etc. Use FURPS+ as a global checklist when identifying requirements for a system you are designing Hoa Sen University 12
Other Terminology  Quality Attributes, or “-ilities” – Usability, reliability, supportability, performance (non-functional)  Functional vs. Non-Functional – Behavioural features vs. everything else  The quality attributes have a strong influence on the architecture of a system Hoa Sen University 13
Document Requirements  Primarily, in the use case model – functional requirements  Also, Supplementary Specifications – other requirements  Glossary – noteworthy terms  Vision – high-level requirements  Business Rules – Requirements or policies that transcend one software project – many applications in the same domain may need to conform to them Hoa Sen University 14
The Use Case Model  “Writing Requirements in Context”  Identify user goals, corresponding system functions / business processes  Brief, casual, and “fully-dressed” formats  Iterative refinement of use cases Hoa Sen University 15
Stories  Using a system to meet goals  E.g. brief format – Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line- item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a Receipt from the system and then leaves with the items. Usually, writing the stories is more important than diagramming a use case model in UML Hoa Sen University 16
Definitions  Actor: something with a behaviour; person, system, organization  Scenario: specific sequence of actions and interactions between actor(s) and system (= one story; success or failure)  Use Case: collection of related success and failure scenarios describing the actors attempts to support a specific goal Hoa Sen University 17
Examples  Handle Returns – Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item… – Alternate Scenarios:  If they paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash.  If the item identifier is not found in the system, notify the cashier and suggest manual entry of the identifier code  If the system detects failure to communicate with the external accounting system… (etc.) Hoa Sen University 18
Why use cases?  A key attitude in use case work is to focus on the question ‘How can using the system provide observable value to the user, or fulfil their goals? rather than merely thinking of requirements in terms of a list of features or functions  Focus on business process, not technology features Hoa Sen University 19
Common use case formats  Brief: one-paragraph summary, main success scenario – When? During early requirements analysis  Casual: multiple, informal paragraphs covering many scenarios – When? Also early requirements analysis  Fully-Dressed: all steps and variations written in detail with supporting sections – See http://alistair.cockburn.us/usecases/usecases.html – When? Before each elaboration starts, do it for a portion of use cases selected for the following elaboration Hoa Sen University 20