Unit-4

OBJECT ORIENTED DESIGN WORKFLOW

SYLLABUS:

Design workflow-format of the attributes- allocation of operations- Osbert Oglesby case study-
Workflows of the unified process-Phases of the unified process- class diagrams-Use case
diagrams- Interaction diagrams-state charts-package diagrams-Deployment diagrams.

4.1 DESIGN WORKFLOW

 The input to the design workflow is the set of analysis workflow artifacts
– These artifacts are iterated and incremented until they can be used by the
programmers
 A major aspect of this iteration and incrementation is
– The identification of operations, and
– Their allocation to the appropriate classes
 Many other decisions have to be made as part of the design workflow, including
– Choice of programming language
– Deciding how much of existing information systems to reuse in the new
information system
– Level of portability
– The allocation of each software component to its hardware component
 The case studies in this book are small-scale information systems
– Under 5,000 lines of Java or C++ code in length
 The Unified Process was designed for developing large-scale information systems
– 500,000 lines of code or more
 During the analysis workflow, a large information system is partitioned into analysis
packages
– Each analysis package consists of a set of related classes that can be implemented
as a single unit
– Example:
o Accounts payable, accounts receivable, and general ledger are typical
analysis packages
 The concept underlying analysis packages is:
– It is easier to develop smaller information systems than larger information
systems
– A large information system will be easier to develop if it can be decomposed into
independent packages
 The idea of decomposing a large workflow into independent smaller workflows is carried
forward to the design workflow
 The objective is to break up the upcoming implementation workflow into manageable
pieces
– Subsystems

1
  It does not make sense to break up the two case studies into subsystems—they are just
too small
 Reasons why subsystems are utilized
– It is easier to implement a number of smaller subsystems than one large system
– If the subsystems are independent, they can be implemented by programming
teams working in parallel
o The information system as a whole can then be delivered sooner
 The architecture of an information system includes
– The various component modules
– How they fit together
– The allocation of components to subsystems
 The task of designing the architecture is specialized
– It is performed by an information system architect
 The architect needs to make trade-offs
– Every information system must satisfy its functional requirements (the use cases)
– It also must satisfy its nonfunctional requirements, including
o Portability, reliability, robustness, maintainability, and security
– It must do all these things within budget and within the time constraint
 The architect must assist the client by laying out the trade-offs
 It is usually impossible to satisfy all the requirements, functional and nonfunctional,
within the cost and time constraints
– Some sort of compromises have to be made
 The client has to
– Relax some of the requirements;
– Increase the budget; and/or
– Move the delivery deadline
 The architecture of an information system is critical
– The requirements workflow can be fixed during the analysis workflow
– The analysis workflow can be fixed during the design workflow
– The design workflow can be fixed during the implementation workflow
 But there is no way to recover from suboptimal architecture
– The architecture must immediately be redesigned

4.2 FORMAT OF THE ATTRIBUTES

 As part of the design workflow, the exact format of each attribute of the class diagram
must be specified
– Example: A date is usually represented by 10 characters
– For instance, December 3, 1947 is represented as
o 12/03/1947 in the United States (MM/DD/YYYY format), and
o 03/12/1947 in Europe (DD/MM/YYYY format)
– For both date conventions, 10 characters are needed

 The formats could be determined during the analysis workflow

 However, the object-oriented paradigm is iterative
– Information is added to models as late as possible

2
 Adding an item too early will make the next iteration unnecessarily burdensome
– Formats are therefore added during the design workflow

 Examples:
– First name of an artist is up to 20 characters in length, optionally followed by ? if
there is uncertainty
o firstNameOfArtist : 21 chars
– Title is up to 40 characters in length, optionally with ?
o title : 41 chars
– Height and width are measured in centimeters
o height, width : 4 digits (up to 9999 centimeters, or 99.99 meters)
– Prices
o targetSellingPrice, actualSellingPrice, maxPurchasePrice : 8 digits (up to
$99,999,999)
– Dates
o dateOfPurchase, dateOfSale, auctionDate : 10 chars
 Fashionability coefficient
– This could be a large number or a small number

3
  The range can be determined only by computing coefficients from a sample of Osbert’s
sales
– High: 985 (Rembrandt van Rijn)
– Low: 0.064 (Joey T. Dog)
 For safety, coefficient is of type 4 + 4 digits
 Range is
– High: 9999.9999
– Low: 0.0001
 Class diagram with the formats of attributes added

 Example:
– An asset number consists of 12 characters
o assetNumber : 12 digits
– Annual operating expenses are up to $999,999,999.99
o estimatedAnnualOperatingExpenses : 9 + 2 digits

4.3 ALLOCATION OF OPERATIONS

 First the initial class diagram is determined

– Then the interaction diagrams of the realizations of the use cases
 These interaction diagrams are used to deduce the operations

4
 – Only then can the operations be allocated to the classes
 Identifying the operations to be allocated to the various classes is easy
 Determining to which class each operation should be allocated is hard
 Three criteria are used
– Responsibility-driven design
– Inheritance
– Polymorphism and dynamic binding
 Third iteration of the initial MSG class diagram

4.3.1 RESPONSIBILITY-DRIVEN DESIGN

 The principle of responsibility-driven design

o If Class A sends a message to Class B telling it to do something, it is the
responsibility of Class B to perform the requested operation

 Responsibility-Driven Design: MSG Case Study

5
 The weekly return on investments is computed by summing the estimated annual return
of each investment and dividing by 52
– The sequence diagram includes the message
o 3: Request estimated return on investments for week
 The MSG Foundation case study must therefore include the operation
getAnnualReturnOnInvestment
– Thus, for each object of class Investment Class, the estimated annual return on
that investment can be determined
 It is not important which class sends that message
 What is important is that Investment Class has the responsibility of determining the
annual return on an investment
– Accordingly, operation getAnnualReturnOnInvestment must be allocated to
Investment Class
 Allocation of getAnnualReturnOnInvestment

6
4.3.2 INHERITANCE

 Suppose an operation is applicable to

– An instance of a superclass; and to
– Instances of subclasses of that superclass
 Allocate that operation to the superclass
 Then there is just one version of that operation
 It can be used by
– Instances of the superclass and by Instances of all its subclasses
 Convention in an object-oriented information system
– Associated with each attribute of a class are operations
o setAttribute, used to assign a particular value to that attribute; and
o getAttribute, which returns the current value of that attribute
 Example: In the MSG case study every asset has an asset number
– Asset Class has an attribute assetNumber
o Operation setAssetNumber is used to assign the number of the asset to the
object that represents that asset
o Operation getAssetNumber is used to obtain the asset number of the asset
represented by that object
 To which class should operation setAssetNumber be allocated?
 In the traditional paradigm, there would be two different versions of setAssetNumber,
one for each of the two types of asset
– That is, there would have to be
o setInvestmentNumber
o setMortgageNumber
 Two separate functions are needed because the traditional paradigm does not support
inheritance
 In the object-oriented paradigm
– Consider the MSG inheritance hierarchy

7
 Asset Class has attribute assetNumber
– Inherited by Investment Class and Mortgage Class
– Thus
o Every instance of class Investment Class, and
o Every instance of class Mortgage Class
has attribute assetNumber that consists of 12 characters
 Any operation of class Asset Class that could be applied to attribute assetNumber
– Can also be applied to attribute assetNumber of
o Every instance of class Investment Class, and
o Every instance of class Mortgage Class
 Allocation of setAssetNumber, getAssetNumber

 Operation setAssetNumber can then be applied to instances of

– Class Investment Class or
– Class Mortgage Class

 Allocation of Operations: Osbert Oglesby

– Fifth iteration of the initial class diagram

8
4.4 OSBERT OGLESBY CASE STUDY

4.4.1 RESPONSIBILITY-DRIVEN DESIGN: OSBERT OGLESBY CASE STUDY

– Consider operation getAuctionPrice

– Irrespective of the source of the message requesting an auction price
o Operation getAuctionPrice must be allocated to Auctioned Painting Class

– Allocation of getAuctionPrice

9
4.4.2 INHERITANCE: OSBERT OGLESBY CASE STUDY

 Consider operations
o setTitle and
o getTitle
 Example: Osbert prints a list of all his paintings
o Each object in the information system in turn is examined
o A message is sent to operation getTitle to obtain the title of the painting
represented by that object
 To which class must operations
o setTitle and
o getTitle
be allocated?
 First consider operation setTitle
 In the traditional paradigm, there would have to be three different versions of setTitle,
one for each type of painting
o set_masterpiece_title
o set_masterwork_title
o set_other_painting_title
 That is because the traditional paradigm does not support inheritance
 In the object-oriented paradigm, consider the Painting Class inheritance hierarchy
 Painting Class has attribute title
o This attribute is inherited by instances of its 5 subclasses
 Gallery Painting Class
 Auctioned Painting Class
 Masterpiece Class
 Masterwork Class
 Other Painting Class
 Thus, operation setTitle must be allocated to Painting Class so that it can be inherited
(and used) by instances of all five subclasses
 This applies to all operations, including getTitle
 Allocation of operations setTitle and getTitle

10
4.5 WORKFLOWS OF THE UNIFIED PROCESS

 There are five core workflows

– Requirements workflow
– Analysis workflow
– Design workflow
– Implementation workflow
– Test workflow
 In each increment, part of each of these five workflows is carried out

 In addition to the five core workflows, the Unified Process includes other workflows
– Management
– Planning

The Requirements Workflow

 The aim of the requirements workflow
– To ensure that the developers build the right information system
The analysis workflow
 The aim of the analysis workflow
– To analyze and refine the requirements
 Why not do this during the requirements workflow?
– The requirements artifacts must be totally comprehensible by the client
 The artifacts of the requirements workflow must therefore be expressed in a natural
(human) language
– All natural languages are imprecise
 Example from a manufacturing information system:
– “A part record and a plant record are read from the database. If it contains the
letter A directly followed by the letter Q, then calculate the cost of transporting
that part to that plant”

11
  To what does the it refer?
– The part record?
– The plant record?
– Or the database?
 Two separate workflows are needed
– The requirements artifacts must be expressed in the language of the client
– The analysis artifacts must be precise, and complete enough for the designers
The Design Workflow
 The aim of the design workflow is to refine the analysis workflow until the material is
in a form that can be implemented by the programmers
– Many nonfunctional requirements need to be finalized at this time, including
» Choice of programming language
» Reuse issues
» Portability issues
The Implementation Workflow
 The aim of the implementation workflow is to implement the target information
system in the selected implementation language
– A large information system is partitioned into subsystems
– The subsystems consist of components or code artifacts
The Test Workflow
 The test workflow is the responsibility of the quality assurance group
– Each component is tested as it has been implemented
o Unit testing
– At the end of each iteration, the completed components are compiled and linked
together (integrated) and tested
o Integration testing
– When the product appears to be complete, it is tested as a whole
o Product testing
– Once the completed product has been installed on the client’s computer, the client
tests it
o Acceptance testing

4.6 PHASES OF THE UNIFIED PROCESS

 In the figure, the increments are identified as phases

12
  The four increments are labeled
o Inception phase
o Elaboration phase
o Construction phase
o Transition phase
 The phases of the Unified Process are the increments
 In theory, there could be any number of increments
o In practice, development seems to consist of four increments
 Every step performed in the Unified Process falls into
o One of the five core workflows and also
o One of the four phases
 Why does each step have to be considered twice?
 Workflow
o Presented in a technical context
 Phase
o Presented in a business context

4.6.1 The Inception Phase

 The aim of the inception phase is to determine whether the proposed information system
is economically viable
1. Gain an understanding of the domain
2. Build the business model
3. Delimit the scope of the proposed project
o Focus on the subset of the business model that is covered /by the
proposed information system
4. Begin to make the initial business case

The Inception Phase : The Initial Business Case

 Questions that need to be answered include:

o Is the proposed information system cost effective?
o How long will it take to obtain a return on investment?
o Alternatively, what will be the cost if the company decides not to develop the
proposed information system?
o If the information system is to be sold in the marketplace, have the necessary
marketing studies been performed?
o Can the proposed information system be delivered in time?
o If the information system is to be developed to support the client organization’s
own activities, what will be the impact if the proposed information system is
delivered late?
 What are the risks involved in developing the information system, and
 How can these risks be mitigated?
o Does the team who will develop the proposed information system have the
necessary experience?
o Is new hardware needed for this information system

13
 o If so, is there a risk that it will not be delivered in time?
o If so, is there a way to mitigate that risk, perhaps by ordering back-up hardware
from another supplier?
o Are software tools (Chapter 11) needed?
o Are they currently available?
o Do they have all the necessary functionality?
 Answers are needed by the end of the inception phase so that the initial business case can
be made

The Inception Phase: Use Cases and Risks

 The next step:

o Identify the use cases
o Prioritize them in the order of the risk that they carry
 There are three major risk categories:
o Technical risks
o The risk of not getting the requirements right
 Mitigated by performing the requirements workflow correctly
o The risk of not getting the architecture right
 The architecture may not be sufficiently robust
 To mitigate all three classes of risks
o The use cases need to be prioritized in order of associated risk so that the critical
risks are mitigated first
 This concludes the steps of the inception phase that fall under the requirements workflow

The Inception Phase: Analysis, Design Workflows

 A small amount of the analysis workflow may be performed during the inception phase
 A few critical use cases are analyzed, so that the design of the architecture can begin
 Thus, a small amount of the design workflow may be performed, too

The Inception Phase: Implementation Workflow

 Coding is generally not performed during the inception phase

 Sometimes a proof-of-concept prototype is build to test the feasibility of part of the
information system
o This is not a rapid prototype constructed to be certain that the requirements have
been accurately determined
 Rapid prototyping is not part of the Unified Process
o A proof-of-concept prototype is more like an engineering prototype
 A scale model constructed to test the feasibility of construction

The Inception Phase: Test Workflow

 The test workflow commences almost at the start of the inception phase
o The aim is to ensure that the requirements have been accurately determined

14
 The Inception Phase: Planning

 There is insufficient information at the beginning of the inception phase to plan the entire
development
o The only planning that is done at the start of the project is the planning for the
inception phase itself
 For the same reason, the only planning that can be done at the end of the inception phase
is the plan for just the next phase, the elaboration phase

The Inception Phase: Documentation

 The deliverables of the inception phase include:

o The initial version of the domain model
o The initial version of the business model
o The initial version of the requirements artifact (especially the use cases)
o A preliminary version of the analysis artifacts
o A preliminary version of the architecture
o The initial list of risks
o The initial ordering of the use cases
o The plan for the elaboration phase
 The initial version of the business case

The Inception Phase: The Initial Business Case

 Obtaining the initial version of the business case is the overall aim of the inception phase
 This initial version incorporates
o A description of the scope of the information system
o Financial details
o If the proposed information system is to be marketed, the business case will also
include
 Revenue projections, market estimates, initial cost estimates
o If the information system is to be used in-house, the business case will include
 The initial cost–benefit analysis

4.6.2 The Elaboration Phase

 The aim of the elaboration phase is to refine the initial requirements

o Refine the use cases
o Refine the architecture
o Monitor the risks and refine their priorities
o Refine the business case
o Produce the project management plan
 The major activities of the elaboration phase are refinements or elaborations of the
previous phase

15
 The Tasks of the Elaboration Phase

 The tasks of the elaboration phase correspond to:

o All but completing the requirements workflow
o Performing virtually the entire analysis workflow
o Starting the design of the architecture

The Elaboration Phase: Documentation

 The deliverables of the elaboration phase include:

o The completed domain model
o The completed business model
o The completed requirements artifacts
o The completed analysis artifacts
o An updated version of the architecture
o An updated list of risks
o The project management plan (for the rest of the project)
o The completed business case

4.6.3 Construction Phase

 The aim of the construction phase is to produce the first operational-quality version of the
information system
o This is sometimes called the beta release
 The Tasks of the Construction Phase
 The emphasis in this phase is on
o Implementation, and
o Testing
 Unit testing of modules
 Integration testing of subsystems
 Product testing of the overall system

The Construction Phase: Documentation

 The deliverables of the construction phase include:

o The initial user manual and other manuals, as appropriate
o All the artifacts (beta release versions)
o The completed architecture
o The updated risk list
o The project management plan (for the remainder of the project)
o If necessary, the updated business case

4.6.4 The Transition Phase

 The aim of the transition phase is to ensure that the client’s requirements have indeed
been met

16
 o Faults in the information system are corrected
o All the manuals are completed
o Attempts are made to discover any previously unidentified risks
 This phase is driven by feedback from the site(s) at which the beta release has been
installed

The Transition Phase: Documentation

 The deliverables of the transition phase include:

o All the artifacts (final versions)
o The completed manuals

4.7 CLASS DIAGRAMS

 A class diagram depicts classes and their interrelationships

 Here is the simplest possible class diagram

 Class diagram showing more details of Bank Account Class

 Add as many (or as few) details as appropriate for the current iteration and
incrementation

Class Diagrams: Notation

 Freedom of notation extends to objects

 Example:
o bank account : Bank Account Class
 Bank account is an object, an instance of a class Bank Account Class
o The underlining denotes an object
o The colon denotes “an instance of”
o The bold face and initial upper case letters in Bank Account Class denote that this
is a class
 UML allows a shorter notation when there is no ambiguity

17
 o bank account
 The UML notation for modeling the concept of an arbitrary bank account is
o : Bank Account Class
 The colon means “an instance of,” so
o : Bank Account Class means
o “an instance of class Bank Account Class”

Class Diagrams: Visibility Prefixes

 UML visibility prefixes (used for information hiding)

o Prefix + indicates that an attribute or operation is public
 Visible everywhere
o Prefix – denotes that the attribute or operation is private
 Visible only in the class in which it is defined
o Prefix # denotes that the attribute or operation is protected
 Visible either within the class in which it is defined or within subclasses of
that class
 Example:
o Class diagram with visibility prefixes added

o Attribute accountBalance is visible only within the Bank Account Class

o Operations deposit and withdraw are accessible from anywhere within the
information system

4.7.1 AGGREGATION

 Example: “A car consists of a chassis, an engine, wheels, and seats”

18
  The open diamonds denote aggregation
o Aggregation is the UML term for the part–whole relationship
 The diamond is placed at the “whole” (car) end, not the “part” (chassis, engine, wheels,
or seats) end of the line connecting a part to the whole

4.7.2 MULTIPLICITY

 Example: “A car consists of one chassis, one engine, 4 or 5 wheels, an optional sun roof,
zero or more fuzzy dice hanging from the rear-view mirror, and 2 or more seats”

 The numbers next to the ends of the lines denote multiplicity

o The number of times that the one class is associated with the other class
 Item 1:
o The line connecting Chassis Class to Car Class
 The 1 at the “part” end of the line denotes that there is one chassis
involved
 The 1 at the “whole” end denotes that there is one car involved
o Each car has one chassis, as required
o Similar observations hold for the line connecting Engine Class to Car Class
 Item 2:
o The line connecting Wheels Class to Car Class
 The 4..5 at the “part” end together with the 1 at the “whole” end denotes
that each car has from 4 to 5 wheels (the fifth wheel is the spare)
o A car has 4 or 5 wheels, as required
 Instances of classes come in whole numbers only
 Item 3:
o The line connecting Sun Roof Class to Car Class
 Two dots .. denote a range, so the 0..1 means zero or one, the UML way of
denoting “optional”
o A car has an optional sun roof, as required
 Item 4:

19
 o The line connecting Fuzzy Dice Class to Car Class
 The * by itself means zero or more
o Each car has zero or more fuzzy dice hanging from the rear-view mirror, as
required
 Item 5:
o The line connecting Seats Class to Car Class
 An asterisk in a range denotes “or more,” so the 2..* means 2 or more
o A car has two or more seats, as required
 If the exact multiplicity is known, use it
o Example: The 1 that appears in 8 places
o If the range is known, use the range notation
o Examples: 0..1 or 4..5
o If the number is unspecified, use the asterisk
o Example: *
o If the range has upper limit unspecified, combine the range notation with the
asterisk notation
o Example: 2..*

4.7.3 COMPOSITION

 Aggregation example: Every chess board consists of 64 squares

 This relationship goes further

o It is an instance of composition, a stronger form of aggregation
 Association
o Models the part–whole relationship
 Composition
o Also models the part–whole relationship
o In addition, every part may belong to only one whole
o If the whole is deleted, so are the parts
 Example: A number of different chess boards
o Each square belongs to only one board
o If a chess board is thrown away, all 64 squares on that board go as well
 Composition is depicted by a solid diamond

20
4.7.4 GENERALIZATION

 Inheritance is a required feature of object orientation

 Inheritance is a special case of generalization
o The UML notation for generalization is an open triangle
o Sometimes the open triangle is labeled with a discriminator
 Every instance of Asset Class or its subclasses has an attribute assetType (the
discriminator)
o This attribute can be used to distinguish between instances of the subclasses

4.7.5 ASSOCIATION

 The association between the two classes may be modeled as a class

o Example: Suppose the radiologist consults the lawyer on a number of occasions,
each one for a different length of time
 Now consults has become a class, Consults Class, which is called an association class
o Because it is both an association and a class

21
4.8 USE CASE DIAGRAMS

 A use case is a model of the interaction between

o External users of an information system (actors) and
o The information system itself
 More precisely, an actor is a user playing a specific role
 A use-case diagram is a set of use cases
 Generalization of actors is supported
o The open triangle points toward the more general case

4.9 INTERACTION DIAGRAMS

 Interaction diagrams show how objects interact with one another

 UML supports two types of interaction diagrams
o Sequence diagrams
o Collaboration diagrams

4.9.1 Sequence Diagrams

 Example: Dynamic creation followed by destruction of an object

22
 The lifelines in the sequence diagram
o An active object is denoted by a thin rectangle (activation box) in place of the
dashed line
 Creation of the : Masterpiece Class object is denoted by the lifeline starting at the point of
dynamic creation
 Destruction of that object after it receives message
 9: Destroy object
o is denoted by the heavy X
 A message is optionally followed by a message sent back to the object that sent the
original message
 Even if there is a return, it is not necessary that a specific new message be sent back
o Instead, a dashed line ending in an open arrow indicates a return from the original
message, as opposed to a new message
 There is a guard on the message
 9: [offer rejected] Destroy object
o Only if Osbert’s offer is rejected is message 9 sent
 A guard (condition) is something that is true or false
o The message sent only if the guard is true
 The purpose of a guard
o To ensure that the message is sent only if the relevant condition is true
 Iteration an indeterminate number of times is modeled by an asterisk (Kleene star)
 Example: Elevator (see next slide)
 *move up one floor
o The message means: “move up zero or more floors”
 Sequence diagram for elevator

 An object can send a message to itself

o A self-call

23
  Example:
o The elevator has arrived at a floor
o The elevator doors now open and a timer starts
o At the end of the timer period the doors close again
o The elevator controller sends a message to itself to start its timer—this self-call is
shown in the previous UML diagram

4.9.2 Collaboration Diagrams

 Collaboration diagrams are equivalent to sequence diagrams

o All the features of sequence diagrams are equally applicable to collaboration
diagrams
o Use a sequence diagram when the transfer of information is the focus of attention
 Use a collaboration diagram when concentrating on the classes

4.10 STATE CHARTS

 The elevator is in state Elevator Moving

o It performs operation
 Move up one floor
o while guard [no message received yet] remains true, until it receives the message
 Elevator has arrived at floor
 Receipt of this message (event) causes the guard to be false
 It also enables a transition to state Stopped at Floor
o In this state, activity
 Open the elevator doors
o is performed
 The most general form of a transition label is
 event [guard] / action
o If
 event
o has taken place and
 [guard]
o is true, the transition occurs, and, while it is occurring,
 action
o is performed
 Statechart with guards

24
 An event also causes transitions between states
 Example: The receipt of a message

 Equivalent statement with most general transition

 The transition label is

o Elevator has arrived at floor [a message has been received] / Open the elevator
doors
o The guard
o [a message has been received]
o is true when the event
o Elevator has arrived at floor
o has occurred and the message has been sent
 The action to be taken is
o Open the elevator doors
 There are two places where an action can be performed in a statechart
o When a state is entered
 Activity
o As part of a transition
 Action
 An event can be specified in terms of words like “when” or “after”
 Example:
o When (cost > 1000) or after (2.5 seconds)

25
  Superstates combine related states

 States A, B, C, and D all have transitions to Next State

 Combine them into superstate ABCD Combined
o Now there is only one transition
o The number of arrows is reduced from four to only one
 States A, B, C, and D all still exist in their own right
 Example: Four states are unified into MSG Combined

4.11 PACKAGE DIAGRAMS

 A large information system is decomposed into relatively independent packages

 UML notation for a package

26
  Example showing the contents of My Package

4.12 DEPLOYMENT DIAGRAMS

 A deployment diagram shows on which hardware component each software

component is installed (or deployed)
 It also shows the communication links between the hardware components
 Example:

4.13 OTHER UML DIAGRAMS

4.13.1 Component Diagrams

 A component diagram shows dependencies among software components, including

o Source code
o Compiled code

27
 o Executable load images
 Example:
o Programmers write source code in an object-oriented language
 C++ or Java
o The source code is translated by a compiler into compiled code
 (The binary code that is the only language a computer understands)
o The compiled code for each module is combined with run-time routines to
produce an executable load image (that is, a program)
 Example:

4.13.2 Activity Diagrams

 Activity diagrams show how various events are coordinated

o Used when activities are carried on in parallel
 Example:
o One diner orders chicken, the other fish
o The waiter writes down their order, and hands it to the chef
o The meal is served only when both dishes have been prepared
 Example:

 A fork has
o One incoming transition, and

28
 o Many outgoing transitions, each of which starts an activity to be executed in
parallel with the other activities
 A join has
o Many incoming transitions, each of which lead from an activity executed in
parallel with the other activities, and
o One outgoing transition that is started when all the parallel activities have been
completed
 Example: A company that assembles computers as specified by the customer

 The three departments involved

o Assembly Department
o Order Department
o Accounts Receivable Department
o are each in their own swimlane

29