Moving from Analysis to
Design
Overview
● What is the difference between analysis and design?
● Logical v. physical design
● System v. detailed design
● System Architecture
● Characteristics of a good design
● Data management issues
● Development standards
The Difference between Analysis and
Design
• Analysis involves finding out what happens in the current
system and what is required in the new system
– understanding, investigating and modelling requirements
• Design is concerned with specifying how the new system
will satisfy the requirements determined during analysis
– “how the system will be constructed without actually
building it” (Rumbaugh 1997)
– the aim is to produce the best possible solution that
satisfies the requirements
Logical and Physical Design
• Design is sometimes divided into two stages:
• logical or implementation-independent design
– concerned with those aspects of the system that can be designed
without knowledge of the implementation language and platform
 the interaction between objects
 layout of data entry screens, as well as the order in which they will
appear
 commands and data to be sent/received from hardware or other
systems
• physical or implementation-dependent design
– concerned with those aspects of the system that are dependent on
knowing which implementation language and platform will be used
 the use of middleware to allow objects to communicate across
different machines
 choice of Java AWT, Java Swing for designing interface
System Design
● System design is concerned with:
– the overall architecture of the system
● the structure of sub-systems, their distribution on processors,
and communication between sub-systems
– the setting of standards
● interface design (screen layouts, report layouts)
– job design
● how people's work will change and what training they may
require
● Detailed design is concerned with:
– Objects and classes
– Details of interface
– Details of interaction
System Architecture
● Defining the system architecture is a major part of system design
– High level view that determines overall structure, the relationship
among its major components and their interactions
– Classes are grouped together in packages
● Architectural decisions determine the degree to which the system will
meet its non-functional objectives
– getting the architecture right reduces the risks involved in the
project
● Involves understanding the client's business and how that business
can best be supported by an information system
– Often drives decision of which architecture to adopt
Rational Unified Process 4 + 1 Views
● Development processes based on the Rational Unified Process are
architecture-centric
– use case view
 important use cases and scenarios that describe architecturally
significant behaviour
 this view ties the remaining four views together
– logical view
 important design classes and interfaces in a package structure
– implementation view
 sub-systems and components and relationships among them
– process view
 a description of the processes and interprocess communications
– deployment view
 physical nodes, components deployed on the nodes and the
communication channels between them
Sub-systems
● Sub-dividing an information system into sub-systems
has the following advantages
– produces smaller units of development
– helps to maximise reuse at the component level
– helps the developers to cope with complexity
– improves maintainability and portability
● Each sub-system should have a clearly specified
boundary and fully-defined interfaces with other subsystems
Sub-system Communication
Layering and Partitioning
● There are two general approaches for dividing a software
system into sub-systems
– layering -> sub-systems usually represent different
levels of abstraction
– partitioning -> each sub-system focusses upon a
different aspect of functionality
● Both approaches may be used together on one system
Layered architectures may be either open or
closed
• closed layered
– layer N can only use the services of layer N-1
– minimises the dependencies between layers
– reduces the impact of a change to the interface of any one layer
• open layered
– layer N may use the services of any layers that lie below it
– produces more compact code
– breaks the encapsulation of the layers
– increases the dependencies between layers
A Simple Layered Architecture
Example of Layered Architecture
Partitioned Sub-systems
Model-View-Controller (MVC) Architecture
● The MVC architecture separates an application into three
types of component
– models: the main functionality
– views: present the user interface
– controllers: manage the updates to views
● Advantages
– supports different interface styles
– aids maintainability and portability
– Provides multiple interfaces for the same core
functionality
Difficulties to be Resolved
•
•
•
•
The same information must be presented in different formats in different
windows
Changes in one view should be reflected immediately in other views
Changes in the user interface should be easy to make
Core functionality should be independent of the interface
– enables multiple interface styles to co-exist
Each sub-system
Contains some core
functionality
Changes to data in one
Sub-system need to be
propogated to the others
Campaign
Advert
Campaign
Forecasting Development Management
Campaign and Advert Database Access
Model-View-Controller : Key Components
● Model
– provides the central functionality of the application and is aware of each of
its dependent view and controller components
● View
– a view corresponds to a particular style and format
– retrieves data from the model and updates its presentation when data has
been changed in any of the other views
– creates its associated controller
● Controller
– accepts user input which triggers execution of operations within the model
– these may cause changes to the information which in turn trigger updates
in all the views
● Propagation Mechanism
– enables the model to inform each view that the model data has been
changed and that the view must update itself
MVC Example
MVC Component Interaction Example
Architecture for Distributed Systems
Concurrency
● In OO modelling concurrency is captured through the
development of interaction diagrams and statecharts (as
well as use cases)
● Objects that operate concurrently must be implemented on
different logical processors
● Logical concurrency
– multi-tasking operating systems (Unix and Windows XP)
– multi-threaded programming languages (Java)
● Physical concurrency
– multi-processor environment
Criteria for Good Analysis
• Correct scope
– the scope of the system should be clearly understood and
everything in the analysis model should fall within the scope of the
system
• Completeness
– everything that is within the scope of the system should be
documented in the analysis models
• Correct content
– the analysis documentation should be correct
• Consistency
– each element is consistently referred to by the same name
Good Design Objectives
• Functional
– performs the functions that it is claimed to perform
• Efficient
– performs required functions efficiently in terms of time and
resources
• Economical
– the fixed costs and running costs should be economical
• Reliable
– the system should not be prone to hardware or software failure and
should maintain the integrity of data
• Secure
– against unauthorised use and malicious attacks
• Flexible
– should be able to adapt to changing business requirements
Good Design Objectives
• General
– the system should be general-purpose and portable
• Buildable
– the design should be clear so that developers may implement it
• Manageable
– it should be easy for a project manager to estimate the amount of
work required and to check progress
• Maintainable
– a well-designed and documented system is easier to maintain
• Usable
– using the system should be both a satisfying and productive
experience
• Reusable
– elements of the system may be reused
Prioritising Design Trade-offs
• Some design objectives may conflict with others
– functionality, reliability and security could conflict with
economy
• Conflicts also arise from constraints imposed on the
system by the users' requirements
– e.g. budget, timescale, staff-skills, integrating the new
system with existing hardware or systems
• To resolve conflicts, compromises or trade-offs are
required during design
– the reason for any compromise or trade-off should be
clearly documented
Further Design Guidelines
● Design clarity
● Don't over-design
● Control inheritance hierarchies
● Keep messages and operations simple
● Design volatility
● Evaluate by scenario
● Design by delegation
● Keep classes separate
Data Management Issues
• File storage versus DataBase Management Systems
(DBMS)?
• DBMS offers support for
– different views of the data, control of multi-user access,
distribution of the data over different platforms,
security, enforcement of integrity constraints, access to
data by various applications, data recovery, portability
across platforms, data access via query languages and
query optimisation
– relational, OO, object-relational
• See later lectures
Development Standards
• HCI guidelines
• Input/output device guidelines
– try to use a standard form of interface with devices
• (Also see later lectures)
• Construction guidelines
– advice on naming classes, operations and attributes
– the use of particular software features
– layout of the code
• Guidelines for design trade-offs
System Design Activities - Summary
• Identify sub-systems and major components
(architecture)
• Identify any inherent concurrency
• Allocate sub-systems to processors
• Select a data management strategy
• Choose strategy and standards for human-computer
interaction
• Specify code development standards
• Plan the control aspects of the application
• Produce test plans
• Set priorities for design trade-offs
• Identify implementation requirements
Descargar

Moving from Analysis to Design