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