28  Lectures 5 & 6: Analysis Modeling

Requirements analysis it the process of understanding and documenting a customer’s need. It expresses “what” is to be built and “how” it is to be built. More precisely, in requirements analysis you specify the software’s

Domain analysis collect a representative sample of applications in the domain and analyzes each application in the sample.

Data Modeling: Examines the data objects independently of processing.

A data object is something that is described by a set of attributes. A relationship indicates connections between the objects.

28.1 ERD

28.2 Object Oriented Concepts

A class is a template, generalized description, or a blueprint describing a collection of similar items

A metaclass (aka superclass) establishes a hierarchy of classes.

The object encapsulates both data and the logical procedures required to manipulate the data.

28.3 Scenario-Based Modeling

28.3.1 Use Case

Use-Cases define what exists outside the system (actors) and what should be performed by the system (use-cases). Actors represent roles people or devices play as system functions. Users can play a number of different roles for a given scenario.

28.3.2 Use Case Analysis

  • Supplement the Use-Case Description
  • For each use-case realization
    • Find classes from use-case behavior
    • Distribute use-case behavior to classes
  • For each resulting analysis class
    • Describe responsibilities
    • Describe attributes and associations
    • Qualify architectural analysis mechanisms
  • Unify analysis classes
  • Checkpoints

28.3.3 Activity Diagram

An activity diagram supplements the use-case by providing a diagrammatic representation of procedural flow.

28.4 Flow-Oriented Modeling

A flow-oriented model shows how data objects are transformed as they move through the system. A data-flow-diagram (DFD) is the diagrammatic form that is used.

  • External Entity: A producer or consumer of data
  • Process: A data transformer
  • Data Flow: “Data flows through a system, beginning as input and be transformed into output.” (Isn’t this just the connection between two different components in a DFD)
  • Data Store: Data is often stored for later use

A DFD evolves through multiple levels of details. Always begin with a context level diagram (aka level 0) and show the external entities in it.

Moving to level 1 from level 0:

28.4.1 Control Flow Diagrams

Control flow diagrams represent “events” and the processes that manage events. An event is a boolean condition.

The Control Specification (CSPEC) can be

  • State Diagram (Sequential Spec)
  • State Transition Table
  • Decision Tables
  • Activation Tables

28.5 Data Dictionary

Data Dictionary is a repository that defines the data elements or attributes used in the system. Some notation

  • Primary Data Element: This is an element that doesn’t need further decomposition.

  • Composition: Indicated with +

  • Iteration: min:max {item} (shows that multiple instances of an item can appear)

  • Selection [item|item]

28.6 Class Based Modeling

In CRC modeling, you define for each class its responsibilities and collaborators.

There are 3 class types:

  • Entity Classes: also called model or business classes, are extracted directly from the statement of the problem

  • Boundary Classes: are used to create the interface

  • Controller Classes: manage a “unit of work” from start to finish.

In UML, relationships are called associations and can refined by indicating multiplicity (aka cardinality)

28.7 Behavioral Modeling