SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/...Boost,...
25
February 12, 2015 Sam Siewert SE310 Analysis and Design of Software Systems Lecture 6, Part 2 – Code Re-Use from C++ and Java OOP Libraries (Transition from Architecture to Design)
Transcript of SE310 Analysis and Design of Software Systemsmercury.pr.erau.edu/~siewerts/se310/documents/...Boost,...
February 12, 2015 Sam Siewert
SE310
Analysis and Design of Software
Systems
Lecture 6, Part 2 – Code Re-Use from
C++ and Java OOP Libraries
(Transition from Architecture to Design)
Re-Use Ideally at Design Level OOA -> OOP (C++, Ada95 or Java)
– OOP (E.g. C++) Should Compile
– Focus on Classes to Implement Domain Model
– In OOA Phase, Limited to Class Specification (Virtual and Pure Virtual Methods for Refinement, Limited to Those in OIM)
– Bodies of Methods Stubbed Out – Prints message
– OIM Becomes Test Driver in Detailed Design (later)
Prior to Starting OOD, Consider Code Re-Use Libraries During OOA Architecture to Design Transition
OOD -> OOP (C++, Ada95 or Java) – Development of Method Implementation (State Machines, Activity Diagrams,
Modularity)
– Integration of OOP API’s and Classes into Design – Design and Code Level Re-Use
– E.g. Boost, OpenCV, Allegro, PythonGameLibraries, NumPy, BLAS, LEDA
Not a Time Short-Cut! View as Method to Improve Quality and Extensibility
Consider Licensing Issues Carefully for Products
Sam Siewert 2
Domain Models – Use Case Details Complete a Design
Provide Code Re-Use Candidates and PoC
Sam Siewert 3
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
Enables Useful PoC/Prototype Code OpenCV PoC – Interactive Edge Finder, OCR
C/C++ Allegro Games - http://alleg.sourceforge.net/
Also Transformational (Ok to be Hybrid)
Display + Slider = Interactive
Sam Siewert 4
Interactive Control(s)
Visual Feedback (Interactive)
OpenCV Example
Cv Namespace for Fundamental Types/Classes Used – http://docs.opencv.org/modules/core/doc/basic_structures.html
– http://docs.opencv.org/opencv2refman.pdf
Broad User Community – Continuously Improved – C API
– C++ API
– Java API - http://docs.opencv.org/java/
– Python API - http://docs.opencv.org/trunk/doc/py_tutorials/py_tutorials.html
Use to Select Algorithms and Compare, Use in Application, Full Source
http://www.cse.unr.edu/~bebis/CS485/Lectures/Intro_OpenCV.pdf
Follow My Updated Instructions for Ubuntu – CU CV Class
Sam Siewert 5
Boost, BLAS, IPP and LEDA
Boost, C++ Boost is a set of libraries for the C++ programming language that provide support for tasks and structures such as linear algebra, pseudorandom number generation, multithreading, image processing, regular expressions, and unit
testing. It contains over eighty individual libraries. - Wikipedia
BLAS (Basic Linear Algebra Subprograms), FORTRAN (IV, 77) The Basic Linear Algebra Subprograms (BLAS) are a specified set of low-level subroutines that perform common linear algebra operations such as copying, vector scaling, vector dot products, linear combinations, and matrix multiplication. They were first published as a Fortran library in 1979[1] and are still used as a building block in higher-level math programming languages and libraries, including LINPACK, LAPACK, MATLAB,[2] GNU Octave, Mathematica,[3] NumPy[4] and R. – Wikipedia
IPP (Integrated Performance Primitives), C/C++ Intel Integrated Performance Primitives (Intel IPP) is a multi-threaded software library of functions for multimedia and data processing applications, produced by Intel.[2] – Wikipedia
LEDA (Library of Efficient Data types and Algorithms), C++ The Library of Efficient Data types and Algorithms (LEDA) is a proprietarily-licensed software library providing C++ implementations of a broad variety of algorithms for graph theory and computational geometry.[1] It was originally developed by the Max Planck Institute for Informatics Saarbrücken. – Wikipedia
Sam Siewert 6
Why No C++ Design Pattern Library
Design Re-use – Design Patterns (E.g. Singleton) should be
OOP Independent, Often Domain Specific (Domain Model)
Code Re-use – Algorithm and Data Structure Level in a
Specific PL or OOP
Design Re-Use Has Higher Payoff, But Higher Risk of
Incorrect Re-Use
Trends => Libraries -> Language Features, Design Patterns -
> Libraries
Open Research Area – No Universal Agreement, E.g. GoF
Patterns in C++
Sam Siewert 7
Architecture Transition to Design
Use Case, Domain Model (Class Diagram) -> OIM
(Instantiation, Addition of Methods, Interaction)
Refinement of Class Diagram from Domain Model to
Design Class Diagram
– Hierarchical Refinement
– Updates Based on Object Model (static instantiation) and OIM
(dynamic interaction)
– Association and Aggregation Details
Preparation to Define the Body, Implementation of
Methods and the Application Class (or Driver)
Sam Siewert 8
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-9
Key Takeaway Points
• A design class diagram (DCD) is a UML class
diagram, derived from the behavioral models
and the domain model.
• It serves as a design blueprint for test-driven
development, integration testing, and
maintenance.
• Package diagrams are useful for organizing
and managing the classes of a large DCD.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-10
Acquiring Requirements
(Domain Modeling)
Software architecture
Deriving DCD in the Methodology Context
Deriving Use Cases from Requirements
Allocating Use Cases & Subsystems to Iterations
Business goals & needs
Current situation
Preliminary requirements
Abstract & high level use cases, use case diagrams
Use case-iteration allocation matrix
(a) Planning Phase
control flow data flow control flow & data flow
(b) Iterative Phase – activities during each iteration
Actor-System Interaction Modeling
Domain Modeling
Accommodating Requirements Change
Behavior Modeling & Responsibility Assignment
Deriving Design Class Diagram
Test Driven Development, Integration, & Deployment
Customer feedback
Iteration use cases
Domain model
Expanded use cases & UI design
Behavior models
Design class diagram
Domain model
Use case-iteration allocation matrix
Producing an Architecture Design
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-11
Deriving Design Class Diagram
• A design class diagram (DCD) is a structural diagram.
• It shows the classes, their attributes and operations,
and relationships between the classes. It may also
show the design patterns used.
• It is used as a basis for implementation, testing, and
maintenance.
• It should contain only classes appear in the sequence
diagrams, and a few classes from the domain model.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-12
Deriving Design Class Diagram
• It is derived from the domain model (DM) and the
sequence diagrams:
– The domain model provides a few classes, the attributes
and some relationships.
– The sequence diagrams determines the classes, methods,
some attributes, and dependence relationships.
• DCD may contain design classes like controller,
command, GUI classes. Domain model only contains
application classes.
• DCD must be carefully specified. DM is more liberal.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-13
Steps for Deriving DCD
1) Identify all classes used in each of the sequence
diagrams and put them down in the DCD:
– classes of objects that send or receive messages
– classes of objects that are passed as parameters or return
types/values
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-14
Identify Classes Used in Sequence Diagrams
<<singleton>> classes used.
:Checkout GUI
<<uid,
cnList>>
:DBMgr
u:=get
User(uid):User
d:=get Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
:Checkout
Controller
msg:=check-
out(uid, cnList)
[u!=null] process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn
in cnList)
Identify objects that
send or receive
messages, passed as
parameters or return
type.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-15
Classes Identified
User
Document
Loan
CheckoutGUI
DBMgr
CheckoutController
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-16
Steps for Deriving DCD
2) Identify methods belonging to each class and fill
them in the DCD:
– Methods are identified by looking for messages that label
an incoming edge of the object.
– The sequence diagram may also provide detailed
information about the parameters, their types, and return
types.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-17
Identify Methods
:Checkout GUI
<<uid,
cnList>>
:DBMgr
u:=get
User(uid):User
d:=get Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
:Checkout
Controller
msg:=check-
out(uid, cnList)
[u!=null] process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn
in cnList) methods of
CheckoutControll
er
methods
of
Document
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-18
Fill In Identified Methods
User
Document
Loan
CheckoutGUI
DBMgr
getUser(uid) getDocument(callNo) saveLoan(loan) saveDocument(book)
isAvailable() :
boolean
setAvailable(a:boole
an)
<<singleton>>
CheckoutController
checkout(uid,cnList)
process(cn:String[])
create(u:User,
d:Document)
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-19
Steps for Deriving DCD
3) Identify and fill in attributes from sequence diagrams
and domain model:
– Attributes are not objects and have only scalar types.
– Attributes may be used to get objects.
– Attributes may be identified from getX() and setX(...)
methods.
– Needed attributes may also be found in the domain model.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-20
:Checkout GUI
<<uid,
cnList>>
:DBMgr
u:=get
User(uid):User
d:=get Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
:Checkout
Controller
msg:=check-
out(uid, cnList)
[u!=null] process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn
in cnList)
Identify Attributes
attribute of User
attribute value
attributes of
Document
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-21
Fill In Attributes
display(msg:String)
User
Document
Loan
CheckoutGUI
DBMgr
getUser(uid) getDocument(callNo) saveLoan(loan) saveDocument(book)
isAvailable() : boolean
setAvailable(a:boolean)
<<singleton>>
CheckoutController
checkout(uid,cnList)
process(cn:String)
create(u:User, d:Document)
uid : String
callNum : String
isAvailable : boolean
dueDate : Date
from
domain
model
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-22
Steps for Deriving DCD
4) Identify and fill in relationships from sequence
diagram and domain model:
– An arrow from one object to another is a call and hence it
indicates a dependence relationship.
– An object passed as a parameter or return type/value
indicates an association or uses relationship.
– Two or more objects passed to a constructor may indicate
an association and an association class.
– The domain model may contain useful relationships as well.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-23
Identify Relationships
:Checkout GUI
<<uid,
cnList>>
:DBMgr
u:=get
User(uid):User
d:=get Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
:Checkout
Controller
msg:=check-
out(uid, cnList)
[u!=null] process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn
in cnList)
call relationship
association w/ an
association class.
CheckoutController
and DBMgr use User.
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-24
Fill In Relationships
display(msg:String)
User
Document
Loan
CheckoutGUI
DBMgr
getUser(uid) getDocument(callNo) saveLoan(loan) saveDocument(book)
isAvailable() : boolean
setAvailable(a:boolean)
<<singleton>>
CheckoutController
checkout(uid,cnList)
process(cn:String)
create(u:User, d:Document)
uid :
String
callNum : String
available : boolean
dueDate : Date
The dashed arrow lines denote
uses or dependence
relationships.
<<create>>
Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.
11-25
From Sequence Diagram to Implementation
:Checkout GUI
<<uid,cnList>>
:DBMgr l:Loan
[a]create(u,d)
[a]saveLoan(l)
d:Document
[a]setAvailable(false)
[a]save- Document(d)
[u!=null] process(cnList)
a:=isAvailable():boolean
<<msg>>
Loop
(for each cn in cnList)
Patron u:= getUser(uid): User
d:=get Document(cn): Document
public class CheckoutGUI {
DBMgr dbm=new DBMgr ();
public void process(String[] cnList) {
for(int i=0; i<cnList.length; i++) {
Document d=dbm.getDocument(cnList[i]);
if (d.isAvailable()) {
Loan l=new Loan(u, d);
dbm.saveLoan(l);
d.setAvailable(false);
dbm.saveDocument(d);
}
}
