SE300 Software Engineering Practicesmercury.pr.erau.edu/~siewerts/se300/documents/Lectures/... ·...
Transcript of SE300 Software Engineering Practicesmercury.pr.erau.edu/~siewerts/se300/documents/Lectures/... ·...
-
February 5, 2015 Sam Siewert
SE300
Software Engineering Practices
Lecture 5, Part 2 – Revisiting Use
Cases and Transition from Architecture
to Design
-
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
6-2
Four Common Types of Systems
(a) Interactive subsystem
a
b
c
c
z
y x
a
a/x
b/y c/z
b
(b) Event-driven subsystem
(c) Transformational subsystem (d) Database subsystem
-
Architecture Patterns
No Pattern is Perfect Fit and Real Applications May Have Aspects (and Requirements) from Multiple Patterns
Hybrid Architectures Combine Capabilities
Classify First Based on Primary Use and Capabilities and Refine Through Agile XP, Scrum or Spiral Process
1. Transformational – E.g. Image Processing
2. Interactive – E.g. User Interface
3. Service Oriented Architectures – Transactional – E.g. Database Services
– Client/Server – E.g. Web Browser, Disk Drives (Storage), File Systems
4. Event Driven – E.g. Robotics, E-mail, Digital Control – Hard Real-Time Event Driven – E.g. Anti-lock Braking System (Digital
Control with Specific Deadlines for Response to Events)
– Soft Real-Time Event Driven – E.g. Digital Video for Cable or Netflix
– Best Effort Event Driven – E-mail Reminder System
Sam Siewert 3
-
Canny Edge Finder – Threshold Control Consider a Transformation – Continuous Image
Processing with a Simple Control Added
Sam Siewert 4
-
Activity – Canny Interactive Demo
Slider – What is Going on? – Think, Pair, Share
1. Is this Transformational?
2. Is this Interactive?
3. Is this Something Else?
4. What are Key Capabilities and Requirements?
5. What Sorts of Applications Could We Use Canny For?
Sam Siewert 5
-
License Plate or Sign OCR MATLAB Example – Reading a Sign
Canny is Fundamental Step – Transformational Capability in a
Larger Application (OCR)
Correct Threshold for Intensity Gradient to Segment Image
Sam Siewert 6
http://www.mathworks.com/help/vision/examples/automatically-detect-and-recognize-text-in-natural-images.html
-
Domain Models – Use Case Details Further Domain Model with Use Case Details
Sam Siewert 7
Start Here!
https://www.modelio.org/
http://argouml.tigris.org/
Helpful Validation and Verification Features for
Design
• Integrated Models
• Checklists – Completeness
• CPP and Java Code Generation
WARNING: ArgoUML has bugs, so use only
to review Argo design examples
USE Modelio as your DESIGN TOOL
https://www.modelio.org/http://argouml.tigris.org/
-
Supplements to Chapter 9 in Pressman
Use Cases are Critical
What’s in the System, What’s Not
Who are the Actors – Scenarios Start and End with an
Actor
Precursor to Activity Diagrams (We’ll Defer Discussion
for Later Date)
Behavioral Side (Compared to Classes and Class
Diagrams)
Sam Siewert 8
-
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-9
Simplify with Use of Inheritance
Login
Logout
SAMS/Search Program
SAMS
End User
SAMS
Admin
SAMS
Staff
This is OK. Login
Logout
SAMS/Search Program
SAMS
End User SAMS
Admin SAMS
Staff Better
Study-Abroad Management
System
P. 179, Example 7.4
-
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-10
Use Case Diagram
Log In
Log Out
Start Up
SAMS
SAMS
End User
SAMS
Staff User SAMS
Admin
Add Program
Delete Program
Edit Program
Create User
Delete User
Update User
Search for Programs
Display Program
Detail
Apply Online
Shutdown
-
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-11
Create User
Delete User
Update User
SAMS/User Mgmt
SAMS
Admin
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMS
Staff
Search for Programs
Display Program
Detail
Apply Online
SAMS/End User
SAMS
End User
Start Up
Shutdown
Login
Logout
SAMS/Authentication
SAMS
End User SAMS
Admin SAMS
Staff
Software engineering
principle applied:
• separation of
concerns
• divide and conquer
-
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
7-12
What Should Be In and Out?
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMS
Staff
Login
Login
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMS
Staff
Login
Login
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMS
Staff
Login
Login
DB
Add Program
Delete Program
Edit Program
SAMS/Program Mgmt
SAMS
Staff
Login
Login
Hacker
Only use cases and
their relationships
are allowed in the
boundary.
-
Tying Use Case Back to Requirements
Create Traceability – Rn is Described by Use-Casen
Prioritize Requirements (Shall, Must, Should, …)
Sam Siewert 13
Help Distinguish Requirement
Priority Based on Use and Use
Case Based on Requirements
Weight
Drive Next Steps and Focus for
Walk-throughs and Inspections
based on Highest Column Scores
or Perhaps Adjust Weightings
-
Agile with Use Cases
Create Backlog – Attack Highest
Priority Use Cases First
Schedule Scrums Around Use
Cases
Synchronize with SQA on Use
Case Acceptance Testing
Simple – Easy to Share with
Customer
Sam Siewert 14
Work with Customer – Use Case
Inspection or Walk-through
Team – Walk-throughs and
Division of Labor, Planning and
Backlog
Refinement of Requirements
Frequent Delivery of Small
Increments (Use Case Design,
Construction, Coding)
What the System Includes and
Does not (Boundary)
-
Minute Paper #3 – Architecture and
Application of YOUR Interest
Think about Architecture Patterns and Applications
Discussed so Far …
Choose an Application that Emphasizes one of the
Architecture Patterns and Describe Why it Interests
You?
Turn in Your Minute Paper
Sam Siewert 15
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 16
Software Engineering Design
Data/Class design – transforms analysis
classes into implementation classes and data
structures
Architectural design – defines relationships
among the major software structural elements
Interface design – defines how software
elements, hardware elements, and end-users
communicate
Component-level design – transforms
structural elements into procedural descriptions
of software components
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 17
Analysis Model -> Design Model
Analysis Model
use-cases - text
use-case diagrams activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams processing narratives
f l ow- or i e nt e d
e l e me nt s
be ha v i or a le l e me nt s
c l a ss- ba se d
e l e me nt s
sc e na r i o- ba se d
e l e me nt s
class diagrams analysis packages
CRC models collaboration diagrams
state diagrams
sequence diagramsD a t a / Cla ss D e sign
A rc h it e c t u ra l D e sig n
In t e rf a c e D e sig n
Co m po n e n t -
L e v e l D e sig n
Design Model
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 18
Design and Quality
the design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.
the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 19
Quality Guidelines A design should exhibit an architecture that (1) has been created using
recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion
A design should be modular; that is, the software should be logically partitioned into elements or subsystems
A design should contain distinct representations of data, architecture, interfaces, and components.
A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.
A design should lead to components that exhibit independent functional characteristics.
A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.
A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
A design should be represented using a notation that effectively communicates its meaning.
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 20
Design Principles
The design process should not suffer from ‘tunnel vision.’
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being created, not after the fact.
The design should be reviewed to minimize conceptual (semantic) errors.
From Davis [DAV95]
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 21
Fundamental Concepts Abstraction—data, procedure, control
Architecture—the overall structure of the software
Patterns—”conveys the essence” of a proven design solution
Separation of concerns—any complex problem can be more easily handled if it is subdivided into pieces
Modularity—compartmentalization of data and function
Hiding—controlled interfaces
Functional independence—single-minded function and low coupling
Refinement—elaboration of detail for all abstractions
Aspects—a mechanism for understanding how global requirements affect design
Refactoring—a reorganization technique that simplifies the design
OO design concepts—Appendix II
Design Classes—provide design detail that will enable analysis classes to be implemented
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 22
Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a]
Structural properties. This aspect of the architectural design
representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are
packaged and interact with one another. For example, objects are
packaged to encapsulate both data and the processing that manipulates
the data and interact via the invocation of methods
Extra-functional properties. The architectural design description
should address how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other system
characteristics.
Families of related systems. The architectural design should draw
upon repeatable patterns that are commonly encountered in the design
of families of similar systems. In essence, the design should have the
ability to reuse architectural building blocks.
-
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014) Slides copyright 2014 by Roger Pressman. 23
Patterns Design Pattern Template
Pattern name—describes the essence of the pattern in a short but
expressive name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is
applicable
Structure—describes the classes that are required to implement the
pattern
Participants—describes the responsibilities of the classes that are
required to implement the pattern
Collaborations—describes how the participants collaborate to carry out
their responsibilities
Consequences—describes the “design forces” that affect the pattern and
the potential trade-offs that must be considered when the pattern is
implemented
Related patterns—cross-references related design patterns
-
Practical Concern – Management of
the Revisions of Artifacts
Artifacts Include:
– Requirements Text and Analysis
– Architecture Diagrams and Documents
– Design Diagrams and Documents
– Prototype Code and Proof-of-Concept Code
We Need a Project Archive for All Artifacts
Detailed Configuration Management and Version Control
for all Code
Sam Siewert 24
-
Integration and Test Integrate Software Modules [units] and Hardware Components into Sub-systems – CMVC is Critical at all Phases, but Can’t Live without it During I&T!!
Test Focus on Interfaces [Function, Message, Shared Memory, Hardware], Protocols, and Interoperability of Modules
Sam Siewert 25
-
GitHub and GitHub Desktop Primer Use CMVC from Now On
– Install GitHub Desktop on Windows or Mac
– Create GitHub Account - https://github.com/
– Code is Public for FREE Use
– Clone from siewertserau or PRClab or Desktop
git clone https://github.com/siewertserau/Examples-RAID-Unit-Test.git
You need my permission to push changes back, but anyone can pull
Sam Siewert 26
https://windows.github.com/https://mac.github.com/https://github.com/https://github.com/https://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.githttps://github.com/siewertserau/Examples-RAID-Unit-Test.git
-
University Machines PRClab has Git client for Cloning and CMVC on EE Servers
See Cloning Path on GitHub Desktop / Web – View on GitHub
– Use SSH or HTTPS to Clone [SSH is Preferred]
Sam Siewert 27
Grab clone path here
Clone to Desktop here
Get Archive here
-
Git RAID Example - Browse
To See What I Changed, Browse
First, 4 New “+” Lines for Includes for Simple file I/O
Next, 2 New Lines to Declare Simple file Descriptors
Sam Siewert 28