The analysis model is the first technical representation of a system. Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Building analysis models helps make it easier to uncover requirement inconsistencies and omissions. Two types of analysis modeling are commonly used: structured analysis and object-oriented analysis. Scenario-based modeling represents the system from the user's point of view. Flow-oriented modeling shows how data are transformed inside the system by processing functions. Class-based modeling defines objects, attributes, and relationships. Behavioral modeling uses state transition diagrams to show the impact of events on the system states. Analysis work products must be reviewed for completeness, correctness, and consistency.
Analysis Model Guidelines
Analysis products must be highly maintainable, especially the software requirements specification.
Problems of size must be dealt with using an effective method of partitioning.
Graphics should be used whenever possible.
Differentiate between the logical (essential) and physical (implementation) considerations.
Find something to help with requirements partitioning and document the partitioning before specification.
Devise a way to track and evaluate user interfaces.
Devise tools that describe logic and policy better than narrative text.
Analysis Model Objectives
Describe what the customer requires.
Establish a basis for the creation of a software design.
Devise a set of requirements that can be validated once the software is built.
Analysis Model Rules of Thumb
The model should focus on requirements that are visible within the problem or business domain and be written as a relatively high level of abstraction.
Each element of the analysis model should add to the understanding of the requirements and provide insight into the information domain, function, and behavior of the system.
Delay consideration of infrastructure and non-functional models until design.
Minimize coupling throughout the system.
Be certain the analysis model provides value to all stakeholders.
Keep the model as simple as possible.
Domain Analysis Activities
Define the domain to be investigated
Categorize the items extracted from the domain
Collect a representative sample of applications in the domain
Analyze each application in the sample
Identify candidate reusable objects
Indicate reasons the objects may be reused
Define adaptations of the objects that may be reused
Estimate percentage of applications in the domain that might make reuse of the objects
Identify objects by name and use configuration management techniques to control them
Develop an analysis model for the objects
Structured Analysis Model Elements
Data dictionary - contains the descriptions of all data objects consumed or produced by the software
Entity relationship diagram (ERD) - depicts relationships between data objects
Data flow diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC)
State diagram (SD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)
Data Modeling Elements (ERD)
Data object - any person, organization, device, or software product that produces or consumes information
Attributes - name a data object instance, describe its characteristics, or make reference to another data object
Relationships - indicate the manner in which data objects are connected to one another
Cardinality and Modality (ERD)
Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N)
Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship
Functional Modeling and Information Flow (DFD)
Shows the relationships of external entities, process or transforms, data items, and data stores
DFD's cannot show procedural detail (e.g., conditionals or loops) only the flow of data through the software
Refinement from one DFD level to the next should follow approximately a 1:5 ratio (this ratio will reduce as the refinement proceeds)
To model real-time systems, structured analysis notation must be available for time continuous data and event processing (e.g., Ward and Mellor or Hately and Pirbhai)
Behavioral Modeling (STD)
State transition diagrams represent the system states and events that trigger state transitions
STD's indicate actions (e.g., process activation) taken as a consequence of a particular event
A state is any observable mode of behavior
Hatley and Pirbhai control flow diagrams (CFD) and UML sequence diagrams can also be used for behavioral modeling
Creating Entity Relationship Diagrams
Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities
Analyst and customer define connections between the objects
One or more object-relationship pairs is created for each connection
The cardinality and modality are determined for an object-relationship pair
Attributes of each entity are defined
The entity diagram is reviewed and refined
Creating Data Flow Diagram
Level 0 data flow diagram should depict the system as a single bubble
Primary input and output should be carefully noted
Refinement should begin by consolidating candidate processes, data objects, and data stores to be represented at the next level
Label all arrows with meaningful names
Information flow must be maintained from one level to level
Refine one bubble at a time
Write a PSPEC (a "mini-spec" written using English or another natural language or a program design language) for each bubble in the final DFD
Creating Control Flow Diagrams
Begin by stripping all the data flow arrows form the DFD
Control items (dashed arrows) are added to the diagram
Add a window to the CSPEC (contains a SD that is a sequential specification of the behavior) for each bubble in the final CFD
Data Dictionary Contents {not covered explicitly in SEPA, 6/e}
Name - primary name for each data or control item, data store, or external entity
Alias - alternate names for each data object
Where-used/how-used - a listing of processes that use the data or control item and how it is used (e.g., input to process, output from process, as a store, as an external entity)
Content description - notation for representing content
Supplementary information - other data type information, preset values, restrictions, limitations, etc.
Object-Oriented Concepts
Objects - encapsulate both data (attributes) and data manipulation functions (called methods, operations, and services)
Class - generalized description (template or pattern) that describes a collection of similar objects
Superclass - a collection of objects
Subclass - an instance of a class
Class hierarchy - attributes and methods of a superclass are inherited by its subclasses
Messages - the means by which objects exchange information with one another
Inheritance - provides a means for allowing subclasses to reuse existing superclass data and procedures; also provides mechanism for propagating changes
Polymorphism - a mechanism that allows several objects in an class hierarchy to have different methods with the same name (instances of each subclass will be free to respond to messages by calling their own version of the method)
Object-Oriented Analysis Model Elements
Scenario-based - depict how the user interacts with the system (use-case diagram) and the sequence of activities that occur during software use (activity diagrams and swim lane diagrams)
Class-based - model the system objects, operations, class relationships (class diagram)
Behavioral - depict how external events change the state of the system or the system classes (state diagram and sequence diagrams)
Flow-oriented - represent the system as an information transform and depict how data objects are transformed as they flow through system function (dataflow diagram)
Developing Use-Cases
Use cases capture the interactions between actors (i.e., entities that consume or produce information)
Begin by listing the activities performed by a single actor to accomplish a single function
Continue this process for each actor and each system function
Use-cases are written first in narrative form and then mapped to a template if more formality is required
Each primary scenarios should be reviewed to see if alternative interactions are possible
Can the actor take some other action at this point?
Is it possible that the actor will encounter an error condition at some point? If so, what?
Is it possible that the actor will encounter some other behavior at some point? If so, what?
UML Activity Diagrams
Supplements use-case by providing graphical representation of the interaction flow within a specific scenario
Variation of activity diagrams used show flow of activities in use case as well as indicating which actor has responsibility for activity rectangle actions
Responsibilities are represented by parallel line segments that divide the diagram vertically headed by the responsible actor
Specifying Analysis Classes
Examine the problem statement and try to find nouns that fit the following categories and produce or consume information (i.e., grammatical parse)
External entities (systems, devices, people)
Things (e.g., reports, displays, letters, signals)
Events occurring during system operation
Roles (e.g., manager, engineer, salesperson)
Organizational units (e.g., division, group, team)
Places (e.g., laboratory, control room, aircraft cockpit)
Structures (e.g., sensors, vehicles, computers)
Consider whether each potential class satisfies one of these criteria as well
Contains information that should be retained
Provides needed services
Contains multiple attributes
Has common set of attributes that apply to all class instances
Has common set of operations that apply to all object instances
Represents external entity that produces or consumes information
Specifying Class Attributes
Examine the processing narrative or use-case and select the things that reasonably can belong to each class
Ask what data items (either composite or elementary) fully define this class in the context of the problem at hand?
Defining Operations
Look at the verbs in the processing narrative and identify operations reasonably belonging to each class that (i.e., grammatical parse)
manipulate data
perform computation
inquire about the state of an object
monitor object for occurrence of controlling event
Divide operations into sub-operations as needed
Also consider communications that need to occur between objects and define operations as needed
Class-Responsibility-Collaborator (CRC) Modeling
Develop a set of index cards that represent the system classes
One class per card
Cards are divide into three sections (class name, class responsibilities, class collaborators)
Once a complete CRC card set is developed it is reviewed examining the usage scenarios
Allocating Responsibilities to Classes
Distribute system intelligence evenly
State each responsibility as generally as possible
Information and its related behaviors should reside within the same class
Localize all information about one thing in a single class
Share responsibilities among related classes when appropriate
Collaborators
Any time a class cannot fulfill a responsibility on its own it needs to interact with another class
A server object interacts with a client object to fulfill some responsibility
Reviewing CRC Models
Each review participant is given a subset of the CRC cards (collaborating cards must be separated)
All use-case scenarios and use-case diagrams should be organized into categories
Review leader chooses a use-case scenario and begins reading it out loud
Each time a named object is read a token is passed to the reviewer holding the object's card
When the reviewer receives the token, he or she is asked to describe the responsibilities listed on the card
The group determines whether one of the responsibilities on the card satisfy the use-case requirement or not
If the responsibilities and collaborations on the index card cannot accommodate the use-case requirements then modifications need to be made to the card set
Associations and Dependencies
Association - present any time two classes are related to one another in some fashion
association multiplicity or cardinality can be indicated in a UML class diagram (e.g., 0..1, 1..1, 0.., 1..)
Dependency - client/server relationship between two classes
dependency relationships are indicated in class diagrams using stereotype names surrounded by angle brackets (e.g., «stereotype»)
Analysis Packages
Categorization is an important part of analysis modeling
Analysis packages are made up of classes having the same categorization
In class diagrams visibility of class elements can be indicated using a + (public), - (private), # (package)
Object-Behavior Model Construction
Evaluate all use-cases to understand the sequence of interaction within the system
Identify events that drive the interaction sequence and how events relate to specific objects
Create an event-trace for each use-case
Build a state diagram for the system
Build a sequence diagram for the system
Review the object behavior model to verify accuracy and consistency
UML State Diagrams
Round corned rectangles are used for each state
Arrows connecting states are labeled with the name of the event that triggers the transition from one state to the other
Guards limiting the transition from one state to the next may be specified as Boolean conditions involving object attributes in the use-case narratives
UML Sequence Diagrams
Built from use-case descriptions by determining how events cause transitions from one object to another
Key classes and actors are shown across the top
Object and actor activations are shown as vertical rectangles arranged along vertical dashed lines called lifelines
Arrows connecting activations are labeled with the name of the event that triggers the transition from one class or actor to another
Object flow among objects and actors may be represented by labeling a dashed horizontal line with the name of the object being passed
