Glossary

 

Analysis Object Interaction Diagram:   Graphical representation of an Analysis Scenario, a high level view of how objects or object instances, defined in the Analysis Object Model, interact in order to carry out the system requirements.  The focus is on protocol (how objects interact), including event flows or message passing between objects.  Sequence diagram in UML.

 

Analysis (Object) Model:   Fundamental way to document static aspects of objects in the problem domain.  The basic idea is to decompose a system down into classes of objects that cooperate by passing messages to solve the problem.  May use CRC cards to focus on why classes must interact and Analysis Object Interaction Diagrams to focus on how objects interact.  Compare with Design (Object) Model.

 

Analysis Pattern:   In the context of Solution Delivery, the realization that a previously-established pattern is occurring in a business domain and the subsequent representation of that essential business concept in a particular business model and design.  Contrast with Business Pattern, Design Pattern and Domain Pattern.

 

Analysis Scenarios:   An elaboration of a use case (use case + initial conditions [assumptions] + outcomes).  A reflection of the system requirements.  Drives the analysis phase.  Often used to develop Object Interaction Diagrams.

 

Application Developer:   Responsible for (among other things): coordination of all database access; ensuring that all developed code (including script) is fully functional, documented, verified and tested; researching solutions (innovation); communication with Designers, Analysts and Architects; communication with customers and clients; conducting design reviews; conducting usability and acceptance testing.

 

Application Implementation Team:   Any collection of individuals convened for the purpose of implementing a technical solution to a specific business need.  Typical groups are business account teams in Information Technology (Client Services), Web Development and CIS (Customer Information Services).

 

Application Requirements/Analysis/Design:   That portion of the solution architecture pertaining to the definition and analysis of the business problem to be solved and the design of its solution.

 

Application Topology:   The definition of logical “nodes” to illustrate ways to configure interaction between users, applications and data.  An application topology focuses on the principal layout of the application and the application logic.  It does not show actual middleware, files or databases (see Runtime Topology).  An Application Topology leads to a Runtime Topology.

 

Business Activity Monitoring (BAM):  

 

Business Cash Flow Model:   See Model for generic modeling characteristics and to contrast various model types.

Allowances – Portion of sales expected to be returned, lost in delivery, or otherwise requiring the company to refund the customers' money.

Cost of Sales – Expenses directly related to creating the goods or services being sold (like the cost of raw materials, salaries of persons turning raw materials into sellable goods, depreciation of equipment).  Excludes expenses like R&D, marketing, and interest payments on debt.

Gross Profit – Net revenue minus sales cost and taxes.

Gross Revenue – "Raw" sales income; the payments actually received by the company when customers make purchases or receive services.

Net Profit – Also net income or profit.  After-tax profit, before paying dividends.

Net Revenue – Income from sales of goods and services, minus the cost associated with things like returned or undeliverable merchandise.  A.K.A. sales revenue.

Operating Expenses – Expenses associated with running a business but not considered directly applicable to the current line of goods and services being sold. These include Sales and Marketing, R & D, and General and Administrative costs (including the salaries of people working in these areas).

Receivables – Sales that have not yet been collected.

Sales – Payments promised to be paid by customers for services and products.

 

Business Functional Requirements:   That collection of requirements that drives application analysis (e.g. external agents (human and non-human) and scenarios of usage).  See Solution Delivery Components.  Contrast with Business Non-functional Requirements.

 

Business Intelligence Enabled Environment:   An environment that helps an enterprise combine and analyze disparate data sources.  Information derived in this manner could provide key insights and data points that can be used to make informed and intelligent business decisions.  This environment typically includes systems such as data warehousing, data mining, trend analysis, simulations, and executive and knowledge asset information management.  Knowledge assets are comprised of the knowledge regarding markets, products, technologies, and organizations that businesses own or need to own, and that enable its business processes to generate profits and provide value.

 

Business Non-functional Requirements:   That collection of system requirements that are not directly related to what the system should do for the business unit.  This includes delivery platform definition, development platform definition, performance, reliability, maintainability, cost, response time, security, availability, data consistency, data integrity.  See Solution Delivery Components.  Non-functional requirements drive the system design.  Contrast with Business Functional Requirements.

 

Business Pattern:   A business practice abstracted to the point that it is independent of any specific corporation's implementation, yet is still applicable to all;  does not refer to computer-based solutions or middleware structure that supports implementation.  See, for instance, Collaboration, Extended Enterprise, Information Aggregation and Self Service.   Contrast with Analysis Pattern, Design Pattern and Domain Pattern.

 

Business Practice:   (1) The way a company conducts business -- including business principals, business goals, business processes, and services and products provided.  (2) The specific implementation of a Business Process or Processes.  Takes into consideration the Business Process(es), the Business Process users, and the mechanism(s) of communication between them.

 

Business Process:   A corporate-internal Business System (or set of internal Business Systems) exercised to serve customers.  Also, a Business System (or Systems) with workflow.  Business Process analysis, design and modeling might be carried out by a Business Analyst or by business analysis/design/modeling specialists:

Business Proocess Analysis – Assemble information on the connected activities and relationships that transform specific business sub-process inputs to outputs, by interviewing corporate decision makers and process personnel.  Activities and relationships may extend across organizational structures and across international boundaries.  Primary work products are a thorough, documented understanding of the as-is business process requirements (goals), inputs, outputs, workflow, IT architecture and resource utilization.

Business Process Design – Given the business process analysis results, determine how to make the process more efficient and effective.  "Efficient and effective" may be measured by various metrics, usually determined by business goals (e.g. ROI).  Bottom-line design requirement should be to satisfy internal and external customers in a way that is aligned with the overall business goals.  Primary work products are a set of documents that completely quantify the to-be business process architecture (inputs, outputs, workflow, IT architecture and resource utilization).

Business Process Model – An abstraction of a Real World Business System, used to focus attention on important business process aspects and as a repository for pertinent business requirement, analysis, design and implementation information.  Model-driven Software Development necessitates a close continuity between a business model and any resulting domain software.  See Model for generic modeling characteristics and to contrast various model types.

 

Business Process Execution Language (BPEL):   Actually WS-BPEL, Web Services Business Process Execution Language.  An XML-based language that models the communication between business domains by using Web Service interfaces.  Specifies an executable business process that relies on WSDL.  Reference SOE/SOA.

 

Business Process Modeling Language (BPML):  

 

Business Process Modeling Notation (BPMN):   A standardized (OMG) graphical notation for drawing business processes in a workflow.  BPMN is intended to serve as a common language for bridging the communication gap that frequently occurs between stakeholders in business process design and business process implementation.

 

Business Requirements Model:   Includes (1) Business Rules: statements that express business policies (business term, roles, rights, duties, ...) and constraints on creating, updating, and removing persistent corporate data (rules that get decomposed into component parts, each with accompanying (graphical) constraint and attribute notation).  The core of functional requirements.  (2) Operational Rules: statements directly related to performance (response time, security, availability, data consistency, data integrity, ...). The core of non-functional requirements.

 

Business System:   A collection of business entities that work together to reach a common goal or goals.

 

Business Unit:   A department identified in the business organization chart, with significant responsibilities and contributions toward the financial success of the company.

 

Business Vision:   In the business development process, a statement from upper management addressing the business value of the the business development to be done.  This statement may be often referred to during development to refocus parts of the project.

 

Capacity Planning: A business process that attempts to predict when future load levels will surpass the current load-carrying capacity of a business process.  May also include the ability to model, simulate and analyze forecast business processes.

Business Case – A document that justifies conducting a development project, showing not only direct financial costs and benefits but also the costs and benefits of all related business concerns.

Creative Brief – A document addressing the use and value of the development project end product, from the viewpoint of the target audience and from the viewpoint of the proposing department (client).

Business Requirements – A list of business conditions or capabilities necessary for the development project to be successful.

Analyze Infrastructure Incremental Needs – Process of converting business needs to technical solutions.

Business Model – Used to gather measurable business objectives and convert them into performance requirements.

Functional Model – Describes the business functions performed by an electronic business.

Customer Model – Captures elements of user behavior in terms of navigational patterns, business functions used, frequency of function access and times between function access (e.g. by using CBMG or CVM) [i] for specific e-business functions.

Workload Model – Describes the electronic business workload in terms of intensity (e.g. arrival rates (hits per time unit, page views (transactions) per time)) and navigational patterns (e.g. CSID, cluster analysis (based on transaction volume/types, transaction complexity)) ¹ for specific e-business functions.

Enterprise Architecture – The types of hardware (e.g. servers, routers, load balancers, firewalls, disk farms), software (e.g. operating systems, middleware, database management systems), network components and network protocols used to build an electronic business.

Resource Model – Represents, at some modeling level, the infrastructure (hardware, software, support) components of an electronic business – from both the operations and applications environments.

Performance Model – Used to calculate performance metrics (e.g. response time, throughput, utilization, queue lengths) as a function of architecture (expressed through (a) systems parameters such as load balancing philosophy, queue lengths, number of threads supported by database management systems, network protocol restrictions and (b) resource parameters such as disk seek times, latency and transfer rates, network bandwidth, router latency, CPU speeds, support availability), workload intensity (e.g. number of sessions per time unit, number of secure operations required, number of database transactions required per time unit) and customer navigation patterns (e.g. CPU time of transactions at the application server, total transmission time of responses from Web server to customer, total IO time at the database for a specific access function, actual Web pages traversed, customer think time).  Modeling may be carried out by actual measurement (e.g. load testing with performance monitoring), by simulation (e.g. discrete event with system and workload parameters) and/or by analytic equation (e.g. queuing models with system parameters).

Infrastructure Design – The process of determining an IT infrastructure that best supports a given electronic business (by comparing measured infrastructure performance with the business-derived performance model; and model verification, model / infrastructure validation).

 

Change Management:   Attempting to reduce the cost of change (CoC) by anticipation and adaption.  Anticipation involves planning for the future and predicting what kinds of change are possible.  Adaption means waiting until requirements evolve or changes manifest themselves and then building them into the product. ²

 

Collaboration:   A business pattern that captures the interaction among employees, vendors, customers, suppliers and business partners.  E-mail is an example of one of these collaboration tools.  Other internal examples include real-time information sharing via agents, shared document libraries, discussion databases, newsgroups, and expert identification and information collection through monitored online chat rooms.

 

Component Design, Build and Test:   Each cycle produces a working and tested yet (incomplete) version of the final product.

 

Content Auditing:   That portion of the presentation pertaining to building and verifying the message given to the customer, and the message continuity with the corporate image.

 

Corporate Shell:   The collection of legacy and electronic business (e-business) practices.

 

Corrective Maintenance:   Transfer ongoing maintenance responsibilities to appropriate groups.

 

Cost Elements:   The general, high level accounting categories forecast in yearly budget estimates.  These values would be based on high levelproject requirements and specifications statements.

 

Customer Care Web Initiative:   That part of Customer Relationship Management, Enterprise Resource Planning and Supply Chain Management that does not involve extensive use of a Business Intelligence Enabled Environment, but does require an E-commerce Enable Environment (reference the above links and this Figure).  The vision of this initiative is that it be a key driver of future customer relationship, resource planning and supply chain management while meeting the needs of today's customers.

 

Customer Relationship Management:   A business process used to learn more about customers’ needs and behaviors in order to develop stronger customer relationships.  CRM sub-processes include prospecting, marketing, sales, customer service, and support.  These sub-processes cover all the ways in which customers and the business can interact (person to person, call center, kiosk, voice-response unit and the Internet).  Reference Customer Care Web Initiative.

 

Design Object Interaction Diagram:   Used for dynamic modeling in an object-oriented design.  A graphical representation of object collaborations in a design scenario in terms of design objects and their interactions.  Is a result of transforming the corresponding Analysis Object Interaction Diagram (if it exists).  The driving force behind the transformation is the system architecture.  Not present in UML.

 

Design (Object) Model:   A static structural representation of the software objects (classes) that comprise the system implementation.  Comprised of design objects and their attributes, responsibilities, operations and interrelationships (expressed as association, aggregation and inheritance links).  Focus is on the structure of the software system, as opposed to the structure of the problem domain.  Compare with Analysis (Object) Model.

 

Design Pattern:   In the context of Solution Delivery, an abstraction of some re-occurring programming task.  May be motivated by business needs (see Domain Pattern) or technical needs.  General (abstract) design patterns are customized to a particular programming context in a particular (Object-Oriented) programming language by an application developer.  See Model/View/Controller for an exampe of a technical design pattern.  Contrast with Analysis Pattern, Business Pattern and Domain Pattern.

 

Development environments:   A framework for the organization and development of systems and/or software.  The framework should be based on specific paradigms that leads to an efficient Solution Delivery for the application of interest.  Typical paradigms are (The following isn't intended to be complete, just some that I've been involved with.  For more "intense" coverage see, for example, this link, this link, this document and these diagrams.):

Data oriented – A software development environment that focuses foremost on data entities and the relationships between data entities.  An analyst maps the real world problem domain into data flows and bubbles, where bubbles correspond to events. (Events are those occurrences that happen in the outside world that a planned-response system must respond to.)  Each bubble is named according to what the system does in response to the event. Appropriate input and output flows are added to each bubble.  Data stores are added between bubbles that need to communicate with persistent data.  Group the bubbles "that deal with common data structures" and create successive higher level abstractions, the highest of which shows the entire system in a single bubble. Apply functional decomposition to define lower level abstractions, as needed.  Data dictionaries need to be defined at each level.  One problem with data flow modeling is that "following the flow of data" is not one of the basic methods humans use to manage complexity (abstraction [procedural, data], encapsulation (information hiding), inheritance, organization [objects, attributes, classification structures]). A second is how to pick a reasonable number of bubbles.  A third is to keep the data dictionary tractable.  Since this methodology has a strong functional and interface emphasis, it also suffers from the same resistance to change as does functional decomposition. (data flow modeling = data (& control) flows + data (& control) transformations + data (& control) store + terminators + minispecs + dictionary)

Procedure oriented – A software development environment that focuses foremost on selecting the processing steps and sub-steps (functions and sub-functions). The focus is on what processing is required for the new system, followed by specifying the processing and functional interfaces. Requires the analyst to map from problem space to functions and sub-functions. (The analyst must internalize the subject matter and then produce the corresponding required functions and sub-functions. Because of this, there is no direct map back from the functionality to the subject matter, which makes it difficult to assess whether or not the requirements are an accurate statement of what the system must do.) Additional drawbacks are that (1) processes and functions are the most volatile (often changed) aspects of system development , and (2) external interfaces are the second most volatile. If the system development is based on them (if they are the foundation of all work to follow), changes will propagate throughout the analysis, design and implementation phases. (functional decomp = functions + sub-functions + interfaces)

Object oriented – A software development environment that focuses foremost on encapsulating properties and operations into entities called objects.  The power of object modeling, as opposed to data flow or functional decomposition modeling, is that by focusing on modeling complete abstractions (objects) which encapsulate both function and data, it's possible to use the same basic concepts during all development (e.g. business and domain modeling) phases.  By contrast, one might analyze a problem conventionally in terms of data and then design in terms of function -- e.g. CORBA in a development environment using it's common programming interface (IDL) and common interoperability protocol (IIOP).  Objects are defined by method signatures (object-oriented = objects (abstract encapsulation of attributes and functionality) + classification + inheritance + message communication).  There are three basic OO development approaches:  (1) Scenario-driven: Functional requirements (as Use Cases) are elaborated into Scenarios, which enumerate the assumption and outcome pairs associated with each Use Case.  (2) Data-driven: The data portion of the Object Model is developed first from a pre-existing entity- relationship diagram, database schema, or legacy data structures.  (3) State-driven: The State Models are developed first, usually from pre-existing legacy State Models.

Service oriented – A software development environment that focuses foremost on providing services between system entities.  A service is defined by messages exchanged with other services, and at a higher abstraction level (lowest common denominator) than object-oriented (might have to interface to a procedural language (e.g. COBOL, PL/I), a queuing system (e.g. JMS, MSMQ), and/or an object-oriented system (e.g. J2EE, .NET)).  E.g. SOA development environment based on Web Services -- has a common programming interface (WSDL) and a common interoperability protocol (SOAP).  Is suited for satisfying interoperability across object, procedure, data environments (introduces another level of indirection). 

Agent oriented – A software development environment that focuses foremost on the interaction of autonomous agents with built-in decision making capabilities.  Agents are basically "active" objects (in the OO sense), objects with autonomy, proactiveness, responsiveness, and social behavior.  Agents promote autonomous actions and decision making, often better enabling the peer-to-peer interactions found in business information systems.  JADE is an open source, Java-based Agent-oriented DEvelopment environment.

Logic oriented – A software development environment that focuses on defining logical rules ( predicates) and on using those rules to  navigate / alter complex symbolic structures.  To help in making decisions, Agent-oriented applications may employ Logic-oriented, ontological concepts of beliefs, perceptions, local memory, goals and commitments.  JADE includes the ability to define an ontology (via Prolog) that can include schemas for the types of predicates, agent actions and concepts that are pertinent to the addressed domain.

Aspect oriented – A type of object-oriented software development focusing on aspects of the Real World System that cut across a number of unrelated or loosely-related functions (functions that might even use different programming languages and different programming paradigms).  See for instance "Single Sign-on Access, Authentication, Authorization and Administrative Services" in this Internet / Extranet implementation.

 

Development Patterns:   See Analysis Pattern, Business Pattern, Design Pattern, Domain Pattern.

 

Domain:   A sphere of knowledge.  An architecture.

 

Domain-driven Development Environment:   A development environment based on Business Domain Patterns.  Incorporates Model-driven Development techniques as necessary.

 

Domain (Functional) Architecture:   That part of the solution architecture (see, for example, Architecting Packages) that addresses the following responsibilities:

Business functionality: e.g. business requirements, ROI, ROE, productive lifespan, justification, competitive need and customer satisfaction.

Application organization: e.g. application topologies, software component identification and modularity.

Application software development: e.g. synchronous or asynchronous interactions, industry standard or custom interfaces, tool set determination.

Application management: e.g. application performance, maintenance, cost containment and currency; business forecasting.

Domain (Non-functional, a.k.a. Operational) Architecture:   That part of the solution architecture (see, for example, Architecting Packages) that addresses the following responsibilities:

System organization: e.g. hardware platforms, network segmentation and runtime topologies.

Software and data components placement: e.g. mainframe or server, DMZ or internal

Service requirements: e.g. system performance, availability and security (SLAs).

System management: e.g. capacity planning, software distribution, backup, recovery, maintenance, cost containment and runtime forecasting.

 

Domain Expert:   In the context of model development, a member of the modeling team with deep knowledge of the Real World System being modeled.  Contrast with Analysis Expert and Modeling Expert.  See overview of model-driven design/analysis and contrast with domain-driven design/analysis.

 

Domain Pattern:   A Design Pattern with a business-related motivation (as opposed to a technical one).  Also, an identified Business Pattern generalized toward business domain modeling.  Domain patterns are used in organizing domain models.  A business might identify several business principles in conjunction with a business vision, and these principles (as Domain Patterns) would influence the business domain model.  In a technical sense, these business principles, as Design Patterns, would be used as software constraints by an application developer.  Contrast with Analysis Pattern, Business Pattern and Design Pattern.

 

E-commerce Enabled Environment:   A corporate environment that enables a business to offer products and services to existing and new users (customers, employees, suppliers, partners) across channels based on Internet technologies.  Provides the foundation for managing electronic transactions, and allowing customers to browse public and private information with convenience and confidence that their transactions are secure and their privacy is protected.

 

Engineering:   The analysis, design, construction, operation and maintenance of useful objects or processes for practical purposes.  Engineers use imagination, judgment, and reasoning to apply science, technology, mathematics, and practical experience.

 

Enterprise Architecture:   The types of hardware (e.g. servers, routers, load balancers, firewalls, disk farms), software (e.g. operating systems, middleware, database management systems), network components and network protocols used to build an electronic business.

 

Enterprise Resource Planning:   A business process strategy to integrate major back-office applications.  The most frequently cited benefits of ERP center around process automation and integration, and making data available to support business analysis.   ERP often requires the top-to-bottom transformation of the way a company operates, does business, and plans for the future.  Reference Customer Care Web Initiative.

 

Equipment:   Any electronic hardware utilized for the purpose of aiding a company’s business units or implementation teams in completing their business goals.  Equipment is distinguished from operational tool sets in that equipment includes only original purchase (hardware and software) costs, not ongoing maintenance costs.

 

Evolutionary Production Build Cycles:   Incrementally building toward (convergence to) evolving client requirements.

 

Extended Enterprise:   A business pattern addressing the interactions and collaborations between business processes in separate enterprises.

 

Extended Production Build Cycles:   Incrementally building toward (convergence to) extended client requirements.

 

Extranet:   A market facing marriage of the Internet and an intranet.(=> access to internal data by internal and external personnel + ability to act on it)

 

Functional Implementation and Maintenance Activities & Tasks:   In project planning for a particular application, specific functional domain responsibilities are subdivided into activities which are subdivided again into personal task assignments.  See Solution Delivery Activities.

 

Functional Labor Resources:   Those personnel that work for the implementation team in the capacity of supporting ongoing application technical, interface and content innovation and maintenance, working with both functional tool sets and related application equipment.  The portion of application labor resources that apply to ongoing maintenance of business unit processes may be charged back to business units.  This category includes educational and outside consulting costs.

 

Functional (Business) Model:   Represents, at some modeling level, the processes directly related to the functional requirements of the (business) system.  Contrast with Operational (Business) Model.  See Model for generic modeling characteristics and to contrast various model types.

 

Functional Tool Sets:   That set of utilities (software, documents, organizational structures, etc.) that support application innovation and maintenance by the implementation team.  The portion of functional tool sets that apply to ongoing maintenance of business processes may be charged back to business units.

 

Governance (Corporate):   (1) The executive focus on managing business investments and risk.   (2) A business process established at the executive level, determining who is empowered to make what decisions.

Executive questions to be answered:

(1) What are the projected business need, risk and ROI?

(2) What is the probability that the need will go away, any risk can be avoided / reduced and the ROI can be achieved?

Governance process:

(a) Spend some money.

(b) Receive some results.

(c) Decide next investment increment.

Fundamental process of establishing a governance framework:

(a) Establish process to determine who is empowered to make governance decisions.

(b) Establish mechanisms and policies to manage the way those decisions are implemented.

 

Information Aggregation:   A business pattern that addresses allowing users (customers, employees, suppliers, partners) to access and manipulate data aggregated from multiple sources.  This business pattern captures the process of using tools to extract useful information from large volumes of data, text, images, video, and so on.  These tools may personalize data to suit user preferences, distill summary information from large volumes of data, use algorithms to identify trends hidden in the data, or allow users to ask “what-if” questions.

 

Information Services:   That portion of Information Technology (IT) dealing directly with the operational domain, namely IT planning & Budget Services, IT Technical Services and IT Operations.

 

Interface Design:   That portion of the presentation pertaining to the way customers interact with the application software (e.g. navigation), and the way the application software interacts with the customer (e.g. feedback mechanisms).

 

Internet:   An electronic communications network that connects computer networks and organizational computer facilities around the world (outward facing).

 

Intranet:   A network operating like the Internet, having a Web component, but having access restricted to a limited group of internal authorized users (inward facing). (=> access to internal data by internal personnel + ability to act on it)

 

Java :  (Misc. General Definitions, Notes and Sample Applications -- not intended to be complete)

J2SE – Java 2 Standard Edition, primarily for developing desktop applications. Contains the core Java API.  (e.g. JADE in Agent oriented development can use J2SE)

J2EE – Java 2 Enterprise Edition, primarily for developing server (e.g. Web) applications.  (e.g. JADE in Agent oriented development can use J2EE.)

J2ME – Java 2 Micro Edition, primarily for developing on resource-constrained devices (e.g. cell phones).  (e.g. JADE in Agent oriented development can use J2ME.)

WEB-related Applications:

Applet – A client-side Java-based application that runs within a Web browser.

Servlet – A (Web) server-side Java-based application (via a plug-in) that adds dynamic behavior to an HTML page.  It receives requests from and returns responses to a URL requester.  May be generated from a JSP.  Reference Servlet.

JSP (Java Server Page) – A way to write snippets of servlet code (scriplets) directly within a static HTML page.  Intended to remove HTML generation from servlets.   Reference JSP.  JSTL ( Java Standard Template Library) allows JSP programming using tags, rather than the scriptlet code.

AJAX (Asynchronous JavaScript And XML) – A group of inter-related web development techniques used for creating interactive web applications.  A primary characteristic is the increased responsiveness, interactivity and usability of web pages achieved by exchanging small amounts of data with the server "behind the scenes" (asynchronous) so that entire web pages do not have to be reloaded each time there is a need to fetch data from the server.  AJAX and applets can be used together in the same UIs.  AJAX function calls may be via JavaScript or tag libraries (JSP/JSTL).  Reference AJAX and AJAX tags.

JavaScript – A scripting language most often (but not always) used for client-side web development.  JavaScript is the scripting language in which AJAX function calls are usually made.  Reference JavaScript.  Dojo is a set of JavaScript libraries that provide a simple API to extended features.  One of these features is the ability to make HTTP requests and receive their responses.  Aside from providing AJAX functionality, Dojo also provides packages for string manipulation, DOM manipulation, drag-and-drop support, data structures such as lists, queues, and stacks and abstracts browser differences.  Reference Dojo.  JSON (JavaScript Object Notation) is a Java library that helps convert Java objects into a string representation.  JSON is designed to be used in conjunction with JavaScript code making HTTP requests.  Reference JSON and Using Dojo and JSON to Build AJAX Applications.

JavaFX – A family of software products (framework) for creating rich Internet applications (RIA), web applications that have the features and functionality of traditional desktop applications but also include interactive multimedia applications. The JavaFX products can build applications for desktop, mobile, TV and other platforms. Contrast Adobe Flash and Microsoft Silverlight. (Needs to be installed on the platform before launching the application?)

DWR (Direct Web Remoting) – Framework which helps developers write web sites that include AJAX technology. It allows code in a web browser to use Java functions running on a web server as if those functions were within the browser.

JSTL (JavaServer Pages Standard Tag Library) – A component of the J2EE platform. Extends JSP with XML data processing, conditional execution, loops, internationalization,… tags.

Struts – Older UI development technology. Reference vs JSF.

JSF (Java Server Faces) – Newer UI development technology. A Java EE application-development architecture that makes Web-based user interface development easier (uses a component-based approach instead of Struts MVC request-driven approach). Reference vs Struts.

ICEfaces – An integrated AJAX application framework that enables J2EE application developers to create and deploy thin-client Rich Internet Applications (RIA) in pure Java.

Swing – A lightweight (as opposed to Abstract Window Toolkit (AWT)) API for providing a graphical user interface to Java programs.  Is Model/View/Controller design pattern-based.

Matisse – NetBeans Swing GUI Builder.

NetBeans – A J2EE extension framework that simplifies the development of desktop applications.

RPC –

CRUD –

Business-related Tools:

BPM (Business Process Management) – Methodologies and technologies for automating business operations.

EJB3 (Enterprise Java Beans version 3) – Java component architecture for application development on Java EE servers. Allows the packaging of functionality into reusable components (beans).

Spring Tools – Spring is a Java EE framework that facilitates the mixing and matching of its components to satisfy application requirements. Spring could, for example, do the application Transaction Management and Aspect-oriented Programming (AOP – a part of Spring functionality), but choose to use Spring MVC (a Spring component) or Struts as the MVC framework (or use JSF as the component-based framework). Reference Spring MVC vs Struts vs JSF.

Database Tools:

Persistence – The characteristic of data that outlives the execution of the program that created it.

DAO (Data Access Object) – See Core J2EE Patterns.

JPA (Java Persistence API) – Java framework that allows developers to manage relational data in J2SE and J2EE. Reference JPA.  Several providers (e.g. Hibernate and Toplink (Oracle)).

Hibernate Tools – Provide Object-Relational Mapping (ORM) services for the Java language (maps an object-oriented model into a traditional relational database – manages persistence by allowing storage of POJOs (Plain Old Java Objects) in an SQL database, which are transparent to the database application). Uses runtime reflection to determine the persistent properties of a class. The objects to be persisted are defined in a mapping document (__.hbm.xml), which serves to describe the persistent fields and associations, as well as any subclasses or proxies of the persistent object.

Define session

Define transaction

Define, Collect, save POJOs

Commit transaction

End session

Reference Hibernate, Spring, JSF integration.

Web Services-related tools:

Web Services – XML-based technologies for messaging, service description, discovery and extended features that provides a platform for: pervasive, distributed computing open standards; underlying technology independence; uniform enterprise security, transactions and reliability; composite applications.  Along with Service-oriented Architecture (SOA) and Business Process Management (BPM) makes up a Service-Oriented Enterprise.

JAX-WS – Sun Java API for XML Web Services, on J2EE 1.5 or later.  Supported by MyEclipse.

XFire – Codehaus Java framework for development and consumption of Web Services, on J2EE 1.3 or 1.4. Competed with Axis2. Superseded by Apache CXF, but MyEclipse still (1/09) supports XFire for 1.3 & 1.4 (discontinued starting with MyEclipse 7).

AXIS – Apache XML-based Web Services framework (Axis1 & Axis2).  Not supported by MyEclipse.

Process control tools:

Make – A Unix tool (originally) for automatically building executable programs and libraries from source code (C, C++, Java, …). Has its own declarative programming language.

Ant – An XML-based Apache tool that automates the Java software build process.

Maven – An XML-based Apache tool for Java project management in addition to automating the build process (see Ant). Maven Goals can invoke Ant Tasks.

Unit testing tools:

JUnit – JUnit is a unit testing framework for the Java programming language.

HtmlUnit – HtmlUnit is not a generic unit testing framework. It is specifically a way to simulate a browser for testing purposes and is intended to be used within another testing framework such as JUnit.

JWebUnit – JWebUnit is a Java framework that facilitates creation of acceptance tests for web applications. It evolved from a project that was using HttpUnit and JUnit to create acceptance tests. It wraps existing testing frameworks such as HtmlUnit and Selenium with a unified, simple testing interface to allow you to quickly test the correctness of your web applications. “We are now using HtmlUnit.”

HttpUnit – HttpUnit is an open source software testing framework used to perform testing of web sites without the need for a web browser.  HttpUnit supports HTML form submission, JavaScript, HTTP basic access authentication, automatic page redirection, and cookies. Written in Java, HttpUnit allows Java test code to process returned pages as text, XML DOM, or containers of forms, tables and links. HttpUnit is well suited to be used in combination with JUnit, in order to easily write tests that verify the proper behavior of a web site.

 

Lifecycle Tracking:   In the sense of Information Technology hardware/software development, the monitoring of the viability of a given business product with respect to, among other things, competitors abilities/products, system responsiveness, system presentation and system currency.

 

Marketing:   Ongoing process of planning and executing Product Management, Pricing, Placement (distribution) and Promotopn (advertising).

Product Management – coordinate product planning (internal activities) and product marketing (external activities) to maximize sales revenues and market share.

Pricing – manual/automatic procss of applying prices to purchase/sales orders based on cost/market factors.

Placement (distribution) – broadcasting a product to the next organization down the distribution channel.

Promotion (advetising) – persuation of potential customers to purchase/consume products.

Selling – transfer of products to customers for compensation.

Marketing Research – systematically gathering/recording/analyzing customer/competitor/market information.

Distribution channel – the chain of intermediaries (if any) between the Supplier (Producer) and the customer. May include Retailers, Wholesalers and Distributers.

Supplier (producer) – entity using resources (labor, supplies, plant space) to make things for sale to Customers.

Customer – entities that purchase goods/services generated by Suppliers.

Retailer – sells goods or merchandise from a fixed location in small or individual lots for direct consumption by Customers.

Wholesaler – sells goods or merchandise to Retailers, to industrial, commercial, institutional, or other professional business users, or to other wholesalers and related subordinated services.

Distributer – a middleman between product Suppliers (producers) and Retailer(s).

 

Mathematics Notes (general definitions):   A collection of miscellaneous mathematics notes.

 

Methodology:   A set or system of methods, principles and rules for regulating a given discipline (e.g. OOP (Object Oriented Programming), Structured Programming, Top-down analysis/design, Bottom-up analysis/design).

 

Model:   A model is an abstraction of a Real World System (RWS) -- used to focus attention on the system aspects important to the model being built (related to the reason for creating the model) and not to “reproduce” the system.  A model includes enough information about the RWS entities, processes, events and states to emulate system “reality” and excludes information deemed to be irrelevant.  Model process design requires inductive reasoning (specific => general; from experience & observation to general conclusion; the premises may predict a high probability of the conclusion, but do not ensure that the conclusion is true (see Problem of Induction)) rather than deductive reasoning (general => specific; from laws, rules & widely accepted principles to specific solution; the conclusion is necessitated by, or reached from, previously known facts).  Generally, a model may be physical (e.g. a wind tunnel model) or conceptual (i.e. of the mind).  Conceptual models might be explicit (expressible by a closed-form equation, when it exists, or by a numerical approximation – e.g. a computer simulation) or might be implicit (e.g. expressible by a diagram or text).  Certain analytic models may incorporate both implicit and explicit techniques (e.g. computer-based multi-agent systems where agent actions depend on some form of (rule-based) reasoning).  Contrast Analytical Model, Analysis (Object) Model, Business Model, Business Process Model, Business Requirements Model, Cash Flow Model, Conceptual Model, Customer Model, Data Flow Model, Design (Object) Model, Domain Model, Functional (Business) Model, Functional Decomposition Model, Functional Model, Object-oriented Model, Operational (Business) Model, Performance Model, Resource Model, State Model, Systems (Simulation) Model, Use Case Model, Workflow Model.

 

Model-driven Development Environment / Model-based Design / Domain Model:   As opposed to text(code/pure-mathematical)-based design.  A method of reducing the complexity of systems design by introducing a (graphical, e.g. UML, or graphical/mathematical, e.g. Petri Nets) development environment with hierarchies of pre-defined individual design blocks specific (at some modeling level) to the type of system being developed.  See, for example, Systems Engineering and Vee-Model (a popular systems engineering product development process that purports to improve the systems engineering verification/validation processes).  Also see My History with Modeling, Simulators and Simulations and the referenced overview of model-driven design/analysis for my variation of this process.  In this last overview, three types of experts are shown collaborating during model validation, Domain, Model and Analysis.  This collaboration must center around a basic, common understanding of the problem at hand.  Of up-most importance to this collaboration is an early definition (and use) of domain-specific terms (a glossary/vocabulary).

 

Model/View/Controller:   A (originally) Smalltalk Design Pattern that uses three classes to build and coordinate application interaction interfaces (one to the application logic (Model), one to the presentation logic (View) and one to the input logic (Controller)).

 

Modeling Expert:   In the context of model development, a member of the modeling team with the ability to make understandable abstractions of pertinent domain concepts (analysis of the domain, expressed by Domain Expert(s)).  In that role, the Modeling Expert is also responsible for representing the model abstraction analytically through software.  Contrast with Domain Expert, Analysis Expert and Business Process Modeling.  See overview of model-driven design/analysis.

 

Object Oriented Analysis:   The component of Object Oriented Development that deals with analysis (what to) by decomposing the analysis environment into static and dynamic object-oriented models of domain-meaningful objects.

 

Object Oriented Design:   The component of Object Oriented Development that deals with design (how to) by decomposing the design environment into static and dynamic object-oriented models of domain-meaningful objects.

 

Object Oriented Model:   A real world system abstraction based on the object-oriented development paradigm.  It includes all essential real world system capabilities / properties and excludes details extraneous to the model purpose.  See Model for generic modeling characteristics and to contrast various model types.

 

Ontology:   See Semantic Web.

 

Operational Delivery:   The set of operational methodologies (e.g. Capability Maturity Model (CMM), Rational Unified Process (RUP), International Standards Organization (ISO), Extreme Programming (XP)), processes (e.g. risk identification, testing, implementation), practices (e.g. project management, collaboration, technical) and people (with skills) necessary to deliver the goods and services being sold.  Ultimately, the people and their skills determine the delivery success.  [All methodologies are processes, not all processes are methodologies.]

 

Operational Labor Resources:   Those personnel that work in the capacity of supporting ongoing computer systems-level innovation and maintenance, working with both operational tool sets and equipment.  The portion of operational labor resources that apply to ongoing maintenance of business unit processes may be charged back to business units.  This category includes education and outside consulting costs.

 

Operational (Business) Model:   Represents, at some modeling level, the infrastructure (hardware, software, support) components of an electronic business – from both the operations and applications environments.  Contrast with Functional (Business) Model.  See Model for generic modeling characteristics and to contrast various model types.

 

Operational Support:

 

Operational Tool Sets:   The set of utilities (software, documents, organizational structures, etc.) that support computer equipment systems-level innovation and maintenance.  The portion of operational tool sets that apply to ongoing maintenance of business processes may be charged back to business units.

 

Pervasive Devices:   The collection of electronic devices used for communicating with the World Wide Web.

Telephone:

Hand Held Device:

Pager:

Cell Phone:

Workstation:

Smart Phone:

Laptop:

 

Portfolio Management:   In the sense of Information Technology development, the art of selecting and managing technical projects perceived to be beneficial to the business vision.  See Corporate Governance.

 

Presentation:   That portion of the solution architecture pertaining to visual design (includes aesthetics, interface design and content auditing).

 

Production:   The environment in which a working, documented and tested version of the current release of a product resides.

 

Production Build:   Build and test the production environment.

 

Production Build Cycles:   Incrementally building toward (convergence to) the original long range client objectives.

 

Production Deploy:   Produce a working, documented and tested version of this release of the product in the production environment.

 

Project Brief:   A document addressing the use and value of the development project end product, from the viewpoint of the target audience and from the viewpoint of the proposing department.

 

Project Launch:   Requirements, business context and architectural scoping; exploration of choices; possible prototyping.

 

Project Rating Process:   Negative Value Definitions

Content Management Requirements – The degree to which the project will demand ongoing allocation of web team resources in order to make revisions to the graphic and textual content.

Technical Feasibility Demands – How difficult will it be to implement the project from the standpoint of hardware availability and software acquisition or development?

New Data Requirements – The degree to which this project requires the development of new data rather than drawing it from an established source.

Data Protection Risk – The degree to which the project places existing operational or analytical data at risk for corruption as a result of web-based transactions.

Data Confidentiality Risk – The degree to which this project places confidential customer, financial or other forms of data at risk of being indiscriminately dispersed.

 

Project Rating Process:   Positive Value Definitions

Benefit Effectiveness Measurability – The level of ease with which it could be measured as to whether the project is producing its intended benefit. One should take into consideration such factors as cost, level of measurement effort and likelihood of accurate measurement results.

Productive Lifespan – The length of time the project will endure before it will require major revisions or removal.

Customer Satisfaction Improvement – The degree to which the project will enhance customer satisfaction.

Respects Regulatory Requirements – The degree to which the project will either meet or exceed regulatory agency expectations or regulations.

ROI (Return On Investment) Value – Does the project have a rate of return on investment?  And is it sufficiently substantiated?  See below.

Return on Effort – Is there a balance between the efforts it will take to produce the project with the benefit it will create?

Supports Corporate Strategic Needs – How strongly does the project contribute to the achievement of corporate strategic goals?

Ease Competitive Pressure – The degree to which the project directly addresses a challenge from competitive forces or prepares the company to meet such challenges in the future.

Supports Other I/T – The degree to which this project ties into existing Information Technology (I/T) projects and the degree to which this project establishes a foundation for future I/T projects.

 

Return on Investment (ROI):   Most generally, ROI = results / investment, which implies to increase ROI requires either an increase in results for the same or smaller investment or a decrease in investment for the same or greater result.  Results and investment can be measured by various metrics.  Components to be investigated: (1) Value (income) produced; (2) Expenditures; (3) Timing of expenditures and income.

 

Risk:   The chance (e.g. high, medium, low) of loss (e.g. severe, moderate, nominal) to some entity (e.g. customer, client, operations, business process) or in some portion of a process (e.g. requirements identification, design, implementation).  From a high level, risks identified during business process modeling can be separated into (1) those that come from business vision formalization and business requirements and (2) those that come from the technical implementation of the vision, the requirements and the customer needs.

 

Risk Investigation:   Identify, categorize, mitigate events that may jeopardize one or more of the project’s objectives.

 

Runtime Topology:   The definition of “nodes” to group functional and operational components of an Application Topology.  This is basically an implementation solution to an Application Topology, including firewalls, servers, load balancers, directory and security services, and databases -- without actually naming brands. Runtime Topologies eventually get mapped into specific products (e.g. specific application servers, operating systems, LDAP servers, …).

 

Self Service:   A business pattern that captures the essence of direct interactions between interested parties and a business.  Interested parties include customers, business partners, stakeholders, employees, and all other individuals with whom the business intends to interact.

 

Semantic Web (Ontology, Taxonomy):   Intended to become the next generation of the Internet, where Internet components understand the meanings of words and relationships.  See Semantic Web (for an overview) and Agent Oriented Development (to define an ontology that includes schemas for the types of predicates, agent actions and concepts that are pertinent to the addressed problem domain).  The Semantic Web includes hyperlinks and resource metadata that are based on well-defined concepts, relationships and constraints defined in an underlying vocabulary.

 

Service Level Agreement (SLA):   A formal agreement between technical service providers and technical service requesters.  Usually includes service measurement metrics such as availability, throughput, response time and mean time between failure.  May tie performance to the requirements of a particular business process, with penalties for missing requirements.  Sample SLA.

 

Simulation Analysis Expert:   In the context of simulation model development, a member of the modeling team with deep knowledge of statistics, probability and stochastic analysis.  Responsible for gleaning pertinent information from model simulations and for relaying that information in a meaningful way to other modeling experts.  Contrast with Domain Expert, Modeling Expert and Business Process Analyst.  See overview of model-driven design/analysis.

 

Simulation (Systems) Model:   Reference Notes On Systems Modeling.  See Model for generic modeling characteristics and to contrast various model types.

 

Single Sign-on Access:   The ability of an Internet/intranet/extranet customer to log into a restricted environment once (username:password), and to repeatedly access portions of that environment without again logging in -- for as long as that customer's original login session is active. See, for example, IBM's Tivoli Access Manager.

 

SOE (Service-Oriented Enterprise):   There are two general approaches to using XML and Web Services for integration and interoperability in an SOA-type environment; (1) WSI (Web Services Integration) - tactical and opportunistic and (2) SOI (Service-oriented Integration) - strategic and systematic (ref. Newcomer ³ ).  High level SOE Components:

XML (eXtensible Markup Language) (W3C) – A common, independent data format across the enterprise and beyond that provides: (a) standard types and structures (.dtd, .xsd), independent of any programming language, development environment, or software system; (b) pervasive technology for defining business documents [1] and exchanging business information, including standard vocabularies for many industries; (c) ubiquitous software for handling operations on XML, including parsers, queries and transformations.

WS (Web Services) – XML-based technologies for messaging, service description, discovery, and extended features, providing: (a) pervasive, open standards for distributed computing interface descriptions and document exchange via messages; (b) independence from the underlying execution technology and application platforms; (c) extensibility for enterprise qualities of service such as security, reliability, and transactions; (d) support for composite applications such as business process flows, multi-channel access, and rapid integration.

SOA (Services-Oriented Architecture) – A methodology for achieving application interoperability and reuse of IT assets that features: (a) a strong architectural focus, including governance, processes, modeling and tools; (b) an ideal level of abstraction for aligning business needs and technical capabilities, and creating reusable, coarse-grained business functionality; (c) a deployment infrastructure on which new applications can quickly and easily be built; (d) a reusable library of services for common business and IT functions. Also, a methodology for building IT systems in which business services (requirements, customers, clients, processes…) are the key organizing principals.  Resulting IT systems are ultimately tied to any underlying development environment technology ((CICS, IMS – mainframe), CORBA (OMG), J2EE, and COM/DCOM); may or may not be through WSDL (W3C) and SOAP (W3C) (object, procedure and data oriented development tend to tie the resulting systems directly to the underlying development environment technology).

BPM (Business Process Management) – Methodologies and technologies for automating business operations that: (a) explicitly describe business processes so that they are easier to understand, refine and optimize; (b) make it easier to quickly modify business processes as business requirements change; (c) automate previously manual business processes and enforce business rules; (d) provide real-time information and analysis on business processes for decision makers.  IBM Business Integration Reference.

 

Solution Delivery:   Solution Delivery is a process geared toward the design and implementation of systems, which includes sub-processes (activities and activity tasks).  Solution Delivery is associated with and accomplished within a particular Development Environment.  A solution delivery activity is a state of product development that focuses on making progress on a particular development aspect or facet.  The activities of most interest here are:

Requirements – Solution Delivery activity that defines the purpose of the development, and the conditions or capabilities needed to solve a problem or achieve an objective. Functional business requirements can be gleaned from a Business Case, and functional customer requirements from a Project Brief.  Non-functional (a.k.a. operational) requirements are gleaned from development and delivery platform needs, and performance, reliability, availability, interoperability, persistence, maintainability and cost needs. Usually includes a problem statement. The main work product is a series of use cases prioritized by importance, window of opportunity and technical complexity.

Analysis – Solution Delivery activity that examines the use cases, defined in the functional requirements activity, to gain a better understanding of the problem. The main work product is a series of detailed analysis scenarios and/or diagrams that describe the component parts necessary to accomplish development, and how these component parts interact.

System Design – Solution Delivery activity that maps an analysis into a selected architecture, designing a solution to the problem. Specifically, the main activities involve planning a solution to the functional problem detailed in the analysis, with constraints provided by the non-functional requirements. Application Design, a component of System Design, starts by dividing the application into subsystems and defining the Application Architecture. The main work product is identification of the hardware/ software architecture necessary to support this application -- including runtime, test and development structure, communication, security, component distribution, persistence, information recovery and error handling.

User Interface Design – Solution Delivery activity that describes how users will invoke the functions specified in the requirements and analysis models, and the content necessary to convey the client’s ideas. The main work products are building consistent screen flows and layouts, enforcing required interface standards, and transforming the information intent into a visual design that meets the client’s standards while meeting the corporate content and design guidelines.

Build – Solution Delivery activity that pieces together (builds) the product. This tends to be highly iterative, and generally proceeds in a collaborative environment between multiple disciplines (roles). This mainly involves bringing graphic design, information content and application development (from the UI Design activity) together within the architectures designed in the System Design activity. The main work products are graphical layout, site mapping, code, and user support materials (documentation). The ultimate goal is to produce a testable version of the application.

Test – Solution Delivery activity that checks the build activity work products to determine if they satisfy specific quality criteria. May be subdivided into internal verification (that the problem is being solved correctly) and validation (that the correct problem is being solved). Types of testing include: unit, usability, function, integration, user acceptance, load, stress and performance. The main purpose is to ensure that the application meets the requirements set forth in the requirements activity.

Implement – Soution Delivery activity that creates a working solution of the built and tested System and UI Design activities.

Maintain – Solution Delivery activity that includes error detection and correction, and the addition of enhancements required to adapt the application to a new environment or meet requirements that were not initially specified. Conducted after the solution is delivered to the client. Maintenance is actually a full path through the system development cycle (must have an understanding of the requirements, analysis, system design, user interface design, building, testing and implementation).

 

Special Needs:   Equipment that can be identified for the use only of particular business units or implementation teams may be charged back to those units and/or teams.

 

Supply Chain Management:   A business process that supervises the flow of products and information as they move along a supply chain.  Successful supply-chain management allows an enterprise to anticipate demand and deliver the right item to the right place at the right time, at the lowest possible cost.  SCM aims at improving the efficiency of all the links in the supply chain — thereby providing measurable benefits to the business (e.g. reduced costs, faster cycle times and improved product quality).  Reference Customer Care Web Initiative.

 

Synthetic Reasoning:   With regard to systems modeling and model-driven design, a model may be physical (e.g. a wind tunnel model) or conceptual (i.e. of the mind). Conceptual models might be explicit (expressible by a closed-form equation, when it exists, or by a numerical approximation – e.g. a computer simulation) or might be implicit (e.g. expressible by a diagram or text). Certain analytic models may incorporate both explicit and implicit techniques (e.g. computer-based multi-agent systems where agent actions depend on some form of synthetic (rule-based) reasoning).

 

System:   a collection of objects that interact to accomplish a common goal. The system may incorporate several different system processes .

A system process is a time-ordered sequence of system events directed toward some common end.  A system process coordinates the lives of the process objects.  Examples are: Agile, RAD, RUP, Waterfall, XP.

A system event is a object activity that may change the system state of the system.

The system state is that collection of information necessary to describe the system at any particular time.

 

Systems Analyst/Designer:   As an analyst, knowledgeable and experienced in translating a business requirement into an information technology solution.  As a designer, put mechanisms (e.g. runtime and development structure, communication, security, component distribution, persistence, information recovery and error handling) in place that ensure there is a physical system providing the results specified by the analysis.  See, for example, my Systems Architecture overview and a specific implementation.

 

Systems Architect:   Participate in Business Analyst' meetings as an observer, to better understand the rationale driving the business process. Interact with the Systems Architect to define and refine the next level of details during the analysis phase.  Once the business analysts and the various business specialists have modeled the business processes to the lowest level that the business can define without going into the technical details, jointly review as-is business services to determine whether the services already exist or will need to be built.  The Systems Architect understands the business goals of the system to be developed and has specialized understanding of particular aspects of the business.  The Systems Architect fully understands the current IT architecture and is responsible for mapping new business goals to technical solutions compatible with current IT structure.  The solution architect also understands industry patterns and approaches related to the solution such as SOA and Web Services.  See, for example, my Systems Architecture overview and a specific implementation.

 

Taxonomy:   See Semantic Web.

 

Technical Development:   That portion of the solution architecture pertaining to software development (e.g. database interfaces, error messages).

 

Uncertainty types:

Aleatory – results from variability intrinsic to system behavior.  AKA objective uncertainty.

Analysis technique:  Frequentist probability theory; used by Monte Carlo simulation (models first order uncertainties and discrete event simulations -- which use classical probability theory (e.g. probability distribution functions).

Epistemic – results from gaps in knowledge (stochastically unknown) or a deviation from reality (systemically unknown).  AKA subjective uncertainty.  (Epistemology: the branch of philosophy which is concerned with the nature and scope of knowledge.  According to Plato, knowledge is a subset of the intersection of beliefs and truths.)  Relativist epistemology centers on the belief that knowledge is relative to cuture and history.

Analysis technique:  Generally incorrect to represent epistemic uncertainty with probability density functions -- use Bayesian probability theory (subdivided into Objective and Subjective Bayesian inference).  See Bayes' Theorem and Bayesian probability.  Typical epistemic knowledge unknowns in the design and risk worlds: requirements, environment, future design decisions, emergent attributes.

Both types of uncertainty are present in design and risk assessment.  Schedule risk is predominately epistemic.  Software quality risk can be either epistemic or aleatory.  Frequentist and Bayesian interpretations disagree about the ways in which probabilities should be assigned in applications.  Frequentists assign probabilities to random events according to their frequencies of occurrence or to subsets of populations as proportions of the whole, while Bayesians describe probabilities in terms of beliefs and degrees of uncertainty.  The articles on Bayesian probability and frequentist probability discuss these debates in greater detail.

 

Unified Modeling Language (UML):   The attempt by Rumbaugh, Jacobson and Booch (e.g. ref. "The Unified Modeling Language Reference Manuel, Second Edition") at formalizing a language to "...specify, visualize, construct and document the artifacts of a software system.".  UML relies heavily on several diagram types to communicate system component attributes and relationships -- the most popular diagram types being activity, interaction, use case, object/class and package.  Diagram components (shapes, icons, key words, line styles, multiplicity, constraint types, ...) are rigorously defined so that UML-knowledgeable people viewing these diagrams operate from a common dictionary of terms.  There is a level, however, at which diagrams (UML or otherwise) loose their worth (become too time consuming to maintain and interpret) -- and that level generally occurs when the detail necessary to convey an idea diagrammatically surpasses the syntactic capability of the diagram components.  The ultimate, detailed description of a software system lies in the software code itself; in the end, actual code interpretation (and the occasional in-line, up-to-date comment) must be relied on to "...specify, visualize, construct and document" the artifacts of a software system.

 

Use Case Model:   Captures functional requirements and consists of a set of actors (external agents -- human or other systems), use cases (representing usages of the system by the actors or usages of the actors by the system -- externally visible system behavior that defines the functional system requirements), and links between the actors and the use cases.  Not concerned with permutations of assumptions.  Use Case Models drive the analysis phase, and Analysis Scenarios are derived from Use Cases.

 

Vocabulary:   A shared language between domains that expresses the information necessary for communication.  A thesaurus is a detailed vocabulary that is part of an ontology , and as such operates in conjunction with concepts such as syntax (usage rules), semantics (word meanings) and taxonomy (word classifications).  XML vocabularies may be complex (as in a thesaurus) or simple (as in just expressing the correct XML syntax).  In the spirit of the Semantic Web, XML vocabularies should be accessible by both humans (e.g. via HTML through XSLT) and applications (e.g. directly  by databases or indirectly through XML parsers).

 

Web = World Wide Web (WWW):   A part of the Internet designed to allow easy, unrestricted navigation of the network through use of hypertext links between different addresses and graphical user interfaces.  Also see intranet, extranet.

 

Work Products:   The outcome of an activity task.  May or may not be a deliverable.

 

XMI (XML Metadata Interchange):   A standard adopted by the OMG (Object Management Group) for representing objects in XML (XML is not object-oriented).  This standard facilitates the transfer of information between UML applications and the creation of XML schemas from UML models.

 

XML (eXtensible Markup Language):   (1) XML is a universally accepted, interpreted, tag-based computer language used for representing data on the World Wide Web.  A collection of properly syntaxed XML statements (elements) is called an XML document.  XML documents can be manipulated so that the information they contain can be readily presented to humans (e.g. as HTML on the WWW) and/or can be digested by computer applications (e.g. by database management systems).  This manipulation is generally done by one or more XSLT scripts, contained in XSL (XSD) files and written in XML.  (2) In a particular domain, XML is often used to build a domain vocabulary.  OWL, Web Ontology Language, written in XML, is also often used (see Semantic Web).  (3) XML is the basic language used by many UML applications for representing domain systems.  (4) XMI provides a standard for representing modeled objects in XML.  (5) XML is an important component of an SOE.  See XML Usage.

 

XML schema:   A file that describes the "type" of another XLM file.  "Type" is typically expressed in terms of constraints on the structure and content of the other file.  XSL (XML Schema Language, from W3C, written in XML, also called XSD) and DTD (Document Type Definition, written in its own language) files are kinds of XML schemas.  CSS (Cascading Style Sheets) are to HTML as XML schemas are to XML.  CSS and XML schemas can together operate on XML files.  XML schemas can be a part of a domain's vocabularly.  XSLTs  (XML Schema Language Transformation) are XSLs written to transform XML files from one vocabulary to another.   See XML Usage.

 

XSLT (eXtensible Stylesheet Language: Transformations) Script:   A script, written in XML, that directs how a given XML document will be transformed.  Created by coordinating two XML schemas in an XSLT editor.  Then, using a properly created XSLT file, a transformation processor and a XML file that has been validated against the "from" XML schema, an XML file consistent with the "to" XML schema can be created.  See XML Usage.