Enterprise System Analysis: Specification and Modeling

advertisement
Enterprise System Analysis: Specification and Modeling
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 or multi-media (e.g., music video) files.
What is domain analysis?
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 (i.e., relations) or links 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
 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
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)
When is a domain analysis complete?
 This is a business decision, since a domain analysis is never exhaustively complete.
 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.
Specifications require identification of:
 enterprise system components,
 user-system interfaces,
 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 or products for enterprise use
 internal system inputs and outputs between system components,
 process control guidance or decision-making constraints,
 human roles or automated mechanisms 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 into 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 for the focal problem domain
 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.
 Inputs
 Objects (entities) or data containers (e.g., text files; mp3 files; video stream;
database; directory)
 Objects have attributes (e.g., length; format; data encoding)
 Attributes have values (e.g., length is 64Kbytes; format is ASCII; data
encoding follows MPEG3 standard)
 Values have ranges (good data values vs. erroneous data values)
 Boundary and anomalous values
 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 (formatted in HTML, PDF or .DOC)
 MIME objects ("registered" objects types that are associated with specific
application programs -- .mp3 objects require an "mp3" player application)
 Temporal and Spatial identifiers (e.g., timestamps; GPS coordinates; URL
addresses)
 Namespaces and Universal (Unique) Resource Identifiers
 Etc.
 Outputs
 Includes same types as Inputs
 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
 User Roles
 Control, guidance or decision-making constraints
 Business or application data exchange protocols
 Business processes
 Business rules
System Modeling
 Entity-Relation (ER) Data Modeling
 Object-Oriented (OO) Modeling
 Component-Based Modeling
Project Discussion and Exercise
Reference materials and recommended readings
Assignment and Required Readings
Download