UML

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

Mohammad Ashraful Alam — Fri, 12 Sep 2008 15:35:10 GMT

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 which overcomes the limitation of typical modeling languages by providing revolutionary way within a single space to describe an application system with its structural and behavioral, as well as physical and logical components. It illustrates real world samples, from user interface experience, .NET specific language (such as C#) classes to database level SQL commands, to let software architects and developers to have a clean model for the future system. One of it’s the most powerful objectives of this new visual language is the besides an easy way to model the system, the target model will require near to zero knowledge on notation semantics from reader aspect.

Primary Objectives

The primary objectives of nAML can be considered as follows:

Provides a single space to visually describe one or more application systems with structural and behavioral components.
Provides a single space to visually describe one or more application systems with logical and physical components.
Provides a single space to visually describe one or more application systems from top to low level.
Provides a single space to visually describe a part or whole of one or more application systems.
Extremely simple and easy understand and learn from readers and designers perspective.
Concentrates on .NET applications, with its related logical and physical entities (user interface, application logic, business logic, database etc).

Links and Downloads

Here is the nAML project site: http://code.msdn.microsoft.com/nAML
Download the latest specification, examples and Visio 2003 Stencil for nAML tutorial from here.
Download Visio 2003 Stencil for nAML from here.

Technorati Tags: architecture,modeling,.net,asp.net,development

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

Mohammad Ashraful Alam — Fri, 14 Jul 2006 02:37:00 GMT

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 of view there are couple of solutions, based on the situation:

1. Initiator: the use case name should be given according to the initiator actor. For instance, in the ticket sells use case, if the sells man is the initiator, then the use case name should be “Sell a ticket”.
However there may be another new use case that can be associate with <<include>>/<<exclude>> relationship with this use case. In this case to show the association of the corresponding actor with the new use case, we need to explicitly mention this association. For example if there is a new use case is included “attend the concert” with the “Sell a ticket” use case, we don’t EXACTLY know who is attending the concert. Well putting a simple association with “Customer” actor and “attend the concert” use case says the customer will going to attend the concert.

2. Split the use case: if we want to show the responsibilities among the actors specifically, in that case we have to divide the functionality into two use cases. In our example: we can split the “ticket sells” functionality into two use cases: one is “sell a ticket”, which is associated with the “Salesman” actor and the other one is “buy a ticket” which is associated with the “Customer” actor. However to express the total functionality we have to associate these two use cases.
Any following use case from any of two use cases can automatically reflect the association of the corresponding actor of the first use case, with the current following use case. For example: If the “buy a ticket” use case follows or includes a new use case “attend the concert”, it automatically says or associates the “customer” actor, as it is associated with “buy a ticket”. However we can still associate “customer” with the “attend the concert” use case if we wish, which is semantically correct.

Notes:

Initiator: In a use case diagram, there are the common situations, where actor begins a use case and then the use case interacts with other use cases. However in this case we need to specify the initialization process. This can be done in two ways, either by using the <<initiates>> stereotype in the corresponding association line, or we can use a arrow head line, rather using simple association notation among the actor and the use case.

Use case generalization: As it is possible to generalize a use case with another use case, we should consider all the actors and use case related to the inheriting use case will be implemented to the inherited use case.

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

Mohammad Ashraful Alam — Fri, 14 Jul 2006 02:35:00 GMT

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: Casing and naming of the attributes and methods should be flexible enough (for instance with words with spaces).

Low level view:

1. Definition: This is an implementation level view of the identified entities, in the top level. Anyway this is not the EXACT view in implementation view, instead very near to the implementation model (regarding both in database and data access layer programming level). This level basically concentrates about the data fields, entities and relationships among them.
2. Benefit: Well, as we are considering UML rather using database schema diagram or traditional E-R diagram, we can analyze, identify, validate and finalize the data fields along with strong (and more meaningful) relationship notations.
3. Functional Requirements: As this level doesn’t correspond the EXACT implementation model, we can analyze and specify the functional requirements in more technical point of view with the analysis level flexibility. While mentioning functional solutions, in the methods portion, we can ignore commonly used functionalities (such as create, read all, read by id, update, delete etc).
4. Casing and naming standard: The filed names and entity names can’t be as flexible as real-world naming. Casing and naming should be done in such a way that they can be syntactically mapped to coding and database layers. However for functional issues, naming can be a bit flexible.
5. Notation: Commonly used UML relationship notations in this level are uni-directional association, aggregation/composition etc.
6. Generalization: Generalization is normally ignored in this layer, as we are mapping an object oriented design to RDBMS data entities, so the generalized relations will be mapped to additional physical entities in implementation level. For example: The Promoter and Agent was inherited in from the Promotion Worker entity in the top level view. In the implementation level the Promotion Worker entity will have a physical entity (or table) as Promotion Worker Type which will contains all other possible worker types include Promoter and Agent.
7. Dependency: Dependency relations in the top level generally mapped to one to many relations in the physical model. For example: Ticket depends on Event entity, in physical layer we can map the Event and Ticket entity as “One to many” relation.
8. Keys: Low level view will contain the primary key and foreign key attributes in the data entities. For any attribute that is a key should be suffixed with “ID” and the key type should be mentioned beside the name as <<PK>>, <<FK>> etc.

Different Views While Designing and Architecting Software

Mohammad Ashraful Alam — Mon, 10 Jul 2006 02:16:00 GMT

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 of view considers physical details, implementation details.

Scenario Analysis + Prototype = [Any Alternative??]

Mohammad Ashraful Alam — Sat, 08 Jul 2006 08:56:00 GMT

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 static in that sense, and are not able to give the idea about the accurate and dynamic behavior of the software.

I believe, an alternative visual language should be developed so that we can capture both requirements with same set of diagrams and notations and thus when both requirements will be full filled it will provide us a faster, clear and specific way to elicit, discover, understand and update the system requirements.