System Analysis & Design

Phases of Software Development

• System conception: Software development begins with business
analysis or users conceiving an application and formulating tentative
requirements. Outcome of this phase is problem statement.
• Analysis: The analysis model is a concise, precise abstraction of what
the desired system must do, not how it will be done.
• The analysis model has two parts:
• Domain Model: a description of real world objects reflected within the
system.
• Application Model- a description of parts of the application system itself that
are visible to the user.
Phases of Software Development
• System Design: It gives a high-level strategy. The system designer
should decide what performance characteristics to optimize, chose a
strategy of attacking the problem, and make tentative resource
allocations.
• Class Design: The class designer adds details to the analysis model in
accordance with the system design strategy. His focus is the data
structures and algorithms needed to implement each class.
• Implementation: Implementers translate the classes and relationships
developed during class design into a particular programming
language, database or hardware.
Phases of Software Development
• Testing: Ensures that system is suitable for actual use and it satisfies
all requirements.
• Training: Train the end users to master the new system.
• Deployment: Replace the old system with new system.
• Maintenance: new bugs found should be fixed. New functionality may
be added.
Analysis
• Domain Analysis
• Static structure of the real world system
• Domain class model
• Domain State Model
• Application Analysis
Domain Class Model: Steps to construct this
model
• Find classes
• Prepare a data dictionary
• Find associations
• Find attributes of objects and links
• Organize and simplify classes using inheritance
• Verify that access paths exist for likely queries
• Iterate and refine the model
• Reconsider level of abstractions
• Group classes into packages
Domain State Model: steps to construct
• Identify domain classes with states
• Find states
• Find events
• Build state diagram
• Evaluate state diagram
Application Analysis

• Application Interaction Model

• Application class model
Application Interaction Model
• Determine the system boundary
• Find actors
• Find use cases
• Find initial and final events
• Prepare normal scenarios
• Add variation and exception scenarios
• Find external events
• Prepare activity diagrams for complex use cases
• Organize actors and use cases
• Check against the domain class model
Application state model
• The application state model focuses on application classes
• Augments the domain state model
• Application State Model- steps
• 1. Determine Application Classes with States
• 2. Find events
• 3. Build state diagrams
• 4. Check against other state diagrams
• 5. Check against the class model
• 6. Check against the interaction model
System Design
• focus is on decisions about how the problem will be solved
• First at high level – Then with more detail
• Estimate system performance - To determine if the system is feasible - To
make simplifying assumptions
• ATM Example
• Suppose – The bank has 40 branches, also 40 terminals.
– On a busy day half the terminals are busy at once.
– Each customer takes one minute to perform a session.
– A peak requirement of about 40 transactions a minute.
– storage – Count the number of customers.
– Estimate the amount of data for each customer
Estimate system performance
• To determine if the system is feasible
• To make simplifying assumptions
• ATM Example
Suppose – The bank has 40 branches, also 40 terminals.
– On a busy day half the terminals are busy at once.
– Each customer takes one minute to perform a session.
– A peak requirement of about 40 transactions a minute.
– storage – Count the number of customers.
– Estimate the amount of data for each customer
Make a reuse plan
• Two aspects of reuse:
– Using existing things
– Creating reusable new things
• Reusable things include: – Models – Libraries – Frameworks –
Patterns
Make a reuse plan
• Reusable Libraries • A library is a collection of classes that are useful in
many contexts.
• Qualities of “Good” class libraries:
– Coherence – well focused themes
– Completeness – provide complete behavior
– Consistency polymorphic operations should have consistent names and
signatures across classes
– Efficiency – provide alternative implementations of algorithms
– Extensibility – define subclasses for library classes
– Genericity – parameterized class definition
Make a reuse plan
• Reusable Libraries • A library is a collection of classes that are useful in
many contexts.
• Qualities of “Good” class libraries:
– Coherence – well focused themes
– Completeness – provide complete behavior
– Consistency polymorphic operations should have consistent names and
signatures across classes
– Efficiency – provide alternative implementations of algorithms
– Extensibility – define subclasses for library classes
– Genericity – parameterized class definition
Make a reuse plan
• Reusable Frameworks
• A framework is a skeletal structure of a program that must be
elaborated to build a complete application.
• • Frameworks class libraries are typically application specific and not
suitable for general use.
Make a reuse plan
• Reusable Patterns : A pattern is a proven solution to a general problem.
• There are patterns for analysis, architecture, design, and implementation.
• A pattern is more likely to be correct and robust than an untested, custom
solution.
• Patterns are prototypical model fragments that distill some of the
knowledge of experts.
• Pattern vs. Framework • A pattern is typically a small number of classes
and relationships. • A framework is much broader in scope and covers an
entire subsystem or application.
Breaking a System into Subsystem
• A subsystem is a group of classes, associations, operations, events,
and constrains.
• A subsystem is usually identified by the services it provides.
• Each subsystem has a well-defined interface to the rest of the system
• The relation between two subsystems can be
– Client-server relationship
– Peer-to-peer relationship
The decomposition of systems
• Subsystems is organized as a sequence of
– Horizontal layers
– Vertical partitions
– Combination of layers and partitions.
Layered system
• Each layer is built in terms of the ones below it.
• The objects in each layer can be independent e.g. – A client-server
relationship
• Problem statement specifies only the top and bottom layers:
– The top is the desired system.
– The bottom is the available resources.
• The intermediate layers is then introduced.
• Two forms of layered architectures: – Closed architecture : Each layer is
built only in terms of the immediate lower layer.
– Open architecture : A layer can use features on any lower layer to any
depth
Partitioned System
• Vertically divided into several subsystems
• Independent or weakly coupled
• Each providing one kind of service.
• E.g. A computer operating system includes – File system – Process
control – Virtual memory management – Device control
Partitions vs. Layers
• Layers vary in their level of abstraction.
• Layers depend on each other.
• Partitions divide a system into pieces.
• Partitions are peers that are independent or mutually dependent.
(peer-to-peer relationship
Identifying Concurrency
• To identify – The objects that must be active concurrently – The objects
that have mutually exclusive activity
• Inherent Concurrency : by examining state model
• Two objects are inherently concurrent if they can receive events at the same time
without interacting.
• If the events are unsynchronized, you cannot fold the objects onto a single thread of
control
• Defining Concurrent Tasks –
• By examining the state diagrams, you can fold many objects onto a single thread of
control.
• A thread of control is a path through a set of state diagrams on which only a single
object at a time is active.
Allocation of Subsystems
• Allocate each concurrent subsystem to a hardware unit by
– Estimating hardware resource requirements
– Making hardware-software trade-offs
– Allocating tasks to processors
– Determining physical connectivity
Estimating hardware resource requirements
• The number of processors required depends on the volume of
computations and the speed of the machine
• Example: military radar system generates too much data in too short
a time to handle in single CPU, many parallel machines must digest
the data
• Both steady-state load and peak load are importan
Making hardware-software trade-offs
• You must decide which subsystems will be implemented in hardware
or software
• Main reasons for implementing subsystems in hardware
– Cost
– Performance – most efficient hardware available in the market
Allocating tasks to processors
• Allocating software subsystems to processors
• Several reasons for assigning tasks to processors.
– Logistics – certain tasks are required at specified physical locations, to control
hardware or permit independent operation
– Communication limits
– assigning highly interactive systems to the same processor, independent
systems to separate processors
Determining physical connectivity
• Determine the arrangement and form of the connections among the
physical units
• Connection topology- choose an topology for connecting the physical units
• Repeated units-choose a topology of repeated units
• Communications- choose the form of communication channels and
communication protocols
Management of Data Storage
• Alternatives for data storage:
• Data structures
• Files
• Databases
Handling Global Resources
• The system designer must identify global resources and determine
mechanisms for controlling access to them.
• Kinds of global resources:
• Physical units: Processors, tape drivers…
• Spaces : Disk spaces, workstation screen…
• Logical name : Object ID, filename, class name…
• Access to shared data : Database
• Some common mechanisms are: – Establishing “guardian” object that
serializes all access – Partitioning global resources into disjoint
subsets which are managed at a lower level, and – Locking
Choosing a Software Control Strategy
• To choose a single control style for the whole system.
• Two kinds of control flows:
• External control
• Internal control
Software External Control
• Concerns the flow of externally visible events among the objects in
the system.
• Three kinds:
• Procedure-driven sequential
• Event-driven sequential
• Concurrent
Procedure-driven Control
• Control resides within the program code
• Procedure request external input and then wait for it • When input
arrives, control resumes with in the procedure that made the call.
• Advantage: Easy to implement with conventional languages
• Disadvantage: The concurrency inherent in objects are to mapped into a
sequential flow of control. Suitable only if the state model shows a regular
alternation of input and output events. C++ and Java are procedural
languages
• They fail to support the concurrency inherent in objects.
Event-driven Control
• Control resides within a dispatcher or monitor that the language,
subsystem, or operating system provides.
• The dispatcher calls the procedures when the corresponding events
occur.
Software Internal Control
• Refer to the flow of control within a process.
• To decompose a process into several tasks for logical clarity of for
performance.
• Three kinds: – Procedure calls, – Quasi-concurrent inter-task call, •
Multiple address spaces or call stacks exist but only a single thread of
control can be active at once. – Current inter-task calls
Handling Boundary Conditions
• Most of system design is concerned with steady-state behavior, but
boundary conditions are also important
• Boundary conditions are – Initialization – Termination, and – Failure
• Initialization – The system must initialize constant data, parameters, global
variables, …
• Termination – Release any external resources that it had reserved.
• Failure – Unplanned termination of a system. The good system designer plans
for orderly failure
Setting Trade-off Priorities
• The priorities reconcile desirable but incompatible goals. – E.g
memory vs. cost
• Design trade-offs affect the entire character of a system.
• The success of failure of the final product may depend on how well its
goal s are chosen.
• Essential aspect of system architecture is making trade-offs between
– time and space – Hardware and software – Simplicity and
generality, and – Efficiency and maintainability
• The system design must state the priorities
Class Design
• The purpose of the class design is to complete the definitions of the
classes and associations and choose algorithms for operations
Class Design
• Bridging the gap
• Realizing Use Cases
• Designing Algorithms
• Recursing Downward
• Refactoring
• Design Optimization
• Reification of Behavior
• Adjustment of Inheritance
• Organizing a Class Design
Bridging the gap
• Bridge the gap from high-level requirements to low-level services
• Salesman can use a spreadsheet to construct formula for his
commission – readily build the system
• Web-based ordering system – cannot readily build the system
because too big gap between the resources and features
• The intermediate elements may be operations, classes or other UML
constructs. You must invent intermediate elements to bridge the
gap.
Realizing Use Cases
• Realize use cases with operations.
• The cases define system-level behavior.
• During design you must invent new operations and new objects that
provide this behavior.
Designing Algorithms
• Formulate an algorithm for each operation
• The analysis specification tells what the operation does for its clients
• The algorithm shows how it is done
• Choose algorithms that minimize the cost of implementing operations.
• Select data structures appropriate to the algorithms
• Define new internal classes and operations as necessary.
• Assign operations to appropriate classes.
Recursing Downward
• To organize operations as layers.
• Operations in higher layers invoke operations in lower layers.
• Two ways of downward recursion:
• By functionality
• By mechanism
• Any large system mixes functionality layers and mechanism layers.
Recursing Downward
• Functionality Layers
• Take the required high-level functionality and break it into lesser
operations.
• Make sure you combine similar operations and attach the operations
to classes.
• An operation should be coherent meaningful, and not an arbitrary
portion of code.
Recursing Downward
• Mechanism Layers
• Build the system out of layers of needed support mechanisms.
• These mechanisms don‟t show up explicitly in the high-level
responsibilities of a system, but they are needed to make it all work.
• E.g. Computing architecture includes
• Data structures, algorithms, and control patterns.
• A piece of software is built in terms of other, more mechanisms than
itself
Refactoring
• Changes to the internal structure of software to improve its design
without altering its external functionality.
• You must revisit your design and rework the classes and operations so
that they clean satisfy all their uses and are conceptually sound.
Design Optimization
• To design a system is to first get the logic correct and then optimize it.
• Often a small part of the code is responsible for most of the time or
space costs.
• It is better to focus optimization on the critical areas, than to spread
effort evenly. Design Optimization
• Optimized system is more obscure and less likely to be reusable.
• You must strike an appropriate balance between efficiency and clarity.
• Tasks to optimization: i. Provide efficient access paths. ii. Rearrange
the computation for greater efficiency. iii. Save intermediate results to
avoid recomputation.
Reification of Behavior
• Behavior written in code is rigid; you can execute but cannot
manipulate it at run time
• If you need to store, pass, or modify the behavior at run time, you
should reify it
Adjustment of Inheritance
• To increase inheritance perform the following steps
• Rearrange classes and operations to increase inheritance
• Abstract common behavior out of groups of clusters
• Use delegation to share behavior when inheritance is semantically invalid
Adjustment of Inheritance
• Rearrange classes and operations to increase inheritance
• Use the following kinds of adjustments to increase the chance of inheritance
– Operations with optional arguments
– Operations that are special cases
– Inconsistent names
– Irrelevant operations
Adjustment of Inheritance
• Use delegation to share behavior when inheritance is semantically invalid
• When class B inherits the specification of class A, you can assume that
every instance of class B is an instance of class A because it behaves the
same
• Inheritance of implementation – discourage this
• One object can selectively invoke the desired operations of another class,
using delegation rather than inheritance
• Delegation consists of catching operation on one object and sending it to a
related object
• Delegate only meaningful operations, so there is no danger of inheriting
meaningless operations by accident
Adjustment of Inheritance
• Delegation as alternative to Implementation Inheritance
• Delegation is a way of making composition (for example aggregation)
as powerful for reuse as inheritance
• In Delegation two objects are involved in handling a request – A
receiving object delegates operations to its delegate. The developer
can make sure that the receiving object does not allow the client to
misuse the delegate object
Organization of Class Design
• We can improve the organization of a class design with the following
steps:
• Information hiding
• Coherence of Entities
• Fine-tuning packages
Organization of Class Design
• Information hiding
• Carefully separating external specification from internal specification
• There are several ways to hide information:
– Limit the scope of class-model traversals
– Do not directly access foreign attributes
– Define interfaces at a high level of abstraction
– Hide external objects
– Avoiding cascading method calls
Organization of Class Design
• Coherence of Entities
• An entity, such as a class, an operation or a package is coherent if it is
organized on a consistent plan and all its parts fit together toward a common
goal.
• An entity should have a single major theme
• It should not be a collection of unrelated parts.
Organization of Class Design
• Fine – Tuning Packages
• Overview of Implementation
• Fine-tuning Classes
• Fine-tuning Generalization
• Realizing Associations
• Testing
Organization of Class Design
• Fine-tuning classes
• Fine tune classes before writing code in order to simplify development or to
improve performance
• Partition a class
• Merge classes
• Partition / merge attributes
• Promote an attribute / demote a class
References
• Michael Blaha, James Rumbaugh: Object-Oriented Modeling and
Design with UML, 2nd Edition, Pearson Education, 2005. (Chapters 10-
15)
• Grady Booch et al: Object-Oriented Analysis and Design with
Applications, 3 rd Edition, Pearson Education, 2007.
• Brahma Dathan, Sarnath Ramnath: Object-Oriented Analysis, Design,
and Implementation, Universities Press, 2009.
• Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling
Language User Guide, Pearson Education