Archives
now browsing by author
Business continuity management – how to model it
Business Continuity Management (BCM) projects are really difficult . The main reason is the system complexity: many documents, many tasks, many processes, many associations between all of them. Each task connected to one or more business application. Each documents stored in different database. The applications are integrated. Everything works like one chain ? but one broken link can crash everything .
How we can managing risks? We can create Business Architecture model and expand this up to Enterprise Architecture, as a model for trace process, data, IT system and infrastructure.
How we prepare Enterprise Architecture model? Simple version: prepare business model :
Transform this to use case model (application services) :
Build matrix for trace mapping control :
Trace (map) use case to software components :
We have completed model, we can do impact analysis, e.g. what happens and where, when the Ruter go down:
Sometimes we ask: what does the possibility of carrying out the Package Goods task depend on?
How can we do this and what tools do we need? Welcome in my courses, hire me …
References
Types instead of inheritance
Many time we can see requirement written as a “class diagram for project”. What “class diagram” mean? We can use UML class diagram for: architecture model, notions model, sometimes other. Which type of model do you need? Class diagram is a tool. When we say model, we have to provided context: model of what?
We use inheritance in models of notions (for building taxonomies), never in architecture.. In architecture models we use types. In 2015 OMG published UML v.2.5. Inheritance was removed from UML . Why? Welcome in my courses?
References
Systems analysis and design
Many time we heard about agile in software development. Many times authors wrote that agile provide us to fast and cheapest solutions. It is true but not all the times. Chaos Report (see Standish Group) show us, that is not true all the times.
Few comments…
Generally small projects are not a (big) problem..
Waterfall vs. agile: first one method consume many more time than second one, but we have no time to ‘big analysis’. Second one mean ‘working too fast’, and effect is more prototyping mean cost increasing… many time mean: cancel project before finish caused by budget:
A waterfall is not a solution, but agile is not a good remedy for it. A common problem in software design is system size and complexity:
How to improve quality and chance to succeed software project? We need really good person to business analysis role and only one. More than one person in a first stage, mean more problem with merging parts to one completed and unambiguous requirements document :
Disciplined agile, what is it? Using models in agile, why and for what? Modern system analysis and design is not a waterfall and not a agile style? It is science method used for software engineering . Discover the MDA and patterns as a wand for your success in software projects. See the system as a architecture .
More about general systems and SysML notation coming soon ?
Try my courses for improve your skills and your teammates, hire me as a gifted person in your project.
References
Why using extend and include stereotypes in OOAD projects is wrong?
Many analyst and UML practitioner use Use Cases as a “process model”. It is really bad idea. As we say “we use OOAD methods”, it means we use object paradigm. The fundatin of OOAD is hermetization, but ‘include’ and ‘extend’ dependencys break this rule.
A lots of time we see diagrams like this:
Uses Case models with include and extend stereotypes
A few citation (UML specification) :
A UseCase is a kind of Behaviored Classifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (UML, 18.1.3.1 Use Cases and Actors)
Important sentence: without reference to its internal structure (see what encapsulation means below).
An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. (UML, 18.1.3.2 Extends)
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. (UML, 18.1.3.3 Includes).
Object oriented paradigm based on main concepts:
- object (part of system)
- encapsulation (objects hides their implementation)
- polymorphism (one operation could be implemented by more then one methods)
- cooperation (objects cooperate to achieve the particular goal)
In OOAD <<include>> and <<extend>> breaks encapsulation (we can’t use use diagram to modeling any internal application or component structure/architecture). , .
Need more arguments and explanation? Try my courses…
References
New era
First and short post. After six years visiting Scotland to visit tourist attractions, spending time on folk festivals and traditional music sessions in pubs (I play whistle), now it’s time to start living in Scotland. It means I have to move and continue my business activities here. What is my business? I’m analyst and system designer, providing business analysis, business logic and software design, systems architecture design. Researcher and lecturer as well.
Wish me luck… try me for free…
On modelling errors
In response to numerous questions, I have produced an example of such an analysis. This analysis is presented in a simplified form in order to demonstrate its content and not its volume. The content and degree of detail are each time determined by the context and purpose of the project. Those interested in this document are invited to the modelling course: Project
Source: O błędach w modelowaniu – Jarosław Żeliński IT-Consulting