April 9, 2020 Sam Siewert

SE310Analysis and Design of Software

Lecture 14 – Detailed Design(Review of Models and Methods in

Part-2 of SE310)

Domain Models – Use Case DetailsComplete a DesignProvide Code Re-Use Candidate and PoC/Prototype

Sam Siewert 2

Start Here! https://www.modelio.org/

Helpful Validation and Verification Features for Design

• Integrated Models• Checklists – Completeness• CPP and Java Code Generation

USE Modelio as your DESIGN TOOL

Key Value of Each Model

Proper Use – Notation, Phase

Consistency, Completeness

Correctness

Testing Strategies – Detailed Design

Sam Siewert 3

Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014)

copyright 2014 by Roger PressmanConsiderations for Software Test and Evaluation – NDIA Software Test Summit

Dr. Ernest Seglie, Science Advisor to the Director, Operational Test and Evaluation

Process phase descriptions can vary.

However, the concepts and theory aregenerally the same for a given model.

Progression from Specification, to Analysis to High-Level Design (Architecture and System) to Components in Subsystems, to Units or Modules of Code

OOSE Chapter 12 – Part III (Interactive Systems, Beyond OIM)

User Interface Design – Interactive Systems - CS415Key Values [Human Computer Interaction]– Window multi-tasking [e-mail, web, IDE]– Easy to Learn and Use [subjective, but most consumers prefer to

command line]– Multi-media Presentations [Video, Visualization Graphics, Audio,

Animation]GUI Widgets [e.g. X-windows and Qt, MS Windows]Kung P. 303 – Major System Displays, Figure 12.5User Interface State Diagrams – P. 306, Figure 12.9 in KungPrototypes [Mock-Ups]Guidelines Sam Siewert 4

OOSE Chapter 13, Part IVObject State Modeling – Event-DrivenCollecting and Classifying State Behavior

Extensions to Domain Models [Class Diagram and OIM] to add Domain State Machine Model

– P. 325, Figure 13.6 [Thermostat Domain State Machine]

– P. 326, Figure 13.4 [Cruise Control Domain State Machine]

– P. 336 – State Pattern– CFD/DFD [Transformations on State Transition]

For Event-Drive Architectures or Architectures with Event-Driven Aspects and Subsystems, EFSMs are High-Level (Domain)

State Transition TablesUML Notation – P. 331event[guard] / act1; act2Cruise Control – P. 332

Sam Siewert 5

http://en.wikipedia.org/wiki/Specification_and_Description_Language

SDL FYI – Not on Exam(s)

http://en.wikipedia.org/wiki/UML_state_machine

State Machine Examples (pp. 320-346)Manual, Automatic, and Cruise Control -Reviewed in Lecture-Week-10-1State Machines are Formal Models (Prove / Disprove Properties of the Model)Computation - Class of Automation– Combinational Logic (And, Or, Not)– State Machines (State, input/output)– Push-Down Automata (add stack, tape)– Turing Machines (Von Neumann

Architecture - Memory, ALU+Control, and I/O is modern equivalent)

Sam Siewert 6

https://en.wikipedia.org/wiki/Finite-state_machine

https://en.wikipedia.org/wiki/Turing_machine

Simple Switch 2-Way Switch

Electrical Circuit Specification - Video

Switches:SPSTSPDTDPSTDPDT

2-Way Switch as State MachineSoftware can model hardware

e.g. SPICE (analog), HDL (digital)Turing > Combinational Logic, State Machine

2-Way Circuit Combinational Logic is XOR(S1, S2)

How Many States to Model?4 State, Single Input: {Ssame-up-up, Sopposite-up-dwn, Ssame-dwn-dwn, Sopposite-dwn-up}

2 State, Combined Input:{Ssame, Sopposite}, {on-on, on-off, off-on, off-off}Mealy State Machine is 2 x 2

Sam Siewert 7

XOR

Switch S1 Switch S2 XOR(S1, S2)

0 0 0

0 1 1

1 0 1

1 1 0

Switch S1 Switch S2 Output

off off Dark

off on Light

on off Light

on on Dark

XOR implementation

Ssame Sopposite

on-on/Dark

on-off/Light

off-on/Light

off-off/Dark

on-on/Dark

off-off/Dark off-on/Light

on-off/Light

Cruise Control - Improved (p. 329)Author’s Example has 5 States

Author’s Example has 7 Events– Enable[], Disable[]

for safety– Brake[]– Start-IS[], Stop-IS[]– Resume[]– Speed-Reached[]

Numerous actions follow

Sam Siewert 8

Event Enable Disable Start-IS Stop-IS Brake Resume Speed-Reached

State

Start (trigger RRR; enable MCS) / MS

(noop) / START

(noop) / START

(noop) / START

(noop) / START

(noop) / START

(noop) / START

MS (noop) / MS (disable MCS) / START

(disable MCS; enable IS) / IS

(noop) / MS (disable MCS) / INT

(noop) / MS (noop) / MS

IS (noop) / IS (disable IS) /INT

(noop) / IS (disable IS; trigger RRR; enable MCS) / MS

(disable IS) / INT

(noop) / IS (noop) / IS

Interrupt (noop) / INT (noop) / START

(noop) / INT (noop) / INT (noop) / INT (enable RPS) / RS

(noop) / INT

RS (noop) / RS (disable RPS) / INT

(noop) / RS (noop) / RS (disable RPS) / INT

(noop) / RS (disable RPS;enable MCS) / MS

States: START, MS=Maintain Speed, IS=Increase Speed, INT=Interrupted, RS=Resume Speed

Events: Enable, Disable, START_IS=Start increase speed, STOP_IS=Stop increase speed, Brake, Resume, Speed reached

Actions: trigger RRR (Record Rotation Rate); enable or disable RPS (Return to Previous Speed); enable or disable MCS (Maintain Constant Speed); enable or disable IS (Increase Speed)

UML State Machines are EFSM

UML Extended Finite State Machine– Can be Nested (Hierarchical Machines)– Events with guards cause transition– Action list on transition into and out-of new

state

Sam Siewert 9

Mealy_machineUsed in digital design

SDL - Specification and Description LanguageIs composed of EFSM - Used in Telecomm

OOSE Chapter 14 - Concurrent ActivityActivity Models – Concurrency, Fork, Join for TasksTask Could Be Implemented as Linux Process, POSIX Thread, VxWorks Task, Unix/Windows Service, etc.Petri-Net – Formalism, Can Be Simulated and Used for Cleanroom SWE – P. 352CFD/DFDUML Activity Diagram Notation –P. 355Activity Table - AnalysisOffice of Int’l Ed. – P. 361 Sam Siewert 10

http://www.holub.com/goodies/uml/

OOSE Chapter 18 – Part VI (QA)Coding StandardsCode Generation from Design, P. 459 in Kung– SQL from MySQL Workbench [CS317]– C++ from Modelio [Domain Model]

Potentially All Code – E.g. Telelogic SDL– Generated Code Can be Ugly [Hard to Maintain]– GOTO almost Unavoidable for State-Machines– Make a Trade-off

Test-Driven Development [Flowchart P. 464 in Kung]Pair Programming [Agile Scrum and XP]Concurrent Test + Analysis/Design/Construction

Sam Siewert 11

OOSE Chapter 19 - SQAP. 471 - ____ilities, ISO/IEEE Quality Attributes – Non-Functional

Quality Metrics – Table on P. 475 in Kung– Structure Chart Complexity Metric– Cyclomatic Complexity– Reliability and Availability – MTTF, MTBF, MTTR

Inspections and Walk-throughs

Verification and Validation [Design Level, Code Level]– Design – E.g. Verify that Model is Consistent, Adheres to Notation

(Design Entry), Simulates (E.g. Petri-Net)– Design – E.g. Validate that Use Cases Trace to Requirements– Code – Validate Function Implements Class Diagram Method, Verify that

Code Terminates Loop Given Input Vector

Sam Siewert 12

OOSE Chapter 20 – SE TestingDynamic – Must Run CodeStatic – Compiles, Passes –Wall, LintBug vs. Defect [Reported vs. Root-Cause Verification]

Types of Code Level Tests (Unit)– Functional – Black-box, P. 504

Equivalence Partitioning – P. 506, Figure 20.2Boundary Value Analysis, P. 508, Figure 20.3Cause and Effect – Construct Decision Table

– White-Box – Path Testing (Coverage)Cyclomatic Complexity and Coverage CriteriaLoopsDataflow Testing [Concept Only]

Software Testing Process – P. 517– Test Case Identification and Generation [from Design]– Performance and Stress Testing– EXIT Criteria for Testing

Sam Siewert 13

Take Away – Part-1 & Part-2Value of OOA/OOD and OOP Compared to or in Addition to SA/SDOther Design Formalisms (SDL, Petri nets, Pseudocode)

Practice and Proficiency with UML (standard of practice)

Addition of Block Diagrams and SA/SD to Complete Specifications (former standard of practice)

Design Life-cycle: Concurrent Test of Requirements, Analysis, Design, Prototypes/PoC and Constructed Modules

Sustaining Life-cycle: Deployment, Maintenance, Refactoring

Sam Siewert 14