Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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