CIS 375 SOFTWARE ENGINEERING

UNIVERSITY OF MICHIGAN-DEARBORN

DR. BRUCE MAXIM, INSTRUCTOR

Date: 10/13/97

Week 6

1. Structured analysis and design technique(SADT)

Structured analysis activity diagram:

(Activity Network)

Control

Inputs Output

Mechanism

Structured analysis data diagram:

(Data Network)

Control

Generating Activity Resulting Activity

Storage Devices

Design techniques:

Explains how to interpret results of SA (control issues).

1. Structured system analysis:
   • Use data flow diagram.
   • Use data dictionaries.
   • Use pseudocode algorithms (control inf.)
   • Use relational data tables to indicate data elements and relations.
   (Database way of attacking things)
2. Requirements dictionary:
   (a.k.a. data dictionary)
   • All system elements.
   • Dictionary format:
3. 1) Name.
4. 2) Aliases.
5. 3) Where something's used & how it is used (producer & consumer).
6. 4) Content description (motivation for representation).
7. 5) Supplementary information - restrictions, limitations.

OBJECT ORIENTED ANALYSIS

OBJECT ORIENTED DESIGN

IDENTIFY THE PROBLEM OBJECTS

1. 1) External entities (people & devices).
2. 2) Things in problem domain (reports, displays, signals).
3. 3) Occurrences or events (completion of some task).
4. 4) Roles (manager, engineer, sales person).
5. 5) Organizational units (division, groups, department).
   1. 6) Structures (sensors, vehicles, computers).

CRITERIA:

1. 1) Does object inf. need to be retained?
2. 2) Does object have a set of needed services?
   1. (Can change it's attributes)
3. 3) Does the object have major attributes?
   1. (Trivial objects should not be built)
4. 4) Identify common attributes for all object instances.
5. 5) Identify common operations for all object instances.
   1. (If nothing to share, why make it an object?)
   2. External entities which produce or consume must have defined classes.

SPECIFYING ATTRIBUTES:

SPECIFYING OPERATIONS:

1. Include anything needed to manipulate data elements.
2. Communication among objects.

OBJECT SPECIFICATION:

1. Object name.
2. Attribute description:
   1. Attribute name.
   2. Attribute content.
   3. Attribute data type/structure.
3. External input to object.
4. External output from object.
5. Operation description:
   1. Operation name.
   2. Operation interface description.
   3. Operation processing description.
   4. Performance issues.
   5. Restriction and limitations.
6. Instance connections:

OBJECT ORIENTED ANALYSIS STEPS:

1. Class modeling.

1. (Build an object model similar to an ER diagram)
   1. Dynamic modeling.
2. (Build a finite state machine type model)
   1. Functional modeling.

CASE STUDY:

ELEVATOR MODEL.

CLASS MODELING

• Buttons.
• Elevators.
• Floor.
• Building.
• Movement.
• Illumination.
• Doors.
• Requests.

DYNAMIC MODELING:

-> production rules (describe state transitions).

FUNCTIONAL MODELING:

OBJECT-ORIENTED LIFE CYCLE MODEL:

FOUNTAIN MODEL:

Date: 10/15/97

Week 6

CLASS RESPONSIBILITY COLLABORATOR MODEL (CRC):

MANAGEMENT & OBJECT ORIENTED PROJECTS:

1. Establish a common process framework (CPF).
2. Use CPF & historic data to eliminate time & effort.
3. Specify products & milestone.
4. Define Q.A. checkpoints.
5. Manage changes.
6. Monitor.

1. 1) Number of scenario scripts.
2. 2) Number of key classes.
3. 3) Number of support classes.
   1. 4) (# of key classes)/(# of support classes).

OBJECT ORIENTED ESTIMATING & SCHEDULING:

1. Develop estimates using effort decomposition, FP, etc.
2. Use O.O.A. to develop scenario script and count them.
3. Use O.O.A. to get the number of key classes.
4. Categorize types of interfaces:
   No U.I. = 2.0 G.U.I. = 3.0
   Text U.I. = 2.25 Complex G.U.I. = 3.0
   Use to derive support classes:
   (# of key classes) * (G.U.I. #)
5. Total classes = (key + support) * (average # of work units per class).
   ( 15-20 person days per class)
6. Cross check class based estimate (5) by multiplying.
   (avg. # of work units) * (# of scenario scripts)

PROJECT SCHEDULING METRICS:

1. Number of major iterations (around spiral model).
2. Number if completed contracts.

OBJECT ORIENTED MILESTONES:

1. Contracts completed.
2. O.O.A. completed.
3. O.O.D. completed.
4. O.O.P. completed.
5. O.O. testing completed.

SYSTEM DESIGN:

1. Conceptual Design (function) {for the customer}.
2. Technical design (form) {for the hw & sw experts}.

CHARACTERISTICS OF CONCEPTUAL DESIGN:

1. Written in customer's language.
2. No techie jargon.
3. Describes system function.
4. Should be implement independent.
5. Must be derived from requirements document.
6. Must be cross referenced to requirements document.
7. Must incorporate all the requirements in adequate detail.

TECHNICAL DESIGN CONTENTS:

1. System architecture (sw & hw)
2. System software structure.
3. data

DESIGN APPROACHES:

1. Decomposition (function based, well defined).

PROGRAM DESIGN:

• Defining modules and their interfaces.
• Each system module is rewritten as a set of program specifications (input, output, process).

PROGRAM DESIGN MODULES:

1. Must contain detailed algorithms.
2. Data relationships & structures.
3. Relationships among functions.

PROGRAM DESIGN GUIDELINES:

1. Top - down approach.

1. vs.
   1. Bottom - up approach.
2. (There are risks and benefits for both)
   1. Modularity & independence (abstraction).
   2. Algorithms:
      1. Correctness.
      2. Efficiency.
      3. Implementation.
   3. Data types:
      1. Abstraction.
      2. Encapsulation.
      3. Reusability.

WHAT IS A MODULE?

1. 1) A name.
2. 2) The ability to be called.
3. 3) Some type of local environment (variables).
   (Self contained, sometimes can be compiled separately)
   Modules either contain executable code or creates data.

DETERMINING PROGRAM COMPLEXITY:

PROGRAM COMPLEXITY FACTORS:

1. 1. Span of the data item.
   1. (too many lines of code between uses of a variable)
   1. 2. Span of control.
   2. (too many lines of code in one module)
   1. 3. Number of decision statements.
   3. (too many "if - then - else", etc.)
   1. 4. Amount of information which must be understood.
   4. (too much information to have to know)
   1. 5. Accessibility of information and standard presentation.
   5. (x,y -> x,y; not y₁,y₂)
   1. Structured information.
   6. (good presentation)