Transcript Class #9

Information Systems Analysis
and Design
ERD, Screen/Dialog Flow, and Architecture
INFO 620
Glenn Booker
INFO 620
Lecture #9
1
Relational Database Schema
• Only 1% of databases are fully object
oriented – so we usually need to convert our
class structure into a relational database
schema (entity-relationship diagram, ERD)
• Start with the completed application
class diagram
• Identify and keep only persistent classes
[These notes adapted from Prof. Song]
INFO 620
Lecture #9
2
Persistent Classes
• Persistent classes are those which exist
throughout the life of your system
– They capture long term data
– They do not get created or destroyed repeatedly
– They will become entities in the ERD
INFO 620
Lecture #9
3
Relational Database Schema
•
•
•
•
Remove methods and reference attributes
Each class becomes an entity
Create primary key attribute for each entity
Decompose composite attributes into
simple ones
• For multi-valued attributes, create a
separate entity with suitable keys
INFO 620
Lecture #9
4
Relational Database Schema
• For association classes or many-to-many
relationships, create an associative entity
with two foreign keys (FKs) (p. 562-3)
• For 1:many relationships, add the PK of the
1-side to become a FK for the “many” side
• For 1:1 relationships, either merge the
entities, or treat one side like 1:many case
INFO 620
Lecture #9
5
Relational Database Schema
• Use same aggregation rules
• Inheritance rules
– Each class in the hierarchy becomes an entity
– Subclass inherits PK from superclass
• That’s it!
• Draw ERD using the rules you learned in
INFO 503 or 605
INFO 620
Lecture #9
6
Screen Flow Diagram
• A screen flow diagram uses an organization
or state chart style to show how the user can
navigate among windows or reports
– Windows or reports are represented by boxes
– Lines with arrowheads represent initial
allowable paths among boxes
– Top to bottom flow implies the order in which
the user could see boxes (top first)
INFO 620
Lecture #9
7
Sample Screen Flow Diagram
Main Menu
Customer Maintenance
Add Customer
INFO 620
Remove Customer
Done using Statechart
diagram symbols;
state assumptions about
return flows possible
Search
Security Management
Modify Customer Data
Search Results
Lecture #9
Set User Permissions
8
Dialog Flow Diagram
• Same intent as the screen flow diagram,
just a different way of showing it
• Better for complex interactions
• “Diagram” looks like a table
• Each screen is represented by a row, with
the screen name followed by dashes
• Vertical lines with arrowheads show
allowable paths to other screens
INFO 620
Lecture #9
9
Dialog Flow Diagram
• Rose and Visio don’t generate these
– Can use a Word table
• For N screens, use N+1 columns
– First column has screen names
– Other N columns each represent navigation
options, starting from each screen in order
• Use extra columns if needed; state return
flow assumptions, or show them explicitly
INFO 620
Lecture #9
10
Dialog Flow Diagram
• For symbols, could use vertical line from
normal keyboard (|), and up and down
arrows ( and ) from Insert Symbol, using
the Symbol font (see next slide)
• Or could use the Drawing Toolbar, and draw
vertical lines manually
• Either way is a pain
INFO 620
Lecture #9
11
Sample Dialog Flow Diagram
Main Menu
Sec. Mgmt.
-
-
-
--
Add Cust.
--
Remove Cust.
--
Mod Cust Data
--
-|
-|
-
-
-
--
Search Results
--
--
-|
-|
-|
-|
-
--
Set User Pref.
--
--
--
Cust. Maint.
Search
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
-|
-|
-|
-|
-
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
Starting from this screen, where is it possible to go?
INFO 620
Lecture #9
12
For Term Project
• If using the Analysis & Design or Life
Cycle options, do EITHER a screen flow
diagram OR a dialog flow diagram
• State clearly if all flows are bidirectional, or
show explicitly if they aren’t
INFO 620
Lecture #9
13
Software Architecture
• Software Architecture is a very big topic –
we’ll only cover the most basic concepts
• For more info, see books recommended by
the World Wide Institute of Software
Architects (http://www.wwisa.org/ )
• Our main focus is on deciding the logical
organization of software
INFO 620
Lecture #9
14
Software Architecture
• Software Architecture is a logical structure
which results from a set of decisions about
how software is organized, and how those
elements interface with each other
• To create the architecture, there are two
activities – architectural investigation, and
architectural design
INFO 620
Lecture #9
15
Investigation and Design
• Architectural investigation is to identify
which functional and non-functional
requirements affect the design
– Security, cost, performance, growth, and
reliability may be strongly affected
• Architectural design uses the results of that
investigation to select software, hardware,
operating rules, etc.
INFO 620
Lecture #9
16
Logical vs. Physical Architecture
• The logical architecture of the system is
captured in the package, component, and
subsystem diagrams
• Where the components are deployed (e.g.
which processor or node) is shown in the
deployment diagram
INFO 620
Lecture #9
17
Architectural Patterns
• Patterns help capture major architectural
concepts at various levels of the design
– Architectural patterns are the largest level, such
as Layers pattern
– Design patterns, such as the Façade, help
connect elements of the system
– Idioms, such as the Singleton pattern apply to a
single component or object
INFO 620
Lecture #9
18
The Layers Pattern
• We’ve already mentioned the Layers pattern
in the concept of having some components
related to the user interface, some serve
applications, and some fulfill more
fundamental functions (e.g. database)
• The Layers pattern generalizes that concept
to many possible layers instead of just three
INFO 620
Lecture #9
19
The Layers Pattern
• Problem: Coupling too high; changes ripple
throughout the system
Different types of logic are intertwined so
that reusability is low
• Solution: Organize the large scale structure
of the system into layers with clear
responsibilities in each layer
INFO 620
Lecture #9
20
The Layers Pattern
• Collaboration and coupling between layers
should only flow from the top down
– Avoid reversing that flow
• The Layers pattern is a general n-tier
layered architecture
• There are over 100 variations on this pattern
INFO 620
Lecture #9
21
The Layers Pattern
• Layers from ‘top’ to ‘bottom’ could include:
– Presentation or user interface (GUI, reports,
HTML, XML, Java, etc.)
– Application (controls work flow logic, window
transitions, and preparing data to be displayed)
– Domain (implement services used by many
applications, such as Inventory class)
INFO 620
Lecture #9
22
The Layers Pattern
– Business Infrastructure (very fundamental
functions, such as CurrencyConverter)
– Technical Services (support functions for the
entire system, such as security)
– Foundation or Core (low level functions, such
as data structures, thread management, math
routines, database, and network services)
• Below the Foundation are the system’s
hardware and operating system(s)
INFO 620
Lecture #9
23
The Layers Pattern
• The top level layers are the most application
specific, and the least depended upon by
other parts of the system
• Conversely the low layers are more general,
and apply to more (or all) of the system
• Each layer typically is drawn as a package
INFO 620
Lecture #9
24
The Layers Pattern
• Coupling between packages (layers) can be
shown by dashed lines
• If used, a façade can appear within a
package (p. 454)
• External interfaces can also be
represented within packages using
the <<interface>> stereotype
• Minimize coupling!
INFO 620
Lecture #9
25
Interaction Diagrams & Packages
• Interaction diagrams can specifically show
how packages are used (p. 456)
– Separate package names with double colon
:packagename::classname is an object
– Can emphasize facades with the
<<singleton>> stereotype (like the pattern)
– Can use the interface symbol (line w/ dot) for
external interfaces
INFO 620
Lecture #9
26
Package vs Subsystem
• A subsystem is flagged with a
<<subsystem>> stereotype on a package
• Subsystems have clearly defined
responsibilities, behavior, and interfaces
• Packages are more just a group of related
functions – “A general purpose mechanism
for organizing elements into groups.”
INFO 620
Lecture #9
27
Lower Level Architecture
• Design patterns help support lower level
architectural needs
– Façade pattern controls access to lower levels
– Controller pattern are often used for application
level classes
– Observer pattern is used when a low level
function needs to monitor a higher level event
INFO 620
Lecture #9
28
Observer Pattern
• The Observer pattern allows lower level
functions (application) to send events safely
to high level (e.g. user interface)
• Creates an artificial “external” interface for
the user interface, so that the application
doesn’t need to know what kind of interface
it is (p. 462)
INFO 620
Lecture #9
29
Tiers versus Layers
• Originally a “tier” was a logical layer, but
it now often means a physical node level
• Typical tiers for a 3-tier system could be:
– Interface (PC or workstation)
– Application server
– Database server
• Adding layers often slows performance
INFO 620
Lecture #9
30
Package Design
• Often want packages to isolate components
which will need to change frequently
• Need to identify which packages are most
heavily depended upon by other packages,
and try to stabilize them quickly
• When a class changes, all classes which call
upon it generally need to be recompiled
INFO 620
Lecture #9
31
Encouraging Cohesion
• We want generally high cohesion – group
things which fulfill a similar function
• Can quantify cohesion, but rarely needed
(p. 477)
• Often group interfaces together
• Could group by frequency of change,
not as much by functionality
INFO 620
Lecture #9
32
Encouraging Cohesion
• Packages upon which many things depend
need to be the most stable packages
• Factor out types of packages which are very
different from other packages (e.g. SQL)
• Avoid cyclic dependency between packages
(A calls B and B calls A)
– Break by making an interface for B, see p. 481
INFO 620
Lecture #9
33
Software Architecture Document
• Factors affecting the software
architecture are described in the
Supplementary Specification
• The Software Architecture Document
(SAD) describes the effect those factors had
on the actual architecture
• Architecture analysis starts during Inception
phase, and is a key result of Elaboration
INFO 620
Lecture #9
34
Architectural Analysis
• Architectural Analysis looks for nonfunctional requirements which will affect
how the system is structured
• How reliable are external services? What
happens if they aren’t available?
• How does licensing of components affect
the design?
INFO 620
Lecture #9
35
Architectural Analysis
• How does distribution of functions affect
speed and quality of service?
– Volume and number of messages sent among
nodes could severely tax hardware limits
• How different are local requirements
and needs? Are all parts of the system
needed everywhere?
INFO 620
Lecture #9
36
Architectural Analysis
• Based on these factors, make
architectural decisions
– Some will affect application architecture (how
functions are assigned to components)
– Some will affect system architecture (hardware
and software of entire system)
• We’ve also seen logical versus physical
architectural views
INFO 620
Lecture #9
37
Architectural Analysis
• Quality limits may affect architecture
very strongly
• Distinguish between average performance
goals, versus allowable goals
• Be able to describe how goals will be
measured – is it testable?
• Be sure goals are needed and significant
INFO 620
Lecture #9
38
Architectural Analysis
• Can describe key factors in a table (p. 490)
in the Supplementary Specification if they
apply to the entire system or most use cases
• Factors may also appear in the use case
documentation (special requirements,
technology and data variations list, and
open issues)
INFO 620
Lecture #9
39
Architectural Views
• In the SAD there could be six types of
views of the architecture’s influence:
1. Logical – the package, component, and
subsystem diagrams
2. Process – activity, statechart, and
interaction diagrams
3. Deployment – as in the diagram
INFO 620
Lecture #9
40
Architectural Views
4. Data – the ERD derived from the final
class diagram
5. Use case – the use case diagram
and documentation
6. Implementation – the actual source code
used to implement the system, and the final
executable system itself
INFO 620
Lecture #9
41
Persistence Frameworks
• More generally than the ERD discussion
earlier, a persistence framework is a set
of classes which will support saving
persistent objects
• Could be stored in a relational database,
Java Data Objects, XML files, flat files, etc.
INFO 620
Lecture #9
42
Frameworks
• Frameworks are a set of objects which
are designed to be extended for
specific functions
• Java Swing GUI and the Apple Cocoa
environments are frameworks to support
quick OO design and implementation
• Frameworks provide core functions (file,
GUI, basic I/O, etc.) and support Observers
INFO 620
Lecture #9
43
Frameworks
• Frameworks a cohesive set of interfaces and
classes for fundamental functions
• They contain classes which generally expect
the developer to subclass off of them
• They deliberately support reuse
INFO 620
Lecture #9
44
Object Identifier (OID)
• Is a pattern:
• Problem: Need to relate objects to record
• Solution: Assign an OID to relate each
object and record
• The OID is the primary key (PK) for the
data table
• The OID is an attribute of the class, of type
OID (p. 542)
INFO 620
Lecture #9
45
Database Broker or Mapper
• The façade for a persistent object doesn’t
directly get data from that object
• Could let persistent data object get its data
– Called Direct Mapping design approach
– Consistent with Information Expert
• But if the database doesn’t manage this
automatically, this could violate Low
Coupling and High Cohesion
INFO 620
Lecture #9
46
Database Broker or Mapper
• Then use a database broker (also called
mapper by Fowler) pattern
• “Mapper” preferred since broker has
other meanings
• A mapper class is defined for each
persistent object class
• A generalized mapper class handles all
similar data requests (p. 545)
INFO 620
Lecture #9
47
Metadata Mappers
• When using reflexive programming
languages, can define a description of data
types, so that data can be mapped from its
type to appropriate classes
• More flexible than just mapping ERD to
classes, it allows data structures to be
changed without affecting the mapping
INFO 620
Lecture #9
48
Template Method
• A pattern:
• Problem: an algorithm must be followed
which varies in a predictable way for
different cases or situations
• Solution: use the Template method
• A template method is in a superclass which
has common parts of the algorithm in a
protected method
INFO 620
Lecture #9
49
Template Method
• Then each subclass can rewrite methods as
needed (p. 547)
– The method which may be overwritten is the
“hook method”
– Typically the template method (here, “update”)
is public, and the hook method (“repaint”)
is protected
– The template method calls the hook method
INFO 620
Lecture #9
50
Concurrency and Threads
• UML has notation for describing tasks
which occur simultaneously, or have to
wait for other tasks to complete
– Each task is a “thread”
– Major design issues may include preventing
threads from interfering with each other, or
prevent them from waiting for each other
• Beyond scope of class
INFO 620
Lecture #9
51