5.A.

Operation Contracts
We have described:
Use Cases
Domain Model
System Sequence Diagrams
We now describe
Operation Contracts

Afterwards, we go into the Design

Model
➢ Use Cases often fully describe the behavior of a system But they may not be
enough
➢ Operation Contracts describe how the internal state of the concepts in the
Domain Model may change
➢ Operation Contracts are described in terms of preconditions and
postconditions
➢ This is a sample OC for “enterItem”
➢ Operation Contracts are defined in terms of system operations
 - Operations (say, methods) that the system offers as a whole
➢ The system is still a black box at this stage
➢ The System Sequence Diagrams show system events I.e., the SSD's
messages
➢ System operations handle system events
➢ Operation—name of operation (parameters)
➢ Cross Reference—the Use Cases in which the OC occurs
➢ Preconditions—noteworthy assumptions about state of system or objects
in DM before execution
➢ Postconditions—state of objects in DM after execution of operation
Postconditions
➢ Most important part of OCs!
➢ Include changes in state of DM
➢ Book uses categories (note that the names are for reference only):
• Instance creation or deletion
• Association formed or broken
• Attribute modification
➢ Write in past (passive voice?)
• A LineSaleItem was created
➢ Readability first
➢ Common mistake—forgetting that instance creation often implies association
formation, and similarly, that instance deletion often implies association
breaking
5.B. Implementation
The UML artifacts created during the design work the interaction diagrams
and DCDs will be used as input to the code generation process.
5.B.1 Programming and Iterative, Evolutionary Development
The creation of code in an OO language such as Java or C# is not part of
OOA/D it's an end goal. The artifacts created in the Design Model provide
some of the information necessary to generate the code.
A strength of use cases plus OOA/D plus OO programming is that they
provide an end-to-end roadmap from requirements through to code. The
various artifacts feed into later artifacts in a traceable and useful manner,
ultimately culminating in a running application. This is not to suggest that the
road will be smooth, or can simply be mechanically followed there are many
variables. But having a roadmap provides a starting point for
experimentation and discussion.
A strength of an iterative and incremental development process is that the
results of a prior iteration can feed into the beginning of the next iteration
(see Figure ). Thus, subsequent analysis and design results are continually
being refined and enhanced from prior implementation work. For example,
when the code in iteration N deviates from the design of iteration N (which it
inevitably will), the final design based on the implementation can be input to
the analysis and design models of iteration N+l.

Fig: Implementation in an iteration influences later design.

An early activity within an iteration is to synchronize the design diagrams;
the earlier diagrams of iteration N will not match the final code of iteration
N, and they need to be synchronized before being extended with new design
results.
5.B.1.2 Creativity and Change During Implementation
Some decision-making and creative work was accomplished during design
work. It will be seen during the following discussion that the generation of
the code in these examples a relatively mechanical translation process.
However, in general, the programming work is not a trivial code generation
step quite the opposite! Realistically, the results generated during design
modeling are an incomplete first step; during programming and testing,
myriad changes will be made and detailed problems will be uncovered and
resolved.
Done well, the ideas and understanding (not the diagrams or documents!)
generated during OO design modeling will provide a great base that scales
up with elegance and robustness to meet the new problems encountered
during programming. But, expect and plan for lots of change and deviation
from the design during programming. That's a key and pragmatic attitude in
iterative and evolutionary methods.
5.2 Mapping Designs to Code
Implementation in an object-oriented programming language requires
writing source code for:
➢ class and interface definitions
➢ method definitions
5.2.1. Creating Class Definitions from DCDs
At the very least DCDs depict the class or interface name, superclasses,
method signatures, and simple attributes of a class. This is sufficient to create
a basic class definition in an Object-oriented programming language. The
detail discussion will explore the addition of interface and namespace (or
package) information, among other details.
5.2.2 Defining a Class with Methods and Simple Attributes
From the DCD, a mapping to the basic attribute definitions (simple Java
instance fields) and method signatures for the Java definition of SalesLineltem
is straightforward, as shown in the figure below: -
ProductSpecification
SalesLineItem Described by desc : Text
quantity : Integer price : Money
+ProdSpec id : ItemID
getSubTotal:Money()
...()

public class SalesLineItem

{
private int quantity;
Public SalesLineItem(ProductSpecification spec, int qty) {…} public Money
getSubTotal() {…} }
Note the addition in the source code of the Java constructor SalesLineltem().
It is derived from the create (spec, qty) message sent to a SalesLineltem in the
enterItem interaction diagram. This indicates, in Java, that a constructor
supporting these parameters is required. The create method is often excluded
from the class diagram because of its commonality and multiple
interpretations, depending on the target language.
5.2.3 Adding Reference Attributes
A reference attribute is an attribute that refers to another complex object,
not to a primitive type such as a String, Number, and soon. The reference
attributes of a class are suggested by the associations and navigability in a
class diagram.
For example a SalesLineltem has an association to a ProductSpecification,
with navigability to it. It is common to interpret this as a reference attribute
in class Saleslineltem that refers to a ProductSpecification instance.
public class SalesLineItem
{
…
public ProductSpecification prodSpec;
…
}
In Java, this means that an instance field referring to a ProductSpecification
instance is suggested. For example, although we have added an instance
field to the Java definition of SalesLineItem to point to a ProductSpecification,
it is not explicitly declared as an attribute in the attribute section of the class
box. There is a suggested attribute visibility—indicated by the association
and navigability—which is explicitly defined as an attribute during the code
generation phase.
5.2.4 Reference Attributes and Role Names
The next iteration will explore the concept of role names in static structure
diagrams. Each end of an association is called a role. Briefly, a role name is a
name that identifies the role and often provides some semantic context as to
the nature of the role.
If a role name is present in a class diagram, use it as the basis for the name
of the reference attribute during code generation.
5.2.5 Mapping Attributes
The Sale class illustrates that in some cases one must consider the mapping
of attributes from the design to the code in different languages. The figure
below illustrates the problem and its resolution.
public class Sales
{
…
private Date dateTime = new Date();
…
}
5.2.6 Creating Methods from Interaction Diagrams
An interaction diagram shows the messages that are sent in response to a
method invocation. The sequence of these messages translates to a series of
statements in the method definition. The enterItem interaction diagram
illustrates the Java definition of the enterItem method.
Register ProductCatalog ProductSpecification Sale SalesLineItem

spec:=getSpec(id)
enterItem(id,qty) spec:=find(id)

makeLineItem(spec,qty) create(spec,qty) sl:

SalesLineItem
add(sl)

public class Register

{
private ProductCatalog prodCat; private Sale s;
public Register(ProductCatalog pc) {…}
Public void enterItem(int: ItemID, qty: Integer) {…} }
The Register-enterItem Method looks something like this: - public class
Register private Productcatalog catalog.
private Sale sale, public Reglster(Productcetalog PC) f ProductCatalog public
void endSale() Looks-in public void enterltem(ItemlD id ml qty) C-) i e public
void makeNewsale() (_-} I - - - public void makePayment(lvoney cashlendered)
The enterItem message is sent to a Register instance; therefore. the
enterItem method is defined in class Register. public void enteritem(itemID
id, int qty)
Message 1:
ProductSpecification spec = prodCat.getSpec(id)
Message 2:
s.makeLineItem(spec, qty)
In summary, each sequenced message within a method, as shown on the
interaction diagram, is mapped to a statement in the Java method.
5.2.6 Collection Classes in Code
A collection is a group of data manipulate as a single object. Corresponds to
a bag.
• Collection classes insulate client programs from the implementation. Eg.
array, linked list, hash table, balanced binary tree
• Insulate client programs from the implementation.n array, linked list,
hash table, balanced binary tree
• Like C++'s Standard Template Library (STL)
• Can grow as necessary.
• Contain only Objects (reference types).
• Heterogeneous.
• Can be made thread safe (concurrent access).
• Can be made not-modifiable.
In real worlds ,One-to-many relationships are common. For example, a Sale
must maintain visibility to a group of many SalesLineItem instances, as shown
in Figure 4.5. In OO programming languages, these relationships are usually
implemented with the introduction of a collection object, such as a List or
Map, or even a simple array.
What is a deployment diagram?
In the context of the Unified Modeling Language (UML), a deployment
diagram falls under the structural diagramming family because it describes an
aspect of the system itself. In this case, the deployment diagram describes the
physical deployment of information generated by the software program on
hardware components. The information that the software generates is called
an artifact. This shouldn't be confused with the use of the term in other
modeling approaches like BPMN.
Deployment diagrams are made up of several UML shapes. The three-
dimensional boxes, known as nodes, represent the basic software or hardware
elements, or nodes, in the system. Lines from node to node indicate
relationships, and the smaller shapes contained within the boxes represent
the software artifacts that are deployed.
 Deployment diagram applications
Deployment diagrams have several valuable applications. You can use them
to:
• Show which software elements are deployed by which hardware elements.
• Illustrate the runtime processing for hardware.
• Provide a view of the hardware system’s topology.
Deployment diagram guidelines
Use Lucidchart's UML diagram tool to construct deployment diagrams.
Before you begin diagramming, ask yourself these questions:
1. Have you identified the scope of your system? For example, you should know
whether you are diagramming a single application or the deployment to a
whole network of computers.
2. What are the limitations of your physical hardware? What legacy systems will
you need to interact with? Make sure that you know the operating software
 and protocols you will be working with and what monitoring you will be
putting into place.
3. Which distribution architecture are you using? You should know how many
tiers your application will have and what application you will deploy to.
4. Do you have all the nodes you need? Do you know how they are all
connected?
5. Do you know which components are going to be on which nodes?
Diagramming is quick and easy with Lucidchart. Start a free trial today to
start creating and collaborating.
Create a UML Diagram
Deployment diagram elements
A variety of shapes make up deployment diagrams. This list offers an
overview of the basic elements you may encounter, and you can see most of
these items illustrated in the image below.
• Artifact: A product developed by the software, symbolized by a rectangle
with the name and the word “artifact” enclosed by double arrows.
• Association: A line that indicates a message or other type of communication
between nodes.
• Component: A rectangle with two tabs that indicates a software element.
• Dependency: A dashed line that ends in an arrow, which indicates that one
node or component is dependent on another.
• Interface: A circle that indicates a contractual relationship. Those objects that
realize the interface must complete some sort of obligation.
• Node: A hardware or software object, shown by a three-dimensional box.
• Node as container: A node that contains another node inside of it—such as
in the example below, where the nodes contain components.
• Stereotype: A device contained within the node, presented at the top of the
node, with the name bracketed by double arrows.
Deployment diagram symbols and notation
Use these shapes as you build UML deployment diagrams.
Nodes

There are two types of nodes in a deployment diagram: device nodes and
execution environment nodes. Device nodes are computing resources with
processing capabilities and the ability to execute programs. Some examples
of device nodes include PCs, laptops, and mobile phones.
 An execution environment node, or EEN, is any computer system that resides
within a device node. It could be an operating system, a JVM, or another
servlet container.
Database

Databases represent any data stored by the deployed system. In some

instances, you'll see a database represented as just another node, but
sometimes you will see this shape as a database.
Other shapes
• Communication path: A straight line that represents communication
between two device nodes.
• Artifacts: A box with the header "<>" and then the name of the file.
• Package: A file-shaped box that groups together all the device nodes to
encapsulate the entire deployment.
• Component: An entity required to execute a stereotype function. Take a look
at this guide for UML component notation.
Deployment diagram example
This example shows a basic deployment diagram for Lucidchart. There is a
web server, a database server, and the machine where the user views the
website. You can add more complexity by showing the different parts of the
web server and the way Javascript works on the UserClient, but this
example gives you an idea of how a deployment looks in UML notation.
What is a UML component diagram?
The purpose of a component diagram is to show the relationship between
different components in a system. For the purpose of UML 2.0, the term
"component" refers to a module of classes that represent independent
systems or subsystems with the ability to interface with the rest of the
system.
There exists a whole development approach that revolves around
components: component-based development (CBD). In this approach,
component diagrams allow the planner to identify the different components
so the whole system does what it's supposed to do.
More commonly, in an OO programming approach, the component diagram
allows a senior developer to group classes together based on common
purpose so that the developer and others can look at a software
development project at a high level.
Benefits of component diagrams
 Though component diagrams may seem complex at first glance, they are
invaluable when it comes to building your system. Component diagrams can
help your team:
• Imagine the system’s physical structure.
• Pay attention to the system’s components and how they relate.
• Emphasize the service behavior as it relates to the interface.
How to use component diagrams
A component diagram in UML gives a bird’s-eye view of your software
system. Understanding the exact service behavior that each piece of your
software provides will make you a better developer. Component diagrams
can describe software systems that are implemented in any programming
language or style.
UML is a set of conventions for object-oriented diagrams that has a wide
variety of applications. In component diagrams, the Unified Modeling
Language dictates that components and packages are wired together with
lines representing assembly connectors and delegation connectors. To learn
more about UML and its uses, check out our guide, "What Is UML?"

Diagramming is quick and easy with Lucidchart. Start a free trial today to
start creating and collaborating.
Create a UML Diagram
Component diagram shapes and symbols
Component diagrams range from simple and high level to detailed and
complex. Either way, you'll want to familiarize yourself with the appropriate
UML symbols. The following are shape types that you will commonly
encounter when reading and building component diagrams:
How to use component shapes and symbols

There are three popular ways to create a component's name compartment.

You always need to include the component text inside the double angle
brackets and/or the component logo. The distinction is important because a
rectangle with just a name inside of it is reserved for classifiers (class
elements).
As with the class notation, components also have an optional space to list
interfaces, similar to the way you add attributes and methods to class
notation. Interfaces represent the places where the groups of classes in the
component communicate with other system components. An alternative way
to represent interfaces is by extending symbols from the component box.
Here is a quick rundown of the most commonly used symbols.

Provided interfaces: A
straight line from the
component box with an
attached circle. These
symbols represent the
interfaces where a
component produces
information used by the
required interface of another
component.

Required interfaces: A
straight line from the
component box with an
attached half circle (also
represented as a dashed
arrow with an open arrow).
These symbols represent the
interfaces where a
component requires
information in order to
perform its proper function.
 In UML, a component diagram visually represents how the components of a
software system relate to one another. To build one, try using Lucidchart’s
custom component diagram shape library. Component diagrams should
communicate:
• The scope of your system
• The overall structure of your software system
• Goals that the system helps human or non-human entities (known as actors)
achieve
Component diagram examples
UML component diagrams bring simplicity to even the most complex
processes. Take a look at the examples below to see how you can map the
behaviors of specific processes with component diagrams in UML.
Component diagram for a library management system
Library systems were some of the first systems in the world to become
widely run by computers. Today, many of these systems are managed in the
cloud by third-party services, rather than internally. Though the term “library
system” typically calls to mind a way to monitor printed books, library
systems today organize all kinds of data checked in and checked out by users.
These transactions create a network of relationships between the
components of the library system. To understand how these relationships
work and how the system functions overall, examine the UML diagram
below. You or your team can also use this diagram as a template.
Click here to use this template
Component diagram for an ATM system
A component diagram is similar to a class diagram in that it illustrates how
items in a given system relate to each other, but component diagrams
show more complex and varied connections that most class diagrams can.
In the diagram below, each component is enclosed in a small box. The dotted
lines with arrows show how some components are dependent on others. For
example, the card reader, web page, client desktop, and ATM system are all
dependent on the bank database. The dotted lines with circles at the end,
known as “lollipop” symbols, indicate a realization relationship.
How to make a component diagram
 In Lucidchart, you can easily craft an intricate component diagram in UML
from scratch. Just follow the steps below:
1. Open a blank document or start with a template.
2. Enable the UML shape library. Click "Shapes" on the left side of the editor,
check "UML" in the Shape Library Manager, and click "Save."
3. Select the shape you want from the library you added, and drag the shape
from the toolbox to the canvas.
4. Model the process flow by drawing lines between shapes.
What is a state diagram in UML?
A state machine is any device that stores the status of an object at a given
time and can change status or cause other actions based on the input it
receives. States refer to the different combinations of information that an
object can hold, not how the object behaves. In order to understand the
different states of an object, you might want to visualize all of the possible
states and show how an object gets to each state, and you can do so with a
UML state diagram.
Each state diagram typically begins with a dark circle that indicates the initial
state and ends with a bordered circle that denotes the final state. However,
despite having clear start and end points, state diagrams are not necessarily
the best tool for capturing an overall progression of events. Rather,
they illustrate specific kinds of behavior—in particular, shifts from one state
to another.
State diagrams mainly depict states and transitions. States are represented
with rectangles with rounded corners that are labeled with the name of the
state. Transitions are marked with arrows that flow from one state to
another, showing how the states change. Below, you can see both these
elements at work in a basic diagram for student life. Our UML diagram
tool can help you design any custom state machine diagram.
 State diagram applications
Like most UML diagrams, state diagrams have several uses. The main
applications are as follows:
• Depicting event-driven objects in a reactive system.
• Illustrating use case scenarios in a business context.
• Describing how an object moves through various states within its lifetime.
• Showing the overall behavior of a state machine or the behavior of a related
set of state machines.
Diagramming is quick and easy with Lucidchart. Start a free trial today to
start creating and collaborating.
Create a UML Diagram
State diagram symbols and components
You can include many different shapes in a state diagram, particularly if you
choose to combine it with another diagram. This list summarizes the most
common shapes you may encounter.
Composite state
A state that has substates nested into it. See the university state
diagram example below. “Enrollment” is the composite state in this example
because it encompasses various substates in the enrollment process.
Choice pseudostate
A diamond symbol that indicates a dynamic condition with branched
potential results.

Event
An instance that triggers a transition, labeled above the applicable transition
arrow. In this case, “classes end” is the event that triggers the end of the
“Being taught” state and the beginning of the “Final exams” state.

Exit point
The point at which an object escapes the composite state or state machine,
denoted by a circle with an X through it. The exit point is typically used if the
process is not completed but has to be escaped for some error or other
issue.

First state
A marker for the first state in the process, shown by a dark circle with a
transition arrow.

Guard
A Boolean condition that allows or stops a transition, written above the
transition arrow.
State
A rectangle with rounded corners that indicates the current nature of an
object.

Substate
A state contained within a composite state's region. In the university state
machine diagram found below, “Open for enrollment” is a substate in the
larger “Enrollment” composite state.
Terminator
A circle with a dot in it that indicates that a process is terminated.

Transition
An arrow running from one state to another that indicates a changing state.

Transitional behavior
A behavior that results when a state transitions, written above the transition
arrow.
Trigger
A type of message that actively moves an object from state to state, written
above the transition arrow. In this example, “Issue with reservation” is the
trigger that would send the person to the airport travel agency instead of the
next step in the process.
State diagram examples
Calendar availability state diagram example
This state machine diagram example shows the process by which a person
sets an appointment on their calendar. In the “Check date” composite state,
the system checks the calendar for availability in a few different substates. If
the time is not available on the calendar, the process will be escaped. If the
calendar shows availability, however, the appointment will be added to the
calendar.
University state diagram example
This state diagram shows the process of enrollment and classes at a
university. The composite state “Enrollment” is made up of various substates
that will lead students through the enrollment process. Once the student has
enrolled, they will proceed to “Being taught” and finally to “Final exams.”
Airport check-in state diagram example
The following example simplifies the steps required to check in at an airport.
For airlines, a state diagram can help to streamline processes and eliminate
unnecessary steps.