Het logische model: toepassingsdefinitie en -planning

De tweede stap in een COM+-toepassingsontwerpproces is het conceptueel model opsplitsen in de logische lagen van de architectuur met drie lagen: de presentatielaagof gebruikersservices; de middelste laagof zakelijke diensten; en de gegevenslaagof gegevensservices. Als u niet bekend bent met architectuur met drie lagen, raadpleegt u Een Three-Tier Architectuurmodel gebruiken.

Begin dit proces door het conceptuele model voor zelfstandige naamwoorden en werkwoorden te bekijken. De zelfstandige naamwoorden kunnen vaak worden omgezet in zakelijke objecten (klassen) en de werkwoorden die eraan zijn gekoppeld, kunnen worden omgezet in acties (methoden van de klassen). Hoewel het lastig kan zijn om alle zelfstandige naamwoorden te definiëren als zakelijke objecten, worden weglatingen of fouten duidelijk wanneer u het logische model voltooit.

De meeste zakelijke objecten komen terecht in de servicelaag voor bedrijven, waarbij de resterende objecten zijn verdeeld over gebruikersinterfaceobjecten in de laag gebruikersservices en gegevensobjecten in de gegevensserviceslaag. Houd rekening met het volgende bij het maken van een logisch model met behulp van de architectuur met drie lagen:

• Sommige zelfstandige naamwoorden in het conceptuele ontwerp vertegenwoordigen geen werkelijke fysieke gegevens, maar kunnen een actie op het systeem of de rol van een bedrijfsobject in het systeem vertegenwoordigen. Een bedrijfsobject kan ook een service zijn die een soort systeembeheer uitvoert, zoals een aanmeldings-id voor beveiliging.
• Vermijd het maken van vage zakelijke objecten door 'tussen de regels' te lezen in het conceptueel model. Dergelijke zakelijke objecten zijn mogelijk niet correct en u moet ze zorgvuldig overwegen voordat u ze in het logische model opgeeft. Als ze correct worden weergegeven, voegt u ze expliciet toe aan het conceptuele model.
• Vermijd het maken van zakelijke objecten die dezelfde informatie of functie uitdrukken; duplicatie kan kostbaar zijn in termen van toepassingssnelheid en prestaties.
• Objectafhankelijkheden bepalen. Sommige zelfstandige naamwoorden in het conceptuele model kunnen gewoon kenmerken van andere zakelijke objecten zijn. Bepaal of het kenmerk onafhankelijk kan bestaan. Als dat het geval is, moet het een eigen bedrijfsobject worden; als dat niet het geval is, moet deze worden gecombineerd met het juiste bedrijfsobject.
• Vermijd het maken van zakelijke objecten die te veel proberen uit te voeren. Overbelasting van zakelijke objecten kan betekenen dat er later meer tijd wordt besteed aan het scheiden van code en dat dit een onderhoudshoofdpijn kan zijn. Afzonderlijke objecten in het conceptuele model mogen niet worden gecombineerd; ze moeten afzonderlijke bedrijfsobjecten blijven. U kunt overeenkomsten afhandelen met behulp van code om hun algemene functies te delegeren aan een bedrijfsobject.
• Verwijder zakelijke objecten die niet worden gebruikt in gebruiksscenario's. Als de objecten zijn bedoeld voor toekomstige groei, kunt u overwegen deze te implementeren nadat de initiële toepassing is voltooid.

Op dit moment kunt u beginnen te denken aan de computers en code. Bepaal vanuit deze zakelijke services de weergave- en invoerfunctionaliteit die u als gebruikersservices moet leveren. Definieer welke tabellen en opgeslagen procedures moeten worden geleverd als gegevensservices. Als u het logische model wilt voltooien, definieert u de interfaces voor elke service en neemt u definities van elk gegevensveld en de bijbehorende validatieregels op. Neem ook alle functies, hun syntaxis en hun parameters op.

De definitie van de service of het object mag geen enkel aspect van de fysieke implementatie bevatten. De bedoeling is om een duidelijke richtlijn te bieden voor de opbouwfuncties voor logische onderdelen waaruit kan worden gewerkt en om andere programmeurs in staat te stellen onderdelen van de toepassing te coden die het onderdeel kunnen gebruiken voordat het daadwerkelijk wordt voltooid. In het ontwerp van het logische model moet u elk scherm, elke functie en elk object documenteren. Ga pas verder met het fysieke model of de implementatie als u aan deze criteria voldoet. Als u doorgaat terwijl het conceptuele model en het logische model niet in overeenstemming zijn, hebt u later in de ontwikkelingscyclus ernstige problemen.

Incrementele ontwikkeling van een COM+-toepassing is gebruikelijk. Dit omvat het maken van een subset van de uiteindelijke, bekende onderdelen en het testen ervan via elke laag van de toepassing: client-, bedrijfs- en gegevenslagen, via naar gegevensopslag. Dit werkmodel biedt inzicht in aanvullende vereisten door de klant en implementatieoverwegingen. Dit werkende model wordt vaak getest op één computer.

Verwante onderwerpen

het conceptuele model: toepassingsvereisten

Het fysieke model: toepassingsarchitectuur

een Three-Tier-architectuurmodel gebruiken