Enterprise System Analysis:
Specification and Modeling
Walt Scacchi, M271 and F271
Spring 2003
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
Why analyze an enterprise system
domain?
- 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.
What is domain analysis?
The activity of
understanding, abstracting, and modeling a bounded problem domain, the
people (roles) involved, and its enterprise context(s).
Figure 1. (SADTtm) 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
When is a domain analysis complete?
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
System Specification
- 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!
System Modeling
- 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
Project Discussion and Exercise
- 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)
Reference materials and
recommended readings
- 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