Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Each patient is on a single ward and is under the care of a single team of doctors. A patient may
be treated by any number of doctors but they must all be in the team that cares for the patient. A
doctor can treat any number of patients. The team leader accepts ultimate responsibility, legally
and otherwise, for the care of all the patients referred to him/her, even with many of the minuteto-minute decisions being made by subordinates.
UML structural diagrams are categorized as follows: class diagram, object diagram, component
diagram, and deployment diagram.
Class Diagram
A class diagram models the static view of a system. It comprises of the classes, interfaces, and
collaborations of a system; and the relationships between them.
Relationships:
A Branch with role Zonal Head Office supervises other Branches : unary association,
oneto-many
From the class Account, two classes have inherited, namely, Savings Account and Current Account.
Object Diagram
An object diagram models a group of objects and their links at a point of time. It shows the
instances of the things in a class diagram. Object diagram is the static part of an interaction
diagram.
Example : The following figure shows an object diagram of a portion of the class diagram of the
Banking System.
Component Diagram
Component diagrams show the organization and dependencies among a group of components.
Component diagrams comprise of:
Components
Interfaces
Relationships
modeling configuration management of source code files while developing a system using
an object-oriented programming language.
Example
The following figure shows a component diagram to model a systems source code that is
developed using C++. It shows four source code files, namely, myheader.h, otherheader.h,
priority.cpp, and other.cpp. Two versions of myheader.h are shown, tracing from the recent version
to its ancestor. The file priority.cpp has compilation dependency on other.cpp. The file other.cpp has
compilation dependency on otherheader.h.
Deployment Diagram
A deployment diagram puts emphasis on the configuration of runtime processing nodes and their
components that live on them. They are commonly comprised of nodes and dependencies, or
associations between the nodes.
Example
The following figure shows the topology of a computer system that follows client/server architecture.
The figure illustrates a node stereotyped as server that comprises of processors. The figure
indicates that four or more servers are deployed at the system. Connected to the server are the
client nodes, where each node represents a terminal device such as workstation, laptop, scanner,
or printer. The nodes are represented using icons that clearly depict the real-world equivalent.
of SpecialOrder object
and
the
last
call
is Dispatch
() which
is
method
ofSpecialOrder object. So here the diagram is mainly describing the method calls from one object to
another and this is also the actual scenario when the system is running.
Now to choose between these two diagrams the main emphasis is given on the type of
requirement. If the time sequence is important then sequence diagram is used and if organization is
required then collaboration diagram is used.
Activities
Association
Conditions
Constraints
Once the above mentioned parameters are identified we need to make a mental layout of the entire
flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:
Confirm order
Dispatch order
After receiving the order request condition checks are performed to check if it is normal or special
order. After the type of order is identified dispatch activity is performed and that is marked as the
termination of the process.
The name of the class diagram should be meaningful to describe the aspect of the system.
For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.
Use notes when ever required to describe some aspect of the diagram. Because at the end
of the drawing it should be understandable to the developer/coder.
Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct.
First of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.
We would keep Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
The two inherited classes have all the properties as the Order class. In addition they have
additional functions like dispatch () and receive ().
So the following class diagram has been drawn considering all the points mentioned above:
How to draw
UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a
system. The behavioral diagrams are categorized as follows: use case diagrams, interaction
diagrams, statechart diagrams, and activity diagrams.
(b) Actor
An actor represents the roles that the users of the use cases play. An actor may be a person (e.g.
student, customer), a device (e.g. workstation), or another system (e.g. bank, institution).
The following figure shows the notations of an actor named Student and a use case called
Generate Performance Report.
Use cases
Actors
To model the context of a system by enclosing all the activities of a system within a
rectangle and focusing on the actors outside the system by interacting with it.
Example
Let us consider an Automated Trading House System. We assume the following features of the
system:
The trading house has transactions with two types of customers, individual customers and
corporate customers.
Once the customer places an order, it is processed by the sales department and the
customer is given the bill.
The system allows the manager to manage customer accounts and answer any queries
posted by the customer.
Interaction Diagrams
Interaction diagrams depict interactions of objects and their relationships. They also include the
messages passed between them. There are two types of interaction diagrams:
Sequence Diagrams
Collaboration Diagrams
Sequence Diagrams
Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to
time.
Notations : These diagrams are in the form of two-dimensional charts. The objects that initiate the
interaction are placed on the xaxis. The messages that these objects send and receive are placed
along the yaxis, in the order of increasing time from top to bottom.
Example : A sequence diagram for the Automated Trading House System is shown in the following
figure.
Collaboration Diagrams
Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send
and receive messages.
Notations : In these diagrams, the objects that participate in the interaction are shown using
vertices. The links that connect the objects are used to send and receive messages. The message
is shown as a labeled arrow.
Example : Collaboration diagram for the Automated Trading House System is illustrated in the
figure below.
StateChart Diagrams
A statechart diagram shows a state machine that depicts the control flow of an object from one
state to another. A state machine portrays the sequences of states which an object undergoes due
to events and their responses to events.
StateChart Diagrams comprise of:
State-chart diagrams are used for modeling objects which are reactive in nature.
Example
In the Automated Trading House System, let us model Order as an object and trace its sequence.
The following figure shows the corresponding statechart diagram.
Activity Diagrams
An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state
machine. Activities result in actions which are atomic operations.
Activity diagrams comprise of:
Transitions
Objects
Example
The following figure shows an activity diagram of a portion of the Automated Trading House
System.
What is SDLC?
SDLC is a process followed for a software project, within a software organization. It consists of a
detailed plan describing how to develop, maintain, replace and alter or enhance specific software.
The life cycle defines a methodology for improving the quality of software and the overall
development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.
Deployment of system: Once the functional and non functional testing is done, the product
is deployed in the customer environment or released into the market.
Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In
this model phases do not overlap.
What is Agile?
Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are divided to time boxes
(small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.
Here is a graphical illustration of the Agile Model:
Agile thought process had started early in the software development and started becoming popular
with time due to its flexibility and adaptability.
The most popular agile methods include Rational Unified Process (1994), Scrum (1995), Crystal
Clear,
Extreme
Programming
(1996),
Adaptive
Software
Development,
Feature
Driven
Development, and Dynamic Systems Development Method (DSDM) (1995). These are now
collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles
Unified process:
Inception
Elaboration
Construction
Transition
Inception Phase[edit]
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception
Phase is long then it may be an indication of excessive up-front specification, which is contrary to the
spirit of the Unified Process.
The following are typical goals for the Inception phase.
Outline the use cases and key requirements that will drive the design tradeoffs
Identify risks
The Lifecycle Objective Milestone marks the end of the Inception phase.
Develop an approximate vision of the system, make the business case, define the scope, and
produce rough estimate for cost and schedule.
Elaboration Phase[edit]
During the Elaboration phase the project team is expected to capture a healthy majority of the
system requirements. However, the primary goals of Elaboration are to address known risk factors
and to establish and validate the system architecture. Common processes undertaken in this phase
include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic
notation) andpackage diagrams (architectural diagrams).
The architecture is validated primarily through the implementation of an Executable Architecture
Baseline. This is a partial implementation of the system which includes the core, most architecturally
significant, components. It is built in a series of small, time boxed iterations. By the end of the
Elaboration phase the system architecture must have stabilized and the executable architecture
baseline must demonstrate that the architecture will support the key system functionality and exhibit
the right behavior in terms of performance, scalability and cost.
The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the
Construction phase. At this point the plan should be accurate and credible, since it should be based
on the Elaboration phase experience and since significant risk factors should have been addressed
during the Elaboration phase.
Construction Phase[edit]
Construction is the largest phase in the project. In this phase the remainder of the system is built on
the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed
iterations. Each iteration results in an executable release of the software. It is customary to write full
text use cases during the construction phase and each one becomes the start of a new iteration.
Common UML (Unified Modelling Language) diagrams used during this phase include Activity,
Sequence, Collaboration, State (Transition) and Interaction.
Transition Phase[edit]
The final project phase is Transition. In this phase the system is deployed to the target users.
Feedback received from an initial release (or initial releases) may result in further refinements to be
incorporated over the course of several Transition phase iterations. The Transition phase also
includes system conversions and user training.
Scrum Definition
Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage complex product development since
the early 1990s. Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear the
relative efficacy of your product management and development practices so that you can improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to Scrums
success and usage.
The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and
interaction between them. The rules of Scrum are described throughout this tutorial.
Note - Across the industry, there are misconceptions that Scrum means no documentation, scrum
team consists of only developers, and so on. It is not entirely so; we will give clarifications on these
in later sections.
In Scrum, the prescribed events are used to create regularity. All events are time-boxed events,
such that every event has a maximum duration. The events are described more elaborately in the
subsequent chapters.