Unitiii Partial

SA_UNIT III _Partial II
Integration in Software Development

Environments
 Software development has different requirements from database
processing. As compared to databases. software development involves
more different types of data, fewer instances of each distinct type, and
slower query rates. The units of information are larger, more complex,
and less discrete than in traditional databases.

Environments
 The earliest software development tools were standalone programs. Often
their output appeared only on paper and perhaps in the form of object code
on cards or paper tape.
 New tools incorporated prior knowledge of related tools, and the usefulness of
shared information became more evident. Scripts grew up to invoke tools in
fixed orders. These scripts essentially defined batch sequential architectures.

Environments
 The ways that tools could interact with a shared repository.

 Tight coupling: Share detailed knowledge of the common, but
proprietary, representation among the tools of a single vendor
 Open representation: Publish the representation so that tools can
be developed by many sources. Often these tools can manipulate
the data, but they are in a poor position to change the
representation for their own needs.
 Conversion boxes: Provide filters that import or export the data in
foreign representations. The tools usually lose the benefits of
incremental use of the repository.
 No contact: Prevent a tool from using the repository, either
explicitly, through excess complexity, or through frequent changes.
Integration in Building Design
 A project generally involves a number of independent,

geographically dispersed companies.
 The diversity of expertise and dispersion of the industry inhibit
communication and limit the scope of responsibilities.
 Each new project creates a new coalition, so there is little
accumulated shared experience and no special advantage for pair
wise compatibility between companies.
 However, the subtasks interact in complex, sometimes non-obvious
ways, and coordination among specialties (global process expertise)
is itself a specialty.
Integration in Building Design
 Integration includes,
 construction community operates on divide-and-conquer problem
solving with interactions among the sub problems.
 a large number of tasks in facility development depend on judgment,
experience, and rules of thumb accumulated by experts in the domain
 involving standalone programs and batchsequential compositions
 toward integration focused on support-supervisory systems, which
provided basic services such as data management and information flow
control to individual independent applications
 Integrated environments for building design are frameworks
◦ efficient in managing problem-solving and information xchange
◦ flexible in dealing with changes to tools
◦ graceful in reacting to changes in information and problem solving
strategies
Architectural Structures for Shared
Information Systems
 Current software tools, treat all modules equally, and they mostly
assume that modules interact only via procedure calls and perhaps
shared variables.
 By providing only a single model of component, they tend to blind
designers to useful distinctions among modules.
 The architectural descriptions focus on design issues such as the gross
structure of the system, the kinds of parts from which it is composed,
and the kinds of interactions that take place.
 The use of well-known patterns leads to a kind of reuse of design
templates.
 These templates capture intuitions that are a common part of our
folklore: it is now common practice to draw box-and-line diagrams that
depict the architecture of a system, but no uniform meaning is yet
associated with these diagrams.
Architectural Structures for Shared
Information Systems
Design Rules (Guidance) for User Interface
Systems
Stronger requirements for user interface adaptability across
devices favour higher levels of application interface abstraction, so
as to decouple the application from user interface details that may
change across devices. If the requirement is for global behaviour or
application semantics changes, then parameterized abstract devices
are also favoured.
High user customizability requirements favor external notations
for user interface behavior. Implicit and internal notations are
usually more difficult to access and more closely coupled to
application logic than are external notations.
Design Rules (Guidance) for User Interface
Systems
A high requirement for application portability across user
interface styles favours the higher levels of application interface
abstraction. Less obviously, it favours event-based or pure state-
based communication over the hybrid forms
If the maximum command execution time is short, a single thread
of control is practical and is favored as the simplest solution.
If external events must be handled, it is often worthwhile to
provide separate control thread(s) for this purpose. Separate
threads serve to decouple event handling logic from user interface
logic.

Unitiii Partial

Uploaded by

Copyright:

Available Formats

Unitiii Partial

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unitiii Partial

Uploaded by

Copyright:

Available Formats

SA_UNIT III _Partial II

Integration in Software Development

 Software development has different requirements from database

processing. As compared to databases. software development involves

and less discrete than in traditional databases.

 The earliest software development tools were standalone programs. Often

on cards or paper tape.

shared information became more evident. Scripts grew up to invoke tools in

fixed orders. These scripts essentially defined batch sequential architectures.

 The ways that tools could interact with a shared repository.

 A project generally involves a number of independent,

You might also like