Group Members

Aishwaraya Jay shree Santhosh kumar Surender Vijayan Vishnu arthi

y Visual modeling. y UML. y When can we use UML? y Diagrams. y USE CASE Diagram y Actors y Use cases y Stereotypes y Use case diagram for designer as knowledge creator

and user. y References

y Software models are similar to

Mechanical Drawings

Electrical Schematics

Construction Blueprints

OR

7 source files 940 lines of code

One diagram

A picture is worth a thousand lines of code

DOCUMENTATION

REAL APPLICATION

METRICS

y Unified Modeling Language

An industry standard notation for

y Expressing software Requirements. y Expressing software Architecture. y Expressing software Dynamics and Behavior. y Documenting Software Deployment.

y The UML is the standard notation only. y It does not specify process at all. y UML is most effective when combined with effective

software process.

y Visual UML modeling has been traditionally focused on

ANALYSIS and DESIGN

Require-ments

Analysis

Design

Implementation

Testing

y CLARITY: Graphical Depiction of ideas are easy to

understand. y AUDIENCE: This Clarity allows a wider audience to understand and participate. y DISCIPLINE: Modeling, as a rigorous technique, imposes discipline on the specifications of business problems and a common language to understand and resolve them.

An actor specifies a role that some external entity adopts when interacting with your system directly. It may represent a user role, or a role played by another system, that touches the boundary of your system. Identifying actors
y Who or what uses the system? y What roles do they play in the interaction? y Who installs the system? y Who starts and shutdowns the system? y Who maintains the system? y Who gets and provides information to the system?

A specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem or class can perform by interacting with outside actors. Finding Use Cases
starts with the actors previously defined y Which functions does the actor require from the system? What does the actor need to do? y Does the actor need to read, create, destroy, modify, or store some kind of information in the system? y Does the actor have to be notified about events in the system, or does the actor need to notify the system about something?

A use-case description can be rather difficult to overview if it contains too many alternatives, optional or exceptional flows of events that are performed only if certain conditions are met as the use-case instance is carried out.

This relationship occurs when you have behaviors that are similar across more than one use case and you don t want to redundantly copy the behavior in each use case.

y Develop a knowledge base system. The software must

provide the following requirements

y The knowledge base system must contain the process,

procedures etc.., for manufacturing products. y Designers should be able to create knowledge base system. y Designers should be able to get details from knowledge base for design tasks. y Knowledge base or data base should be able to store knowledge base data.

y The object advantage business process reengineering

with object technology- IVAR JACOBSON y UML and the Unified Process practical object-oriented Analysis and Design- JIM ARLOW & ILA NEUSTADT y CIM journal- Fostering continuous innovation in design with an integrated knowledge management approach-Jing Xu

y UNIFIED: Result of unifying the information systems

and technology industry s best engineering practices. y MODELING: a number of models are used to describe the system. y LANGUAGE: not simply a notation for drawing diagrams, but a complete language or capturing semantics about a subject and expressing the same for the purpose of communication.