COMP 325 Lecture 10: Classical Analysis Workflow
major resources: Introduction to Object Oriented Analysis, Brown 2002, Object-Oriented and Classical Software Engineering 6ed, Schach 2005.

[ previous | schedule | next ]

Analysis Workflow Goal

Specifications doc is significant because:

• this is contract between developer and client regarding what the system will do
• if developer and client are different organizations, it is a legal contract
• it needs to address both functional and non-functional requirements of the system
• it is blueprint that designer will use for design then programmer to implement

Due to ambiguities of specifications written in prose, written descriptions are supplemented or replaced by diagrams.

Historical progression of modeling methods

• 1960s: output-oriented
• 1970s: function- and process-oriented
• 1980s: data-oriented
• 1990s: object-oriented
• 2000s: aspect-oriented?

1970s: Function-oriented

• top-down decomposition of business process
• each decomposition results in set of two or more simpler subprocesses
• recursively decompose until function becomes trivial or easily understood/expressed
• results in tree structure that resembles organizational chart

1970s: Process-oriented

• first apply functional decomposition to identify processes/subprocesses
• use arrows to indicate directed activity
• control flow from process to process is a directed activity
• data flow is a directed activity (e.g. from database to process or vice versa)
• control flow typically expressed using Flowcharts
• data flow typically expressed using Data Flow Diagrams (DFD)
• these methods are basis for Structured Analysis, which dominated business systems development in the 1970s
• functional decomposition and flowcharts dominated for technical/scientific systems development
• Here is a short PowerPoint presentation illustrating some DFDs

1980s: data-oriented

• Identify data entities in the system
• "something that has separate and distinct existence in the world of the users and is of interest to the users in that they need to record data about it" (Brown p. 64)
• Entities are identified by certain nouns in a system description
• Identify entity types by grouping together similar entities. This is an important form of abstraction.
• Each entity is an occurrence of its type
• Then determine what attributes those entity types have
  • Attributes are the relevant properties that an entity has
  • All entities of a type have the same attributes
  • Different entities of the same type will have different values for some attributes
  • Attribute values will record an entity's state
  • An attribute whose value uniquely identifies an entity may be selected as a key
  • If no single attribute has unique value, a combination of attributes may be used.
• Then determine what associations, or interactions, those entities have with other entities.
• one entity can take an action with another, or may play a role for another
• Associations are identified by certain verbs or verb phrases
• associations are also known as relationships
• the entity-relationship diagram (ERD) was developed for modeling
• consider some examples: car, bookstore, library, table factory

More on Relationships

• relationships are also known as associations
• each relationship is between two entity types
  e.g. in the library example, the phrase "a patron borrows books" describes a relationship "borrows" between two entity types, "patron" and "book"
• a relationship is normally directed,
  e.g. in the library example, when a patron borrows a book, the "borrows" relationship is directed from the patron to the book
• each end of the association is also characterized by its cardinality
• cardinality is number of occurrences of each entity type involved in an association
  e.g. in the library example, one patron borrows one or more books. Cardinality on the patron end is 1 and on the book end is many (usually denoted by M or N or * or a triangle)

Entity-Relationship Diagrams

• visual modeling technique, a.k.a. "ERD" or "ER diagram"
• key concepts are described above: entities, attributes, relationships, cardinality
• ERDs describe static system views; DFDs show system dynamics
• ERDs and DFDs complement each other and Structured Analysis uses both
• database layouts and structures can be designed from ERDs
• as with DFDs, there are several different graphical notations
• most common notation is from Chen (ERD originator) or derivative:

typically boxes for entities, ovals for attributes, diamonds for named relationships, lines to connect attributes to entities, arrows to connect entities and relationships
• we'll look at several examples which show different styles

Formal classical specification techniques

State Transition Diagrams

Petri Nets

Z specification language

• formal specification notation based on set theory and first order predicate logic.
• named after German mathematician Zermelo
• pronounced "zed", European pronunciation of the letter Z
• used mostly in Europe
• methodology-independent
• produces precise unambiguous specifications
• some mathematical skills required
• fundamental entity is the schema
• data schema consists of: name, subcomponents, invariants
• operation schema consists of: name, parameters, pre- and post-conditions
• non-standard object-oriented versions exist
• Lots of information available at http://www.zuser.org

Here it is, written in Z