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 sub-systems

Sub-system Communication

Layering and Partitioning

● There are two general approaches for dividing a softwaresystem 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 threetypes 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

Campaign and Advert Database Access

Campaign Advert CampaignForecasting Development Management

Each sub-systemContains some corefunctionality

Changes to data in oneSub-system need to bepropogated to the others

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