MC 0069-02 Sys Analy and Design
MC 0069-02 Sys Analy and Design
Stereotypes:The UML provides a language for structural things, behavioral things, grouping things,
and notational things.
majority of the systems we will need to model. However, sometimes well want to
introduce new things that speak the vocabulary of the domain and look like primitive
building blocks.
A stereotype is not the same as a parent class in a parent/child generalization
relationship. Rather, we can think of a stereotype as a metatype, because each one
creates the equivalent of a new class in the UMLs metamodel.
modeling a business process, well want to introduce things like workers, documents,
and policies. Similarly, if we are following a development process, such as the Rational
Unified Process, well want to model using boundary, control, and entity classes. This is
where the real value of stereotypes comes in. When we stereotype an element such as
node or a class, we are in effect extending the UML by creating a new building block
just like an existing one but with its own special properties ( each stereotype may
provide its own set of tagged values), semantics (each stereotype may provide its own
constraints), and notation (each stereotype may provide its own icon).
In its simplest form, a stereotype is rendered as a name enclosed by guillemots (for ex,
name) and placed above the name of another element. As visual cue, we may define
an icon for the stereotype and render that icon to the right of the name (if we are using
the basic notation for the element) or use that icon as the basic symbol for the
stereotyped item.
When we define an icon for a stereotype, consider using color as an accent to provide a
subtle visual cue. But the color should be used sparingly. The UML lets us use any
shape for such icons, and if our implementation permits it, these icons might appear as
primitive tools so that the users who create the UML diagrams will have a palette of
things that look basic to them and speak the vocabulary of their domain.
Tagged Values:Everything in the UML has its own set of properties; classed have names, attributes, and
operations; associations have names and two or more ends (each with its own
properties); and so on. With stereotypes, we can add new things to the UML; with
tagged values, we can add new properties.
We can define tags for existing elements of the UML, or we can define tags that apply to
individual stereotypes so that everything with that stereotype has that tagged value. A
tagged value is not the same as a class attribute. Rather, we can think of a tagged value
as a metadata because its value applies to the element itself, not its instances. For ex, if
we might want to specify the number of processors installed on each kind of node in a
deployment diagram, or we might want to require that every component be stereotyped
as a library if it is intended to be deployed on a client or server.
In its simplest form, a tagged value is rendered as a string enclosed by brackets and
placed below the name of another element. That string includes a name (the tag),
separator (the symbol = ), and a value ( of the tag). We can specify just the value of its
meaning is unambiguous, such as when the value is the name of enumeration.
One of the most common uses of tagged values is to specify properties that are relevant
to code generation or configuration management.
substitution principle, and multiple associations connected to one class denote distinct
relationships. With constraints, we can add new semantics or change existing rules. A
constraint specifies conditions that must be held true for the model to be well formed.
Constraints may be written as free form text. If we want to specify semantics more
precisely, we can use the UMLs Object Constraint Language (OCL), described further
in The Unified Modeling Language Reference Manual.
A constraint is rendered as a string enclosed by brackets and placed near the associated
element. This notation is also used as an adornment to the basic notation of an element
to visualize paerts of an elements specification that have no graphical cue. for ex, some
properties of association (order and changeability) are rendered using constraint
notation.
focus only on data, class diagrams go a step further by permitting the modeling of
behavior, as well. In the physical database, these logical operations are generally turned
into triggers or stored procedures.
To model a schema
-
Identify those classes in our model whose state must transcend the lifetime of
their applications.
Create a class diagram that contains those classes and mark them as persistent ( a
standard tagged value). We can define our own set of tagged values to address
database-specific details.
Expand the structural details of these classes. In general, this means specifying
the details of their attributes and focusing on the associations and their
cardinalities that structure these classes.
Watch for common patterns that complicate physical database design, such as
cryptic associations, one-to-one associations, and n-ary associations.
Where
Consider also the behavior of these classes by expanding operations that are
important for data access and data integrity. In general, to provide a better
separation of concerns, business rules concerned with the manipulation of sets of
these objects should be encapsulated in a layer above these persistent classes.
Where possible, we should use tools to help us transform our logical design into
a physical design.
The example figures under shows a set of classes drawn from an information system for
a school. This figure expands upon an earlier class diagram, and we will see the details
of these classes revealed to a level sufficient to construct a physical database. Starting at
the bottom left of this diagram, we find the classes named Student, Course, and
Instructor. Theres an association between Student and Course, specifying that students
attend courses. Furthermore, every student may attend any number of courses and every
course may have any number of students.
All six of these classes are marked as persistent, indicting that their instances are
intended to love in a database or some other form of persistent store. This diagram also
exposes the attributes of all six of these classes. We can notice that all the attributes are
primitive types.
2) What are the considerations that should be taken care to model the distribution
of responsibilities in a system?
Once we start modeling more than a just a handful of classes, we will want to be sure
that our abstractions provide a balanced set of responsibilities. What this means is that
we dont want any one class to be too big or too small. Each class should do one thing
well. If we abstract classes that are too big, well find that our models are hard to
change and are not very reusable. If we abstract classes that are too small, well end up
with many more abstractions than we can reasonably manage or understand. We can use
the UML to help us visualize and specify this balance of responsibilities.
To model the distribution of responsibilities in a system,
-
Identify a set of classes that work together closely to carry out some behavior.
Look at this set of classes as a whole, split classes that have too many
responsibilities into smaller abstractions, collapse tiny classes that have trival
responsibilities into larger ones, and reallocate responsibilities so that each
abstraction reasonably stands on its own.
Consider the ways in which those classes collaborate with one another, and
redistribute their responsibilities accordingly so that no class within collaboration
does too much or too little.
The figure below shows a set of classes drawn from Smalltalk, showing the distribution
of responsibilities among Model, View, And Controller classes. We can see how all
these classes work together such that no one class does too much or too little.
10) Explain with a neat diagram how you would model the architecture of a system.
The most common use for which well apply systems and models is to organize the
elements we use to visualize, specify, construct, and document a systems architecture.
Ultimately, this touches virtually all the artifacts we will find in a software development
project.
systems requirements, its logical elements, and its physical elements. We will also
model both structural and behavioral aspects of the systems and the patterns that shape
these views. Finally, we will want to focus on the seams between subsystems and the
tracing from requirements to deployment.
To model the architecture of a system,
-
Identify the views that we will use to represent the architecture. Most often,
well want to include a use case view, a design view, a process view, an
implementation view, and a deployment view.
Specify the context for this system, including the actors that surround it.
Specify a use case view of the system, encompassing the use cases that describe
the behavior of the system as seen by its end users, analysts, and testers. Apply
use case diagrams to model static aspects, and interaction diagrams, statechart
diagrams, and activity diagrams to model the dynamic aspects.
-
Specify a design view of the system, encompassing the classes, interfaces, and
collaborations that form the vocabulary of the problem and its solution. Apply
class diagrams and object diagrams to model static aspects, and interaction
diagrams, statechart diagrams, and activity diagrams to model the dynamic
aspects.
Specify a process view of the system, encompassing the threads and processes
that form the systems concurrency and synchronization mechanisms. Apply the
same diagrams as for the design view, but with a focus on active classes and
objects that represent threads and processes.
Specify a deployment view of the system, encompassing the nodes that form the
systems hardware topology on which the system executes. Apply deployment
diagrams to model static aspects, and interaction diagrams, statechart diagrams,
and activity diagrams to model the dynamic aspects.
Model the architecture patterns and design patterns that shape each of these
models using collaborations.
We should understand that we dont ever create a systems architecture in one big-bang
event. Rather, a well structured process for the UML involves the successive refinement
of a systems architecture in a manner that is use case driven, architecture-centric, and
iterative and incremental.
For all but the most trivial systems, we have to manage versions of our systems
artifacts. We can use UMLs extensibility mechanisms and tagged values, in particular
to capture our decisions about the version of each element.
Either
diagram is appropriate because, for most purposes, they are semantically equivalent.
This means that when we model a society of classes by naming their interaction
as a collaboration, we can zoom inside that collaboration to expose the details of their.
10
11