Unit - I: Write About Principles of Modeling?
Unit - I: Write About Principles of Modeling?
The choice of what models to create has a profound influence on how a problem is attacked and
how a solution is shaped.
Every model may be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient. Every nontrivial system is best approached through a small set of
nearly independent models.
Algorithmic Perspective
0
The traditional view of software development takes an algorithmic perspective.
1
In this approach, the main building block of all software is the procedure or function.
2
This view leads developers to focus on issues of control and the decomposition of larger
algorithms into smaller ones.
3
As requirements change and the system grows, systems built with an algorithmic focus
turn out to be very hard to maintain.
Object-oriented perspective
0
1
2
3
Every object has identity, state, and behavior.
4
Object-oriented development provides the conceptual foundation for assembling systems
out of components using technology such as Java Beans or COM+.
Modeling allows us to specify, visualize, construct and document the system to be constructed
Visualizing:-
Specifying:-
Visualizing
Specifying
Constructing
Documenting
The UML is more than just a bunch of graphical symbols. Rather, behind
each symbol in the UML notation is a well-defined semantics. In this manner, one developer can
write a model in the UML, and another developer, or even another tool, can interpret that model
unambiguously
Specifying means building models that are precise, unambiguous, and
complete.
Constructing:the UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages
Documenting:A healthy software organization produces all sorts of artifacts in addition to raw
executable code. These artifacts include
o
o
Requirements
Architecture
Design
Source code
Project plans
Tests
Prototypes
Releases
Things
Relationships
Diagrams
Structural things
Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. In all, there are seven kinds of
structural things.
1. Classes
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes
Class
Class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. A class implements one or more interfaces. Graphically, a class is
rendered as a rectangle, usually including its name, attributes, and operations.
Interface
0
Interface is a collection of operations that specify a service of a class or
component.
1
An interface therefore describes the externally visible behavior of that element.
Collaboration
Collaboration defines an interaction and is a society of roles and other elements
that work together to provide some cooperative behavior that's bigger than the sum of all the
elements. Therefore, collaborations have structural, as well as behavioral, dimensions. A given class
might participate in several collaborations.
Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its
name
Usecase
Use case is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor
Use case is used to structure the behavioral things in a model.
A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse
with solid lines, usually including only its name
Active class
Active class is just like a class except that its objects represent elements whose
behavior is concurrent with other elements. Graphically, an active class is rendered just like a class,
but with heavy lines, usually including its name, attributes, and operations
Component
Node
Node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often, processing capability. Graphically, a
node is rendered as a cube, usually including only its name
Interaction
state machine
Interaction
0
Interaction is a behavior that comprises a set of messages exchanged among a set of
objects within a particular context to accomplish a specific purpose
1
An interaction involves a number of other elements, including messages, action sequences
and links
2
Graphically a message is rendered as a directed line, almost always including the name of
its operation
State Machine
0
State machine is a behavior that specifies the sequences of states an object or an
interaction goes through during its lifetime in response to events, together with its responses to
those events
1
State machine involves a number of other elements, including states, transitions, events
and activities
2
Graphically, a state is rendered as a rounded rectangle, usually including its name and its
substates
Grouping Things:1.
2.
are the organizational parts of UML models. These are the boxes into which a model can be
decomposed
There is one primary kind of grouping thing, namely, packages.
Annotational things
Annotational things are the explanatory parts of UML models. These are
the comments you may apply to describe about any element in a model.
0
1
Note:2
3
Note is simply a symbol for rendering constraints and comments attached to an element or
a collection of elements.
4 Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a
textual or graphical comment
Relationships :
There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
Dependency:0
Dependency is a semantic relationship between two things in which a change to one thing
may affect the semantics of the other thing
1
Graphically a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label
Association
Association is a structural relationship that describes a set of links, a link being a
connection among objects.
Graphically an association is rendered as a solid line
Aggregation
Aggregation is a special kind of association, representing a structural relationship
between a whole and its parts. Graphically, a generalization relationship is rendered as a solid line
with a hollow arrowhead pointing to the parent
Class diagram
Object diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
Component diagram
Deployment diagram
Class diagram
0
1
2
3
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships.
4
Class diagrams that include active classes address the static process view of a system.
Object diagram
Object diagrams represent static snapshots of instances of the things found in class
diagrams
These diagrams address the static design view or static process view of a system
An object diagram shows a set of objects and their relationships
A use case diagram shows a set of use cases and actors and their relationships
Use case diagrams address the static use case view of a system.
These diagrams are especially important in organizing and modeling the behaviors of a
system.
Interaction Diagrams
0
1
Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams
2
Interaction diagrams address the dynamic view of a system
3
A sequence diagram is an interaction diagram that emphasizes the time-ordering of
messages
4
A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages
5
Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take
one and transform it into the other
6
Statechart diagram
A statechart diagram shows a state machine, consisting of states, transitions, events, and
activities
Statechart diagrams address the dynamic view of a system
They are especially important in modeling the behavior of an interface, class, or
collaboration and emphasize the event-ordered behavior of an object
Activity diagram
0
An activity diagram is a special kind of a statechart diagram that shows the flow from
activity to activity within a system
1
Activity diagrams address the dynamic view of a system
2
They are especially important in modeling the function of a system and emphasize the flow
of control among objects
Component diagram
Deployment diagram
A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them
Deployment diagrams address the static deployment view of an architecture
Specification
Specification that provides a textual statement of the syntax and semantics
of that building block. The UML's specifications provide a semantic backplane that contains all the
parts of all the models of a system, each part related to one another in a consistent fashion
Adornments
Adornment Most elements in the UML have a unique and direct graphical
notation that provides a visual representation of the most important aspects of the element. A
class's specification may include other details, such as whether it is abstract or the visibility of its
attributes and operations. Many of these details can be rendered as graphical or textual adornments
to the class's basic rectangular notation.
Extensibility Mechanisms
The UML's extensibility mechanisms
1.
2.
3.
include
Stereotypes
Tagged values
Constraints
Stereotype
Stereotype extends the vocabulary of the UML, allowing you to create new kinds of building
blocks that are derived from existing ones but that are specific to your problem
A tagged value extends the properties of a UML building block, allowing you to create new
information in that element's specification
A constraint extends the semantics of a UML building block, allowing you to add new rules or
modify existing ones
6)Explain
Software Architecture
0
A system's architecture is perhaps the most important artifact that can be used to
manage these different viewpoints and so control the iterative and incremental development of a
system throughout its life cycle.
1
Architecture is the set of significant decisions about
0
The organization of a software system
1
The selection of the structural elements and their interfaces by which the system is
composed
2
Their behavior, as specified in the collaborations among those elements
3
The composition of these structural and behavioral elements into progressively larger
subsystems
The architectural style that guides this organization: the static and dynamic elements
and their interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior, but also with usage,
functionality, performance, resilience, reuse, comprehensibility, economic and technology
constraints and trade-offs, and aesthetic concerns.
Vocabulary
Assembly
Functionality
System
Configuration Mgmt
Design View
Behavior
Performance
Scalability
Throughput
Implementation
View
Use
case
view
Process View
Deployment
view
System topology
distribution delivery
installation
Design View
The design view of a system encompasses the classes, interfaces, and collaborations that form
the vocabulary of the problem and its solution.
This view primarily supports the functional requirements of the system, meaning the services
that the system should provide to its end users.
Process View
The process view of a system encompasses the threads and processes that form the system's
concurrency and synchronization mechanisms.
This view primarily addresses the performance, scalability, and throughput of the system
Implementation View
0
The implementation view of a system encompasses the components and files that are
used to assemble and release the physical system
1
This view primarily addresses the configuration management of the system's releases,
made up of somewhat independent components and files that can be assembled in various ways to
produce a running system.
Deployment view
0
The deployment view of a system encompasses the nodes that form the system's
hardware topology on which the system executes.
1
This view primarily addresses the distribution, delivery, and installation of the parts that
make up the physical system.