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 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 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 Campaign and Advert Database Access Campaign Advert Campaign Forecasting Development Management Each sub-system Contains some core functionality Changes to data in one Sub-system need to be propogated 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 inall 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