Information Systems Analysis and Design ERD, ScreenDialog Flow, and Architecture

1
Information Systems Analysis and DesignERD,
Screen/Dialog Flow, and Architecture

• INFO 620
• Glenn Booker

2
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
3
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

4
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

5
Relational Database Schema

• For association classes or many-to-many
  relationships, create an associative entity with
  two foreign keys (FKs) (p. 562-3)
• For 1many relationships, add the PK of the
  1-side to become a FK for the many side
• For 11 relationships, either merge the entities,
  or treat one side like 1many case

6
Relational Database Schema

• Use same aggregation rules
• Inheritance rules
• Each class in the hierarchy becomes an entity
• Subclass inherits PK from superclass
• Thats it!
• Draw ERD using the rules you learned in INFO 503
  or 605

7
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)

8
Sample Screen Flow Diagram
Done using Statechart diagram symbolsstate
assumptions about return flows possible
9
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

10
Dialog Flow Diagram

• Rose and Visio dont generate these
• Can use a Word table
• For N screens, use N1 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

11
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

12
Sample Dialog Flow Diagram
Starting from this screen, where is it possible
to go?
13
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 arent

14
Software Architecture

• Software Architecture is a very big topic well
  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

15
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

16
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.

17
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

18
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

19
The Layers Pattern

• Weve 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

20
The Layers Pattern

• Problem Coupling too high changes ripple
  throughout the systemDifferent 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

21
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

22
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)

23
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 systems hardware
  and operating system(s)

24
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

25
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 ltltinterfacegtgt
  stereotype
• Minimize coupling!

26
Interaction Diagrams Packages

• Interaction diagrams can specifically show how
  packages are used (p. 456)
• Separate package names with double
  colonpackagenameclassname is an object
• Can emphasize facades with the ltltsingletongtgt
  stereotype (like the pattern)
• Can use the interface symbol (line w/ dot) for
  external interfaces

27
Package vs Subsystem

• A subsystem is flagged with a ltltsubsystemgtgt
  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.

28
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

29
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
  doesnt need to know what kind of interface it is
  (p. 462)

30
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

31
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

32
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

33
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

34
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

35
Architectural Analysis

• Architectural Analysis looks for non-functional
  requirements which will affect how the system is
  structured
• How reliable are external services? What happens
  if they arent available?
• How does licensing of components affect the
  design?

36
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?

37
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)
• Weve also seen logical versus physical
  architectural views

38
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

39
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)

40
Architectural Views

• In the SAD there could be six types of views of
  the architectures influence
• 1. Logical the package, component, and
  subsystem diagrams
• 2. Process activity, statechart, and
  interaction diagrams
• 3. Deployment as in the diagram

41
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

42
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.

43
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

44
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

45
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)

46
Database Broker or Mapper

• The façade for a persistent object doesnt
  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 doesnt manage this
  automatically, this could violate Low Coupling
  and High Cohesion

47
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)

48
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

49
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

50
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

51
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