Unit-Ii: Chapter-4 Object Oriented Methodologies Objectives
Unit-Ii: Chapter-4 Object Oriented Methodologies Objectives
CHAPTER- 4
OBJECTIVES:
INTRODUCTION:
Basic Definitions
by step.
1986: Booch came up with the object-oriented design concept, the Booch
method.
1987: Sally Shlaer and Steve Mellor came up with the concept of the
1
1990: Wirfs-Brock, Wilkerson, and Wiener came up with responsibility-
driven design.
1991: Peter Coad and Ed Yourdon developed the Coad lightweight and
prototype-oriented approach.
1991: Jim Rumbaugh led a team at the research labs of General Electric to
Goals
Object-Oriented Methodologies
Jacobson's methodologies
layered Architecture
2
Survey of Some of the Object-Oriented Methodologies
and Jacobson which are the origins of the Unified Modeling Language
models.
the system.
robust code.
3
OMT Modeling
dictionary.
diagrams.
Object Model
Identity
Attributes
Operations
4
OMT Object Model of a Bank System
Each state receives one or more events at which time it makes the
5
State Transition Diagram for Bank Application User Interface
OMT data flow diagram shows flow of data between different processes in
business
6
OMT DFD of ATM System
Booch Methodology
7
Diagrams in Booch Method
Class diagrams
Object diagrams
State transition diagrams
Module diagrams
Process diagrams
Interaction diagrams
Eg. of Booch class diagram
8
Eg. of Booch state transition diagram
9
OO Methodologies
Rumbaugh Booch
et al.s methodology
OMT
Some of the OO
methodologies
Jacaobson et al.
methodologies
OMT is a fast, intuitive approach for identifying & modeling all the
10
1. Analysis ==> results are objects, and dynamic and
functional models
decisions
robust code
Object Model
presented by object
model & data
dictionary Dynamic model
presented by state
diagrams & event
flow diagrams Functional Model
presented by data
flow & constraints
Booch Methodology
11
Booch method consists of those diagrams ==> class diagram, object
development process
Conceptualization
Evolution or implementation
Maintenance
12
Jacobson et al. Methodologies
Object Oriented
Business Object Oriented
Engineering Software
(OOBE) Engineering
(OOSE) / also
called Objectory
covers the entire life cycle & stress traceability between different
phases
OOSE : Objectory
Development
OOBE
o Analysis phase
o Design & implementation phases
o Testing phase
13
Boochs Macro Development Process
Conceptualization
Establish goal
system
Use class diagram to decide what classes exist, how they relate to one
another
Use module diagram to to map where each class & object should be
declared
14
Evolution or Implementation
Maintenance
15
A Unified Approach (UA)
guidelines along with UML notations & diagrams ==> for better
16
SUMMARY
KEY TERMS:
OMT
Object model
Dynamic model
Object Model
OMT Functional Model
Framework
17
MULTIPLE CHOICE
REVIEW QUESTIONS:
1. What are the phases of OMT? Briefly describe each phase (Pg 63)
2. What is an object model? What are the OMT models? (Pg 63)
3. What is dynamic model? What are the OMT models? (Pg 63)
4. What is functional model? What are the OMT models? (Pg 64)
5. What is the main advantage of DFD? (Pg 64)
6. What is the strength of OMT? (Pg 63-64)
7. Name five Booch diagrams (Pg 65)
8. Briefly describe the Booch system development process (Pg 66-67)
9. What is the strength of Booch methodology? (Pg 65)
10. What is Objectory? (Pg 68)
11. Name the models in Objectory (Pg 70)
12. What is a use case? (Pg 68)
13. What is the reason for having abstract use cases? (Pg 69)
14. Name some ways of describing use cases (Pg 69)
15. What must a use case contain? (Pg 69)
16. What is the strength of Jacobson methodology? (Pg 68)
17. Differentiate between patterns and frameworks (Pg 78)
18
18. Define Pattern (Pg 72)
19. Define Proto Pattern (Pg 73)
20. Name the characteristics of a good pattern (Pg 73)
21. Differentiate between generative and non-generative patterns (Pg 73)
22. List out the components of a Pattern template (Pg 74)
23. What is a pattern thumbnail? (Pg 76)
24. What are Anti Patterns? (Pg 76)
25. Name the guidelines for capturing patterns (Pg 76)
26. What is pattern mining? (Pg 76)
27. Define framework (Pg 77)
28. What is Unified Approach? (Pg 78)
29. Give the steps in OOA (Pg 80)
30. Give the steps in OOD (Pg 80)
31. What is layered approach to software development? (Pg 82)
32. Give the significance of Business Layer (Pg 83)
33. Give the significance of UI(View) Layer (Pg 84)
34. Give the significance of Access Layer (Pg 84)
Reference :
19
CHAPTER- 5
Chapter objectives
INTRODUCTION
20
STATIC AND DYNAMIC MODELS
Static model
o It can be viewed as a snapshot of a systems parameters at rest or a
specific point in time. They are needed to represent the structural or static
aspect of a system. The UML class diagram is an example of static model.
Dynamic model
o It can be viewed as a collection of procedures or behaviors that taken
together reflect the behavior of a system over time. Dynamic modeling is
the most useful during the design and implementation phases of the
system development. The UML interaction diagrams and activity models
are examples of dynamic models.
WHY MODELING?
Clarity
Familiarity
Maintenance
Simplification
Advantages of Modeling
Good models are essential for communication among project teams. As the
complexity of systems increases, so does the importance of good modeling
techniques. Some of the advantages are as follows:
Models make it easier to express complex ideas.
The main reason for modeling is to reduction of complexity.
Models enhance and reinforce learning and training.
The cost of modeling analysis is much lower than the cost of similar
perimentation conducted in real system.
Manipulation of the model is much easier.
21
INTRODUCTION TO UNIFIED MODELING LANGUAGE:
22
What is UML?
UML stands for Unified Modeling Language. This object-oriented system of
notation has evolved from the work of Grady Booch, James Rumbaugh, Ivar
Jacobson, and the Rational Software Corporation. These renowned computer
scientists fused their respective technologies into a single, standardized model.
Today, UML is accepted by the Object Management Group (OMG) as the standard
for modeling object oriented programs.
Class diagrams
Class diagrams are the backbone of almost every object oriented method, including
UML. They describe the static structure of a system.
Package diagrams
Package diagrams are a subset of class diagrams, but developers sometimes treat
them as a separate technique. Package diagrams organize elements of a system into
related groups to minimize dependencies between packages.
Object diagrams
Object diagrams describe the static structure of a system at a particular time. They
can be used to test class diagrams for accuracy.
Sequence diagrams
Sequence diagrams describe interactions among classes in terms of an exchange of
messages over time.
Collaboration diagrams
Collaboration diagrams represent interactions between objects as a series of
sequenced messages. Collaboration diagrams describe both the static structure and
the dynamic behavior of a system.
Statechart diagrams
Statechart diagrams describe the dynamic behavior of a system in response to
external stimuli. Statechart diagrams are especially useful in modeling reactive
objects whose states are triggered by specific events.
23
Activity diagrams
Activity diagrams illustrate the dynamic nature of a system by modeling the flow
of control from activity to activity. An activity represents an operation on some
class in the system that results in a change in the state of the system. Typically,
activity diagrams are used to model workflow or business processes and internal
operation.
Component diagrams
Component diagrams describe the organization of physical software components,
including source code, run-time (binary) code, and executables.
Deployment diagrams
Deployment diagrams depict the physical resources in a system, including nodes,
components, and connections.
Each UML diagram is designed to let developers and customers view a software
system from a different perspective and in varying degrees of abstraction. UML
diagrams commonly created in visual modeling tools include:1
Use Case Diagram displays the relationship among actors and use cases.1
Class Diagram models class structure and contents using design elements such as
classes, packages and objects. It also displays relationships such as containment,
inheritance, associations and others. 1
Interaction Diagrams
24
Activity Diagram displays a special state diagram where most of the states are
action states and most of the transitions are triggered by completion of the actions
in the source states. This diagram focuses on flows driven by internal processing. 1
Physical Diagrams
Introduction
25
UML Notation
There are many different types of UML notation. For this short presentation, a few
types of notation will be covered. For a more complete description of the UML
notation, you can refer to the UML 1.1 Notation Guide. When beginning to use
the UML, it is helpful to start with some basic notation (e.g., class diagrams) and,
then, as you become more proficient, advanced UML notation can be used.
Class Diagram
Class diagrams represent the static structure of the classes and their relationships
(e.g., inheritance, aggregation) in a system. A class icon is divided into three
components?class name, attributes, and operations.
26
Source: Fowler & Scott, UML Distilled
Class diagrams can be used to document a Business Object Model and are
widely used in both high-level and low-level design documents.
From a Java perspective, it may not be effective to include each and every
operation and attribute of a class in a class diagram because this leads to
maintenance issues (e.g., if a method or attribute changes in the code then
the model needs to be updated); rather, javadoc can be used to document an
implementation.
To maintain consistency with Java coding style, class names should begin
with an uppercase letter while operations and attributes should begin with a
lowercase letter.
27
Generalization relationships can be mapped to the Java extends relationship
while the realizes relationship can be mapped to the Java implements
relationship.
Class diagrams are widely used to describe the types of objects in a system and
their relationships. Class diagrams model class structure and contents using design
elements such as classes, packages and objects. Class diagrams describe three
different perspectives when designing a system, conceptual, specification, and
implementation. These perspectives become evident as the diagram is created and
help solidify the design. This example is only meant as an introduction to the
UML and class diagrams. If you would like to learn more see the Resources page
for more detailed resources on UML.
Classes are composed of three things: a name, attributes, and operations. Below is
an example of a class.
28
The association relationship is the most common relationship in a class
diagram. The association shows the relationship between instances of classes. For
example, the class Order is associated with the class Customer. The multiplicity of
the association denotes the number of objects that can participate in then
relationship.1 For example, an Order object can be associated to only one customer,
but a customer can be associated to many orders.
In this example the classes Corporate Customer and Personal Customer have
some similarities such as name and address, but each class has some of its own
attributes and operations. The class Customer is a general form of both the
Corporate Customer and Personal Customer classes. This allows the designers to
just use the Customer class for modules and do not require in-depth representation
of each type of customer.
29
When to Use: Class Diagrams
Class diagrams are used in nearly all Object Oriented software designs. Use them
to describe the Classes of the system and their relationships to each other.
Class diagrams are some of the most difficult UML diagrams to draw. To draw
detailed and useful diagrams a person would have to study UML and Object
Oriented principles for a long time. Therefore, this page will give a very high level
overview of the process. To find list of where to find more information see the
Resources page.
Before drawing a class diagram consider the three different perspectives of the
system the diagram will present; conceptual, specification, and implementation.
Try not to focus on one perspective and try see how they all work together.
When designing classes consider what attributes and operations it will have. Then
try to determine how instances of the classes will interact with each other. These
are the very first steps of many in developing a class diagram. However, using just
these basic techniques one can develop a complete view of the software system.
30
This example is only meant as an introduction to the UML and use cases. If you
would like to learn more see the Resources page for more detailed resources on
UML.
31
An actor is represents a user or another system that will interact with the
system you are modeling. A use case is an external view of the system that
represents some action the user might perform in order to complete a task.
Use cases are used in almost every project. The are helpful in exposing
requirements and planning the project. During the initial stage of a project most
use cases should be defined, but as the project continues more might become
visible.
Use cases are a relatively easy UML diagram to draw, but this is a very
simplified example. This example is only meant as an introduction to the UML
and use cases. If you would like to learn more see the Resources page for more
detailed resources on UML.
32
This example shows the customer as a actor because the customer is using
the ordering system. The diagram takes the simple steps listed above and shows
them as actions the customer might perform. The salesperson could also be
included in this use case diagram because the salesperson is also interacting with
the ordering system.
From this simple diagram the requirements of the ordering system can easily
be derived. The system will need to be able to perform actions for all of the use
cases listed. As the project progresses other use cases might appear. The customer
33
might have a need to add an item to an order that has already been placed. This
diagram can easily be expanded until a complete description of the ordering system
is derived capturing all of the requirements that the system will need to perform.
Package Diagram
Package diagrams provide a mechanism for dividing and grouping model elements
(e.g., classes, use cases). In UML, a package is represented as a folder.
34
Source: Fowler & Scott, UML Distilled
35
UML use case diagram syntax
Actor participant in use case; usually a user of the system, may not be a human.
36
performed)
Exceptions: Recipient address not entered (different error situations that can occur)
Variations: Create an email with an attachment (alternative courses that can
potentially be taken)
Related use cases: Login use case
Non-functional requirements (Priority, Response Time, etc.): High priority
A use case diagram provides an overview of the system's use cases and their
actors; it places use cases in context. In UML, an actor is represented as a
stickman while a use case is represented as an oval.
37
Source: Fowler & Scott, UML Distilled
38
Interaction Diagrams: Sequence and Collaboration
Interaction diagrams show how objects interact with one another. There are two
types of interaction diagrams: Collaboration Diagram and Sequence Diagram.
Interaction diagrams can be used during the high-level design (e.g., for business
object model development) as well as for low-level design activities (e.g.,
developing an implementation for a use case). Interaction diagrams are helpful for
showing the collaborations between objects but fall short in terms of a complete
definition of the behavior.
Interaction diagrams model the behavior of use cases by describing the way
groups of objects interact to complete the task. The two kinds of interaction
diagrams are sequence and collaboration diagrams. This example is only meant as
an introduction to the UML and interaction diagrams. If you would like to learn
more see the Resources page for a list of more detailed resources on UML.
Interaction diagrams are used when you want to model the behavior of
several objects in a use case. They demonstrate how the objects collaborate for the
behavior. Interaction diagrams do not give a in depth representation of the
behavior. If you want to see what a specific object is doing for several use cases
use a state diagram. To see a particular behavior over many use cases or threads
use an activity diagrams. 1
39
Sequence diagrams:
40
The next diagram shows the beginning of a sequence diagram for placing an
order. The object an Order Entry Window is created and sends a message to an
Order object to prepare the order. Notice the the names of the objects are followed
by a colon. The names of the classes the objects belong to do not have to be
listed. However the colon is required to denote that it is the name of an object
following the objectName:className naming system.
Next the Order object checks to see if the item is in stock and if the
[InStock] condition is met it sends a message to create an new Delivery Item
object.
41
The next diagrams adds another conditional message to the Order object. If
the item is [OutOfStock] it sends a message back to the Order Entry Window
object stating that the object is out of stack.
42
This simple diagram shows the sequence that messages are passed between
objects to complete a use case for ordering an item.
Collaboration diagrams:
Collaboration diagrams are also relatively easy to draw. They show the
relationship between objects and the order of messages passed between them. The
objects are listed as icons and arrows indicate the messages being passed between
them. The numbers next to the messages are called sequence numbers. As the
name suggests, they show the sequence of the messages as they are passed between
the objects. There are many acceptable sequence numbering schemes in UML. A
simple 1, 2, 3... format can be used, as the example below shows, or for more
detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.
43
The example below shows a simple collaboration diagram for the placing an
order use case. This time the names of the objects appear after the colon, such as
:Order Entry Window following the objectName:className naming convention.
This time the class name is shown to demonstrate that all of objects of that class
will behave the same way.
44
State Diagrams
State diagrams have very few elements. The basic elements are rounded
boxes representing the state of the object and arrows indicting the transition to the
next state. The activity section of the state symbol depicts what activities the
object will be doing while it is in that state.
All state diagrams being with an initial state of the object. This is the state of the
object when it is created. After the initial state the object begins changing states.
Conditions based on the activities can determine what the next state the object
transitions to.
45
Below is an example of a state diagram might look like for an Order
object. When the object enters the Checking state it performs the activity "check
items." After the activity is completed the object transitions to the next state based
on the conditions [all items available] or [an item is not available]. If an item is
not available the order is canceled. If all items are available then the order is
dispatched. When the object transitions to the Dispatching state the activity
"initiate delivery" is performed. After this activity is complete the object
transitions again to the Delivered state.
46
State diagrams can also show a super-state for the object. A super-state is
used when many transitions lead to the a certain state. Instead of showing all of
the transitions from each state to the redundant state a super-state can be used to
show that all of the states inside of the super-state can transition to the redundant
state. This helps make the state diagram easier to read.
The diagram below shows a super-state. Both the Checking and Dispatching
states can transition into the Canceled state, so a transition is shown from a super-
state named Active to the state Cancel. By contrast, the state Dispatching can only
transition to the Delivered state, so we show an arrow only from the Dispatching
state to the Delivered state.
47
48
STATE CHART DIAGRAM FOR ATM system
49
Activity Diagrams
Activity diagrams show behavior with control structure. Activity diagrams can be
used to show behaviors over many use case, model business workflows, or
describe complicated methods.
50
A synchronization bar indicates that the outbound trigger occurs only after
all inbound triggers have occurred.
Swimlanes (using a swimming pool analogy) allow you to vertically
partition an activity diagram so that the activities in each lane represent the
responsibilities of a particular class or department
Activity diagrams are helpful early in the modeling of a process to help you
understand the overall process. Useful when you want to show parallel
processes or for multithreaded programs.
Disadvantage of activity diagrams is that they do not make explicit which
objects execute which activities, and the way that the messaging works
between them.
However, activity diagrams should not take the place of interaction diagrams and
state diagrams. Activity diagrams do not give detail about how objects behave or
how objects collaborate.
Activity diagrams show the flow of activities through the system. Diagrams are
read from top to bottom and have branches and forks to describe conditions and
parallel activities. A fork is used when multiple activities are occurring at the same
time. The diagram below shows a fork after activity1. This indicates that both
activity2 and activity3 are occurring at the same time. After activity2 there is a
branch. The branch describes what activities will take place based on a set of
conditions. All branches at some point are followed by a merge to indicate the end
of the conditional behavior started by that branch. After the merge all of the
51
parallel activities must be combined by a join before transitioning into the final
activity state.
Swimlane diagram
Below is a possible activity diagram for processing an order. The diagram shows
the flow of actions in the system's workflow. Once the order is received the
activities split into two parallel sets of activities. One side fills and sends the order
while the other handles the billing. On the Fill Order side, the method of delivery
is decided conditionally. Depending on the condition either the Overnight
52
Delivery activity or the Regular Delivery activity is performed. Finally the parallel
activities combine to close the order.
53
Types of physical diagrams
Many times the deployment and component diagrams are combined into one
physical diagram. A combined deployment and component diagram combines the
features of both diagrams into one diagram.
54
The component diagram contains components and dependencies.
Components represent the physical packaging of a module of code. The
dependencies between the components show how changes made to one component
may affect the other components in the system. Dependencies in a component
diagram are represented by a dashed line between two or more components.
Component diagrams can also show the interfaces used by the components to
communicate to each other. 1
The combined deployment and component diagram below gives a high level
physical description of the completed system. The diagram shows two nodes
which represent two machines communicating through TCP/IP. Component2 is
dependant on component1, so changes to component 2 could affect component1.
The diagram also depicts component3 interfacing with component1. This diagram
gives the reader a quick overall view of the entire system.
55
Patterns
A pattern is instructive information that captures the essential structure and insight
of a successful family of proven solutions to a recurring problem that arises within
a certain context and system of forces.
56
It is a proven concept.
Patterns capture solutions with a track record, not theories or speculation.
The solution is not obvious.
The best patterns generate a solution to a problem indirectlya necessary
approach for the most difficult problems of design.
It describes a relationship.
Patterns do not just describe modules, but describe deeper system structures
and mechanisms.
The pattern has a significant human component.
All software serves human comfort or quality of life; the best patterns
explicitly appeal to aesthetics and utility.
Generative Patterns:
Patterns that suggest the way of finding the solution
Patterns template
There are different pattern templates are available which will represent a
pattern. It is generally agreed that a pattern should contain certain following
components
57
Known uses The known occurrences of the pattern and its application
within existing systems.
Anti patterns
A pattern represents a best practice whereas an anti pattern represents worst
practice or a lesson learned.
Capturing Patterns
Guidelines for capturing patterns:
Focus on practicability.
Aggressive disregard of originality.
Nonanonymous review.
Writers' workshops instead of presentations.
Careful editing.
Frameworks:
Frameworks are the way of delivering application development patterns to
support/share best development practice during application development.
Framework groups a set of classes which are either concrete or abstract. This
group can be sub classed in to a particular application and recomposing the
necessary items..
Design patterns are instructive information; hence they are less in space
where Frameworks are large in size because they contain many design
patterns.
58
Frameworks are more particular about the application domain where design
patterns are less specified about the application domain.
Conclusion
References
Modeling Tools
Rational Rose http://www.rational.com/
TogetherJ http://www.togetherj.com/
Web Sites
http://www.holub.com/ UML Quick Reference guide
http://www.ambysoft.com/ Whitepapers on a variety of UML-related topics
www.softdocwiz.com/UML.html UML Dictionary which is a supplement to Fowler's UML
Distilled book
www.navision.com/default.asp?url=/services/methodology/default.asp UML
templates for Visio
Books
Muller, Instant UML
Fowler and Scott, UML Distilled ,
Eriksson and Pensker, UML Toolkit
Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide
UML Notation Guide, Version 1.1
Coad, North, and Mayfield, Object Models: Strategies, Patterns, and Applications
59
Coad and Mayfield, Java Design: Building Better Apps and Applets
SUMMARY
KEY TERMS
Model
Static model
Dynamic model
UML Class diagrams
UML Use case diagrams
UML Sequence diagrams
UML Collaboration diagrams
UML State chart diagrams
UML Activity diagrams
UML Component diagrams
UML Deployment diagrams
60
KEY TERM QUIZ
1. A model is an abstract representation of a system, constructed to understand
the system prior to building or modifying it.
2. Static model can be viewed as a snapshot of a systems parameters at rest or
a specific point in time.
3. Dynamic model can be viewed as a collection of procedures or behaviors
that take together reflect the behavior of a system over time.
4. The unified modeling language (UML) is a language for specifying
constructing, visualizing and documenting the software system and its
components.
5. Class diagrams are the backbone of almost every object oriented method,
including UML. They describe the static structure of a system.
6. Package diagrams are a subset of class diagrams, but developers sometimes
treat them as a separate technique. Package diagrams organize elements of a
system into related groups to minimize dependencies between packages.
7. Object diagrams describe the static structure of a system at a particular
time. They can be used to test class diagrams for accuracy.
8. Use case diagrams model the functionality of system using actors and use
cases.
9. Sequence diagrams describe interactions among classes in terms of an
exchange of messages over time.
10. Collaboration diagrams represent interactions between objects as a series
of sequenced messages. Collaboration diagrams describe both the static
structure and the dynamic behavior of a system.
11. Statechart diagrams describe the dynamic behavior of a system in response
to external stimuli.
12. Statechart diagrams are especially useful in modeling reactive objects
whose states are triggered by specific events.
13. Activity diagrams illustrate the dynamic nature of a system by modeling the
flow of control from activity to activity. An activity represents an operation
on some class in the system that results in a change in the state of the
system. Typically, activity diagrams are used to model workflow or business
processes and internal operation.
14. Component diagrams describe the organization of physical software
components, including source code, run-time (binary) code, and executables.
15. Deployment diagrams depict the physical resources in a system, including
nodes, components, and connections.
61
MULTIPLE CHOICE
1. A model is an abstract representation of a system, constructed to understand
the system prior to building or modifying it.
(a) model (b) static model (c) dynamic model
2. Static model can be viewed as a snapshot of a systems parameters at rest or
a specific point in time.
(a) model (b) static model (c) dynamic model
3. Dynamic model can be viewed as a collection of procedures or behaviors
that take together reflect the behavior of a system over time.
(a) model (b) static model (c) dynamic model
4. The unified modeling language (UML) is a language for specifying
constructing, visualizing and documenting the software system and its
components.
(a) UML (b) static model (c) dynamic model
5. Class diagrams are the backbone of almost every object oriented method,
including UML. They describe the static structure of a system.
(a) Class diagrams (b) Package diagrams (c) Object diagrams
6. Package diagrams are a subset of class diagrams, but developers sometimes
treat them as a separate technique. Package diagrams organize elements of a
system into related groups to minimize dependencies between packages.
a) Class diagrams (b) Package diagrams (c) Object diagrams
7. Object diagrams describe the static structure of a system at a particular
time. They can be used to test class diagrams for accuracy.
a) Class diagrams (b) Package diagrams (c) Object diagrams
8. Use case diagrams model the functionality of system using actors and use
cases.
a) use case diagrams (b) collaboration diagrams (c) sequence diagrams
9. Sequence diagrams describe interactions among classes in terms of an
exchange of messages over time.
a) use case diagrams (b) collaboration diagrams (c) sequence diagrams
10. Collaboration diagrams represent interactions between objects as a series
of sequenced messages.
a) use case diagrams (b) collaboration diagrams (c) sequence diagrams
11. Statechart diagrams describe the dynamic behavior of a system in response
to external stimuli.
a) state chart diagrams (b) activity diagrams (c) component diagrams
12. Statechart diagrams are especially useful in modeling reactive objects
whose states are triggered by specific events.
a) state chart diagrams (b) activity diagrams (c) component diagrams
62
13. Activity diagrams illustrate the dynamic nature of a system by modeling the
flow of control from activity to activity. An activity represents an operation
on some class in the system that results in a change in the state of the
system. Typically, activity diagrams are used to model workflow or business
processes and internal operation.
a) state chart diagrams (b) activity diagrams (c) component diagrams
14. Component diagrams describe the organization of physical software
components, including source code, run-time (binary) code, and executables.
a) state chart diagrams (b) activity diagrams (c) component diagrams
15. Deployment diagrams depict the physical resources in a system, including
nodes, components, and connections.
a) state chart diagrams (b) deployment diagrams (c) component diagrams
REVIEW QUESTIONS:
63
19. Why do we go in for modeling? (Pg 91)
20. Give the benefits of modeling (Pg 91)
21. List out the advantages of modeling (Pg 92)
22. List out the goals in the design of UML (Pg 93)
23. Name the UML diagrams (Pg 93)
24. What is the significance of sequence diagram? (Pg 106)
25. What is a swimlane? (Pg 111)
26. What are implementation diagrams? (Pg 111)
27. Differentiate between component and deployment diagrams
a. (Pg 112-113)
28. What is a package? (Pg 114)
29. What is model dependency? (Pg 115)
30. What is a note? (Pg 117)
31. What is a stereotype? (Pg 117)
Reference :
64