среда, 25 марта 2009 г.
вторник, 24 марта 2009 г.
вторник, 17 марта 2009 г.
JIRA Example
http://www.jetbrains.net/jira/secure/Dashboard.jspa
понедельник, 16 марта 2009 г.
Пример описания бизнес-процесса с помощью UML
Используется несколько нотаций для описания бизнес-процессов.
Пример 1 (UML):
http://www.interface.ru/fset.asp?Url=/misc/uml1.htm
Пример 2 (UML): http://www.intuit.ru/department/se/ibmrrose/11/4.html
Пример 1 (UML):
http://www.interface.ru/fset.asp?Url=/misc/uml1.htm
Пример 2 (UML): http://www.intuit.ru/department/se/ibmrrose/11/4.html
Бизнес-процесс и бизнес-правила
Бизнес-процесс представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью ресурсов входы процесса преобразуются в выходы, результаты процесса, представляющие ценность для потребителей. Wikipedia
Бизнес-правила представляют собой специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении.
В общем случае существует три типа правил. К первому типу принадлежат правила вывода. Правило вывода (derivation rule) преобразует полученную информацию в возвращаемые значения. Например, скидки на товары можно вычислить с помощью специального алгоритма, учитывающего размер заказа, рекламную поддержку и значимость клиента, которому будут поставляться товары. Правила этого типа допускают изменения, и поэтому, прежде чем с ними можно было работать, их требуется выделить.
Второй тип правил - правила ограничения. Правило ограничения (constraint rule) проверяет значения транзакции или операции на непротиворечивость. Например, чтобы заказчик получил письмо, почтовый индекс на письме должен соответствовать индексу штата, в котором проживает заказчик. Эти правила могут использоваться для изучения взаимосвязей между объектами, например, когда все клиенты имеют адресующие объекты в интернет-магазине видеоаппаратуры. Кроме того, они могут применяться вместе с Булевыми результатами. Если они не истинны, то мы не сможем продолжить или завершить операцию.
Наконец, существуют инвариантные правила. Инвариантные правила (invariant rules) проверяют множественные изменения и обеспечивают непротиворечивость итоговых результатов. Например, баланс сберегательного счета должен быть равен предыдущему балансу плюс сумма прихода или минус сумма расхода. Если у вас что-то не сходится, значит, ваша система теряет деньги, и пришло время поднять исключение на более высокий уровень.
http://www.interface.ru/home.asp?artId=1752
Бизнес-правила представляют собой специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении.
В общем случае существует три типа правил. К первому типу принадлежат правила вывода. Правило вывода (derivation rule) преобразует полученную информацию в возвращаемые значения. Например, скидки на товары можно вычислить с помощью специального алгоритма, учитывающего размер заказа, рекламную поддержку и значимость клиента, которому будут поставляться товары. Правила этого типа допускают изменения, и поэтому, прежде чем с ними можно было работать, их требуется выделить.
Второй тип правил - правила ограничения. Правило ограничения (constraint rule) проверяет значения транзакции или операции на непротиворечивость. Например, чтобы заказчик получил письмо, почтовый индекс на письме должен соответствовать индексу штата, в котором проживает заказчик. Эти правила могут использоваться для изучения взаимосвязей между объектами, например, когда все клиенты имеют адресующие объекты в интернет-магазине видеоаппаратуры. Кроме того, они могут применяться вместе с Булевыми результатами. Если они не истинны, то мы не сможем продолжить или завершить операцию.
Наконец, существуют инвариантные правила. Инвариантные правила (invariant rules) проверяют множественные изменения и обеспечивают непротиворечивость итоговых результатов. Например, баланс сберегательного счета должен быть равен предыдущему балансу плюс сумма прихода или минус сумма расхода. Если у вас что-то не сходится, значит, ваша система теряет деньги, и пришло время поднять исключение на более высокий уровень.
http://www.interface.ru/home.asp?artId=1752
Rump Up - обучающие ресурсы Microsoft
Ramp Up is a free, online, community-based learning program, with a number of different tracks that will help you build your portfolio of professional development skills. Ramp Up has a solid foundation of premium technical content from subject-matter gurus, and provides easy-to-access content in a variety of forms that guide you in learning the important skills. Join Ramp Up (it's free!) and help advance your career - click on a track now to start!
Примеры бизнес-приложений
На сайте компании Борлас подробный перечень бизнес-приложений Oracle
среда, 11 марта 2009 г.
Association, aggregation and composition
Problem: UML has several relations (association, aggregation and composition) that seem to all mean the same thing : "has a".
So, what is the difference between them?
http://ootips.org/uml-hasa.html
Association represents the ability of one instance to send a message to another instance. This is typically implemented with a pointer or reference instance variable, although it might also be implemented as a method argument, or the creation of a local variable.
[Example:]
|A|----------->|B|
class A
{
private:
B* itsB;
};
Aggregation [...] is the typical whole/part relationship. This is exactly the same as an association with the exception that instances cannot have cyclic aggregation relationships (i.e. a part cannot contain its whole).
[Example:]
|Node|<>-------->|Node|
class Node
{
private:
vector itsNodes;
};
The fact that this is aggregation means that the instances of Node cannot form a cycle. Thus, this is a Tree of Nodes not a graph of Nodes.
Composition [...] is exactly like Aggregation except that the lifetime of the 'part' is controlled by the 'whole'. This control may be direct or transitive. That is, the 'whole' may take direct responsibility for creating or destroying the 'part', or it may accept an already created part, and later pass it on to some other whole that assumes responsibility for it.
[Example:]
|Car|<#>-------->|Carburetor|
class Car
{
public:
virtual ~Car() {delete itsCarb;}
private:
Carburetor* itsCarb
};
So, what is the difference between them?
http://ootips.org/uml-hasa.html
Association represents the ability of one instance to send a message to another instance. This is typically implemented with a pointer or reference instance variable, although it might also be implemented as a method argument, or the creation of a local variable.
[Example:]
|A|----------->|B|
class A
{
private:
B* itsB;
};
Aggregation [...] is the typical whole/part relationship. This is exactly the same as an association with the exception that instances cannot have cyclic aggregation relationships (i.e. a part cannot contain its whole).
[Example:]
|Node|<>-------->|Node|
class Node
{
private:
vector
};
The fact that this is aggregation means that the instances of Node cannot form a cycle. Thus, this is a Tree of Nodes not a graph of Nodes.
Composition [...] is exactly like Aggregation except that the lifetime of the 'part' is controlled by the 'whole'. This control may be direct or transitive. That is, the 'whole' may take direct responsibility for creating or destroying the 'part', or it may accept an already created part, and later pass it on to some other whole that assumes responsibility for it.
[Example:]
|Car|<#>-------->|Carburetor|
class Car
{
public:
virtual ~Car() {delete itsCarb;}
private:
Carburetor* itsCarb
};
четверг, 5 марта 2009 г.
Отличный инструмент для создания иллюстраций - копий экрана Cropper
среда, 4 марта 2009 г.
Подписаться на:
Сообщения (Atom)