Lecture 6: Analysis and Design DescriptionsKenneth M. AndersonUniversity of Colorado, BoulderJanuary 27, 20051January 27, 2005 © University of Colorado, Boulder, 2005OverviewDiscuss the various types of system descriptions that can be used during analysis and designUse Cases (in brief, more in Lecture 7NarrativesScenariosConversationsAnnotationsCRC Cards2January 27, 2005 © University of Colorado, Boulder, 2005BackgroundDuring analysis and design, we willcapture requirements,brainstorm candidate objects and roles,consider trade-offs and design alternatives,and make decisionsIn order to document these activities, we need various types of software artifactstraditional requirements documents, UML diagrams, Use cases, etc.The format of these artifacts provide us with a means to structure and capture the information we are working so hard to create3January 27, 2005 © University of Colorado, Boulder, 2005User PerspectiveIn analysis, as much as possible, we want to write our artifacts from the standpoint of a userWe will make frequent and consistent use of domain-related vocabulary and conceptsWe will talk about the software system as a “black box”We can describe its inputs and its expected outputs but we try to avoid discussing how the system will process or produce this informationUse cases are a technique for maintaining this perspectivewe identify the different types of users for our systemwe then develop tasks for each of the different types of user 4January 27, 2005 © University of Colorado, Boulder, 2005ActorMore formally, a user is represented by an actorEach use case can have one or more actors involvedAn actor can be either a human user or a software systemActors have two defining characteristicsThey are external to the system under designThey take initiative and interact with our systemTypical types of users will includeCustomers, “Front-Line” Employees, Administrators, Security Personnel, Managers, etc.5January 27, 2005 © University of Colorado, Boulder, 2005Use CasesEach use case describes a single task for a particular actorThe description typically includes one “success” case and a number of extensions that document “exceptional” conditionsIn our text book, three different types of use case are presentednarratives, scenarios, and conversationsIn lecture 7, we will see a more formal version of the scenario style of use caseUse cases are used to capture functional requirementsThey can be annotated to also describe non-functional requirements but typically the focus is on functional requirements only6January 27, 2005 © University of Colorado, Boulder, 2005Example: Word ProcessorOur textbook makes use of a word processor as an example domain for analysis and design descriptionsThis domain has a number of real world counterparts, but be aware that this example is inherently “tool focused”In the “real world”, you will be tackling larger problem domains, understanding a specific problem within that domain, and then creating tools (or a single software system) to address that problemThis domain has a number of primary concepts that will emerge during analysis and design discussionsDocument, Page, Paragraph, Spell Checker, etc.7January 27, 2005 © University of Colorado, Boulder, 2005Use Case NarrativeA narrative is a brief, high-level description of a user task; A narrative consists of typically one or two paragraphs of natural language textNarratives are highly informal and typically leave out a lot of details that will need to be filled in at a later timeThey are useful when discussing a new task for the first timeExample8Documents can be saved in different file formats. When you save a new document, the default file format is used unless another is specified. When a Save Document operation has completed saving an existing document, the file represents accurately the document as displayed to the user upon savingJanuary 27, 2005 © University of Colorado, Boulder, 2005Narratives DiscussedFrom the example, we can see that narrativesmay not be labeled or otherwise have a titlemay not explicitly identify an actormay use undefined termsHowever, they allow for the quick capture of functional requirements and identify areas in the domain that require additional analysis and/or descriptionFor instance,What is a file format? What’s the default format? How is a “Save Document Operation” invoked?9January 27, 2005 © University of Colorado, Boulder, 2005Use Case ScenarioA scenario describes a specific path (through a software system) that a user will take to complete a taskEach step will describe either an action taken by the user (or actor) or a response generated by the system under designAs we will see, each step should be kept as simple as possibleUse case scenarios require a particular writing styleWe will cover guidelines for writing effective use cases in Lecture 7The scenario should end with the successful completion of the given task10January 27, 2005 © University of Colorado, Boulder, 2005Example: Saving an HTML Doc11Save a document to an HTML File1. The user commands the system to save a file.2. The system presents a "Save File" dialog box.3. If the file is being saved for the first time, the system will construct a name for the file using a default file extension and the first line of text in the document.4. The user indicates the HTML document type from the dialog.5. The system replaces the default extension with ".html"6. The user selects a directory for the file.7. The user clicks the "Save" button in the dialog box.8. The software warns the user that some formatting information may be lost in the transformation to HTML. It gives the user a chance to cancel the operation.9. The user asks for the operation to continue.10. The software saves the document in HTML format in the location specified by the user.Scenarios will typically contain a title and list the sequence of actions needed to successfully complete a taskScenarios can be informal (like this example) or extremely formalScenarios can also indicate extensions that show how to handle error conditionsJanuary 27, 2005 © University of Colorado, Boulder, 2005Use Case Conversations12Use case conversations go one step further than scenarios to explicitly identify the system responsibilities that are implied by an actor’s actionsThese responsibilities begin to reveal explicitly the functional requirements of the system under designRecall that the creation of these responsibilities
View Full Document
Unlocking...