Week 6 Notes - Software Architecture and Design
Week 6 Notes - Software Architecture and Design ITIS 3310
Popular in Software Arch and Design
verified elite notetaker
Popular in ComputerScienence
verified elite notetaker
This 4 page Class Notes was uploaded by Jakeya Flood on Friday October 2, 2015. The Class Notes belongs to ITIS 3310 at University of North Carolina - Charlotte taught by Lance Peterman in Summer 2015. Since its upload, it has received 28 views. For similar materials see Software Arch and Design in ComputerScienence at University of North Carolina - Charlotte.
Reviews for Week 6 Notes - Software Architecture and Design
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 10/02/15
Chapter 6 Requirements Modeling Scenarios Information and Analysis Classes Requirements Model Objectives 0 Remember to focus on what not how 0 Objectives for a requirements model are 0 Describe what the customer requires 0 Establish the basis for designing the software solution 0 Define a means of validating the solution Analysis Model Rules of Thumb 0 Focus on requirements that are visible within the problem or business domain ie a high level of abstraction 0 Each element should 0 Add to an overall understanding of software requirements 0 Provide insight into the information domain function and behavior of the system 0 Delay consideration of infrastructure and other nonfunctional models until design 0 This is more how than what 0 Minimize coupling throughout the system 0 Reduce interconnectedness as much as possible 0 Be certain that the analysis model provides value to all stakeholders 0 Keep the model as simple as it can be 0 Don t add diagrams unless they cover new perspectives 0 Use simple representations if possible Domain Analysis 0 Domain analysis is oriented towards the business 0 The domain within which the system will function and whose operations it serves 0 Some basic techniques 0 Define the domain to be investigated 0 Collect a representative sample of applications in the domain 0 Collect a representative sample of applications in the domain 0 Develop an analysis model for the objects Approaches 0 Structured Analysis 0 Considers data and processes separately 0 Data models describe attributes and relationships 0 Process models describe how data is transformed as it ows through the system 0 ObjectOriented Analysis 0 Defines classes and how they collaborate 0 Each approach might be useful 0 An overall model would consider all the above Samaria Erased Inning mewdais V ng I i egg Make diagramg use rages Eulabumtmn user memes magrams 511 wam mgufmmen r5 e am m a How mailsJ5 H dai E39JQL a mate diagrams 7 DFDE data models sequence diagrama Scenario Based Modeling 0 What should we write about 0 How much should we write about it 0 How detailed should we make our description 0 How should we organize the description What Should We Write About 0 Inception and elicitation provide you with the information you ll need to begin writing USC C SCS 0 Requirements gathering meetings QFD and other requirements engineering mechanisms are used to 0 Identify stakeholders Define the scope of the problem Specify overall operational goals Establish priorities OOOOO Outline all known functional requirements and Describe the things objects that will be manipulated by the system I To begin developing a set of use cases list the functions or activities performed by a specific actor How Much to Write About 0 As further conversations with the stakeholders progress the requirements gathering team develops use cases for each of the functions noted 0 In general use cases are written first in an informal narrative fashion 0 If more formality is required the same use case is rewritten using a structured format similar to the one proposed 0 Details are added as they become known or necessary UseCases I A scenario that describes a thread of usage for a system 0 ie one actor s interaction to achieve a specified result 0 Actors represent roles people or devices play as the system functions I The actual users can play a number of different roles for a given scenario 0 That is actors are defined by their roles with respect to the use case not by their job title or some other criteria 0 Many different kinds of real people can interact with a system to accomplish the same goal they can probably be grouped together as a single actor 0 Developing a UseCase 0 What are the main tasks or functions that are performed by the actor 0 What system information will the actor acquire produce or change 0 Will the actor have to inform the system about changes in the external environment 0 What information does the actor desire from the system 0 Does the actor wish to be informed about unexpected changes 0 A primary scenario will emerge I Redefining a UseCase 0 At each step in the process you should ask I Can the actor perform some other action at this point I Will the actor encounter some error condition I Will the actor encounter some behavior invoked by an event outside that actor s control 0 These lead to secondary scenarios or exceptions I Cause the system to deviate from the primary scenario 0 Ways in which the system will handle these exceptions must be developed I These themselves may be separate use cases 0 Formal UseCase Elements 0 Actors Who participates Goal in Context Overall scope of the Use Case Preconditions What must be true for the Use Case to begin Trigger Event that initiates the Use Case Scenario Actions by actors and responses by system Exceptions Alternate paths through the use Case 00000 O Postconditions The state of the system when the Use Case has been completed 0 Open issues Anything unknown requiring resolution Activity Diagram 0 Supplements the use case by providing a graphical representation of the ow of interaction within a specific scenario 0 Elements 0 Rounded rectangles Functions 0 Arrows Sequence of events 0 Diamonds Decisions 0 Horizontal bars Parallel activities
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'