Upload
avice-stephens
View
213
Download
2
Embed Size (px)
Citation preview
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
1
Chapter 14
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Overview of system design• Estimating performance• Making a Reuse plan• Breaking system into sub-system• Identifying Concurrency• Allocation of Sub Systems• Management of Data Storage• Handling Global Resources• Choosing a Software Control strategy• Handling Boundary Conditions• Setting Trade-off Priorities• Common Architectural Style
Topic Covered
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Till now, focus was on WHAT needs to be done, independent of HOW it is done.
• During System design, decide how the problem will be solved.
• Need to apply high level strategy – System Architecture – for solving the problem and building a solutions.
• During System design, developer decide the overall structure and style.
• System architecture provides the organization of the system into subsystem.
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• To construct system architecture, following decision must make:
• Estimating performance– Making a Reuse plan– Breaking system into sub-system– Identifying Concurrency– Allocation of Sub Systems– Management of Data Storage– Handling Global Resources– Choosing a Software Control strategy– Handling Boundary Conditions– Setting Trade-off Priorities– Common Architectural Style 4
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Estimating Performance• You should prepare rough performance
estimate.• Purpose of this task to determine if the system
is feasible.• You will have to make simplifying assumptions.
(i.e. assume factors)• Don’t worry about detail – just approximate,
estimate and guess.5
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For ATM exa. Consider following case– Bank has 40 branches and no. of terminals.– On a busy day half the terminal are busy at once.– Suppose each customer takes one min to perform
a session and most transaction involve a single transaction. i.e. 40 transaction a time.
– You can perform similar estimate for data storage. – Count the no. of customer, estimate amount of
data for each one and multiply. i.e. 40 *20 =800.
6
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Making a Reuse plan• Two different aspect of reuse
– Using existing thing– Creating reusable new things.
• Much easier to reuse existing things than to design new things.
• Most developer reuse existing thing and only a small fraction of developers create new things.
• Creating reusable new things is not easy task. It require good experience.
7
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Reusable thing includes mainly– Libraries– Frameworks– Patterns
• Libraries: it is a collection of classes that are useful in many contexts.
• Classes must be organized, so users can find them. Online searching can help more.
• Classes must have accurate and thorough description to help users determine their relevance.
8
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Several qualities of good class libraries:– Coherence: organized well focus– Completeness: complete behavior– Consistency: consistent names and signature.– Efficiency: provide alternative to implement– Extensibility: able to define subclasses – Genericity: should be parameterized class
where appropriate.
9
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Framework: it is skeletal structure of a program that must be elaborated to build complete application.
• Framework consists of more than just the classes. It is more specific to individual application.
• Framework class libraries are typically application specific and not suitable for general use.
10
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Patterns: A pattern is proven solution to a general problem.
• There are patterns for analysis, architecture, design and implementation.
• A pattern comes with guideline on when to use it, as well as exchange on its use.
• There are many benefits. One advantage, carefully created and applied on past problems.
• A pattern is different from a framework. 11
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• A pattern is typically a small number of classes and relationship.
• A Framework is much broader in scope and covers an entire application.
12
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Breaking a system into SubSystems• First steps in system design is to divide the
system into pieces.• Each major pieces of a system is called Sub
System.• Each subsystem is based on common
functionality, common physical location and common hardware.
• A subsystem is not an object nor a function. But a group of classes, association operations, events and constraints that are interrelated. 13
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• A Sub system always identified by its Service it provides.
• A Service is group of related functions that share common purpose.– For. File system within an operating system is a
subsystem.• Each subsystem interface specifies the form of
all interactions and information flow between them.
• Relationship between two subsystems can be client-server or peer-to-peer.
14
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Client-Server Relationship:– Client calls on the server, which performs some
services and replies with a result.– Client must know server interface, but server did
not know its client’s interface.– Because client initiates all interactions.
• Peer-to-Peer Relationship:– A communication from one subsystem to another
is not necessarily followed by an immediate response.
15
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Each subsystem must know each other’s interfaces.
– Therefore, these interactions are more complicated.
• So Decomposition of system into subsystem may be organized as a sequence of horizontal layers or vertical partitions.
16
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Layers:• A layered system is ordered set of tiers.• Each built in terms of the ones below it and
providing the implementation basis for the ones above it.
• Information is one way only – subsystem knows about the layers below it but has no information of layers above it.
• Client-Server relationship exists between upper layers(users of services) and lower layers (providers of services) 17
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• In interactive graphics system, windows are made from screen operation, which implemented using pixel operation, which execute device I/O operation.
• Each layer is implemented in terms of classes and operation of lower layers.
• Layers architecture are in two forms:– Open Architecture– Close Architecture.
18
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Closed Architecture:– Each layer built only in terms of immediate lower
layer.– Reduces dependencies between layered– Allows changes easily.
• Open Architecture:– A layer can use features of any lower layer to any
depth.– It reduces the need to redefine operation at each
level.– Changes to sub system can affect at higher level– So, it is Less robust compare to close architecture 19
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Usually Problem statement specifies only the top and bottom layers:– Top layers is desired system– Bottom layers is available resources (Hardware,
Operating system)
20
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Partitions:• Vertically divide a system into several
independent or weakly coupled subsystem.– For ex. Computer operating system includes a file
system, process control, virtual memory management and device control.
• Sub system may have some information of each other but not deep.
21
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Diff. between layers and partitions– Layers vary in their level. While partitions only
divide a system into pieces.( all have same level)– Layers depend on each others(client Server
relationship). While partitions are independent (peer to peer relationship)
22
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Combining layers and partitions• Layers can be partitioned, and partitions can
be layered.• Most large system require a mixture of layers
and partitions. (Refer fig 1)• Once you have identified the top-level
subsystems, you can show their informational flow.
• Many computations have the form of pipeline; 23
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
24
Figure 1
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For ATM example: there are 3 major sub systems. ATM stations, Consortium Computer and Bank computes.
• Consortium computer communicate with all ATM and bank computers ( comm. Links)
• Architecture uses station code and bank code to differentiate phone lines and consortium computer.
25
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
26
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Identifying Concurrency:• Identify the objects that must be active
concurrently and objects that have mutually exclusive activity.
• You can fold the latter objects into a single thread of control or task.
• Two steps:– Identifying inherent concurrency– Defining Concurrent Tasks. 27
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Identifying inherent concurrency• State model guide to identifying concurrency.• If two objects receive events at the same time
without interacting then its called inherently concurrent.
• If event are unsynchronized, you can’t fold the objects into a single thread of control.
• Often problem statement specifies that distinct hardware units can implement the objects.
28
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For Example ATM: it was stated (in chapter 11) each machine should continue to operate locally in event of central system failure, then would have no choice but to include a CPU in each ATM machine with full control program.
29
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Defining concurrent Tasks• By studying state diagram of individual objects
and exchange of events among them.• You can fold many objects onto a single thread
of control..• A thread of control is path through a set of
state diagram on which only a single object at a time is active.
30
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• A thread remains within a state diagram until an object sends an event and passes to the receiver of event.
• A thread splits if the object sends an event and continues executing.
• Only single object at a time is active.• ATM Ex. : if a central computer directly
controls the ATM, we can combine ATM object with Bank transaction object as a single task.
31
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Allocation of Subsystem• Must allocate each concurrent subsystem to
hardware unit.• Either general purpose or specialized
functional unit.• Criteria would be
– Estimate hardware resource requirement– Making hardware-software trade-off– Allocating Tasks to processors– Determining Physical connectivity. 32
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Estimating hardware resource requirement• System designer must estimate the required
CPU processing power by computing steady-state load.– I.e. Product of number of transaction per second
and time required to process a transaction.• You should increase estimate to allow for
transient effects(i.e. failure cases)• Steady-state and peak load are important.
33
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For. Ex. ATM machine just proive user interface and some local processing. So single CPU would work for each ATM.
• Consortium computer is essential – as it receives ATM request and sending them to appropriate bank computer. So it involves multiple CPUs.
• While Bank computers perform data processing and database application.
• Appropriate depend upon needed throughout.34
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Making Hardware-Software Trade-offs• You must decide which subsystem will be
implemented in hardware and which in software.
• Two main reason:– Cost – it is easier buy floating point chip than to
implement floating point in software.– Performance – more efficient hardware is
available.
35
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Allocating Tasks to processors• Several reasons for assigning task to
processors• Logistics : Some tasks are required at specific
physical locations or to permit independent operations.
• For ex. At ATM, might communication network is down on that case ATM must have its own CPU and programming logic.
36
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Communication Limits– Sometime available comm. bandwidth between
task & piece of Hardware is not sufficient then response is not getting on time or its taking more time to complete.
• Computation Limits– Assign separates processors for computation
process.
37
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Determining Physical Connectivity• Connection topology:
– Choose the topology for connecting physical units.– As Association in the class model indicating
physical connection.– For ATM communicate with Consortium.– Also client-server relationship also correspond to
physical connections.
38
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Repeated units– Topology has a regular pattern such as
• Linear Sequence , A martix, A tree, A Star• If you have boosted performance for
particular kinds of units or group of units, then you must specify their topology.
• Communications:– Choose the form of connection channel & comm
protocol.
39
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• System designer may specify the exact interfaces among units for interaction mechanisms.– For Ex. Interactions may be Asynchronous,
Synchronous or blocking.• Based on estimate bandwidth & latency of the
comm channels and choose the correct kinds of comm channels.
40
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Management of data storage• There are several alternatives for data storage.• You can use separately or in combinations.
– Data structure– Files– Database
• Based on cost, access time and reliability different kinds of data storage.– For Ex. PC application may use memory data structure
or files.– An accounting system may use a database, 41
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Data storage – Files– Files are cheap, simple and permanent.– Files implementation vary for different
computer systems.– For ex. Implementation for sequential files
are mostly standard, but commands and storage formats for random-access files and indexed files vary
42
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Kinds of data that belongs in files–Data with high volume and low
information density (historical records)– Quantities of data with simple structure.– Data that are accessed sequentially.– Data that can be fully read into memory
43
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Data storage – Database– Various type of DBMS available
• Relational DB• OO DB.
• DBMS cache frequently accessed data in memory.
• DB makes application easier to port different hardware and OS.
• Disadvantage – complex interface44
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Kinds of data that belongs in DB– Data that requires updates from multiple
users.– Data that must accessed by multiple
application programs.– Data that require updates via transaction.– Data that are long-lived and highly valuable.– Data that must be secure.
45
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Note:• Most application need a database, you should
use relational DBMS.• RDBMS features are sufficient for most
application.
46
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Handling Global Resources• System designer must identify
– Global resources – Mechanism for controlling the access.
• There are several kinds of global resources.– Physical units : Processors, tape drives and
communication satellites.– Space: Disk space, workstation screen and buttons
on a mouse
47
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Logical names: Object IDs, Filenames and class names.
– Access to shared data: Database• Resource can be
– Physical object : It can control itself by specifying protocol
– Logical object: Conflicting access in a shared environment.
– To solve conflicting access, you should introduce “Guardian object”.
48
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Guardian object - own each global logical resource and have control access to it.– All access must be pass through Guardian object
only • In ATM example, Bank code and Account
numbers are global resources. • Bank codes must be unique within
consortium.• Account number must be unique within the
Bank.49
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Choose the Software control strategy• Two kinds of control system in Software
system:– External control– Internal control
• External control concerns the flow on externally visible events among objects.
• Three kinds of control external event:– Procedure-driven sequential– Event-driven sequential– Concurrent 50
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Control style depend on the available resource (language, OS) and on the kind of interaction.
• Internal control refers to the flow of control within the process.
• It is only used in implementation therefore neither concurrent or sequential.
51
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Procedure-driven Control• Control resided inside the program code.Basic working:• Procedure request for input event and wait for
it.• When event arrives, control resumes within
the procedure that made the call.Advantage:• Easy to implement with conventional
programming.52
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Procedure-driven paradigm is suitable only if state model shows a regular alternation of input and output events.
Note:• C++ and Java are procedural languages. That is
why they fail to support concurrency inherent in objects.
53
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Event-driven Control• Control resides within a dispatcher or monitor
that the language, subsystem or OS provides.Basic Working• Dispatcher call the procedure when events
occurs.• Procedure call to the dispatcher sent output
or enable input but do not wait for it in-line.
54
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Once event is over, procedure return control to the dispatcher instead on retaining.
Advantage:• More flexible control than procedure-driven
systems.• Event-driven system are more modular and
can handle error conditions better than procedure-driven system.
55
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Concurrent Control• Control resides concurrently in several
independent objects, each a separate task.Basic Working:• A task can wait for input but other tasks
continue execution.• OS resolves scheduling conflicts among tasks
and usually supplies a queuing mechanism so that events are not lost.
56
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Internal control• Internal object interaction are similar to
external object interaction because you can use the same implementation mechanisms.
• Importance difference is– External interaction inherently involve events,
because objects are independent.– Internal interaction involve operation as
procedure calls.
57
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Other paradigm are possible such as– Rule based systems– Logic programming system– Other forms Nonprocedural programs
• Developer used such languages in limited areas only such as– Artificial Intelligence– Knowledge based programming
58
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Handling Boundary Conditions• Consider boundary conditions as well and
address kinds of issues. • Initialization
– System must initialize constant data, parameters, global variables, guardian objects, and possibly the class hierarchy.
– Initialize concurrent task is most difficult because object are independent.
59
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Termination– Termination is simpler than initialization because
internal object can be abandoned.– In concurrent system, one task must notify other
task of its termination. • Failure:
– Failure is unplanned termination of a system.– Basically it arise from user errors or from external
breakdown. – It can also arise from bugs in the system
60
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Common Architectural Styles• Several kinds of system listed :
– Batch transformation– Continuous transformation– Interactive interface– Dynamic simulation– Real-time system– Transaction Manager
61
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Batch transformation• A batch transformation performs sequential
computations.Working:• Application receives the input• Compute the answer• No ongoing interaction with outside worldExample:• Computational problems such as compilers,
payroll processing etc. 62
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For batch transformation problem, we can use class and interaction models.
• As it contains input, output and intervening stages.
• Most important thing is it should define a clean series of steps.
63
System Design
Parse TextDetermine
connectivityAbstract to OO model
Generate DB code
ASCII code
Graphics model
Connectivity model
class model
Database model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Compiler has five class model – One for input, one for output and three for
intermediate representation.
Steps for designing batch transformation:• Break overall transformation into stages
– Each stage performing one part of transformation.• Prepare class models for input, output and
intermediate stages. • Expand each stage until the operation are easy to
implement.• Restructure the final pipeline for optimizations. 64
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Continuous transformation• It is a system in which the outputs actively
depends on changing inputs.• In batch transformation, output compute one
time.• In continuous transformation, updates output
frequently.• System can’t recomputed each set of output
each time an input changes.65
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Implement continuous transformation with a pipeline of functions.
• Pipeline propagates the effect of each input change.
• To improve the performance of pipeline, define intermediate and redundant objects.
66
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Steps for designing a pipeline for continuous transformation
• Break overall transformation into stages– Each stage performing one part of transformation.
• Define input, output and intermediate models between each pair of stages.
• Differentiate each operation – that is propagate the incremental effects of each change to an input through the pipeline as series of incremental updates.
• Add additional intermediate objects for optimization 67
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Interactive Interface• System that is dominated by interaction
between the system and external agents, such as humans or devices.
• System can not control the agents.• Example of interactive system include
– forms-based query interface, – Workstation windowing system and – Control panel for a simulation.
68
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Major concerns of interactive interface are– Communication protocol between system and
agents– Syntax of possible interaction– Presentation of output– Flow of control within the system– Performance – Error handling
69
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Steps for designing interactive • Separate interface classes from the application
classes.• Use predefined classes to interact with
external agents• Use the state model as the structure of the
program.( i.e. concurrent, event-driven or procedure-driven control)
• Isolate physical events from logical event.• Fully specify the application functions that
invoked by the interface. 70
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Dynamic Simulation• A dynamic simulation models or tracks real-
world objects.– Ex. Economic models, video games.
• Objects and operation com directly from the application.
• Two ways for implementing control:– Explicit controller to application object– Objects can exchange messages among
themselves.71
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Steps in designing dynamic simulation• Identify active real-world objects from the
class model.• Identify discrete events.• Identify continuous dependencies. (i.e. one
attributes may depend on other)• Discrete events between objects can be
exchanged as a part of timing loop.
72
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Real-time system• A real-time system is an interactive system
with tight time constraints on actions.• Two types of real-time system
– Hard real-time system• Critical application that require a guaranteed response
within the time constraints.
– Soft real-time system• Highly reliable, but occasionally violate time
constraints.
73
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Real-time design is complex and involves issue such as– Interrupt Handling– Prioritization of tasks– Coordinating multiple CPUs
74
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Transaction manager• Main function is to store and retrieve data.• It deal with multiple users who read and write
data at the same time.• It also secure data from unauthorized access.• It is built on top of a DBMS
75
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Steps in designing• Map the class model to database structure.• Determine the units of concurrency.• Determine the units of transaction.• Design concurrency control for transaction.
76
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Application Interaction Model• Application Class Model• Application State Model• Adding Oerations
Topic Covered
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Most domain model focus on building a model of intrinsic concepts.• While Application model focus on the details of the application and consider interaction.• You can construct application interaction model with following steps:
– Determine the system boundary– Find actor– Find use cases
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Find initial and final events– Prepare normal scenarios– Add variation and exception scenarios– Find external events.– Prepare activity diagram for complex use cases.– Organize actors and use cases– Check against the domain class model.
79
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Determine the system boundary• Must know scope of an application to specify
functionality.• It means, you must decide what system
includes and what it omits.• If boundary is correct, you can treat system as
box where internal details are hidden and changeable.
• At this state, determine purpose of the system.80
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Don’t consider humans as part of system, • Ex. From problem statement (Chap 11),
mentioned “ design system for human cashiers and Automatic Teller machine (ATM)..”
• So here there will two different system is going to be design.– Human Cashier (Will be used at Bank)– ATM ( At ATM location).
Note: Will focus on ATM behavior only.81
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding Actors• Identify the external object that interact
directly with the system called Actors• Actors includes
– Humans, external devices and other software systems.
• In finding actors, we are not searching for individual but for standard behavior.
• Each actor should be idealized.82
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• It is possible for different kinds of external to play the same actor.– Ex. ATM application, the actors are Customer,
Bank and Consortium.
83
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding Use Cases• For each actor, list the functionality different
ways in which the actor uses the system called Use Cases.
• Use cases partition the functionality of a system into a small number of discrete units.
• Each use cases should represent a kind of service that system provides – something that provides value to the actor.
84
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Keep similar level of detail for use cases– “Apply for loan”– It should not be “Withdraw cash from saving
account using ATM” . Restate with “Make Withdrawal”
• Now draw preliminary use case diagram. • Show actors and use cases, connect actors to
use cases.• Usually, you can associate a use case with the
actor that initiates it.85
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• You should also write a one or more sentence for each use case.
86
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Initiate session: ATM establish the identity of the user and make a list of accounts and actions.
• Query Account: System provides general data for an account, such as current balance, date of last transaction etc.
• Process Transaction: transaction like deposit, withdraw and transfer.
• Transmit Data: ATM uses the consortium’s facilities to communicate with the appropriate bank computers.
87
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding Initial and Final Events• Use case diagram does not show behavior
clearly.• To Understand behavior, you must understand
the execution sequences of each use cases. • Determine which actor initiate the use case.• In may case, initial event is request for
services that use case provides.
88
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• In many cases, initial event is occurrence that triggers a chain of activity.
• Similar, determine final event(s).– For ex. For “apply of loan” would continue until
• Application submit• Loan grant or reject• Loan is delivered.• Paid off and Closed.
• User must define the scope for termination.89
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For ATM Example:– Initiate session:
• Initial Event is customer’s insertion of a cash card.
• Two Final Event: system keeps cash card and system returns the cash card.
– Query Account:• Initial Event is customer’s request for account
data.• Final event is system retrieve data for customer.
90
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Process Transaction:– Initial event is customer’s initiation of transaction.– Two final event : committing or aborting it.
• Transmit Data:– Initial event:
• customer’s request for account data.• Recovery from network, power or kind of
failure.– Final event: successful transmission of data.
91
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Preparing Normal Scenarios• For each use case, prepare one or more story
base scenarios.• Scenario illustrate the major interactions,
external display and information exchange.• Scenario is a sequence of events among a set of
interacting objects.• Think in terms of sample interactions.• Sometime problem statement describes full
interaction sequences, but most of time you will have invent.
92
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• So prepare scenarios for “normal” cases – interaction without any unusual inputs or error conditions.
• Information values exchanged are event parameters.– Ex. Entered password has password value as a
parameter.• So for each event, identify the actor that
caused the event and the parameters of the events.
93
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
94
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Adding variations and Exception Scenarios• Once normal scenarios prepared, consider
“Special” cases, such as omitted input, maximum and minimum values and repeated values.
• Then consider “error” cases, including invalid values and failures to respond.
• Consider various other kind of interactions also such as help request and status inquiries.
95
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• ATM Example:– ATM can’t read the card– Card has expired– ATM times out waiting for a response– Amount is invalid– Machine is out of cash or paper.– Communication lines are down.– Transaction rejected because of suspicious
patterns of card usage.
96
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding External Events• To find all external events – includes all inputs,
decisions, interrupts, and interaction to or from users or external devices.
• An Event can execute effects for a target object.• Use scenario to find out normal events, unusual
event and error conditions.• In simple words, transmission of information to
an object is Event.97
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For ex. Enter password is message from external User to application object ATM.
• Event instances whose values affect the flow of control should be different kinds of events.– Account OK, Bad Account and Bad Password are
different events.• Based on event entered, prepared sequence
diagram for it.
98
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Prepare a sequence diagram for each scenario.
• It shows participation in an interaction and sequences of message among them.
• From sequence diagram, you can then summarize the events that each class sends and receives.
99
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
100
Application Interaction Model
Sequence diagram for the process Transaction Scenario
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
101
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Preparing Activity diagrams for Complex use Cases
• Sequence diagram capture dialog and interplay between actors.
• Do not clearly show alternatives and decisions.
• Activity diagram let you consolidate all the behavior by documenting forks and merges in the control flow.
102
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
103
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Organizing Actors and Use cases• Next step to organize use cases with
relationship (includes, extend and generalization)
• It will helpful for large and complex systems.• For. Admin might be an operator with
additional privileges.
104
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
105
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Checking Against the Domain Class model• Application and domain models should be
mostly consistent.• The actors, use cases and scenarios are all
based on classes and concept from domain model.
• Cross check the application and domain models to ensure that there are no inconsistencies.
106
Application Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Construct an application class model with following steps:–Specify User Interfaces–Define Boundary classes.–Determine controllers.–Check against the interaction model.
107
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Specifying User Interface• Most interaction divided into two parts
– Application Logic– User Interface
• A user interface provides the user with way to access its objects, command (function/Features) and application options.
• Same program logic can accept input from command lines, files, mouse buttons, touch pane, physical push buttons, or remote links. 108
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• It is acceptable to sketch out a sample interface to help you visualize the operation of an application.
• Might need mock up the interface so that user can try it.
• Dummy procedure can simulate application logic. It will help you to evaluate the “look and feel” of the user interface.
109
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
110
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Defining Boundary Classes• It is always helpful to define boundary classes to
isolate the inside of a system from the external world.
• A boundary class is a class that provides a staging area for communication between a system and an external source.
• It understand the format of one or more external sources and converts information for transmission to and from the internal system.
111
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For ex. To summarize the communication between ATM and consortium, we need to define boundary classes (CashCardBoundary, AccountBoundary).
112
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Determining Controllers• A controller is active object that manages
control within the application.– It receives signal from outside world.– Reacts to them– Invokes operation on the objects in the system.– Send signals to outside world.
• A controller is piece of reified behavior captured in form of object.
113
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• For Ex. ATM has two major control loops.– Outer loop verifies customer and account.– Inner loop services transactions.
114
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Checking against the Interaction Model• Once you build class model, go over the use
cases and think about how they would work.• For Examples
– user sends a command– Parameters of command must come from UI
object.– Requesting a command itself must come from
some controller.• Finally, simulate use case with the classes.
115
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
116
Application Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Application state model focuses on application classes and enhances the domain state model.
• Application class are more important than domain classes.
• Identify application classes with multiple states and use the interaction model to find events for these classes.
• Then organized event sequences for each class with a state diagram.
117
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Next check various state diagram to make sure that common events match.
• Finally check state diagram against the class and interaction model.
• So to construct application state model with following steps:– Determine application classes with states.– Find events– Build state diagram
118
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Check against other state diagram– Check against the class model– Check against the interaction model.
119
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Determining Application Classes with States• Identify classes that are prominent to users
and important to the operation.• Consider each application class and determine
which one have multiple states.• User interface classes and controller classes
are good candidate.• In contrast, boundary classes are less likely to
be involved in state model.120
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding Events• From prepared scenario, extract events.• Don’t overlook common interaction and
highlights the major events.• Difference between domain and application
processes for state model.– With Domain model, first we find states and then
we find events. Because its focus on data.– With Application model, first we find events and
then states.• Ex. Insert card, enter password etc.
121
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Building State Diagram• Next step, build state diagram for each
application class.• Select any one class and consider a sequence
diagram for it.• Now find event from that.• Interval between any two event is a state.• Give each state a name.• Now merge other sequence diagrams into the
state diagram. 122
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Now finds loops within the diagram. If a sequence of events can be repeated indefinitely then they form a loop.
• Once loops found, merge other sequence diagram and look for alternative path.
• Another alternative is to partition a state diagram into two concurrent sub-diagram, using one subdiagram for the main line and other for distinguishing information.
123
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Once normal events considered, add variation and exception cases.
• When diagram covers all scenarios, you are finished with state diagram.
• Now refer each state diagram figure. for ATM Example.
124
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
125
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
126
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
127
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
128
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Checking against other state diagram• Check state diagram for each class.• Every event should have sender and receiver. • Follow the effects of input event from object to
object to make sure that they match scenarios.• For Ex. SessionController initiates the
TransactionController, and the termination of the TransactionController causes the SessionController to resume.
129
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Checking against the Class Model
• Same way, make sure that the state diagram are consistent with the domain and application class models.
• ATM Example: Multiple ATMs concurrently access an account. And account access need to be controlled to ensure that only one update a time is applied. 130
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Checking against the Interaction Model• When state model is ready, go back and check
it against the scenarios of interaction model.• Simulate each behavior sequence by hand and
verify that state diagram give correct behavior.• If error discovered, change state diagram or
scenarios. Don’t assume that the scenarios are always correct.
131
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Adding Operations• Till now we did not focus on operations
because the list of useful open-ended and it is difficult to know when to stop adding them.
• Following are source through which we can add operations:– Operations from Class model , Operations from
Use Cases, Shopping-List Operations and Simplifying operations.
132
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Operation from Class model: To add operation, note down attributes values and links implies by Class model because it does not shows explicitly.
• Operation from Use Cases: To add operation, we are using use cases. Most complex functionality of system comes from use cases.
133
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Shopping list operations: Shopping list mean Operations are not dependent on particular application but are meaningful in their own right.
• ATM Exam:– Bank.createSavingAccount()– Bank.CreateCheckingAccount()– AddAccount()– Remove Account()– Close()
134
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Simplifying Operations: Study class model for similar operation and variations in form on a single operations.
• Use inheritance where possible to reduce the number of distinct operations.
• If needed then only introduce New superclass.• Locate each operation at correct level within
the class hierarchy.
135
Application State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
136
Chapter 12
Domain Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Introduction• Overview of Analysis• Domain Class Model• Domain State Model• Domain Interaction Model
Topic Covered
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• During analysis, we build models and begin to understand the requirements deeply.• To build a domain model, you must interview business expert, examine requirements statements, and study related requirements.• Successful analysis model states what must be done, without restricting how it is done and avoid implementation decisions. Introduction
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Overview of Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• As fig. shows, analysis begin with problem statement during system conception.
• Problem statement can be incomplete or informal but analysis makes it more precise and expose ambiguities.
• You must understand real-world system described by the problem statement, and abstract its essential features into a model.
• Sequence can be problem statement build model (Domain) build model(application).
Overview of Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Analysis model addresses the three aspects of objects.– Static structure of objects (Class Model)– Interaction among objects ( Interaction
Model)– Life-cycle histories of objects (State Model)
Overview of Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• First step in analyzing the requirements is to construct a domain model.
• Static structure of the real world system is captured.
• The domain model describes real-world classes and their relationships to each other.
142
Overview of Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Information for the domain model comes from the – Problem statement, – Artifacts from related systems, – Expert knowledge of the application domain and– General knowledge of the real world.
The steps to be performed to construct a domain class model:
1. Find Classes. 2. Prepare a data dictionary. 143
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
3. Find associations. 4. Find attributes of objects and links. 5. Organize and simplify classes using
inheritance. 6. Verify that access paths exist for likely
queries. 7. Iterate and refine the model. 8. Reconsider the level of abstraction. 9. Group classes into packages
144
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
1. Finding Classes• First Step, find relevant classes for objects
from application domain.– It includes houses, person, machines etc.
• Classes often correspond to nouns.• Eg- ” a reservation system sell tickets to
performances at various theater”-– Tentative classes would be Reservation, System,
Tickets, Performance and Theaters.
145
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Idea is to capture concepts. not all nouns are concepts, and concepts are also expressed in other parts of speech.
• For the Case study of the ATM: The following are the classes extracted from problem statement nouns. 146
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
147
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Additional classes that do not appear directly in the statement but can be identified from our knowledge of the problem domain
148
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
2.Keeping the Right classes• Discard unnecessary and incorrect classes
according to the following criteria.• Redundant classes: If two classes express
the same concept, you should keep the most descriptive name. –ATM example. Customer and user are
redundant; we retain customer because it is more descriptive.
149
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Irrelevant classes: If class has little or nothing do with application, eliminate it.– ATM Ex. cost is outside the scope of the ATM
software.• Vague classes: class should be specific.
– ATM Example, System, Security provision, Banking network etc are not specific thing.
• Attributes: Names that primarily describe individual objects should be restated as attributes.
150
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• ATM Example, Account Data, Cash, Transaction data are purely indicating attributes not a class.
• Operations: If a name describes an operation that is applied to objects and not manipulated in its own right, then it is not a class. – Eg-if we are simply building telephones, then call
is part of the state model and not a class
151
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– But Billings system for telephone calls a Call would be important class with attributes date, time, origin and destination.
• Roles: The name of a class should reflect its intrinsic nature and not a role that it plays in an association.– Ex.Owner of a car in a car manufacturing
database, not correct as a class. It can be a person( owner, driver, lessee)
152
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Implementation Constructs: Eliminate constructs from the analysis model that are irrelevant to the real world. – We may need them during design and not now.– Ex. Transaction Log class.
• Derived classes: As a general rule, omit classes that can be derived from other classes.– Mark all derived classes with a preceding
slash(‘/’)in the class name.
153
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
154
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
3. Preparing a Data Dictionary• Prepare a data dictionary for all modeling
elements.• Describe the scope of the class within the
current problem, including all assumptions or restrictions on its use.
• It also describes associations, attributes, operations and enumeration values.
155
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Account, • ATM, • Bank, • BankComputer, • CashCard, • Cashier,
• CashierStation • CentralComputer, • Consortium, • Customer, • Transaction
156
Data Dictionary for the ATM classesDomain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
4. Finding Associations• Find A structural relationship between two or
more classes is an association. • A reference from one class to another is an
association.• Associations often correspond to verbs or verb
phrases.– Ex. Physical Location ( part of, NextTo)– Directed Actions (Drives)– Communication (Talks To) 157
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Ownership ( Has, Part of)– Satisfaction of condition ( WorksFor, Manages).
• Idea here is to capture relationships
158
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
159
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
160
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
5. Keeping the Right AssociationsDiscard unnecessary and incorrect associations,
using the following criteria:• Associations between eliminated classes: If
you have eliminated one of classes then either you eliminate association or restate it.– Ex. Banking Network includes cashier stations and
ATMs.– ATM dispenses cash
161
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– ATM prints receipts– Bank provide software– Cost apportioned to banks– System provides record keeping and– System provides security.
• Irrelevant or implementation associations: Eliminate any association that deals with implementation or outer problem statement.– Ex. System handles concurrent access (Implementation)
162
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Actions: An association should describe a structural property of the application domain not a transient event.– Ex. ATM accepts Cash card (Interaction
cycle)It is not a permanent relationship between
ATM and Cash.– Eliminate ATM interact with user. Central
computer clears transactions with bank .
163
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Ternary associations: You can decompose most association among three or more classes into binary associations.
• Always decomposed without losing information.
• Ex. Bank computer processes transaction against account can be convert into Bank computer processes transaction and transaction concern accounts.
164
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Derived associations : Omit association and attributes, they may be redundant.– Ex. GrandParentOf can be defined in terms of pair
of ParentOf.– Ex. youngerThan expresses condition on the
birthdate of two person, not additional information.
• Derived association don’t add information, they useful for understanding.
165
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Semantics of Association• Misnamed Association: Name are important
to understanding and should be chosen with care.– Ex. Bank computer maintain accounts. Rephrase as
Bank hold account.• Association End name: Add association end
name where appropriate.– Ex. Person manages person. It would be
appropriate to give end names boss and worker166
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Qualified Associations: Most names are not globally unique. So context combines with the name to uniquely identify the object.– Ex. Company name unique within one state but
may be duplicated in other state.– So combining State + Company name will uniquely
identify company.– Ex. bankCode differentiate bank in a consortium.
167
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Multiplicity: Don’t put much effort as it is often changes during analysis.
• Missing Association: Add any missing association that are found during analysis.– Transaction entered on cashier station, Customers
have accounts and transaction authorized by cash cards.
– To perform above, we need to introduce relationship from Cashier to cashier station. So association Cashier authorized on cashier station needed 168
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Aggregation: it is specially for mechanical parts or bills of material.– Don’t spend much time trying to defer between
association and aggregation.– Ex. Bank is part of Consortium and indicate the
relationship with aggregation.• Now combining all things together, class
diagram prepare.
169
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
170
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
6. Finding Attributes: • Attributes are data properties of objects like
colour, weight etc.• Attributes usually correspond to nouns followed
by possessive phrases, such as “the color of the car”
• Attributes are less likely to be fully described in problem statement.
• Only consider attributes directly relevant to application. Get important attributes then add details to it.
171
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Avoid derived attributes.– EX. Age is derived from birthdate and currentTime
• Looks for attributes on associations.– Ex. Workfor association attribute can be salary,
title etc.
172
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
7. Keeping the Right Attributes• Eliminate unnecessary and incorrect
attributed with the following criteria:• Objects: if element is important rather than
just its value, then it is an object.– Ex. Boss refers to a class and Salary is an
attributes.• Name: Name often refer as Qualifier rather
than attributes.• Name is an attribute when its use does not
depend on context, 173
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Ex. Names of person are not unique therefore its attributes.
• Identifiers: it mean referencing objects used for some work.– Ex. ATM transaction always generate Transaction
ID for each operation. So you can count Transaction ID as attributes.
• Attributes on Association:– If value require the presence of link then
attributes of the association should derived. 174
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Ex. Workfor association attribute can be salary, title etc
• Internal Values: if an attributes describes internal state of an object then eliminate it.
• Fine Detail: Omit minor attributes that are unlikely to affect most operation.
• Discordant attributes :- an attribute that seems completely different from and unrelated to all other attributes then remove it.
175
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Boolean Attributes: Convert Boolean attributes into enumeration.
176
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
177
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
8. Refining with Inheritance• Next step, to share common structure.• Apply in two directions:
– Bottom Up• By Generalizing common aspects of existing
classes into a superclass.– Top Down
• By Specializing existing classes into multiple classes
178
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Bottom Up Generalization:– Searching for classes(from bottom up) with similar
attributes, associations and operation.– For each generalization, define a superclass to
share common features.– May have to slightly redefine some attributes or
classes to fit in. But don’t push too hard it create wrong generalization.
– Ex. RemoteTransactiona and CashierTransaction are similar and can be generalized by Transaction.
179
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Top-Down Specialization:–It main derived from application
domain itself.–Look for noun phrases composed of
adjectives:• Fixed menu, sliding menu and text menu.
–Avoid excessive refinement.
180
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Generalization Vs. enumeration :- – Generalization is all about common structure– Enumeration is all about list of values.– Ex. CurrentAccount and SavingAccount share
common structure but it does not affect behavior within the ATM application. So Type can introduces as attributes of account and enumerate it.
• Multiple Inheritance: if require then apply because it increasing both conceptual and implementation complexity 181
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Similar association: – when the same association name appears more
than once with the same meaning, try to generalize the associated class.
– Ex. EntryStation generalizes CashierStation and ATM.
• Adjusting inheritance Level– Assign attributes and association to specific
classes in the class hierarchy.– You may need some adjustment to get everything
right.182
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
183
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
9.Testing Access Paths• Verify that access paths exist for likely queries.• Trace access paths through the class model to
see if they yield sensible results. • Make sure you have not overlooked any
associations.
184
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
10. Iterating a Class model• A class model is rarely correct after a single
pass.• If you find any deficiency, go back to an earlier
stage if necessary to correct it. So iterate and refine the model.
• There are some sing of missing classes.– Asymmetries in association and generalization.– Disparate attributes and operation on a class.– Difficulty in generalizing cleanly. 185
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
– Duplicate association with same name and purpose.– A role that substantially shapes the semantics of a
class. Ex. It mean converting association into a class. • Look out for missing associations
– Missing access paths for operations– Lack of attributes, operations and association on a
class.– Redundant information:
• Adjust the placement of attributes and associations
186
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
187
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
11.Shifting the level of abstraction• Abstraction makes a model more complex but
can increase flexibility and reduce the number of classes.
• In case of abstraction, we need to think in terms of pattern.
• A pattern distills the knowledge of experts and provide a proven solutions to a general problem.– Ex. Management hierarchy. 188
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
189
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
12.Group classes into packages.• The last step of class modeling is to group
classes into packages. • A package is a group of elements(classes,
association, generalizations and lesser packages) with common theme.
• When you place classes and association in a package, you are making semantic statement.
190
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Therefore, package might be:– Tellers – Cashier, Entry Station, Cashier Station,
ATM– Accounts – Account, cash card, card authorization,
customer, transactions, update, cashier transaction, remote transaction.
– Bank- consortium, bank• Each package can add details to it.
191
Domain Class Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• The Following steps are performed in constructing a domain state model– Identifying classes with states – Finding states – Finding Events – Building state diagrams – Evaluating state diagrams
192
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
1. Identifying Classes with states• Study list of domain classes.• Look for classes that can be characterized by a
progressive history or represent cyclic behavior.
• Identify significant states in the life cycle of an Object. Not every state occurs in every cycle.– ATM Example, Account is appropriate behavior for
ATM. Life cycle of Account is progressive and cycling to and from problem states.
193
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding States• List the state for each class.• Characterized the object by their
– Attributes Values– Associations that may participants – Attributes and association that are meaningful in
certain states only.• Avoid names that indicate how the state
came.194
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• By looking at events and considering transitions among states, missing states will become clear.
• Ex. Some states for Account– Normal (Normal access)– Closed ( Closed by customer)– Overdrawn ( withdrawal exceeds the balance)– Suspended ( blocked for some reason)
195
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Finding Events• Now find events that cause transitions among
states.• Think about stimuli (input) that cause a state
to change.• Find other events that takes object into a
specific states– Ex. Pickup receiver on telephone, it enters into
Dialing State.– But many telephone has pushbuttons that invoke
specific functions. 196
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• So there are some additional event that occur within a state and don’t cause a transitions.
• For Domain State model, make focus on events that cause transition among states.
• Ex. Event includes: close account, withdraw excess funds, repeated incorrect PIN, suspected fraud and Administrative action.
197
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Building State diagrams• Determine for which state, each event applies.• Add transitions to show the change in state
caused by the occurrence of an event when an object is in particular state.
• Once you have specified the transitions, check does it represent an error or not? If yes then add transitions to error state.
198
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
199
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Evaluating State Diagram• Examine each state model. Are all states
connected? • Path from initial state to the final state?• Are the expected variations represent it?• Are there any dead states that terminate the
cycle?• Find missing path and states from it.• When complete, it should indicate life cycle of
the class. 200
Domain State Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
201
Chapter
Process Overview
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Development Stages– System Conception– Analysis– System Design & Class Design– Implementation & Testing– Training, Deployment and Maintenance
• Development Life Cycle– Waterfall Development– Iterative Development
Topic Covered
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
System Conception• System Conception deals with origin of the system or
application.• S/W development begins with
- business analyst or users conceiving an application & formulating tentative requirement.
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Analysis• Focuses on creation of models.• It specify What must be done, not how it should be done.• Task of Analyst
- Must work with the requester (client) to understand the problem, because problem statement are rarely complete or correct.
• There are two stages of analysis:– Domain Analysis & Application Analysis
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Domain Analysis– Focus on real-world things whose semantics
the application captures– Ex. Airplane Flight is real-world object,
Flight reservation system must represent it.• Domain model is mainly to decide which
information to capture and how to represent it.
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Application analysis– Focuses the computer aspects of the application that are visible to users.– Ex. Flight reservation screen is part of flight reservation system.– It does describes the application appears from the outside.– It does not describe the implementation of the application
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
System Design• During system design, developer makes strategic decisions relevant to system architecture.• Architecture is high level plan or strategy for solving application problem.• Architecture is depend on requirement and based on past experience.• Must understand how a new system interacts with other systems.
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Class Designer• Task of class designer
–Add details to analysis model–They determine data structures &
algorithm for each of the operation of window class.
–They elaborate both domain & application objects using same OO concept & notation.
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Implementation• It is the stage of writing code.• Translating design elements into programming language and database code.• Tools can used to generate code.
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Testing• Now system is ready but it must be carefully tested before delivered to customer.• Tester once again revisit the original requirement and verify the proper functionality.• Can discover errors or bugs.• Tester perform testing on all hardware and software platform
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Training• Organization must train users so that they can get full benefit from an application.• Team should prepared separate user documentation(i.e. Help file or user manual) Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Deployment• Deployment mean, product release• Once training is over, system is ready to install.• System must work on various platform and on various configuration.• It should support multiple languages.
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Maintenance• Bugs that remain in the original system
will gradually appear during use and must be fixed.
• Preserve the long-term viability of the application.
213
Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Waterfall Development– In this approach, developer has to follow strictly
linear sequence with no backtracking.– First, capture requirement, construct analysis
model then prepare system design, class design and followed by implementation, testing, deployment.
– Suitable for well understood applications with predictable outputs from analysis and design, such systems seldom occur.
214
Software Development Life Cycle
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• A waterfall approach also does not deliver a useful system until completion.
• Drawback : This makes it difficult to assess progress and correct a project that has gone wrong.
215
Software Development Life Cycle
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
216
Software Development Life Cycle
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Iterative Development• More flexible. • There are multiple iterations as the system
evolves to final deliverable. • Each iteration includes a full complement of
stages: analysis, design, Implementation and testing.
• This is the best choice for most applications because it gracefully responds to changes and minimizes risk of failure. 217
Software Development Life Cycle
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
218
Management and business users get early feedback about progress.
Software Development Life Cycle
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Enumeration• An enumeration is a data type that has finite set of
values:• For ex.
• Enumeration often occur and are important to users.– i.e. it display only the possible values or users are restricted to
access only allowed values or data.• Do not use generalization to capture the values of an
enumerated attributes
Calendarweek: Week
<<enumeration>>week
SundayMondayTuesday…….Saturday
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• An enumeration list of values• Generalization Structuring the description of objects.
– Ex. We are not introducing generalization for “Card” Class because most games do not differentiate the behavior of “Suit”.
Card
suit:suitrank: rank
<<enumeration>>Suit
SpadesClubsHeartsdiamonds
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
UML notation
• Top section: Write keyword enumeration in between “<<>>” above enumeration name.• Second section : List the enumeration values.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Multiplicity
• Multiplicity is a constraint on the cardinality of a set.• Multiplicity for an attribute specifies the number of possible values for each representation of attributes.• Common specifications are
– Mandatory single value [1]– An optional single value [0..1]– Many[*]
• It specify whether an attribute is mandatory or optional• It indicates if an attribute is single valued or can be a collection.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• If not specified, it is assumed to be a mandatory single value[1]
Person
name: string[1]address:string[1..*]birthdate:date[1]
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Scope• It indicates if a feature applies to an object or
a class.• You should avoid attributes with class scope
because they can lead inferior model.• It is better to model group explicitly and assign
attributes to them.
Personname
PhoneMailBox
maxMessageCountphoneNumberpassword
PhoneMessage
maximumDurationmaxDaysRetaineddateRecordedtimeRecordedpriority
1 * *
*
0..1
source
owner
1
{ordered}
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Upper model is inferior because the maximum duration, maximum day retained and maximum message count have a single value for the entire phone mail system.
• It is acceptable to use an attribute with class scope to hold the extent of a class ( Set of objects for a class)
Personname
PhoneMailBox
phoneNumberpassword
PhoneMessage
dateRecordedtimeRecordedpriority
1 **
*
0..1
source
owner
1
{ordered}
MailCategory
maxMessageCount maximumDurationmaxDaysRetained
1
*
owner
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• It is also acceptable to define operations of class scope.• It is convenient to define class scoped operations to provide summary data.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Visibility
• Visibility refers to the ability of a method to reference a feature from another class and has the possible values of – Public, – Protected– Private– Package
• Public features: Any method freely access• Protected features: only methods of the containing class and its descendant via inheritance can access• Private features: only methods of the containing class can access.• Package features: Methods of classes defined in the same package as the target class can access.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• UML denotes visibility with a prefix.– Character “+” precedes public– Character “-” precedes private– Character “#” precedes protected– Character “~” precedes package
• Several issues when choosing visibility– Comprehension
• You must understand all public features to understand the capabilities of a class. • Others are merely an implementation convenience.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Extensibility– Many classes can depend on public methods, so it can be highly disruptive to change their signature.– Fewer classes depend on private, protected, and package methods, there is more latitude to change them.
• Context– Private, protected and package methods may rely on preconditions or state information created by other methods in the class. – A private method may calculate incorrect results or cause the object to fail.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Association ends
• A binary association has two ends, a ternary association has three ends and so forth.Few properties:• Association end name:
– An association end may have meaningful name.– Names clarifies multiple references to a class and facilitate navigation
• Multiplicity:– Can specify multiplicity for each association end.
• Ordering:– Objects for a “many” association end are usually just a set.
• Bags & Sequences:– Objects for a “many” association end also be a bag or sequence.
• Qualification:– One or more qualifier attributes can disambiguate the objects for “many” association end
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Additional properties
• Aggregation:– It may be an aggregate or constituent (element) part.– Only binary association can be a aggregation:
• One association end must be an aggregate• Other must be a constituent
• Changeability:– It specifies the update status of an association end.
• Navigability– UML shows navigability with an arrowhead on the association end attached to the target class.– Arrowheads may be attached to zero, one or both ends of an association.
• Visibility– Similar to attributes and operations, association ends may be public, protected, private or package.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
N-ary AssociationsProject
Person
Language*
*
*
programmer
• N-ary associations mean associations among three or more classes.– Ex. Programmers use computer languages on projects.
• UML notation:– It is diamond with lines connecting to related classes.– If the association has a name, written in italics next to the
diamond.Note:• Avoid n-ary associations – most of them can be decomposed into
binary associations, with possible qualifiers and attributes.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• N-ary association can have a name for each end just like binary associations.
• You can not traverse n-ary associations from one end to another as with binary associations.
Semester
ListedCourse
Professor
*
*
*
DeliveredCourse
roomNumberTextbook
* *
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Ex. A professor teaches a listed course during a semester. The resulting delivered course has a room number and any number of textbooks.
• Programming language can not express n-ary associations.• So you need to promote (support) n-ary associations to
classes.• When you promote n-ary associations to a class, might change
the meaning of a model.• An n-ary associations enforces that there is most one link for
each combinations.– Ex. For each combinations of professor, semester and
ListedCourse there is one DeliveredCourse • So if you were implementing below fig. special application
code would have to enforce the uniqueness of Professor + Semester + ListedCourse.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Semester
ListedCourse
Professor
DeliveredCourse
roomNumber Textbook
1
1
*
* * *
*
1
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• UML has two forms of part-whole relationships:– Aggregation - A general form – Composition – More restrictive.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Aggregation
• Definition:– An aggregation as relating an assembly class to one constituent part class.– An assembly with many kinds of constituent parts corresponds to many aggregations.– For ex.
• College consists of students, professor, courses etc.• Here college is assembly and the others are constituents. • Therefore, college to student is one aggregation, college to professor is another aggregation.
– We define each individual pairing as an aggregation.– So that we can specify the multiplicity of each constituent part within the assembly.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Aggregation is an special form of binary associations.• Most important property of aggregation:
– Transitivity• If A is part of B and B is part of C, then A is part of C.
– Antisymmetric• If A is part of B, then B is not part of A.
• Aggregate operations imply transitive closure and operate on both direct and indirect parts.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Aggregation v/s Association
• Aggregation is not an independent concept, it is a special form of association.• If two objects are tightly bound by a part-whole relationship, it is an aggregation.• If two objects are usually considered as independent and have linked, it is association. To find whether there is a aggregation or not, some tests includes:
– Use the phrase part of– Some operations on the Whole apply to its parts– Some attributes values circulate from whole to all or some parts.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
UML notation:• Like association, except a small diamond indicates the assembly
end. • Decision to use aggregation is
– Matter of Judgment– Arbitrary
College
ProfessorStudent
Courses
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Aggregation v/s Composition• Composition is a form of aggregation with two
additional constraints.– A constituent part can belong to at most one
assembly.– Once its assigned, it has coincident lifetime with
the assembly.• Composition implies ownership of the parts by
the whole. • Composition is convenient for programming
– Ex. Deletion of assembly object triggers deletion of all constituent objects.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
UML notation:• Composition is a small solid diamond next to assembly
class.
EX. A company consists of divisions, which in turn consists of departments.
• A Company is indirectly a composition of departments.
Company
Person
Division Department1
*
* *1
1WorksFor
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overviewPropagation of operations
• Propagation is the automatic application of an operation to a network of objects. When the operation is applied to some starting object.
• Ex. A persons owns multiple documents.• Copy operations propagate from document to paragraph to
characters. • Copying a paragraph copies all the characters in it.• Operation does not propagate in the reverse direction: A
paragraph can be copied without copying the whole document.
Person
copy()
Document
copy()
Paragraph
copy()
Character
1 *
Owns
1 *
Copy4
1 *
Copy4
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
UML notation:• Small arrow indicating the direction and operation name next to the affected association.Note: this notation is not part of the UML and is a special notation.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Abstract Classes
• An abstract class is a class that has no direct instances but whose descendant classes have direct instances.• A Concrete class is a class that is instantiable; it can have direct instances.• Only concrete classes may be leaf classes in an inheritance tree.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Baker and candelstickMaker are concrete classes because they have direct instances.
Worker
Baker CandlestickMaker
{ note: listing of workers is incomplete}
Concrete Class: it can have direct instances.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
ComputePay()
yearToDateEarnings
Employee
ComputePay()
weeklyRate
FullTimeEmployee
ComputePay()
hourlyRate
PartTimeEmployee
Abstract Class and Abstract operation: it has not direct instances.
FullTimeEmployee and PartTimeEmployee are concrete classes because they can be directly instantiated.
UML Notation:Abstract class name listed in italic font or may place
keyword {abstract} below or after the name.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• An abstract class can define signature for an operation without supplying corresponding method.
• An abstract operation defines the signature of an operation for which each concrete subclass must provide its own implementation.
• A concrete class may not contain abstract operations.UML Notation:• An abstract operation is designated by italics or the
keyword {abstract}. Note:• Abstract nature of a class is always provisional,
depending on the point of view or application.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Multiple Inheritance
• It permits a class to have more than one superclass and to inherit features from all parents. • More complicated form of generalization than single inheritance. • Advantage is greater power in specifying classes and an increased opportunity for reuse.• Disadvantage is a loss of conceptual and implementation simplicity.• Multiple inheritance mean either the conceptual relationship between classes or the languages mechanism that implements that relationship.• Distinguish between
– Generalization : conceptual relationship– Inheritance : Language mechanism.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Kinds of multiple Inheritance• Common form of multiple inheritance is from
sets of disjoint classes.• Each subclasses inherits from one class in each
set.
FullTimeIndividualContributor
FullTimeEmp PartTimeEmp Manager IndividualContributor
Employee
employementStatus managerialStatus
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Here, FullTimeEmp and PartTimeEmp are disjoint; and Manager and IndividualContributor are also disjoint classes.
• We can also define additional combinations classes here like FullTimeManager, PartTimeContributor, PartTimeManager and FullTimeIndividualContributor.
• Each generalization should cover a single aspect (A generalization set name).
• Therefore, here class Employee has two aspect – Employment Status– Managerial Status
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• So, FullTimeIndividualContributor inherits Employee features along two paths via employmentStatus and managerialStatus.• Conflicts among parallel definitions create ambiguities. • You should avoid such conflicts in models or explicitly resolve them.
– For Ex. FullTimeEmp and IndividualContributor both have attribute called name.– FullTimeEmp.name could refer as person’s full name and IndividualContributor.name might refer as person’s title.
• Solution is restating the attributes of classes.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Multiple inheritance can also occur with overlapping classes.
landVehicle watervehicle
Amphibiousvehicle boatCar
Vehicle
{overlapping, incomplete}
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• AmphibiousVehicle is both Land and water vehicle. So there is a overlapping.• UML uses constraint to indicate an overlapping generalizations set;• Notation is a dotted line cutting across affected generalization with keyword in braces.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overviewMultiple Classification
Definition:– One instance happens to participant in two overlapping
classes.
Person
Faculty
UniversityMember
Student Staff
Instructor
1 *
{Overlapping: }
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• UML permits multiple classification but most OO languages handle it poorly. • Fig. show that Person as an object composed of multiple UniversityMember object. • This workaround replaces inheritance with delegation.• This is not totally satisfactory, there is a loss of identity separates roles.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Workaround
• Dealing with multiple inheritance is implementation issue but early restructuring of a model is often the easiest way to work around its absence.• Two approaches make use of delegation, which is an implementation mechanism by which object forwards an operation to another object for execution.• Restructuring technique
– Delegation using composition of parts– Inherit the most important class and delegate the rest.– Nested generalization
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Delegation using composition of parts– You can recast superclass with multiple independent generalization as a composition in which each constituent part replaces a generalization. – Single object having a unique ID by a group of related objects that compose an extended object.– Inheritance of operations across the composition is not automatic.– Composite must capture operations and delegate to appropriate part.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overviewEmployee
EmployeeEmployment EmployeeManagement
FullTimeEmployee PartTimeEmployee IndividualContributorManager
1
11
1
employmentStatus managerialStatus
You need not create various combination as explicit classes.
All combinations of subclasses from the different generalizations are possible.
Workaround for multiple inheritance - delegation
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Inherit the most important class and delegate the rest.– Maintain identity and inheritance across the most important
generalization.– Reduce the remaining generalization to composition and delegate
their operations.
Employee EmployeeManagement
PartTimeEmployee IndividualContributorManager
1 1
employmentStatus managerialStatus
FullTimeEmployee
Workaround for multiple inheritance – inheritance and delegation
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Nested Generalization:– Factor on one generalization first, then the other.– This approaches multiplies out all possible combinations.– This preserves inheritance but duplicates declarations and
code and violates the spirit of OO programming.
Employee
FullTimeEmployee PartTimeEmployee
employmentStatus
FullTimeManager
PartTimeManager
FullTimeIndividualContributor
PartTimeIndividualContributor
fullTimeEmpStatus partTimeEmpStatus
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• There are several issue when selecting the best workaround.– Superclass of equal importance– Dominant superclass– Few subclass– Sequencing generalization sets– Large quantities of code– Identity
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Superclass of equal importance:– If a subclass has several superclasses it may be best to use
delegation and preserves symmetry in the model.
• Dominant superclass:– If one superclass clearly dominate and others are less important,
preserve inheritance through this path.
• Few subclasses:– If the number of combinations is small, consider nested
generalization otherwise avoid.
• Sequencing generalization sets.– In a case of generalization, factor on most important criterion
first, then second most and so forth.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Large quantities of code:– Try to avoid nested generalization, in a case of duplicate large quantities of code.
• Identity:– Consider the importance of maintaining strict identity. Only nested generalization preserves this.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overviewMetadata
Definition• Metadata is data that describes other data.
– For ex. A class definition is metadata.
• Models are inherently metadata, they describe the things being modeled.
modelNameyearbasePrice
CarModel
modelNameyearbasePrice
PhysicalCar
Company Person
*
manufacturer1
*1 Describes
owner 1
*
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• A car model describes many physical cars and holds common data.• A car model is metadata relative to a physical car, which is data.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Constraints
Definition• A constraint is Boolean condition involving model elements, such as objects, classes, attributes, links, associations and generalizations sets. • A constraint restricts the values that elements can assume.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overviewConstraints on objects
salary
Employee
boss 0..1
*
lengthwidth
Window
priority
Job
Ex-1. No employee’s salary can exceed the salary of the employee’s boss. ( a constraints between two things)
Ex-2. No window can have an aspect ratio of less than 0.8 or greater than 1.5 ( a constraint between attributes).
Ex-3. Priority of a job may not increase (a constraint on the same object)
Employee.salary < boss.salary 0.8< length/width<1.5 Priority never increase
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Constraints on Generalization sets
• Class models capture many constraints through their structure.– For ex. The semantics of generalization imply certain structural
constraints.• With single inheritance the subclasses are mutually exclusive• UML had few keywords for generalization sets.
– Disjoint• The subclasses are mutually exclusive. Each object belongs exactly one of
subclasses.– Overlapping
• The subclasses can share some objects. An object may belongs to more than one subclass.
– Complete:• The generalization lists all the possible subclasses.
– Incomplete:• The generalization may be missing some subclasses.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Constraints on Links• Multiplicity is a constraint on cardinality set.• Multiplicity for an associations restricted the number of
objects related to a given object.• Qualification also constraints an association.• A qualifier attribute does not merely describe the
association but also significant in resolving the “many” objects.
• An association class implies a constraint.• An association class has constraint that an ordinary class
does not; it derives identity from instances of the related classes.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• There is no particular order on the objects of a “many” end for ordinary association.• But, constraint {ordered} indicates that elements of a “many” associations end have explicit order.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Use of constraints Declaration lets you express a constraint’s intent,
without supposing an implementation. That mean, convert constraints to procedural
form before implementation. Practically, you can not enforces every constraint
with model’s structure, but you should try to enforce the important ones.
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
UML notation• Two alternative notations of constraints:
– Delimit a constraint with braces or – place it in a “dog-eared” comment box.
• You should try to position constraint near affected elements.
• A dashed arrow can connect a constrained element to the element on which it depends.
{Constraint2: }priority
Job
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• The subject is not primarily about OO-language or coding.• This subject emphasize on initial stages of process development
i.e. Requirement Gathering Planning etc.
• Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects.
OOAD Concept
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
OOAD is divided into two parts as follows:• OOA (Object Oriented Analysis):
– Definition :Object Oriented Analysis (OOA) is concerned with developing requirements and specifications • OOD (Object Oriented Design)
– Definition: Object Oriented Design (OOD) is concerned with developing object-oriented models of a software/system to implement the requirements identified during OOA
OOAD Concept
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• What is an object?1) any concept that represent a single thing2) a representation of a specific entity in the real world3) may be tangible (physical entity) or intangibleExamples: In the case of LMS, software or system itself is intangible object and student and Library clerk act as tangible objects.
What is an object?
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Organize software as a collection of discrete objects that incorporate both data structure and behavior.– Data structure data pattern or data style or
formation of data– Behavior things that the object can do that
are relevant to model• OO approach has 4 characteristics:
– Identity– Classification– Inheritance– Polymorphism
What is Object-Orientation?
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Identity • Classification
• Polymorphism
• Inheritance
Characteristics of Objects
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Definition : Discrete (i.e. unique) & distinguishable entities called objects.
Ex. A person is an object.His name is Identify Ex. Ram
Note:• Objects are uniquely identifiable by name.• Each objects has its own inherent identity.• In other words, two objects are distinct even if an their attribute values (i.e. name and size) are identical.Ex. Twins are two distinct person by identity
Characteristics of Objects - Identity
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Definition:
– Objects with the same data structure (attributes) & behavior ( operation) are grouped into a class.
• In OO systems, class is a set of objects that share common structure and common behavior
• Classes are important mechanisms for classifying objects.
• Each class describes a possibly infinite set of individual objects.
Characteristics of Objects - Classification
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Each objects is said to be instance of its class.
• Objects has its own value for each attributes but shares the attributes names & operations.
Example : Class Name : Circle Attributes : radius, center Operation : setCenter(), setRadius()
Characteristics of Objects - Classification
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Definition: Sharing of attributes & operations (features) among classes based on hierarchical relationship.– A superclass has general information that subclass
refine and elaborate.– Each subclass incorporates all the features of its
superclass and adds its own features.– In other words, defining new classes from the
existing one.
Characteristics of Objects - Inheritance
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Note: subclasses need not repeat the features of the superclass.Advantage: common features of several classes into a superclass can reduce repetition within design and programs.
Characteristics of Objects - Inheritance
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
class Person { String name; String age; void birthday () { age = age + 1; }}
class Employee extends Person { double salary; void pay () { ...}}
Every Employee has a name, age, and birthday method as well as a salary and a pay method.
Person
Employee
Inheritance is implied by is-a or kind-of relationship.
Characteristics of Objects – Example of Inheritance
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Definition– Same operation may behave differently for
different classes.– In simple words, “ One name multiple form”– Here operation mean – it’s a procedure or
transformation that an object perform or is subject to.
– For example , Class name is POLYGON– Attributes - vertices, border color, fill color.– Operations – Draw, erase, fill
– An implementation of an operation by a specific class is called Method
Characteristics of Objects – Polymorphism
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• OO Development refers to the software life cycle.i.e. Planning, Analysis, Design & Implementation
Why OO Development?• In essence of OO development is the
identification & organization of application concepts, rather than in a programming language.
286
What is OO Development?
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Earlier, OO community focused on implementation part rather than analysis and design.
• It focuses excessively on implementation mechanisms rather than the underlying thought process that support.
• An OO development approach encourage software developers to work & thinks in terms of the application throughout software life cycle.
287
OO Dev – Modeling Concept, Not implementation
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• OO development is a conceptual process independent of a programming language until the final stage.
• OO development is fundamentally a way of thinking & not a programming technique.
• It can serve as a medium for specification, analysis, documentation & interfacing as well as for programming
288
OO Dev – Modeling Concept, Not implementation
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• OO Development & Graphical notation represents OO concept.
• OO process consists of building a model of an application & then adding details to it during design.
• Same notation is used from – Analysis Design Implementation.
• So information is not lost or translated into the next stage [Reusability].
289
OO Dev – Modeling Concept, Not implementation
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• System Conception• Analysis• System Design • Class Design • Implementation
290
OO Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• System Conception means origin of the system.
• S/W development begins with - business analyst or users conceiving an
application & formulating tentative requirement.
291
System Conception
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• System Conception• Analysis• System Design • Class Design • Implementation
292
OO Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Task of Analyst- Must work with the requester (client) to
understand the problem, because problem statement are rarely complete or correct.
- To design the Analysis model which demonstrates what the desired system must do, not how it will be done.
- Analyst is not concerned about implementation decision.
293
Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
294
Analysis model
Domain model Application model
Description of real-world
objects reflected Within the system
Description of the parts of application system itself that are
visible to the user.
Ex. Bank account is domain model. Application model includes Saving accounts, current account, demat account etc.
Analysis
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
System ConceptionAnalysisSystem Design Class Design Implementation
295
OO Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Task of system designer - must decide what performance characteristics to optimize.- choose strategy to attack the problem.- making tentative resource allocation.
• Ex. Designer might decide to change the window screen for fast & smooth working, even when windows are moved or erased.
System Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
System ConceptionAnalysisSystem Design Class Design Implementation
297
OO Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Task of class designer- add details to analysis model- They determine data structures & algorithm for each of the operation of window class.- They elaborate both domain & application
objects using same OO concept & notation.
Class Design
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
System ConceptionAnalysisSystem Design Class Design Implementation
299
OO Development Stages
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Task of Implementers :-• Translates the classes & relationships developed during class design into particular programming language, database or hardware• During implementation, follow good software engineering practice so that traceability to the design is apparent (i.e. clear). Implementation
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• OO concepts apply throughout the System Development Life Cycle (SDLC)– i.e. Analysis design implementation
• Use same classes from stage to stage without a change of notation.
• Some classes are not part of analysis but are introduced during design or implementation.
Ex. Data structure such trees, hash table & linked list are not visible to users at the time of analysis.– but designers introduce them to support particular algorithms.
Summary of OO Development
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Models
Class Model
State model
Interaction model
Objects in the system and their relationship
Life history of objects in the system
Interaction among objects
Three Software Models
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Class model
•Describe the static structure of the objects in a system & their relationship •It define the context for software development.•Class model contains class diagram to express it.•A class diagram is graph phase.•Nodes are classes.•Arcs are relationship among classes.
Book Store
Relationship
classes
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
State Model
• Describe aspect of an object that change over time.• State model specifies & implement control with state
diagram• A state diagram is a graph whose
• Nodes are state• Arcs are transitions between state caused by events
State 1 State 2
State Diagram
Event
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Interaction model
•How the objects in a system co-operate to achieve broader results.•Interaction model start with•Use case that are elaborate into with sequence and activity diagram.
Use Cases
Activity Diagram
Sequence DiagramElaborate
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Use cases:Focus on functioning of systemSimple mean, what a system does for users
Sequence diagramShows the object that interact Time sequence of their interactions
Activity diagramElaborate important processing steps.Activity diagrams can be used to describe the business and operational step-by-
step workflows of components in a system
Interaction Model
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
307
• Grady Booch• James Rumbaugh • Ivar Jacobson Are the man behind Invention of OO Modeling Technique.• Object Modeling Technique (OMT) concept evolved in 1991.
OO Modeling History
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
308
• In 1994 James Rumbaugh joined Rational (now the part of IBM) in 1994 & began working with Grady Booch on UML Notations.• In 1995, Ivar Jacobson also joined Rational & added his concept to the unification work.
OO modeling History
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
309
• In 1996 the Object Management Group issued a request for proposals for standard OO modeling notation.• Later Rational led the final proposal team, with Booch, Rumbaugh & Jacobson deeply involved.
OO modeling History
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
310
OO modeling History
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
OO themes are not unique to OO systems, they are particularly well supported.AbstractionEncapsulationCombining data and behaviorSharingEmphasis on the essence of an objectSynergy
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Abstraction:Focus on essential aspects of an application while ignoring details.
i.e. focusing on what an object is and does, before deciding how to implement it.Use of Abstraction:
Freedom to make decisions as long as possible by avoiding premature commitment to details.
Ability to abstract is probably the most important skill required for OO development.
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Encapsulations ( Information Hiding):
– It is separates the external ( accessible to objects) aspects of an objects from the internal ( hidden from other objects) implementation details.
– It prevents portions of a program from becoming so interdependent that a small change has massive ripple effects.
– For ex. You may want to change the objects to • Improve performance, Fix a bug, Consolidate
code, Support porting
313
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• Encapsulation is not unique to OO language but ability to combine data structure & behavior in a single entity makes encapsulation cleaner & powerful.
314
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Combining data & Behavior• In non-OO code, to display the content of a window
must distinguish the type of each figure, such as circle, polygon etc & call the appropriate procedure to display it.
• In OO code, program invoke the “Draw” operations on each figure and each object implicitly decide which procedure to use, based on its class.
• So caller of an operation need not consider how many implementation exist.
315
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
• So, maintenance is easier, because the calling code need not be modified when a new class is added.
• In an OO system, the data structure hierarchy matches the operation inheritance hierarchy.
316
Data structure Hierarchy
Procedure Hierarchy
Class Hierarchy
Is replaced by
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Sharing• OO technique promote sharing at different levels.• Sharing via inheritance is one of the main advantage of
OO language.• OO development not only lets you share information
within an application, but also offers the aspects of reusing designs & code on future projects.
• OO provides the tools to build libraries ( or collection) of reusable component.
317
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Emphasis on the essence of an object:– In OO technology, focus is on what an objects is
rather than how it is used.– Use of an object depend on the details of
application and often change during development.
– OO development greater emphasis on data structure & lesser emphasis on procedure structure.
318
OO THEME
Prepared By Jay Dave© RKU 2014
Object-Oriented Analysis and DesignProcess overview
Synergy : • OO concepts can be used in isolation but
together they complement each other synergistically.
319
OO THEME