Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Architectural and Object Oriented Design

VIEWS: 61 PAGES: 36

									ARCHITECTURAL
   DESIGN
        Why is Architecture Important?
   Representations of software architecture are an
    enabler for communication between all parties
    (stakeholders) interested in the development of a
    computer-based system.
   The architecture highlights early design decisions
    that will have a profound impact on all software
    engineering work that follows and, as important,
    on the ultimate success of the system as an
    operational entity.
   Architecture “constitutes a relatively small,
    intellectually graspable model of how the system
    is structured and how its components work
    together” [BAS03].
  Architectural design represents the structure of
  data and program components that are required
  to build a computer based system.

   Architecture is not the operational software.
   Rather it is a representation that enables a
   software engineer to
(1)analyze the effectiveness of the design in
   meeting its stated requirements
(2)Consider architectural alternatives at a stage
   when making design changes is still relatively
   easy
(3)Reducing the risks associated with the
   construction of the software.
      Representations of software architecture are an
enabler for communication between all parties
interested in the development of a computer based
system.

      The architecture highlights early design
decisions that will have a profound impact on all
software engineering work that follows, and as
important on the ultimate success of the system as an
operational entity.

       Architecture constitutes a relatively small,
intellectually graspable model of how the system is
structured and how its components work together.
                      Data Design
       Like other software engineering activities, data
design creates a model of data and/or information
that is represented at a high level of abstraction. This
data model is then refined into progressively more
implementation specific representations that can be
processed by the computer based program.

      The structure of data has always been an
important part of software design. At the program
component level, the design of data structures and
the associated algorithms required to manipulate
them is essential to the creation of high-quality
applications. The data design activity translates the
elements of the requirements model into data
structures at the software component level.
                       Data Design

   At the architectural level …
    • Design of one or more databases to
      support the application architecture
    • Design of methods for „mining‟ the content
      of multiple databases
         navigate through existing databases in an
          attempt to extract appropriate business-level
          information
         Design of a data warehouse—a large,
          independent database that has access to the
          data that are stored in databases that serve
          the set of applications required by a business
      Data design at the component level focuses on
the representation of data structures that are directly
accessed by one or more software components. A
set of principles can be applied for data design.
      1. Systematic analysis principles applied to
function and behavior should also be applied to data.

     2. All data structures and the operations to be
performed on each should be identified.

     3. Data dictionary should be established and
used to define both data and program design.
     4. Low level design processes should be
deferred until late in the design process.

     5. Representations of data structure should be
known only to those modules that must make direct
use of the data contained within in the data structure.

     6. A library of useful data structures and
operations should be developed.

      7. A software design and its implementation
language should support the specification and
realization of abstract data types.
               Architectural Styles

     The software that is built for computer-based
systems exhibits one of the many architectural styles.
Each style encompasses

      1. a set of components, that perform a function
required by the system
      2. a set of connectors that enable
communication, coordination and cooperation among
components
      3. constrains that define how components can
be integrated to form the system
      4. semantic models that enable a designer to
understand the overall properties of a system
       Architectural Styles

   Data-centered architectures
   Data flow architectures
   Call and return architectures
   Object-oriented architectures
   Layered architectures
         Data-Centered Architecture




     A data store resides at the centre of this and is
accessed by other components that update, add,
delete, modify within the store.
             Data Flow Architecture




      This is applied when input data are to be
transformed through a series of computational or
manipulative components into output data.
              Data Flow Architecture

       A pipe and filter pattern has a set of
components called filters, connected by pipes that
transmit data from one component to the next. Each
filter works independently of those components
upstream and downstream, is designed to expect
data input of a certain form and produces data output
of a specified form. However, the filter does not
require knowledge of the working of its neighboring
filters.

      If the data flow degenerates into a single line of
transforms, it is termed batch sequential. This
accepts a batch of data and then applies a series of
sequential components to transform it.
      Call and Return Architecture




     This style enables a software designer to
achieve a program structure that is relatively easy to
modify and scale
     Mini program/subprogram architectures.
     Remote procedure call architectures.
           Layered Architecture




     A number of different layers are defined, each
accomplishing operations that progressively become
closer to the machine instruction set.
     Object oriented architecture
     The components of a system encapsulate data
and the operations that must be applied to
manipulate the data. Communication and
coordination between components is accomplished
via message passing.
                     MAPPING

      Software requirements can be mapped to
various requirements. The transition from information
flow to program structure is accomplished as a part
of six-step process.
Establish type of information flow
Flow boundaries indicated
DFD is mapped into program structure
Control hierarchy defined
Resultant structure refined using design measures
and heuristics
Architectural description refined and elaborated
      Two type of information flow are transform flow
and transaction flow.

      In transform flow externalized data must be
converted in to an internal form for processing.
Information enters the system along paths that
transform external data into an internal form and the
paths are identified as incoming flow. Data moving
along the paths after transformation are called
outgoing flow. Overall data flow occurs in a
sequential manner.
      In transaction flow, information flow is often
characterized by a single data item, called
transaction, that triggers other data flow along one of
many paths.
              TRANSFORM MAPPING

      It is a set of design steps that allows a DFD with
transform flow characteristics to be mapped into a
specific architectural style.

Review fundamental system model
Review and refine data flow diagrams for the
software
Determine whether the DFD has transform or
transaction characteristics
Isolate the transform center by specifying incoming

and outgoing flow boundaries

Perform first level factoring

Perform second level factoring

Refine the first iteration architecture using design

heuristics for improved software quality
    Transform Mapping
             b                             g            h
         a                  e    f
                      d
             c                             i
                                                    j
                      data flow model

                 x1                                "Transform" mapping
    x2           x3                   x4

b        c   d        e     f     g            i

    a                            h             j
                  Factoring
direction of increasing
decision making                    typical "decision
                                   making" modules




                          typical "worker" modules
First Level Factoring
               main
             program
             controller




  input      processing    output
controller   controller   controller
        Second Level Mapping
                                              main
               D
                       C
                                    control
                            A
                   B
                                A
                                              B
                                C


           mapping from the           D
        flow boundary outward




     Second level factoring is accomplished by
mapping individual transforms of DFD into
appropriate modules within the architecture
               TRANSACTION MAPPING
Review fundamental system model

Review and refine data flow diagrams for the software

Determine whether the DFD has transform or
transaction characteristics

Identify the transaction center and flow characteristics
along each action path
Map the DFD to a program structure amenable to
transaction processing
Factor and refine the transaction structure and the
structure of each action path
Refine the first iteration architecture using design
heuristics for improved software quality
OBJECT ORIENTED
    DESIGN
   Object oriented design transforms the analysis
    model created using object-oriented analysis in
    to a design model that serves as a blueprint for
    software construction
   An object-oriented system draws upon class
    definitions that are derived from the analysis
    model
   OOD is divided into two major activities
    • System Design
    • Object Design
      System design defines the product
architecture (the system functions and classes
encapsulated in the subsystems). System design
focuses on the specification of three components:
the user interface, data management functions,
and task management facilities.

      Object design focuses on the internal details
of the individual classes and the messaging
scheme. The design specification document form
the SEPA web site is applicable to OOD. The OOD
projects must be reviewed to ensure quality.
        Design for Object-oriented System




The conventional Pyramid concept is introduced for
OOD, which contains four layers
     Responsibilities layer (highest layer - contains
data structure detail and algorithmic detail for each
object's attributes and operations)

      Message layer (establishes the internal and
external interfaces for the system, including the
details of communication among object collaborators)

      Class and object layer (contains class hierarchy
including representations of each object)

     Subsystem layer (lowest level - contains
representations of each of the subsystems and the
necessary infrastructure that enable the software to
achieve the customer's requirements)
             Object-oriented Design Issues

      Decomposability - facility of design method that allows
the designer to decompose the problem into easily solved
subproblems
      Composability - degree to which design method
ensures that modules constructed for one project can be
reused in another
      Understandability - ease with which a component can
be understood without examining other components

     Continuity - ability to isolate changes made in one
module and restrict the propagation of changes to other
modules

     Protection - architectural characteristic that reduces the
propagation of side effects when errors occur
     Object-Oriented System Design Process

Partition the analysis model into subsystems.
       Subsystems should have well defined communication
interfaces with few exceptions classes should collaborate
within their subsystem
       Keep number of subsystems small partition
subsystem internally to reduce complexity

Identify concurrency dictated by the problem.
Allocate subsystems to processors and tasks
       Allocate each subsystem to an independent
processor (or) allocate subsystems to same processor and
provide concurrency support through operating system
features
Develop user interface design
Choose basic strategy for implementing data management
      Management of data critical to the application itself
creation of infrastructure for storage and retrieval of objects


Identify global resources and control mechanisms to access
them

Design control mechanism for system (including task
management)

Consider how subsystem boundary conditions should be
handled

Review and consider trade-offs
                      The Object Design

Object descriptions
      protocol description - object interface specified by
defining each message an object can receive and the
operation triggered by message (or)
      implementation description - shows implementation
details for each operation implied a message passed to the
object

Designing algorithms and data structures
      algorithm categories: data manipulation,
computation, monitors
refinement of operation programs defined during OOA

Design optimization
                   The Object Design

       Review object-relationship model to ensure
implemented design leads to efficient resource
utilization, add redundancy where necessary
revise attribute data structures and related operation
algorithms to improve processing efficiency
create attributes to save derived information and avoid
re-computation

     Modularity is important aspect of object-oriented
design quality (the program design language should
support object definition)
             Describing Design Pattern

Design Pattern Specification Components

•Name
•Intent
•Design forces motivating the pattern
•Solution that mitigates these design forces
•Classes required to implement the solution
•Responsibilities and collaborations among the
solution classes
•Implementation suggestions
•Source code examples or templates
•Cross-references to related design patterns

								
To top