0% found this document useful (0 votes)
97 views11 pages

MC 0069-02 Sys Analy and Design

Stereotypes allow users to extend the UML by creating new modeling elements with their own properties, semantics, and notation. Tagged values add new metadata properties to UML elements. Constraints specify rules that must be true for the model to be valid, and can be used to change element semantics or define new semantics. Modeling a logical database schema involves identifying persistent classes, detailing their structure and attributes, and considering how they will be stored in a physical database. When modeling responsibilities in a system, classes should each have a clear role and collaborate without any single class having too many or too few responsibilities.

Uploaded by

shrikrush
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
97 views11 pages

MC 0069-02 Sys Analy and Design

Stereotypes allow users to extend the UML by creating new modeling elements with their own properties, semantics, and notation. Tagged values add new metadata properties to UML elements. Constraints specify rules that must be true for the model to be valid, and can be used to change element semantics or define new semantics. Modeling a logical database schema involves identifying persistent classes, detailing their structure and attributes, and considering how they will be stored in a physical database. When modeling responsibilities in a system, classes should each have a clear role and collaborate without any single class having too many or too few responsibilities.

Uploaded by

shrikrush
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 11

MC 0069 - 02

SYSTEMS ANALYSIS AND DESIGN

4) Define stereotype, tagged value and constraint.

Stereotypes:The UML provides a language for structural things, behavioral things, grouping things,
and notational things.

these four basic kinds of things address the overwhelming

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.

For ex, if we are

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.

Constraints:Everything in the UML has its own semantics.

Generalization implies the Liskov

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.

6) Explain the process of modeling a logical database schema.


Many of the systems well model will have persistent objects which mean that they can
be stored in a database for later retrieval. Most often, well use a relational database, an
object oriented database, or a hybrid object/relational database for persistent storage.
The UML is well suited to modeling logical database schemas, as well as physical
databases themselves.
The UMLs class diagrams are a superset of entity relationship (E-R) diagrams, a
common modeling tool for logical database design. Whereas classical E-R diagrams

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

necessary, create intermediate abstractions to simplify our logical structure.


-

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.

When we model a schema, well generally want to model the

relationship to any non-primitive types using an explicit aggregation rather than an


attribute.
Two of these classes (School and Department) expose several operations for
manipulating their parts. These operations are included because they are important to
maintain data integrity (adding or removing a Department like, will have some rippling
effects). There are many other operations that we might consider for these and the other
classes, such as querying the prerequisites of a course before assigning a student. These
are more business rules than they are operations for database integrity and so are best
placed at a higher level of abstraction than this schema.

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.

Identify a set of responsibilities for each of these classes.

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.

When we model a systems architecture, we capture decisions about the

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.

As necessary, decompose the system into its elementary subsystems.

The following activities apply to the system, as well as to the subsystems.


-

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 an implementation view of the system, encompassing the components


that are used to assemble and release the physical system. Apply component
diagrams to model static aspects, and interaction diagrams, statechart diagrams,
and activity diagrams to model the dynamic aspects.

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.

9) Explain the behavioral aspects of collaboration with an example.


The structural part of a collaboration is typically rendered using a class diagram. But the
behavioral part of a collaboration is typically rendered using an interaction diagram. AN
interaction diagram specifies an interaction that represents a behavior comprised of a set
of messages that are exchanged among a set of objects with a context to accomplish a
specific purpose. An interactions context is provided by its enclosing collaboration,
which establishes the classes, interfaces, components, nodes and other structural
elements whose instances may participate in that interaction.
The behavioral part of a collaboration may be specified by one or more
interaction diagrams. If we want to emphasize the time ordering of messages, we can
use a sequence diagram. If we want to emphasize the structural relationships among
these objects as they collaborate, we have to use a collaboration diagram.

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

The behavioral parts of a collaboration must be consistent with its structural


parts. This means that the objects found in a collaborations interactions must be
instances of classes found in its structural part. Similarly, the messages named in an
interaction must relate to operations visible in the collaborations structural part. We can
have more than one interaction associated with a collaboration, each of which may show
a different but consistent aspect of its behavior.

11

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy