- Process Models and Agile Development:
- Understanding Requirements
- Use case diagram
- Use case narrative
- Activity diagram
- Class diagram
- Design patterns
- Software refactoring
- Software quality
مدل‌های فرایند و توسعه چابک
- adaptable approach: رویکرد سازگار
- activity: فعالیت کاری
- action: کنش
- task: وظیفه
- linear
- iterative
- evolutionary: circular iterative
- parallel
prescriptive process models strive for structure and order
- waterfall: when requirements are well understood
- v
- incremental: parallel lines
- prototyping: circular
- spiral
- concurrent
- commutation
- planning
- modeling
- construction
- deployment
- project tracking and control
- risk management
- quality assurance
- configuration management
- technical reviews
Agility: rapid, incremental delivery of software. Conventional wisdom: that the cost of change increases nonlinearly as a project progresses.
A well-designed agile process may “flatten” the cost of change curve by coupling incremental delivery
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
- satisfy the customers
- welcoming changes
- deliver working software frequently
- daily meeting
- motivated individuals
- face-to-face communications
- working software
- technical excellence
- simplicity
- self–organizing teams
- tunes and adjusts
- Component based development: the process to apply when reuse is a development objective
- Formal methods: emphasizes the mathematical specification of
requirements
- AOSD: provides a process and methodological approach for
defining, specifying, designing, and constructing aspects
- Unified Process: a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified
Modeling Language (UML)
فهم نیازمندی‌ها
مهندسی نیازمندی‌ها
- basic understanding
- identify stakeholders
- asking the first question
- meeting with stakeholders & engineers
- agenda suggestion
- facilitator controls meeting
- analysis model
- deliverable realistic system
- written document
- models
- user scenarios
- prototype
- errors in content or interpretation
- required clarification
- missing information
- inconsistencies
- unachievable requirements
Quality function deployment: استقرار عملکرد کیفیت
- needs -> technical requirements
Elicitation Work Products: استخراج محصولات کاری
EWP is a statement of need bounded for the product which customers, users and stakeholders participated to make
EWP includes description of system, requirements, usage scenarios or any provided prototypes.
- scenario-based elements
- class-based elements
- behavioural elements
- flow-oriented elements
In order to achieve the best result, the stakeholders “win” condition first should get determined.
Then, the stakeholders’ win condition can get negotiated in order to achieve a “win-win” condition.
- Is the requirement consistent with the overall objective of the system?
- Does the requirement have the proper level of abstraction?
- Is the requirement really necessary?
- Do any requirements conflict with other requirements?
- Is each requirement testable, once implemented?
- Use case elements are based on the requirements of the system, not the solutions.
- In use case diagram we show what the system does as opposed to how the system works.
- Each element in the system must effect or be effected from the system.
- Each element outside the system must depend or be depended from the system elements.
- association: line (انجمنی)
- generalization: arrow (تعمیم)
- dependency: dashed arrow (وابستگی)
A generalization relation depicts an inheritance of the use cases where the child use case have the parent’s features.
Usually when two use cases have the same type, a generalization relation is used.
- include is mandatory dependency while extend is secondary.
- include can connect to actors while extend can’t.
Use case diagram shows the requirements of the system visually while use case narrative describes what system requirements are.
Use case narrative includes information from analysis, design & coding steps.
-
Assumption: فرضیات
- Conditions which must be met before the execution of the system.
- Unlike pre-conditions, assumptions are not evaluated before the execution.
- e.g. user authentication for banking transactions.
-
Pre-conditions: پیش‌شرط‌ها
- Like assumptions, pre-conditions must be met before the execution of the system.
- Unlike assumptions, pre-conditions are evaluated before the execution of the system.
- e.g. evaluation of the user input
-
Start: شروع
- By calling a use case in the system, the start is began.
- The start part can be called from an actor, another use case or in a timely manner.
- When start is began, the different states of the system is described.
-
Dialogue: گفت‌وگو
- Includes the commutation between the actor and use cases or uses cases themselves.
- Shows the different ways of how to implement a feature.
- Dialogue does not illustrate implementation.
-
End: پایان
- A use case can end from controlled/planned or uncontrolled/unexpected actions.
- The causation of the end should be in the dialogue part.
- When the use case can end in many ways, pre-conditions can be used in order to balance the outputs.
-
Post-conditions: پس‌شرط‌ها
- A list of conditions and stated that must be met after the execution of the system use case.
- Because the ending of the use case is not well-defined, system must be remain stable. Thus, post-conditions are used.
- Activity diagram describes the processes, dependencies, logical process of the system.
- This diagram is an enhanced version of the flowchart which is used in the UML.
- AD defines the steps and implementation of how things are done in the system; so details are not debated.
- Each activity can itself have multiple activities inside.
- An activity diagram have one start point and one or more end points.
- When an activity diverge and can run in parallel.
-
When multiple parallel activities merge and become one.
Study diagram symbols in SLIDES
- Class diagram is the main source of inspirition for making software. UML diagrams can be used to complete the details.
- Class
- Name
- Attribute
- Activity
- Relation
- Association (انجمنی)
- Plurality (تعدد)
- Restriction (محدودیت)
- Restricted (محدود شده)
- Reflation (بازتابی)
- Aggregation (تجمع) Aggregation is a special kind of association where one or more relations belong to another relation.
- Composition (ترکیب) Composition is a special kind of aggregation where if the parent relation demolishes, the childrent relations demolish as well.
- Generalization (تعمیم)
- Association (انجمنی)
Experienced designers try to reuse solutions that worked before. Patterns capture the static and dynamic structures and collaborations of successful solutions.
Gang of four design patterns are a set of 23 design patterns.
- Creational: deal with initializing and configuring classes or objects.
- Structural: Deals with composition of classes or objects and deal with decoupling interface and implementation of classes and objects.
- inheritance
- Behavioral: Characterizes ways in which classes or objects interact
and distribute responsibility
-
Intent
Define a one-to-many dependency between objects.
-
Example
- Different plot engines using the same spreadsheet data.
- Email subscriptions.
-
Applicability
- When an abstraction has two aspects, one dependent on the other.
- When a change to one object requires changing others.
- When an object should be able to notify other objects.
-
Participants
- subject
- observer
- concrete subject
- concrete observer
-
Intent
Define an object that encapsulates how a set of objects interact by loose coupling.
Restricts direct communication between objects and forces them to collaborate via a mediator, hence reducing the dependencies between then.
-
Example
- Planes in an airport communicate with the traffic tower instead of direct communication.
- User inputs in graphical interfaces.
-
Applicability
- A behavior that’s distributed between several classes should be customizable without a lot of subclassing.
-
Participants
- mediator
- concrete mediator
- colleague
- concrete colleague
-
Intent
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
-
Example
- Having different classes for TCPConnection state such as TCPClosed & TCPOpen where TCPConnection’s methods would act differently in each state.
-
Applicability
- An object’s behavior depends on its state, and it must change its behavior at run-time depending on that state.
- The state pattern convert logical conditions into structural subclasses.
-
Participants
- context: TCPConnection
- state: TCPState
- concreate state subclasses: TCPEstablished, TCPListen, TCPClosed
-
Intent
Define a family of algorithms, encapsulate each one, and make them interchangeable. The object will appear to change its class.
The difference between state and strategy is that:
- Unlike state, in strategy we have different implementation of the same goal.
- Unlike states, strategies are completely independent and unaware of each other.
-
Example
- Sorting algorithms
-
Applicability
- Many related classes differ only in their behavior.
- An algorithm uses data that clients shouldn’t know about.
-
Participants
- context
- strategy
- concrete strategy
-
Intent
Compose objects into tree structures to represent part-whole hierarchies.
-
Example
- Calculating price of boxes and products.
-
Applicability
- You want to represent part-whole hierarchies of objects.
- You want clients to be able to ignore the difference between compositions of objects and individual objects thus treating them uniformly.
-
Participants
- client (Box calculator)
- component (Box)
- composite (Composite Box)
- leaf (Book, Videogame)
-
Intent
Attach additional responsibilities to an object dynamically.
-
Example
- Notify users with email as well as SMS.
-
Applicability
- To add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects
- For responsibilities that can be withdrawn.
-
Participants
- component (INotifier)
- concrete component (Notifier)
- decorator (BaseNotifierDecorator)
- concrete decorator (SMSDecorator, EmailDecorator)
Software refactoring is the process of changing the structure of software without any alteration in its behavior and functionality.
extract: make, create inline: delete if unnecessary
-
extract class
-
extract subclass
-
extract superclass
-
extract interface
-
move class
-
rename class
-
extract method
-
inline methods
-
move methods
-
pull up methods
-
push down methods
-
rename methods
-
extract variable
-
inline variable
- determine the signature of the potentials
- structural analysis
- behavioural analysis
- qualitative analysis
- detect the potentials
- detect structural candidates
- detect behavioural candidates
- detect qualitative candidates
- investigate behaviour preservation
- investigate detected opportunities
- apply refactoring
- code-to-code transformations
- semi-automatically or manually
-
functional requirements: define what a software product must do, features and functions
-
non-functional requirements: quality attribute factors of the system
-
quality factors -> quality subfactors -> OOP concepts -> quality metrics
How easy is to a system can be modified for conditions other than its purpose
How much a module can be used in more than one system
How easy is to correct a module faults
How easy is to build upon a module
- formula: abstraction + polymorphism + inheritance - final and static class
How much a system is composed of different modules
- formula: cohesion + encapsulation - coupling - complexity
How well the system can adapt to changes
- formula: cohesion - coupling - complexity - inheritance
How well the system can be diagnosed for deficiencies or causes of failures
- formula: cohesion + inheritance - coupling - complexity - encapsulation
How much each component facilitates test criteria
- formula: cohesion + inheritance - coupling - encapsulation
How resistance the system is to the amplification of changes
- formula: abstraction - coupling - complexity
How simple is the design and implementation of the system
- formula: 1 - complexity
- formula: (abstract classes + interfaces / classes) + (abstract methods / methods)
- formula: average DIT, where DIT is the level of the class in an inheritance hierarchy
- formula: average INS factors within the class, where INS is the instace method and instance variables.
- formula: average number of relations of each methods in class
- formula: (overloaded methods + overriden methods) / methods
- formula: (private variables / variables) + (private methods / methods)
- formula: (sum of iteration, declaration and jumps in each method) / lines of code in the class