MEDIU Software Development Architecture
Policies & Guideline
Draft Version 1.0
8 October 2007
1|Page
Author
Date
Description
Version
Irwan Azam Bin Ahmad
02/09/2007
Initial Draft – MEDIU
Software Development
Architecture
1.0
Irwan Azam Bin Ahmad
03/10/2007
Add In Agile Principles,
Patterns, and Practices
1.1
2|Page
Table of Contents
1. Agile Development
2. Agile Principles
3. Agile Methodology (Unified Process)
Iterative Development
Best Practices and Key Concept
Benefit of Iterative Development
Development Case
Inception/ Initial Exploration
User Stories
Spiking, Splitting and Velocity
Use Case Format
Use Case Diagram
Inception Checkpoint
Supplementary Specification
Elaboration
Domain Model
Sequence Diagram
Business Rules Specification
4. Practice of Extreme Programming
5. Domain Driven Design
Crunching Knowledge
Ubiquitous Language
Layered Architecture
Design Pattern
Domain Driven Design Checklist
6. Test Driven Development
Acceptence Test
7. NHibernate
8. Dependency Injection
9. Mock
10. Refactoring
11. Stress Test
3|Page
MEDIU - Software Development Architecture Guideline
Agile Development
Every software program relates to some activity or interest of its user. That subject area to which the
user applies the program is the domain of the software. Some domains involve the physical world. The
domain of an airline-booking program involves real people getting on real aircraft. Some domains are
intangible. The domain of an accounting program is money and finance. Software domains usually have
little to do with computers, though there are exceptions. The domain of a source code control system is
software development itself.
To create software that is valuably involved is users activities, a development team must bring to bear a
body of knowledge related to those activities. The breath of knowledge required can be daunting.
A domain model is not a particular diagram, it is the idea that the diagram is intended to convey. It is not
just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of
the knowledge.
This document is as a guideline for developer to practice Agile ExtremeProgramming, Domain Driven
Design and Test Driven Development in software development lifecycle.
Agile Principles











Our highest priority is to satisfy the customer/user through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhance agility.
Simplicity – the art of maximizing the amount of work not done – essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly
4|Page
Agile Methodology Practices (Unified Process)
Agile implies a light and adaptive process meaning that any change should be accepted as inevitable
driver and encourages flexible adaption; they usually have an iterative lifecycle of software
development.
Iterative Development
Iterative development is a skillful approach to software development. Development is
organized into a series of short, fixed-length (for example four week) mini projects called
iterations; the outcome of each is a tested, integrated and executable system. Even though
it has all the process but it is not ready to deliver to production. The system may not be
eligible for production deployment until after many iterations; for example 5 to 10
iterations. Each iteration includes its own requirement analysis, design implementation and
testing activities.
The iterative lifecycle is based on the successive enlargement and refinement of a system
through multiple iterations, with cyclic feedback and adaptation as core drivers to converge
upon suitable system. The system growth incrementally over time, iteration by iteration and
thus this approach is also known as iterative and incremental development.
Each iteration involves choosing a small subset of the requirements, and quickly designing,
implementing and testing. In early iterations the choice of requirements and design may not
be exactly what is ultimately desired. The output of an iteration is not experimental or
throw-away prototype, and iterative development is not prototyping. Rather, the output is a
production grade subset of the final system. Once an iteration has been started, the
business agrees not to change the definition or priority of the stories in that iteration.
People are the most important ingredient of success. A strong player is not necessarily an
ace programmer. A strong player may be an average programmer but someone who works
well with others. Working well with others communicating and interacting is more
important than raw programming talent. A team of average programmers who
communicate well are more likely to succeed than a group of superstars who fail to interact
as a team. Building the team is more important that building the environment. Many teams
and managers make mistake of building the environment first and expecting the team to gel
automatically. Instead, work to create the team, and let the team configure the
environment on the basis of need.
Best Practices and Key Concepts:

Tackle high-risk and high-value issues in early iterations – For example, if the new
system is a server application that has to handle 2000 concurrent clients with subsecond transaction response time, do not wait for many month (or years) to design
5|Page
and implement this high risk requirement. Rather, quickly focus on designing,
programming, and proving the essential software components and architecture for
this risky issue; leave the easier work till later iterations. The idea is to drive down
the high risks in the early iterations, so that the project dos not fail late. Better to
fail early if at all, by doing the hard thing first. Thus the Agile UP is said to be risk
driven. Finally, notice that risk comes in many forms; lack of skill or resources,
technical challenges, usability, politics, and so on. All these forms influence what is
addressed is early iterations.

Continuously engage users for evaluation, feedback and requirements – Iterative
development and the UP is about quickly taking small steps and getting feedback. It
requires continuous attention and engagement by business stakeholders and
subject matter experts to clarify and steer the project. At first, business may feel this
is an imposition.

Build a cohesive, core architecture in early iterations – That is, the UP is
architecture-centric. This is related to tackling the high risk concerns is early
iterations, since getting the core of the architecture established is usually a risky or
critical element. Early iteration typically focus on wide and shallow architectural
implementation, establishing the major design themes and the subsystem with their
interfaces and responsibilities.

Continuously verify quality; test early , often and realistically – Quality in this
context includes correctly meeting or exceeding the requirements in a sustainable
and repeatable process, with maintainable and scalable software.

Model software visually (with the UML) – An extraordinary percentage of the
human brain is involved in visual processing, which is a motivation behind the visual
or graphical presentation of information. A visual language such as the UML allows
us to visualize and reason about abstract models of software, moving quickly with
diagrammatic sketches of the big ideas in design.

Carefully manage requirements – This does not mean employing the waterfall
practice of fully defining and freezing the requirements in the first phase of a
project. Rather, it implies not being sloppy – that is, being skillful in the elicitation,
recording, prioritization, tracing, and lifecycle tracking of requirements

Practice change request and configuration management – This practice
encompasses several ideas: First change request. Although an iterative UP project
embraces change, it does not embraces chaos. Second configuration management.
Configuration and build management tools are used to support frequent (deally, at
least daily) system integration and test, parallel development, separate developer
6|Page
workspaces and configurations, and version control – from the start of the project.
In the UP, all projects assets (not just code) should be under configuration and
version control.

Apply use case/user stories – Informally, use case are written stories of using a
system. There are mechanism to explore and record functional requirements. The
UP recommends applying use cases as the primary form for requirements capture
and as a driving force in planning, designing and testing and writing end-user
documentation.
Benefits of Iterative Development





Early rather than late mitigation of high risks (technical, requirements, objectives,
usability and so forth)
Early visible progress
Early feedback, user engagement and adaptation, leading to refined system that
more closely meets the real needs of the stakeholders
Managed complexity; the team is not overwhelmed by “analysis paralysis” or very
long and complex steps.
The learning within an iteration can be methodically used to improve the
development process itself, iteration by iteration
Development Case
Iteration across four major phase:
1. Inception (Incep) – approximate vision, business case, scope, vague estimates.
2. Elaboration (Elab)– refined vision, iterative implementation of the core architecture,
resolution of high risks, identification of most requirements and scope more realistic
estimates.
3. Construction (Const)-iterative implementation of the remaining lower risk and easier
elements and preparation for deployment.
4. Transition (Trans) – user acceptance test, system integration test, stress test and
deployment.
Discipline
Discussion with Domain
Expert
Activity
Design Domain
Model
Incep
Elab
Cons
Trans
E1..En
C1..Cn
T1..Tn
s
r
7|Page
Requirements
Class Design
s
r
Sequence
Diagram
Interaction
s
r
Business Rules
Specification
s
Test Code
s
User Stories
s
High Level
Overview/Vision
s
Supplementary
Specification
s
Iteration Plan
s
Implementation Design
r
s
r
Project Management
Software
s
Development Plan
r
r
r
Testing
Test Model
s
r
r
Environment/Deployment Installation
s
Table 1.0 s-start; r-refine
Example – 2-3 days Inception and 4 Iteration
Discipline
Inception
Iteration1
Iteration 2
Iteration 3
Iteration 4
Requirements
2 – 3 days
4 weeks
4 weeks
4 weeks
4 weeks
Inception/ Initial Exploration
The purpose of the inception step is not to define all the requirements or generate a
believable estimate or project plan. At the risk over-simplification, the idea is to do just
enough investigation to form a rational, justifiable opinion of the overall purpose and
feasibility of the potential new system and decide if it is worthwhile to invest in deeper
exploration. Thus the inception phase should be relatively short for most projects.
8|Page
The intent of inception is to establish some initial common vision for the objectives of the
project, determine if it is feasible, and decide if it worth some serious investigation in
elaboration.
At the start of the project, the developers and customers have conversations about the new
system in order to identify all the significant that they can. However, they don’t try to
identify all features. As the project proceeds, the customers will continue to discover more
features. The flow of features will not shut off until the project is over.
As a feature is identified, it is broken down into one or more user stories, which are written
onto index card or their equivalent. Not much is written on the card except the name of the
story (eg : Login, Add User, Delete User, or Change Password). We aren’t trying to capture
details at this stage. We simply want something to remind us of the conversations we’ve
been having about the features.
Example – Lists sample inception activity and indicates the issue they address.
Activity
Comment
Vision and Business Case
Describes the high level goals and
constraints, the business case and provides
and executive summary.
User Stories
Describes the functional requirements
Supplementary Specification
Describes other requirements
Glossary
Key domain terminology
Risk List & Risk Management Plan
Describes the business, technical, resource,
schedule risks and ideas for their mitigation
or response.
Iteration Plan
Describes what to do in the first elaboration
iteration
Phase Plane & Software Development Plan
Low-precision guess for elaboration phase
duration and effort. Tools, people,
education and other resources.
The activity will be iteratively refined in subsequent iterations.
User Stories
Use case is an excellent technique to understand and describe requirements. Use cases are
requirements; primarily they are functional requirements that indicate what the system will
9|Page
do. Use case is text documents, not diagrams and use case modeling is primarily as act of
writing test, not drawing. In order to plan a project, we must to know something about the
requirements, but we don’t need to know very much. The real trick to use cases is to keep
tem simple. For planning purposes, we need to know only enough about a requirement to
estimate it. You may think that in order to estimate a requirement, you need to know all its
detail. But it’s not quite true. You have to know that there are details, and you have to
know roughly the kinds of details there are, but you don’t have to know the specifics.
Spiking, Splitting and Velocity
Stories that are too large or to small are difficult to estimate. Developers tend to
underestimate large stories and overestimate small ones. Any story that is too big should be
split into pieces that aren’t too big. Any story that is too small should be merged with other
small stories.
For example, concider the story “Users can securely transfer money into, out of, and
between their accounts”. This is a big story. Estimating will be difficult, and probably
inaccurate. However, we can split it into many stories that are much easier to estimate:





Users can login.
Users can logout.
Users can deposit money into their accounts.
Users can withdraw money from their accounts.
Users can transfer money from one of their accounts to another account.
Every user story have their own velocity points. Every week developer complete a certain
number of stories. The sum of the estimates of the completed stories is metric known as
velocity.
Use Case Format
Example Student Management System
Process Register Subject
Primary Actor
Student
Stakeholders and Interest
Student – wants register subject
Pre conditions
Student already registered in the system and
authenticated.
Post conditions
Student information is updated, get
timetable
Main Success Scenario
1. Student login into the system.
10 | P a g e
2. Choose menu register subject
3. System display available subject for
that semester
Use Case Diagram
Figure 1.0 : Student use case
Inception Checkpoint:
It is not the requirements phase of the project, but a short step to determine basic
feasibility, risk, and scope, and decide if the project is worth more serious investigation,
which occurs in elaboration. Not all activities that could reasonably occur in inception have
been covered; this exploration emphasizes requirements-oriented artifacts. Some likely
activies and artifacts in inception include:





a short requirement workshop
most actors, goals and use cases named
most use cases written in brief format ; 10-20% of the use case are written in fully
dressed detail to improve understanding of the scope and complexity
recommendations on what components to buy/build/reuse to be refined in
elaboration
plan for the first iteration
Elaboration (Iteration)
Elaboration is the initial series of iterations during which the team does serious
investigation, implements (program and tests) the core architecture, clarifies most
requirements and tackles the high risk issues.
Elaboration often consists of between two and four iteration, each iteration is
recommended to be between two or six week. Each iteration is time boxed, meaning its end
11 | P a g e
date is fixed; if the team is not likely to meet the date, requirement are placed back on the
future list, so that the iteration can end on time with stable and tested release.
Elaboration ends when the high risk issues have been resolved, the architectural core or
skeleton is complete, and the most requirements are understood. At the end of elaboration,
it is possible to more realistically estimate the remaining effort and duration for the project.
At the end of each iteration, the current running executable is demonstrated to the
customers. The customers are asked to evaluate look, feel and performance of the project.
They will provide their feedback in terms of new user stories.
The customers see progress frequently. They can measure velocity. They can predict how
quickly the team is going and can schedule high priority stories early. In short customers
have all the data and control they need to manage the project to their liking.
Example – Lists sample inception activity and indicates the issue they address.
Activity
Comment
Domain Model
This is a visualization of the domain
concepts.
Design Model (Class Design + Sequence
Diagram)
This is the set of diagrams the describes the
logical design. This includes software class
diagram, sequence diagram, package
diagram and so forth.
Test Model/Code
A set of first test programming can be
tested.
Prototype
Simple proof of concept can include in the
iteration
Domain Model
Figure 1.1 Domain Model
12 | P a g e
A domain model is widely used as a source of inspiration for designing software objects. A
domain model is a representation of real-world conceptual classes, not of the software
components. It is not a set of diagrams describing software classes, or software objects with
responsibilities.
Sequence Diagram
Figure 1.2 Sequence Diagram
Sequence diagrams are the most common of the dynamic models drawn by UML users. Use
sequence diagram when explain to someone how a group of objects collaborate or when to
visualize collaboration.
Some key ideas and best practices that will manifest in elaboration include:





do short time boxed risk-driven iterations
start programming early
adaptively design, implement, and test the core and risky parts of the architecture
test early, often, realistically
adapt based feedback from tests, users, developers
Practices of Extreme Programming


Whole Team
All the contributors to an XP projects, developers, business analyst, tester, etc work togother in
an open space, members in one team. The walls of this space are littered with big visible and
other evidences of their progress
Planning Game
Planning is continous and progressive. Every two weeks, for the next two weeks, developer
13 | P a g e










estimate the cost of the candidate features, and customer select those features to be
implemented based upon cost and business value.
Customer Test
As part of selecting each desired feature, the customer define automated acceptance tests to
show that the feature is working.
Simple Design
The team keeps the design exactly suited for the current functionality of the system. It passes all
the tests, contains no duplication, expresses everything that author wants expressed, and
contains as little code as possible.
Pair Programming
All production software us built by two programmers, sitting side by side, at the same machine.
Test Driven Development
The programmers work in very short cycles, adding a failing test, then making it work.
Design Improvement
Don’t let the sun set on bad code. Keep the code as clean and expressive as possible.
Continuos Integration
The team keeps the system fully integrated at all times.
Collective Code Ownership
Any pair of programmers can improve any code at any time.
Coding Standard
All the code in the system looks as if it was written by a single – very competent – individual.
Metaphor
The team develops a common vision of how the program works.
Sustainable Pace
The team is in it for the long term. The work hard, at the pace that can be sustained indefinitely.
They conserve their energy, treating the projects as a marathon rather a sprint.
Domain Driven Design
Software made up by many aspects. In order to create good software, you must have to know what that
software all about. To create an accounting system someone must have depth knowledge in accounting.
Whose have knowledge in accounting process? Software architect? No. Software developer? Not really.
Then who? The accountant itself, which is domain expert in their field. We should have heavy discussion
with domain expert. Include this person in business process discussion will reduce knowledge gap
between developer and domain expert.
In Domain Driven Design when the team decide to build a system, there should focus in the domain
itself. The complexity of the system should reside in the domain. The heart of software is its ability to
solve domain – related problems for its user.
-
Crunching Knowledge
14 | P a g e
Software architect/developer must have discussions session to tackle the complexity of the
software they want to build. In the session software architect/developer and domain expert will
have brainstorming and refining, questioning and explaining the overall system they wanted to
build. The understanding of the domain in this early stage can be presented in model/class
diagram which is supposed to be captured along the discussion held. Software architect must
explain what class diagram meant and how the domain expert can play their role.
Some people are naturally visual and diagrams help people grasp certain kinds of information.
UML diagrams are pretty good at communicating relationships between object and they are fair
at showing interactions. Simple, informal UML diagrams can anchor a discussion. Sketch a
diagram of three to five objects central to the issue at hand and everyone can stay focused.
Domain expert also need to involve in designing the model of the software base on their
understanding. They have to understand how the model would play into solution.
A simple prototype should be able to demonstrate the behavior of the system. There is no need
to show the infrastructure, user interface and persistence. The concreteness of this prototype
made clearer to the domain expert what the model meant and how it related to the functioning
software.
In the old waterfall method, the business expert talk to the analysts and the analysts digest and
abstract and pass the result along to the developers, who code the software. This approach fails
because it completely lacks feedback. The analysts have full responsibility for creating model,
based only on input from business expert. They have no opportunity to learn from developers or
gain experience with early version of software.
-
Ubiquitous Language
Every software team members (System Analyst/Functional also in software team members) and
domain expert should speak in the same level of language. Domain expert have limited
understanding of the technical term of software therefore developers need to describe in
common language and domain expert also have their own term, they also need to describe to
more understanding. A project faces serious problem when its language is fractured. The
communication should be directed within developer and domain expert. The indirectness of
communication conceals the formation of schisms – different team members use terms
differently but don’t realize it.
The model-based language should be used among developers to describe not only artifacts in
the system, but tasks and functionality therefore use model as the backbone of a language.
Commit the team to exercising that language relentlessly in all communication within the team
and in the code. Use the same language in diagrams, writing and especially speech.
15 | P a g e
The developers and domain expert can informally test the model by walking through scenarios,
using the model objects step-by-step.
Developers encourage sketching simple UML model when discussing software design. Class
diagram or object interactions are good enough. Class diagram should be organized by use case
scenario.
-
Layered Architecture
User Interface
Application
Domain
Infrastructure
Figure 1.0 : Layered Architecture
Figure 1.0 is layered architect. Domain Driven Design promoting this technique for separation of
concern. The value of layers is that each specializes in particular aspect of a computer program.
This specialization allows more cohesive designs of each aspect, and it makes these designs
much easier to interpret.
Layer
Description
Component
User Interface
Responsible for
aspx , jsp
showing information
to the user and
interpreting the
user’s command. The
external actor might
sometimes be
another computer
system rather than a
human.
16 | P a g e
Application Layer
Defines the job the
software is supposed
to do and directs the
expressive domain
objects to work out
problems. This layer
is kept thin. It does
not contain business
rules or knowledge,
but only coordinates
task and delegates
work to
collaborations of
domain object in the
next layer.
Controller, Presenter,
Application Services
Domain Layer
Responsible for
representing
concepts of the
business. The
complexity of the
process should be
tackle in this layer.
Heart of the system
resides here.
Entity, Value Object,
Repository, Domain
Services
Infrastructure Layer
Provides generic
technical capabilities
that support the
higher layer.
Persistence, Data
Access object is
defined here.
Email Notification,
UnitOfWork, Object
Relational Mapper
Partition a complex program in layers. The domain objects should not know how to string
themselves or how to displaying and so forth. Domain object should focus on the business
knowledge.
17 | P a g e
Figure 1.1 : Example class diagram captured by Solution Architect with domain expert.
Domain Driven Design Pattern
1. Entity
Some objects are not defined primarily by their attributes. They represent a thread of identity
that runs through time and often across distinct representations. Sometimes such an object
must be distinguished from other objects even though they might have the same attributes.
Mistaken identity can lead to data corruption. An object defined primarily by its identity is called
ENTITY.
2. Value Object
An object that represents a descriptive aspect of the domain with no conceptual identity is
called VALUE OBJECT.
3. Aggregate
Minimalist design of associations helps simplfy traversal and limit the explosion of relationships
somewhat, but most business domains are so interconnected that end up tracing long, deep
paths through object references. An AGGREGATE is a cluster of associated objects that we treat
as a unit for the purpose of data changes. Each AGGREGATE has a root and boundary. The
boundary defines what is inside the AGGREGATE. The root is a single, specify ENTITY contained
in the AGGREGATE. The root is the only member of the AGGREGATE that outside objects are
allowed to hold references to, although object within the boundary may hold references to each
other.
4. Repository
To do anything with an object, you have to hold a reference to it. For each type of object that
needs global access, create an object that can provide the illusion of an in-memory collection of
all objects of that type. Set up access through a well-known global interface. Provide method to
add and remove objects, which will encapsulate the actual insertion or removal of data in the
data store. Provide methods that select objects based on some criteria and return fully
18 | P a g e
instantiated objects or collections of objects whose attribute values meet the criteria, thereby
encapsulating the actual storage abd query technology. Provide REPOSITORIES only for
AGGREGATE roots that actually need direct access. Keep the client focused on the model,
delegating all object storage abd access to the REPOSITORIES.
5. Factory
Creation of an object can be a major operation in itself, but complex assembly operations do not
fit the responsibility of the created objects. Combining such responsibilities can produce
ungainly designs that are hard to understand. Making the client direct construction muddies the
design of the client, breaches encapsulation of the assembled object or AGGREGATE, and overly
couples the client to the implementation of the created object.
Shift the responsibility for creating instances of complex objects and AGGREGATES to a separate
object, which may itself have no responsibility in the domain model but is still part of the
domain design. Provide an interface that encapsulates all complex assembly and that does not
require the client it reference the concrete classes of the objects being instantiated. A programe
element whose responsibility is the creation of other objects is called a FACTORY.
6. Services
Some concepts from the domain aren’t natural to model as objects. Forcing the required
domain functionality to be the responsibility of an ENTITY and VALUE OBJECT either distorts the
definition of a model-based objects or adds meaningless artificial objects. A SERVICE is an
operation offered as in interface that stands alone in the model, without encapsulating state, as
ENTITIES and value object do.
Domain Driven Design Check List
1.1 Involve in software design discussion with domain expert.
1.2 Asking, refining, brainstorming, challenge the process with domain expert.
1.3 Include domain expert in modeling the domain in common language. Avoid of using computer
term in explaining domain model
1.4 Sketch class or domain object interaction and get domain expert feedback.
1.5 Test the domain model with a few scenarios.
1.6 Write simple prototype
1.7 Define layer architecture in the model.
1.8 Add Domain Driven Design pattern in the model.
Test Driven Development (TDD)
TDD is primarily a design technique with a side effect of ensuring that your source code is thoroughly
unit tested. Also known as test-first programming. In this practice, unit testing code is written before
the code to be tested, and developer writes unit testing code for all production code. The basic rhythm
19 | P a g e
is to write a little test code, then write a little production code, make it pass the test, then write some
more test code and so forth.
Advantages include:





The unit test actually get written – Human (or at least programmer) nature is such that
avoidance of writing unit test is very common, if left an afterthought.
Programmer satisfaction – If a developer writes the production code, informally debugs it, and
then as an afterthought adds unit tests, it does not feel very satisfying. However, if tests are
written first, and then production code is created and refined to pass the test, there is some
feeling of accomplishment of passing a test.
Clarification of interface and behavior – Often, the exact public interface and behavior of a class
is not perfectly clear until programming it. By writing the unit test for it first, one clarifies the
design of the class.
Provable verification – Obviously, having hundreds or thousands of unit tests provides some
meaningful verification of correctness.
The confidence to change things – In test first programming, there are hundreds or thousands
of unit test class for each production class. When a developer needs to change existing code
written by themselves or others, there is a unit test suite that can be run, providing immediate
feedback if the change caused an error.
Example Test Driven Development
[Test]
public void TestCreateCourse()
{
Crypto.DES crypto = new Crypto.DES();
Course course = new Course();
course.CourseName = crypto.encrypt("HP","itemBanking0@");
course.CreatedDate=DateTime.Today;
course.UpdateDate=DateTime.Today;
ItemBanking.Core.Persistence.ServiceTransaction serviceTransaction =
(ItemBanking.Core.Persistence.ServiceTransaction)ctx.GetObject("ServiceTransaction");
serviceTransaction.BeginTransaction();
ItemBanking.Core.Persistence.Repository.CourseRepository courseRepository
=
(ItemBanking.Core.Persistence.Repository.CourseRepository)ctx.GetObject("CourseReposi
tory");
courseRepository.Add(course);
serviceTransaction.CommitTransaction();
}
[Test]
public void TestGetCourse()
{
Crypto.DES crypto = new Crypto.DES();
20 | P a g e
ItemBanking.Core.Persistence.ServiceTransaction serviceTransaction =
(ItemBanking.Core.Persistence.ServiceTransaction)ctx.GetObject("ServiceTransaction");
serviceTransaction.BeginTransaction();
ItemBanking.Core.Persistence.Repository.CourseRepository courseRepository
=
(ItemBanking.Core.Persistence.Repository.CourseRepository)ctx.GetObject("CourseReposi
tory");
List<Course> list = courseRepository.GetCourses();
foreach(Course course in list)
{
Console.WriteLine(crypto.decrypt(course.CourseName,"itemBanking0@"));
}
serviceTransaction.CommitTransaction();
}
Figure 1.1 : Running NUnit to assert test
21 | P a g e
Acceptance Test
Unit tests are necessary but insufficient as verification tools. Unit tests verify that the small elements of
the system work as they are expected to, but they do not verify that the system work properly as a
whole. Unit test are white box test that verify the individual mechanisms of the system. Acceptance test
are black box tests that verify that the customer requirement are being meet.
Acceptance test are written by folks who do not know the internal mechanism of the system. These test
may be written directly by the customer or by business analysts, testers, or quality assurance specialist.
Acceptance test are automated. They are usually composed is a special specification language that is
readable are writeable by relatively nontechnical people.
Acceptance test are the ultimate documentation of a feature. Once the customer has written the
acceptance tests that verify that a feature is correct. In short, the acceptance test becomes the true
requirements document.
NHibernate
Working with object-oriented software and a relational database can be cumbersome and time
consuming in today's enterprise environments. NHibernate is an object/relational mapping tool for .NET
environments. The term object/relational mapping (ORM) refers to the technique of mapping a data
representation from an object model to a relational data model with a SQL-based schema.
NHibernate not only takes care of the mapping from .NET classes to database tables (and from .NET data
types to SQL data types), but also provides data query and retrieval facilities and can significantly reduce
development time otherwise spent with manual data handling in SQL and ADO.NET.
Dependency Injection
Dependency Injection describes the situation where one object uses a second object to provide a
particular capacity. For example, being passed a database connection as an argument to the constructor
instead of creating one internally.
The pattern seeks to establish a level of abstraction via a public interface, and to remove dependency on
components by (for example) supplying a plug-in architecture. The architecture links the components
rather than the components linking themselves or being linked together. Dependency injection is a
pattern in which responsibility for object creation and object linking is removed from the objects
themselves and transferred to a factory. Dependency injection therefore is inverting the control for
object creation and linking, and can be seen to be a form of IoC.
There are three common forms of dependency injection: setter-, constructor- and interface-based
injection.
Dependency injection is a way to achieve loose coupling. The technique results in highly testable
objects, particularly when applying test-driven development using mock objects: Avoiding dependencies
on the implementations of collaborating classes (by depending only on interfaces that those classes
adhere to) makes it possible to produce controlled unit tests that focus on exercising the behavior of,
and only of, the class under test. To achieve this, dependency injection is used to cause instances of the
22 | P a g e
class under test to interact with mock collaborating objects, whereas, in production, dependency
injection is used to set up associations with bona fide collaborating objects.
Mock
A mock object is a simulation of a real object. It replaces a collaborator and provides expected values to
the code under test. In addition, it supplies a mechanism to set up expectations about how it should be
used and can provide some self-validation based on those expectations.
Refactoring
Martin Fowler defines refactoring as “the process of a changing a software system in such a way that it
does not alter the external behavior of the code yet improves its internal structure.”
Every software module has three functions. First is the function it performs while executing. The second
function of a module is to afford change. Almost all modules will change in the course of their lives, and
it is the responsibility of the developers to make sure that such changes are as simple as possible to
make. A module that is difficult to change is broken and needs fixing, even though it works. The third
function of a module is to communicate to its readers. Developers whose are not familiar with the
module should be able to read and understand it without undue mental gymnastics. A module that does
not communicate is broken and needs to be fixed.
Stress Test
Before the application is release into production environment, its need to go through a stress test. A
stress test is useful to determine the performance of the application. Developers can get how many
concurrent connection it can serve before the application crash. There are a few tools we can use like
JMeter.
23 | P a g e
Reference:
1.
2.
3.
4.
5.
6.
7.
Applying UML and Patterns – Craig Larman
Domain Driven Design – Eric Evans
Applying Domain Driven Design and Pattern – Jimmy Nilsson
The Unified Modeling Language User Guide – Grady Booch, James Rumbaugh, Ivar Jacabson
Patterns of Enterprise Application Architecture – Martin Fowler
Agile Principles, Patterns, and Practices in C# - Robert C Martin, Micah Martin
The Pragmatic Programmer – Hunt, Thomas
24 | P a g e