Unit-3 Analysis Modeling

1. Unit-3Analysis Modeling

2. Requirements analysis results in the specification of software’s operational characteristics, indicates software’s interface with other system elements, and establishes constraints that software must meet. Requirements analysis allows you (regardless of whether you’re called a software engineer, an analyst, or a modeler) to elaborate on basic requirements established during the inception, elicitation, and negotiation tasks that are part of requirements engineering

3. The requirements modeling action results in Scenario-based models of requirements from the point of view of various system “actors” Data models that depict the info domain for the problem Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements Flow-oriented models that represent the functional elements of the system and how they transform data as it moves through the system Behavioral models that depict how the software behaves as a consequence of external “events”

4. The requirements model must achieve three primary objectives: • to describe what the customer requires, • to establish a basis for the creation of a software design, • to define a set of requirements that can be validated once the software is built.

5. The analysis model bridges the gap between a system-level description that describes overall system or business functionality as it is achieved by applying software, hardware, data, human, and other system elements and a software design that describes the software’s application architecture, user interface, and component-level structure

6. Analysis Rules of Thumb • The analysis 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 following • Information domain, function, and behavior of the system • The model should delay the consideration of infrastructure and other non-functional models until the design phase • First complete the analysis of the problem domain

7. Analysis Rules of Thumb • The model should minimize coupling throughout the system • Reduce the level of interconnectedness among functions and classes • The model should provide value to all stakeholders • The model should be kept as simple as can be

8. Domain Analysis • Definition • The identification, analysis, and specification of common, reusable capabilities within a specific application domain • Do this in terms of common objects, classes, subassemblies, and frameworks • Sources of domain knowledge • Technical literature • Existing applications • Customer surveys and expert advice • Current/future requirements • Outcome of domain analysis • Class taxonomies • Reuse standards • Functional and behavioral models • Domain languages

9. Domain Analysis Requirements Modeling Approaches

10. A Set of Models • Flow-oriented modeling – provides an indication of how data objects are transformed by a set of processing functions • Scenario-based modeling – represents the system from the user's point of view • Class-based modeling – defines objects, attributes, and relationships • Behavioral modeling – depicts the states of the classes and the impact of events on these states

11. Analysis Modeling Data modeling Object oriented analysis Scenario-based modeling Flow modeling Class based modeling Behavioral modeling

12. Goals of Analysis Modeling • Provides the first technical representation of a system • Is easy to understand and maintain • Deals with the problem of size by partitioning the system • Uses graphics whenever possible • Differentiates between essential information versus implementation information • Helps in the tracking and evaluation of interfaces • Provides tools other than narrative text to describe software logic and policy

13. Analysis Modeling Approaches • Structured analysis • Considers data and the processes that transform the data as separate entities • Data is modeled in terms of only attributes and relationships (but no operations) • Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data • Object-oriented analysis • Focuses on the definition of classes and the manner in which they collaborate with one another to fulfill customer requirements

14. Scenario-based modeling Flow-oriented modeling Use case text Use case diagrams Activity diagrams Swim lane diagrams Data structure diagrams Data flow diagrams Control-flow diagrams Processing narratives Behavioral modeling Class-based modeling State diagrams Sequence diagrams Class diagrams Analysis packages CRC models Collaboration diagrams Elements of the Analysis Model Object-oriented Analysis Structured Analysis

15. Data Modeling Concepts • The entity-relationship diagram (ERD) addresses these issues and represents all data objects that are entered, stored, transformed, and produced within an application • Data objects- A data object is a representation of composite information that must be understood by software. • Example: width (a single value) would not be a valid data object, but dimensions (incorporating height, width, and depth) could be defined as an object.

16. A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), a structure (e.g., a file)For example, a person or a car can be viewed as a data object in the sense that either can be defined in terms of a set of attributes. The description of the data object incorporates the data object and all of its attributes.

18. Data Attributes define the properties of a data object and take on one of three different • characteristics. They can be used to • name an instance of the data object, • Describe the instance, or • make reference to another instance in another table.

19. Relationship • Cardinality (number of occurrences)

20. Scenario based Modeling • User satisfaction • Properly characterize requirements • Actors Interaction with the system • Build meaningful analysis models • Requirements modeling • UML • Usecase • Activity diagrams • Swimlane diagrams

21. Creating a preliminary Use Case • Contract for behavior • what to write about (inception and elicitation) • Requirements gathering meeting, QFD, scope, functional requirements etc. • how much to write about it • how detailed to make your description • how to organize the description?

22. Writing Use Cases • It is effective to use the first person “I” to describe how the actor interacts with the software • Format of the text part of a use case Use-case title: Actor: Description: I …

23. Use Case

25. Example 1 Use Case Diagram

26. Example 2 Use Case Diagram Make automated menu selections Expert Menu System Order food and drink Cook Notify customer that food and drink are ready Customer Pay for food and drink Payment System

27. Refining a Preliminary Use Case • Can the actor take some other action at this point? • Is it possible that the actor will encounter some error condition at this point? If so, what might it be? • Is it possible that the actor will encounter some other behavior at this point (e.g., behavior that is invoked by some event outside the actor’s control)? If so, what might it be? • Are there cases in which some “validation function” occurs during this use case? • Are there cases in which a supporting function (or actor) will fail to respond appropriately? • Can poor system performance result in unexpected or improper user actions?

28. Activity Diagrams • Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario • Uses flowchart-like symbols • Rounded rectangle - represent a specific system function/action • Arrow - represents the flow of control from one function/action to another • Diamond - represents a branching decision • Solid bar – represents the fork and join of parallel activities

30. Swimlane diagram • The UML swimlane diagram is a useful variation of the activity diagram and allows you to represent the flow of activities described by the use case and at the same time indicate which actor (if there are multiple actors involved in a specific use case) or analysis class (discussed later in this chapter) has responsibility for the action described by an activity rectangle. • Responsibilities are represented as parallel segments that divide the diagram vertically, like the lanes in a swimming pool.

32. Flow-Oriented Modeling • Represents how data objects are transformed at they move through the system • data flow diagram (DFD) – complement UML diagrams and provide additional insight into system requirements and flow • Considered by many to be an “old school” approach, but continues to provide a view of the system that is unique • Input –process-output view of the system Data objects flow into the system- transformed by processing elements-resultant data objects flow out of the software • represented in hierarchical fashion

33. Data flow modeling is a core modeling activity in structured analysis • 1st data model- level 0 DFD or context diagram • Represents the system as a whole • Subsequent data flow diagrams refine the context diagram, providing increasing detail with each subsequent level • The data flow diagram enables one to develop models of the information domain and functional domain

34. A few simple guidelines during the derivation of a data flow diagram: the level 0 data flow diagram should depict the software/system as a single bubble primary input and output should be carefully noted Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level all arrows and bubbles should be labeled with meaningful names information flow continuity must be maintained from level to level one bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram. This occurs when you attempt to show too much detail too early or represent procedural aspects of the software in lieu of information flow.

35. Flow Modeling Notation external entity process data flow data store

36. External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something

37. Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

38. Data Flow Data flows through a system, beginning as input and transformed into output. base compute triangle area area height

39. Data Stores Datais often stored for later use. sensor # sensor #, type, location, age look-up sensor data report required type, location, age sensor number sensor data

40. Level 0 DFD ExampleContext level DFD for Safe Home Security Function

41. Level 1 DFD for Safe Home Security Function

42. Level 2 DFD that refines the monitor sensors process

43. Control Flow Modeling • Represents “events” and the processes that manage events • An “event” is a Boolean condition that can be ascertained by: • listing all sensors that are "read" by the software. • listing all interrupt conditions. • listing all "switches" that are actuated by an operator. • listing all data conditions. • recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs. • Describe the behavior of the system by identifying its states, identify how each state is reached and define the transitions between states • Focus on possible omissions- a very common error in specifying control

44. Control Specification (CSPEC) The CSPEC can be: state diagram (sequential spec) state transition table combinatorial spec decision tables activation tables

45. Data Flow and Control Flow • Data Flow Diagram • Depicts how input is transformed into output as data objects move through a system • Process Specification • Describes data flow processing at the lowest level of refinement in the data flow diagrams • Control Flow Diagram • Illustrates how events affect the behavior of a system through the use of state diagrams

46. State Diagram for Safe Home Security function

47. Process activation table for SafeHome Security function

48. Object oriented Analysis • Design classes • User interface classes- abstractions necessary for HCI • Business domain classes- refinements • Process classes- low level business abstractions • Persistent classes- represent data stores • System classes- software management and control functions interacting with outside world

49. Four characteristics of classes • Complete and sufficient- encapsulation • Primitiveness- accomplishing one service completely • High cohesion- small, foccussed set of responsibility • Low coupling

50. Class based modeling • Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation, relationships (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined. • The elements of a class-based model include classes and objects, attributes, operations, class responsibility- collaborator (CRC) models, collaboration diagrams, and packages.