Transcript Design

Design
Analysis builds a logical model
that delivers the functionality.
Design fully specifies how this
functionality will be delivered.
Design looks from the
implementation point of view.
Goals
• Flexible, Flexible, Flexible
• Should be fluid enough to modify and
extend
• Efficiency
• Secure and reliable
• Look for available components
• Each package becomes a subsystem
• Details for interfaces is emphasized
• For small systems you may take the
analysis model and convert it into the
design model
• For large complex systems maintain two
models
• Ensure that these two models are
consistent with each other
Deliverables
•
•
•
•
•
Design classes – with all details
Design subsystems – with all details
Interfaces
Use-case realization design
Deployment diagram
Flexibility
•
•
•
•
•
Model-View-Controller Architecture
UI
Application
Database
Three separate pieces that are developed
independently
• Interfaced with each other
Design considerations
• Concurrency issues
• Language issues
• Administrative issues
– Procedures
– Versioning
– Permissions and security
– Responsibilities
– Documentation
– Schedules and testing
Design classes
•
•
•
•
•
•
•
Ready to be implemented classes
Interface and implementation
Detailed and Refined analysis classes
Implementation required classes
All attributes and operations are to be specified
Figure 15.2
Completeness and sufficiency for users of the
class
• High cohesion and low coupling
• Use inheritance with care
• In analysis inheritance is used only when an “isa” relationship exists between analysis classes
• In design you may use inheritance for the sake
of code re-use
• Inheritance is the strongest form of coupling and
most inflexible
• Template classes (general-purpose classes) that
can be parameterized at runtime may be used
Relationship - design
• Refining associations into aggregation or
composition
• Implementing all forms of associations (1-1, 1-n,
n-n)
• Aggregation and composition implements 1-1
and 1-n and n-1
• Issues with reflexive association
• Implementing association classes Clarifying all
of this is refining analysis relationship into
design relationship
• Associations can have properties –
particularly when multiplicity is allowed
• This clarifies cases of every instance of
association
• Composition, Aggregation, Collection
• When to use collection?
• Many to Many association needs to be
reified – concretized
• Bidirectional associations needs to reified
to avoid cyclical ownership!!
• Analysis may have Association class!!
• Simple association constraints since it
depicts only one association for every
instance of the object pair associated
• Otherwise you need a separate class then
inter-relate them appropriately
• Navigation through a multiple association
can be qualified using a qualifier (like
member-id) as part of the association
Sample Relationship
• Manager manages one office
• Supervisor may manage many projects
• Supervisor’s time is broken-up over
projects
• A vendor works with many offices
• An office uses many vendors
• A project is assigned the necessary
personnel
Sample Relationship
• Corporation has a head office and many
other offices
• Offices co-ordinate many projects and
warehouses
• Projects may have warehouses assigned
• Projects may choose from one or another
plant
• Offices may be added or eliminated
• Newer warehouses may be added
Collection class
• These specialize in managing collection of
other objects
• Essentially an ADT handler
• Vector class is an example
• Implements 1 to *
• Reify for n-n or * - * – what does that
mean?
Interfaces
• Interface defines a contract
• Separates definition from implementation
• Class defines an interface and an
implementation
• Interfaces do not carry any attributes and
relationships
• Derived classes gets the interface,
attributes, and relationships from the
parent class
• Interfaces contribute only contracted
operations and can be used for plug-in
components
• Do not carry relationship
• One may use pure abstract classes
without relations – instead
• Interfaces can become complex – why?
• Interfaces have additional overhead –
how?
• Figure 17.3, 17.4 shows the use of
interface
• Section 17.4 describes how to design
using interfaces
• Subsystems are designed to
– Separate design concerns
– Represent large grain component
– Wrap legacy systems
• Figure 17.10
• Adv. And dadv. of interfaces
Use-case design
• Detail the steps of use-case – sequence
diagram. Fig 18.2,3,4
• Refine activity diagrams
• Develop state charts
State Chart
• Similar to DFA
• Defines states and transitions of one Reactive Object
• Reactive objects respond to external events, clear
lifecycle and state dependent behavior
• Start node and potential end-node
• Other nodes are intermediate well-defined states of the
element
• State transitions are triggered by system events
• Events can be guarded
• Transitions can also have actions
• Figure 19.4, 19.5
State Info
•
•
•
•
•
•
•
State name
Entry with action
Exit with action
Internal transitions and actions
Internal activity
Actions are atomic/uninterruptible
Activities may be interrupted by events
• Call event
• Signal event
– one way asynchronous communication
• Change event
– Boolean condition change
• Time event
– Absolute time
– Elapsed time
• There can be composite states - with
decomposition indicators
• There can be concurrent composite states
– Fork and/or join
– Indicative of concurrency within the object
– Can communicate between concurrent states
using attributes
• Sync states
– Synchronization/communication between submachines
• History of an object
– Shallow and deep history
• Fig. 20.3-11
Implementation
• Implement class
• Implement subsystem
• Perform unit testing
Component
• Physical replaceable part of a system
• Each component may contain many
classes and realize many interfaces
• A class can be shown to be inside a
component in 2 ways - fig 22.2
• Components usually are used to
implement significant aspects of the
system
• Database access
• Issues pertaining to distributed system
– Synchronization
– Replication
– Failure handling
•
•
•
•
•
Transaction processing
Persistence
Security
Resource Pooling
User Interface
Deployment
• Map of software architecture to hardware
architecture
• Type and possible deployments
• Nodes, relationships and component on
nodes
Objectives of Design
•
•
•
•
•
•
•
Streamline Implementation
Faster delivery
Standardized product
Cheaper
Components
Patterns
Framework
Topics for CASE tool
• http://www.cs.queensu.ca/SoftwareEngineering/toolcat.html#label233
• http://www.rspa.com/spi/CASE.html
• http://www.geocities.com/millermax2001/c
asetool.html
• www.Ilogix.com
• www.gentleware.com