Q2p2 - First draft Use-Case and Class modeling Must include Use-Case Modeling Identify your actors/users of the system define usage scenarios

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
First draft: Use-Case and Class modeling (2/24/2011) Must include: - Use-Case Modeling Identify your actors/users of the system, define usage scenarios, define the event flow for each scenario, draw UML use-case diagrams, and provide use-case descriptions in table format. - Class Modeling Apply CRC method (Chapter 6 in 7 th ed. / Chapter 8 in 6 th ed.) to use-cases to identify analysis classes, draw “conceptual” UML class inheritance diagram showing relationships among classes, and provide class descriptions in table format. Your Class Project - SRS Document - 2 - Sequence Diagrams Draw UML sequence diagram for each use-case. Derived from “Event Flow” section of use-case descriptions. - Object Collaboration Modeling Draw UML object collaboration diagram(s) to show how objects interact with each other. Interactions are based on methods invocations among objects. - Object Behavior Modeling Draw UML state diagram(s) for the system to show what events make the system transition from one state to another. States are derived from actions performed classes. Requirements Analysis Requirements analysis specifies software’s operational characteristics indicates software's interface with other system elements establishes constraints that software must meet Requirements analysis allows the software engineer (called an analyst or modeler in this role) to: elaborate on basic requirements established during earlier requirement engineering tasks build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed. A Bridge Elements of Requirements Analysis Rules of Thumb The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Delay consideration of infrastructure and other non- functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be. Specification Guidelines Specification Guidelines Specification Guidelines Domain Analysis Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . . [Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks . . . Domain Analysis
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 06/22/2011 for the course COMP 3002 taught by Professor Staff during the Spring '10 term at Kennesaw.

Page1 / 3

Q2p2 - First draft Use-Case and Class modeling Must include Use-Case Modeling Identify your actors/users of the system define usage scenarios

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online