CHAPTER THREE

PART II

An overview of UML
 What is UML?
 The Unified Modeling Language (UML) is a standard graphical
language for modeling software systems. It is also used to model
non-software systems as well. For example, the process flow in a
manufacturing unit.
 developed in the mid-1990s by James Rumbaugh, Grady Booch and
Ivar Jacobson.
 UML is a pictorial language used to make software blueprints.
 UML described as a general purpose visual modeling language to
visualize, specify, construct, and document software system.
 UML is not a programming language but tools can be used to
generate code in various languages using UML diagrams. UML
has a direct relation with object oriented analysis and design,
 Modeling with UML

 Notation enable us to articulate complex ideas concisely and

accurately.
 Software development project involve many participants,
usually those participants have different technically and cultural
backgrounds, accuracy and clarity are critical as the cost of
miscommunication increases rapidly.
 Notation must come with a well-defined semantics, it must be
well suited for representing a given aspect of a system, and it
must be well understood among project participants.
 when a standardized notation is used by a large number of
participants, there is little room for misinterpretation and
ambiguity.
 Systems, Models, and Views
 A system is an organized set of communicating parts. Ex. a car
system, watch system, student registration system, payroll
system…

 Modeling is a means for dealing with the complexity.

 Modeling means constructing an abstraction of a system that
focuses on interesting aspects and ignores irrelevant details,
What is interesting or irrelevant varies with the task at hand.
 … Cont’d
 System development focuses on three different models of the
system:-
1. The functional model: represented in UML with use case diagrams,
describes the functionality of the system from the user’s point of view.
2. The object model: represented in UML with class diagrams, describes
the structure of the system in terms of objects, attributes, associations,
and operations.
3. The dynamic model, represented in UML with interaction diagrams,
state machine diagrams, and activity diagrams, describes the internal
behavior of the system.

 A view focuses on a subset of a model to make it

understandable.
 Where Can the UML Be Used?

❖ A UML diagram is typically used in software engineering and

other business processes where modeling is useful.
❖ There are two main ways UML diagrams are used as a part of
these processes:
✓ Forward design:- the modeling and design are all done before
coding the software application. Usually, forward design is
used to help developers better see the system they are trying
to create.
✓ Backward design:- the modeling is done after the code has
been written, and the UML diagrams act as documentation for
the workflow of the project. This can help developers see the
project development as it was, in reality, to improve in the
future.
 Building Blocks of the UML

 The building blocks of UML can be defined as the following:-

♯ Things
♯ Relationships
♯ Diagrams
 Things:- are the most important building blocks of UML. Things
can be :-
♯ Structural:- define the static part of the model. They represent the physical
and conceptual elements. Class, interface , collaboration, usecase, component,
and node.
♯ Behavioral:- consists of the dynamic parts of UML models.it includes
interaction and state machine.
 … Cont’d
♯ Grouping:- can be defined as a mechanism to group elements of a UML
model together. There is only one grouping thing available. e.g. package
♯ Annotational:- a mechanism to capture remarks, descriptions, and
comments of UML model elements.
 Relationships:-shows how the elements are associated with each
other and this association describes the functionality of an
application. four kinds of relationships are available:-
♯ Dependency:- is a relationship between two things in which change in one
element also affects the other.
♯ Association:- is basically a set of links that connects the elements of a UML
model. It also describes how many objects are taking part in that
relationship.
 … Cont’d
♯ Generalization:-a relationship which connects a specialized element with a
generalized element. It basically describes the inheritance relationship in the
world of objects.
♯ Realization:- a relationship in which two elements are connected. One
element describes some responsibility, which is not implemented and the
other one implements them. This relationship exists in case of interfaces.

 Diagrams:- are the ultimate output of the entire discussion. All

the elements, relationships are used to make a complete UML
diagram and the diagram represents a system.
 Diagrams in UML

 UML contains a variety of diagram types, including:

 Use case diagrams, describes the functionality of the system.
 Class diagrams, which describe classes and their relationships.
 Interaction diagrams, which show the behavior of systems in terms
of how objects interact with each other. Two types of interaction
diagrams: sequence diagrams and communication diagrams.
 State diagrams and activity diagrams, which show how systems
behave.
 Component and deployment diagrams, which show how the various
components of systems are arranged logically and physically.
 UML Use Case Diagram
 Use cases are used during requirements elicitation and analysis
to represent the functionality of the system.
 A Use cases describe the function of the system as seen from an
actor’s point of view.
 The identification of actors and use cases results in the
definition of the boundary of the system.
 The actors are outside the boundary of the system, whereas the
use cases are inside the boundary of the system.
 When we are planning to draw a use case diagram, we should
have the following items identified:-
➢ Use case: Functionalities of the system
➢ Actors
➢ Relationships among the use cases and actors.
USE CASES
 A use case is a specific way of using the system by
performing some part of the functionality.

 A use case describes what a system does; not how.

 List the discrete business functions in your problem
statement - potential use case.
 A use case is shown as an ellipse in a use case
diagram
Perform Medical
Make Appointment
Tests
 Actor
 An actor define roles that users can play.
 Actors model anything that needs to exchange
information with the system
 The different roles the actor represents are the
actual business roles of users in a given system.
 An actor in a use case diagram interacts with a use
case.

13
 Actor …
 Actor classes have actors instances or objects that
represent specific actors.
 An actor is shown as a stick figure in a use case
diagram depicted "outside" the system boundary.
 To identify an actor, search in the problem
statement for business terms that describe roles in
the system.

Doctor Patient Student

14
 Example

 In an Accident Management System, field officers like

police officers or firefighters use wireless computers to
communicate with a dispatcher. The dispatcher can see
the status of all resources, like police cars or trucks, on
a computer screen and can send them out by giving
commands from a workstation.

 Actors: Dispatcher, field officer

 … Cont’d

Fig 4.1:An example of a UML use case diagram for First

Responder Interactive Emergency Navigational Database
(FRIEND), an accident management system.
Types of relation-ship in use case
diagram
 Use case diagrams can include four types of relationships:
communication, inclusion, extension, and inheritance.

 Communication relationships
✓ Actors and use cases communicate when information is
exchanged between them .

✓ Communication relationships are depicted by a solid

line between the actor and use case symbol.
 … Cont’d
 Include relationships
✓ Used When describing a complex system, its use
case model can become quite complex and can
contain redundancy.
✓ Reduce the complexity of the model by identifying
commonalities in different use cases.

✓ Two use cases are related by an include relationship

if one of them includes the second one in its flow of
events.
Are labelled with the <<include>> keyword (stereotype).
 … Cont’d

Figure 4.3 An example of an «include» relationship (UML use case diagram).

Figure 4.4 Textual representation of include relationships of figure 4.3

 … Cont’d
 Extend relationships
✓ Extend relationships are an alternate means for
reducing complexity in the use case model.
✓ A use case can extend another use case by adding events.

✓ An extend relationship indicates that an instance of an

extended use case may include (under certain
conditions) the behavior, specified by the extending use
case.
Is labelled with the <<extend>> keyword (stereotype), and
 … Cont’d

Figure 4.5 An example of an «extend» relationship (UML use case diagram).

Figure 4.6 Textual representation of extend relationships of figure 4.5

 … Cont’d
 Inheritance relationships
✓ It is a third mechanism for reducing the complexity of
a model.
✓ One use case can specialize another more general one
by adding more detail.

Figure 4.7 An example of an inheritance relationship (UML use case diagram).

 … Cont’d

Figure 4.8 Textual representation of inheritance relationships of Figure 4.7

 Scenarios
 A scenario is an instance of a use case describing a concrete set
of actions.
 It used to describe all possible cases; their focus is on
completeness.
 It’s majorly described using three fields.
1. Name of the scenario: Enables us to refer to it unambiguously. The
name of a scenario is underlined to indicate that it is an instance.
2. The participating actor instances field: Indicates which actor
instances are involved in this scenario. Actor instances also have
underlined names.
3. The flow of events: of a scenario describes the sequence of events step
by step.
 HINTS AND TIPS: For developing use cases

 On-line Bookstore is a web application that can be

accessed by the store’s registered customer, whereby each
customer can order books, review one or more books sold
in the book store, and sell used books to other customers.
Before performing any one of these transactions, the
customer must first log-in into the system using their user id
and password kept in their account. The customer can also
take a book he/she ordered.
 Problems:
 Develop a use case model(system use case)-Provide your reason
to pick “one” as a component of your model
 Document one of the use cases you have identified “sell used
book
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out

Customer Order books

<<include>>

<<include>>
Sell used Log-in
books
<<include>>

Review books

26
 Practice
 Assume online Student registration system was developed for
OBU University. By using this system; students could register
for courses and view their status, the teachers can insert, update
and delete students result. But, to inter the result, teachers
must get information from the administrator (Registrar),
because students must registered by Administrator before they
enter into the university. However, to access the system all of
them must have an account. Students and teachers account were
managed (created, modified and deleted) by Administrator. To
have an access to the system all of them must insert their
username and password on the login form.
◼ From this description list actors, use cases and draw a use
case diagram by using appropriate type of relationship.
UML Class Diagram
Class
Attribute
Operation/ method
Association / relationship
 UML Class Diagram

 Class diagrams are used to describe the structure of the system.

 Classes are abstractions that specify the common structure and
behavior of a set of objects.
 Objects are instances of classes that are created, modified, and
destroyed during the execution of the system.
 An object has state that includes the values of its attributes and its
links with other objects.
 Class diagrams describe the system in terms of objects, classes,
attributes, operations, and their associations.
 It is he most important tools for both requirements analysis and
design of object-oriented software systems.
 … Cont’d

 UML class diagrams show the classes of a system, their

interrelationships, and the operations and attributes of the
classes.
 The main symbols shown on class diagrams are:
 Classes, which represent the types of data themselves.

 Associations, which show how instances of classes

reference instances of other classes.
 Attributes, which are simple data found in instances.

 Operations, which represent the functions performed by the

instances.
 Generalizations, which are used to arrange classes into
inheritance hierarchies.
 General Guidelines for UML class
diagram
 UML class diagrams are used for a variety of purposes:- from
understanding your requirements to describing your detailed
design.

 The general guidelines for class diagram are

 Identify Responsibilities on Domain Class Models
 Indicate Visibility Only on Design Models
 Be Consistent with Attribute Names and Types
 Model Association Classes on Analysis Diagrams
 Do Not Name Associations That Have Association Classes
 Center the Dashed Line of an Association Class
 … Cont’d

Modeling association
classes.
 Class Style Guidelines

 Use Common Terminology for Class Names

 Prefer Complete Singular Nouns for Class Names
 Name Operations with Strong Verbs
 Name Attributes with Domain-Based Nouns
 Do Not Model Scaffolding Code
 Center Class Names
 Left-Justify Attribute Operation and Names
 Do Not Model Keys
… Cont’d (UML Class Diagram)

OrderItem class with and without scaffolding code.

 Associations
 In UML, associations can be symmetrical (bidirectional) or
asymmetrical (unidirectional).
 Ex:

Example of Asymmetrical(Unidirectional) association

 An association without arrows indicates that navigation is

supported in both directions.
 … Cont’d
 In UML, an association end can have an arbitrary set of
integers as a multiplicity.
 Those integers indicate the number of links that can
legitimately originate from an instance of the class connected
to the association end.
 In practice, however, most of the associations we encounter
belong to one of the following three type:
❖ A one-to-one association: Ex: Police officer and badge
number
❖ A one-to-many association: Ex: Company and employee

❖ A many-to-many association: Ex: Field officer and

incident report
 Association Guidelines
 Center Names on Associations
 Write Concise Association Names in Active Voice
 Indicate Directionality to Clarify an Association Name
 Name Unidirectional Associations in the Same Direction
 Word Association Names Left to Right
 Indicate Role Names When Multiple Associations Between Two
Classes Exist
 Indicate Role Names on Recursive Associations
 Make Associations Bidirectional Only When Collaboration Occurs in
Both Directions
 … Cont’d

Each association can be labeled, to make explicit the nature of

the association. There are two types of labels, association
names and role names.
… Cont’d
 Aggregation
 Aggregations are special associations that represent ‘part–whole’
relationships.

 The ‘whole’ side of the relationship is often called the assembly or

the aggregate.

 Aggregations are specified using a diamond symbol, which is

placed next to the aggregate.

 Many aggregations are one-to-many, but this is not a requirement.

 … Cont’d
 As a general rule, an association can marked as an
aggregation if the following are true:
 When we can state that the parts ‘are part of ’ the
aggregate, or the aggregate ‘is composed of ’ the parts.

 When something owns or controls the aggregate, then

they also own or control the parts.
 … Cont’d
 Ex:
… Cont’d
 … Cont’d
 A composition is a strong kind of aggregation in which if the
aggregate is destroyed, then the parts are destroyed as well.

 A composition is shown using a solid (filled-in) diamond, as

opposed to an open one.
 Practice

 For each of the following associations, indicate whether it

should be an ordinary association, a standard aggregation, or a
composition. Give a justification for your answer.
(a) A telephone and its handset.
(b) A school and its teachers.
(c) A book and its chapters.
(d)An author and his/her book.
Class diagram for ATM
… Cont’d

Class diagram for ATM

 UML SEQUENCE
DIAGRAMS
Object
Interaction
Message
Lifeline
 UML Sequence Diagrams
 UML sequence diagrams are a dynamic (interaction) modeling.
 A sequence diagram shows the sequence of messages exchanged by the set of
objects performing a certain task.
 It shows objects as lifelines running down the page
 The interaction starts near the top of the diagram and ends at the bottom
Example: sequence diagram for login

.
 … Cont’d

 The objects are arranged from left to right across the diagram
 An actor that initiates the interaction is often shown on the left.
The vertical dimension represents time.

 The top of the diagram is the starting point, and time

progresses downwards towards the bottom of the diagram.
… Cont’d
ATM sequence diagram

library
 General Guidelines For Sequence
Diagram
 Strive for Left-to-Right Ordering of Messages
 Layer Object Lifelines
 Give an Actor the Same Name as a Class, If Necessary
 Place Proactive System Actors on the Leftmost Side of Your
Diagram
 Avoid Modeling Object Destruction
 Avoid Activation Boxes
 Name Objects Only When You Reference Them in Messages
 Name Objects When Several of the Same Type Exist
 Apply Textual Stereotypes to Lifelines Consistently
UML Communication Diagrams
 UML communication diagrams, formerly known as
collaboration diagrams, are used to explore the dynamic
nature of your software.
 Communication diagrams are often used to:-
✓ provide a bird’s-eye view of a collection of collaborating objects,
particularly within a real-time environment;
✓ provide an alternate view to UML sequence diagrams;
✓ allocate functionality to classes by exploring the behavioral aspects of a
system;
✓ model the logic of the implementation of a complex operation,
particularly one that interacts with a large number of other objects;
✓ explore the roles that objects take within a system, as well as the
different relationships in which they are involved when in those roles.
UML ACTIVITY
DIAGRAMS
 UML Activity Diagrams

 UML activity diagrams are the object-oriented equivalent of

flow charts and data-flow diagrams from structured
development.

 … Cont’d

 UML activity diagrams are used to explore the logic of

✓ a complex operation,
✓ a complex business rule,
✓ a single use case,
✓ several use cases,
✓ a business process,
✓ concurrent processes,
✓ software processes.
 … Cont’d

 UML activity diagrams symbol and description

 … Cont’d

 Initial node. The filled in circle is the starting point of the

diagram. An initial node isn't required although it does make it
significantly easier to read the diagram.

 Activity final node. The filled circle with a border is the

ending point. An activity diagram can have zero or more
activity final nodes.
 Activity. The rounded rectangles represent activities that
occur. An activity may be physical, such as Inspect Forms, or
electronic, such as Display Create Student Screen.
 Flow/edge. The arrows on the diagram.
 … Cont’d
 Fork. A black bar with one flow going into it and several
leaving it. This denotes the beginning of parallel activity.
 Join. A black bar with several flows entering it and one
leaving it. All flows going into the join must reach it before
processing may continue. This denotes the end of parallel
processing.
 Condition. Text such as [Incorrect Form] on a flow, defining a
guard which must evaluate to true in order to traverse the
node.
 Decision. A diamond with one flow entering and several
leaving. The flows leaving include conditions although some
modelers will not indicate the conditions if it is obvious.
 … Cont’d

 Merge. A diamond with several flows entering and one leaving.

The implication is that one or more incoming flows must reach
this point until processing continues, based on any guards on the
outgoing flow.
 Partition: also called swimlanes, indicating who/what is
performing the activities.
 Sub-activity indicator. The rake in the bottom corner of an
activity, indicates that the activity is described by a more finely
detailed activity diagram.
 Flow final. The circle with the X through it. This indicates that
the process stops at this point.
 Note. Used to make reader understandable .
… Cont’d
 … Cont’d

a UML Activity Diagram for Enrollment.

… Cont’d
 Class work
 Assume online Student registration system was developed for
OBU University. By using this system; students could register
for courses and view their status, the teachers can insert, update
and delete students result. But, to inter the result, teachers must
get information from the administrator (Registrar), because
students must registered by Administrator before they enter
into the university. However, to access the system all of them
must have an account. Students and teachers account were
managed (created, modified and deleted) by Administrator. To
enter into the system all of them must insert their username
and password on the login form.
◼ From this description select one use case and draw activity
diagram.
UML COMPONENT
DIAGRAMS
UML Component Diagrams

 UML component diagrams show the dependencies among

software components.
 Component diagrams show the organization and
dependencies among a group of components.
 We create them to
 model the low-level design configuration of your system,
 model the technical infrastructure
 model the business/domain architecture for the organization
UML Component Diagrams

Component diagrams comprise of:

 Components

 Interfaces

 Relationships

 Packages and Subsystems (optional)

 Basic Component Diagram Symbols and
Notations
Component A full circle represents
an interface created or
provided by the
component.
Interface A semi-circle represents
a required interface, like
a person's input.

Dependencies
Port is often used to
help expose required
and provided interfaces
Port of a component.
… Cont’d
UML DEPLOYMENT
DIAGRAMS
 UML Deployment Diagrams
 Deployment diagrams are used to visualize the topology of the
physical components of a system, where the software components
are deployed.
 Deployment diagrams are used to describe the static deployment
view of a system.
 These diagrams consist of nodes and their relationships.
 The purpose of deployment diagrams can be described as −
Visualize the hardware topology of a system.
Describe the hardware components used to deploy software
components.
Describe the runtime processing nodes.
 How to Draw a Deployment
Diagram?
 Before drawing a deployment diagram, the following artifacts
should be identified:-
 Nodes:-are nothing but physical hardware used to deploy the
application.
 Relationships among nodes
 Sample example of deployment diagram to provide an idea of the
deployment view of order management system. Here, we have
shown nodes as:-
√ Monitor
√ Modem
√ Caching server
√ Server
 … Cont’d

deployment diagram for an order management system

Any Question?
Software Engineering

Chapter Four
Software Project Management

By: Ketema D.
1
 Eyes break
 What is SPM? Is really different from ordinary
project management?

 How do you know when project has been successful?

For example do the expectation of the customer/
client match those of the developer?
 What are parameters that makes projects fail

2
Failure Statics of S/w project
✓ Satisfied customer

✓ Unsatisfied customer

3
Why S/W Project Fail

4
Software Project Management
 Concerned with activities involved in ensuring
that software is delivered on time and on schedule and in
accordance with the requirements of the organisations
developing and procuring the software.

 Project management is needed because software

development is always subject to budget and schedule
constraints that are set by the organisation developing the
software.

5
Cont..
Tips:
SPM is Concerned with activities involved in ensuring
that software is delivered:
 On time
 Within budget
 Meets standards
 In accordance with requirements
 According to the planned timeline

6
 The Four P’s in Management
 People — the most important element of a
successful project
 Product — the software to be built
 Process — the set of framework activities and
software engineering tasks to get the job done
 Project — all work required to make the
product a reality

7
 4 P’s : People
❖ This is virtually any type of stakeholder who is involved in the project
❖ People are the primary resource on every project.
❖ A well-managed team can greatly increase the chances for success
❖ Project stakeholders can include for example:
 Project manager
 Project administrator
 Project team members
 Executive management of the company
 Clients/customers/end users
 Suppliers and outsourced labor
 Sponsors and investors
 Business analysts
 IT professionals

8
 4 P’s : Product
❖ It is simply whatever represents the goal of the
project.

❖The resources, materials, quality, and everything

else that defines the development of the project
belong to the P of product

9
 4 P’s : Process
❖Is the process the team will follow in order to produce
the product.
❖This involves the exact tasks and activities that need to
be completed,
Project
❖It can also be considered as a blueprint of process.
❖In this phase, the project manager plays a critical
role to guide the team members

10
Activities in software project management
1) Project Planning
2) Project Scheduling
3) Risk Management
4) Managing people

11
1. Project Planning
 The biggest single problem that afflicts software
developing is that of underestimating resources
required for a project.
 Developing a realistic project plan is essential to gain
an understanding of the resources required, and how
these should be applied.

12
1.1 Types of plan:
 Software development plan.
 The central plan, which describes how the system will be
developed.
 Quality assurance plan.
 Specifies the quality procedures & standards to be used.
 Validation plan.
 Defines how a client will validate the system that has
been developed.

13
Cont.
 Configuration management plan.
 Defines how the system will be configured and installed.
 Maintenance plan.
 Defines how the system will be maintained.
 Staff development plan.
 Describes how the skills of the participants will be
developed.

14
2.Project scheduling
❖Split project into tasks, estimate time and resources
required to complete each task.
❖Organize tasks concurrently to make optimal
use of workforce.
❖Minimize task dependencies to avoid delays caused by
one task waiting for another to complete.

15
2.1 The project scheduling process

16
2.2 Scheduling problems
 It's tough to guess how hard problems are and how
much they'll cost to fix.
 More people doesn't mean more work gets done.
 Adding people to a late project just slows it down due
to extra communication.
 The unexpected always happens. Plan with extra time
just in case.

17
3. Risk management
 Risk management is concerned with identifying risks
and drawing up plans to minimise their effect on a
project.
 A risk is a probability that some adverse circumstance
will occur
 Project risks affect schedule or resources;
 Product risks affect the quality or performance of the
software being developed;
 Business risks affect the organisation developing or
procuring the software.

18
3.2 The risk management process
 Risk identification
 Identify project, product and business risks;
 Risk analysis
 Assess the likelihood and consequences of these risks;
 Risk planning
 Draw up plans to avoid or minimise the effects of the
risk;
 Risk monitoring
 Monitor the risks throughout the project;

19
3.3.1 Risk identification
 Technology risks.
 People risks.
 Organisational risks.
 Requirements risks.
 Estimation risks.

20
3.3.2 Risk analysis
 Assess probability and seriousness of each risk.
 Probability may be very low, low, moderate, high or
very high.
 Risk effects might be catastrophic, serious, tolerable or
insignificant.

21
3.3.3 Risk planning
 Consider each risk and develop a strategy to manage
that risk.
 Avoidance strategies
 The probability that the risk will arise is reduced;
 Minimisation strategies
 The impact of the risk on the project or product will be
reduced in case it occured
 Contingency plans
 If the risk arises, contingency plans are plans to deal
with that risk;

22
3.3.3 Risk Monitoring
 continually monitoring or tracking any changes in
their likelihood or impact of risk

 This means keeping an eye out for signs of risks and

seeing if planned risk management strategies are
effective.

23
Rise above challenges, conquer your goals

24
Chapter 5
Analysis
 An Overview of Analysis
 Analysis results in a model of the system that aims to be correct,
complete, consistent, and unambiguous.

 Developers formalize the requirements specification produced

during requirements elicitation and examine in more detail boundary
conditions and exceptional cases.
 Developers validate, correct and clarify the requirements
specification if any errors or ambiguities are found.

 The client and the user are usually involved in this activity when
the requirements specification must be changed and when additional
information must be gathered.
 …Cont’d
 The analysis workflow of the Unified Process has two overall
aims.
 From the viewpoint of the requirements workflow (the preceding
workflow), the aim of the analysis workflow is to obtain a deeper
understanding of the requirements.
 From the viewpoint of the design and implementation workflows
(the workflows that follow the analysis workflow), the aim of the
analysis workflow is to describe those requirements in such a
way that the resulting design and implementation are easy to
maintain.
 …Cont’d
 Analysis focuses on producing a model of the system, called the
analysis model, which is correct, complete, consistent, and
verifiable.
 Analysis is different from requirements elicitation in that developers
focus on structuring and formalizing the requirements elicited from
users.
 The analysis model is composed of three individual models:
 the functional model, represented by use cases and scenarios,

 the analysis object model, represented by class and object

diagrams, and
 the dynamic model, represented by state machine and sequence
diagrams.
 …Cont’d

Products of requirements elicitation and analysis (UML activity diagram).

 Analysis Concepts
 The following are the main analysis concept we will discussed in
this chapter:-

 Analysis Object Models and Dynamic Models

 Entity, Boundary, and Control Objects

 Generalization and Specialization.

Analysis Object Models and
Dynamic Models
 …Cont’d

 Analysis object model is a part of the analysis model and focuses

on the individual concepts that are manipulated by the system, their
properties and their relationships.
 Depicted with UML class diagrams, includes classes, attributes, and
operations.
 Is a visual dictionary of the main concepts visible to the user.
 The dynamic model focuses on the behavior of the system. The
dynamic model is depicted with sequence diagrams and with state
machines.
 Sequence diagrams represent the interactions among a set of
objects during a single use case.
 …Cont’d

 State machines represent the behavior of a single object (or a

group of very tightly coupled objects).
 The dynamic model serves to assign responsibilities to individual
classes and, in the process, to identify new classes, associations,
and attributes to be added to the analysis object model.
 Both models represent user-level concepts, not actual software classes or
components.
 For example, classes such as Database, Subsystem, SessionManager,
Network should not appear in the analysis model as the user is
completely shielded from those concept.
 Entity, Boundary, and Control
Objects

 The analysis object model consists of entity, boundary, and

control objects.
 Entity objects represent the persistent information tracked by
the system.
 Boundary objects represent the interactions between the actors
and the system.
 Control objects are in charge of realizing use cases.
 Generalization and
Specialization

 Inheritance enables us to organize concepts into hierarchies.

 At the top of the hierarchy there is a general concept , and at
the bottom of the hierarchy there are the most specialized
concepts.
 Analysis Activities: From Use Cases to
Objects
 The following are the activities that transform the use cases and
scenarios produced during requirements elicitation into an analysis
model. Generally analysis activities include:
Identifying Entity Objects
Identifying Boundary Objects
Identifying Control Objects
Mapping Use Cases to Objects with Sequence Diagrams
Modeling Interactions among Objects with CRC Cards
Identifying Associations
Identifying Aggregates
Identifying Attributes
Modeling State-Dependent Behavior of Individual Objects
Modeling Inheritance Relationships
Reviewing the Analysis Mode
 Identifying Entity Objects
 Noun extraction / natural language analysis
 found by examining each use case and identifying candidate objects.
Using natural language analysis
 Pioneered by Russell Abbott (1983), popularized by Grady Booch
 Not perfect, but coupled with other techniques, it's a good start
 This can be done from a general problem description, or better,
from a use case or scenario
 Map parts of speech to object model components.
 nouns usually map to classes, objects, or attributes

 verbs usually map to operations or associations

…Cont’d
 …Cont’d

 Heuristics for identifying entity objects

• Terms that developers or users need to clarify in order to understand the use
case
• Recurring nouns in the use cases
• Real-world entities that the system needs to track
• Real-world activities that the system needs to track
• Data sources or sinks
 Identifying Boundary Objects

 Heuristics for identifying boundary objects

✓ Identify user interface controls that the user needs to initiate the use case (e.g.,
Report Emergency Button).
✓ Identify forms the users needs to enter data into the system (e.g.,
Emergency Report Form).
✓ Identify notices and messages the system uses to respond to the user (e.g.,
Acknowledgment Notice)
✓ When multiple actors are involved in a use case, identify actor terminals
(e.g., Dispatcher Station) to refer to the user interface under consideration.
✓ Do not model the visual aspects of the interface with boundary objects.

✓ Always use the end user’s terms for describing interfaces; do not use terms
from the solution or implementation domains.
 Identifying Control Objects
✓ Heuristics for identifying control objects:-
 Identify one control object per use case.

 Identify one control object per actor in the use case.

 The life span of a control object should cover the extent of

the use case or the extent of a user session. If it is difficult to
identify the beginning and the end of a control object
activation, the corresponding use case probably does not have
well-defined entry and exit conditions.

➢ Ex: report emergency control and manage emergency control.

 Mapping Use Cases to Objects with
Sequence Diagrams

 A sequence diagram ties use cases with objects.

 It shows how the behavior of a use case (or scenario) is
distributed among its participating objects.
 Sequence diagrams are usually not as good a medium for
communication with the user as use cases are, since sequence
diagrams require more background about the notation.

 Sequence diagrams represent another shift in perspective and

allow the developers to find missing objects or grey areas in the
requirements specification.
 …Cont’d

 Heuristics for drawing sequence diagrams

 The first column should correspond to the actor who initiated the use case.

 The second column should be a boundary object (that the actor used to
initiate the use case).
 The third column should be the control object that manages the rest of the
use case.
 Control objects are created by boundary objects initiating use cases.

 Boundary objects are created by control objects.

 Entity objects are accessed by control and boundary objects.

 Entity objects never access boundary or control objects; this makes it easier
to share entity objects across use cases
 Modeling Interactions among
Objects with CRC Cards
 A class responsibility collaborator model is a collection of
standard index cards that have been divided into three sections.
 A class represents a collection of similar objects, a
responsibility is something that a class knows or does, and a
collaborator is another class that a class interacts with to fulfill its
responsibilities.
 For each class, the software development team fills in a card
showing the name of the class, its functionality
(responsibility), and a list of the other classes it invokes to
achieve that functionality (collaboration).
Introduction to CRC

Example CRC card

 …Cont’d

CRC cards model for Process new order use case

 …Cont’d

Examples of CRC cards for the ReportEmergencyControl and

the Incident classes.
 …Cont’d

 CRC models are an incredibly effective tool for conceptual

modeling as well as for detailed design.
 The strength of CRC cards is that, when utilized by a team, the
interaction among the members can highlight missing or incorrect
fields in a class, whether attributes or methods.
 Also, the relationships between classes are clarified when CRC
cards are used.
 One especially powerful technique is to distribute the cards among
the team members, who then act out the responsibilities of their
classes.
 …Cont’d
 A weakness of CRC cards is that this approach generally is not a
good way of identifying entity classes unless the team members
have considerable experience in the relevant application domain.
 On the other hand, once the developers have determined many of
the classes and have a good idea of their responsibilities and
collaborations, CRC cards can be an excellent way of completing
the process and making sure that everything is correct.
 So how do you create CRC models? Iteratively perform the
following steps:
◼ Find classes
◼ Find responsibilities.
◼ Define collaborators.
◼ Move the cards around.
 …Cont’d
 CRC cards and sequence diagrams are two different
representations for supporting the same type of activity.
 Sequence diagrams are a better tool for a single modeler or for
documenting a sequence of interactions, because they are more
precise and compact.
 CRC cards are a better tool for a group of developers refining
and iterating over an object structure during a brainstorming
session, because they are easier to create and to modify.
 Identifying Associations

➢ class diagrams allow developers to describe the interdependencies

of objects.
➢ An association shows a relationship between two or more classes.
➢ Identifying associations has two advantages.
✓ First, it clarifies the analysis model by making relationships between objects
explicit.
✓ Second, it enables the developer to discover boundary cases associated with
links. Boundary cases are exceptions that must be clarified in the model.
➢ Name, role and multiplicity are properties of association.
➢ Initially, the associations between entity objects are the most
important, as they reveal more information about the application
domain.
 …Cont’d
 associations can be identified by examining verbs and verb phrases
denoting a state.
(e.g., has, is part of, manages, reports to, is triggered by, is contained in, talks to,
includes).
 Every association should be named, and roles should be assigned to
each end.
 Identifying Aggregates
 Aggregations are special types of associations denoting a whole–
part relationship.
 A State is composed of a number of Counties that are, in turn,
composed of a number of Townships.
 An aggregation is shown as an association with a diamond on the side
of the whole part.
 A composition aggregation indicates that the existence of the parts
depends on the whole.
 For example, a County is always part of exactly one State, a
Township is always part of a County.
 Identifying Attributes

 Attributes are properties of individual objects.

 When identifying properties of objects, only the attributes relevant
to the system should be considered.
 Developers should identify as many associations as possible before
identifying attributes to avoid confusing attributes and objects.
 Attributes have a name and type.
 Often, attributes are discovered or added late in the development
when the system is evaluated by the users. Unless the added
attributes are associated with additional functionality, the added
attributes do not entail major changes in the object (and system)
structure.
 …Cont’d

➢ Heuristics for identifying attributes

• Examine possessive phrases.
• Represent stored state as an attribute of the entity object.
• Describe each attribute.
• Do not represent an attribute as an object; use an association
instead.
• Do not waste time describing fine details.
 Modeling State-Dependent Behavior of
Individual Objects

 Sequence diagrams are used to distribute behavior across objects

and to identify operations.
 It represent the behavior of the system from the perspective of a
single use case.
 State machine diagrams represent behavior from the
perspective of a single object.
 Viewing behavior from the perspective of each object enables the
developer to build a more formal description of the behavior of
the object, and consequently, to identify missing use cases.
 Modeling Inheritance Relationships between
Objects

 Generalization is used to eliminate redundancy from the analysis

model.
 If two or more classes share attributes or behavior, the similarities
are consolidated into a superclass.
 Reviewing the Analysis Model

❖ The analysis model is built incrementally and iteratively.

❖ The analysis model is not often correct or even complete on the first
pass.
❖ Several iterations with the client and the user are necessary before the
analysis model converges toward a correct specification usable by the
developers for design and implementation.
❖ Once the number of changes to the model are minimal and the
scope of the changes localized, the analysis model becomes stable.
❖ Then the analysis model is reviewed, first by the developers (i.e.,
internal reviews), then jointly by the developers and the client.
❖ The goal of the review is to make sure that the requirements
specification is correct, complete, consistent, and unambiguous.
 …Cont’d
❖ The following questions should be asked to ensure that the model
is correct:
♯ Is the glossary of entity objects understandable by the user?

♯ Do abstract classes correspond to user-level concepts?

♯ Are all descriptions in accordance with the users’ definitions?

♯ Do all entity and boundary objects have meaningful noun phrases as

names?
♯ Do all use cases and control objects have meaningful verb phrases as
names?
♯ Are all error cases described and handled?
 …Cont’d
❖ The following questions should be asked to ensure that the model
is complete:
For each object: Is it needed by any use case? In which use case is it created?
modified? destroyed? Can it be accessed from a boundary object?
For each attribute: When is it set? What is its type? Should it be a qualifier
For each association: When is it traversed? Why was the specific multiplicity
chosen? Can associations with one-to-many and many-to-many multiplicities
be qualified?
For each control object: Does it have the necessary associations to access the
objects participating in its corresponding use case?
 …Cont’d
❖ The following questions should be asked to ensure that the model
is consistent:
Are there multiple classes or use cases with the same name?
Do entities (e.g., use cases, classes, attributes) with similar names denote
similar concepts?
Are there objects with similar attributes and associations that are not in
the same generalization hierarchy
Analysis Summary