Jumat, 11 Mei 2012
Selasa, 10 Januari 2012
UML
The Unified Modeling Language (UML) has quickly become the de-facto standard for building Object-Oriented software. This tutorial provides a technical overview of the 13 UML diagrams supported by Enterprise Architect. UML 2 semantics are explained in detail in the new UML 2.0 tutorial.
Firstly... What is UML?
The OMG specification states:
"The Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual
things such as business processes and system functions as well as concrete things such
as programming language statements, database schemas, and reusable software
components."
The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process.
UML defines the notation and semantics for the following domains:
- The User Interaction or Use Case Model - describes the boundary and interaction between the system and users. Corresponds in some respects to a requirements model.
- The Interaction or Communication Model - describes how objects in the system will interact with each other to get work done.
- The State or Dynamic Model - State charts describe the states or conditions that classes assume over time. Activity graphs describe the workflows the system will implement.
- The Logical or Class Model - describes the classes and objects that will make up the system.
- The Physical Component Model - describes the software (and sometimes hardware components) that make up the system.
- The Physical Deployment Model - describes the physical architecture and the deployment of components on that hardware architecture.
The UML also defines extension mechanisms for extending the UML to meet specialized needs (for example Business Process Modeling extensions).
Firstly... What is UML?
The OMG specification states:
"The Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual
things such as business processes and system functions as well as concrete things such
as programming language statements, database schemas, and reusable software
components."
The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process.
UML defines the notation and semantics for the following domains:
- The User Interaction or Use Case Model - describes the boundary and interaction between the system and users. Corresponds in some respects to a requirements model.
- The Interaction or Communication Model - describes how objects in the system will interact with each other to get work done.
- The State or Dynamic Model - State charts describe the states or conditions that classes assume over time. Activity graphs describe the workflows the system will implement.
- The Logical or Class Model - describes the classes and objects that will make up the system.
- The Physical Component Model - describes the software (and sometimes hardware components) that make up the system.
- The Physical Deployment Model - describes the physical architecture and the deployment of components on that hardware architecture.
The UML also defines extension mechanisms for extending the UML to meet specialized needs (for example Business Process Modeling extensions).
Selasa, 03 Januari 2012
UML
Use Case Diagrams
Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.
Note, that UML 2.4 specification also describes use case diagrams as a specialization of class diagrams, and class diagrams are structure diagrams.
Use case diagrams are in fact twofold - they are both behavior diagrams (because they describe behavior of the system), and they are also structure diagrams - as a special case of class diagrams where classifiers are restricted to be either actors or use cases related with association.
Use case diagrams are used to specify:
(external) requirements on a subject, required usages of a system - to capture what a system under construction is supposed to do;
the functionality offered by a subject – what system can do;
requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services.
Major elements of the use case diagram are shown on the picture below.
UML use case diagram major elements.
Use case diagram major elements.
You can find some examples of use case diagrams here:
Business model - Airport check-in and security screening
Business model - Restaurant
e-Library online public access catalog use cases
Point of Sales Terminal
Use cases for a retail website
Credit card processing system
ATM use cases
Hospital Management
Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.
Note, that UML 2.4 specification also describes use case diagrams as a specialization of class diagrams, and class diagrams are structure diagrams.
Use case diagrams are in fact twofold - they are both behavior diagrams (because they describe behavior of the system), and they are also structure diagrams - as a special case of class diagrams where classifiers are restricted to be either actors or use cases related with association.
Use case diagrams are used to specify:
(external) requirements on a subject, required usages of a system - to capture what a system under construction is supposed to do;
the functionality offered by a subject – what system can do;
requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services.
Major elements of the use case diagram are shown on the picture below.
UML use case diagram major elements.
Use case diagram major elements.
You can find some examples of use case diagrams here:
Business model - Airport check-in and security screening
Business model - Restaurant
e-Library online public access catalog use cases
Point of Sales Terminal
Use cases for a retail website
Credit card processing system
ATM use cases
Hospital Management
Langganan:
Postingan (Atom)