UML

UML modeling guidelines, tips and can include some of my experiences while modeling.

nAML: A New Revolutionary Way to Model Your .NET Applications!

Understanding the architecture and code in software application plays as major factors while building good software products. Having an easy to understand visual notation, not only helps architects to model the system efficiently, but also helps developers to quickly implement that, as well as it helps the re-engineering process to easily adopt the architectural model with respect to new requirement. A new visual modeling technique, termed as “nAML” (.NET Application Modeling Language) is being introduced ...
Print | posted on Posted On Friday, September 12, 2008 9:35 PM | Comments (1)

Removing Confusion While Creating Use Cases, Regarding Actor Responsibilities/Association

While developing use cases, the designer often faces a confusing situation to name the use case, while this is associated by multiple actors. For instance, a salesman sells a concert ticket to the customer. In this case there are two actors salesman, customer and one use case. What will be the use case name??? “Sell a ticket” ? or “Buy a ticket”? Since both actors are associated, how we can recognize specifically which actor is buying or selling the ticket? Well from my point ...
Print | posted on Posted On Friday, July 14, 2006 8:37 AM | Comments (0)

Some Common Issues That Should Be Considered While Creating UML Class Diagrams

Top level view: 1. Definition: Use standard dependency, aggregation, composition, generalization, associations where possible to identify, illustrate data entities and their relationships. 2. Restriction: As this is top level view, we don’t have to consider the primary key, foreign key issues here.3. Functional Requirements: Rather mentioning commonly used functionalities, we will mention specific functional requirements in the “Method” portion of each classes.4. Casing and Naming: ...
Print | posted on Posted On Friday, July 14, 2006 8:35 AM | Comments (2)

Different Views While Designing and Architecting Software

Domain view: which considers the domain environment of the system, based on which the future system will be developed. This is also known as ‘existing system’. Design view: This is the view of the future (or the proposed) system, which is being built after analyzing domain view. Top level view: Considers the system (domain or design) from very abstract level, hiding underlying details. We can also consider this view as ‘analysis view’.Implementation/low level view: This level ...
Print | posted on Posted On Monday, July 10, 2006 8:16 AM | Comments (0)

Scenario Analysis + Prototype = [Any Alternative??]

Regarding software requirements, there are several scenarios, generally that should be illustrated, considering different conditions while using the software. When we use UML, two types of diagrams comes in place, one is 'Activity diagram' which preferably can be used from top level perspective or the 'Interaction diagrams' (Sequence/Collaboration diagrams) in that case. On the other hand 'Screen Mockups' or 'Prototypes' are used to illustrate the snaps of the real software, well but mock-up are ...
Print | posted on Posted On Saturday, July 08, 2006 2:56 PM | Comments (0)

Copyright © Mohammad Ashraful Alam