Download
1 / 40
420 likes | 619 Vues
ניתוח ועיצוב מערכות תוכנה אביב 2012. תהליך הפיתוח האחוד (The Unified Process). Motivation: Analysis and Design Should Be Done Iteratively!. Presented 1981, this is one of the most famous graphs in Software Engineering.
E N D
ניתוח ועיצוב מערכות תוכנהאביב 2012 תהליך הפיתוח האחוד (The Unified Process)
Motivation: Analysis and Design Should Be Done Iteratively! • Presented 1981, this is one of the most famous graphs in Software Engineering. • The cost of removing a software defect grows exponentially for each downstream phase of the development lifecycle in which it remains undiscovered. • …And if you work in waterfall, you always get more distant from the early levels!
Topics Discussed in this Session • The UP: An Overview • What are the stages of the Unified Process (UP) • Which artifacts are created in each stage • Inception • Use Case Modeling • Identifying Requirements • Elaboration • System Sequence Diagram • Domain Model • Contracts • Design Class Diagram
RUP Phases and Iterations • At the end of each phase we reach a project milestone! • Inception: Is the project feasible? • Elaboration: Is the architecture stable? • Are all the primary risks mitigated? • Construction: Is the system ready for installation at the customer’s environment? • Common misconception: each phase matches a waterfall phase.
Write Use Cases Stories or scenarios of how people use the application. Brief: a paragraph of textual explanation. Fully Dressed: like we’ve seen in the previous Practical Session. Use Case Diagrams: can visualize the use cases and their connections. They are secondary in use case work: to create use cases is to write text.
Create A Domain Model • The noteworthy domain concepts or objects. • Visualization of the concepts or mental models of a real-world domain. • Also called: a conceptual object model.
Assign Object Responsibilities and Draw Interaction Diagrams • Usually sequence diagram. • Software object designs and programs do take inspiration from real-world domains… • But they are not direct models or simulations of the real world. • (Who rolls a dice? Player or Dice object?) • Designated Patterns exist and should be used (GRASP – more on this later).
Define Class Diagrams • Illustrates the attributes and methods of the classes. • Includes visibility and all operations. • In contrast to the domain model showing real-world classes, this diagram shows software classes. • Mind The (Representational) Gap.
How Does It All Connect? Partial Artifacts refined at each Iteration
You don’t understand UP when… • You think that inception = requirements, elaboration = design, and construction = implementation (that is, superimposing a waterfall lifecycle on to the UP). • You try to define most of the requirements before starting design or implementation. • You try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing. • A "long time" is spent doing requirements or design work before programming starts. • You think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code. • You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one. • You want believable plans and estimates for projects before the elaboration phase is finished.
Inception • Inception in one sentence: Envision the product scope, vision, and business case. • The main problem to solve in one sentence: Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?
Inception: An Analogy toOil Business In the oil business, when a new field is being considered, some of the steps include: 1. Decide if there is enough evidence or a business case to even justify exploratory drilling. 2. If so, do measurements and exploratory drilling. 3. Provide scope and estimate information. 4. Further steps... • The inception phase is like step one in this analogy. In step one people do not predict how much oil there is, or the cost or effort to extract it. It is premature— there is insufficient information. Although it would be nice to be able to answer "how much" and "when" questions without the cost and effort of the exploration, in the oil business it is understood to not be realistic. • In UP terms, the realistic exploration step is the elaboration phase. The preceding inception phase is akin to a feasibility study to decide if it is even worth investing in exploratory drilling. Only after exploration (elaboration) do we have the data and insight to make somewhat believable estimates and plans. Therefore, in iterative development and the UP, plans and estimates are not to be considered reliable in the inception phase. They merely provide an order-of-magnitude sense of the level of effort, to aid the decision to continue or not.
You Know You Didn't Understand Inception When... • It is more than "a few" weeks long for most projects. • There is an attempt to define most of the requirements. • Estimates or plans are expected to be reliable. • You define the architecture; rather, this should be done iteratively inelaboration. • You believe that the proper sequence of work should be:1) define the requirements; 2) design the architecture; 3) implement. • The names of most of the use cases and actors were not identified. • All the use cases were written in detail. • None of the use cases were written in detail. Best Practice:10-20% should be written in detail to obtain some realistic insight into the scope of the problem.
Understanding Requirements:Types of Requirements (FURPS+) In the UP, requirements are categorized according to the FURPS+ model [Grady92], a useful mnemonic with the following meaning: • Functional—features, capabilities, security. • Usability—human factors, help, documentation. • Reliability—frequency of failure, recoverability, predictability. • Performance—response times, throughput, accuracy, availability, resource usage. • Supportability—adaptability, maintainability, internationalization, configurability. The "+" in FURPS+ indicates ancillary and sub-factors, such as: • Implementation—resource limitations, languages and tools, hardware, ... • Interface—constraints imposed by interfacing with external systems. • Operations—system management in its operational setting. • Packaging • Legal—licensing and so forth.
Use Case Model:Writing Requirements in Context • Objectives: • Identify and write use cases. • Relate use cases to user goals and elementary business processes. • Use the brief, casual, and fully dressed formats, in an essential style. • Relate use case work to iterative development.
Formality Types Use cases are written in different formats, depending on need. Use cases are written in varying degrees of formality: • brief—terse one-paragraph summary, usually of the main success scenario. • casual—informal paragraph format. Multiple paragraphs that cover various scenarios. • fully dressed—the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.
Brief Format Use Case:an Example 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.
Guideline: The EBP Use Case • For requirements analysis for a computer application, focus on use cases at the level of elementary business processes (EBPs). • EBP is a term from the business process engineering field, defined as: “A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. e.g., Approve Credit or Price Order.”
Finding Primary Actors, Goals,and Use Cases • Use cases are defined to satisfy the user goals of the primary actors. Hence, the basic procedure is: 1. Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization? 2. Identify the primary actors: those that have user goals fulfilled through using services of the system. 3. For each, identify their user goals. Raise them to the highest user goal level that satisfies the EBP guideline. 4. Define use cases that satisfy user goals; name them according to their goal
Identifying Other Requirements • Write a Supplementary Specification, Glossary, and Vision. • Compare and contrast system features with use cases. Relate the • Vision to other artifacts, and to iterative development. Define quality attributes.
From Inception to Elaboration Elaboration is the initial series of iterations during which: • The majority of requirements are discovered and stabilized. • The major risks are mitigated or retired. • The core architectural elements are implemented and proven.
Elaboration in one sentence: Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources. Some key ideas and best practices that will manifest in elaboration include: • Do short, timeboxed risk-driven iterations • Start programming early • Adaptively design, implement, and test the core and risky parts of the • Architecture • Test early, often, realistically • Adapt based on feedback from tests, users, developers. • Write most of the use cases and other requirements in detail, through a • series of workshops, once per elaboration iteration.
You Know You Didn't Understand Elaboration When... • It is more than "a few" months long for most projects. • It only has one iteration (with rare exceptions for well-understood problems). • Most requirements were defined before elaboration. • The risky elements and core architecture are not being tackled. • It does not result in an executable architecture; there is no production-code programming. • It is considered primarily a requirements phase, preceding an implementation phase in construction. • There is an attempt to do a full and careful design before programming. • There is minimal feedback and adaptation; users are not continually engaged in evaluation and feedback. • There is no early and realistic testing. • The architecture is speculatively finalized before programming. • It is considered a step to do the proof-of-concept programming, rather than programming the production core executable architecture. • There are not multiple short requirements workshops that adapt and refine the requirements based on feedback from the prior and current iterations. If a project exhibits these symptoms, the elaboration phase was not understood.
Use Case System Sequence Diagram • Identify system events. • Create system sequence diagrams for use cases. • A system sequence diagram (SSD) is a picture that shows, for a particular • scenario of a use case, the events that external actors generate, their order, and • inter-system events. All systems are treated as a black box; the emphasis of the • diagram is events that cross the system boundary from actors to systems. • An SSD should be done for the main success scenario of the use case, and frequentor complex alternative scenarios.
Domain Model:Visualizing Concepts Objectives: • Identify conceptual classes related to the current iteration requirements. • Create an initial domain model. • Distinguish between correct and incorrect attributes. • Add specification conceptual classes, when appropriate. • Compare and contrast conceptual and implementation views.
Domain Model (cont.) • Using UML notation, a domain model is illustrated with a set of class diagrams • in which no operations are defined. It may show: • • domain objects or conceptual classes • • associations between conceptual classes • • attributes of conceptual classes • Some software systems are for domains that find very little analogy in natural • or business domains; software for telecommunications is an example. It is still • possible to create a domain model in these domains, but it requires a high • degree of abstraction and stepping back from familiar designs. • For example, here are some candidate conceptual classes related to a telecommunication • switch: Message, Connection, Port, Dialog, Route, Protocol.
Contracts – An Example • Contract CO2:enterItem • Operation:enterItem(itemID:ItemID,quantity:integer) • Cross References: Use Cases: Process Sale • Preconditions: There is a sale underway • Postconditions: • A SalesLineItem instance sli was created (instance creation). • sliwas associated with the current Sale (association formed). • sli.quantitybecame quantity (attribute modification). • sliwas associated with a ProductSpecification, based on itemID match (association formed).
GRASP: Designing Objectswith Responsibilities The following sections present the first five GRASP patterns: • Information Expert - Assign a responsibility to the information expert: the class that has the information necessary to fulfill the responsibility. • Creator - Assign class B the responsibility to create an instance of class A. • High Cohesion - Assign a responsibility so that cohesion remains high. • Low Coupling - Assign a responsibility so that coupling remains low. • Controller - Assign the responsibility for receiving or handling a system event message to a class.
Design Model:Creating Design Class Diagrams • Create design class diagrams (DCDs). • Determine Visibility • Identify the classes, methods, and associations to show in a DCD. • A (short) Example from Larman – The Dice Game.
Summary • In the next iteration we start by updating our UP artifacts (use case model, domain model) according to the last iteration insights. • Choose a different use case (or more than one) to express in a fully dressed mode. • Continue to realize it via the discussed techniques from above according to the last iteration insights. • We continue to do this until the product is finished.
Benefits of Iterative Development (vs. waterfall) • Earlyrather than late mitigation of high risks. • technical, requirements, objectives, usability, and so forth. • Early visible progress. • Programmers program early, testers test early etc’. • Early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders. • Managed complexity; • The team is not overwhelmed by "analysis paralysis" or very long and complex steps • The learningwithin an iteration can be methodically used to improve the development process itself, iteration by iteration.
