Body

R Body

Mann Creek Software

System Development Definitions and Descriptions

I. System Development Methodologies.
		A. System: A collection of objects that interact to accomplish a common goal.  An object is any
			 real or abstract thing about which we store information (data) and the means to manipulate that
			 data.  A system may incorporate several different processes. A process is a time-ordered
			 sequence of events (or sub-processes of events) that describe the lives of objects. An event is
			 a object activity that may change the state of the system.  A system's state is that collection of
			 information (data) necessary to completely describe the system at any particular time.
		B. Development:	A process geared toward the design and implementation of systems, which
			 includes sub-processes (phases).  A development phase is a state of product development that
			 focuses on making progress on a particular development aspect or facet.  The eight phases of
			 most interest to software developers are⁽¹⁾:

			
			1. Requirements Gathering: Development phase that defines the purpose of the
					 development, the conditions or capabilities needed to solve a problem or achieve an
					 objective.  The main activities are to group requirements into use cases and prioritize by
					 importance, window of opportunity and technical complexity.  There are two major kinds
					 of requirements:

1. User requirements: Drives analysis. Expressed by use cases.
2. Nonfunctional requirements: Drives design. Typical examples are:
a. Development platform: hardware, software, etc. -- drives implementation.
b. Delivery platform: hardware, software, etc. -- drives interface specifications
and implementation activities.
c. Performance: clarify space, time, etc. customer resource constraints
d. Reliability: drives "delivery vehicles" selection.
e. Availability: drives implementation activities.
f. Interoperability:
g. Persistence:
h. Maintainability:
i. Cost:
Phase may include some or all of the following work products:
a. Problem statement (E): Describes the business requirements of the development
(short description of the business problem that the development should solve).
b. Use case model (E): 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 (see analysis scenarios). Drives the
analysis phase. Analysis scenarios are derived from this.
c. Nonfunctional requirements (E): Collection of system requirements that are not
directly related to what the system should do (response time, security, availability,
data consistency, data integrity, ...). Must be known before design.
d. Prioritized requirements (O): Defines the relative importance (from customers
and/or users view) of the system requirements.
e. Business case (E): Justification for undertaking the development, from a business
perspective (e.g. revenue, productivity, complete org. mission statement, ...).
f. Acceptance plan (O): Description of sequence of steps by which the customer
will verify that the developed system does indeed satisfy its requirements.
2. Project Management: The main activities are to allocate requirements to releases and/or
increments and plan activities that manage resource availability and other project
constraints. May include some or all of the following work products:
a. Intended development process (O): Documents the broad outlines of the
development process that is to be used for the project. Might include things
such as (ref. pp131,132 Developing Object-Oriented Software: An
Experience-Based Approach):
i. Follow the techniques outlined in a particular reference.
ii. Use a combination of a waterfall and an iterative and incremental process.
iii. Use conventional estimation techniques to provide initial sizing estimates.
iv. State specific release cycle schedules.
v. State specific increment phase schedules.
vi. State any presence of depth-first development approaches.
b. Project workbook outline (E): Needed to find agreement among the
development team members about the set of work products to be created for the
project. It is also needed to establish a commitment from the development team
to record each of the identified work products in a project workbook.
c. Resource plan (E): Identify all the resources that will be required during the life
of a project for its successful completion.
d. Schedule (E): Produced to understand the work completed and the work needed
to be completed for the project. Used to plan and measure project progress.
e. Release plan (O for single release projects, E for multiple release): Sets up the
scope of the project and divides the work into manageable units.
f. Quality assurance plan (O at this stage, included with each work product):
Involves:
i. Establishing quality goals, defining success criteria and expected results..
ii. Validation and tracking.
iii. Removing defects.
iv. Addressing global quality aspects.
g. Risk management plan (O, E for innovative projects): Identifies risk associated
with a project and suggests plans to manage them. Risks may be eliminated,
reduced, possibly controlled, and if not controllable a contingency plan
developed.
h. Reuse plan (O except when spelled out in the requirements plan): Development
of reusable parts has to be justified, planned, and tracked separately from the
rest of the project. There are two major items effected by reuse: (1) the business
case and (2) the project plan.
i. Test plan (E): Ensures that testing is complete, feasible, and successful, and that
adequate resources for testing are identified and planned for. Ensures that the
testing strategy is agreed to in advance.
j. Metrics (O): Measurements of essential elements of the development project that
enable successful planning and tracking of projects. Metrics fall into the
following categories:
i. Size
ii. Productivity
iii. Quality
iv. Reuse
k. Project dependencies (O): Items that the project requires for successful
completion.
l. Issues (E): Identify areas of disagreement or uncertainty that require clarification.
All resolved issues should be recorded.
3. Analysis: Development phase that explores the problem domain (as defined in the
requirements specification) to gain a better understanding of the problem. The main
activities are to develop solutions to scenarios (use cases => analysis scenarios drive the
analysis phase) in terms of active objects that group related tasks and communicate with
other objects in order to complete them (identification and division of responsibilities
among objects). May include some or all of the following work products:
a. Analysis guidelines (O but I): Set of guidelines intended to document the way in
which analysis is to be performed. May be divided into work product guidelines
and process guidelines.
b. Subject areas (O in small/medium, E in large): Identification of distinct domains
of interest, recognizable parts of the problem domain that can be analyzed as
separate units. May or may not become subsystems at design time. Tend to be
clusters of analysis classes that are closely related by inheritance (is-a),
aggregation (has-a) or other (uses) associations.
c. Analysis object model (AE): Fundamental way to document static aspects of
objects in problem domain. 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 OIDs to focus
on how objects interact.
d. Analysis scenarios (AE): An elaboration of a use case (use case + initial
conditions [assumptions] + outcomes). A reflection of the system requirements.
Drives the analysis phase. Used to develop object interaction diagrams.
e. Analysis object interaction diagrams (E): 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 analysis scenarios
(the system requirements). The focus is on protocol (how objects interact), including
event flows or message passing between objects. OMT = event trace diag.
UML = sequence diag.
f: Class-Responsibility-Collaboration cards (O): A technique for responsibility analysis.
For each class create a CRC card that includes the class name, lists class
responsibilities, and lists the collaborators needed to fulfill each responsibility. May use
the card back to describe the class definitions and other specifications (transcribed
later to the model dictionary). During the CRC exercise, individuals may assume the
identity of objects and be called upon to interact with other objects to fulfill a particular
responsibility. The focus is on why a class has to interact with other classes. CRC
analysis results in:
i. Better defined object services
ii. Refined attributes
iii. Verified and refined classes and their relationships
iv. Discovery of new classes
Difficult to use for large problem domains. Still need to distinguish between the
responsibilities of the class and the responsibilities of a class instance.
g. Analysis state models (O, E in real-time domains): Describes the life cycle of a
class or class instance, by giving an overview of how an object reacts to external
events.
h. Analysis class descriptions (O): Summaries of all information known about a
class at the analysis level (similar to CRC cards).
4. User Interface Model: Describes how users will invoke the functions specified as part of
the analysis model. The analysis model assumes external users can communicate directly
with the problem domain objects to invoke their services and concentrates on the
object-oriented semantics of the services themselves. The user interface model assumes
that the detailed semantics of the services are specified (and managed) elsewhere, and it
focuses on simplifying the communication required to invoke them. The main activities
are to document how users will interact with the application. May include some or all of the
following work products:
a. User interface guidelines (O but I if critical to acceptance): Consists of a set of
guidelines to assist developers in constructing work products related to user
interfaces. Might refer to required standards. May require or suggest a
particular GUI-builder.
b. Screen flows (O but I): Needed to design user interfaces that match the intended
user's conceptual model of the domain and to ensure efficient user interaction
with the software. Interacts with the use cases by detailing how the information
flows from the user to the system, and visa versa, for each functional
transaction.
c. Screen layouts (O but I): Depict the actual appearance of screens (windows,
dialogs, prompts, etc.) that the users will see during the operation of the system.
Usually does not include exception conditions. Show the actual text, labels, and
icons intended for that screen as well as detailed spatial arrangement of text,
icons, and controls.
d. User interface prototype (O but I): A small application program which models
the look, feel, and sequencing of the intended application's user interface. The
point is to invest in validating the application's visual behavior while avoiding as
much as possible the other facets of the application.
5. Design: Development phase that maps an analysis into a selected architecture to create a (software)
solution to the problem. Mapping can be difficult if the analysis and design phases don't use the same
underlying methodology (a "semantic gap" is created). The main activities involve the planning of a
solution to the problem examined during analysis in terms of interacting objects, within the constraints
specified by the nonfunctional requirements (nonfunctional requirements drive the design phase).
Responsibilities take a more detailed form than in analysis, indicating method names, parameter types,
data flow, etc. for all participating objects. Can be subdivided into System Design (the design of a
high-level architecture for a proposed solution) and Application (Object) Design. System Design starts
with the System Architecture (defines the major system building blocks and subsystems, and their
high-level connectivity -- reflecting system (subsystem) functions as opposed to hardware or software
products) and includes the following steps (see ref. 2):
i. Determine the application, support, and services subsystems and their relationships (the
requirements for defining subsystems are that they should have clearly defined functions, be
fairly independent, and have well defined interfaces).
ii. Allocate the subsystems to different resources (e.g. network nodes / processors -- influenced by
nonfunctional requirements).
iii. Determine how data is managed (influences subsystem design and placement).
iv. Define priorities and trade-offs between desirable characteristics.

SYSTEM DESIGN
Design Detail Level System Architecture Application Architecture
conceptual design from use case model, object model, dynamic model from use case model, object model, dynamic model
logical design subsystem decomposition subsystem decomposition
physical design system platforms / infrastructure system platforms / infrastructure

Application Design divides the application into subsystems (a tightly coupled collection of classes) and
defines the Application Architecture (see ref. 2). The Application Architecture can be partitioned
(vertically) by functionality (i.e. roles and responsibilities) and layered (horizontally) by services provided
(e.g.. model/view/data). Design may include some or all of the following work products:
a. Design guidelines (O): A set of rules intended to define the design deliverables
and to guide the design process. May be divided into work product guidelines
and process guidelines.
b. System architecture (E): The set of global, project wide design decisions (can be
broad or narrow). May include the following areas of interest:
i. structure (the way in which the software is to be layered or partitioned)
ii. communication patterns between structure components
iii. communications (e.g. interprocess)
iv. component distribution
v. persistence
vi. security
vii. error handling
viii. recovery
ix. debugging
x. use / reuse of existing or specific hardware / software
c. Application program interfaces (O): Documents an internal or external API
provided by the system. Is defined to enable the system or subsystem to be used
without the need to understand all its internal details.
d. Target environment (E): Should specify hardware platform(s), operating
system(s) and runtime environment [(s) in distributed or client/server system].
Ensures that the architect and end user share a common understanding of the
operating environment.
e. Subsystem model (O in small/medium, E in large): A partitioning of a system
into subsystems and a delegation of system responsibilities to the subsystems.
Subsystems may be nested. Logical and/or physical models.
f. Design object model (AE): A static structural representation of the software
objects (classes) that comprise the system implementation. Comprised of design
object classes 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 (see analysis object model).
g. Design scenarios (E): Similar to analysis scenarios, except they refer to design
objects in describing their behavior, assumptions and outcomes, and they include
information about how to trigger the scenario. May define system or subsystem
behavior. Specifies a design object interaction diagram (OID) (states formally
what a OID must do).
h. Design object interaction diagrams (E, major activity of design phase): 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 OMT or UML.
i. Design Class-Responsibility-Collaboration cards (O): Starting with analysis CRC cards,
create additional cards for new classes designed (generally interface and service
classes). Assign responsibilities and reallocate responsibilities. Evenly distribute
responsibilities among objects. Conduct new CRC exercises. May indicate required
attributes, actions and events (public interface) for each class.
j. Design state models (O): A representation of the dynamic object behaviors for
the design classes. Only represents classes with strong state-dependent object
behavior, use design OIDs otherwise.
k. Design class descriptions (E): Containers of all the information known about a
class at the design level. Provides the starting point for class implementations.
l. Rejected design alternatives (O): A listing of design decisions considered but
rejected.
6. Implementation: Development phase that creates a working solution to a problem, from
the design. The main activities involve systematically coding the classes specified as a
result of design in a programming language according to documented public/private
interfaces so that they can be built and installed on the target platforms. Implementer
should follow traceability of functional requirements from Use Cases into Design
Scenarios and Design Object Interaction Diagrams, the results being organized into
classes that are described by the Design Object Model and the Design Class Descriptions.
May include some or all of the following work products:
a. Coding guidelines (E): A set of documented rules and recommendations
addressing the programming style to be used within the development project.
Typical topics covered include:
i. File naming conventions
ii. File structure
iii. Fiile and function prologues (e.g. security and copyright)
iv. Identifier naming conventions
v. Global names
vi. Class/structure layout
vii. Initialization
viii. Use of types within a language
ix. Calling conventions and return types
x. Cohesion, encapsulation, binding
xi. Memory management
x. Exception and error handling
xi. Use of language specific features
xii. Terseness of expressions
xiii. Performance
xiv. Portability
xv. Formatting
b. Physical packaging plan (O): Contains decisions about the physical structure of
the product deliverables (e.g. executables, source code, dynamic link libraries,
etc.).
c. Development environment (O): A minimum environment contains tools to edit,
compile or interpret, run, and debug source code. It should span all phases of
development without requiring us to enter the same data more than once (even
if multiple tools are used).
d. Source code (E): The actual implementation of the application design in a
programming language. There may be several different types of code files.
e. User support materials (E): Customer documentation. Typical customer tasks
to be covered include:
i. Evaluation
ii. Planning
iii. Installation
iv. Administration
v. Operation
vi. Customization
vii. Application programming
viii. Diagnosis
ix. End use
f. Database schema (O):
7. Testing: Development phase that checks work products to determine whether they satisfy
specific quality criteria. May be divided into internal verification (ensuring that the
problem is being solved correctly) and validation (ensuring that the correct problem is
being solved) against other work products or specifications. The main activities involve
insuring that the application meets the requirements set forth in the problem statement
and requirements. Includes the following work product:
Test cases (E): May perform one or more of the following during one or more
development increments:
i. Function test:
ii. Integration test:
iii. User acceptance test:
iv. Stress test:
v. Performance test:
vi. System test:
8. Maintenance: Development phase that includes error detection and correction and the
addition of enhancements requires to adapt it to a new environment or meet requirements
that were not initially specified. Conducted after the solution is delivered to the
customer. Is actually a full path through the system development cycle (must have an
understanding of the requirements analysis, design, implementation, test and
maintenance).

C. Methodology: A formal framework for modeling a system from its requirements to its
deployment and maintenance. Common methodologies for accomplishing system development
are:
1. Functional decomposition: Consists of selecting the processing steps and sub-steps
(functions and sub-functions) anticipated. 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)
2. Data flow (structured) modeling: 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)
3. Information modeling: The strategy is to find objects in the real world and describe them
with attributes. Add relationships between the objects. Refine the model with
supertype/sub-types and associative objects. Sometimes takes the form of an
entity-relationship diagram. Information modeling is missing the following concepts:
i. services (object functionality)
ii. inheritance
iii. messaging (object interface)
iv. structure (object classification and assembly)
(information modeling = objects + attributes + relationships + supertype/subtype +
associative objects)
4. Object-oriented modeling: 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 is possible to use the same basic
concepts during all development phases. By contrast, one might analyze a problem
conventionally in terms of data and then design in terms of function.
(object-oriented = objects (abstract encapsulation of attributes and functionality) +
classification + inheritance + message communication)
i. Scenario-driven approach: Functional requirements (as Use Cases) are
elaborated into Scenarios, which enumerate the assumption and outcome
pairs associated with each Use Case. Each Scenario is elaborated into an
Object Interaction Diagram, which distributes the system functions to the
objects by assigning class responsibilities and identifying object
collaborations. The classes and their OID-implied attributes, associations,
and operations are organized by class and transferred to an Object Model.
When a sufficient amount of class behavior varies due to an object's state, the
operation sequences identified in the OIDs referring to that class are collected
and reorganized into a State Model.

							ii.    Data-driven approach: The data portion of the Object Model is developed first
									 from a pre-existing entity-relationship diagram, database schema, or legacy
									 data structures.  The normal Scenario-driven approach is used to identify Use
									 Cases, Scenarios, Object Interaction Diagrams, and State Models.  The
									 Object Model acts like a design constraint, and is updated from the OID with
									 the assignment of operations and possibly new attributes and associations that
									 became evident during the dynamic modeling.

							iii.  State-driven approach: The State Models are developed first, usually from
									 pre-existing legacy State Models.  Some attributes, transition operations and
									 relationships may be obtained this way.  Transfer State Models to the Object
									 Model.  Use the Data-driven variation to identify Use Cases, Scenarios, and
									 Object Interaction Diagrams.  The State Model acts like a design constraint
									 when developing the OIDs.  Finally, the Object Model is updated with the
									 additional classes (attributes, relations, operations) that become evident
									 during the dynamic modeling.

ref. ⁽³⁾

Procedural Abstraction

Data Abstraction

Encapsulation

Classification/Inheritance

Organization Methods

Behavior Categories

Functional Decomposition

Data Flow Modeling

Information Modeling-Data

(y)

Object-oriented Modeling

II. Iterative and Incremental Development: A process model for software development in which the
project is divided into a sequence of increments. During each increment a combination of
incremental by requirements development and iterative rework is performed. Each increment is
principally driven by the end-user requirements that define that increment, but a certain portion of the
increment is set aside for iterative rework of existing work products to take reviews, tests,
experience, and other feedback into account. Each increment results in executable system code.

Components Requirements
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10
A A1 A2
B B2 B5 B7 B9
C C1 C3 C6 C8 C10
D D3 D4
E E2 E5 E6 E9
F F4 F7 F10
G G1 G6 G8
H H5 H9
I I4 I7 I9
J J6 J8 J10 Ref: (1)

When planning the increments it will not be possible to anticipate which particular parts of the
design will require rework, but a certain portion of each increment should nevertheless be set aside
to anticipate the inevitable fact that rework of some kind will be necessary (to correct errors,
increase performance, increase modularity, increase extensibility, ....). Some issues may not arrise
until reviews or tests.

III. Distributed Systems
A. Types of distributed systems (ref. 3):
1. Distributed operating system: Applications run on top of a distributed operating system, seeing a collection of services and
resources to use without concern for where they exist.
Advantages: Dealing with distribution done by operating system, not application
Disadvantages: Requires node operating systems to be homogeneous.
Examples:
2, Network operating system: Nodes run an independent operating systems, each providing a network interface that
applications use to communicate with other nodes.
Advantages: Independent operating system environment.
Disadvantages
Examples: IBM Customer Information Control System (CICS) product family.
3. Distributed file systems: Each node mounts file systems from other nodes at boot or as requested.
Advantages: Node has access to remote files.
Disadvantages: Each application has to find node where file resides.
Examples: Sun's Network File System (NFS), OSF's Distributed Computing Environment (DCE).
4. Distributed programming language: The programming language is responsible for dealing with distribution. May access
remote resources directly or may try to make make the network transparent (see distributed operating system).
Advantages: Language can be implemented on different operating systems.
Disadvantages: Complex to design such a language.
Examples: HP's Distributed Smalltalk, IBM's Distributed Smalltalk, IBM's VisualAge Distributed Feature
5. Distributed programming toolkit: Provide a library that aids in writing distributed applications. Higher level of abstraction
than network operating system, lower than distributed programming language.
Advantages:
Disadvantages:
Examples: IBM's Distributed System Object Model (DSOM), OSF's Distributed Computing Environment (DCE), Sun's
Network Computing System (NCS).
B. How to divide classes for distribution(ref. 3):
1. From requirements specification.
2. From use cases.
3. From object model.
4. From dynamic model.
5. From system design.
6. From persistent object design.

R Hoffman, mann creek software, reh@manncreek.com, last updated 9/98.