INFO 620Lecture #91 Information Systems Analysis and Design ERD, Screen/Dialog Flow, and Architecture INFO 620 Glenn Booker

INFO 620 Lecture #9 1

Information Systems Analysis and Design

ERD, Screen/Dialog Flow, and Architecture

INFO 620

Glenn Booker


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]


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



• 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



• 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



• 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


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)


Sample Screen Flow Diagram

Main Menu

Customer Maintenance Search Security Management

Add Customer Remove Customer Modify Customer Data Search Results Set User Permissions

Done using Statechart diagram symbols;state assumptions about return flows possible


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


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


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


Sample Dialog Flow DiagramMain Menu -- -- -- -- -- -- -- -- -- Cust. Maint. -- -- -- -- -- -- -- -- -- | Search -- -- -- -- -- -- -- -- -- | | Sec. Mgmt. -- -- -- -- -- -- -- -- -- | | Add Cust. -- -- -- -- -- -- -- -- -- | | Remove Cust. -- -- -- -- -- -- -- -- -- | | Mod Cust Data -- -- -- -- -- -- -- -- -- | Search Results -- -- -- -- -- -- -- -- -- Set User Pref. -- -- -- -- -- -- -- -- --

Starting from this screen, where is it possible to go?


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


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

http://www.wwisa.org/


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


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.


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


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


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


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


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


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)


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)


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


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!


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


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


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


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)


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


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


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


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


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


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 aren’t available?

• How does licensing of components affect the design?



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



• 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



• 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



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


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


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


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.


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


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


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)


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


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)


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


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


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


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

Documents

INFO 620Lecture #91 Information Systems Analysis and Design ERD, Screen/Dialog Flow, and Architecture INFO 620 Glenn Booker