Domain Analysis

System Analysis

System Specification

System Modeling

Project Discussion and Exercise

Reference materials and recommended readings

Assignment and Required Readings
 
 

Domain Analysis

What is an enterprise system domain?

• A collection of current and future enterprise system (software) applications that share a set of common characteristics.
• A well-defined set of characteristics that accurately, narrowly, and completely describe a family of problems for which enterprise application system solutions are being, and will be sought.
• Example: open information sharing systems is a domain of enterprise systems
• Another example: open global file sharing systems is a domain of enterprise systems

• Identify opportunities for creating or recognizing reusable system requirements, specifications, designs, implementations, test plans, and user documentation.
• Characterize a family of related application systems that conform to a common solution framework for a well-defined problem domain.
• Example: Napster, Gnutella, FreeNet and Scour Exchange are each a global file sharing application system, where the application centers about Internet-based sharing of music, multi-media (e.g., music video) or other files.

Figure 1. (SADT^tm) Model of Domain Analysis (after Arango and Prieto-Diaz, 1989)

What do we model when conducting a domain analysis?

• Common and variable properties (components, dependencies, error conditions, etc.) of an enterprise system in the domain
• Semantics of the system properties
• also known as a conceptual system model
• an configuration of system entities/objects, components, user roles, control schemes, etc. that constitute the system data model
• Dependencies or links (i.e., relations) between system properties that establish the conceptual model, workflow (data flow), and business process flow (control flow)
• A vocabulary or lexicon (i.e., a data dictionary) that identifies common objects, attributes, values, relations, constraints or computational processes that collectively constitute a language for the domain
• Also called a domain-specific language
• Generic and taxonomic classification of the elements and dependencies that bound the scope of application systems within the domain.
• Sometimes called a system meta-model (a model of models, or a model of a family of interrelated models)
• Examples and counter-examples of application systems that are respectively in and not in the domain
• Napster, Gnutella, FreeNet, Scour Exchange and Free Haven are application systems in the domain of global file sharing systems
• The World Wide Web is not in the domain of global file sharing systems. However to many users, it is a global file system that provides access to files on (de)centrally managed Web servers.
• Reusable requirements: requirements that account for system features found in members of the system's product family

At least three choices:

• When it is possible to formalize the domain model into system components that can be automatically configured and specialized to generate an enterprise application system directly from its specification.
• This is a business decision, since a domain analysis is never exhaustively complete, just resource limited!.
• Domains tend to evolve more slowly than the enterprise systems that support them.

System Analysis

Moving from System Requirements to System Specification

• Use Cases and Rich Pictures identify many system elements and dependencies
• Use Cases help identify user-system interactions, transactions or processes
• Rich Pictures help identify different roles people play, their concerns, overall process flow dependencies, and scope of overall problem domain.
• Overall, system analysis serves as the bridge between the requirements of the problem domain and the (architectural) design of a solution.

Fundamental assumption

• System analysis focuses on what the enterprise system is suppose to do, not how the system should be implemented.
• System specification captures the "what"
• System design captures the "how"
• System specification and modeling represents the solution to the problems described by the system's requirements!

What do system specifications specify?

• Specifications require identification of:
• enterprise system components,
• user-system interfaces (and associated input devices),
• display or navigation screens, data entry forms, printed reports
• user processes for interacting with the system,
• information processes performed within the information system (technology),
• both user activities (e.g., storing, sharing and retrieving business model assets) and computational services (e.g., "file serving") may provide inter-firm service offerings, intra-firm capabilities, or core competencies
• user inputs and system outputs,
• outputs may be information resources, artifacts, or products for enterprise use
• internal system inputs and outputs between system components,
• process control guidance or decision-making constraints,
• human roles or automated system components that enables processing steps,
• error conditions, error handling/signaling
• erroneous user input
• erroneous system output
• erroneous internal system inputs/outputs
• boundary values or anomalous values in inputs or outputs that require special handling
• patterns that configure and bundle inputs, actions/function steps, outputs into workflows (flow of data objects) and processes (flow of control according to business rules).
• Specified elements and dependencies need to be organized as abstractions:
• Hierarchical abstraction:
• Top-level: the Big picture of the system
• Middle-levels: sub-systems (a configured collection of components or internal sub-systems), sub-sub-systems, etc.
• Lowest-level: where system/software mechanisms operate
• Two kinds of hierarchical system abstractions of interest:
• Generic: from most general (domain-independent) to most specific (domain-specific)
• Taxonomic: from whole to part
• Each is orthogonal to the other
• Generic and domain-specific component abstraction:
• Components are to be parts of the implemented information system
• Components have interfaces through which inputs and outputs pass
• User-system interface
• Sub-system to sub-system interface
• Component to component
• Taxonomic classification:
• System to sub-system, sub-system to sub-sub-system, etc. to component.
• How the parts compose the whole; how the whole is decomposed into parts

• Enterprise system meta-model and lexicon (data dictionary) for the focal problem domain
• People/User Roles: as identified in the Enterprise System Requirements
• Processes and Workflows
• Processes denote an ordered set of activities (sub-processes) or actions ("process steps") that collectively realize an enterprise business function, strategy, or workflow
• Processes have inputs, outputs
• Processes transform inputs into outputs via functional computations or interactive operations
• Each such transformation denotes the activity or action of the process
• Processes consume, use, or produce objects, artifacts, products or other resources
• People roles enact/perform processes using system components that consume inputs and use other resources to create outputs.
• Workflows denote the physical (e.g., via email) or logical (e.g., via navigational access to a new Web page) transport of enterprise work objects/artifacts between people roles, or between people and system components
• People in certain roles may be able to delegate processes or workflows to other people or system components
• Control, guidance or decision-making constraints for Processes (or process actions) or Workflow (data objects, artifacts or products flowing between people roles and/or system components.
• Business or application data exchange protocols
• Business processes
• Business rules
• System development techniques (e.g., following the Unified Software Process from Rational Inc. for developing UML-based system specifications)
• Other concerns/issues associated with people roles in the Requirements
• These constraints tend to appear primarily at the higher or top-most levels of system description or abstraction.
• Inputs
• Objects (entities) or data containers (e.g., text files; mp3 files; video stream; database; directory)
• Objects are abstractions of entities in the problem domain, representing one or more occurrences of some entity.
• Examples:
• Enterprise system structure: a configuration of interdependent (linked) information system entities
• Other systems (opaque to the enterprise, except through an external system interface): the Web; customer's ordering system; logistics carrier package tracking system.
• Devices and sensors: computer-attached entities that can capture (or "sense") events (e.g., mouse clicks; Web page hits; ATM transactions) and transform them into data values
• Information records: your DMV driver's license; your bank-provided VISA credit card account; data containers whose attribute value set denotes a "state" or "status" (your tuition payment and GSM course ID registration indicated that you are "enrolled" in GSM207 during Fall 2001).
• Objects may be used to represent resources, inputs, outputs, products, or sometimes services required, used, or provided by an enterprise information system
• Objects are also encapsulations of attributes (the object's properties) and services on those attributes
• Objects have attributes (e.g., ObjectId; length; format; data encoding)
• Attributes have values (e.g., ObjectId=notes.html; length=64Kbytes; format=HTML; data encoding follows W3C HTML standard)
• Values have ranges (good data values vs. erroneous data values)
• Boundary values (e.g., maximum/minimum value for good data) and anomalous values (attribute values requiring special handling)
• An attribute instance represent the value of a datum.
• Services are computational functions or methods that are invoked in response to a "message" (e.g., a request (data entry submission) to update to an object's attribute value).
• Service invocation may subsquently create, update or delete other object attribute values
• Objects also used to denote data classes, categories, or abstract data types
• Objects are defined/modeled with a schema/template.
• Objects may also denote information artifacts (e.g., enterprise data model; bar chart; UML design diagram; data entry record)
• May be contained within a single object (data type)
• May incorporate and compose multiple objects (complex data type)
• Other object types
• Documents (e.g., formatted in HTML, XML, PDF or .DOC)
• MIME objects ("registered" objects types associated with specific application programs -- .mp3 objects require an "mp3" player application)
• Temporal and Spatial identifiers (e.g., timestamps; Global Positioning System coordinates; URL addresses)
• Namespaces and Universal (Unique) Resource Identifiers (e.g., Telephone numbers, Internet Domain Names)
• Etc.
• Outputs
• Similar to the kinds of objects as Inputs (but their instances are not the same).
• Reports (for printing), Displays (for browsing or reading), and Forms (for subsequent data entry).
• Objects or artifacts that include data specifying how to layout and present according to an implicit/explicit style guide or data exchange standard.
• Application invocation commands -- system generated commands that start/launch another application or plug-in component corresponding to associated output types (e.g., when you download a PDF document type through a Web browser, this triggers an automatic command to start the Adobe PDF document reader program).
• Relations: Objects types whose services affect or enable a dependency within (for relational/ER data models) or between (for Semantic Nets) related objects' attributes
• Also called tuples (rhymes with "couples") in the realm of relational/ER data models for database management systems.
• Relations have degree: number of associated attributes
• Relations have cardinality--number of data instances (e.g., zero or more, one, one or more, more than one, etc.) per tuple or per attribute
• Certain kinds of relations are common:
• Decomposition/Composition: e.g., Part-whole (Part_of; is_part_of:)
• Assembly/Disassembly: Compositions where ordering of related objects is important
• Ordering may be spatial, temporal, geographic, subject to some other explicit constraint
• The object model for people, strategy, technology, and the enterprise systems can each be modeled via decomposition or composition
• Precedence (logical): denotes the ordering of a set of process activities, actions, or workflows.
• sequential (before; between; after);
• concurrent (during);
• iterative (while_true_do; do_until_<expr> "false");
• selection (if loginID="OK" then Allow-Read-Only-Access else Return-to-Login-screen)
• Precedence relations are useful when specifying object data flow (workflow) or business process logic (process control flow)
• Containment/Membership: e.g., Has_members; is_member_of; contains; is_contained_by.
• Examples:
• a file system contains directories/folders;
• a folder contains files;
• directory=http://www.ics.uci.edu/~wscacchi/SA/ contains file=index.html;
• KnownErrorTypes := {user-input-error, system-input-error, system-computation-error, system-output-error, data-transmission-error, data-display-error, data-reporting-error, hardware-fault-error, other-anomaly}
• Inheritance (and Delegation): e.g., Is_a (e.g., daughter is_a girl, girl is_a woman); Is_assigned_to (for delegation)
• Used for automatically creating instances of an generic object type (i.e., the object's attributes and attribute values) for further specialization
• Example: You have "inherited" biological attributes from your father and mother, and from their fathers and mothers, but your attribute values are different from those of your siblings and cousins.
• Inheritance is a kind of copy-then-update method, which is employed as a reuse (or reusable objects) technique
• Inheritance may be one-to-one (single inheritance; used in Java) or many-to-one (multiple inheritance)
• Inheritance is also known as (aka) extension.
• Automatic usage is generally limited to ONLY object-oriented or semantic net system implementations
• Inheritance offers an economy of representation for enterprise systems that primarily manage composite object data sets
• Counter-example: files in a directory/folder do not automatically inherit the attributes or attribute values of other files in the same or higher-level directory
• "Delegation" is a variant of inheritance that hands offs a copy/instance of an object to another user role/automated system component only under command (i.e., not automatically)
• The object that delegates (the "delegator") is a proxy for those that are delegated.
• Generally speaking, relations are often specified by simple declarative name (e.g., has_parts; is_part_of; contains) whose computational function or method remains unspecified until detailed design time.
• Remember, in Use Cases, relations are used to denote system activities (verb)
• System components (coarse-grain): e.g., a database management system; a Web server; a Web browser; an electronic billing and payment system; a corporate accounting system.
• System components refer to information technology, not people!

• All system specification models require some sort of data dictionary, lexicon, or meta-model that identifies and defines (provides a model schema)
• people (roles): e.g., an enterprise organizational chart or roles, skills, or process assignments,
• business strategies and rules,
• information technology components
• and how they are interrelated into an enterprise system configuration.
• each of these requires a separate model
• Entity-Relation (ER) Data Modeling
• Entities are essentially objects
• ER can be viewed as object-based, but NOT object-oriented!
• Entities have attributes, attributes have values, values have instances, etc., as in System Specifications
• ER data models sometimes also called ERA (entity-relation-attribute) or OAR (object-attribute-relation).
• ER data models are sometimes confused with Semantic Network/Net data models (which is a somewhat misleading use of this type of data model--Semantic Nets denote a Web of object/entity types that are interlinked with relation types)
• Entity data sets are often represented as tables,
• the table (relational) schema defines its application data model (or application meta-data) as a collection of entity attributes (and their primitive data types, e.g., string, integer, real, timestamp, currency, etc.)
• table columns denote the entity's attributes,
• table rows denote the entity's instances.
• ER data sets (e.g., a relational database) generally have a flat structure and many instances of each entity
• In contrast, OO data sets (e.g., an object-oriented database) generally has few instances for each object
• object-oriented data sets are often represented as hierarchies and instances
• the object schema (aka, class) defines its application data model (or application meta-data) as a collection of object attributes (and their primitive data types, e.g., string, integer, real, timestamp, currency, etc.)
• lower-level objects (aka, sub-classes; specializations) in an OO hierarchy inherit attributes of higher-level (aka, classes; super-classes; generalizations) objects,
• higher-level attributes do not need to be restated at lower levels
• OO data sets generally have complex hierarchical structure and few instances.
• ER data models are visualized using ER Diagrams (example, though many more examples can be found on the Web via Search)
• Entities visualized with a rectangular box
• Entity attributes are visualized as elliptic shapes linked to one entity
• Relations visualized with a diamond (rhombus shape) that is linked between two or more entity boxes
• Head and tail of a relation link usea variety of graphic arrowheads to denote the relations cardinality.
• Alternatively, cardinality may be informally displayed using some parenthetical expression (1,1; 1-M; N-M) near each end of the relation
• ER models used primarily for enterprise systems built around a relational database management system
• Object-Oriented (OO) Modeling
• ER models supporting inheritance!
• OO models are usually modeled as object hierarchies
• Processes, workflow and messages are usually hidden within object methods
• OO models can be visualized using the Unified Modeling Language (UML--developed by Rational Inc.)
• Component-Based Modeling
• ER models supporting components as system entities

• Assignment #3: Develop a system specification as an electronic document (e.g., as an MS Word .doc or .htm file) for the Open Global File Sharing System you analyzed and developed as a Rich Picture in Assignment #2.
• Data dictionary (a narrative glossary of terms, at this time)
• People roles (organize roles as named objects in a hierarchical abstraction)
• Major processes or workflows (organize processes/workflows as named objects in a hierarchical abstraction)
• Inputs and Outputs (a list for each)
• Major relations (as a list, where each relation describes which inputs, processes, outputs, roles or system components are linked)
• Major system components (organize components as named objects in a hierarchical abstraction)

• Find via Web search or select a Recommended Course book that describes ER data modeling
• Find via Web search or select a Recommended Course book that describes OO modeling using UML+XML

Required Readings

• A comprehensive description for object-oriented system analysis can be found here
• Understanding System Architecture a white paper from TRCInc.(no longer posted on their Web site)